The UVM 1.2 User's Guide describes an agent with a monitor and, when active, a driver and sequencer. A checker, coverage collector or scoreboard may live in or outside that agent. Sequences describe stimulus, the sequencer arbitrates items and the driver converts them to interface activity. The monitor must reconstruct what was observed rather than treating the sequence's intended item as a completed transfer.
An active agent owns stimulus on its assigned connection; a passive agent observes without driving it. Either arrangement can occur at block, subsystem or chip level. A real manager and an active replacement manager must not both drive the same signals. These examples borrow the architecture vocabulary; the executable examples below are plain SystemVerilog and require no UVM library.
What to notice
The monitor's input is observed interface activity, not the sequence item's intended completion.
The scoreboard needs its independent expected result as well as observed events; this figure shows only the monitor-side evidence path.
The DUT-interface-to-monitor observation path, interpreted with the interface's sampling and acceptance rules.
Intent is not accepted work
CPU0 intends a single-beat write of LEN_BYTES=16 at 0x4000_0008. Outside reset, the monitor samples the actual AXI and APB boundaries. No target error is injected in this example.
View | Observed fact | What it may conclude |
|---|---|---|
Sequence | Write item requested | Stimulus intent exists; no hardware acceptance established. |
Driver | WVALID=1, WREADY=0 | A data beat is offered and stalled; preserve payload. |
AXI monitor | WVALID && WREADY | One W beat accepted; retain it even if AW arrives later. |
APB monitor | PSEL && PENABLE && PREADY, PSLVERR=0 | One successful peripheral access completed. |
AXI monitor | BVALID && BREADY | One response accepted; compare it with captured request/target evidence. |
Not as evidence that the register changed. Maintain prediction separately from observed acceptance and target completion. A driver or bridge may still be stalled, reset or return an error. Compare the intended operation with the actual boundary events.
A VIP pass means its enabled checkers observed no violation for the monitored signals, interval, configuration and assumptions. It does not by itself establish unobserved protocol behaviours, functionality, the system address map, firmware configuration or cross-interface ordering.
A block-level pass followed by a chip-level failure means the existing evidence did not cover the failing condition. Compare boundaries, configuration, traffic, resets, clocks, power states, bridges and reference-model assumptions before calling it an integration gap or a VIP defect.
Configure VIP to match implemented spec version and feature subset.
Match observed widths and supported features to the DUT; give monitors enough capacity for the allowed outstanding work or explicitly constrain the exercised subset.
Choose active or passive roles from who owns stimulus at that boundary; chip-level environments can use either when the connection and ownership contract permit.