From: Adam Krolnik (adamk@cyrix.com)
Date: Mon May 25 1998 - 21:45:06 PDT
Behavioral Task Force - Errata Submission
Assigned Errata Number: BE72
Errata Name (Description): Section 5.5 "Race conditions"
Section: 5.5
Date Submitted: 970929
Requestor: Daryl Stewart
Status: Submitted (priority not yet assigned)
Errors found in the Verilog LRM (IEEE 1364-1995).
Details:
From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk>
module EXP_143;
reg q;
// comment out only one of the following two lines:
wire p; assign p=q;
// wire p=q;
initial begin
#1 $display("1st simulation cycle: q",q," p",p);
#0 $display("2nd simulation cycle: q",q," p",p);
end // initial #1
initial begin // this code based on that on p5-4, Oct P1364
q=1;
#1 q=0;
$display("1st: q",q," p",p);
#0 $display("2nd: q",q," p",p);
end // initial begin
initial begin
#1 $display("1st simulation cycle: q",q," p",p);
#0 $display("2nd simulation cycle: q",q," p",p);
end // initial begin
endmodule // EXP_143
With wire p=q; only commented out
$verilog -q experiment.143.cv
1st simulation cycle: q1 p1
1st: q0 p1
1st simulation cycle: q0 p1
2nd simulation cycle: q0 p1 (p is still 1)
2nd: q0 p0
2nd simulation cycle: q0 p0
The example code in section 5.5 "Race conditions" is at fault.
It states that the display immediately following the q=0
assignment could show p as either 1 or 0.
This code shows that in fact, p does not become 0 until
partway through the 2nd simulation cycle in the same timestep,
hence it is impossible for the first display to see p=0.
This is because of the implicit #0 net delay.
With wire p; assign p=q; only commented out
$verilog -q experiment.143.cv
1st simulation cycle: q1 p1
1st: q0 p0
1st simulation cycle: q0 p0 (p is already 0)
2nd simulation cycle: q0 p0
2nd: q0 p0
2nd simulation cycle: q0 p0
Here, without the implicit #0 net delay, p becomes 0
within the 1st simulation cycle.
------------------------------------------------------
Addition of VCS 4.0.3 results
w/ assign (first case above, + implies different)
Compiler version 4.0.3; Runtime version 4.0.3; May 26 10:19 1998
1st simulation cycle: q1 p1
+1st: q0 p0
+Another 1st simulation cycle: q0 p0
+2nd simulation cycle: q0 p0
2nd: q0 p0
Another 2nd simulation cycle: q0 p0
w/ wire (second case)
Compiler version 4.0.3; Runtime version 4.0.3; May 26 10:23 1998
1st simulation cycle: q1 p1
1st: q0 p0
Another 1st simulation cycle: q0 p0
2nd simulation cycle: q0 p0
2nd: q0 p0
Another 2nd simulation cycle: q0 p0
VCS takes the latter half of the statement " or execute the update for p,
followed by the $display task." XL seems to follow the first part of the
statement, "The simulator may either continue and execute the $display task"
but as Daryl points out, they execute much more before processing the active
update event for 'p'. It seems that at the point the update event for 'p'
is scheduled, there are 4 '#0' events queued. The simulator IS free
to execute them in any order and that is what XL appears to be doing.
While this may not seem straightforward (to reorder execution of statements
queued with the same time delay) it is legal.
Recommend no actions be taken for this erratta.
<p> Adam Krolnik
Verification Engineer
Cyrix - NSM.
Richardson TX. 75085
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:53 PDT
and
sponsored by Boyd Technology, Inc.