( ESNUG 428 Item 9 ) -------------------------------------------- [04/28/04]
Subject: ( ESNUG 424 #5 ) Glitches, Race Conditions, VCS and Verilog-XL
> I want to test if a zero width glitch in Verilog can cause VCS to hang
> or lock in infinite loop. Here's my simple Verilog source file used
> for the test:
>
>
> 1: // zero width glitch to test if VCS will hang
> 2:
> 3: module test;
> 4: reg [3:0] a;
> 5: reg [3:0] b;
> 6:
> 7: initial
> 8: begin
> 9: a = 0;
> 10: b = 0;
> 11: #10;
> 12: a=5;
> 13: b=10;
> 14: #10;
> 15: $display("Reached End.");
> 16: $finish;
> 17: end
> 18:
> 19: always @(a)
> 20: begin
> 21: b=10;
> 22: $display("Changing always block B");
> 23: b=0;
> 24: end
> 25:
> 26: always @(b)
> 27: begin
> 28: a=5;
> 29: a=0;
> 30: end
> 31: endmodule
>
>
> To my surprise I couldn't get VCS to hang, with or without +delay_trigger
> option. I tested versions 6.0* and 7.0*.
>
> For comparison, my Verilog-XL sim doesn't hang with +delay_trigger, but
> hangs without it. I suppose such behavior is IEEE 1364 compliant, but
> I could be wrong.
>
> Unsure why the difference between VCS and Verilog-XL, I would like to ask
> the ESNUG community for any insight.
>
> - Ken Wong
> Conexant Systems, Inc. San Diego, CA
From: Joe Larabell <larabell=user domain=synopsys.co.jp>
Hi, John,
VCS has never had a +delay_trigger option. This example is actually a race
condition (a race between the retriggering of one always block and the
propagation of the value change from another block as a result of assigns
inside that first always block.)
In order to get speedups, VCS tends to propagate assigns immediately in
order to avoid queueing and de-queueing overhead. Thus, when the initial
block assigns a value to 'a' on line 9, the 'always @(a)' block is
triggered and executed immediately. This causes the assign to 'b' on line
21 to be executed and the 'always @(b) block to be triggered. When the
assign to 'a' on line 28 is executed, the value is propagated immediately
but the 'always @(a)' block is not retriggered because it's not listening
(see [1] below). By the time the 'always @(a)' block has completed (and
wrapped back around to the '@(a)' event trigger), the changes on signal
'b' should have already been propagated and thus no oscillation occurs.
Another more common occurance of this race happens when a register
assigned by an always block drives an assign statement whose left-hand
side is a signal to which that same block is sensitive. In that case,
there is no infinite loop -- but the behavior of VCS could be different
from other simulators.
[1] As an aside, you may recall that, in Verilog, the sequence:
always @(a)
begin
<statements>
end
is exactly the same as:
always
begin
@(a);
<statements>
end
That is, the '@(a)' only has meaning when the execution of the block
has actually reached that trigger and is armed and waiting for the
signal in question to change. During the time the other statements
in the block are executing, the '@(a)' has no effect.
When race conditions occur in the design, the result can be unpredictable.
For example, if you were to change your blocks to:
always @(a)
begin
b=~b;
$display("Changing always block B");
end
always @(b)
begin
a=~a;
end
then VCS would indeed enter an infinite loop.
As w/ most race conditions, both behaviors are "IEEE compliant". According
to section 5.4.2 of IEEE 1364-2001:
"At any time while evaluating a behavioral statement, the simulator may
suspend execution and place the partially completed event as a pending
active event on the event queue. The effect of this is to allow the
interleaving of process execution. Note that the order of interleaved
execution is nondeterministic and not under control of the user."
So, when any IEEE-compliant simulator reaches the assign statement at line
21, for example, it has the choice of continuing to execute statements
from the same always block or to suspend that always block and propagate
the change on 'b' and execute whatever blocks may be sensitive to that
signal. It's this kind of event reduction that makes VCS faster than XL.
- Joe Larabell
Synopsys Japan
|
