NOT accuracy when mix block & non-block assignment about iverilog

[martinwhitaker]

You have a race in your code. At time 105 there are two processes (threads) waiting for the rising edge of MPC_LCLK. One is the task foo, the other is the always block that assigns to addr. A simulator can legitimately choose either of these to execute first. In this case Icarus is choosing the task, which proceeds to assign to mpc_address, MPC_LA, and MPC_LALE before relinquishing control to wait for the next clock edge. Icarus then executes the always block, which samples the current state of MPC_LA. Because you used blocking assignments in the task, MPC_LA has already been updated with the new value. Change the blocking assignments to non-blocking assignments, and you will get the behaviour you expect.

Closing as invalid.

[steveicarus]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin is 100% correct, your example had a race and it is not
a problem with Icarus Verilog. Whenever you mix blocking and
non-blocking assignments in synchronous logic, you run the risk
of races. The offending assignments in your example are in the
"foo" task. Rework that code to use non-blocking assignments,
and you should see better results.

On 07/08/2015 02:26 AM, Simuc wrote:

I show an example, it's a loop-left shifter.

|reg [7:0] q; always @(posedge clk) q <= {q[6:0], q[7]}; |

As you know, q[i] change after the clk event, and get a value which
was the data from q[i-1] at the time BEFORE the clk event.

I hope that you can understand what I mean.

— Reply to this email directly or view it on GitHub
#74 (comment).

---

Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlWdOk4ACgkQrPt1Sc2b3ikxRgCgq2ucVS6zmFzM3BEGs3aHCk2c
9mQAoIqX43urnhSxbav7h7SpKRnkX6Hf
=vVxA
-----END PGP SIGNATURE-----

[balanx]

Maybe you miss a understanding.
For circuit simulation, generally "non-blocking assignments" is used for synchrous simulation. e.g. always @(posedge clk) q <= d; it means q got value d BEFORE events, i.e. setup time is 0 before posedge clk.

Generally "blocking assignments" is used for Asynchrous simulation. e.g. @(posedge clk) q = d; it means q got value d AFTER events, i.e. firstly event 'posedge clk', then do 'q = d'.

One is before evnet, and the other is after event. So that is a accurary behaviorial description, simulator can NOT choose at random !!

[martinwhitaker]

No, your understanding is wrong. "@(event) statement;" means wait for "event" then execute "statement", regardless of what "statement" is. So if you write

always @(posedge clk) statement1;
always @(posedge clk) statement2;

a simulator can choose to execute either statement1 or statement2 first (and can choose differently each time the event occurs).

If the statement is a non-blocking assignment, the RHS expression is evaluated after waiting for the event, not before.

For a more thorough explanation, try Cliff Cumming's paper: http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

[balanx]

I show an example, it's a loop-left shifter.

reg [7:0] q;
always @(posedge clk) q <= {q[6:0], q[7]};

As you know, q[i] change after the clk event, and get a value which was the data from q[i-1] at the time BEFORE the clk event.

I hope that you can understand what I mean 'before'.

[martinwhitaker]

By 'before' you mean before any updates caused by non-blocking assignments triggered by that event. This is correct. But the problem in your original test case is that you used a blocking assignment which causes an immediate update, creating a timing race. This is equivalent to a hold-time violation in a real circuit.

If you don't understand this, read the Cliff Cummings paper.