AMBA AHB · Module 17

UVM AHB Agent Overview

Assembling the driver, sequencer, and monitor into a reusable AHB agent — the VIP that all of the verification components plug into. An agent packages the sequencer (arbitrates sequences), the driver (drives transactions onto the bus), and the monitor (passively observes and reconstructs), and is configurable as active (drives — master/responder) or passive (monitor only — observe a real interface); the monitor is always present, only the active path is conditional. The environment instantiates one agent per AHB interface and wires the monitors' analysis ports to the scoreboard and coverage, with assertions bound and tests built from sequences. Assembled, this is reusable verification IP (a VIP) that drops into any AHB verification, configured for the design.

This final chapter of Module 17 assembles everything into a reusable package: the UVM AHB agent and the environment around it. Throughout the module you built the pieces — the monitor (17.3), scoreboard (17.4), coverage (17.5), constrained-random stimulus (17.6), assertions (17.2), and the targeted tests (17.7–17.10). The agent is the reusable unit that packages the per-interface components: a sequencer (arbitrates sequences, feeds items to the driver), a driver (drives each transaction onto the bus as legal AHB through the virtual interface), and the monitor (passively observes the same interface and reconstructs transactions, broadcasting on its analysis port). The sequencer + driver are the active path (generate stimulus); the monitor is the passive path (observe). An agent is configurable: an active agent instantiates all three and drives the bus (modeling a master or a responder); a passive agent instantiates only the monitor and just observes (watching a real interface without driving). The environment instantiates one agent per AHB interface and wires the monitors' analysis ports to the scoreboard and coverage, with assertions bound to the interfaces and tests built from sequences. Assembled, this is reusable verification IP (a VIP) that drops into any AHB verification, configured for the specific design. So every component from the module fits into one structure. This chapter shows the assembly.

1. What Is It?

A UVM AHB agent is a reusable unit packaging the driver, sequencer, and monitor for one interface. Its parts:

Sequencer — arbitrates sequences and feeds transaction items to the driver (the stimulus scheduler).
Driver — drives each transaction onto the bus as legal AHB (via the virtual interface) — the active output.
Monitor — passively observes the interface and reconstructs transactions, broadcasting on its analysis port (17.3) — the passive observation.
Active/passive mode — active (sequencer+driver+monitor — drives) for a master/responder; passive (monitor only) to observe a real interface.

Figure 1 — the UVM AHB agent: sequencer + driver + monitor, packaged and reusable. The sequencer arbitrates sequences and feeds items to the driver; the driver drives each transaction onto the AHB bus (via the virtual interface); the monitor passively observes the same interface and reconstructs transactions, broadcasting on its analysis port to the scoreboard and coverage. The sequencer + driver form the active path (generate); the monitor is the passive path (observe). An ACTIVE agent instantiates all three and drives the bus (master/responder); a PASSIVE agent instantiates only the monitor and observes a real interface without driving. One agent per AHB interface — a bridge env has an active upstream agent and an active downstream responder, each monitor feeding the end-to-end scoreboard.

So the UVM AHB agent is the organizing unit of the verification environment — the reusable package that turns the individual components into a coherent, instantiable whole. The insight is that the per-interface components (driver, sequencer, monitor) always go together — they all serve one AHB interface — so they're packaged into one agent that's instantiated per interface. The active/passive configurability is the reuse enabler: the same agent can drive an interface (active — as a master or responder in a unit test) or just watch it (passive — observing a real interface in a system test). The environment then instantiates the agents (one per interface), connects the monitors to the shared checkers (scoreboard, coverage), binds the assertions, and runs the tests. So the agent + environment is the VIP — the reusable verification IP that drops into any AHB verification. So the UVM AHB agent is the reusable per-interface packaging of the stimulus-and-observation components. So it's how the methodology becomes reusable IP.

A UVM AHB agent = sequencer + driver + monitor packaged per interface, configurable active (drives — master/responder) or passive (monitor only — observe); the env instantiates one per interface and wires the monitors to the scoreboard + coverage, with assertions bound and tests = sequences → reusable VIP

