Designing a reset-aware OVM testbench

The monitor
Monitor
The monitor is a passive component that resides in an agent, and monitors bus transactions on the pin interface to convert them to transaction level and send them out to the rest of the testbench for consumptions. That said, the monitor doesn’t need to wait for reset deassertion at the beginning of simulation since it is guaranteed there will be no transactions driven on the bus during reset assertion as that was modeled in the driver.

The monitor code changes are very similar to those made to the driver, yet somehow simpler. Below is an example for a monitor that will continuously monitor the bus until reset is asserted. Once reset is asserted, the monitor will drop the transaction it was handling and go back to monitoring a new transaction.

It may be a testbench architecture requirement that the monitor observes and sends the incomplete transaction to its subscribers if needed when reset is asserted, but for the code shown above, the monitor drops the transaction. The code will have to change a little to handle this case. One solution is to make the object handle of the transaction the monitor_bus() method is building up visible outside the method. Then, before disabling the fork process when reset is asserted, clone this object and send it to the analysis port.

In addition to monitoring the reset assertion, the monitor_reset_assertion() task will also inform the agent’s components of a reset using the OVM event pool. This event will be used later by other components of the agent to make decisions and take actions on the triggering of the reset event. Following is an example code for the monitor_reset_assertion() task.

 
Note that in order to be able to reference the agent static event pool, the agent class needs to be forward defined before the monitor uses it.