UVM blocking assignment race conditions

1.7k views Asked by At

I have a doubt about race conditions in SystemVerilog, especially in UVM. In the standard case what we have is multiple drivers that drive our dut in the same front of the clock, generating some function calls in the scoreboard. These calls are simultaneous, and it is realistic that they check/modify some shared variables in the golden reference model. If these operations would be done with non blocking assignment there would be no problem, but with blocking assignment there could be race conditions. Which is the best way to overcome this problem? To implement the golden reference model not in a class? Thanks in advance

an example of pseudocode of scoreboard could be:

function void write_A(input TrA A);
    if(GRF.b >= 100 && A.a==1)
        GRF.c = 1;
endfunction

function void write_B(input TrB B);
    GRF.b+=B.b;
endfunction

Of course the result depends on the order of execution of these two functions, which is unknown. One can solve with some synchronization mechanism, but things become harder with many write parallel functions. Using non-blocking assignment would make the situation way more clear and simple...maybe a solution could be to have all members of GRF as static?

2

There are 2 answers

0
Ray Salemi On

The problem here is that you're trying to simulate RTL behavior using behavioral code. You are using multiple functions in multiple threads and calling them all on the same clock edge in a random order. There is no solution to this problem other than enforcing an order upon your operations.

The easiest way to do this is to combine all the @(posedge clk) threads in your scoreboard into one thread. This will force you to call the functions in the same order every time.

So instead of

@(posedge clk)
  write_A(A);

@(posedge clk)
  write_B(B);

You have

@(posedge clk) begin
  write_A(A);
  write_B(B);
end

The latter code will run the same way every time.

0
Ankit On

Race condition is created just because of expression or assignments are try to access same signal at a same time.

If two signals try to access same signal at different time stamp then user can remove race condition.

Actually code is written in verilog or system verilog is execute in different time region like active region, reactive region.

Race condition can be removed using following things.

(1) Program block

(2) Clocking block

(3) Non blocking assigment

Before program block and clocking block race condition is removed using non blocking assignment.

As I explained above statement written in verilog code or system verilog code is not execute code in single time same. There are different region in which specific syntax is executed by tool.

Here I mainly talked about Active and Reactive region. Active region consider continuous assignments, blocking assignments. Reactive region consider LHS of non blocking assignments are evaluated in this region.

First active region is evaluated then reactive region is evaluated.

So before program block to remove race condition verification engineers take care of this things(regions of execution).

Now in system verilog there are many other regions are added like prepone region, observed region, postpone region.