Per SV LRM, a time slot is divided into “active-region-set” - “observed” - " reactive -region -set" , and all the RTL related events are finished within “active-region-set”, properties and clocking block are evaluated in observed region, while program-related events are done in “reactive-region-set”. Then how about class-related events?
I’m trying to comprehend with the classic UVM environment as an example. Inside UVM driver, we usually have non-blocking-assignments to virtual interface, and inside UVM monitor, we usually have transaction created by probing the virtual interface.
my question:
In which region are the assignments inside uvm driver being finished? “active-region-set” or “reactive_region-set”
In which region are the probing of virtual interface in UVM_MONITOR gets finished? is it “observed region”?
what’s the difference between active region and inactive region inside “active-region-set”? per LRM, “The Inactive region holds the events to be evaluated after all the Active events are processed.” why it is called “inactive” region then?
In reply to Jeff_Li_90:
There is nothing magical about UVM and clocking regions, as things work the same way as as in RTL designs. The only exception is if one use clocking blocks.
Per 1800’2017 on clocking blocks: 14.13 Input sampling
All clocking block inputs (input or inout) are sampled at the corresponding clocking event. If the input skew is not an explicit #0, then the value sampled corresponds to the signal value at the Postponed region of the time step skew time units prior to the clocking event (see Figure 14-1 in 14.4). If the input skew is an explicit #0, then the value sampled corresponds to the signal value in the Observed region. In this case, the newly sampled values shall be available for reading at the end of the Observed region processing. If upon
processing the Reactive region, the simulation must process Active events without advancing time (thereby executing the Observed region more than once), clocking inputs sampled with #0 skew shall not be resampled unless a new clocking event occurs in the active region set.
In reply to ben@SystemVerilog.us:
Hi Ben,
Do you know what region would sv force be performed in?
I was using UVM_HDL_FORCE/RELEASE and noticed an race condition between an rtl blocking statement and assertions on the same rtl signal. I think due to assertions being sampled(pre-poned) before the PLI force/release(pre-active?), which is before active region rtl assignment.
Made me curious how regular sv force worked, but couldn’t find much on it.
Thanks
Hi Dave,
Thanks for the quick reply. I had missed that section 4.9.2. So the short answer is that it would be the Active Region? Which would also create race condition.
In my case it seems like at least using UVM_HDL_FORCE/RELEASE was deterministic, but it would always result in incorrect latching behavior because the seemingly synced forces actually change value before blocking assignments.
My guess is that UVM_HDL_FORCE uses PLI cb to implements the force statements, if you check LRM figure 4.1 posible PLI region for this might be Pre-Active or Pre-NBA. There’s not much material online for this. But this might explains the deterministic behavior of UVM_HDL_FORCE/RELEASE.