Testbench question

Hi,
I am working on a VHDL test bench. I have generated a bunch of
procedure such as writeData, readData, generateClocks and so forth. I
threw these into a package file and can call them from my main
testbench. They work fine but I would like to alter how they get
called.

Question 1: When you call a procedure- you need to pass it all of the
arguements and all the signals it needs to change. For example, I have
to do the following for each write

writeData(addressToWrite, dataToWrite, clk, addressBus, dataBus,
validStrobe);

For each transaction. Can I alias that to something short and simple?
Ex.

alias standardWrite = writeData(addressToWrite, dataToWrite, clk,
addressBus, dataBus, validStrobe); (alias not being the VHDL call
obviously)

Question 2: Can I make a file that contains just a bunch of testbench
commands and doesn't include the entire architecture for the testbench?


I have in the past put this stuff in a text file then read it out-
parse it and called the proper commands- but this seems like a complete
waste of time and effort- and is not very scalable. I don't want to
define my own operands and would simply like to stay in VHDL. I would
like to do something like....

tb_uut.vhd

entity tb_uut
end tb_uut;

architecture tb of tb_uut is

comp uut.....

signal .......

begin

uut1: uut......

case something_I_can_control_externally IS
X: loadVHDLFile x.vhd -- where x.vhd has my testbench control
commands.

end;

 

[Mike Treseler]

wpiman@aol.com wrote:

Question 1: When you call a procedure- you need to pass it all of the
arguements and all the signals it needs to change. For example, I have
to do the following for each write
writeData(addressToWrite, dataToWrite, clk, addressBus, dataBus,
validStrobe);
For each transaction. Can I alias that to something short and simple?

You can overload it in scope of the main process like this:
http://groups.google.com/groups?q=vhdl+procedure+UsesPulseGen

Or put all the procedures in the main process like this:
http://home.comcast.net/~mike_treseler/test_uart.vhd

Question 2: Can I make a file that contains just a bunch of testbench
commands and doesn't include the entire architecture for the testbench?

You can, but it is much more work, for no gain.

I have in the past put this stuff in a text file then read it out-
parse it and called the proper commands- but this seems like a complete
waste of time and effort- and is not very scalable.

I agree.

I don't want to
define my own operands and would simply like to stay in VHDL.

I declare procedures to get the same effect:

constant reps : natural := 16;
begin -- process main: Top level loop invokes top procedures.
init;
for i in 1 to reps loop
timed_cycle;
end loop;
for i in 1 to reps loop
handshake_cycle;
end loop;
coda;
end process main; -- that's it


-- Mike Treseler

 

You can overload it in scope of the main process like this:
http://groups.google.com/groups?q=vhdl+procedure+UsesPulseGen

Or put all the procedures in the main process like this:
http://home.comcast.net/~mike_treseler/test_uart.vhd

I see. So basically anything in the package file only knows local
variables/signals which you must pass. I am thinking of using AWK to
insert a bunch of commands into the main testbench file- so if I were
to put all the procedure there rather than my package file- it wouldn't
be that big a deal. Thanks- that was very helpful.

Question 2: Can I make a file that contains just a bunch of testbench
commands and doesn't include the entire architecture for the testbench?

You can, but it is much more work, for no gain.

Can you elaborate a little here- how would I go about this?

The gain I see is this- I have one major testbench file which contains
all the heavily laden typing- like component instantiations and
declarations. I then have separate files which are much smaller and
more readable- like loopbacktest.vhd- which whacks a register and sends
a packet, receives it, and checks it. I could have all the tests, of
which there are dozens, have the component declarations and all- but
then

A. They become not very readable.
B. They become not very scalable- I add a pin to the unit under test-
I have to add it to all 12 files.

