1

Avoidance and Static Determination of Races in Verilog Designs Internship Report (Summer 2008)

Submitted by

Kundan Kumar 05EC1019 Department of Electronics and Electrical Communication Engineering Indian Institute of Technology, Kharagpur

Under the guidance of

Ms Rudra Mukherjee Senior Manager, Mentor Graphics, India

2

TABLE OF CONTENTS I.

INTRODUCTION……………………………………………………………………3 Race Conditions ………………………………………………………………..3 Race Conditions in Verilog …………………………………………………….3

II.

GUIDELINES TO AVOID RACE CONDITIONS IN VERILOG DESIGNS …….4 Verilog Coding Guidelines ……………………………………………………...5

III.

STATIC DETERMINATION OF RACES IN VERILOG DESIGN…………...…..6 Race Graph ………………………………………………………………………7 Race Graph for HDL Designs……………………………………………………8 Write-Write Race Detection Algorithm ………………………………………....9 Example of Write-Write Race Detection …..…………………………………...12 General Race Detection Algorithm …………………………………………......13 Read-Write Race Detection Algorithm ………………………………………....14

IV.

CONCLUSION………………………………………………………..……………...14

V.

FUTURE DIRECTIONS……………………………………………...………...…….14

VI.

REFERENCES………………………………………………………...………...……15

3

I.

INTRODUCTION

RACE CONDITIONS A race condition in digital electronic circuit occurs where the output to input response time changes according to the inputs passed to it. In simple words a race condition is a case where an expected event does not occur. As the inputs change state, a finite delay will occur before the output changes, due to the physical nature of the electronic system. For a brief period, the output may change to an unwanted state before settling back to the designed state.

The circuit shown in the figure1 consists of a two input AND gate fed with a logic signal A on one input and its negation, A’, on another input. In theory, the output (A AND A’) should never be high. However, if changes in the value of take longer to propagate to the second input than the first when A changes from false to true, a brief period will ensue during which both inputs are true, and so the gate's output will also be true. Let the delays associated with the NOT and the AND gates are t1 and t2 respectively. As shown in the timing diagram, A’ changes its value from low to high at time t1. So, both A and A’ are high for a brief time interval of t1. Since the AND gate also has a delay of time t2, the output goes high for a period t1 at time t1+t2. This explains a typical example of race in a logic circuit.

Figure1. An example of a logic circuit having race condition. Race conditions create such glitches in a logic circuit and can cause it to perform in an undesired manner. So, care should be taken while designing a logic circuit and races should be avoided as much as possible. Races are divided in to two categories, critical and non-critical. A critical race occurs when the order in which internal variables are changed determines the eventual state that the state machine will end up in. A non-critical race occurs when the order in which internal variables are changed does not alter the eventual state. In other words, a noncritical race occurs when moving to a desired state means that more than one internal state variable must be changed at once, but no matter in what order these internal state variables change, the resultant state will be the same.

RACE CONDITIONS IN VERILOG A Verilog race condition occurs when two or more statements are scheduled to execute in same simulation time-step, would give different results when the order of statement execution is changed, as permitted by IEEE. To understand the Verilog race condition, the concept of blocking and nonblocking assignments in Verilog must be understood clearly. If a current statement contains a blocking procedural assignment then the next statement will be executed after the execution of the current statement (in the next step of the simulation). On the other hand, if a current statement contains

4 a non-blocking procedural assignment then the next statement will be executed at the same time (in the same step of the simulation). Execution of blocking assignments can be viewed as a one-step process: 1. Evaluate the RHS (right-hand side equation) and update the LHS (left-hand side expression) of the blocking assignment without interruption from any other Verilog statement. Whereas, Execution of nonblocking assignments can be viewed as a two-step process: 1. Evaluate the RHS of nonblocking statements at the beginning of the time step. 2. Update the LHS of nonblocking statements at the end of the time step. A problem with blocking assignments occurs when the RHS variable of one assignment in one procedural block is also the LHS variable of another assignment in another procedural block and both equations are scheduled to execute in the same simulation time step, such as on the same clock edge. If blocking assignments are not properly ordered, a race condition can occur. When blocking assignments are scheduled to execute in the same time step, the order of execution is unknown. To illustrate this point, Verilog code of a Feedback oscillator with blocking assignments is taken as an example.

Module fbosc1 (y1, y2, clk, rst); output y1, y2; input clk, rst; reg y1, y2; always @(posedge clk or posedge rst) if (rst) y1 = 0; // reset else y1 = y2; always @(posedge clk or posedge rst) if (rst) y2 = 1; // preset else y2 = y1; endmodule According to the IEEE Verilog Standard, the two always blocks can be scheduled in any order. If the first always block executes first after a reset, both y1 and y2 will take on the value of 1. If the second always block executes first after a reset, both y1 and y2 will take on the value 0. This clearly represents a Verilog race condition. It is very important to identify and avoid such conditions in a Verilog design to simulate and synthesize it correctly.

II.

GUIDELINES TO AVOID RACE CONDITIONS IN VERILOG

In order to avoid race conditions, it is important to schedule the Verilog Blocking and Nonblocking assignments properly. A blocking assignment gets its name because a blocking assignment must evaluate the RHS arguments and complete the assignment without interruption from any other Verilog statement. The assignment is said to "block" other

5 assignments until the current assignment has completed. A nonblocking assignment gets its name because the assignment evaluates the RHS expression of a nonblocking statement at the beginning of a time step and schedules the LHS update to take place at the end of the time step. Between evaluation of the RHS expression and update of the LHS expression, other Verilog statements can be evaluated and updated and the RHS expression of other Verilog nonblocking assignments can also be evaluated and LHS updates scheduled. The nonblocking assignment does not block other Verilog statements from being evaluated. The difference between the two can be easily understood by the example: 1. Blocking Assignment

begin a = 1; #10 a = 0; #5 a = 4; End During the simulation, this block will be executed in 15 time units. At time 0 the ‘a’ variable will be 1, at time 10 the ‘a’ variable will be 0, and at time 15 (#10 + #5) the ‘a’ variable will be 4. 2. Nonblocking Assignment

begin a <= 1; #10 a <= 0; #5 a <= 4; End During the simulation, this block will be executed in 10 time units. At time 0 the ‘a’ variable will be 1, at time 5 the ‘a’ variable will be 0, and at time 10 the ‘a’ variable will be 4. Now, the feedback oscillator, which was proved to have race when designed with blocking assignments, can be implemented without any race condition using nonblocking assignments.

Module fbosc2 (y1, y2, clk, rst); output y1, y2; input clk, rst; reg y1, y2; always @(posedge clk or posedge rst) if (rst) y1 <= 0; // reset else y1 <= y2; always @(posedge clk or posedge rst) if (rst) y2 <= 1; // preset else y2 <= y1; endmodule

6 Now, according to the IEEE Verilog Standard, the two always blocks can be scheduled in any order. No matter which always block starts first after a reset, both nonblocking RHS expressions will be evaluated at the beginning of the time step and then both nonblocking LHS variables will be updated at the end of the same time step. From a user’s perspective, the execution of these two nonblocking statements happen in parallel.

VERILOG CODING GUIDELINES While coding Verilog designs, following guidelines should be followed to make the design free of race conditions. 1: When modeling sequential logic, nonblocking assignments should be used. 2: When modeling latches, nonblocking assignments should be used. 3: When modeling combinational logic with an always block, blocking assignments should be used. 4: When modeling both sequential and combinational logic within the same always block, nonblocking assignments should be used. 5: Blocking and nonblocking assignments should not be mixed in the same always block. 6: Assignments to the same variable should not be made from more than one always block. 7: $strobe should be used to display values that have been assigned using nonblocking assignments. 8: Assignments using #0 delays should not be made.

III. STATIC DETERMINATION OF RACES IN VERILOG DESIGNS A race condition is defined as a situation where reading a variable may result in one of several values non-deterministically. There are two types of races in a Verilog design, read-write race and write-write race (or multiple drivers). A read –write race arises when a variable is read and written both at the same simulation step. A write-write race arises when a variable is written by two assignments at the same simulation step. There are two common ways to predict races in a Verilog design. 1. By applying a test bench 2. Statically (by looking at the design) In the first method, we simulate the design by applying a test bench (written in the same design language) and predict the races on the basis of the result (output). The biggest problem with this method is the writing of the test vectors, which is very costly and time consuming. To determine all the races, one needs to write an exhaustive set of test vectors for a given design. If the right test vectors are not provided, all the potential races can not be determined. In the second

7 method, races are predicted by just analyzing the design. In this report such an algorithm has been discussed which applies the concept of race graphs to predict the races in the design. There are two benefits of static determination of races. 1. No test vectors are required. 2. All potential races can be determined. Usually the race arises when two write statements or a read and a write statement is triggered simultaneously in a design. In the method discussed in the report, race graph has been used to represent races in contrast to the conventional methods, where a race is confined to a signal at a particular time point.

RACE GRAPH A race graph contains the following:

A source node i.e. the object starting the race; A target node i.e. the object being raced for; Two anchor nodes i.e. the objects competing for the target object; Triggering edges i.e. edges, each of which links an object A to another object B, where executing A first results in B being executed next.

A typical example of a race graph is shown in the figure2. In the figure, O1 to O7 are objects. O1 is the source object, O7 is the target object, and O4 and O6 are anchor objects. The race is started from O1. This is why it is called the source node. While O1 is executed, O2 and O3 are triggered and executed via links E12 and E13 respectively. Executing O2 then triggers the execution of O4. At the same time, executing O3 triggers the execution of O5, and executing O5 triggers the execution of O6. Both O4 and O6 are competing for the common target object O7. This is why O4 and O6 are called anchor objects and O7 is called the target object.

A realistic example could be O7 being a register in a circuit and O4 and O6 being two computing elements which are trying to write to the common register O7 simultaneously (writewrite race). Figure2. A race Graph

8 RACE GRAPH FOR HDL DESIGNS To detect a race in a logic design, the circuit is first translated into a directed graph, referred as a design graph. In this graph, there are two kinds of nodes namely computing nodes and data nodes. Computing nodes are computing elements, such as an always block in Verilog designs. Data nodes are storage or wiring elements, such as a reg in Verilog designs. Edges are used to link computing nodes and data nodes to denote signal flows and triggering relations. A Verilog always block provides an example. Suppose there is an always block such as the following:

always @(a) b=a; In this example, the design generates: One computing node B1 for the always block; One data node B2 for symbol "a"; One data node B3 for symbol "b"; One edge from B2 to B1 because when "a" is changed, B1 must be executed; and One edge from B1 to B3 because after B1 is executed, the value of "b" may change. Now, an example of a Verilog design is shown below and its design graph in figure 4.

module foo(clk, a, b); input clk; output a; Input b; wire dl, d2; reg cl, c2, a; always @(posedge clk) cl = b; always @(posedge clk) c2 = ~b; assign dl = cl; assign d2 = c2; always @(dl) a = dl; always @(d2) a = d2; endmodule

//1 //2 //3 //4 //5 //6 //7 //8 //9 //10 //11 //12 //13 //14 //15 //16

In the above example, symbol a is written at line 14 and line 15, which are triggered by line 11 and 12 respectively, which in turn are triggered by line 8 and 9 respectively, and which are sensitive to the value change of clk. That is, once clk is changed, both line 14 and 15 may be executed. However, it is not guaranteed whether line 14 or line 15 is executed earlier. This is called a potential race condition.

Figure4. Design Graph for the module ‘foo’

9

WRITE-WRITE RACE DETECTION ALGORITHM To detect write-write races, the following steps are followed. It will be generalized later to detect all the races: Target Selection Step First, a possible target node is chosen. In this example, suppose "a" (figure 4) is chosen as the target node. Anchor pair selection step Next, a pair of possible anchor nodes is chosen. In this example there are only two possible anchor nodes, i.e. node “15" and node “14”. Nodes “14” and “15” are hence the only possible pair. Backward Step Next, starting from each of the anchor nodes, the design graph is traversed in backward direction: Backward Traversal for Path 1 Traverse backward from Node "15" (one of the anchor nodes), and mark all the traversed nodes with "m1". The marked nodes are "15", "d2", "12, "c2", "9", and "clk". Backward Traversal for Path 2 Also, traverse backward from Node "14" (another anchor node). The traversal stops traversing down an edge when ever it visits a node which has been marked with "m1". Also, all the nodes that are traversed this time are marked with "m2". The marked nodes are "14", "d1", "11", "c1", "8", and "clk". Source Collection Step All the nodes that are marked with both "m1" and "m2” are the source nodes. In this example, the only source node is the node "clk". Forward Traversal Step Next, starting from a source node, the design graph is traversed in forward direction: Forward Traversal for Path 1 Traverse forward toward Node "15", over the nodes previously marked with "m1". The nodes and edges traversed constitute the first path of the race graph. Path Condition Collection and Verification for Path 1 Also, during the traversal the path condition is collected and verified aggregately. Whenever it is found that the path condition becomes always false, the traversal aborts and the process continues with the next possible source node.

10

Forward Traversal for Path 2 Traverse forward toward Node "14", over the nodes previously marked with "m2". The nodes and edges traversed constitute the second path of the race graph. Path Condition Collection and Verification for Path 2 Also, the path condition is collected and verified similarly as that for path 1. Single Path Condition Check A path condition is the aggregate conditions over a path of the design graph, such that when it is satisfied, executing the starting node of the path results in the execution of the ending node of the path. For example, consider the design of

always @(a or b) if (a == l'bO) c = b; always @(a or c) if (a == l'bl) d = c;

// B1

// B2

Conceptually, there might be a path from the first always block, (computing node B1), to signal "c", (data node "c"), then to the second always block (computing node B2), and finally to signal "d" (data node "6'). Note that to have "c=b” executed, "a==1’b0" must hold; and to have "d=c” executed, "a==1’b1" must hold. However, the path condition ((a==1’b0) AND (a==1’b1)) is always false. Therefore, there should be no such a path as stated. During race detection in the forward traversal stage, one can collect and verify the path condition aggregately, and abort the traversal accordingly. Any condition that can be used to rule out a race can be used as the path condition.

Single Path Condition Check Using Branch Conditions In this example, the conditions used are branch conditions. The term branch condition is used to mean the condition in an "if' statement or a "case" statement in most hardware description languages. In these statements, the execution branches to one part of the program or another part of the program. This is why the conditions in these statements are called branch conditions. Dual Path Condition Check The path conditions of the first and the second paths can also be combined together to check if the race is possible. Suppose traversing path 1 needs path condition 1 to hold, and traversing path 2 needs path condition 2 to hold. If condition 1 and condition 2 contradict each other, then the race is not possible. Dual Path Condition Check Using Branch Conditions When branch conditions are used as path conditions, the path conditions of the first and the second paths can also be AND'ed together to check if the race is possible. For example, suppose the first path's condition is "c==d", and the second path's condition is

11 "c! =d”. When these two conditions AND'ed together, the result is ((c==d) AND (c! =d)), which is FALSE. Therefore, there is no race in this situation. Dual Path Condition Check Using Non-Blocking Assignments There are various kinds of path conditions. They could be used to rule out false races that would otherwise be reported. For example, suppose during the forward traversal, it is found that the first path and the second path have different steps of non-blocking assignments. Then the race can be ruled out. This is another kind of path condition. Consider as an example of the Verilog code shown below.

module t(clk, a, b, c); input clk, b, c; output a; reg a, d, e; always @(posedge clk) e <= b; always @(e) a <= e; always @(posedge clk) d <= c; always @(d) a = d; endmodule

// // // // //

C1 C2 C3 C4 t

There is an otherwise write-write race to signal "a", startin-g from "clk". Path 1 takes the route "clk=>C1=>e=>C2=>a", and Path 2 takes the route "clk=>C3=>d=>C4=>a". However, to get "a" assigned along Path 1, it takes two steps or simulation cycles because there are two non-blocking assignments denoted by "=>" in the path. On the other hand, to get "a" assigned along Path 2 it only takes one step. As a result, assignments to "a" along Path 1 and 2 cannot happen at the same simulation cycle, and hence there is no race.

Race Graph Generation Step

If the race is not ruled out by the condition checks, then the result is a race graph. The first and the second paths, together with the target node, constitute the race graph. Some work can be done to improve the presentation of the race graph. For example, if a data node is between two Computing nodes, one can eliminate the data node, link these two computing nodes directly, and put the data node label as the new edge's label. By doing this, one gets the improved race graph as shown in the figure 5.

Figure5. The Improved Race Graph

12 EXAMPLE OF WRITE-WRITE RACE DETECTION Another example for the path traversal has been discussed for the design graph shown in the figure 6. In the Target Section Step, a data node is chosen. Suppose D10 is selected here. Next, in the Anchor Pair Selection Step, all possible anchors (for D10) are identified and each pair of anchors is selected in turn. In this case, there are only two predecessors of D10, so the only pair of D10's anchor nodes is C7 and C8. In the Backward Traversal Step, the process traverses backward from each of the anchor nodes to find the common source node. First, the process traverses backward from C7 (Backward Traversal for Path 1). The traversed nodes are marked with horizontal lines as shown in the figure 7. Next, the process traverses backward from C8 (Backward Traversal for Path 2). The traversed nodes are marked with vertical lines as shown in the figure 8. Note that the nodes which are marked by both horizontal lines and vertical lines are the source nodes (Source Collection Step). In this case, C4 and D4 are the source nodes. Next, the process starts from the source node C4 and traverses forward, performing the Forward Traversal Step, including its sub-steps. The traversed nodes constitute a race graph, as shown in the figure 9. The process then starts from another source node D4 and traverses forward, performing the Forward Traversal Step, including its sub-steps. The traversed nodes constitute another race graph, as shown in the figure 10.

Figure 6

Figure 7

13

Figure 9

Figure 8

Figure 10

GENERAL RACE DETECTION ALGORITHM The general race detection algorithm is described below.

do Target Selection; for each target t, do: do Anchor Pair Selection; for each anchor pair (a1, a2). do Backward Traversal (BT): do BT from al; do BT from a2; do Source Collection; for each source s, do Forward Traversal IFT): do FT and Single Path Condition Check for path 1; do FT and Single Path Condition Check for path 2; do Dual Path Condition Check; do Race Graph Generation;

14

READ-WRITE RACE DETECTION ALGORITHM To detect read-write races, it is only necessary to change the Anchor Pair Selection Step. All other steps are the same as the steps of detecting write-write races. When detecting read-write races, after a target node "D" is selected, the process does the following for the Anchor Pair Selection Step: Put in Set 1 all the computing nodes which read the target node. For example, for the following Verilog always block:

always @(b or c) a = b + c; If "b" is the target node, then this always block, i.e. a computing node, should be put in Set 1. Put in Set 2 all the computing nodes which write to the target node. For example, for the following Verilog always block:

always @(d or e) b = d + e; If "b" is the target node, then this always block, i.e. a computing node, should be put in Set 2. Select one node from Set 1 and another node from Set 2. These two nodes are the anchor pair selected.

IV. CONCLUSION In this report, various coding guidelines to avoid races and a method for improved race detection have been discussed. Following the coding guidelines discussed herein, 90-100% potential races can be avoided. The race detection method discussed herein detects races statically by analyzing the circuits, which are usually written in a Hardware Description Language (HDL), such as VHDL or Verilog. Compared with the pre-existing simulation approaches, this method has following two advantages: no test vectors are required and all the potential races can be detected.

V. FUTURE DIRECTIONS Using the above discussed algorithm, software can be created to create race graphs and detect races automatically in HDL designs without simulating it. The method discussed here can also be well applied for the designs written in the languages other than the HDL languages.

15

VII.

REFERENCES

[1]

Predko Myke, Predko Michel, “Digital Electronics Demystified: A Self-teaching Guide”, McGraw-Hill Professional, 2005

[2]

Cumming Cliffords E., “Nonblocking Assignments in Verilog Synthesis, Coding Styles that Kill!”, Sunburst Design, Inc.

[3]

IEEE Standard Hardware Description Language Based on the Verilog Hardware Description Language, IEEE Computer Society, IEEE Std 1364-1995

[4]

http://en.wikipedia.org/wiki/Race_condition.

[5]

Cumming Cliffords E., "Correct Methods For Adding Delays To Verilog Behavioral Models," International HDL Conference 1999 Proceedings, pp. 23-29, April 1999.

[6]

Ouyang Pel, “Race Condition Detection and Expression”, United States Patent, No. : 7,243,319 B2, Date: July 10, 2007

[7]

Spyrou, Athanasius W., “Method of finding a critical path in a circuit by considering the clock skew”, United States Patent, No. 5,608,645:, Date: April 3, 1997