AMBA AXI · Module 16

AXI Monitors

Build a passive AXI monitor that observes the five channels and reconstructs complete transactions from beats — sampling handshakes, matching write data to addresses and responses by ID, assembling read bursts to RLAST, and broadcasting transaction objects through an analysis port to scoreboards and coverage.

Assertions (16.2) check signal-local rules cycle by cycle, but the stateful rules — beat counts, per-ID ordering, data integrity — live at the transaction level, and to check them you first need to reconstruct transactions from the raw beats on the bus. That's the monitor's job. An AXI monitor is passive: it never drives the bus, only observes it, sampling the five channels' handshakes and assembling the scattered beats of each burst into a complete transaction object, which it then broadcasts to scoreboards and coverage collectors. This chapter builds the monitor — what it samples, how it matches write data to addresses and responses by ID, how it assembles read bursts, and how it publishes transactions through an analysis port — making it the bridge from the per-cycle world of assertions to the transaction-level world of scoreboards (16.4) and coverage (16.5).

1. The Monitor's Place and Passivity

A monitor sits at an AXI interface and only observes — it taps the signals, never asserts VALID/READY or drives any line. It reconstructs transactions and sends them out an analysis port to any number of subscribers (scoreboard, coverage, protocol log). Because it's passive, the same monitor works whether the interface is driven by a testbench agent or by real RTL, and multiple monitors can watch different points (manager side, subordinate side, interconnect ports) of the same path.

Figure 1 — the monitor's place in a UVM-style environment. The monitor passively taps the AXI interface (no driving), reconstructs transactions, and broadcasts them through an analysis port to subscribers — a scoreboard (correctness/ordering) and a coverage collector. The driver/sequencer drive the bus separately; the monitor observes the result. Passivity means it works identically on a testbench-driven or RTL-driven interface.

2. Sampling Beats on the Handshake

