Information Technology Reference
In-Depth Information
[5] Proposes an automated verification methodology (VeriSC2) that provides
working testbenches during hierarchical decomposition and refinement of the design,
even before the RTL implementation starts. This creates a running testbench but does
not talk about interface connection and definition which remains the central idea of
the paper.
[6] Deals with SoC design and testbench automation based on IP_XACT format.
The Platform Verifier methodology creates a SoC level testbench but replaces the IP
instances with empty modules and verification components. While the presented work
connects different Verification IP's with the actual RTL/design without replacing IP
instances.
Synopsys uvmgen tool creates an UVM [1] [7] based testbench based on certain
inputs given by user. This approach is quite helpful at block level, but at SoC level
this approach is not feasible and lacks the interface connection with actual RTL.
Here an automated UVM [1] based testbench is created while connecting the
interfaces with the real design and most importantly re-using the IP level connection
information at SoC level. The concept of standard directory structure and use of
coding guidelines along with the use of central repository has been introduced in the
presented work.
3
The Flow and Methodology
In this section, the flow of creating testbench around IP and SoC level has been
discussed. The existing flow is presented in brief and more emphasis is laid on the
new steps.
At IP level: As discussed in the section II the existing VIPs have to be fetched and
new ones have to be written if they don't exist. After that the top level testbench has
to be written which integrates all the VIPs together and comes up with top level test
cases which have the hooks of the VIPs to exchange transaction details.
Based on certain inputs given by user on interfacing and configuration, a top-level
testbench is created and integrated which is also connected to the actual RTL. The
output of this step is a working testbench, which can be modified according to the
requirements. From the user perspective, he/she just needs to specify the different
VIP definitions. For an existing VIP we have the concept of central repository.
3.1
Use of Central Repository Database
It is assumed that different versions of standard Verification IPs used across various
teams are kept in a common database. This approach aids in knowledge sharing and
saves time in searching for the correct version of VIP.
Either a new VIP template is generated or existing VIP is fetched depending on the
user input. The new VIP template classes are generated as discussed in [5,6], the
templates used also impose coding guidelines for the testbench writers. Customization
of VIP is important when VIP is reused and plugged in across different projects,
hence is standardized according to the company's best practices.
Search WWH ::




Custom Search