AMBA AHB · Module 17

AHB Monitors

Building a passive monitor that reconstructs AHB transfers from the bus signals — observing (never driving) the signals, pairing each address phase with its data phase across the pipeline into a transaction object, and broadcasting it through an analysis port to the scoreboard and coverage collector. Reconstruction bridges the pipeline: sample the address phase on HREADY high (qualified on a real HTRANS so IDLE/BUSY aren't recorded as phantom transfers), hold it across wait states, pair with the data phase. The single trusted transaction-level view the rest of the checking builds on; its correctness is load-bearing.

Assertions (17.2) check cycle-level rules; but data integrity and coverage need a transaction-level view — "a write of D to address A, then a read of A returning D". The monitor provides that view. A monitor is a passive verification component: it observes the AHB bus signals — never drives them — reconstructs each transfer as a transaction object, and broadcasts it (through an analysis port) to subscribers — the scoreboard (17.4, checks data) and the coverage collector (17.5, records scenarios). The hard part is reconstruction, because AHB is pipelined: a transfer's address and data arrive in different cycles. So the monitor must sample the address phase (when HREADY is high — the transfer is accepted; qualified on a real HTRANS so IDLE/BUSY aren't recorded as transfers), hold that context across any wait states, then sample the data phase (again when HREADY is high) and pair them into one complete transaction. It's the same pipeline discipline the slave faces (16.7) — applied to observing instead of acting. Because it only observes, the monitor works on any AHB interface (real RTL or testbench-driven), providing the single, trusted, transaction-level view the rest of the checking builds on. This chapter builds the monitor.

1. What Is It?

An AHB monitor is a passive component that reconstructs bus transfers into transactions and broadcasts them. Its parts:

Passive observation — samples the bus signals (via a virtual interface) but never drives them; works on any AHB interface.
Transfer reconstruction — pairs each address phase with its data phase (across the pipeline) into a transaction object.
Sample discipline — sample on HREADY high (transfer accepted); qualify on a real HTRANS (skip IDLE/BUSY) so no phantom transfers.
Broadcast — sends each completed transaction through an analysis port to subscribers (scoreboard, coverage).

Figure 1 — the passive monitor in the testbench. The monitor observes the AHB bus/DUT signals (HADDR, HWRITE, HTRANS, HWDATA, HRDATA, HREADY, HRESP) via a virtual interface — observe only, never drive — reconstructs each transfer into a transaction object, and broadcasts it through an analysis port. Subscribers are the scoreboard (checks data integrity) and the coverage collector (records scenarios). Because it only observes, the monitor works on any AHB interface, real RTL or testbench-driven, providing the single, trusted, transaction-level view the rest of the checking builds on.

So an AHB monitor is the testbench's transaction-level eye on the bus. The raw bus is a set of cycle-by-cycle signals; the checking infrastructure (scoreboard, coverage) wants transactions ("write D to A"). The monitor bridges that gap — it watches the signals and reconstructs the transactions. It's deliberately passive: it only observes, never drives, so it can't affect the design's behavior and works identically on a testbench-driven interface or a real RTL interface (even a DUT-internal one). The reconstruction is the skill — pairing each address phase with its data phase across the pipeline, sampling at the right time (HREADY high), and qualifying on a real transfer (HTRANS = NONSEQ/SEQ) so IDLE/BUSY cycles don't become phantom transactions. The reconstructed transactions are then broadcast (via an analysis port) to whoever subscribes — the scoreboard checks their data, the coverage collector records their scenarios. So the monitor is the single source of the transaction-level truth. So an AHB monitor is the passive transfer-reconstructor. So it's the eye the checkers see through.

An AHB monitor = a PASSIVE component that observes (never drives) the bus, reconstructs each transfer by pairing the address phase with its data phase across the pipeline (sample on HREADY high, qualify on real HTRANS), and broadcasts the transaction to the scoreboard + coverage

