for 6.111 Introduction to Digital Systems
Simulating with ModelSimby Nathan Ickes, Daniel Finchelstein, and Nathan Ackerman
The design of complex digital systems invariably requires extensive simulation, both of the individual submodules that make up the system, and of the system as a whole. This document describes how to setup and run Verilog simulations, using Project Navigator and ModelSim.
Simulations are controlled using testbenches. A testbench is an additional Verilog module (not part of the actual system design) used to generate the appropriate waveforms on the input ports of the module under test, in order to exercise the functionality of that module. Optionally, the testbench also monitors the outputs of the module under test, and generates warnings if they deviate from the expected output values. (If the testbench does not monitor the modules output, proper operation of the module under test must be verified by manual observation of the simulated output waveforms.)
Setting up the Tutorial Project
The example code for this tutorial is a very simple finite-state machine. To setup the project for this tutorial, launch Project Navigator and create a new project (targeting the labkit's XC2V6000-4BF957 FPGA). Make sure ModelSim-SE Verilog is selected as simulator in the project properties form.
Add the following source files to the project:
The project source tree should look like this:
Synthesize and implement the project now, just to verify that everything is set up properly. (Don't forget to check the "Allow unmatched LOC constraints" checkbox, in the "Implement Design" properties.)
Adding a Testbench to the Project
It may be easiest to write your testbenches from scratch. However, if you wish, Project Navigator can automatically generate a skeletal testbench for any module in your design. The skeletal testbench includes code to instantiate the module under test, and to initialize the input signals to the module. You must extend the testbench in order to generate the stimulus waveforms necessary to test your module.
Click "Next", and then "Next" again, acknowledging
Finally, click "Finish". ISE will generate a basic testbench which instantiates the
Now that you know how to create your own testbenches, download the finished testbench for the
If you auto-generated a testbench, as described above, delete it from the project now. Add the
Project Navigator will identify that
ISE includes an interface for launching ModelSim from within Project Navigator. To use this interface, ModelSim must be selected as the default simulator for the current project. (To check or change the default simulator, right-click on the "xc2v6000-4bf957" item in the project source tree and select "Properties...".)
If a testbench file is selected in the source tree, the following processes become available in the process window:
Double-clicking any of these simulation tasks will launch ModelSim and run a simulation using the selected testbench. (Note that each time you run one of these simulation tasks, a new copy of ModelSim is started. Since there are only a limited number of ModelSim licenses available for the class, please try to avoid running multiple copies of ModelSim at the same time.)
A behavioral simulation uses the Verilog source code you wrote in order to model the behavior of the module under test. Neither gate delays nor interconnect delays are modeled. Furthermore, functionality of the behavioral model may not match that of the synthesized logic, if you make use of Verilog language features that the synthesis engine cannot handle. (In particular, be careful about incomplete sensitivity lists.)
While behavioral simulation gives the least accurate prediction of how the final hardware implementation will perform, it is the most useful form of simulation during the initial debugging of a design. There is little point in running more realistic simulations until the behavioral model works correctly.
Behavioral simulation results for the example FSM
Non-behavioral simulations are performed on some form of synthesized netlist. To simulate synthesized netlists of the fsm module, you need to fully synthesize the fsm module. You will need to set fsm as the top module first by right clicking on fsm1.
Generating synthesized fsm modules.
A post-translation simulation uses the synthesized gate-level netlist to model the module under test. The functionality of the gates is modeled using a generic Xilinx library, but propagation delay is not modeled. The simulation should match the behavior of the actual hardware, but will assume the hardware is infinitely fast. (If you are worried about whether your design has synthesized correctly, start by checking the synthesis report file, as all common synthesis mismatch issues will generate warnings in the report file.)
In a post-mapping simulation, the gates have been mapped to a library specific to the FPGA device being targeted. This library includes accurate gate delay information. However, interconnect delay is not modeled, because the design at this stage has not yet been placed and routed.
Post-Mapping simulation results. Note the clock-to-
A post-place-and-route simulation models interconnect delay, as well as gate delay. This type of simulation will most accurately match the behavior of the actual hardware. However, for large designs, it can take a significant amount of time to extract the interconnect delay values from the place-and-route information, and a significant amount of time to run the actual simulation.
It really only makes sense to perform post-place-and-route simulations at the top level of a design. If you perform a post-place-and-route simulation on a submodule, the place-and-route process is rerun, using the submodule as the top-level of the design. The interconnect delays for the submodule simulation will therefor not match the interconnect delays for that submodule when it is laid out as part of the complete project.
Post-Place-and-Route simulation results. The total clock-to-
Solutions to Common Problems
MIT 6.111 Introduction to Digital Systems, Updated February 04, 2007