The monitor's atomic action is sampling a beat exactly when it transfers — on every cycle where VALID && READY is high for a channel. It captures the payload at that instant into a per-channel record. Nothing is sampled on stalled cycles, so the monitor sees exactly the beats that actually moved.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Passive sampling: capture each channel's beat on its completed handshake
task automatic monitor_run();
  forever begin
    @(posedge vif.aclk);
    if (!vif.aresetn) continue;
 
    // Write address beat
    if (vif.awvalid && vif.awready)
      capture_aw('{id:vif.awid, addr:vif.awaddr, len:vif.awlen,
                   size:vif.awsize, burst:vif.awburst});
    // Write data beat
    if (vif.wvalid && vif.wready)
      capture_w('{data:vif.wdata, strb:vif.wstrb, last:vif.wlast});
    // Write response beat
    if (vif.bvalid && vif.bready)
      capture_b('{id:vif.bid, resp:vif.bresp});
    // Read address beat
    if (vif.arvalid && vif.arready)
      capture_ar('{id:vif.arid, addr:vif.araddr, len:vif.arlen,
                   size:vif.arsize, burst:vif.arburst});
    // Read data beat
    if (vif.rvalid && vif.rready)
      capture_r('{id:vif.rid, data:vif.rdata, resp:vif.rresp, last:vif.rlast});
  end
endtask

This is the same VALID && READY transfer condition the assertions use — the monitor and the assertions agree on exactly when a beat exists.

3. Reconstructing a Transaction

Captured beats are scattered across channels and cycles; the monitor assembles them into a transaction. For a write: collect the AW (address/params), accumulate W beats until WLAST, then match the B response — tied together by AWID/BID. For a read: collect the AR, then accumulate R beats (each with its own RRESP) until RLAST, tied by ARID/RID. Outstanding transactions are tracked in per-ID structures so concurrent, interleaved bursts are reassembled correctly.

Figure 2 — reconstructing a write transaction from scattered beats. The monitor observes the AW beat (address, ID), then the stream of W data beats up to WLAST, then the matching B response (same ID). It assembles these into one transaction object — address, data array, response — and broadcasts it. Read transactions are assembled symmetrically from AR plus R beats to RLAST, matched by ID.

The reconstruction logic, sketched for the write side:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Per-ID outstanding write context, keyed by AWID
typedef struct { axi_addr_t addr; int len; data_t data[$]; bit have_aw; } wctx_t;
wctx_t wctx [int];                       // associative array, key = id
 
function void on_aw(aw_beat b);  wctx[b.id].addr = b.addr;
                                 wctx[b.id].len  = b.len;
                                 wctx[b.id].have_aw = 1; endfunction
 
function void on_w(w_beat b, int id);     // id from matching the open burst
  wctx[id].data.push_back(b.data);
  if (b.last) begin /* data phase complete; await B */ end
endfunction
 
function void on_b(b_beat b);             // B closes the transaction
  axi_txn t = build_write_txn(wctx[b.id], b.resp);
  ap.write(t);                            // broadcast completed transaction
  wctx.delete(b.id);
endfunction

(Matching W beats to the right open burst is the subtle part: AXI write data is in order per the address stream, so the monitor associates the in-progress W stream with the outstanding write — implementations track the current write burst and its ID accordingly.)

Each transaction therefore moves through a small lifecycle in the per-ID context, and tracking it per ID is what untangles concurrent, interleaved bursts:

Figure 4 — the per-ID transaction lifecycle in the monitor. An address beat OPENS a context (keyed by ID); data beats ACCUMULATE into it until the last beat (WLAST/RLAST); the response (matched by ID) CLOSES it, the assembled transaction is broadcast, and the context is freed. Because each ID has its own context (ideally a queue), interleaved and out-of-order bursts are reassembled correctly — same-ID in order, different-ID independent.

4. Broadcasting Through the Analysis Port

Once a transaction is complete, the monitor publishes it on its analysis port (uvm_analysis_port), which broadcasts to every subscribed component without the monitor knowing or caring who listens. This decoupling is what lets one monitor feed a scoreboard, a coverage collector, and a logger simultaneously, and lets you add subscribers without touching the monitor.

Figure 3 — the analysis-port broadcast. The monitor's analysis port (write()) publishes each completed transaction to all subscribers at once — scoreboard, coverage collector, protocol logger — via their analysis exports. The monitor is decoupled from the subscribers: it doesn't know who listens, so subscribers can be added or removed without changing the monitor. One observation, many consumers.

5. Common Misconceptions

Myths to unlearn

"A monitor can drive the bus when needed." No — a monitor is strictly passive; it only observes. Driving is the driver's job. A monitor that drives breaks the separation that lets it work on both testbench- and RTL-driven interfaces and risks corrupting the very traffic it's meant to observe.
"Sample the bus every clock cycle." Sample a beat only on its completed handshake (VALID && READY). Sampling on stalled cycles captures payload that didn't transfer (or captures the same beat repeatedly), corrupting the reconstruction.
"One transaction is on one channel." A write transaction spans three channels (AW, W, B) and a read spans two (AR, R); the monitor's core work is gathering across channels and cycles and matching by ID — not reading a single channel.
"You can ignore IDs when reconstructing." With multiple outstanding transactions, IDs are how you match data and responses to the right address; per-ID context is essential. Ignoring IDs reassembles interleaved bursts incorrectly.
"The monitor should check correctness itself." The monitor reconstructs and reports; the checking (data integrity, ordering vs. reference) is the scoreboard's job. Mixing reconstruction and checking in the monitor couples concerns and prevents reuse across checks.
"The monitor needs to know its subscribers." The analysis port decouples producer from consumers — the monitor broadcasts and doesn't know who listens. This is what lets you attach scoreboard, coverage, and logger independently and add more later without touching the monitor.

6. Debugging Insight

🔍 Debugging insight — monitor problems show as missing, malformed, or mismatched transactions

When transaction-level checks misbehave, the monitor is often the first suspect — and the symptoms point to where:

A transaction never appears at the scoreboard. The monitor didn't complete it — usually it missed WLAST/RLAST (so the burst never closed) or never saw the B/final R. Check the beat-accumulation and last-beat detection.
Transaction has wrong beat count / wrong data array length. Beats sampled on the wrong condition (not VALID && READY), or counted on stalled cycles. Confirm sampling is strictly on the completed handshake.
Data matched to the wrong transaction. ID matching is wrong — interleaved bursts with different IDs got cross-assigned. Check the per-ID context structures.
Response paired with the wrong transaction. BID/RID matching is wrong, or the outstanding context was deleted/created incorrectly. Verify the open/close lifecycle per ID.
Duplicate transactions broadcast. The completion condition fires more than once, or a context isn't cleared after broadcast. Confirm one ap.write() per completed transaction and that the context is deleted.
Monitor perturbs the bus. It's accidentally driving a signal (a non-passive bug) — the monitor must only read vif signals, never assign them.

Because the monitor feeds the scoreboard and coverage, a bug here masquerades as a scoreboard or coverage failure — so when transaction-level checks look wrong, verify the reconstructed transactions first (dump them and eyeball against the waveform) before suspecting the checker.

7. Verification Insight

✅ Verification insight — reconstruct independently, keep the monitor passive and check-free, and verify the monitor itself

The monitor is the source of truth for transaction-level verification, so its quality gates everything downstream. Three disciplines. (1) Reconstruct independently of the DUT — the monitor must derive transactions purely from observed bus activity, never from the DUT's internal state or the driver's intent, so that it provides a genuinely independent view; a monitor that peeks at design internals can't catch the design's mistakes. (2) Keep it passive and check-free — separate reconstruction (monitor) from checking (scoreboard) and coverage (collector): the monitor only assembles and broadcasts transactions, which keeps it reusable across every check and prevents the bus-perturbation bugs a driving monitor causes. Pair it with the per-cycle assertions of 16.2 (often the same bind-ed checker) so signal-local rules are caught at the source while the monitor handles the stateful reconstruction. (3) Verify the monitor itself — because a reconstruction bug masquerades as a scoreboard failure, validate the monitor against known traffic: drive scripted transactions and confirm the monitor reproduces them exactly (right beat counts, IDs, data, responses), including the hard cases — interleaved multi-ID bursts, back-to-back transactions with no idle, maximum-length bursts, mid-burst stalls, and out-of-order responses — which are precisely where ID-matching and last-beat detection break. The payoff: a passive, independent, well-tested monitor turns the raw five-channel signal soup into a clean transaction stream that the scoreboard can check for correctness and the coverage collector can measure for completeness. This separation — monitor reconstructs, scoreboard checks, coverage measures — is the backbone of AXI verification and the structure the next two chapters build directly on top of.

8. Interview Questions

9. Summary

An AXI monitor is the passive component that turns raw bus activity into transaction-level information. It taps the interface without driving it, samples each channel's beat exactly on its completed handshake (VALID && READY — the same condition the assertions use), and reconstructs transactions by gathering beats across channels and cycles: for a write, the AW opens a context, W beats accumulate to WLAST, and the B (matched by ID) closes it; for a read, the AR opens it and R beats (each with its own RRESP) accumulate to RLAST. Per-ID context structures — ideally per-ID queues — let it correctly reassemble multiple outstanding, interleaved, and out-of-order transactions, mirroring AXI's ordering model. Completed transactions are broadcast through an analysis port, which decouples the monitor from its subscribers so one monitor feeds a scoreboard, coverage collector, and logger at once.

The monitor's discipline is to reconstruct independently (from observed traffic, never DUT internals), stay passive and check-free (reconstruction here, checking in the scoreboard, measuring in coverage), and be verified itself against scripted known traffic — especially interleaved multi-ID bursts and out-of-order completion, where reconstruction bugs hide and masquerade as scoreboard failures. As the source of truth for transaction-level verification, the monitor is the bridge from per-cycle assertions to the scoreboard and coverage built next. Next, we feed its transaction stream into a scoreboard that checks data integrity and ordering against a reference.

10. What Comes Next

You can now reconstruct transactions; next we check them for correctness:

16.4 — AXI Scoreboards (coming next) — a scoreboard that checks data integrity and ordering by comparing the monitor's reconstructed transactions against a reference model.

Previous: 16.2 — AXI Assertions (SVA). Related: 8.3 — Same-ID Ordering and 8.4 — Different-ID Ordering for the ordering model the monitor must mirror, and 16.1 — The Protocol-Checker Mindset for where the monitor fits in the verification stack.