Part 6 · Agents & Protocol IP · Intermediate

Active/Passive Debug: Fast Triage for Mode Mismatches

Systematic debug workflow for mode-related failures: topology checks, ownership assertions, vif validation, and transaction-path tracing.

Failure classes to recognize quickly

Mode bugs tend to cluster into a few classes: missing stimulus, illegal pin driving, null component access, and absent monitor data. Recognizing these signatures shortens root-cause time.

Start with structural facts before investigating protocol detail. If mode/topology is wrong, protocol-level debugging is usually noise.

diagram
[AGT][DEBUG] mode failure taxonomy

class 1: under-active
  expected active, resolved passive
  symptom: no driven traffic

class 2: over-active
  expected passive, resolved active
  symptom: bus contention / dual drive

class 3: structural mismatch
  mode says passive but drv exists (or inverse)

class 4: observability gap
  passive monitor exists but no analysis output
diagram
[VIP] first-minute checks

1) read mode logs per agent
2) print topology
3) inspect vif handles in driver/monitor
4) verify connect_phase links
5) observe first transaction path
  • Classify failure type before deep trace collection.

  • Topology correctness is a prerequisite for protocol debugging.

  • Standardized first-minute checks reduce random debug effort.


Topology-first debug workflow

Run deterministic topology validation every simulation. This gives immediate evidence for whether mode-dependent components were created correctly.

systemverilog
function void end_of_elaboration_phase(uvm_phase phase);
  super.end_of_elaboration_phase(phase);
  uvm_top.print_topology();
endfunction
systemverilog
function void assert_agent_shape(protocol_agent agt);
  if (agt.cfg.is_active == UVM_ACTIVE) begin
    if (agt.drv == null || agt.sqr == null)
      `uvm_fatal("SHAPE", "ACTIVE agent missing drv/sqr")
  end
  else begin
    if (agt.drv != null || agt.sqr != null)
      `uvm_fatal("SHAPE", "PASSIVE agent should not have drv/sqr")
  end
  if (agt.mon == null)
    `uvm_fatal("SHAPE", "monitor must always exist")
endfunction
diagram
[UVM] structural debug checklist

active expectation:
  mon present, drv present, sqr present, seq link connected

passive expectation:
  mon present, drv null, sqr null, no seq link

both:
  cfg present
  vif assigned to monitor
  • Shape assertions catch mode inconsistencies before run-phase behavior.

  • Treat missing monitor as fatal regardless of mode.

  • Use deterministic topology print in all regressions.


Transaction-path tracing in mixed environments

After structure is validated, trace exactly one transaction path. In active mode trace sequence->driver->vif->monitor; in passive mode trace vif->monitor->analysis subscribers.

diagram
[AGT] active path trace

sequence start
  -> get_next_item grant
  -> driver drives interface
  -> monitor captures transfer
  -> scoreboard receives analysis item
diagram
[AGT] passive path trace

external traffic on vif
  -> monitor captures
  -> ap.write(item)
  -> checker/coverage receives

if first arrow fails:
  visibility issue
if second arrow fails:
  monitor decode issue
if third arrow fails:
  connect/wiring issue
systemverilog
`uvm_info("TRACE_ACTIVE",
  $sformatf("agt=%s mode=%s first_item addr=0x%0h data=0x%0h",
    get_full_name(), cfg.is_active.name(), tr.addr, tr.data),
  UVM_MEDIUM)
  • Trace one deterministic transaction instead of noisy full tests.

  • Differentiate visibility, decode, and wiring failures explicitly.

  • Use identical trace formats across active and passive agents.


Regression hardening for mode stability

Prevent recurring mode regressions by adding reusable checks and smoke tests that intentionally cover both active and passive configurations.

diagram
[VIP][AGT] recommended smoke suite

smoke 1: active-only directed traffic
  expected: sequence drives and monitor observes

smoke 2: passive-only injected traffic
  expected: no driver ownership, monitor observes

smoke 3: mixed SoC map
  expected: selected agents active, others passive

smoke 4: illegal combo negative test
  expected: build-time fatal from policy checker
diagram
[DEBUG] recurring guardrails

- enforce mode report at start of every run
- add shape assertions in env build/end_of_elaboration
- add ownership-conflict checker for shared interfaces
- include passive monitor activity threshold checks
- gate regressions on these health checks
diagram
[SOC] release-readiness questions

1) can every interface owner be identified unambiguously?
2) do all passive agents publish meaningful transactions?
3) do active agents avoid contention in mixed runs?
4) are mode overrides deterministic and documented?
5) do smoke tests cover both modes per protocol family?

Key takeaways

  • Mode debugging is fastest when done structurally before protocol analysis.

  • Topology assertions and one-transaction traces isolate issues quickly.

  • Mixed environments require explicit ownership and deterministic policy checks.

  • Regression smoke coverage should include active, passive, and mixed cases.

Common pitfalls

  • Jumping into waveform detail before validating mode/topology basics.

  • Running only active-mode tests and assuming passive path is healthy.

  • Allowing interface ownership ambiguity between firmware and testbench.

  • Missing negative tests for illegal active/active contention setups.