The AWK solution I described above
(http://www.stefanvhdl.com/vhdl/html/pre_processing.html) provides a
non-VHDL way to do this.

I have in the past put this stuff in a text file then read it out-
parse it and called the proper commands- but this seems like a complete
waste of time and effort- and is not very scalable.

I agree.

I don't want to
define my own operands and would simply like to stay in VHDL.

I declare procedures to get the same effect:

constant reps : natural := 16;
begin -- process main: Top level loop invokes top procedures.
init;
for i in 1 to reps loop
timed_cycle;
end loop;
for i in 1 to reps loop
handshake_cycle;
end loop;
coda;
end process main; -- that's it


-- Mike Treseler

I think we are saying the same thing. I would rather build a stack of
procedures in VHDL and call them from within VHDL. I have the base
ones working- and am simply building on top of those.

 

[Mike Treseler]

wpiman@aol.com wrote:

You can overload it in scope of the main process like this:
http://groups.google.com/groups?q=vhdl+procedure+UsesPulseGen
Or put all the procedures in the main process like this:
http://home.comcast.net/~mike_treseler/test_uart.vhd

I see. So basically anything in the package file only knows local
variables/signals which you must pass.

You pass the variables, the procedure cooks them
and returns them. You can write a local overload procedure
to map the variables if you prefer a package to
local procedure bodies.

I am thinking of using AWK to
insert a bunch of commands into the main testbench file- so if I were
to put all the procedure there rather than my package file- it wouldn't
be that big a deal.

If you want to take on processing text, I agree
that awk or perl are more appropriate than vhdl.
However with the two pure vhdl solutions that
I referenced, you get the advantage of automatic
makefile generation from emacs vhdl-mode.

Thanks- that was very helpful.

You are welcome.

Question 2: Can I make a file that contains just a bunch of testbench
commands and doesn't include the entire architecture for the testbench?

You can, but it is much more work, for no gain.

Can you elaborate a little here- how would I go about this?

It is quite common for new vhdl testbenchers
to try to write a text script and interpret it using
vhdl textio rather than learning how to use
procedures. I will decline to elaborate because
I don't think this is a good idea.

The gain I see is this- I have one major testbench file which contains
all the heavily laden typing- like component instantiations and
declarations.

If your entities are not black boxes, you
can instance them directly and nuke the component declarations.

-- Mike Treseler

 

[Bill Mills]

Consider how much the pure VHDL solution can do by using different
configurations to instantiate different testbench components. And the
components reuse the same procedures to generate different tests and or
test data. Generics can be used to change test data or parameters.

-- Top level testbench configuration.
configuration loopbacktest_cfg of testbench is
for behave -- testbench architecture
for others : u_tester_component
use entity sim_work.loopback_tester_component(behave)
generic map (
-- Test specific parameters
G_TX_DATA => 7FFF,
G_MAX_RESPONSE_TIME => 500 ns
);
end for;
end for; -- behave
end configuration loopbacktest_cfg ;

 

[Mike Treseler]

Bill Mills wrote:

-- Top level testbench configuration.
configuration loopbacktest_cfg of testbench is
for behave -- testbench architecture
for others : u_tester_component
use entity sim_work.loopback_tester_component(behave)
generic map (
-- Test specific parameters
G_TX_DATA => 7FFF,
G_MAX_RESPONSE_TIME => 500 ns
);
end for;
end for; -- behave
end configuration loopbacktest_cfg ;

Thanks for the configuration example.
It suggests lots of good testbench ideas.

-- Mike Treseler

 

[wpiman@aol.com]

Question 2: Can I make a file that contains just a bunch of testbench
commands and doesn't include the entire architecture for the testbench?
You can, but it is much more work, for no gain.
Can you elaborate a little here- how would I go about this?

It is quite common for new vhdl testbenchers
to try to write a text script and interpret it using
vhdl textio rather than learning how to use
procedures. I will decline to elaborate because
I don't think this is a good idea.

I agree- reading in the files is somewhat hokey. The only advantage I
can see is that you could have some sort of preprocessor write those
text files for you in a more elaborate- random testbench. I guess you
could write a perl script to generate the higher level VHDL as well.

My plan was to have separate files that are all vhdl and invoke my
procedure calls there. We seem to all agree that the best ways seem to
do this awk thing.

If your entities are not black boxes, you
can instance them directly and nuke the component declarations.

Thanks- that should get rid of a couple hundred lines.

If you want to take on processing text, I agree
that awk or perl are more appropriate than vhdl.
However with the two pure vhdl solutions that
I referenced, you get the advantage of automatic
makefile generation from emacs vhdl-mode.

If you are using Xemacs make generation- I believe if simply makes
calls
to 'vmake' if you are using Modelsim- which by your examples it looks
like you are (or at least were). vmake will generate a makefile for
you based off what is in your work directory. You can specify other
libraries as well.

Thanks again,

PS.
I think I miss VERA from my last job

 

[Mike Treseler]

wpiman@aol.com wrote:

My plan was to have separate files that are all vhdl and invoke my
procedure calls there. We seem to all agree that the best ways seem to
do this awk thing.

Actually, I prefer to *not* automate any text editing.

If you are using Xemacs make generation- I believe if simply makes
calls to 'vmake' if you are using Modelsim- which by your examples it looks
like you are (or at least were). vmake will generate a makefile for
you based off what is in your work directory.

That is incorrect. vhdl-mode generates a project
Makefile for use by *make*, not vmake.
Nothing is required to be precompiled.

In fact, I can say:

make clean; make

To specifically clear the work directory first.

Thanks again,

You are welcome.

-- Mike Treseler

 

[wpiman@aol.com]

If you are using Xemacs make generation- I believe if simply makes
calls to 'vmake' if you are using Modelsim- which by your examples it looks
like you are (or at least were). vmake will generate a makefile for
you based off what is in your work directory.

That is incorrect. vhdl-mode generates a project
Makefile for use by *make*, not vmake.
Nothing is required to be precompiled.

In fact, I can say:

make clean; make

To specifically clear the work directory first.

Modelsim's vmake generates a standard makefile and is executed in
exactly the same way you described.
(make clean; make)

I have actually found it to be somewhat error prone in that it does not
figure out the order of file dependancies properly. To start off- make
had to be run several times as dependant files got compiled first even
though they were originally compiled in the correct order. Perhaps it
was user error- I didn't spend too much time as the workaround was so
simple.

I will have check out Xemacs again in this area as I did use this
feature of it (use it infrequently- prefer gvim) of it in the past for
makefile generation.

 

[Mike Treseler]

wpiman@aol.com wrote:

Modelsim's vmake generates a standard makefile and is executed in
exactly the same way you described.
(make clean; make)

True, once you somehow get everything compiled
in ./work manually once. For a complex project
with daily changes, this is a nonstarter.

I have actually found it to be somewhat error prone in that it does not
figure out the order of file dependancies properly. To start off- make
had to be run several times as dependant files got compiled first even
though they were originally compiled in the correct order.

You have discovered the chicken-egg problem
described above.

I will have check out Xemacs again in this area as I did use this
feature of it (use it infrequently- prefer gvim) of it in the past for
makefile generation.

vhdl-mode is a separate download
http://opensource.ethz.ch/emacs/vhdl-mode.html

good luck.

-- Mike Treseler