Functional testbenches 
Author Message
 Functional testbenches



Quote:
>Well, that's the way I do it.  I'd be interested in hearing how others
>approach the problem.
>                      |                            - Douglas Adams

Hello there,

The way I build test benches is this:

I write a process which implements all the textbenchs' actions.
An action would be something like "write_burst", "read_burst" etc.

-- -----------------------------------------------------------------------

Testmuster_VL_process: process

variable test:          test_type;
variable counter:       integer := 0;

begin

test.counter := counter;

test := testprogramm(test);

-- action "write burst"

  if test.command = write_burst then
        ADSn <= '0'; M_IOn <= '0'; WR <= '0';
        ADD <= To_StdULogicVector(itobv(test.address,address_length));
        wait until CLK = '1';
        for word in 0 to test.test_loops-1 loop
                data <= To_StdULogicVector(itobv(test.write_data(word),
                                                 databus_width));
                wait until CLK = '1';
                .
                .
                .
  end if;

-- action "read burst"

        .
        .
        .

counter := counter + 1;

end process;

-- -----------------------------------------------------------------------

The value of the data structure "test" is determined in a function
which contains the test program.

function testprogramm(test: in test_type)
        return test_type is

        variable result:        test_typ;

        begin
                case test.counter is
                  when 1 =>
                        result.command          := Burst_Schreiben;
                        result.address          := 1000;
                        result.test_loops       := 8;
                        for i in 0 to result.test_loops-1 loop
                                result.write_data(i)    := i;
                        end loop;
                  when 2 =>
                        .
                        .
                        .
                  when others =>
                        result.command          := end_test;
                end case;
   return result;

end testprogramm;

With this technique I can write high level test programs, the standard
file based methods look more like assembler, I think. Unfortunately the program
contains now line numbers *shudder* and it's necessary to recompile the
testbench in order to change the test program.
It's easy though to add another case-construct around the existing one in the
function. That construct can evaluate a generic constant (e.g. test_number)
which can be choosen by a configuration statement. With several configurations
Synopsys (this will probably apply to other tools as well) will then allow to
select a testprogram by clicking on one of the configurations (neat!).

configuration Test4 of TESTBENCH is
   for SCHEMATIC
        for TESTPATTERNS_component:TESTPATTERNS
                use entity work.TESTPATTERNS(behaviour)
                     Generic Map
                        (
                        testprog        =>  4, -- selecting a test program
                        cycle           =>  20 ns,
                        .
                        .
                        .
                        );
        end for;
   end for;
end Test4;

configuration Test5 of TESTBENCH is
                        .
                        testprog        =>  5,
                        .
                        .

Furthermore it's possible to control several several test processes with one
test program. Each process must then pass it's ID to the function which returns
the appropriate test commands. Thus different sources of test patterns can
be controlled in one test program easily.

I apologize for the length of the posting and would appreciate any comments on
the method. (Any ideas how to get rid of the line numbers?)

Cheers

Stefan



Wed, 12 Mar 1997 08:41:51 GMT  
 Functional testbenches


Quote:
>Over the years, I've developed a certain set of techniques for
>developing testbenches.  But when I read articles and papers on
>testbenches, it seems that I'm the only person that does things this
>way.  I was wondering if this is really true, and (regardless) I'd
>like to discuss the pros and cons of different techniques.
>So my "test vectors", rather than specifying signal states and clock
>edges, look more like this:

>    cpu r 10080 ns 00080404 ---0000a
>which tells the cpu model in the testbench to do a read transaction,
>starting at time 10080 ns, to location 00080404, and expect to get
>back a 0000a (with the upper 12 bits being "don't care").  Similarly,
>I could command the testbench's serial link to send a word to the
>device with a line like:
>    ser w 100 us 5555ffff
>All of the components in my testbench read their commands from a file
>(whose name is passed in as a generic), and look only for commands
>beginning with a certain string, such as "cpu" (this is also passed in
>as a generic - this allows me to use one file for all of the stimulus,
>or split it up, depending on the situation).
>Well, that's the way I do it.  I'd be interested in hearing how others
>approach the problem.

Janick Bergeron and I cowrote a paper titled "Interactive Models and
Testbenches in VHDL", presented at the spring 1993 VIUF, held in
Ottawa, Ontario.  In there, we discuss the methods we used to create
testbenches that we could interact with text, instead of 1's and 0's,
similar to what you describe above.

We presented two examples, one employing a CSMA-CD protocol to
communicate among a number of processors, and another discussing
interactions with a monitor in a model of the 56156 processor.

We also discussed an automatic parser generator that we wrote that
"[reduces] the time required to generate the parser from over a week
to minutes."

The paper can be found in the proceedings of the Spring 1993 VIUF,
pages 59-66.
--
------------------Above opinions are my own---------------------------
Hemi Thaker     Bell-Northern Research, Ltd        Ph.: (613) 765-2863
Fiber Systems   P.O. Box 3511, Station C           Fax: (613) 763-2714



Fri, 14 Mar 1997 23:49:50 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Testbench Design (using multiple testcases with one testbench)

2. functional.py 0.6 - Functional Programming in Python

3. non-functional syntax in a mostly functional language

4. functional.py 0.7 - Functional programming in Python

5. functional.py - functional programming in Python

6. functional.py 0.7 - Functional programming in Python

7. functional.py 0.6 - Functional Programming in Python

8. functional.py - functional programming in Python

9. Verilog testbench

10. Vector File and Testbench File

11. Writing Testbenches: Function Verification of HDL Models

12. slef-checking testbench

 

 
Powered by phpBB® Forum Software