From: Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk)
Date: Thu May 28 1998 - 10:14:33 PDT
BAD MSG:
Hi!
-Lines: 155
Content-Type: text/plain; charset="us-ascii"
Content-Length: 4926
X-Status: $$$$
X-UID: 0000000493
Status: RO
Not meaning to bore everyone with this one ;) but...
My point was more to do with the behaviour of
wire p; assign p=q;
vs.
wire p=q;
and the specific example on p5-4, rather than refuting the possiblility of
race hazards and a simulator's freedom to reorder execution of statements
queued with the same time delay.
I don't think that XL is simply choosing an inconvenient ordering for the
execution of #0 delayed actions.
I was trying to show that with
wire p; assign p=q;
there is an implicit #0 delay on signals, so the $display which follows
immediately after "q=0" is scheduled too soon to see the 0 appear at p, since
the 0 is scheduled for after a delay (#0) and the display is not.
The text at the top of page 5-4 would agree with XL if the word "wire" is
substituted for "assign".
It seems to me that VCS is treating wire p; assign p=q; as declaring a net
with (absolutely) no delay between p and q. This depends on your reading of
paragraph 2 of section 7.15 - is the default net delay zero as in #0 or zero
as in (absolutely) nothing. XL chooses the former, VCS the latter.
Section 6.1.3 is also worth reading alongside this...
I haven't managed to keep a well annotated version of my draft P1364, so I
apologise if I quote from modified sections!
cheers
Daryl
http://www.cl.cam.ac.uk/users/djs1002/verilog.project/
>
>
> 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.
>
>
> Adam Krolnik
> Verification Engineer
> Cyrix - NSM.
> Richardson TX. 75085
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:54 PDT
and
sponsored by Boyd Technology, Inc.