( ESNUG 301 Item 9 ) --------------------------------------------- [10/15/98]
Subject: Race Conditions That Cause VCS To Differ From Cadence Verilog-XL
> OK, I don't think anyone has addressed the concerns of our original
> posting, so I'm going to restate the questions. If you have responses
> based on the details of the IEEE spec, those would be more helpful than
> other responses. BTW, FWIW, one of the posters has been using Verilog
> successfully since 1989; the other since 1994. I'm not trying to say I'm
> a Verilog expert, but I *thought* I understood how to reliably model
> hardware using Verilog. Also, *lots* of designers/verifiers I've talked
> to think this is a VCS bug (I'm not sure at this point).
>
> First, the (abstracted) code that produced the original problem:
>
> assign a = (b!=0);
>
> always @(a or d)
> begin
> if (a)
> c = d;
> else
> c = ~d;
> b = d + 1;
> ...... // Zero or more statements
> end
>
> I made "a" a wire to get rid of a stupid warning from Verilint, a warning
> I will turn off in the future. I generally expect to inline the
> computation of "a" in these cases in the future, as some have suggested.
>
> Having said that, I expected the code to work. Why? Because I expected
> the always block to fire twice, once to update "c" and "b" (because of "d"
> changing), and again to update "c" (because of "a" changing, since "b"
> changed). When I saw VCS *not* refire the always block a couple of weeks
> ago, it was the first time I had to consider abandoning/restricting my
> coding style since I started using Verilog; the above general style has
> always worked.
>
> - John Andrews
> Silicon Graphics Mountain View, CA
From: Ramesh Narayanaswamy <nramesh@ganesh-systems.com>
Strictly going by what is listed here there is a scenario where the
always block will fire only once:
1. 'b' starts as X, so 'a' would go from X to 1
2. the always block fires because 'a' changed
3. 'b' would go from X to a "non zero" value due to "d + 1"
4. the continuous assignment fires because 'b' changed
5. 'a' does not change because ' "non zero" != 0 ' is still 1.
perhaps i am missing other context from your earlier posts ?
- Ramesh Narayanaswamy
Ganesh Systems
---- ---- ---- ---- ---- ---- ----
From: jandrews@windsurfer.engr.sgi.com (John Andrews)
Yea, I should have said I expect the block to fire twice if 'a' changes.
- John Andrews
Silicon Graphics Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Ashutosh Varma <ashu@axiscorp.com>
Some basic facts about Verilog-
always@(a or b)
begin
// your code
end
is semantically equivalent to:
always
begin
@(a or b);
// your code
end
This means that having always@(a or b) does not make the always block
*always* sensitive to changes to a or b.
This means that always block will trigger on a or b only when it is
*waiting* on the @(a or b) statement. In other words, if the always
block is already entered and is executing procedurally, it is *NO*
longer sensitive to changes to a or b.
This means that always block execution has to finish executing to its "end"
statement before it is ready to accept changes on its sensitivity list (or
to enter its "begin" code again, if you take the second example above).
Now, the next major point-
assign a = (b != 0);
always @(a or d)
begin
if (a)
c = d;
else
c = ~d;
b = d + 1;
...... // Zero or more statements
end
In case of zero delay assignments, Verilog simulators are at liberty to
propagate the change. There is *NO* such thing as delta delay in
Verilog, unless you use the explicit #0 delta delay in assignments.
Therefore, in the above example, the simulators can choose to propagate
b=d+1 assignment *immediately" to the assign statement AND since the
assign is also zero delay, they can choose to update a also immediately.
If that happens, then your always block will not kick off again because
it has not yet gone back to @(a or d) statement.
This is coding style is bad and is prone to different behavior in
different simulators. If you have been using a simulator for many years
and change simulator and find that code doesn't work, you cannot always
blame the simulator.
- Ashutosh Varma
Axis Systems Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
From: Chris Spear <spear@viewlogic.com>
Basically you have a race condition between the assign statement and the
always block. In Verilog-XL, if you change a signal which is on the
sensitivity list of a statement (like your assign a=b...), XL will schedule
that statement to be executed after the always block finishes. VCS reduces
scheduling overhead by immediately executing the assign statement when b
changes, then goes back to the always block. Both execution styles are
perfectly legal according to the IEEE spec. Just because XL did it one way
first, does not make it more or less correct than any other simulator.
One way to resolve this would be to put a delay in the assignment to b,
usually with a non-blocking assignment statement, <= This causes the
Verilog simulator to behave more like VHDL, with a delta cycle for
inter-block propagation. It also makes most Verilog simulators run slower
(hint, hint!).
I am a very biased observer, having sold XL for 5 years and VCS for 3.
- Chris Spear
VCS Applications Consultant
Synopsys Marlboro, MA
|
|
