Race in Initial block with blocking assignments

Status
Not open for further replies.

stanford

Full Member level 2
Joined
Feb 16, 2014
Messages
132
Helped
4
Reputation
8
Reaction score
6
Trophy points
1,298
Visit site
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
 

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?
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.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…