VHDL Programming

CPU: RTL Simulation 345

--- vector file for counter

-- time ld up_dwn clk_en din

10 001 0

20 101 50

30 001 0

100 101 0

110 001 0

250 101 35

260 001 0

If this example were a full testbench, the vector file would not be shorter

because a vector would be needed on each clock transition to specify the

output results for comparison.

The advantage of the hybrid testbench is that less data needs to be read

from a vector file. Stimulus data is instead provided by either simulator

command language commands or generated in the testbench.

The disadvantage of the hybrid testbench is that it is more difficult to

change data from run to run when the hybrid testbench generates the

stimulus in the testbench. In the case where simulator command language

commands are used to generate stimulus, the testbench is less portable.

Fast Testbench

All of the testbench styles discussed so far have one common trait: They can

become the limiting factor in how fast a simulation can run. This is especially

true of the testbenches that read data from vector files. These files can become

very large, and the time it takes to read a vector and process the vector can

be the limiting factor in how fast the simulator executes. The same can be true

of the simulator-specific testbench if the simulator does not read the entire

command file in at the start of simulation. If the file is read in chunks, the

file readoperation can significantly slow the simulation.

To get around these problems, a designer can elect to use a fast test-

bench. The fast testbench is optimized for speed and typically does not

limit the speed of the simulation, unless the design is very small.

Following is an example fast testbench:

ENTITY testbench IS END;

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

-- FAST Testbench

-- testbench for 8-bit loadable updown counter

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

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;