Strange behaviour with blocking and non-blocking assignment 
Author Message
 Strange behaviour with blocking and non-blocking assignment

The following piece of code simulates normally:

----------------------
module test(o);
output o;
reg a,b;
assign o = a&b;
initial
begin
        a = 0;
        b = 0;
end
always
begin
        a = #1 ~a;
        b = #1 ~b;
end
endmodule

-----------------------

However when I change the blocking assignment on the 7th line to
non-blocking
i.e: from "a = 0" to "a <= 0"

'a' always evaluates to 'x' (don't care) and accordingly the output
'o' alternates between 'x' and '0' (zero) depending on the value 'b'

can anyone explain to me what's going on. Why is the non-blocking
assignment changing the behaviour of 'a'
I noticed also that changing 'b' instead of 'a' to non-blocking has no
effect

I tried the previous on 2 different simulators which assured me that
it's something in Verilog symantics and not simulator peculiarity

Regards,



Fri, 29 Apr 2005 06:25:38 GMT  
 Strange behaviour with blocking and non-blocking assignment

Quote:
>The following piece of code simulates normally:

>----------------------
>module test(o);
>output o;
>reg a,b;
>assign o = a&b;
>initial
>begin
>    a = 0;
>    b = 0;
>end
>always
>begin
>    a = #1 ~a;
>    b = #1 ~b;
>end
>endmodule

>-----------------------

>However when I change the blocking assignment on the 7th line to
>non-blocking
>i.e: from "a = 0" to "a <= 0"

>'a' always evaluates to 'x' (don't care) and accordingly the output
>'o' alternates between 'x' and '0' (zero) depending on the value 'b'

>can anyone explain to me what's going on. Why is the non-blocking
>assignment changing the behaviour of 'a'
>I noticed also that changing 'b' instead of 'a' to non-blocking has no
>effect

>I tried the previous on 2 different simulators which assured me that
>it's something in Verilog symantics and not simulator peculiarity

Actually regardless of blocking or nonblocking assignment of a, b in the
initial statement, the LRM does not guarantee that the initial statement will
be execucted before the always statement.
In your case, the simulator first executes the code (simulator dependent) in
the order it is expressed.  Thus, a=0 with no delay is assigned immediately,
and "a=#1~a; is assigned thereafter.  
If your initial has "a<=0;", then the nonblocking assignment is assigned AFTER
all blocking assignments are done in the current time period (e.g., after 1
delta time).  Thus, at time 0 (with 0 delta) "a" is x.
The always statements
        a = #1 ~a;
        b = #1 ~b;
causes a to get the CURRENT value of a (the "x") and negating that (i.e., get
"x").
The always statement then waits for 1 time unit, and then makes the compuited
assignment, i.e., the "x'.
After 1 time period, b is initalized to 0, the 2nd scheduling of b is correct.
----------------------------------------------------------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830  

Author of following textbooks:
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------


Fri, 29 Apr 2005 07:45:39 GMT  
 Strange behaviour with blocking and non-blocking assignment
I believe a simulator is free to act as follows

initialize simulation: a=x, b=x

at timestep 0

(a) evaluate the initial block:
put update a=0, b=0 in the active event queue

(b) evaluate the always block:
update a = (evaluate ~a to get x) in the event queue for time 1

(c) perform the update events: a gets 0, b gets 0

(d) evaluate the assign, perform the update to o: o gets 0.

at timestep 1

(e) perform the update event: a gets x

(f) place in the event queue for time 2 update b = (evaluate ~b to get
1)

(g) evaluate the assign, perform the update to o: o gets x.

and so on. So, I think setting a to x is valid, whether or not you use a
non-blocking assigment.

Quote:

> The following piece of code simulates normally:

> ----------------------
> module test(o);
> output o;
> reg a,b;
> assign o = a&b;
> initial
> begin
>         a = 0;
>         b = 0;
> end
> always
> begin
>         a = #1 ~a;
>         b = #1 ~b;
> end
> endmodule

> -----------------------

> However when I change the blocking assignment on the 7th line to
> non-blocking
> i.e: from "a = 0" to "a <= 0"

> 'a' always evaluates to 'x' (don't care) and accordingly the output
> 'o' alternates between 'x' and '0' (zero) depending on the value 'b'

> can anyone explain to me what's going on. Why is the non-blocking
> assignment changing the behaviour of 'a'
> I noticed also that changing 'b' instead of 'a' to non-blocking has no
> effect

> I tried the previous on 2 different simulators which assured me that
> it's something in Verilog symantics and not simulator peculiarity

> Regards,

--
Robert Swan
Nortel Networks
Ottawa, Ontario, Canada
(613)763-2688


Fri, 29 Apr 2005 23:47:40 GMT  
 Strange behaviour with blocking and non-blocking assignment
hi,
 I think this might be late.. but then i saw this newsgroup now..
regarding the problem presented by Mohammed...
 i tested the code and the code compiled and i saw no x's in the
output at all.
the code compiled normally and the simulation did not show any x's by
using the statements a <=0;
 i think this is mainly how the compiler looks at it rather than a
verilog construct problem.
 regards
 sachin
Quote:

> I believe a simulator is free to act as follows

> initialize simulation: a=x, b=x

> at timestep 0

> (a) evaluate the initial block:
> put update a=0, b=0 in the active event queue

> (b) evaluate the always block:
> update a = (evaluate ~a to get x) in the event queue for time 1

> (c) perform the update events: a gets 0, b gets 0

> (d) evaluate the assign, perform the update to o: o gets 0.

> at timestep 1

> (e) perform the update event: a gets x

> (f) place in the event queue for time 2 update b = (evaluate ~b to get
> 1)

> (g) evaluate the assign, perform the update to o: o gets x.

> and so on. So, I think setting a to x is valid, whether or not you use a
> non-blocking assigment.


> > The following piece of code simulates normally:

> > ----------------------
> > module test(o);
> > output o;
> > reg a,b;
> > assign o = a&b;
> > initial
> > begin
> >         a = 0;
> >         b = 0;
> > end
> > always
> > begin
> >         a = #1 ~a;
> >         b = #1 ~b;
> > end
> > endmodule

> > -----------------------

> > However when I change the blocking assignment on the 7th line to
> > non-blocking
> > i.e: from "a = 0" to "a <= 0"

> > 'a' always evaluates to 'x' (don't care) and accordingly the output
> > 'o' alternates between 'x' and '0' (zero) depending on the value 'b'

> > can anyone explain to me what's going on. Why is the non-blocking
> > assignment changing the behaviour of 'a'
> > I noticed also that changing 'b' instead of 'a' to non-blocking has no
> > effect

> > I tried the previous on 2 different simulators which assured me that
> > it's something in Verilog symantics and not simulator peculiarity

> > Regards,



Mon, 23 May 2005 13:38:04 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. blocking and non-blocking assignment

2. Blocking and Non-blocking assignment ?

3. "Blocking and non-blocking" assignments

4. Strange behaviour in initial block

5. blocking/non-blocking

6. Blocking/Non-Blocking

7. block and non-block?

8. blocking vs non blocking

9. Blocking vs Non-Blocking Assignemts

10. blocking vs non-blocking

11. Blocking and non-blocking sockets

12. blocking/non-blocking

 

 
Powered by phpBB® Forum Software