My testbench uses a function that is defined in a modelsim package (init_signal_spy). So I can't use this testbench with a different simulator than ModelSims vsim, for example Candence's ncsim. But there is an equivalent function for ncsim (nc_mirror) in the cadence packages. The solution is that I need to have two different testbenches.
But I want to use only one. One solution could be, to define a package only if some constant is set. But I don't know if that is possible.
The general way to make proprietary functions from different vendors appear the same in a test bench, is to use a wrapper package that converts the functions to a function interface that you define.
To support both ModelSim and NCSim, you create three files:
The package wrap interface is defined in "wrap.vhd", thus with a common interface to functions, independent of the simulator. The package body wrap is then defined in "wrap_modelsim.vhd" and "wrap_ncsim.vhd", with implementation depending on simulator.
When compiling, only the appropriate package body file is used, depending on the simulator.
The test bench then use work.wrap package, and can access the converted functions through wrap.{function}.
We developed a small package for this very purpose few years back. I just now uploaded a copy of the same @ http://verifnews.org/publications/papers/
Thanks Jim for keeping us updated on this thread.
Srini, Ajeetha
There is also a solution described using a general Systemverilog bind which is tool independent. That will help you to avoid the use of proprietary init_signal_spy!! See the good paper from Dave Rich explaining how to use BIND in UVM http://events.dvcon.org/2012/proceedings/papers/01P_3.pdf
If you are not using UVM, then you just must remember that UVM is only a library in systemverilog so you can use the bind concept too without having to use the driver class in the example.
Basically, the paper shows different ways to connet a DUT or sub modules of the DUT and the testbench.
It offers 3 good options 1) Virtual interfaces 2) Abstract classes 3) Bind using virtual interfaces or abstract classes
Of course this solution only works to avoid the proprietary "signal spy" functions. If you are interested to be general compatible with other tool functions like visualization streams, file read, then you need to wrap the functions so that you select the proper tool call depending on the tool you are using (using defines), as commented above.
