Race conditions

SystemVerilog
,
1

Dear Dave,

Please explain if the below code creates a write-write race condition for “y” :

initial
 begin
  #5 y <= 2;
 end

initial
 begin
   y <= #5 3;
 end

Observation : y always takes the value of 2 irrespective of the order of simulation .

2

In reply to sush:
By definition in the 1800-2012 LRM section 10.4.2 Nonblocking procedural assignments, this is not a simulation race condition. The two assignment statements execute at different times. Even though they both schedule an update to y at time 5, the update to 3 is scheduled to happen before the update to 2. Last update wins.

3

Dear Dave,

I have tried the following code in Synopsys VCS compiler and could see race situation :

module test ;
reg [1:0]y;

initial
begin
#5 y <= 2;
end

initial
begin
y <= #5 3;
end

initial
#5 $strobe(“Value of y =%d”,y) ;

endmodule

Observation : y takes 3 or 2 as per the order of simulation .

4

In reply to sush:
I’ve tried this example on Modelsim/Questa, and 3 other simulators and all preserve the ordering y = 2. You’ll need to report this to your tool vendor,

5

Thanks Dave .

6

Dear Dave,

I have one more query on race :

######################

                initial
		  begin
		   {w,reset} = {1'b1,1'b1};
			repeat(2)
			@(negedge clock);
			reset = 0;
			#100 $finish ;
		  end

                  initial
		    begin
		     #1 clock = 0;
		     forever #1 clock = ~clock ;
		    end
		 
		 always@(negedge clock)
	           begin
		     w = ~w ;
		   end

#################################

In the above snippet , I found the variable w doesn’t repeat with a value = 1 for 2 negedge cycles .It always toggles to 0 in the very first negedge of clock .

I have changed the order of simulation and found the same result .

It looks like repeat has no impact on w .

Could you please clarify the same ?

Thanks,
Susmita

7

In reply to sush:
I do not see how reset affects the value of w with the code you showed. Also note that if you declare clock as a reg, an X to 0 transition is considered a negedge.

8

Dear Dave,

I am not saying “reset” has an impact rather “repeat” construct should repeat value of w to 1 for 2 neg-edge of clock cycles .
####################################################
{w,reset} = {1’b1,1’b1};
repeat(2)
@(negedge clock);
#####################################################

But the following snippet doesn’t repeat w to 1 for 2 negedge clock cycles rather in the first negedge i.e transition from x to 0 toggles initial value of w from 1 to 0.
######################################################
always@(negedge clock)
begin
w = ~w ;
end
########################################################

9

In reply to sush:

Dear Dave,
Please explain if the below code creates a write-write race condition for “y” :

initial
begin
#5 y <= 2;
end
initial
begin
y <= #5 3;
end

Observation : y always takes the value of 2 irrespective of the order of simulation .

Hi,

I see a race condition here! Which means incorrect usage of constructs.

For e.g. look at the code below,

//This is a race condition as you would agree.
initial
 begin
  #5 
  y <= 2;
 end
 
initial
 begin
   #5;
   y <= 3;
 end

//Now only confusion could be of having an 'intra' assignment delay
//Which can be converted to simple delays(IEEE 1800-2012 Sec 9.4.5)
initial
 begin
  #5 
  y <= 2;
 end
 
initial
 begin
   //y <= #5 3;
   //Is same as
   tempY = 3;
   #5
   y <= tempY;
 end

In short any tool you use will give correct behavior(race/incorrect behavior) regardless.

10

In reply to MayurKubavat:
There is no race. Your conversion to remove the intra-assignment delay is not equivalent to the original code and yours does have a race. The LRM section I mention above states that if the ordering of the assignments is determinate, the outcome is determinate.

11

In reply to sush:
Please start a new topic thread if you ate still having issues. It will help if you can provide a complete runnable example along with expected versus actual results. As you have written, I do not understand your issue.