Accessing internal variables from another entity

[GaLaKtIkUs™]

I have some entity/architecture couple.
I'm wrinting a testbench for it. Is it possible to access some internal
variables/register of my entity/architecture couple from the testbench ?

 

[Ralf Hildebrandt]

GaLaKtIkUs™ wrote:

I have some entity/architecture couple.
I'm wrinting a testbench for it. Is it possible to access some internal
variables/register of my entity/architecture couple from the testbench ?

Create a package. Put eighter a "shared variable" or a "signal" into
this package. Include this package in all components, where you want to
access this thing (read or write).

A shared variable has the advantage, that you may write from different
locations to it (witout resolving the value) and it is updated
immediately. A signal has the advantage, that you may use 'event.

Ralf

 

[Jonathan Bromley]

On 17 Oct 2005 07:06:33 -0700, "GaLaKtIkUs™" <taileb.mehdi@gmail.com>
wrote:

I have some entity/architecture couple.
I'm wrinting a testbench for it. Is it possible to access some internal
variables/register of my entity/architecture couple from the testbench ?

Not directly.

There are at least five possible indirect methods:

1) Add an extra output port on the entity so that you can
push the internal signal out to the testbench.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This approach is so messy and generally horrible that no-one
I know of uses it.

2) Use global (package) signals
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A signal declared in a package is visible to any design unit
that "uses" the package. You can make a package containing
a bunch of signals that you will use as probes, and then you
can drive DUT internal values on to those probes - but this
requires you to modify the source code of the DUT. It's
easy to make it work, but it's very ugly. If you have more
than one instance of a design module that does this probing,
then you will need some trickery with configurations to
ensure that each instance drives different probe signals.

3) Use a simulator-specific probing mechanism
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ModelSim has a mechanism called SignalSpy; other simulators
no doubt have similar arrangements, although I haven't worked
with them. They allow the testbench code to inspect
signals within the design hierarchy by calling special functions,
usually written using the simulator's programming language
interface (FLI for ModelSim, VHPI for Cadence, etc). This is
nice because it's non-intrusive (no need to change the DUT code)
but it's simulator-specific.

4) Use the simulator's command language
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most serious simulators can be scripted in Tcl or similar.
From the simulator command line you can probe any signal,
force signals, set breakpoints and so on. Once again this
is of course simulator-specific, and the performance is
probably not so good as (3), but it's easy to get started.

5) Use an external tool such as Specman or Vera
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Achieves the same effect as (3), but the simulator-specific
details are hidden for you by the tool's own interface to
the simulator. In practice you will probably then write
most of the testbench in that external tool as well, to take
advantage of all the extra features such as constrained-random
stimulus and functional coverage. Elegant and effective,
but $$$$$.

There may be other approaches that I've missed - any offers?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Reiner Huober]

There may be other approaches that I've missed - any offers?

File I/O?!

Hubble.