I am implementing a verification environment where the Monitor samples and sends interface data to the Scoreboard strictly upon edge changes (not constantly over time). Because of this event-driven behavior, the Scoreboard cannot natively detect if the interface has completely locked up or gotten “stuck” mid-simulation.
To solve this, I need to implement an inactivity watchdog timer inside the Scoreboard to track simulation time and trigger an error if too much time passes without a transaction.
Problem Statement:
Since a watchdog requires tracking simulation time and waiting for events (#timeout or @activity_event), this logic cannot reside inside zero-time TLM write() functions. I need to use the time-consuming run_phase task within my scoreboard component to execute this tracking loop in the background.
Is utilizing the run_phase in this specific manner considered a clean architectural practice for a UVM Scoreboard when handling interface deadlocks/stuck conditions?