Time elapsed in UVM code base.

[venravi]

Hi,

While migrating code from UVM 1.0ea to UVM 1.0p1 I had noticed a change that was unrelated to the behavioral code in place.

The issue was that a signal value that was used by behavioral code at clock edge was valid for UVM 1.0ea and hence the behavioral code used to work correctly.

With UVM 1.0p1 the same behavioral code had to capture the signal value at posedge because time was lapsed(delta cycles) between the point the get_next_item/try_next_item block is used in the driver. If the signal was not captured before try_next_item/get_next_item step the methods/functions/tasks which use the signal used the updated value(instead of the value at posedge)the incorrect value and hence the behavioral code was affected.

Does anyone know of time being elapsed in UVM code base that behavioral code needs to be sensitive to?

I have workaround(capture the signal at posedge before try_next_item) now and it works but was wondering about other cases that I need to care about.

Ravi

[jadec]

You can use clocking blocks for your interfaces to prevent this kind of race condition.