Simulation is blocking at get_next_item()

UVM
1

I have a simulation that is blocking at get_next_item() at some point. More specifically, it’s a scenario where I simulate some traffic (driver able to pull next sequence item from sequencer each time), apply a global reset, then resume traffic. It’s when coming out of the reset application that the first time the driver calls get_next_item(), the simulation gets stuck.

My question is how can I debug this? I’m using the built-in UVM 1.1d library, so I cannot instrument the source code.

TIA

2

Hi

Please post the code snippet for further analysis.

Thanks,
Vikas Billa

3

If you are calling reset() while you have a transaction being processed by the driver, does the driver terminate the transaction correctly? Or does it abort the transaction and then try to get another transaction? The sequencer can only have one outstanding transaction and won’t provide another transaction until the prior one is completed.

4

In reply to vikas billa:

The code is pretty standard as far as I can tell – start_item/finish_item in the sequence, standard get_next_item/item_done handshaking in the driver. I traced my code to determine that the blockage is happening somewhere within get_next_item. So, my question is really about how I can debug into the UVM library, especially one that is built into the simulator, not asking for help to fix my application code.

Hope that makes sense.

5

In reply to cgales:

The reset is applied in the application code. Specifically, I have my own routine that just triggers the system reset line for some number of cycles. When this is applied, the sequencer/driver has been quiet for perhaps over a thousand clocks, so it’s not a problem with resetting during a transaction. The last transaction has certainly finished normally before the long wait then reset cycle.

I’m more interested in some ways that I can debug into the UVM library to find clues as to why get_next_item is stalling for me.

6

In reply to manning999:

get_next_item() is non-blocking, so your time should still be advancing. Is this still the case? Are you sure that your sequences are still running?

Most simulators have interactive debuggers. Put breakpoints in your sequences where you are calling start_item/finish_item. These two functions bracket the get_next_item() call.

7

In reply to cgales:

Time continues to advance. I should have rephrased it. Somewhere within get_next_item it continues to wait for something, so it doesn’t block time but blocks the procedure from returning back to the driver. This is after start_item had been executed, but before finish_item could be called (nothing between start_item and finish_item in the sequence).

Yes, I’m starting to insert breakpoints within the simulator to try to better understand what’s going on. Thanks for that tip.