A UVM AHB agent in one frame: the reusable unit that packages the per-interface verification components — a sequencer (arbitrates sequences → items), a driver (drives each transaction onto the bus as legal AHB via the virtual interface), and a monitor (passively observes the interface and reconstructs transactions — 17.3). The sequencer + driver are the active path (generate); the monitor is the passive path (observe). An agent is configurable: active (instantiates all three, drives the bus — modeling a master or a responder) or passive (instantiates only the monitor, just observes — for watching a real interface without driving). The environment instantiates one agent per AHB interface and wires the monitors' analysis ports to the scoreboard (17.4 — data) and coverage collector (17.5 — scenarios); assertions (17.2) are bound to the interfaces; tests are built from sequences (constrained-random — 17.6 — plus directed, running the targeted tests — 17.7–17.10) on the agents' sequencers. So every component from the module fits: the agent wraps driver/sequencer/monitor; the scoreboard and coverage subscribe to the monitors; assertions watch the interfaces; tests drive the sequences. Assembled, this is reusable verification IP (a VIP) — configured (active/passive, data width, address map, attributes) and dropped into any AHB verification (a bridge env has an active upstream agent + an active downstream responder, each monitor → the end-to-end scoreboard — 17.10). The agent is the deliverable that makes all the earlier components a coherent, reusable whole.

2. Why Does It Exist?

