Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VHDL White box testing.

71 views
Skip to first unread message

Andrew Bridger

unread,
Sep 14, 2001, 12:27:44 AM9/14/01
to
Hi,
I am at the stage of verifying(simulating) my FPGA VHDL design. Thus
far I have followed the 'black box' testing approach. I have a
testbench that sits around my top level entity and feeds the inputs
and checks the outputs.

I would now like to test my design more throughly by checking signals
deep inside my design hierarchy (white box). The problem I have is
how can my testbench get access to the signals that exist inside my
design, in an elegant fashion?

The only solution I have come up with so far is to add any signals I
want to observe to the entity and bring them out at the top level.
This is very cumbersome and a real hassle for signals deep in my
hierarchy. Surely there must be a better way.

I am using modelsim 5.5c, Foundation Express ISE (Service Pack 8).


Thanks
Andrew

Thomas Stanka

unread,
Sep 14, 2001, 3:02:21 AM9/14/01
to
Andrew Bridger wrote:

> I would now like to test my design more throughly by checking signals
> deep inside my design hierarchy (white box). The problem I have is
> how can my testbench get access to the signals that exist inside my
> design, in an elegant fashion?

I would expect, that any signals inside are controllable from outside
bye a set of Stimuli. (OKOK, in reality

> The only solution I have come up with so far is to add any signals I

[..]


> hierarchy. Surely there must be a better way.

Yes there is.



> I am using modelsim 5.5c, Foundation Express ISE (Service Pack 8).

In Modelsim you could set any signal with the force command. You could
even write a complete testbench in Tcl. I think there was an article
about Tcl-testbenches here a few month ago, you could try google to
search about the topic.

bye Thomas

--
Thomas Stanka
Bosch SatCom GmbH BC/EMD4
D-71522 Backnang Tel. +49 7191 930-1690
Gerberstr. 49 Fax. +49 7191 930-21690
Zi. 10/528 Thomas...@de.bosch.com

Tim Hubberstey

unread,
Sep 14, 2001, 3:24:18 AM9/14/01
to

There are at least 2 ways to handle this:

1. You can create a set of shared (global) variables defined in a
package and 'USE'd in all modules you want to monitor. You can then
assign to these variables and monitor them at the top level. I have
never done this so I'm not familiar with the exact syntax but it is
simulator-independent.

2. Since you're using Modelsim, you can use the Tcl interface to
directly access the value of any signal or variable in your design. The
most general method is to use 'when' statements to watch the signals or
variables of interest for changes and then drive signals in your test
bench. You must specify the full path for signals and the full path plus
process name for variables. The Tcl commands are entered into a script
file and executed with the 'do' command.

For example:

when -label unique_name {
/testbench/uut/top/module1/signal_to_watch'event } {
force testbench_signal [examine
/testbench/uut/top/module1/signal_to_watch]
}

This will force the top-level signal 'testbench_signal' to track your
signal of interest, with possibly one delta delay.

The down side of doing this is a fairly significant hit on simulation
time every time the 'when' gets executed. This is because Modelsim must
pause the simulation engine and run the Tcl interpreter for each 'when'
executed.

The up side is that it is completely non-invasive (no source changes)
and it allows you to use the considerable power of the Tcl language to
implement your testbench, if you want. Also, once you have taken the hit
for the 'when', Tcl is usually more efficient (in my experience) than
VHDL at doing testbench code. Most of my testbenches use some
combination of Tcl and VHDL unless simulation time is of critical
importance.
--
Tim Hubberstey, P.Eng. . . . . . . . . . . . . . . Marmot Engineering
Vancouver, BC, Canada . . . . . Hardware/Software Consulting Engineer
. . . . . . . . . . . . . . . . VHDL, ASICs, FPGAs, embedded systems

Ansgar Bambynek

unread,
Sep 14, 2001, 7:11:04 AM9/14/01
to
Hi,

under the following URL you will find some detailed informations on how to
do this:

http://www.model.com/resources/appnotes/vhdl_testbench.asp

HTH

Ansgar
--
Attention reply address is invalid.
Please remove _xxx_
Andrew Bridger <andrew....@xtra.co.nz> schrieb in im Newsbeitrag:
986a83c3.01091...@posting.google.com...

Michal Rutka

unread,
Sep 14, 2001, 8:22:44 AM9/14/01
to
>>>>> "Andrew" == Andrew Bridger <andrew....@xtra.co.nz> writes:
[...]
Andrew> I would now like to test my design more throughly by checking
Andrew> signals deep inside my design hierarchy (white box).
[...]
Andrew> I am using modelsim 5.5c, Foundation Express ISE (Service
Andrew> Pack 8).

Look for a signal_spy in your modelsim documentation (end of the
Chapter 4).

Regards,

Michal

VhdlCohen

unread,
Sep 14, 2001, 4:18:09 PM9/14/01
to
ModelSim has a PLI called signal_spy that allows REDA access to signals inside
hierarchy.
THe program is at theri site model.com
--------------------------------------------------------------------------
---------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830
http://www.vhdlcohen.com/                 vhdl...@aol.com  
Author of following textbooks:
* Component Design by Example ... a Step-by-Step Process Using
  VHDL with UART as Vehicle",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
--------------------------------------------------------------------------
------------------------------------------


Mike Treseler

unread,
Sep 14, 2001, 4:17:07 PM9/14/01
to
Thomas Stanka wrote:
>
> Andrew Bridger wrote:
>
> > I would now like to test my design more throughly by checking signals
> > deep inside my design hierarchy (white box). The problem I have is
> > how can my testbench get access to the signals that exist inside my
> > design, in an elegant fashion?
>
> I would expect, that any signals inside are controllable from outside
> bye a set of Stimuli. (OKOK, in reality . . .

I think this is actually a good point.
VHDL allows you to virtualize a complex
interface in a procedure. While this
does require some effort, once it
is done, stimulating and observing
internal processes is easy and the result
is a more complete test that works
like a hardware ASIC tester would.

Another tack to take is to have a
testbench for each entity/arch
to cover the low-level details.
In this case, the top level test can
just make sure it hits all
the modes and functions and not
worry so much about the internals.

--Mike Treseler

0 new messages