Information Technology Reference
In-Depth Information
3.4
Re-use of Block Level Information at SoC Level
During IP level verifications users provide interface and configuration details for a
specific VIP. This information is treated golden after successful verification. Interface
related information includes name of protocol, instance name and various connection
details. While creating SoC level testbench, this information can be updated by doing
minimal changes related to hierarchy etc. Thus re-usability of information saves a lot
of time both in testbench creation and debugging.
Configuration related information includes specific settings of a particular VIP,
which are quite important for using any VIP. This can also be ported to SoC level.
Figure 1 describes the flow of methodology at IP level. Followings are steps for
automatic generation of UVM based testbench at IP level:
•
Input the top level design for which testbench has to be made.
•
Populate VIPs in your working area.
•
Define the required information (interface connection and configuration) in
tabular format.
•
Invoke the ip_tb_gen tool.
•
After this, a top level testbench will be made so start the verification
process.
•
Incase if there is any error in connection definition, update the tabular
data.
•
Repeat the process till connection definitions are clean.
•
Once the verification closure is done, the definition is then made golden at IP
level.
At this point a running IP level testbench is made. It is important to note that at SoC
level test-bench integration, the VIP connections remain similar and only hierarchy of
connections may change. Hence testbench integrator will reuse the connection
information at SoC level. While doing so it not only eliminates the scope of manual
error that is not caught by simulator compiler but also saves a lot of manual effort and
time which would otherwise be spent in learning protocol and signals, doing manual
integration and debugging wrong connection.
Figure 2, describes the flow at SoC level. The flow is similar as IP level with
following changes: The connectivity information reused from IP level needs to be
updated by testbench integrator. There will be multiple instances of protocols and
hence multiple tabular definition files will be used as input by the tool.
Multiple projects will be able to share the connection information with few
changes in the connectivity tabular database while the actual changes required in the
testbench need large manual efforts. So finally the methodology delivers a fully
functional testbench both at IP and SoC level.
This methodology adds value both at IP and SoC level testbench creation and
integration.
