To simulate your design,
you need both the design under test (DUT) or unit under test (UUT)
and the stimulus provided by the test bench. A test bench is
HDL code that allows you to provide a documented, repeatable set of
stimuli that is portable across different simulators. A test bench
can be as simple as a file with clock and input data or a more complicated
file that includes error checking, file input and output, and conditional
testing.
Note Verilog designers sometimes refer to a Verilog test
fixture. "Test bench" and "test fixture" are used synonymously throughout
this documentation.
Test Bench Strategies
Because the test bench
becomes a part of the hierarchy in your code, the following is recommended:
- Ensure that the test bench is associated with a Simulation
Design View in Project Navigator.
When you
add a test bench to the project, you must ensure
that the associated Design View is set to a Simulation view, as described
in Using the Design
Views. For simulation source files, Project Navigator automatically
selects the Design View association based on the file name. Project Navigator uses a predefined set
of patterns to determine whether the file is a Simulation source file
and whether the file is a test bench. These patterns are defined in
the data file $Xilinx/data/projnav/xil_tb_patterns.txt. If the source file name matches any of these regular expression
patterns, the Design View association is automatically set to a Simulation
view when you add a file to the project. After the file is added to the project, you can change the default
association in the Source Properties dialog box, as described in Changing
Source Properties. Note To modify
the list of patterns that Project Navigator uses to detect test bench source
files, you can edit the $Xilinx/data/projnav/xil_tb_patterns.txt data file. You can either edit the file in the installation location,
or you can create a copy of the file and place it in the project directory.
The file in the project directory overrides the file in the installation
area.
- Make the test bench the top level of the code.
The test
bench instantiates the unit under test (UUT), and stimulus is applied
from the top-level test bench to the lower-level design or portion
of the design being tested.
- Use the instance name UUT for the instantiated unit under test.
This is the default instance name that Project Navigator expects.
You can use the same test bench for both functional and timing
simulation. Following are general recommendations that apply to both
types of simulation:
- Initialize all input ports at simulation time zero, but do not drive expected stimulus until after 100 nanoseconds (ns) simulation time.
During timing simulation,
a global set/reset signal is automatically pulsed for the first 100
ns of simulation. To keep the test bench consistent for both timing
and functional simulation, it is recommended that you hold off input
stimulus until the global set/reset has completed.
Note You can
still run the clocks during the first 100 ns of simulation.
- Do not provide data to the input ports
at the same time as the clock.
This can cause some signals to
be applied before the clock and some after the clock. Apply data
only after the clock is applied to the input
ports. This makes it easier to keep track of which clock edge data
changes are being applied.
- If output checking is performed in the test bench, apply the
check in accordance with the output timing of the design.
If
you specify an OFFSET OUT AFTER of 5 ns, specify the check 5 ns after
the associated clock edge. This allows checking of both functionality
and timing when performing a timing simulation using this test bench.
Checking the value too early may give false errors, and checking too
late may not ensure that proper output timing is met.