UVM Simulation is not ending

[AlexMatz]

Hello,

I have a UVM simulation that runs many sequences which are config sequence, ptp sequence, and data sequences. However there have been times where my UVM is not ending. I know that is most likely from objections not being dropped. I am looking for something that will notice that the sim is not ending and will error the simulation.

I need this because I use cicd to auto run my tests and cant just let it keep running forever.

Thanks in advance.

[dave_59]

Pre-processing before UVM_TIMEOUT

In reply to hctseng: My recommendation is to not have any objections in the scoreboard to prevent the scenario that you are seeing. Instead, you should end the test when all of your sequences have completed, set the drain_time appropriately to allow all transactions to complete in the DUT, then query the scoreboards to determine if they have accounted for everything that they expected to see. If the scoreboards haven’t seen all of the expected transactions, they can then generate an error.

[AlexMatz]

While this sounds good for that type of issue, what if there is something like a ready that is dropped, making it so that my driver or monitor is stuck in a forever loop waiting for the valid/ready handshake?

[dave_59]

The simplest approach, as discussed earlier in the topic link I provided, is setting a timeout on a per test basis.

Another approach is to use uvm_heartbeat. This approach requires knowledge of how to determine if the test is making progress by counting the number of objections raised or lowered over a specific period. This is going to be very specific to your testbench.

[MichaelP]

Adding some additional thoughts to summarize the thread:

1. Use a Global Timeout
   All tests should include a runtime guard using a global timeout to avoid endless hangs.
   This can be done via:

• The command-line plusarg:
  +UVM_TIMEOUT
• Or programmatically via: set_timeout

2. Basic Progress Monitoring (Quick Hack)
   As a simple debug aid, you can spawn a forever loop in the run_phase that periodically prints a message like "test progress: $time" to the log with a large delay between prints (to prevent log flooding).

• If the message continues to appear, the test is still making progress.
• If it stops, it may indicate an infinite loop in your testbench.

3. Advanced Monitoring with uvm_heartbeat
   The uvm_heartbeat mechanism provides a more structured way to detect activity or stalls in specific components. It can help identify the exact source of a hang.

4. Watchdog Timers at Points of Interest
   Addition of watchdog timers around critical points in your design or testbench, such as:

• Interfaces which are silent, although need to be active, e.g. ready/valid interface which is silent for a very long time should issue error/warning after reaching a timeout.

• Specific internal signals in DUT, to see forward progress of DUT’s flows.

  These watchdogs should be reset based on expected activity (e.g., transaction observed). If not reset in time, they can trigger an alert or error.
  Each watchdog could be separate/orthogonal from others.

[chr_sue]

Using a timeout is only one option and I believe it is not the best. There seems to be a weakness in your testbench either with the usage of objections or any other functional weakness where your simulation runs in a forever loop. In my eyes it is worth to identify and remove this weakness. Can you give us more details about your testbench, like usage of objections.

[AlexMatz]

I tried using the UVM_Heartbeat. I have multiple sequences that run, and tried the different modes of the Heartbeat. If my understanding is correct, te ANY active wasn’t failing as long as one HB objection was raised, however I have a PTP interface that is always sending messages. If I include this for HB checking then if another interface hangs it will not be detected since the PTP will keep raising and dropping objections. If I don’t include it, maybe the PTP hangs and it will not be caught.

I am going to try and use some watchdog/timeout methods.

Sue when you say the usage of the objections what do you mean? The way I am using them now is at the beginning of run phase in driver and monitor I raise and objection and then drop the objection when I am done processing. I am happy to give more info, I just don’t know what you mean exactly.

[chr_sue]

Using objections in the drivers and the monitors is not really a good approach. And it complicates the debugging of code issues. Recommended is to raise/drop the objections in your test. This minimizes the active objections in your testbench and makes the debugging easy.