The UVM AHB agent exists because the per-interface components belong together (so they're packaged for instantiation per interface), because active/passive configurability enables reuse across unit and system tests, and because the agent+environment is the reusable VIP that makes the whole methodology a deliverable — built once, reused everywhere.

The per-interface components belong together is the root: the driver, sequencer, and monitor all serve one AHB interface — they're connected to the same virtual interface, coordinated (the sequencer feeds the driver), and deployed together. So packaging them into one agent (instantiated per interface) is the natural organization — one unit per interface, rather than loose components. So the agent exists to package the per-interface set. So it's cohesion. So the components belong together.

The active/passive enables reuse drives the configurability: the same interface components are needed in different roles — driving the interface (active — a master generating stimulus, or a responder modeling a slave) or just observing it (passive — watching a real interface in a system test, where the real RTL drives it). So the agent is configurable (active/passive) so the same agent serves both roles. So the agent exists to be reusable across roles. So it's role-configurable. So reuse needs the config.

The VIP is the deliverable is the purpose: the individual components (monitor, scoreboard, etc.) are useful, but the deliverable — the thing a verification team reuses — is the whole environment (agents + checkers + assertions + tests), packaged as VIP. The agent is the core of that VIP. So the agent+environment exists to be the reusable IP — built once (correctly, thoroughly) and reused across projects (any AHB design). So the agent exists to make the methodology reusable IP. So it's the deliverable. So the agent exists because: the per-interface components belong together (packaged per interface — the cohesion); active/passive configurability enables reuse across unit and system tests (the configurability); and the agent+environment is the reusable VIP — the deliverable built once and reused everywhere (the purpose). So the UVM AHB agent is the reusable, configurable, per-interface packaging that turns the module's components into deliverable verification IP — the organizing structure that makes AHB verification reusable, scalable, and maintainable. So this chapter assembles the deliverable. So package the components into reusable agents.

3. Mental Model

Model the UVM AHB agent as a self-contained film crew for one camera position, versus a pile of loose equipment. Rather than scattered cameras, operators, and recorders, you organize a crew per camera position: a director deciding what to shoot (the sequencer), a camera operator actually shooting (the driver), and a passive observer logging exactly what was captured (the monitor). The crew is configurable: a full active crew shoots the scene, or a log-only crew just records what another camera shot (passive). For a multi-camera production (a bridge), you deploy one crew per camera position, and all their logs feed a central editor (the scoreboard/coverage) who checks the footage. The crew is the reusable unit — staff it once, deploy it anywhere.

A film production (the verification) that needs to capture and check footage from multiple camera positions (interfaces). The amateur approach is a pile of loose equipment — scattered cameras, operators, recorders — with no organization, hard to deploy or reuse. The professional approach organizes a self-contained crew per camera position. Each crew has three roles: a director who decides what to shoot (the sequencer — arbitrating which sequences to run), a camera operator who actually shoots the scene (the driver — driving the transactions onto the bus), and a passive observer who logs exactly what was captured without touching the shoot (the monitor — observing and reconstructing). The crew is configurable for its role: a full active crew (director + operator + observer) shoots the scene — used when this position generates the action (an active agent — a master or responder); or a log-only crew (just the observer) records what another camera shot, without shooting itself — used to log a real feed (a passive agent — observing a real interface). For a multi-camera production (a bridge, with two interfaces), you deploy one crew per camera position — an active crew on the main camera (upstream) and an active crew on the second camera (downstream responder) — and all their logs feed a central editor (the scoreboard and coverage) who checks the footage (the data and scenarios) and a continuity supervisor (the assertions) who watches each feed for rule violations. The shoot list (the tests/sequences) tells the directors what to capture. And crucially: the crew is the reusable unit — you staff it once (correctly), then deploy it on any production (any AHB design), configured for the shoot.

This captures the UVM AHB agent: the pile of loose equipment = unorganized individual components; the self-contained crew per camera position = the agent per interface; the director deciding what to shoot = the sequencer; the camera operator shooting = the driver; the passive observer logging = the monitor; the configurable active/log-only crew = the active/passive agent; deploying one crew per camera in a multi-camera production = one agent per interface in a bridge env; all logs feeding the central editor = the monitors' analysis ports feeding the scoreboard/coverage; the continuity supervisor watching each feed = assertions bound to interfaces; the shoot list = tests/sequences; staff once, deploy anywhere = the reusable VIP. Organize a configurable crew per camera position, feed all logs to the central editor, and reuse the crew on any production.

Watch one agent serve different roles by configuration:

One agent, configured for different roles

3 cycles

Figure 2 — one agent, configured for different roles. The same AHB agent is instantiated three ways. Instance 1 (active master): instantiates sequencer + driver + monitor, drives the bus as a master generating stimulus into a slave DUT. Instance 2 (active responder): instantiates sequencer + driver + monitor, drives the bus as a responder modeling a slave (e.g. the downstream side of a bridge). Instance 3 (passive): instantiates only the monitor, observing a real RTL interface without driving (e.g. an internal bus in a system test). The 'components' row shows seq+drv+mon for active, mon-only for passive. The same agent code serves all three — configured by the active/passive mode (and parameters). One reusable unit, many roles.

The model's lesson: organize a configurable crew per camera position, feed all logs to the central editor, and reuse the crew on any production. In the figure, the same agent code serves three roles — active master, active responder, passive observer — configured by the active/passive mode. One reusable unit, many roles.

4. Real Hardware Perspective

In UVM, the agent is a uvm_agent containing a uvm_sequencer, a uvm_driver, and a uvm_monitor, built in build_phase per the is_active config and connected in connect_phase; the environment (uvm_env) instantiates the agents and connects the monitors' analysis ports to the scoreboard and coverage.

The agent build (active/passive): the uvm_agent's build_phase conditionally builds its sub-components per the is_active field: if UVM_ACTIVE, it builds the sequencer, driver, and monitor; if UVM_PASSIVE, only the monitor. The connect_phase connects the sequencer to the driver (driver.seq_item_port.connect(sequencer.seq_item_export)) when active. So in UVM, the agent is a configurable container. So it's a uvm_agent. So that's the unit.

Figure 3 — the full UVM environment built from agents. One or more AHB agents connect to the DUT via virtual interfaces. The agents' monitors broadcast reconstructed transactions on their analysis ports to two subscribers: the scoreboard (checks data integrity against an independent reference model) and the coverage collector (records which scenarios were exercised). Assertions, bound to the interfaces, continuously check protocol compliance. Tests, built from sequences, run on the agents' sequencers to generate constrained-random and directed stimulus (the targeted wait/burst/error scenarios). Every component from the module fits: agents wrap driver/sequencer/monitor; scoreboard and coverage subscribe to the monitors; assertions watch the interfaces; tests drive the sequences. Configurable (active/passive, width, map, attributes) and reusable — this is the VIP.

The environment assembly: the uvm_env instantiates the agents (one per interface), the scoreboard, and the coverage collector. In connect_phase, it connects each agent's monitor analysis port to the scoreboard and coverage (agent.monitor.ap.connect(scoreboard.imp); agent.monitor.ap.connect(coverage.imp)). The assertions are bound (separately, via bind — 17.2) to the interfaces. The virtual interfaces are passed via the config DB. So in UVM, the env wires the agents to the checkers. So it's the assembly. So that's the environment.

The tests and sequences: tests (uvm_test) configure the env (active/passive, etc.) and start sequences on the agents' sequencers. A sequence (uvm_sequence) generates the transactions (constrained-random — 17.6 — and directed, including the targeted wait/burst/error sequences — 17.7–17.10). Different tests run different sequences (a smoke test, a wait-stress test, a burst test, an error test, a bridge test). So in UVM, tests drive sequences on the agents. So in UVM, the agent (uvm_agent: configurable sequencer/driver/monitor) + the env (instantiates agents, wires monitors to scoreboard/coverage, binds assertions) + the tests/sequences = the complete, reusable VIP. The skill is clean, configurable, reusable construction (active/passive, parameterised) so the VIP drops into any AHB verification. So in UVM, build the agent configurable and the env reusable. So that's the implementation.

5. System Architecture Perspective

At the system level, the UVM AHB agent (and its environment) is the deliverable of AHB verification — the reusable VIP that amortizes the methodology across every AHB design — and it's the standard structure that makes verification scalable, maintainable, and team-shareable.

The reusable VIP deliverable: the agent+environment is packaged as VIP — reusable verification IP that drops into any AHB verification (any master, slave, interconnect, bridge), configured for the design. So the effort of building the components (the whole module) is amortized — built once, reused across many designs and projects. So at the system level, the VIP is the reusable deliverable — the return on the verification investment. So it's amortized reuse. So the VIP pays back.

The scalability and maintainability: the standard agent/env structure makes verification scalable (add an agent per new interface) and maintainable (a fix in the shared monitor/scoreboard propagates to all uses). And it's team-shareable — a common structure everyone understands (the UVM methodology is an industry standard). So at the system level, the structure gives scalability, maintainability, and shareability. So it's the standard. So the structure scales.

The methodology realized: the agent+environment is where the entire module comes together — the protocol-checker mindset (17.1) realized as a concrete, reusable, executable environment (assertions encode the rules, the monitor reconstructs, the scoreboard checks data, coverage measures, constrained-random generates, the targeted tests stress, all packaged in agents). So at the system level, the agent+environment is the reusable VIP deliverable (amortizing the methodology across every AHB design — the return on the investment), the standard structure (scalable — agent per interface; maintainable — shared-fix propagation; team-shareable — industry-standard UVM), and the realization of the whole methodology (the protocol-checker mindset made a concrete, reusable environment). So the UVM AHB agent is the capstone of AHB verification — the deliverable that turns the module's methodology into reusable, scalable, maintainable IP, the structure into which every component plugs. So assemble the agent and environment — it's the deliverable that makes the methodology reusable. So the agent is the methodology's package.

6. Engineering Tradeoffs

The UVM AHB agent embodies the per-interface-packaging, active/passive-configurable, reusable-VIP design.

Agent (packaged) vs loose components. A packaged agent (driver/sequencer/monitor per interface) is reusable and organized; loose components are harder to deploy/reuse. Package into agents.
Active/passive configurable vs fixed. A configurable agent (active or passive) serves both driving and observing roles (one unit, many uses); a fixed one needs separate components. Make it configurable.
Reusable VIP vs per-project testbench. A reusable VIP (configurable, parameterised) amortizes across projects; a per-project testbench is re-built each time. Build reusable VIP.
Standard UVM structure vs ad-hoc. The standard agent/env structure is scalable, maintainable, and team-shareable; an ad-hoc structure is none of these. Use the standard structure.

The throughline: the UVM AHB agent is the reusable unit that packages the per-interface components — a sequencer (arbitrates sequences), a driver (drives transactions onto the bus), and a monitor (passively observes and reconstructs — 17.3) — configurable as active (drives — master/responder) or passive (monitor only — observe a real interface). The environment instantiates one agent per AHB interface and wires the monitors' analysis ports to the scoreboard (17.4) and coverage (17.5); assertions (17.2) are bound; tests are built from sequences (constrained-random — 17.6 — plus the targeted tests — 17.7–17.10). Every module component fits: agents wrap driver/sequencer/monitor; scoreboard and coverage subscribe; assertions watch; tests drive. Assembled, this is reusable verification IP (a VIP) — configured and dropped into any AHB verification. It's the deliverable that amortizes the methodology, the standard, scalable, maintainable structure, and the realization of the whole protocol-checker methodology.

The monitor is ALWAYS present (even in a passive agent); only the sequencer+driver are conditional on active mode. And keep the agent reusable: configurable (active/passive, width, map), with the virtual interface from the config DB — a hard-coded, single-use agent defeats the whole point of a VIP

Two construction disciplines make the agent correct and reusable — and getting them wrong defeats the VIP. (1) The monitor is always present; only the sequencer+driver are conditional. A common confusion is what's conditional on the active/passive mode. The monitor is always built — both active and passive agents need to observe (the monitor is how the agent contributes transactions to the scoreboard/coverage, regardless of whether it also drives). Only the sequencer and driver (the active path) are conditional — built only when is_active == UVM_ACTIVE. So: active agent = sequencer + driver + monitor; passive agent = monitor only. Getting this backwards (e.g. omitting the monitor in some mode, or building the driver when passive) breaks the agent — a passive agent with no monitor observes nothing (useless), and a passive agent that builds a driver might drive a real interface (corrupting it). So: monitor always, sequencer+driver only when active. (2) Keep the agent reusable — configurable and interface-injected. The whole point of the agent is reuse as VIP, which requires it to be configurable and not hard-coded: the active/passive mode, the data width and address map and attributes (via parameters/config), and — critically — the virtual interface must come from the config DB (not hard-wired to a specific DUT instance). A hard-coded, single-use agent (fixed width, hard-wired interface, no active/passive) defeats the VIP — it can't be reused on another design or in another role, so you'd rebuild it each time (re-introducing bugs). So the agent must be parameterised and config-driven. The broader discipline: the agent (and env) is VIP — its value is reuse, so every design choice should favor reusability (configurable, parameterised, standard-structured, interface-injected) over single-use convenience. A correctly-built agent — monitor always, active path conditional, fully configurable — drops into any AHB verification; a miscable or hard-coded one is worse than loose components (it looks reusable but isn't). The tell of a non-reusable agent: a hard-wired virtual interface or a fixed data width that can't be changed per instantiation. So build the monitor unconditionally, gate only the active path, and make everything else configurable — that's what makes it a VIP, not a one-off. (See AHB Monitors for the always-present monitor and AHB Scoreboards for the subscribers the agent feeds.)