An AHB monitor in one frame: a passive component that observes the AHB bus signals (never drives them), reconstructs each transfer into a transaction object, and broadcasts it through an analysis port to subscribers (scoreboard, coverage). The reconstruction bridges the pipeline: sample the address phase (HADDR/HWRITE/HSIZE/HBURST) when HREADY is high (the transfer is accepted) and HTRANS is a real transfer (NONSEQ/SEQ — qualify so IDLE/BUSY aren't recorded); hold that captured context across any wait states; then sample the data phase (HWDATA for a write, HRDATA for a read, plus HRESP) when HREADY is high; and pair them into one complete transaction. This is the same pipeline discipline the slave faces (16.7) — capture the address phase, hold across waits, complete on the data phase — but for observing, not acting. Because it's passive (observe-only), the monitor works on any AHB interface — real RTL or testbench-driven — and provides the single, trusted, transaction-level view that the scoreboard (17.4) and coverage (17.5) build on. Two pitfalls it must avoid: phantom transfers (recording IDLE/BUSY as transactions — qualify on real HTRANS) and mis-pairing (pairing the wrong address with the wrong data — hold the address context correctly across waits).

2. Why Does It Exist?

The monitor exists because the checking infrastructure (scoreboards, coverage) needs a transaction-level view that the raw cycle-level bus doesn't directly provide — so one passive component reconstructs transactions once, centrally, for all checkers to share, non-intrusively.

The transaction-level abstraction is the root: scoreboards and coverage reason about transactions — "a write of D to A", "a 4-beat INCR burst" — not raw HADDR/HREADY toggling. But the bus presents cycle-level signals. So something must reconstruct the transactions from the signals. So the monitor exists to provide the transaction abstraction — turning signals into transactions. So it's the abstraction layer. So the checkers need transactions.

The reconstruct once, share drives the centralization: many checkers (scoreboard, coverage, maybe protocol-transaction checks) all need the same transaction view. If each reconstructed it independently, that's redundant and inconsistent (different reconstructions might disagree). So one monitor reconstructs the transactions once and broadcasts them (via the analysis port) to all subscribers — one consistent view, shared. So the monitor exists to centralize the reconstruction. So it's the single source. So sharing favors one monitor.

The passive non-intrusiveness is the practicality: because the monitor only observes (never drives), it can't affect the design — so it's safe to attach anywhere (a real RTL interface, an internal bus) without changing behavior, and the same monitor works whether the interface is testbench-driven or DUT-internal. So the monitor exists as a non-intrusive, universal observer. So it's clean and reusable. So passivity favors the monitor. So the monitor exists because: the checkers need a transaction-level view the raw bus doesn't provide (the abstraction — signals → transactions — the why); that view should be reconstructed once and shared (one consistent source, broadcast to all subscribers — the centralization); and it must be passive (observe-only — non-intrusive, universal — the practicality). So the AHB monitor is the passive, central, transaction-reconstructing component that gives the checking infrastructure its shared, trusted, transaction-level view of the bus — the foundation the scoreboard and coverage build on. So this chapter builds that foundation. So reconstruct transactions, passively, once.

3. Mental Model

Model the monitor as a courtroom stenographer. They sit silently and never participate — they don't argue, object, or rule (passive — never drive). They transcribe the proceedings, but not as raw noise: they reconstruct coherent statements — pairing a question (asked at one moment) with its answer (given moments later), across any pauses — into a clean record (a transaction). And they distribute that record to everyone who needs it — the judge, the lawyers, the appeals court (the analysis-port subscribers: scoreboard, coverage). They're careful not to record coughs and shuffles as testimony (qualify on real transfers, skip IDLE/BUSY).

A courtroom (the bus) with proceedings happening cycle by cycle. A stenographer (the monitor) sits in the corner. The first defining trait: they never participate — they don't ask questions, object, or rule; they only record (the monitor is passive — it observes, never drives). This is essential: a stenographer who interjected would change the proceedings; by only recording, they capture what actually happened without affecting it. The second trait: they don't transcribe raw noise — they reconstruct coherent statements. A question is asked at one moment, and its answer comes moments later (after the witness thinks — a pause, like a wait state); the stenographer pairs the question with its answer into one coherent exchange in the record (the monitor pairs the address phase with its data phase, across wait states, into one transaction). They hold the question in mind until the answer comes, then write the complete exchange. The third trait: they're careful what counts — a cough, a shuffle, a pause is not testimony; they only record actual statements (the monitor qualifies on a real HTRANS — skipping IDLE/BUSY, which would otherwise be phantom "transactions"). And finally: they distribute the record to everyone who needs it — the judge (checks the verdict — the scoreboard), the appeals court (reviews what was covered — the coverage collector) — one authoritative record, shared (the analysis-port broadcast). So the stenographer silently, faithfully reconstructs the coherent record of what actually happened and distributes it.

This captures the monitor: the stenographer never participating = the monitor being passive (observe, never drive); transcribing without affecting the proceedings = observing without changing the design; pairing a question with its later answer across a pause = pairing the address phase with its data phase across wait states; holding the question until the answer comes = holding the address-phase context across waits; not recording coughs as testimony = qualifying on real HTRANS (skipping IDLE/BUSY); one authoritative record = the single trusted transaction view; distributing to the judge and appeals court = broadcasting via the analysis port to scoreboard and coverage. Sit silently, reconstruct the coherent record, skip the noise, and distribute it.

Watch the monitor reconstruct a write transfer across a wait state:

The monitor reconstructs a write across a wait

4 cycles

Figure 2 — the monitor reconstructs a write transfer, pairing the address phase with its data phase across a wait. Cycle 0: address phase — HREADY high, HTRANS=NONSEQ (a real transfer), so the monitor SAMPLES the address phase: addr=A, write. It holds this context. Cycle 1: data phase begins, but HREADY is low (a wait) — the monitor does NOT complete the transaction yet (it holds A). Cycle 2: HREADY high — the data phase completes; the monitor samples HWDATA=D and HRESP=OKAY, pairs them with the held address context (A, write), and broadcasts the complete transaction 'write D to A, OKAY'. The 'monitor' row shows: sample-addr (cyc 0), hold (cyc 1), complete+broadcast (cyc 2). Sampling on HREADY high and holding across the wait produces one correct transaction.

The model's lesson: sit silently, reconstruct the coherent record, skip the noise, and distribute it. In the waveform, the monitor samples the address on the real transfer (cycle 0), holds it across the wait (cycle 1), and completes the transaction when the data phase finishes (cycle 2) — pairing A with D into one correct transaction.

4. Real Hardware Perspective

In a UVM testbench, the monitor is a uvm_monitor with a virtual interface (sampling the signals), a reconstruction process (a forever loop pairing address and data phases), and an analysis port (uvm_analysis_port) broadcasting the transactions; the sampling discipline (HREADY, qualified HTRANS) and the address-phase pipeline are the key logic.

The virtual interface sampling: the monitor samples the bus via a virtual interface (vif) — @(posedge vif.HCLK) then read vif.HADDR, vif.HREADY, etc. It only reads (never writes) the interface signals. So in a UVM testbench, the monitor connects to the DUT via the vif and samples it each clock. So it's interface sampling. So that's the input.

Figure 3 — how the monitor reconstructs a transfer across the pipeline. In the address phase (cycle N), sample HADDR/HWRITE/HSIZE/HBURST when HREADY is high — qualified on a real HTRANS (skip IDLE/BUSY). Capture this address-phase context. In the data phase (cycle N+1), sample HWDATA/HRDATA + HRESP when HREADY is high, and pair them with the captured address context to form one complete transaction. The key subtlety is the same as the slave: hold the address-phase context across any wait states until the matching data phase completes — so the monitor maintains a small pipeline of captured contexts and completes each transaction when its data phase finishes.

The reconstruction with the address-phase pipeline: the monitor's run_phase is a loop that tracks the address-phase context. When it samples a real address phase (HREADY && (HTRANS==NONSEQ || HTRANS==SEQ)), it captures the context into a pending transaction (and, for pipelining/bursts, a small queue of pending contexts). When a data phase completes (HREADY high), it samples the data/response and completes the oldest pending transaction, then broadcasts it. The holding across waits is automatic: the context stays pending until its data phase completes (when HREADY goes high). So in UVM, the reconstruction is a pipeline-aware loop — the same address-then-data discipline as the slave (16.7), but observing. So it's a reconstruction loop. So that's the core.

The analysis port broadcast: the completed transaction is broadcast via analysis_port.write(txn) — sending it to all connected subscribers (scoreboard, coverage) non-blockingly. The subscribers connect to the port in the env. So in UVM, the monitor publishes transactions; the scoreboard/coverage subscribe. So in UVM, the monitor is a passive uvm_monitor: a vif-sampling, pipeline-aware reconstruction loop, broadcasting via an analysis port. The sampling discipline (HREADY high, qualified HTRANS) and the address-phase pipeline (hold across waits, pair correctly) are the correctness-critical parts — exactly mirroring the slave's capture (16.7). So in UVM, build the monitor as a pipeline-aware passive observer. So that's its form.

5. System Architecture Perspective

At the system level, the monitor is the transaction-level foundation of the whole verification environment — the single source of truth that every transaction-level checker depends on, the reuse anchor of a verification IP (VIP), and the component whose correctness is load-bearing for all downstream checking.

The transaction-level foundation: everything transaction-level — the scoreboard (17.4), coverage (17.5), transaction-level protocol checks — depends on the monitor's reconstructed transactions. So the monitor is the foundation of the transaction-level verification. So at the system level, it's load-bearing. So the checkers stand on it.

The single source of truth: because one monitor reconstructs the transactions and broadcasts them, all checkers see the same view — a consistent, single source of truth. So there's no disagreement between checkers about what happened (they all got the same transactions). So at the system level, the monitor provides consistency. So it's the shared truth. So checkers agree.

The VIP reuse anchor + load-bearing correctness: the monitor (with the driver, sequencer, agent — 17.11) is the core of an AHB verification IP — a reusable package dropped into any AHB verification. And its correctness is load-bearing: if the monitor mis-reconstructs (mis-pairs address/data, records phantom transfers, or misses transfers), every downstream checker is fed wrong data — a scoreboard would flag false errors (or miss real ones), coverage would be wrong. So the monitor must be correct — its bugs poison the whole environment. So at the system level, the monitor is the transaction-level foundation (every transaction-level checker depends on it — load-bearing), the single source of truth (one consistent view, broadcast — checkers agree), and the core reuse anchor of an AHB VIP (reusable across verifications) whose correctness is critical (a mis-reconstruction poisons all downstream checking — false/missed errors). So the monitor is the keystone of AHB verification — passive yet foundational, the component whose faithful reconstruction the entire checking infrastructure trusts. So build the monitor correctly — everything depends on it. So get the reconstruction right.

6. Engineering Tradeoffs

The AHB monitor embodies the passive, pipeline-aware, broadcast design.

Passive (observe) vs active (drive). A passive monitor observes non-intrusively (works anywhere, can't affect the DUT); an active component (driver) drives stimulus. The monitor is strictly passive — never drives.
Sample on HREADY high vs every cycle. Sampling only when HREADY is high captures accepted transfers correctly; sampling every cycle records wait cycles wrongly. Sample on HREADY high (completion).
Qualify on real HTRANS vs record all. Qualifying on a real HTRANS (NONSEQ/SEQ) skips IDLE/BUSY (no phantom transfers); recording all cycles creates false transactions. Always qualify.
Broadcast (analysis port) vs direct call. Broadcasting via an analysis port decouples the monitor from subscribers (any number, added freely); a direct call couples them. Use the analysis port.

The throughline: an AHB monitor is a passive component that observes the bus (never drives), reconstructs each transfer by pairing the address phase with its data phase across the pipeline, and broadcasts the transaction via an analysis port to the scoreboard and coverage. The reconstruction mirrors the slave's discipline (16.7): sample the address phase on HREADY high qualified on a real HTRANS (skip IDLE/BUSY — no phantom transfers), hold it across wait states, pair with the data phase. Because it's passive, it works on any AHB interface (real or testbench-driven). It's the transaction-level foundation — the single source of truth every checker depends on, the core of an AHB VIP — whose correctness is load-bearing (a mis-reconstruction poisons all downstream checking).

The monitor must qualify on a real HTRANS and pair address/data correctly across the pipeline — recording IDLE/BUSY as transfers creates PHANTOM transactions, and mis-holding the address context across waits MIS-PAIRS data with the wrong address. Either poisons every downstream checker

The monitor's correctness is load-bearing, so its two characteristic bugs are especially dangerous — they silently feed wrong transactions to every downstream checker. (1) Phantom transfers (not qualifying on real HTRANS). HSEL/HADDR are driven on IDLE and BUSY cycles too — the master drives an address even when not transferring. If the monitor records a transfer on every cycle HREADY is high (without qualifying on HTRANS being NONSEQ/SEQ), it fabricates transactions for IDLE/BUSY cycles — phantom transfers that never happened. The scoreboard would then check data for a transfer that didn't occur (flagging false errors), and coverage would count non-existent transactions. The fix: qualify — only record a transfer when HTRANS is a real transfer (NONSEQ or SEQ) and HREADY is high. This is the same qualified-select discipline the slave uses (16.7 / 16.1). (2) Mis-pairing (mis-holding the address context across waits). Because AHB is pipelined and wait states stretch the data phase, the monitor must hold each address-phase context until its matching data phase completes — and pair them correctly. If it mis-handles the holding — e.g. overwrites a pending address context with the next one before the first's data phase completes (during a wait), or pairs the data with the wrong address — it produces transactions with the wrong address/data combination. The scoreboard, comparing this mis-paired transaction, flags a false mismatch (or misses a real one). The fix: maintain a correct pipeline of pending contexts (a small queue for pipelined/burst transfers), holding each across its waits, and completing them in order as their data phases finish — exactly the slave's HREADY-gated capture discipline (16.7), applied to observing. The unifying danger: because every downstream checker trusts the monitor's transactions, a mis-reconstruction doesn't cause an obvious monitor error — it silently feeds wrong data to the scoreboard and coverage, producing false errors (wasting debug time chasing a "bug" that's really a monitor bug) or missed errors (a real DUT bug hidden because the monitor mis-reconstructed around it). So the monitor's reconstruction must be as carefully verified as the DUT — qualify on real HTRANS (no phantoms), and pair address/data correctly across waits (no mis-pairing). A self-check: feed the monitor known traffic and confirm its reconstructed transactions exactly match. (See Address / Control Capture — the monitor faces the same pipeline discipline.)

7. Industry Example

Build an AHB monitor for a slave verification environment, and see it feed the checkers.

You're building the verification environment for the 16.x slave. The monitor reconstructs the bus traffic for the scoreboard and coverage.

Passive connection. The monitor connects to the AHB interface via a virtual interface and samples it each clock — never driving. It works on the slave's interface whether the stimulus comes from a testbench driver or (in a system test) a real master.
Address-phase sampling (qualified). Each clock, if HREADY is high and HTRANS is NONSEQ/SEQ (a real transfer), the monitor captures the address-phase context (HADDR, HWRITE, HSIZE, HBURST) into a pending transaction. IDLE/BUSY cycles are skipped (no phantom transfers).
Holding across waits + data-phase pairing. The pending context is held until its data phase completes (HREADY high). When it does, the monitor samples HWDATA (write) or HRDATA (read) and HRESP, pairs them with the held address context, and forms the transaction ("write D to A, OKAY").
Broadcast. The completed transaction is broadcast via the analysis port. The scoreboard (17.4) subscribes — it records writes and checks reads against expected data. The coverage collector (17.5) subscribes — it records the transfer type, burst, size, response.
Catching a DUT bug via the monitor. When the slave has the wrong-mux-select bug (16.5) and returns the wrong slave's data on a slave-switching read, the monitor reconstructs the actual (wrong) read data; the scoreboard compares it to expected and flags the mismatch — at the transaction level. The monitor faithfully reported what happened; the scoreboard caught the error.
Verifying the monitor. You feed known traffic and confirm the monitor's transactions exactly match — proving it doesn't phantom or mis-pair (so the scoreboard's results are trustworthy).

The example shows the monitor as the transaction-level foundation: passively reconstructing the bus traffic (qualified, correctly paired), broadcasting transactions to the scoreboard and coverage, and enabling them to catch DUT bugs — while being itself verified so its reconstruction is trusted. This is how the checking infrastructure sees the bus. This is the keystone.

8. Common Mistakes

AHB-monitor misconceptions

"The monitor can drive signals." No — a monitor is strictly passive (observe only). Driving is the driver's job. Passivity lets it attach anywhere without affecting the DUT.
"Record a transfer every cycle HREADY is high." No — qualify on a real HTRANS (NONSEQ/SEQ). Recording IDLE/BUSY creates phantom transactions that poison the scoreboard/coverage.
"Sample the address and data in the same cycle." No — they're in different phases (pipelined). Capture the address phase, hold across waits, pair with the data phase.
"Overwrite the pending address on the next cycle." No — hold each pending context until its data phase completes (across waits); mis-holding mis-pairs address with data.
"The monitor doesn't need verifying." No — its correctness is load-bearing (a mis-reconstruction poisons all checkers). Feed known traffic and confirm the transactions match.
"Call the scoreboard directly." No — broadcast via an analysis port (decoupled, any number of subscribers). Don't hard-couple the monitor to one checker.

9. Interview Insight

The AHB monitor is a core verification interview topic — the passive-reconstruction role, the pipeline-pairing discipline, and the qualify/no-phantom awareness are the signals.

Figure 4 — a strong answer in one card: a monitor is passive (observes, never drives) and reconstructs each transfer into a transaction; it bridges the pipeline (sample the address phase, hold across waits, pair with the data phase); it samples only when HREADY is high and qualifies on a real HTRANS (no IDLE/BUSY phantom transfers); it broadcasts via an analysis port to the scoreboard (data) and coverage (scenarios) and works on any AHB interface. The senior point: passively reconstruct transfers — sample on HREADY high, qualify on real HTRANS — and broadcast complete transactions.

The answer that lands gives the passive role and the reconstruction discipline: "A monitor is a passive verification component — it observes the AHB bus signals but never drives them. Its job is to reconstruct each transfer into a transaction object and broadcast it, through an analysis port, to subscribers like the scoreboard and the coverage collector. The interesting part is the reconstruction, because AHB is pipelined — a transfer's address and data are in different cycles. So the monitor samples the address phase — the address, write flag, size, burst — when HREADY is high, and crucially it qualifies on a real HTRANS, NONSEQ or SEQ, so it doesn't record IDLE or BUSY cycles as transfers. That qualification is important; without it you get phantom transactions that never happened, which would poison the scoreboard and coverage. Then it holds that address-phase context across any wait states, and when the data phase completes — HREADY high again — it samples the write data or read data and the response, and pairs them with the held address to form one complete transaction. It's the same pipeline discipline the slave's capture logic faces: hold the address across waits, complete on the data phase. The monitor has to be careful to hold and pair correctly — if it mis-holds the address across a wait, it pairs data with the wrong address, producing mis-paired transactions. Then it broadcasts the transaction via the analysis port, which decouples it from the subscribers — any number can connect. Because it's passive, it works on any AHB interface, testbench-driven or real RTL. And its correctness is load-bearing: every downstream checker trusts its transactions, so a phantom or mis-pairing bug silently feeds wrong data to the scoreboard, causing false errors or missed real ones. So you verify the monitor itself — feed known traffic and confirm the transactions match." The passive-reconstruction role, the pipeline-pairing discipline, and the qualify/no-phantom awareness are the senior signals.

🔍 The discriminator: the monitor is PASSIVE and its reconstruction mirrors the slave's pipeline discipline — qualify on real HTRANS (no phantom transfers) and hold the address context across waits (no mis-pairing); its correctness is load-bearing, so a mis-reconstruction silently poisons every checker

The discriminator on the AHB monitor is whether you grasp it's passive and that its reconstruction faces the same pipeline discipline as the slave — with load-bearing correctness. A weak answer says "the monitor watches the bus and sends transactions to the scoreboard." A solid answer adds that it's passive (observe-only) and reconstructs transfers across the pipeline. But the senior answer nails the two correctness-critical points: (1) qualify on a real HTRANS — sample a transfer only when HREADY is high and HTRANS is NONSEQ/SEQ — because HADDR is driven on IDLE/BUSY too, and recording those creates phantom transactions that poison the scoreboard (false errors) and coverage (wrong counts). (2) hold the address context correctly across waits — the monitor must pair each address phase with its own data phase across any wait states, not overwrite a pending context during a wait — else it mis-pairs data with the wrong address (false mismatches). These are exactly the slave's capture disciplines (16.7 / 16.1) — qualified select and HREADY-gated holding — applied to observing instead of acting. The standout insight is why this matters so much: the monitor's correctness is load-bearing — every downstream checker trusts its transactions, so a mis-reconstruction doesn't throw an obvious error; it silently feeds wrong data to the scoreboard and coverage, causing false errors (debug time wasted on a monitor bug masquerading as a DUT bug) or missed errors (a real DUT bug hidden because the monitor reconstructed around it). So the monitor must be verified as carefully as the DUT (feed known traffic, confirm transactions match). The framing that impresses: the monitor is the transaction-level foundation — the single source of truth, the core of an AHB VIP, the keystone on which all transaction-level checking stands. A candidate who emphasizes passivity, maps the reconstruction to the slave's pipeline discipline (qualify + hold-across-waits), and stresses that the monitor's correctness is load-bearing demonstrates real testbench-architecture maturity — not just "watch the bus".

10. Practice Challenge

Build and reason from the AHB monitor.

The role. Explain what a monitor does and why it's passive (observe, never drive).
Reconstruction. Describe how the monitor pairs the address phase with the data phase across the pipeline (sample on HREADY high, hold across waits).
Read the waveform. From Figure 2, explain how the monitor samples the address, holds across the wait, and completes the transaction on the data phase.
Phantom and mis-pairing. Explain the two reconstruction bugs (not qualifying on real HTRANS; mis-holding across waits) and why they poison the checkers.
Broadcast. Explain why the monitor uses an analysis port and how the scoreboard and coverage subscribe.

11. Key Takeaways

A monitor is passive — it observes the bus (never drives), so it works on any AHB interface (real RTL or testbench-driven) without affecting the design.
It reconstructs transfers by pairing the address phase with its data phase across the pipeline — sample on HREADY high, hold across wait states, pair with the data phase — the same discipline as the slave's capture (16.7).
Qualify on a real HTRANS (NONSEQ/SEQ) — recording IDLE/BUSY creates phantom transactions; hold the address context correctly across waits — mis-holding mis-pairs data with the wrong address.
It broadcasts via an analysis port — decoupling it from subscribers (any number); the scoreboard (17.4) and coverage collector (17.5) subscribe.
Its correctness is load-bearing — a mis-reconstruction silently feeds wrong data to all checkers (false or missed errors). Verify the monitor (feed known traffic, confirm transactions match).
It's the transaction-level foundation — the single source of truth, the core of an AHB VIP, the keystone the scoreboard and coverage stand on.

12. What Comes Next

You now can reconstruct transactions passively. The next chapters consume those transactions:

AHB Scoreboards (next) — check data integrity by comparing the monitor's read transactions against expected values.
Functional Coverage, Constrained-Random Traffic, and the rest — measure completeness and generate stressful stimulus.

To revisit the pipeline discipline the monitor mirrors, see Address / Control Capture; for the rules the monitor's transactions are checked against, see The Protocol-Checker Mindset and AHB Assertions (SVA).