Race in Initial block with blocking assignments

Status
Not open for further replies.
S

stanford

Full Member level 2
Joined
Feb 16, 2014
Messages
132
Helped
4
Reputation
8
Reaction score
6
Trophy points
1,298
Activity points
2,223
Why is it that if you use blocking assignments, you have a race, but if you use non-blocking, you don't have a race? See below example.

initial begin // has race condition.
reset = 1’b0;
#20 reset = 1’b1;
#40 reset = 1’b0;
end

initial begin // no race condition.
reset <= 1’b0;
#20 reset <= 1’b1;
#40 reset <= 1’b0;
end
 

There is no race in the code you show. There is only a race if some other process tries to read the reset variable at the same instant that another process is writing to it.

Code: 
initial #20 $display(reset);

The code above would be in a race with the #20 reset = 1’b1; statement because you don't know if the blocking assignment updates reset before or after the $display.
 

Thanks. How does using non-blocking assignment prevent race in this case?
 

For that you need to read up on how a non-blocking assignment works. Specifically you need to know when the update to the variable assigned occurs.
 

For blocking, reset happens at 20 and gets released at 20+40=60 right?
For non-blocking, reset happens at 20 and gets released at 40?

With initial #20 $display(reset);, why does non-blocking prevent a race?

initial begin // has race condition.
reset = 1’b0;
#20 reset = 1’b1;
#40 reset = 1’b0;
end

initial begin // no race condition.
reset <= 1’b0;
#20 reset <= 1’b1;
#40 reset <= 1’b0;
end
 

stanford said:
For blocking, reset happens at 20 and gets released at 20+40=60 right?
For non-blocking, reset happens at 20 and gets released at 40?
Click to expand...
Not really. There are different queues of things that get scheduled to happen at during different regions of a single time slot.
 

initial begin // has race condition.
reset = 1’b0;
#20 reset = 1’b1;
#40 reset = 1’b0;
end

reset = 1’b0 will cause race condition only in case the design is modeled to use asynchronous active low reset as follows.

always @ (posedge clk or negedge reset)
if (!reset)
q <= 1'b0;
else
q <= d;

Because the tool does not guarantee the sequence in which procedural blocks like initial and always gets triggered.
If the always block gets triggered first the flop q will be reset properly. Otherwise it will miss the reset.

Whereas if you use the non-blocking assignment based reset initial block, the always block will get reset properly.

I think you have picked this code from cummins poaper. I don't remember which paper it is exactly.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…