Tcl vs. VHDL testbenches
Alex Eggenberger
testbenches in either Tcl or VHDL. I'm new to vhdl so I have some
questions:
-Are there inherent simulation speed differences?
-Can a Tcl testbench be used with as many simulators as a VHDL tb?
That is, are Tcl TBs portable?
-Is one language more efficient to write testbenches for
simple/complex entities?
-If there is one, what is the testing paradigm for vhdl for FPGA
designs?
Alex
Abernathey Family
Probably the biggest drawback to using TCL is that it is a different
language skill. When the designers are working in VHDL, a TCL testbench
will require a TCL person FOREVER to add the tests, coverage, etc.
The upside of TCL is that you can do some simple things that are handy
for block level testing.
Srinivasan Venkataramanan
eg...@island.net (Alex Eggenberger) wrote in message news:<930dfcf0.01091...@posting.google.com>...
> I have read conflicting statements over the advantages of writing
> testbenches in either Tcl or VHDL. I'm new to vhdl so I have some
> questions:
>
> -Are there inherent simulation speed differences?
>
From http://www.model.com/resources/pdf/modeluser_q4_1999.pdf I
understand that VHDL based TB's will be better for simulation
performance than TCL based ones.
> -Can a Tcl testbench be used with as many simulators as a VHDL tb?
> That is, are Tcl TBs portable?
>
I am afraid not 100%, for instance the portion of your TB that plays
around with your VHDL Signals will require modifications, for instance
in Modelsim to "monitor" a signal you say
when signal1 == 1 (or something like that)
while with NC (as I understood from Steven in this NG) we use
stop -condition ...
> -Is one language more efficient to write testbenches for
> simple/complex entities?
>
Entirely depends on the team/person building the TB, if it is the
same guy as the designer I suggest you stick to VHDL, if you have a
different team/person focussed on TB then consider TCL - but be aware
of the above issues.
HTH,
Srinivasan
g. giachella
Use both !
Write vhdl testbenches, but use Tcl/Tk to create an easy-to-use GUI
interface
whose aim should be :
1) create stimuli files, read by the Vhdl testbench.
Suppose your Unit Under Test has a serial link interface and you want
to stimulate it through a Remote Controller. Write a Vhdl testbench,
with UUT and Remote Controller connected : the Remote Controller vhdl
entity shall be able to read an external stimulus file,containing
packets to be sent via serial link to the UUT.
Packets may consists of header,data or commands, following a rigid
packet format.
An example of such file:
$header 34
$command load_ram_area
$start_address 00000005
--
--
A Tcl/Tk GUI interface could be a good "Packet Editor":
you can use checkboxes to include/exclude the header to your packet
or pressing a "Command A" pushbutton can cause the appearance of the
"Edit Command A related data fields" window, so that you can edit such
data.
The Tcl program should control the consistence of data, in relation to
the sent command, and the correcteness of the entire packet.
Portability is guaranteed,because the Tcl/Tk GUI create an external
text file that you can edit manually, bypassing the GUI interface.
2) monitor the status your UUT: e.g. internal registers.
It is really useful a Tcl/Tk GUI which reads an internal Interrupt
Register,
and associate each bit of this register to its significance,showing a
message in red (informing that interrupt has occurred) whenever that
bit is 1.
Portability is guaranteed. Without the Tcl/Tk GUI, you can do the
same thing, but I'm sure you understand how boring it is.
3) monitor every unit connected to your UUT (you emulate in your
Vhdl testbench) in order to verify the correct behaviour of the UUT :
e.g a RAM.
Suppose the packet is arrived in your UUT and, if processed correctly,
they packet data shold be in an external RAM.
By pressing a pushbutton in a window of the Tcl/Tk GUI you can dump
selected RAM areas, in order to check the presence of such data.
Again, portability is guaranteed. Without the Tcl/Tk GUI, you can do
the same thing, reading the Vhdl variable which represents memory
into the RAM entity.
4) Occasionally force some UUT internal signals: e.g. very slow
counters.
Sometimes it is necessary to force to zero an internal counter,clocked
by a very slow clock, so that you can check a sequence of events
caused
by the counter's Terminal Count signal. Again, a pushbutton placed on
the GUI window can do that whenever you want,even without stopping the
simulation.
Obviously you can do the same,using the correct simulator command.
Tcl/Tk is easy to learn.
Bye