AMBA AXI · Module 16

UVM AXI Agent Overview

Assemble the driver, sequencer, and monitor into a reusable UVM AXI agent — the standard unit that bundles one interface's verification, switchable between active (drive + observe) and passive (observe-only), with an analysis port to scoreboard and coverage. The reuse boundary that makes AXI verification composable across environments.

The previous chapters built the pieces — a driver's stimulus (16.6), a passive monitor (16.3), a scoreboard (16.4), coverage (16.5), assertions (16.2). The UVM agent is the standard packaging that bundles the per-interface pieces — sequencer + driver + monitor — into one reusable unit. An agent is the reuse boundary of UVM verification: built once for an AXI interface, it drops into any environment, at any level, wherever that interface appears, and switches between active (drive + observe) and passive (observe-only) with a single mode setting. This chapter assembles the AXI agent: its three components and their connections, the active/passive modes, the configuration that controls it, and how it plugs into an environment's scoreboard and coverage — the composable unit that everything before it slots into.

1. The Three Components and the Agent Boundary

An AXI agent bundles exactly three components for one interface: a sequencer (arbitrates and feeds sequence items to the driver), a driver (drives the AXI signals from those items, honoring the handshake), and a monitor (passively observes the bus and reconstructs transactions). The agent is the unit — you don't place a sequencer, driver, and monitor individually; you instantiate the agent and configure it.

Figure 1 — the UVM AXI agent and its three components. The sequencer arbitrates sequence items and feeds them to the driver; the driver drives the AXI interface signals honoring the VALID/READY handshake; the monitor passively observes the same interface and reconstructs transactions, exporting them on an analysis port. The agent boundary bundles all three for one interface as a single reusable unit — built once, instantiated wherever that interface appears.

The agent's build_phase constructs its components, and its connect_phase wires the driver to the sequencer and exports the monitor's port:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