7. Industry Example

Assemble the AHB VIP and deploy it across unit and system (bridge) verification.

You're packaging the module's components into a reusable AHB VIP and deploying it.

The agent. A uvm_agent packages the uvm_sequencer, uvm_driver, and uvm_monitor. Its build_phase builds the sequencer+driver only if is_active == UVM_ACTIVE; the monitor is built always. It's parameterised (data width, address map, attributes) and gets its virtual interface from the config DB.
The environment. A uvm_env instantiates the agent(s), the scoreboard (17.4), and the coverage collector (17.5). In connect_phase, it connects each agent's monitor analysis port to the scoreboard and coverage. The assertions (17.2) are bound to the interfaces.
Unit verification (a slave DUT). For verifying the 16.x slave, the env has one active agent (a master — driving stimulus into the slave) and a passive monitor on the slave's interface (or the active agent's monitor observes it). Tests run sequences — a smoke test, the wait-stress test (17.7), the burst test (17.8), the error test (17.9) — all on the agent's sequencer.
System verification (a bridge DUT). For the bridge (17.10), the env has two active agents: an active master on the upstream AHB side (driving) and an active responder on the downstream side (modeling the downstream resource). Both monitors feed the end-to-end scoreboard. The same agent code serves both — configured differently.
Reuse across projects. The same VIP drops into the next AHB design (a different slave, a different interconnect) — configured (width, map, active/passive) for it. A fix in the shared monitor or scoreboard propagates to all uses.
The avoided pitfall. Early on, the agent omitted the monitor in passive mode (a build-phase bug) — so the passive agent observed nothing and the scoreboard got no transactions. Fixed by building the monitor always (only the sequencer+driver conditional).

