RACE CONDITION
1.Verilog is easy to learn because its gives quick results.
2. Although many users are telling that their work is free from race condition.But the fact is race condition is easy to create, to understand, to document but difficult to find.
Here we will discuss regarding events which creates the race condition & solution for that.
What Is Race Condition?
When two expressions are scheduled to execute at same time, and if the order of the execution is not determined, then race condition occurs.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
The simulator is correct in displaying either a 1 or a 0. The assignment of 0 to q enables an update event for p. The simulator may either continue or execute the $display system task or execute the update for p, followed by the $display task.
Then guess what can the value of p ?
Simulate the above code in your simulator. Then simulate the following code . Statement "assign p = q;" is changed to end of the module.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
Analyze the effect if I change the order of the assign statement.
Why Race Condition?
To describe the behavior of electronics hardware at varying levels of abstraction, Verilog HDL has to be a parallel programming language and Verilog simulator and language itself are standard of IEEE, even though there are some nondeterministic events which is not mentioned in IEEE LRM and left it to the simulator algorithm, which causes the race condition. So it is impossible to avoid the race conditions from the language but we can avoid from coding styles.
Look at following code. Is there any race condition?
EXAMPLE:
initial
begin
in = 1;
out <= in;
end
Now if you swap these two lines:
EXAMPLE
initial
begin
out <= in;
in = 1;
end
Think, is there any race condition created?
Here first statement will schedule a non-blocking update for "out" to whatever "in" was set to previously, and then "in" will be set to 1 by the blocking assignment. Any statement whether it is blocking or nonblocking statements in a sequential block (i.e. begin-end block) are guaranteed to execute in the order they appear. So there is no race condition in the above code also. Since it is easy to make the "ordering mistake", one of Verilog coding guidelines is: "Do not mix blocking and nonblocking assignments in the same always block". This creates unnecessary doubt of race condition.
When Race Is Visible?
Sometimes unexpected output gives clue to search for race. Even if race condition is existing in code, and if the output is correct, then one may not realize that there exists race condition in their code. This type of hidden race conditions may come out during the following situation.
When different simulators are used to run the same code.
Some times when the new release of the simulator is used.
Adding more code to previous code might pop out the previously hidden race.
If the order of the files is changed.
When using some tool specific options.
If the order of the concurrent blocks or concurrent statements is changed.(One example is already discussed in the previous topics)
Some simulators have special options which reports where exactly the race condition is exists. Linting tools can also catch race condition.
How To Prevent Race Condition?
There are many details which is unspecified between simulators. The problem will be realized when you are using different simulators. If you are limited to design guidelines then there is less chance for race condition but if you are using Verilog with all features for Testbench, then it is impossible to avoid. Moreover the language which you are using is parallel but the processor is sequential. So you cant prevent race condition.
Types Of Race Condition
Here we will see race condition closely.
Types of race condition
Write-Write Race:
it occurs when same register is written in both the blocks.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
a = 5;
Here you are seeing that one block is updating value of a while another also. Now which always block should go first. This is nondeterministic in IEEE standard and left that work to the simulator algorithm.
Read-Write Race:
it occurs when same register is read in one block and writes in another.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
b = a;
Here you are seeing that in one always block value is assign to a while simultaneously its value is assign to b means a is writing and read parallel. This type of race condition can easily solved by using nonblocking assignment.
EXAMPLE
always @(posedge clk)
a <= 1;
always @(posedge clk)
b <= a;
More Race Example:
1) Function calls
EXAMPLE:
function incri();
begin
pkt_num = pkt_num + 1;
end
endfunction
always @(...)
sent_pkt_num = incri();
always @(...)
sent_pkt_num_onemore = incri();
2) Fork join
EXAMPLE:
fork
a =0;
b = a;
join
3) $random
EXAMPLE:
always @(...)
$display("first Random number is %d",$random());
always @(...)
$display("second Random number is %d",$random());
4) Clock race
EXAMPLE
initial
clk = 0;
always
clk = #5 ~clk;
If your clock generator is always showing "X" then there is a race condition. There is one more point to be noted in above example. Initial and always starts executes at time zero.
5) Declaration and initial
EXAMPLE:
reg a = 0;
initial
a = 1;
6)Testbench DUT race condition.
In test bench , if driving is done at posedge and reading in DUT is done at the same time , then there is race. To avoid this, write from the Testbench at negedge or before the posedge of clock. This makes sure that the DUT samples the signal without any race.
EXAMPLE:
module DUT();
input d;
input clock;
output q;
always @(posedge clock)
q = d;
endmodule
module testbench();
DUT dut_i(d,clk,q);
initial
begin
@(posedge clk)
d = 1;
@(posedge clock)
d = 0;
end
endmodule
The above example has write read race condition.
Event Terminology:
Every change in value of a net or variable in the circuit being simulated, as well as the named event, is considered an update event. Processes are sensitive to update events. When an update event is executed, all the processes that are sensitive to that event are evaluated in an arbitrary order. The evaluation of a process is also an event, known as an evaluation event.
In addition to events, another key aspect of a simulator is time. The term simulation time is used to refer to the time value maintained by the simulator to model the actual time it would take for the circuit being simulated. The term time is used interchangeably with simulation time in this section. Events can occur at different times. In order to keep track of the events and to make sure they are processed in the correct order, the events are kept on an event queue, ordered by simulation time. Putting an event on the queue is called scheduling an event.
The Stratified Event Queue
The Verilog event queue is logically segmented into five different regions. Events are added to any of the five regions but are only removed from the active region.
1) Events that occur at the current simulation time and can be processed in any order. These are the
active events.
1.1 evaluation of blocking assignment.
1.2 evaluation of RHS of nonblocking assignment.
1.3 evaluation of continuous assignment.
1.4 evaluation of primitives I/Os
1.5 evaluation of $display or $write
2) Events that occur at the current simulation time, but that shall be processed after all the active events are processed. These are the inactive events.
#0 delay statement.
3) Events that have been evaluated during some previous simulation time, but that shall be assigned at this simulation time after all the active and inactive events are processed. These are the nonblocking assign update events.
4) Events that shall be processed after all the active, inactive, and non blocking assign update events are processed. These are the monitor events.
$strobe and $monitor
5) Events that occur at some future simulation time. These are the future events. Future events are divided into future inactive events, and future non blocking assignment update events.
Example : PLI tasks
The processing of all the active events is called a simulation cycle.
Determinism
This standard guarantees a certain scheduling order.
1) Statements within a begin-end block shall be executed in the order in which they appear in that begin-end block. Execution of statements in a particular begin-end block can be suspended in favor of other processes in the model; however, in no case shall the statements in a begin-end block be executed in any order other than that in which they appear in the source.
2) Non blocking assignments shall be performed in the order the statements were executed.
Consider the following example:
initial begin
a <= 0;
a <= 1;
end
When this block is executed, there will be two events added to the non blocking assign update queue. The previous rule requires that they be entered on the queue in source order; this rule requires that they be taken from the queue and performed in source order as well. Hence, at the end of time step 1, the variable a will be assigned 0 and then 1.
Nondeterminism
One source of nondeterminism is the fact that active events can be taken off the queue and processed in any order. Another source of nondeterminism is that statements without time-control constructs in behavioral blocks do not have to be executed as one event. Time control statements are the # expression and @ expression constructs. At any time while evaluating a behavioral statement, the simulator may suspend execution and place the partially completed event as a pending active event on the event queue. The effect of this is to allow the interleaving of process execution. Note that the order of interleaved execution is nondeterministic and not under control of the user.
Guideline To Avoid Race Condition
(A). Do not mix blocking and nonblocking statements in same block.
(B). Do not read and write using blocking statement on same variable.( avoids read write race)
(C). Do not initialize at time zero.
(D). Do not assign a variable in more than one block.( avoids write-write race)
(E). Use assign statement for inout types of ports & do not mix blocking and nonblocking styles of declaration in same block. It is disallow variables assigned in a blocking assignment of a clocked always block being used outside that block and disallow cyclical references that don't go through a non-blocking assignment. It is require all non-blocking assignments to be in a clocked always block.
(F). Use blocking statements for combinational design and nonblocking for sequential design. If you want gated outputs from the flops, you put them in continuous assignments or an always block with no clock.
Avoid Race Between Testbench And Dut
Race condition may occurs between DUT and testbench. Sometimes verification engineers are not allowed to see the DUT, Sometimes they don't even have DUT to verify. Consider the following example. Suppose a testbench is required to wait for a specific response from its DUT. Once it receives the response, at the same simulation time it needs to send a set of stimuli back to the DUT.
Most Synchronous DUT works on the posedge of clock. If the Testbench is also taking the same reference, then we may unconditionally end in race condition. So it~Rs better to choose some other event than exactly posedge of cock. Signals are stable after the some delay of posedge of clock. Sampling race condition would be proper if it is done after some delay of posedge of clock. Driving race condition can be avoided if the signal is driven before the posedge of clock, so at posedge of clock ,the DUT samples the stable signal. So engineers prefer to sample and drive on negedge of clock, this is simple and easy to debug in waveform debugger also. RACE CONDITION
Verilog is easy to learn because its gives quick results. Although many users are telling that their work is free from race condition.But the fact is race condition is easy to create, to understand, to document but difficult to find. Here we will discuss regarding events which creates the race condition & solution for that.
What Is Race Condition?
When two expressions are scheduled to execute at same time, and if the order of the execution is not determined, then race condition occurs.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
The simulator is correct in displaying either a 1 or a 0. The assignment of 0 to q enables an update event for p. The simulator may either continue or execute the $display system task or execute the update for p, followed by the $display task.
Then guess what can the value of p ?
Simulate the above code in your simulator. Then simulate the following code . Statement "assign p = q;" is changed to end of the module.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
Analyze the effect if I change the order of the assign statement.
Why Race Condition?
To describe the behavior of electronics hardware at varying levels of abstraction, Verilog HDL has to be a parallel programming language and Verilog simulator and language itself are standard of IEEE, even though there are some nondeterministic events which is not mentioned in IEEE LRM and left it to the simulator algorithm, which causes the race condition. So it is impossible to avoid the race conditions from the language but we can avoid from coding styles.
Look at following code. Is there any race condition?
EXAMPLE:
initial
begin
in = 1;
out <= in;
end
Now if you swap these two lines:
EXAMPLE
initial
begin
out <= in;
in = 1;
end
Think, is there any race condition created?
Here first statement will schedule a non-blocking update for "out" to whatever "in" was set to previously, and then "in" will be set to 1 by the blocking assignment. Any statement whether it is blocking or nonblocking statements in a sequential block (i.e. begin-end block) are guaranteed to execute in the order they appear. So there is no race condition in the above code also. Since it is easy to make the "ordering mistake", one of Verilog coding guidelines is: "Do not mix blocking and nonblocking assignments in the same always block". This creates unnecessary doubt of race condition.
When Race Is Visible?
Sometimes unexpected output gives clue to search for race. Even if race condition is existing in code, and if the output is correct, then one may not realize that there exists race condition in their code. This type of hidden race conditions may come out during the following situation.
When different simulators are used to run the same code.
Some times when the new release of the simulator is used.
Adding more code to previous code might pop out the previously hidden race.
If the order of the files is changed.
When using some tool specific options.
If the order of the concurrent blocks or concurrent statements is changed.(One example is already discussed in the previous topics)
Some simulators have special options which reports where exactly the race condition is exists. Linting tools can also catch race condition.
How To Prevent Race Condition?
There are many details which is unspecified between simulators. The problem will be realized when you are using different simulators. If you are limited to design guidelines then there is less chance for race condition but if you are using Verilog with all features for Testbench, then it is impossible to avoid. Moreover the language which you are using is parallel but the processor is sequential. So you cant prevent race condition.
Types Of Race Condition
Here we will see race condition closely.
Types of race condition
Write-Write Race:
it occurs when same register is written in both the blocks.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
a = 5;
Here you are seeing that one block is updating value of a while another also. Now which always block should go first. This is nondeterministic in IEEE standard and left that work to the simulator algorithm.
Read-Write Race:
it occurs when same register is read in one block and writes in another.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
b = a;
Here you are seeing that in one always block value is assign to a while simultaneously its value is assign to b means a is writing and read parallel. This type of race condition can easily solved by using nonblocking assignment.
EXAMPLE
always @(posedge clk)
a <= 1;
always @(posedge clk)
b <= a;
More Race Example:
1) Function calls
EXAMPLE:
function incri();
begin
pkt_num = pkt_num + 1;
end
endfunction
always @(...)
sent_pkt_num = incri();
always @(...)
sent_pkt_num_onemore = incri();
2) Fork join
EXAMPLE:
fork
a =0;
b = a;
join
3) $random
EXAMPLE:
always @(...)
$display("first Random number is %d",$random());
always @(...)
$display("second Random number is %d",$random());
4) Clock race
EXAMPLE
initial
clk = 0;
always
clk = #5 ~clk;
If your clock generator is always showing "X" then there is a race condition. There is one more point to be noted in above example. Initial and always starts executes at time zero.
5) Declaration and initial
EXAMPLE:
reg a = 0;
initial
a = 1;
6)Testbench DUT race condition.
In test bench , if driving is done at posedge and reading in DUT is done at the same time , then there is race. To avoid this, write from the Testbench at negedge or before the posedge of clock. This makes sure that the DUT samples the signal without any race.
EXAMPLE:
module DUT();
input d;
input clock;
output q;
always @(posedge clock)
q = d;
endmodule
module testbench();
DUT dut_i(d,clk,q);
initial
begin
@(posedge clk)
d = 1;
@(posedge clock)
d = 0;
end
endmodule
The above example has write read race condition.
Event Terminology:
Every change in value of a net or variable in the circuit being simulated, as well as the named event, is considered an update event. Processes are sensitive to update events. When an update event is executed, all the processes that are sensitive to that event are evaluated in an arbitrary order. The evaluation of a process is also an event, known as an evaluation event.
In addition to events, another key aspect of a simulator is time. The term simulation time is used to refer to the time value maintained by the simulator to model the actual time it would take for the circuit being simulated. The term time is used interchangeably with simulation time in this section. Events can occur at different times. In order to keep track of the events and to make sure they are processed in the correct order, the events are kept on an event queue, ordered by simulation time. Putting an event on the queue is called scheduling an event.
The Stratified Event Queue
The Verilog event queue is logically segmented into five different regions. Events are added to any of the five regions but are only removed from the active region.
1) Events that occur at the current simulation time and can be processed in any order. These are the
active events.
1.1 evaluation of blocking assignment.
1.2 evaluation of RHS of nonblocking assignment.
1.3 evaluation of continuous assignment.
1.4 evaluation of primitives I/Os
1.5 evaluation of $display or $write
2) Events that occur at the current simulation time, but that shall be processed after all the active events are processed. These are the inactive events.
#0 delay statement.
3) Events that have been evaluated during some previous simulation time, but that shall be assigned at this simulation time after all the active and inactive events are processed. These are the nonblocking assign update events.
4) Events that shall be processed after all the active, inactive, and non blocking assign update events are processed. These are the monitor events.
$strobe and $monitor
5) Events that occur at some future simulation time. These are the future events. Future events are divided into future inactive events, and future non blocking assignment update events.
Example : PLI tasks
The processing of all the active events is called a simulation cycle.
Determinism
This standard guarantees a certain scheduling order.
1) Statements within a begin-end block shall be executed in the order in which they appear in that begin-end block. Execution of statements in a particular begin-end block can be suspended in favor of other processes in the model; however, in no case shall the statements in a begin-end block be executed in any order other than that in which they appear in the source.
2) Non blocking assignments shall be performed in the order the statements were executed.
Consider the following example:
initial begin
a <= 0;
a <= 1;
end
When this block is executed, there will be two events added to the non blocking assign update queue. The previous rule requires that they be entered on the queue in source order; this rule requires that they be taken from the queue and performed in source order as well. Hence, at the end of time step 1, the variable a will be assigned 0 and then 1.
Nondeterminism
One source of nondeterminism is the fact that active events can be taken off the queue and processed in any order. Another source of nondeterminism is that statements without time-control constructs in behavioral blocks do not have to be executed as one event. Time control statements are the # expression and @ expression constructs. At any time while evaluating a behavioral statement, the simulator may suspend execution and place the partially completed event as a pending active event on the event queue. The effect of this is to allow the interleaving of process execution. Note that the order of interleaved execution is nondeterministic and not under control of the user.
Guideline To Avoid Race Condition
(A). Do not mix blocking and nonblocking statements in same block.
(B). Do not read and write using blocking statement on same variable.( avoids read write race)
(C). Do not initialize at time zero.
(D). Do not assign a variable in more than one block.( avoids write-write race)
(E). Use assign statement for inout types of ports & do not mix blocking and nonblocking styles of declaration in same block. It is disallow variables assigned in a blocking assignment of a clocked always block being used outside that block and disallow cyclical references that don't go through a non-blocking assignment. It is require all non-blocking assignments to be in a clocked always block.
(F). Use blocking statements for combinational design and nonblocking for sequential design. If you want gated outputs from the flops, you put them in continuous assignments or an always block with no clock.
Avoid Race Between Testbench And Dut
Race condition may occurs between DUT and testbench. Sometimes verification engineers are not allowed to see the DUT, Sometimes they don't even have DUT to verify. Consider the following example. Suppose a testbench is required to wait for a specific response from its DUT. Once it receives the response, at the same simulation time it needs to send a set of stimuli back to the DUT.
Most Synchronous DUT works on the posedge of clock. If the Testbench is also taking the same reference, then we may unconditionally end in race condition. So it~Rs better to choose some other event than exactly posedge of cock. Signals are stable after the some delay of posedge of clock. Sampling race condition would be proper if it is done after some delay of posedge of clock. Driving race condition can be avoided if the signal is driven before the posedge of clock, so at posedge of clock ,the DUT samples the stable signal. So engineers prefer to sample and drive on negedge of clock, this is simple and easy to debug in waveform debugger also.
1.Verilog is easy to learn because its gives quick results.
2. Although many users are telling that their work is free from race condition.But the fact is race condition is easy to create, to understand, to document but difficult to find.
Here we will discuss regarding events which creates the race condition & solution for that.
What Is Race Condition?
When two expressions are scheduled to execute at same time, and if the order of the execution is not determined, then race condition occurs.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
The simulator is correct in displaying either a 1 or a 0. The assignment of 0 to q enables an update event for p. The simulator may either continue or execute the $display system task or execute the update for p, followed by the $display task.
Then guess what can the value of p ?
Simulate the above code in your simulator. Then simulate the following code . Statement "assign p = q;" is changed to end of the module.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
Analyze the effect if I change the order of the assign statement.
Why Race Condition?
To describe the behavior of electronics hardware at varying levels of abstraction, Verilog HDL has to be a parallel programming language and Verilog simulator and language itself are standard of IEEE, even though there are some nondeterministic events which is not mentioned in IEEE LRM and left it to the simulator algorithm, which causes the race condition. So it is impossible to avoid the race conditions from the language but we can avoid from coding styles.
Look at following code. Is there any race condition?
EXAMPLE:
initial
begin
in = 1;
out <= in;
end
Now if you swap these two lines:
EXAMPLE
initial
begin
out <= in;
in = 1;
end
Think, is there any race condition created?
Here first statement will schedule a non-blocking update for "out" to whatever "in" was set to previously, and then "in" will be set to 1 by the blocking assignment. Any statement whether it is blocking or nonblocking statements in a sequential block (i.e. begin-end block) are guaranteed to execute in the order they appear. So there is no race condition in the above code also. Since it is easy to make the "ordering mistake", one of Verilog coding guidelines is: "Do not mix blocking and nonblocking assignments in the same always block". This creates unnecessary doubt of race condition.
When Race Is Visible?
Sometimes unexpected output gives clue to search for race. Even if race condition is existing in code, and if the output is correct, then one may not realize that there exists race condition in their code. This type of hidden race conditions may come out during the following situation.
When different simulators are used to run the same code.
Some times when the new release of the simulator is used.
Adding more code to previous code might pop out the previously hidden race.
If the order of the files is changed.
When using some tool specific options.
If the order of the concurrent blocks or concurrent statements is changed.(One example is already discussed in the previous topics)
Some simulators have special options which reports where exactly the race condition is exists. Linting tools can also catch race condition.
How To Prevent Race Condition?
There are many details which is unspecified between simulators. The problem will be realized when you are using different simulators. If you are limited to design guidelines then there is less chance for race condition but if you are using Verilog with all features for Testbench, then it is impossible to avoid. Moreover the language which you are using is parallel but the processor is sequential. So you cant prevent race condition.
Types Of Race Condition
Here we will see race condition closely.
Types of race condition
Write-Write Race:
it occurs when same register is written in both the blocks.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
a = 5;
Here you are seeing that one block is updating value of a while another also. Now which always block should go first. This is nondeterministic in IEEE standard and left that work to the simulator algorithm.
Read-Write Race:
it occurs when same register is read in one block and writes in another.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
b = a;
Here you are seeing that in one always block value is assign to a while simultaneously its value is assign to b means a is writing and read parallel. This type of race condition can easily solved by using nonblocking assignment.
EXAMPLE
always @(posedge clk)
a <= 1;
always @(posedge clk)
b <= a;
More Race Example:
1) Function calls
EXAMPLE:
function incri();
begin
pkt_num = pkt_num + 1;
end
endfunction
always @(...)
sent_pkt_num = incri();
always @(...)
sent_pkt_num_onemore = incri();
2) Fork join
EXAMPLE:
fork
a =0;
b = a;
join
3) $random
EXAMPLE:
always @(...)
$display("first Random number is %d",$random());
always @(...)
$display("second Random number is %d",$random());
4) Clock race
EXAMPLE
initial
clk = 0;
always
clk = #5 ~clk;
If your clock generator is always showing "X" then there is a race condition. There is one more point to be noted in above example. Initial and always starts executes at time zero.
5) Declaration and initial
EXAMPLE:
reg a = 0;
initial
a = 1;
6)Testbench DUT race condition.
In test bench , if driving is done at posedge and reading in DUT is done at the same time , then there is race. To avoid this, write from the Testbench at negedge or before the posedge of clock. This makes sure that the DUT samples the signal without any race.
EXAMPLE:
module DUT();
input d;
input clock;
output q;
always @(posedge clock)
q = d;
endmodule
module testbench();
DUT dut_i(d,clk,q);
initial
begin
@(posedge clk)
d = 1;
@(posedge clock)
d = 0;
end
endmodule
The above example has write read race condition.
Event Terminology:
Every change in value of a net or variable in the circuit being simulated, as well as the named event, is considered an update event. Processes are sensitive to update events. When an update event is executed, all the processes that are sensitive to that event are evaluated in an arbitrary order. The evaluation of a process is also an event, known as an evaluation event.
In addition to events, another key aspect of a simulator is time. The term simulation time is used to refer to the time value maintained by the simulator to model the actual time it would take for the circuit being simulated. The term time is used interchangeably with simulation time in this section. Events can occur at different times. In order to keep track of the events and to make sure they are processed in the correct order, the events are kept on an event queue, ordered by simulation time. Putting an event on the queue is called scheduling an event.
The Stratified Event Queue
The Verilog event queue is logically segmented into five different regions. Events are added to any of the five regions but are only removed from the active region.
1) Events that occur at the current simulation time and can be processed in any order. These are the
active events.
1.1 evaluation of blocking assignment.
1.2 evaluation of RHS of nonblocking assignment.
1.3 evaluation of continuous assignment.
1.4 evaluation of primitives I/Os
1.5 evaluation of $display or $write
2) Events that occur at the current simulation time, but that shall be processed after all the active events are processed. These are the inactive events.
#0 delay statement.
3) Events that have been evaluated during some previous simulation time, but that shall be assigned at this simulation time after all the active and inactive events are processed. These are the nonblocking assign update events.
4) Events that shall be processed after all the active, inactive, and non blocking assign update events are processed. These are the monitor events.
$strobe and $monitor
5) Events that occur at some future simulation time. These are the future events. Future events are divided into future inactive events, and future non blocking assignment update events.
Example : PLI tasks
The processing of all the active events is called a simulation cycle.
Determinism
This standard guarantees a certain scheduling order.
1) Statements within a begin-end block shall be executed in the order in which they appear in that begin-end block. Execution of statements in a particular begin-end block can be suspended in favor of other processes in the model; however, in no case shall the statements in a begin-end block be executed in any order other than that in which they appear in the source.
2) Non blocking assignments shall be performed in the order the statements were executed.
Consider the following example:
initial begin
a <= 0;
a <= 1;
end
When this block is executed, there will be two events added to the non blocking assign update queue. The previous rule requires that they be entered on the queue in source order; this rule requires that they be taken from the queue and performed in source order as well. Hence, at the end of time step 1, the variable a will be assigned 0 and then 1.
Nondeterminism
One source of nondeterminism is the fact that active events can be taken off the queue and processed in any order. Another source of nondeterminism is that statements without time-control constructs in behavioral blocks do not have to be executed as one event. Time control statements are the # expression and @ expression constructs. At any time while evaluating a behavioral statement, the simulator may suspend execution and place the partially completed event as a pending active event on the event queue. The effect of this is to allow the interleaving of process execution. Note that the order of interleaved execution is nondeterministic and not under control of the user.
Guideline To Avoid Race Condition
(A). Do not mix blocking and nonblocking statements in same block.
(B). Do not read and write using blocking statement on same variable.( avoids read write race)
(C). Do not initialize at time zero.
(D). Do not assign a variable in more than one block.( avoids write-write race)
(E). Use assign statement for inout types of ports & do not mix blocking and nonblocking styles of declaration in same block. It is disallow variables assigned in a blocking assignment of a clocked always block being used outside that block and disallow cyclical references that don't go through a non-blocking assignment. It is require all non-blocking assignments to be in a clocked always block.
(F). Use blocking statements for combinational design and nonblocking for sequential design. If you want gated outputs from the flops, you put them in continuous assignments or an always block with no clock.
Avoid Race Between Testbench And Dut
Race condition may occurs between DUT and testbench. Sometimes verification engineers are not allowed to see the DUT, Sometimes they don't even have DUT to verify. Consider the following example. Suppose a testbench is required to wait for a specific response from its DUT. Once it receives the response, at the same simulation time it needs to send a set of stimuli back to the DUT.
Most Synchronous DUT works on the posedge of clock. If the Testbench is also taking the same reference, then we may unconditionally end in race condition. So it~Rs better to choose some other event than exactly posedge of cock. Signals are stable after the some delay of posedge of clock. Sampling race condition would be proper if it is done after some delay of posedge of clock. Driving race condition can be avoided if the signal is driven before the posedge of clock, so at posedge of clock ,the DUT samples the stable signal. So engineers prefer to sample and drive on negedge of clock, this is simple and easy to debug in waveform debugger also. RACE CONDITION
Verilog is easy to learn because its gives quick results. Although many users are telling that their work is free from race condition.But the fact is race condition is easy to create, to understand, to document but difficult to find. Here we will discuss regarding events which creates the race condition & solution for that.
What Is Race Condition?
When two expressions are scheduled to execute at same time, and if the order of the execution is not determined, then race condition occurs.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
The simulator is correct in displaying either a 1 or a 0. The assignment of 0 to q enables an update event for p. The simulator may either continue or execute the $display system task or execute the update for p, followed by the $display task.
Then guess what can the value of p ?
Simulate the above code in your simulator. Then simulate the following code . Statement "assign p = q;" is changed to end of the module.
EXAMPLE
module race();
wire p;
reg q;
assign p = q;
initial begin
q = 1;
#1 q = 0;
$display(p);
end
endmodule
Analyze the effect if I change the order of the assign statement.
Why Race Condition?
To describe the behavior of electronics hardware at varying levels of abstraction, Verilog HDL has to be a parallel programming language and Verilog simulator and language itself are standard of IEEE, even though there are some nondeterministic events which is not mentioned in IEEE LRM and left it to the simulator algorithm, which causes the race condition. So it is impossible to avoid the race conditions from the language but we can avoid from coding styles.
Look at following code. Is there any race condition?
EXAMPLE:
initial
begin
in = 1;
out <= in;
end
Now if you swap these two lines:
EXAMPLE
initial
begin
out <= in;
in = 1;
end
Think, is there any race condition created?
Here first statement will schedule a non-blocking update for "out" to whatever "in" was set to previously, and then "in" will be set to 1 by the blocking assignment. Any statement whether it is blocking or nonblocking statements in a sequential block (i.e. begin-end block) are guaranteed to execute in the order they appear. So there is no race condition in the above code also. Since it is easy to make the "ordering mistake", one of Verilog coding guidelines is: "Do not mix blocking and nonblocking assignments in the same always block". This creates unnecessary doubt of race condition.
When Race Is Visible?
Sometimes unexpected output gives clue to search for race. Even if race condition is existing in code, and if the output is correct, then one may not realize that there exists race condition in their code. This type of hidden race conditions may come out during the following situation.
When different simulators are used to run the same code.
Some times when the new release of the simulator is used.
Adding more code to previous code might pop out the previously hidden race.
If the order of the files is changed.
When using some tool specific options.
If the order of the concurrent blocks or concurrent statements is changed.(One example is already discussed in the previous topics)
Some simulators have special options which reports where exactly the race condition is exists. Linting tools can also catch race condition.
How To Prevent Race Condition?
There are many details which is unspecified between simulators. The problem will be realized when you are using different simulators. If you are limited to design guidelines then there is less chance for race condition but if you are using Verilog with all features for Testbench, then it is impossible to avoid. Moreover the language which you are using is parallel but the processor is sequential. So you cant prevent race condition.
Types Of Race Condition
Here we will see race condition closely.
Types of race condition
Write-Write Race:
it occurs when same register is written in both the blocks.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
a = 5;
Here you are seeing that one block is updating value of a while another also. Now which always block should go first. This is nondeterministic in IEEE standard and left that work to the simulator algorithm.
Read-Write Race:
it occurs when same register is read in one block and writes in another.
EXAMPLE:
always @(posedge clk)
a = 1;
always @(posedge clk)
b = a;
Here you are seeing that in one always block value is assign to a while simultaneously its value is assign to b means a is writing and read parallel. This type of race condition can easily solved by using nonblocking assignment.
EXAMPLE
always @(posedge clk)
a <= 1;
always @(posedge clk)
b <= a;
More Race Example:
1) Function calls
EXAMPLE:
function incri();
begin
pkt_num = pkt_num + 1;
end
endfunction
always @(...)
sent_pkt_num = incri();
always @(...)
sent_pkt_num_onemore = incri();
2) Fork join
EXAMPLE:
fork
a =0;
b = a;
join
3) $random
EXAMPLE:
always @(...)
$display("first Random number is %d",$random());
always @(...)
$display("second Random number is %d",$random());
4) Clock race
EXAMPLE
initial
clk = 0;
always
clk = #5 ~clk;
If your clock generator is always showing "X" then there is a race condition. There is one more point to be noted in above example. Initial and always starts executes at time zero.
5) Declaration and initial
EXAMPLE:
reg a = 0;
initial
a = 1;
6)Testbench DUT race condition.
In test bench , if driving is done at posedge and reading in DUT is done at the same time , then there is race. To avoid this, write from the Testbench at negedge or before the posedge of clock. This makes sure that the DUT samples the signal without any race.
EXAMPLE:
module DUT();
input d;
input clock;
output q;
always @(posedge clock)
q = d;
endmodule
module testbench();
DUT dut_i(d,clk,q);
initial
begin
@(posedge clk)
d = 1;
@(posedge clock)
d = 0;
end
endmodule
The above example has write read race condition.
Event Terminology:
Every change in value of a net or variable in the circuit being simulated, as well as the named event, is considered an update event. Processes are sensitive to update events. When an update event is executed, all the processes that are sensitive to that event are evaluated in an arbitrary order. The evaluation of a process is also an event, known as an evaluation event.
In addition to events, another key aspect of a simulator is time. The term simulation time is used to refer to the time value maintained by the simulator to model the actual time it would take for the circuit being simulated. The term time is used interchangeably with simulation time in this section. Events can occur at different times. In order to keep track of the events and to make sure they are processed in the correct order, the events are kept on an event queue, ordered by simulation time. Putting an event on the queue is called scheduling an event.
The Stratified Event Queue
The Verilog event queue is logically segmented into five different regions. Events are added to any of the five regions but are only removed from the active region.
1) Events that occur at the current simulation time and can be processed in any order. These are the
active events.
1.1 evaluation of blocking assignment.
1.2 evaluation of RHS of nonblocking assignment.
1.3 evaluation of continuous assignment.
1.4 evaluation of primitives I/Os
1.5 evaluation of $display or $write
2) Events that occur at the current simulation time, but that shall be processed after all the active events are processed. These are the inactive events.
#0 delay statement.
3) Events that have been evaluated during some previous simulation time, but that shall be assigned at this simulation time after all the active and inactive events are processed. These are the nonblocking assign update events.
4) Events that shall be processed after all the active, inactive, and non blocking assign update events are processed. These are the monitor events.
$strobe and $monitor
5) Events that occur at some future simulation time. These are the future events. Future events are divided into future inactive events, and future non blocking assignment update events.
Example : PLI tasks
The processing of all the active events is called a simulation cycle.
Determinism
This standard guarantees a certain scheduling order.
1) Statements within a begin-end block shall be executed in the order in which they appear in that begin-end block. Execution of statements in a particular begin-end block can be suspended in favor of other processes in the model; however, in no case shall the statements in a begin-end block be executed in any order other than that in which they appear in the source.
2) Non blocking assignments shall be performed in the order the statements were executed.
Consider the following example:
initial begin
a <= 0;
a <= 1;
end
When this block is executed, there will be two events added to the non blocking assign update queue. The previous rule requires that they be entered on the queue in source order; this rule requires that they be taken from the queue and performed in source order as well. Hence, at the end of time step 1, the variable a will be assigned 0 and then 1.
Nondeterminism
One source of nondeterminism is the fact that active events can be taken off the queue and processed in any order. Another source of nondeterminism is that statements without time-control constructs in behavioral blocks do not have to be executed as one event. Time control statements are the # expression and @ expression constructs. At any time while evaluating a behavioral statement, the simulator may suspend execution and place the partially completed event as a pending active event on the event queue. The effect of this is to allow the interleaving of process execution. Note that the order of interleaved execution is nondeterministic and not under control of the user.
Guideline To Avoid Race Condition
(A). Do not mix blocking and nonblocking statements in same block.
(B). Do not read and write using blocking statement on same variable.( avoids read write race)
(C). Do not initialize at time zero.
(D). Do not assign a variable in more than one block.( avoids write-write race)
(E). Use assign statement for inout types of ports & do not mix blocking and nonblocking styles of declaration in same block. It is disallow variables assigned in a blocking assignment of a clocked always block being used outside that block and disallow cyclical references that don't go through a non-blocking assignment. It is require all non-blocking assignments to be in a clocked always block.
(F). Use blocking statements for combinational design and nonblocking for sequential design. If you want gated outputs from the flops, you put them in continuous assignments or an always block with no clock.
Avoid Race Between Testbench And Dut
Race condition may occurs between DUT and testbench. Sometimes verification engineers are not allowed to see the DUT, Sometimes they don't even have DUT to verify. Consider the following example. Suppose a testbench is required to wait for a specific response from its DUT. Once it receives the response, at the same simulation time it needs to send a set of stimuli back to the DUT.
Most Synchronous DUT works on the posedge of clock. If the Testbench is also taking the same reference, then we may unconditionally end in race condition. So it~Rs better to choose some other event than exactly posedge of cock. Signals are stable after the some delay of posedge of clock. Sampling race condition would be proper if it is done after some delay of posedge of clock. Driving race condition can be avoided if the signal is driven before the posedge of clock, so at posedge of clock ,the DUT samples the stable signal. So engineers prefer to sample and drive on negedge of clock, this is simple and easy to debug in waveform debugger also.
//content is copied from testbench.in and a bit edited .
//you can give your inputs as comments