class axi_agent extends uvm_agent;
  `uvm_component_utils(axi_agent)
  axi_sequencer            sqr;
  axi_driver               drv;
  axi_monitor              mon;
  uvm_analysis_port #(axi_txn) ap;   // exported monitor port
 
  function void build_phase(uvm_phase phase);
    mon = axi_monitor::type_id::create("mon", this);   // always built
    if (get_is_active() == UVM_ACTIVE) begin           // only if active
      sqr = axi_sequencer::type_id::create("sqr", this);
      drv = axi_driver::type_id::create("drv", this);
    end
  endfunction
 
  function void connect_phase(uvm_phase phase);
    ap = mon.ap;                                        // export monitor's port
    if (get_is_active() == UVM_ACTIVE)
      drv.seq_item_port.connect(sqr.seq_item_export);   // driver pulls from sequencer
  endfunction
endclass

2. Active vs. Passive

The agent's single most important configuration is its mode. An active agent builds all three components and drives the interface (sequencer + driver) while also observing (monitor) — used when the testbench is the source of traffic for that interface. A passive agent builds only the monitor and never drives — used to observe an interface that's driven by the real RTL (e.g. an internal interconnect port, or the DUT's own master). The same agent class serves both; the mode decides what it builds.

Figure 2 — active vs. passive agent. An active agent builds sequencer + driver + monitor and both drives and observes the interface — used where the testbench generates the traffic. A passive agent builds only the monitor and observes without driving — used to watch an interface driven by the RTL itself. The same agent class is reused; get_is_active() decides which components are built, so one agent covers both roles.

3. Configuration and the Reuse Boundary

An agent is parameterised/configured through a config object (set via uvm_config_db): its mode (active/passive), the virtual interface handle, and any protocol parameters (data width, ID width). This is what makes the agent the reuse boundary — the same agent code, configured differently, serves every AXI interface in the design. The interface protocol recurs everywhere (an AXI port appears in dozens of DUTs), so building the per-interface crew once as an agent and reusing it avoids re-implementing the protocol's interaction per project.

Figure 3 — the agent as the reuse boundary. A config object (mode, virtual interface, width parameters), set through uvm_config_db, configures one reusable agent class. The same agent is instantiated per interface — active where the testbench drives, passive where it observes — so the per-interface verification crew is built once and reused everywhere that interface appears, instead of being re-implemented per project. The agent is the unit you reuse, not its internals.

4. The Agent in the Environment

The agent plugs into a UVM environment: the env instantiates one or more agents (one per interface), and connects each agent's monitor analysis port to the scoreboard and coverage subscribers. The test, at the top, configures the env (sets agent modes, the vif handles) and runs sequences on the active agents' sequencers. The agent thus sits between the bus (its driver/monitor) and the env-level checking (its analysis port), encapsulating the interface so the env reasons in transactions, not signals.

Figure 4 — the agent in the UVM environment hierarchy. The test (top) configures the environment, sets each agent active or passive, and runs sequences. The environment instantiates agents (one per interface) and subscribes the scoreboard and coverage to each agent's monitor analysis port. Each agent encapsulates its interface — driving and/or observing — and exports transactions upward. The hierarchy is test → environment → agents → (sequencer, driver, monitor), with checking at the env level.

5. Common Misconceptions

Myths to unlearn

"An agent is just a folder grouping three files." It's a UVM component with a build/connect lifecycle that constructs its sub-components based on mode and wires them — and, crucially, the reuse boundary you instantiate and configure as a unit, not a loose grouping.
"You place the sequencer, driver, and monitor individually." You place the agent and set its mode; the agent decides which of the three to build. Thinking in individual components defeats the reuse the agent exists to provide.
"A passive agent still has a driver/sequencer, just disabled." A passive agent builds only the monitor — the sequencer and driver are not constructed at all (get_is_active() gates their creation). Passive means observe-only, with nothing capable of driving.
"The agent does the checking." The agent drives and observes; the scoreboard and coverage (at the env level) do the checking, subscribing to the agent's monitor analysis port. Keeping checking out of the agent is what lets the same agent feed any set of checks.
"Each interface needs a bespoke agent." The whole point is one reusable agent per protocol, configured per instance (mode, vif, widths) via the config object — the same AXI agent serves every AXI interface, rather than re-implementing the crew per project.
"Active and passive need different agent classes." Same class — get_is_active() (set from config) decides what's built. One agent covers driving an interface in one environment and passively monitoring the same kind of interface in another.

6. Debugging Insight

🔍 Debugging insight — agent bring-up problems cluster at mode, connection, and config

When an agent doesn't work, the cause is usually structural, at the agent's seams:

No traffic is driven. The agent is passive when it should be active — check the mode set via uvm_config_db/get_is_active(). A passive agent builds no driver, so nothing drives, often mistaken for a sequencer/driver bug.
Driver gets no items / sequence hangs. The seq_item_port↔seq_item_export connection is missing or the sequence was started on the wrong sequencer. Check connect_phase and the sequence's target sequencer handle.
Scoreboard/coverage receive nothing. The agent's exported analysis port isn't connected to the subscribers, or the monitor's port wasn't exported (ap = mon.ap). Trace the analysis-port wiring at the env level.
Null virtual interface / driver can't drive signals. The vif wasn't set in the config object or the agent didn't get it. Check the uvm_config_db set/get for the interface handle.
Passive agent tries to drive (or active doesn't observe). A mode/build mismatch — components built that shouldn't be, or vice versa. Confirm build_phase gates the sequencer/driver on get_is_active() and always builds the monitor.
Same sequence works in one env, not another. Different agent configuration between environments (mode, vif, widths) — compare the config objects.

Because the agent is a thin structural wrapper, its bugs are rarely in the (already-verified) driver/monitor logic — they're in mode, connections, and config. Check those three first; the internal components were verified before the agent was assembled.

7. Verification Insight

✅ Verification insight — the agent is the reuse boundary; build it once, configure it per instance, keep checking outside

The UVM agent is the structural keystone that makes everything in Module 16 composable and reusable. Three principles. (1) The agent is the reuse boundary — bundle the per-interface crew (sequencer, driver, monitor) into one agent built once per protocol, then instantiate it wherever that interface appears, configured per instance; because an AXI port recurs across dozens of DUTs and internal nodes, this amortizes the protocol-interaction implementation instead of re-coding it per project, which is the entire economic argument for UVM. (2) Mode is configuration, not a code fork — the same agent class serves active (drive + observe, where the testbench is the traffic source) and passive (observe-only, where the RTL drives, e.g. an internal interconnect port), with get_is_active() gating component construction; this means you monitor internal interfaces with the same agent you use to drive external ones, multiplying reuse. (3) Keep checking outside the agent — the agent drives and observes and exports transactions via the monitor's analysis port; the scoreboard, coverage, and protocol assertions live at the environment level and subscribe to that port, so the same agent feeds any combination of checks and the checking evolves independently of the stimulus/observation. The payoff is a verification environment assembled by composition: configure the env, set each agent's mode and vif, run sequences on the active agents, and subscribe scoreboard/coverage to the agents' ports — and because each agent's internals (driver, monitor) were verified before assembly (the monitor especially, since the scoreboard trusts it), agent-level debugging reduces to mode/connection/config at the seams. This is the same correct-by-composition discipline as the RTL library (15.8), now for verification IP: a well-built agent turns "verify this interface" into "instantiate and configure the agent," and is exactly what a commercial AXI VIP packages — the subject of the final chapter. The agent is where the per-piece work of Module 16 becomes a reusable, drop-in verification component.

8. Interview Questions

9. Summary

The UVM AXI agent is the standard packaging that bundles one interface's verification crew — sequencer + driver + monitor — into a single reusable component. The sequencer feeds items to the driver, the driver drives the AXI signals honoring the handshake, and the monitor passively observes and reconstructs transactions, exporting them on an analysis port. The agent's defining configuration is its mode: an active agent builds all three and drives + observes (testbench is the traffic source); a passive agent builds only the monitor and observes without driving (the RTL is the source, e.g. an internal node) — the same class, with get_is_active() gating construction. A config object (via uvm_config_db) sets mode, virtual interface, and width parameters, making the agent the reuse boundary: built once per protocol, instantiated and configured wherever that interface appears.

In the environment, the agent plugs in by exporting its monitor's analysis port to the env-level scoreboard and coverage, while the test configures the env and runs sequences on the active agents' sequencers — so checking stays outside the agent and the same agent can feed any set of checks. Agent bring-up bugs cluster at the seams (mode, connections, config), not the verified internals. The agent parallels the reusable RTL library (15.8): both encapsulate the recurring protocol work behind a configurable, composable unit and externalize the varying concern (checking for the agent, system composition for the library), enabling correct-by-composition assembly. Next, the final chapter shows how a commercial/open AXI VIP — essentially a pre-built, pre-verified agent plus checks — slots into exactly this structure.

10. What Comes Next

You can now assemble a reusable agent; the final chapter uses a pre-built one:

16.9 — Using AXI VIP (coming next) — how a commercial or open-source AXI Verification IP — essentially a pre-verified agent plus assertions and coverage — slots into the environment you've just learned to build.

Previous: 16.7 — Negative & Error-Injection Testing. Related: 16.3 — AXI Monitors for the monitor the agent bundles, 16.4 — AXI Scoreboards for the env-level checking the agent feeds, and 15.8 — Reusable AXI RTL Templates for the parallel reuse-boundary pattern in RTL.