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.
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.
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.