Information Technology Reference
In-Depth Information
shortened. Now the testbench development itself is a multi-step process: Following
are the steps at IP level testbench creation:
1.
Collect already available testbench components
2.
Create template components for new interfaces
3.
Connect verification IPs to make testbench
4.
Connect various components with the design under test
5.
Configure the verification IPs
6.
Generate constrained random stimulus
7.
Run sample test
The presented work automates the creation of all the above tasks and finally connects
the testbench created with the actual design. The minimum required information related
to interface connection and configuration is collected from user in the form of tabular
data at block level. Based on this information, test environment is created, configuration
is done, interface instances are connected to RTL design, meaningful random stimulus
is generated and finally a top level testbench is created. At block level we use standard
templates to produce new VIP components and table based input for connections etc
where as at SoC level this methodology reuses the block level information to create and
integrate the testbench. So this methodology is useful at both the levels.
At SoC Level where VIPs are used in verifying IPs, the real advantage is in
collecting and connecting many such IP level environments from IP level to the SoC
level. The previous information of block level can be reused. The user will just have to
do hierarchical name changes in the previous database and design will automatically be
connected to different VIP instances which save a lot of time in testbench creation.
Simultaneously debugging time is also saved. Till date VIP instance connection to DUT
is done manually, this is error prone and debugging connection related problem takes lot
of time especially at later stage. Once the user has defined interface information in
tabular format, connection is automatically done. If it runs successfully in a testbench,
the information is made golden at block level. Every organization follows a standard
directory structure. The need for organization specific tools and methodology arises
because of specific market and product requirements. The tool set used are also not
different. There are three parts of this work; process definition, current integration
activities and enabling automation. Because of these requirements, methodology plays
more important role in creating custom tools which integrate specific steps and
processes and good practices to come up with a fully integrated testbench which can
drive transaction into the DUT right within few hours both at block level as well as SoC
level. The usage of this methodology has reduced testbench integration time
considerably and also removed dependence on domain knowledge and experience.
2
Previous Related Work
The problem of testbench automation has been tackled in different ways. This section
presents some of the relevant existing solutions and how the presented work is
innovative in nature.