The example shows the agent+environment as the reusable VIP: the same configurable agent serves master, responder, and passive roles across unit and system (bridge) verification, with the whole methodology (monitor, scoreboard, coverage, assertions, tests) plugged in — built once, reused everywhere, configured per design. This is the methodology packaged. This is the deliverable.

8. Common Mistakes

UVM-AHB-agent misconceptions

"The monitor is only in active agents." No — the monitor is always present (active and passive); only the sequencer+driver are conditional on active mode. A passive agent with no monitor observes nothing.
"Build the driver even when passive." No — the driver is built only when active. A passive agent that builds a driver might drive (corrupt) a real interface.
"Hard-code the virtual interface." No — get it from the config DB. A hard-wired interface makes the agent single-use (defeats the VIP).
"One agent for the whole DUT." No — one agent per interface. A bridge needs two agents (upstream + downstream).
"The agent is just the driver." No — it packages the sequencer + driver + monitor (the per-interface set), configurable active/passive.
"A per-project testbench is fine." No — build a reusable, configurable VIP (parameterised, standard-structured) — amortized across designs and projects; a fix propagates to all uses.

9. Interview Insight

The UVM AHB agent is a defining verification interview topic — the agent-packaging structure, the active/passive (monitor-always) configurability, and the reusable-VIP framing are the signals.

