Adding some additional thoughts to summarize the thread:
- 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
- Basic Progress Monitoring (Quick Hack)
As a simple debug aid, you can spawn aforeverloop in therun_phasethat 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.
-
Advanced Monitoring with
uvm_heartbeat
Theuvm_heartbeatmechanism provides a more structured way to detect activity or stalls in specific components. It can help identify the exact source of a hang. -
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.