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 cases where 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.

-hazards

This option detects event order hazards involving simultaneous reading and writing of the same register in concurrently executing processes.

vsim 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. ModelSim calls this a READ/WRITE hazard if it executed the read first.
• WRITE/READ:
  Same as a READ/WRITE hazard except that ModelSim executed the write first.

vsim 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 with the -hazards option when you compile your source code and you must also invoke vsim 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.

Model Technology Incorporated Voice: (503) 641-1340 Fax: (503)526-5410 www.model.com sales@model.com