Figure 4 — a strong answer in one card: an agent packages sequencer + driver + monitor (driver/seq = active, monitor = passive); configurable active (drives — master/responder) or passive (monitor only — observe); one agent per interface, monitors' analysis ports → scoreboard + coverage, assertions bound, tests = sequences; assembled into an environment = reusable VIP. The senior point: the agent packages driver/sequencer/monitor into a configurable active/passive unit, one per interface; the env wires the agents to the scoreboard, coverage, and assertions.

The answer that lands gives the packaging structure and the configurability: "A UVM AHB agent packages the per-interface verification components into one reusable unit. Inside it are three things: a sequencer that arbitrates sequences and feeds transaction items to the driver; a driver that takes each transaction and drives it onto the AHB bus as legal protocol activity through the virtual interface; and a monitor that passively observes the same interface and reconstructs transactions, broadcasting them on its analysis port. The sequencer and driver are the active path that generates stimulus; the monitor is the passive path that observes. An agent is configurable: an active agent instantiates all three and drives the bus — used to model a master or a responder; a passive agent instantiates only the monitor and just observes — used to watch a real interface without driving it. A key detail is that the monitor is always present, in both active and passive agents — only the sequencer and driver are conditional on active mode, because even a passive agent needs to observe and contribute transactions to the checkers. The environment instantiates one agent per AHB interface and connects each agent's monitor analysis port to the scoreboard, which checks data, and the coverage collector, which records scenarios. Assertions are bound to the interfaces for protocol checking, and tests are built from sequences that run on the agents' sequencers — constrained-random and directed, including the targeted wait, burst, and error tests. So every component from the verification methodology fits into this structure: agents wrap the driver, sequencer, and monitor; the scoreboard and coverage subscribe to the monitors; assertions watch the interfaces; tests drive the sequences. For a bridge, you'd have two active agents — a master upstream and a responder downstream — both feeding an end-to-end scoreboard. And the whole thing is built to be reusable verification IP — configurable for active/passive, data width, address map — that drops into any AHB verification. So the agent is the deliverable that makes all the components a coherent, reusable whole." The packaging structure, the active/passive (monitor-always) configurability, and the reusable-VIP framing are the senior signals.

🔍 The discriminator: an agent packages sequencer+driver+monitor per interface, configurable active/passive — and the MONITOR is always present (only the active path is conditional); the env wires one-agent-per-interface to the shared scoreboard/coverage. It's reusable VIP — the deliverable the whole methodology plugs into

