Search form

My Account Menu

The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.

Techniques & Tools

The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference.
After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.

Analog/Mixed Signal

The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.

Coverage Forum

Additional Forums

The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).

No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.

Mentor Learning Center

The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.

The both WIDTH_A and WIDTH_B parametrize my agent, interface, monitor_bfm and driver_bfm. The code will not compile, as WIDTH_A and WIDTH_B are not defined at the level my_interface_hdl pacakge. My workaround is to add extra include file with macro like:

In reply to chr_sue:
It will not work, as, in my case, those parameters are defined at the level of hdl_top (test_bench). I don't think it's a good idea, if an interface from a VIP library depends on packages defined at the level of testbench.

I do not know the details of your environment, but I believe it is quite common a VIP has a common package and is provided together with the VIP source code. Using this package in a system level is not forbidden.

I do not know the details of your environment, but I believe it is quite common a VIP has a common package and is provided together with the VIP source code. Using this package in a system level is not forbidden.

You are right that VIP can provide extra common packages.
However, in my case, the parameters are propagated top->bottom. During compilation of VIP packages, compilation will fail, as parameters are unknown yet (they are defined at the level of testbench). Basically, I would need parametrized packages which don't exist in SystemVerilog.

SV packages are always top to bottom. I guess your VIP is provoding a common package which is not RO. There you can make your settings regarding your system application.
Then you have to adopt your compile script with respect to your new structure. I do not see any problem.

SV packages are always top to bottom. I guess your VIP is provoding a common package which is not RO. There you can make your settings regarding your system application.
Then you have to adopt your compile script with respect to your new structure. I do not see any problem.

I think we have a misunderstanding.
I assume that VIP packages, in view of reusability, should be testbench agnostic. Thus, they should not make any assumptions that testbench will provide an extra package with parameters. This information, should come through actual parameters syntax (ie. my_interface #(.WIDTH_A(5), .WIDTH_B(3) inter;).

Moreover, let's imagine that in the testbench we would like to have 2 interfaces of the same type but differently parametrized. Solution with an extra package with parameters would not work in such case.

I don't see really the benefit of your approach. In any way your VIP has to be configured with respect to certain parameters etc. This package prrovides certain actual parameters for a configuration
It is an elegant way to use a package for this.
What you are doing is simple Verilog style, not knowing about packages.
If your common VIP packages is RO we can use this to perfrom a systme level setup by exporting imported names of packages.

Solution

No, this solution doesn't address and solve my issue.
As I tried to explain in the first post, my problem was the fact, that a VIP provides an interface which uses structures (or array of structures), which are parametrized. The interface is connected to a DUT, which uses the same kind of ports (structures, or array of structures). As the same type must be shared between interface, monitor_bfm_interface and driver_bfm_interface one would define it, as @chr_sue rightly pointed, in a common package: