SystemVerilog Race Condition Challenge Responses
As promised, here is my response to Siemens EDA’s SystemVerilog Race Condition Challenge.
Race #1 Blocking and non-blocking assignments
byte slam; bit dunk; initial begin forever begin @(posedge clk); dunk = ~dunk; slam += dunk; end end always @(posedge clk) basket <= slam + dunk;
Race #1 must be the number one most common race condition in Verilog/SystemVerilog. Hardware designers may be more familiar with this race, but verification engineers must deal with this as well. When you have multiple threads or processes running in parallel and they are all synchronized to the same event (a clock edge), there is a race between reading the old value or the updated value from a blocking assignment. That’s why you must always use a non-blocking assignment when one process writes, and another process reads the same variable synchronized to the same clock. Then you’re guaranteed to consistently read the previous value. Most of the code examples here have this problem in common
Race #2 Unknowns at initialization
logic pong; initial begin fork forever begin @(posedge clk); if (pong) ping = 0; else ping = 1; end forever begin @(posedge clk); if (ping) pong = 0; else pong = 1; end join_none end
This is basically the same as Race #1. Also, the way this is coded, the unknown values get treated the same as if they were 0. That’s not always the case if you tried to implement this using ping = !pong; Then everything would remain unknown.
Race #3 Procedural and continuous assignments
byte colours, stripes, bouncy; always @(posedge clk) stripes += 1; always begin @(posedge clk); colours += 1; beach_ball = bouncy; end assign bouncy = colours && stripes;
Continuous assignments behave as independent processes, and there’s no deterministic order of execution between any process. Whenever right-hand side operands of a continuous assignment change, there’s an assignment to the left-hand side. But if another process is making changes to those operands there’s no guarantee when the left-hand side updates either before or after the procedural assignment to beach_ball. Note that all the accumulate assignment operators like += or ++ are just shortcuts for blocking assignments. There are no non-blocking equivalent shortcuts, so you must expand it out:
always @(posedge clk) stripes <= stripes + 1;
Race #4 Incomplete sensitivity list
bit score; byte fieldgoal, touchdown; byte down; always @(posedge clk) begin if (down < 4) begin score <= 1; fieldgoal <= fieldgoal + 3; touchdown <= touchdown + 7; down <= down + 1; end else begin score <= 0; down <= 0; end end always @(score) football = fieldgoal + touchdown;
I wouldn’t call this a race, just bad coding. In the earliest versions of Verilog, it was up to you to figure out the sensitivity list for an expression to mimic the behavior of a continuous assignment in an always. Even though this code makes an assignment to score every clock cycle, its value only changes for one half the clock cycles. So, it misses changes to fieldgoal and touchdown. That changed in Verilog-2001 with always @* and further improved with always_comb in SystemVerilog
Race #5 fork/join* that don’t consume time
bit shot_put; bit javelin; initial begin @(posedge clk); fork shot_put = $random(); javelin = $random(); join_none @(shot_put or javelin) throw = (shot_put || javelin); end
This is not a race. The processes inside a fork/join_none are not supposed to start until its parent process suspends or terminates. This code will calculate throw based on the initial values for shot_put and javelin, which are 0, not the values from $random(). Finally, stop using the deprecated $random() with its poor distribution/stability, and switch to $urandom_range(1).
Race #6 assignments in more than 1 thread
bit single, double, triple, homerun, cycle;
initial begin
forever begin
@(posedge clk);
single = $urandom_range(0,10) > 1;
double = $urandom_range(0,10) > 2;
triple = $urandom_range(0,10) > 4;
homerun = $urandom_range(0,10) > 8;
end
end
initial begin
forever begin
#1 cycle = & { single, double, triple, homerun };
@(posedge clk);
end
end
always @(posedge clk) begin
#1 baseball = baseball + homerun;
if (cycle) begin
#0 cycle = 0;
end
end
I cringe whenever I see #0 or #1 sprinkled in code. It usually means the coder did not understand SystemVerilog scheduling semantics well enough and throws these in. In this case the race has been moved one timeunit (#1) away from the clock edge. The assignment to cycle occurs simultaneously to its reading in the always block.
Race #7 Edge sensitive events
bit [3:0] goal; always @(posedge clk) goal += 2; initial begin @(posedge clk); @(goal == 2) hockey = 1; end
This is another form of Race #1. One process is writing, and another process is reading the same variable. But here the read is an event control waiting the expression (goal==2) to change. So, depending on the ordering between the initial and always blocks, it either catches the rise from false(1’b0) to true(1’b1) on the first clock cycle, or the fall from true to false in the next cycle. Always use non-blocking assignments between synchronous processes as I explained in Race #1. And it is rare to use an expression in an edge sensitive event. You should use the following:
@(posedge clk iff (goal==2));
Race #8 Named events
event wicket, batsman; initial begin @(posedge clk); fork forever begin @batsman; repeat (cricket+1) @(posedge clk); ->wicket; end forever begin ->batsman; @wicket; cricket += 1; end join_none end
Named events are synchronization objects that can suffer from the same kinds of problems as in the previous Race #7. You must be waiting for an event before triggering it. If the second forever block triggers batsman before the first forever block starts execution, you get into a deadlock where the first forever block is deadlocked waiting for an event that was already triggered. You can solve this particular race by using non-blocking triggers ->> to batsman and wicket. I would make sure you have a very good understanding of SystemVerilog’s event scheduling algorithm before using named events.
Race #9 NBA functions
bit [3:0] bump, spike, side_out; function bit [3:0] set(bit [3:0] _bump); set <= _bump ^ (_bump << 1); endfunction initial begin forever begin @(posedge clk); bump += 1; spike = set(bump); side_out = bump < spike ? spike : 0; end end
This is a race where you always lose. If you use non-blocking assignments to the return of a function, or to the output arguments of any function or task, the current value gets copied out before the NBA has a chance to update the value. You must use blocking assignments here.
Race #10 Procedural force/release
byte pushups, situps, reps; assign situps = 3 + pushups; always @(posedge clk) reps <= reps + 1; always begin @(posedge clk); pushups += reps; force situps = 0; @(posedge clk); release situps; muscles = pushups + situps; end initial #300 $finish(); endmodule
This is the same as Race #3. All continuous assignments are independent concurrent processes. You cannot depend on their order of execution within the same time region.
And that’s the conclusion of our little race condition challenge. I hope you were able to get something out of it. By the way, these code fragments all come from real customer designs that we’ve seen in the last year or so.
-dave_rich 🧔🏻
Comments