The discriminator on the UVM AHB agent is whether you describe the packaging structure correctly (including the monitor-always detail) and frame it as reusable VIP. A weak answer says "an agent drives the bus." A solid answer lists the three components (sequencer, driver, monitor) and the active/passive mode. But the senior answer nails the details and the framing: (1) the monitor is always present — in both active and passive agents — and only the sequencer+driver (the active path) are conditional on is_active; this is the most-commonly-confused point (a passive agent is monitor-only, not monitor-less, because every agent must observe to feed the checkers). (2) one agent per interface — the env instantiates an agent per AHB interface (a bridge needs two: active upstream + active downstream responder), and wires each monitor's analysis port to the shared scoreboard and coverage (subscribers). (3) the active/passive configurability enables reuse across roles — active drives (master in a unit test, responder modeling a slave), passive observes (a real interface in a system test) — the same agent code, configured. (4) — the framing that impresses — the agent+env is reusable VIP: the deliverable that amortizes the whole methodology (built once, reused across designs/projects, configured per design), the standard structure (scalable — agent per interface; maintainable — a shared-fix propagates; team-shareable — industry-standard UVM), and the realization of the protocol-checker mindset (17.1) as a concrete, reusable environment where every component plugs in (assertions encode rules, monitor reconstructs, scoreboard checks, coverage measures, tests stress). The reusability discipline: configurable (active/passive, width, map), interface-injected (vif from config DB, not hard-coded) — a hard-coded, single-use "agent" defeats the VIP. A candidate who packages the components correctly (monitor-always), wires one-agent-per-interface to the shared checkers, and frames it as configurable reusable VIP demonstrates real UVM environment-architecture command — the capstone skill of the whole verification module.

10. Practice Challenge

Build and reason from the UVM AHB agent.

The components. Describe the agent's three components (sequencer, driver, monitor) and the active vs passive paths.
Active/passive. Explain the active and passive modes, and why the monitor is always present (only the sequencer+driver conditional).
Read the figure. From Figure 2, explain how the same agent serves master, responder, and passive roles by configuration.
The environment. Describe how the env wires one-agent-per-interface to the scoreboard, coverage, and assertions, and how tests drive sequences.
Reusable VIP. Explain why the agent+env is reusable VIP and why that matters (amortization, maintainability, scalability).

11. Key Takeaways

A UVM AHB agent packages the per-interface components — a sequencer (arbitrates sequences), a driver (drives transactions onto the bus), and a monitor (passively observes and reconstructs — 17.3) — into one reusable unit.
Configurable active/passive — active (sequencer+driver+monitor — drives, as master/responder); passive (monitor only — observes a real interface). The same agent serves all roles.
The monitor is always present — in both active and passive agents; only the sequencer+driver (the active path) are conditional on is_active. A passive agent is monitor-only, not monitor-less.
One agent per interface — the env instantiates an agent per AHB interface (a bridge needs two), wiring each monitor's analysis port to the shared scoreboard (17.4) and coverage (17.5); assertions (17.2) bound; tests = sequences.
Keep it reusable — configurable (active/passive, width, map, attributes), interface-injected (vif from config DB, not hard-coded). A hard-coded, single-use agent defeats the VIP.
It's the reusable VIP deliverable — amortizes the methodology across designs/projects (built once, reused), the standard, scalable, maintainable structure, and the realization of the protocol-checker mindset — the capstone of AHB verification.

12. What Comes Next

This completes Module 17 — AHB Verification: you can now verify an AHB design end-to-end — the protocol-checker mindset, assertions, the monitor, scoreboard, coverage, constrained-random stimulus, the targeted wait/burst/error tests, bridge verification, and the reusable UVM agent and environment that package it all into VIP. The next module turns from verifying to debugging:

Module 18 — AHB Debugging (next) — diagnosing real AHB failures (stuck HREADY, wrong HTRANS, address/data misalignment, and the rest) from waveforms and symptoms.

To revisit the components this agent packages, see AHB Monitors, AHB Scoreboards, AHB Functional Coverage, and Constrained-Random AHB Traffic; for the mindset it realizes, see The Protocol-Checker Mindset.