ISE
Test Benches
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.
See Also

© Copyright 1995–2009, Xilinx® Inc. All rights reserved.