0

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.

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
Sadık
  • 4,249
  • 7
  • 53
  • 89
  • 1
    Of course, you could always the VHDL-2008 external names as I suggested in your previous question: http://stackoverflow.com/questions/24527192/get-internal-signals-of-vhdl-design-in-ncvhdl-alternative-to-modelsims-signal. If Cadence does not support external names, you should file a bug report. – Jim Lewis Jul 03 '14 at 18:10
  • I admit that this would be the best solution for that problem. I'm going to check that and write a comment in the other thread. But in this question, init_spy_signal and nc_mirror are only examples. – Sadık Jul 04 '14 at 06:40

3 Answers3

5

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:

  • wrap.vhd
  • wrap_modelsim.vhd
  • wrap_ncsim.vhd

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}.

Morten Zilmer
  • 15,586
  • 3
  • 30
  • 49
1

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

Srini
  • 11
  • 1
  • Thanx, very nice idea. One thing I still don't understand: nc_simutils_pkg.vhd will only compile under ncvhdl and mti_simutils_pkg.vhd will only compile with vcom. So I need to make changes to my compile script each time I change the simulation environment, right? – Sadık Jul 04 '14 at 06:30
  • 1
    Do you have a direct link to the package/paper? The link you gave is a generic one. Thanks. – EML Aug 03 '15 at 11:31
-1

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.

Community
  • 1
  • 1
Joniale
  • 515
  • 4
  • 17
  • Should i remove my post?. Nobody find interesting the idea of avoiding "init_signal_spy" to be compatible between different simulators? I don't understand the negatives. – Joniale Nov 10 '16 at 10:23