Hi,
currently I am trying to figure out how race conditions between the DUT and the UVM environment are prevented. Assume the DUT is providing an update of its outputs whereas these outputs are tracked by a UVM monitor. The DUT updates its outputs according to a clock defined inside the top module of the UVM environment. Additionally, the monitor also observes the DUT outputs according to the same clock. As far as I know both things, UVM environment and the DUT, are executed inside the active region and therefore I would expect a race condition in that case? The shared clock event leads to an update event and an evaluation event whereas the order of these events is arbitrary.
A “program” was used to address this issue in the beginning of SystemVerilog usage. Clocking blocks inside the interfaces which are connecting DUT and UVM environment can also solve the problem. However, I haven’t seen both things in the examples here?
In reply to Stechbeitel:
Finally there is no absolute need to use a clocking block or a program to prevent your testbench/DUT system from race conditions. I have never used in any of my UVM tesstbenches both of them. Most designs are working on 1 edge. I’m driving the design on the rising edge (driver) and observing on the falling edge (monitor). If you have a VHDL DUT, then you do not face the race conditions.
In reply to chr_sue:
Hi chr_sue,
Can you explain how racing happen between DUT and TB? I am not sure to understand why we have race condition. Lets say, DUT drives output at rising adge clock, if monitor can catch the value at the same clock, it will be catched at the next clock. Then why race happen?
Thanks
In reply to chris_le:
It is not explained in a few words. In general it is caused by the Event Scheduler. SystemVerilog adds additional regions to the Verilog Event Scheduler to avoid the races and you can take care by clean coding. I found an interesting article by Cliff Cummings:
http://www.sunburst-design.com/papers/CummingsSNUG2006Boston_SystemVerilog_Events.pdf
In reply to chr_sue:
Thanks so far for the input. If the driver applies the values in a non-blocking way I would expect no race at all between monitor and driver. I am just concerned to read values from the monitor which are driven by the DUT based on the same event. Of course, adding a delay in reading the values of the DUT is possible but sounds a bit like a workaround. Its unclear to me why a language construct like the program is removed since it saves people from having these issues.
Could you explain how VHDL differs from Verilog DUTs regarding these race problematics?
In reply to Stechbeitel:
VHDL does not know problems like race conditions at all because of the tick-delay approach.
In my eyes the races are caused by the blocking and non-blocking assigments in Verilog/SystemVerilog. SV is adding re-active area in the scheduler. This minimizes also the appearance of races.
See the SV event scheduler (figure 4) in the paper I was referring.
In reply to chr_sue:
VHDL does not know problems like race conditions at all because of the tick-delay approach
There need to be a synchronization between UVM and VHDL DUT anyways?
If signals change in VHDL DUTs, the senstive processes will execute which again can cause signal updates followed by additional process executions and so on. The DUT is stable if all these so called delta cycles are processed. However, race conditions are only prevented if the UVM environment reads the VHDL outputs AFTER the delta cycles are executed. And this is where the program block comes into play which uses the reactive area in the event scheduling.
Because the program block is not used any longer, I can’t see a reason why VHDL DUTs are save in that way.
But I agree on Daves Blog, it does not help that much if only a a subset of possible races are covered by the program block. In principle I am fine with using clocking blocks but
at the time I have to react on DUT outputs concurrently, they don’t work any longer.