Part 6 · Agents & Protocol IP · Intermediate

Active vs Passive Agents Hub: Knobs, Build Modes, and SoC Reuse

Hub - is_active control, active internals, passive monitor-only deployments, SoC integration, runtime switching patterns, and debug tactics for mixed-agent environments.

Overview

In UVM, active vs passive is the core reuse knob for agents. The exact same agent class can either drive and monitor an interface (active) or only observe external traffic (passive).

This hub focuses on practical engineering decisions: where to set is_active, how build internals differ by mode, how to integrate passive protocol VIP at subsystem/SoC layers, and how to debug mixed topologies without mode confusion.

Sub-lessons in this topic

is-active-knob - where is_active lives, who owns it, and precedence rules.
active-build-internals - exact components created in active mode and why.
passive-monitor-only - monitor-only deployment pattern and analysis fanout.
soc-integration-passive - integrating many passive VIP agents at SoC level.
cfg-active-passive-switch - switch policy via cfg and config_db with override hygiene.
active-passive-debug - mode mismatch triage, logging, and runtime assertions.

Architecture map

diagram

Legend: [UVM] [AGT] [VIP] [DRV] [MON] [SOC]

same agent class
          +---------------------------------------+
          | protocol_agent [AGT][VIP]             |
          | cfg.is_active = UVM_ACTIVE/PASSIVE    |
          +--------------------+------------------+
                               |
               +---------------+------------------+
               |                                  |
      UVM_ACTIVE path                     UVM_PASSIVE path
      ----------------                     ----------------
  [DRV] driver + sequencer + [MON]       [MON] monitor only
        drives vif to DUT                     no pin driving
        collects response                      analysis only
               |                                  |
               +------------------+---------------+
                                  |
                       analysis_port -> scoreboards/coverage

diagram

[SOC][VIP] mixed integration picture

chip_env
  ├─ cpu_apb_agent        [AGT] active   (verification drives control bus)
  ├─ dma_axi_agent        [AGT] passive  (DUT master observed only)
  ├─ pcie_rc_agent        [AGT] active   (protocol stimulus from VIP)
  ├─ pcie_ep_agent        [AGT] passive  (link partner observation mode)
  └─ noc_stream_agent[4]  [AGT] passive  (throughput coverage)

rule:
  drive where testbench owns stimulus
  observe where DUT or firmware already drives

diagram

[UVM][AGT] phase intent by mode

build_phase:
  - always create cfg
  - always create monitor
  - create driver+sequencer only when active

connect_phase:
  - active: connect driver.seq_item_port <-> sequencer.seq_item_export
  - both: expose monitor.ap to env subscribers

run_phase:
  - active: sequences issue traffic
  - passive: monitor decodes live bus and publishes transactions

Key takeaways

Active/passive is a reuse feature, not two separate agent codebases.
Monitor exists in both modes; driver and sequencer exist only in active mode.
SoC environments often combine active control agents with passive observability agents.
Mode ownership and precedence must be explicit to avoid integration ambiguity.

Common pitfalls

Creating driver unconditionally and assuming it stays idle in passive mode.
Letting both env and test override mode without documented precedence.
Using passive mode but expecting sequence-driven traffic generation.
Forgetting to surface mode in logs, causing long debug cycles.

Practice this lessonQuestions tagged for this topic in the bank