Need help on Automatic self checking testbench

[Sreenivas J]

Hi all,

I am working on self checking automated test bench. Here i have
testbench having each step implemented in VHDL which includes
processor READ and WRITE actions developed in package and calling into
testbench.

Example:

Step_no<=1;
por_n<='0';
wait for 100 ns;
por_n<='1';
wait for 100 ns;

Step_no<2;
WRITE(<Address>, <Data_val_32bit>; <related signals: clocks, ...etc);

Step_no<=3;
READ(<Address>);


My intension is to create Automated testbench golden reference file
which can read all the step's expected results from the main testbench
and compare with the actual results with step number reference.

At some extent i tried to create a model using VHDL TEXT IO's but i am
getting difficulties at READ and WRITE actions.

Please suggest me some good process to follow,...that will be a gr8
help.

Thanks,
Nivas.

 

[KJ]

My intension is to create Automated testbench golden reference file
which can read all the step's expected results from the main testbench
and compare with the actual results with step number reference.

I find it more productive to create a VHDL model of the system under
test rather than reading expected results from a file. Add assertion
checking at will to check everything that needs checking.

At some extent i tried to create a model using VHDL TEXT IO's but i am
getting difficulties at READ and WRITE actions.

Unless you can explain "getting difficulties", it will be difficult
for anyone to help.

Please suggest me some good process to follow,...that will be a gr8
help.

1. Ask yourself how you are going to generate the expected results
2. Ask yourself if it wouldn't be easier to encode the process of #1
within your testbench in the first place and skip reading/writing
files

Kevin Jennings

 

[Andy]

Hint: Read() could take an argument (default to others => '-'). with
which to compare the results, and then it could report failures. Read
could also have an output parameter to allow collecting the read data
and analyzing as a whole after all the data is received.

Andy

 

[Sreenivas J]

I find it more productive to create a VHDL model of the system under
test rather than reading expected results from a file.  Add assertion
checking at will to check everything that needs checking.


Unless you can explain "getting difficulties", it will be difficult
for anyone to help.


1. Ask yourself how you are going to generate the expected results
2. Ask yourself if it wouldn't be easier to encode the process of #1
within your testbench in the first place and skip reading/writing
files

Kevin Jennings

Hi kevin,
Thanks for your response.
The aim of this is when we run for simulation we can see the responses
in waveform file from Modelsim,
so those responses or exptected results i have to capture in a text
file and compare with actual results.

reg,
Nivas

 

[Alessandro Basili]

The aim of this is when we run for simulation we can see the responses
in waveform file from Modelsim,
so those responses or exptected results i have to capture in a text
file and compare with actual results.

I had this idea in mind long time ago, thinking it would be a *great*
(not gr8) way to test any dut, providing input patterns from a file and
comparing output patterns with my "expected results" neatly stored in
another file.
Then I realize the file needed a format (wow!) and the procedure to read
the file would have needed a way to check the format for typos (ouch!).
Then I realized that I needed more than just a series of values to check
since the logic would have processed the data after some time, so I
would have needed to synchronize the reading of the next value with the
logic...
In no longer than a couple of days I realized I was writing a scripting
language and the result was far away from what I wanted. The file
approach was more of a burden rather than a help.

In my mind you need to:

1. identify first the interfaces to your dut (serial/parallel
communication, hand-shake protocol, bus interface), all the means that
give you a handle on the dut.
2. write procedures to communicate with the dut (read/write)
3. identify all the output of the dut (data streams, serial/parallel
interfaces, etc.), all the means that make you "see" what the dut is doing.
4. write procedure to sample the output and evaluate the result.

Now you have a way to stimulate your dut with several operations and
check the results.
Use as much as possible existing models in your testbench, so if you
have a spi interface try to find an existing implementation and use it.

Just bear in mind that when your design is implemented you will only
have inputs and outputs on your board, nothing else.
If a state of the design cannot produce a transition on any output it
means the state is not "observable" and you will spend the rest of your
life trying to figure out what is your logic doing.
If a state of the design cannot be forced through a series of inputs it
means that state is not "controllable" and most probably you will not be
able to perform what you wanted.

reg,

what is reg? is it a register? if it stands for "regards" why not
writing so? are you afraid to use the bandwidth of your internet
connection efficiently? In this last case I spoiled your intent I
believe ;-)

 

[BeesNotIncluded]

I have to agree with Alessandro:

On 2/28/2011 9:22 PM, Sreenivas J wrote:

I had this idea in mind long time ago....

In no longer than a couple of days I realized I was writing a scripting
language ...

Ultimately, every DUT has different requirements on the type, timing, sequence and number of input and output signals. Hoping to write a generic test bench to cover all these cases is no small undertaking.

While it is not possible to reliably auto-generate the test bench, it is possible to save a considerable amount of time and typing by using a script to automatically generate a template test bench file containing:

1. All the DUT port signal definitions
2. The instantiated DUT
3. The port mappings between test bench and DUT

I am currently working on such a project and have a perl script mostly written to do this. You might like to check it out and see if you could use such a script or something similar to achieve savings in the time taken to prepare test benches.

If you are interested you can read more here:

http://www.beesnotincluded.com/2012/03/automating-vhdl-testbench-creation.html