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
Note Verilog designers sometimes refer to a Verilog test fixture. "Test bench" and "test fixture" are used
synonymously throughout this documentation.
You can create the test bench using either of the following methods:
- Text editor
This is the recommended method for verifying
complex designs. It allows you to use all the features available in
the HDL language and gives you flexibility in verifying the design.
Although this method may be more challenging in that you must create
the code, the advantage is that it may produce more precise and accurate
results than using the Test Bench Waveform Editor.
in creating the test bench, you can create a template that lays out
the initial framework, including the instantiation of the UUT and
the initializing stimulus for your design. Create this template
as described in Creating
a Source File
, selecting VHDL Test Bench
or Verilog Test Fixture
as your source type.
You can also use the Language Templates
to create the VHDL or Verilog code for both the test bench and the
design. See Working
with Language Templates
- Xilinx® Test Bench Waveform Editor
This is the recommended
method for verifying less complicated simulation tasks and is recommended
if you are new to HDL simulation. It allows you to graphically enter
the test bench to drive the stimulus to your design. For detailed
information, see the ISim Help
. You can also create a self-checking test
bench. For details, see Generating a Self-Checking Test Bench
The Test Bench
Waveform Editor flow is being considered for deprecation in this release.
If you use this tool and do not want to see it deprecated, please
send feedback through the mechanism in the software.
To learn more, see the ISim Help
Test Bench Strategies
Because the test
bench becomes a part of the hierarchy in your code, the following
- Make the test bench the top level of the code.
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.
For non-timing simulation, 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 data
just before the next clock cycle.
For timing simulation, it
could take up to an entire clock cycle for the data to propagate through
the logic and settle to a known value. Checking data too early in
the clock cycle may yield incorrect results.