Simulation should be compiled into its own object library. The compilation of the code containing the ‘uselib directives only records which object libraries to search for each module instantiation when the design is loaded by the simulator.
Because the ‘uselib directive is intended to reference source libraries, ModelSim
Verilog must infer the object libraries from the library references. The rule is to assume an object library named work in the directory defined in the library reference dir=<library_directory> or the directory containing the file in the library reference file=<library_file>. The library reference
libext=<file_extension> is ignored. For example, the following ‘uselib directives infer the same object library:
‘uselib dir=/h/vendorA
‘uselib file=/h/vendorA/libcells.v
In both cases ModelSim Verilog assumes that the library source is compiled into the object library /h/vendorA/work.
ModelSim Verilog also extends the ‘uselib directive to explicitly specify the object library with the library reference lib=<library_name>. For example,
‘uselib lib=/h/vendorA/work
The library name can be a complete path to a library, or it can be a logical library name defined with the vmap command. Since this usage of ‘uselib is an extension, it may be desirable to qualify it with an ‘ifdef to make it portable to other Verilog systems. For example,
‘ifdef MODEL_TECH
‘uselib lib=vendorA
‘else
‘uselib dir=/h/vendorA libext=.v
‘endif
The MODEL_TECH macro is automatically defined by the ModelSim compiler.
Simulation
The ModelSim simulator can load and simulate both Verilog and VHDL designs, providing a uniform graphic interface and simulation control commands for debugging and analyzing your designs. The graphic interface and simulator commands are described elsewhere in this manual, while this section focuses specifically on Verilog simulation.
5-74
Verilog Simulation ModelSim EE/SE User’s Manual
Simulation
Invoking the simulator
A Verilog design is ready for simulation after it has been compiled into one or more libraries. The simulator may then be invoked with the names of the top level modules (many designs contain only one top level module). For example, if your top level modules are "testbench" and "globals", then invoke the simulator as follows: vsim testbench globals
If a top-level module name is not specified, VSIM will present the Load Design dialog box from which you can choose one or more top-level modules. See
"Simulating with the graphic interface"
(10-251)
for more information.
After the simulator loads the top level modules, it iteratively loads the instantiated modules and UDPs in the design hierarchy, linking the design together by connecting up the ports and resolving hierarchical references. By default, all modules and UDPs are loaded from the library named work.
On successful loading of the design, the simulation time is set to zero, and you must enter a run command to begin simulation. Commonly, you enter run -all to run until there are no more simulation events or until $finish is executed in the
Verilog code. You may also run for specific time periods, i.e., run 100 ns. Enter the quit command to exit the simulator.
Simulation resolution limit
The simulator internally represents time as a 64-bit integer in units equivalent to the smallest unit of simulation time, also known as the simulation resolution limit.
The resolution limit defaults to the smallest time precision found among all of the
‘timescale compiler directives in the design. The time precision is the second number in the ‘timescale directive. For example, "10 ps" in the following:
‘timescale 1 ns / 10 ps
The time precision should not be unnecessarily small because it will limit the maximum simulation time limit, and it will degrade performance in some cases.
If the design contains no ‘timescale directives, then the resolution limit defaults to the "resolution" value specified in the modelsim.ini file (default is 1 ns). In any case, you may override the default resolution limit by specifying the -t option on the command line.
For example, to explicitly choose 100 ps resolution: vsim -t 100ps top
ModelSim EE/SE User’s Manual Verilog Simulation
5-75
Simulation
This forces 100 ps resolution even if the design contains smaller time precisions.
As a result, time values with finer precision are rounded to the nearest 100 ps.
Event order issues
The Verilog language is defined such that the simulator is not required to execute simultaneous events in any particular order. Unfortunately, some models are inadvertently written to rely on a particular event order, and these models may behave differently when ported to another Verilog simulator. A model with event order dependencies is ambiguous and should be corrected. For example, the following code is ambiguous: module top; reg r; initial r = 0; initial r = 1; initial #10 $display(r); endmodule
The value displayed for "r" depends on the order that the simulator executes the initial constructs that assign to "r". Conceptually, the initial constructs run concurrently and the simulator is allowed to execute them in any order. ModelSim
Verilog executes the initial constructs in the order they appear in the module, and the value displayed for "r" is "1". Verilog-XL produces the same result, but a simulator that displays "0" is not incorrect because the code is ambiguous.
Since many models have been developed on Verilog-XL, ModelSim Verilog duplicates Verilog-XL event ordering as much as possible to ease the porting of those models to ModelSim Verilog. However, ModelSim Verilog does not match
Verilog-XL event ordering in all cases, and if a model ported to ModelSim Verilog does not behave as expected, then you should suspect that there are event order dependencies.
Tracking down event order dependencies is a tedious task, so ModelSim Verilog aids you with a couple of compiler options:
-compat
This option turns off optimizations that result in different event ordering than
Verilog-XL. ModelSim Verilog generally duplicates Verilog-XL event ordering, but there are caseswhere it is inefficient to do so. Using this option does not help you find the event order dependencies, but it allows you to ignore them. Keep in mind that this option does not account for all event order discrepancies, and that using this option may degrade performance.
5-76
Verilog Simulation ModelSim EE/SE User’s Manual
Simulation
-hazards
This option detects event order hazards involving simultaneous reading and writing of the same register in concurrently executing processes. To enable hazard detection you must invoke
vlog
(CR-199)
with the -hazards option when you compile your source code and you must also invoke
vsim
(CR-208)
with the
-hazards option when you simulate.
The
vsim
command
(CR-208)
detects the following kinds of hazards:
• WRITE/WRITE:
Two processes writing to the same variable at the same time.
• READ/WRITE:
One process reading a variable at the same time it is being written to by another process. VSIM calls this a READ/WRITE hazard if it executed the read first.
• WRITE/READ:
Same as a READ/WRITE hazard except that VSIM executed the write first.
The
vsim
command
(CR-208)
issues an error message when it detects a hazard. The message pinpoints the variable and the two processes involved. You can have the simulator break on the statement where the hazard is detected by setting the break
on assertion level to error.
To enable hazard detection you must invoke
vlog
(CR-199)
with the -hazards option when you compile your source code and you must also invoke
vsim
(CR-
208)
with the -hazards option when you simulate.
Limitations of hazard detection:
• Reads and writes involving bit and part selects of vectors are not considered for hazard detection. The overhead of tracking the overlap between the bit and part selects is too high.
• A WRITE/WRITE hazard is flagged even if the same value is written by both processes.
• A WRITE/READ or READ/WRITE hazard is flagged even if the write does not modify the variable's value.
• Glitches on nets caused by non-guaranteed event ordering are not detected.
ModelSim EE/SE User’s Manual Verilog Simulation
5-77
Simulation
Verilog-XL compatible simulator options
See
vsim
(CR-208)
for a complete list of simulator options. The options described here are equivalent to Verilog-XL options. Many of these are provided to ease the porting of a design to ModelSim Verilog.
+alt_path_delays
Specify path delays operate in inertial mode by default. In inertial mode, a pending output transition is cancelled before a new output transition is scheduled, and the delay is selected based on the transition from the current value of the net to the new pending value. The result is that an output may have no more than one pending transition at a time, and that pulses narrower than the delay are filtered.
The +alt_path_delays option modifies the inertial mode such that a delay is based on a transition from a pending output value rather than the current value of the net.
This option has no effect in transport mode (see +pulse_e
(5-79)
and +pulse_r
(5-
79)
).
-l <filename>
By default, the simulation log is written to the file "transcript". The -l option allows you to specify an alternate file.
+maxdelays
This option selects the maximum value in min:typ:max expressions. The default is the typical value. This option has no effect if the min:typ:max selection was determined at compile time.
+mindelays
This option selects the minimum value in min:typ:max expressions. The default is the typical value. This option has no effect if the min:typ:max selection was determined at compile time.
+no_notifier
This option disables the toggling of the notifier register argument of the timing check system tasks. By default, the notifier is toggled when there is a timing check violation, and the notifier usually causes a UDP to propagate an X. Therefore, the
+no_notifier option suppresses X propagation on timing violations.
+no_pulse_msg
This option disables the warning message for specify path pulse errors. A path pulse error occurs when a pulse propagated through a path delay falls between the pulse rejection limit and pulse error limits set with the +pulse_r and +pulse_e options. A path pulse error results in a warning message, and the pulse is progagated as an X. The +no_pulse_msg option disables the warning message, but the X is still propagated.
5-78
Verilog Simulation ModelSim EE/SE User’s Manual
Simulation
+no_tchk_msg
This option disables error messages issued by timing check system tasks when timing check violations occur. However, notifier registers are still toggled any may result in the propagation of X’s for timing check violations.
+nosdfwarn
This option disables warning messages during SDF annotation.
+notimingchecks
This option completely disables all timing check system tasks.
+nowarn<mnemonic>
This option disables the class of warning messages specified by <mnemonic>.
This option only disables warning messages accompanied by a mnemonic enclosed in square brackets. For example,
# WARNING: test.v(2): [TFMPC] - Too few port connections.
This warning message can be disabled with the +nowarnTFMPC option.
+pulse_e/<percent>
This option controls how pulses are propagated through specify path delays, where <percent> is a number between 0 and 100 that specifies the error limit as a percentage of the path delay. A pulse greater than or equal to the error limit propagates to the output in transport mode (transport mode allows multiple pending transitions on an output). A pulse less than the error limit and greater than
or equal to the rejection limit (see +pulse_r
(5-79)
) propagates to the output as an
X. If the rejection limit is not specified, then it defaults to the error limit. For example, consider a path delay of 10 along with a +pulse_e/80 option. The error limit is 80% of 10 and the rejection limit defaults to 80% of 10. This results in the propagation of pulses greater than or equal to 8, while all other pulses are filtered.
Note that you can forcespecify path delays to operate in transport mode by using the +pulse_e/0 option.
+pulse_r/<percent>
This option controls how pulses are propagated through specify path delays, where <percent> is a number between 0 and 100 that specifies the rejection limit as a percentage of the path delay. A pulse less than the rejection limit is suppressed
from propagating to the output. If the error limit is not specified (see +pulse_e
(5-
79)
), then it defaults to the rejection limit.
+pulse_e_style_ondetect
This option selects the "on detect" style of propagating pulse errors (see +pulse_e
(5-79)
). A pulse error propagates to the output as an X, and the "on detect" style is to schedule the X immediately, as soon as it has been detected that a pulse error
ModelSim EE/SE User’s Manual Verilog Simulation
5-79
