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

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