uvm_monitor Hub: Passive Sampling and Publish Discipline

Overview

A uvm_monitor observes interface behavior and publishes decoded transactions to downstream analysis consumers. It is the passive truth source in an active or passive agent.

Sub-lessons in this topic

1. passive-sampling - legal monitor behavior and sampling gates.

2. transaction-reconstruction - converting temporal pin activity into transaction objects.

3. monitor-clocking - edge/skew policy and race-free sampling.

4. analysis-port-publish - publication contracts and object ownership.

5. monitor-vs-driver - hard boundaries between observe and drive roles.

6. monitor-debug-checklist - deterministic triage for silent/noisy/wrong monitors.

[MON][UVM][AGT] monitor map

[SEQ] -> [DRV] -> DUT protocol pins
                   |
                   v
             [MON] samples only
                   |
                   v
      analysis_port.write(tr) -> scoreboard/predictor/coverage

monitor never drives DUT behavior

class my_monitor extends uvm_monitor;
  `uvm_component_utils(my_monitor)
  virtual my_if vif;
  uvm_analysis_port #(my_txn) ap;

  function new(string name, uvm_component parent);
    super.new(name, parent);
    ap = new("ap", this);
  endfunction
endclass

Key takeaways

• Monitor credibility determines checker credibility.

• Passivity is mandatory: sample, decode, publish.

• Stable timing policy is the foundation of monitor correctness.

Common pitfalls

• Monitor-side signal driving during debug shortcuts.

• Publishing partial/inconsistent transactions.

• Coupling monitor behavior to driver/sequencer internals.

Applied Patterns

This appendix consolidates reusable monitor patterns for enterprise-scale UVM environments where multiple teams share protocol VIP.

Use this as a quick implementation checklist before releasing monitor updates into regression branches.

[MON][UVM][AGT] reusable pattern grid

sampling:
  accepted-handshake gating only

reconstruction:
  key-based accumulator with completion predicate

publishing:
  clone policy + counter instrumentation

debug:
  boundary-first triage with deterministic smoke

function void monitor_health_report();
  `uvm_info("MON_HEALTH",
    $sformatf("sampled=%0d published=%0d dropped=%0d pending=%0d",
      sampled_cnt, published_cnt, dropped_cnt, pending_cnt),
    UVM_LOW)
endfunction

[MON] review checklist

- passive contract verified
- reset/flush policy documented
- publish ownership policy documented
- consumer fan-out validated
- counters visible in report_phase

• Design monitor updates as API changes to downstream consumers, not local edits.

• Keep monitor diagnostics always-on and low overhead for regression reliability.

• Revalidate sample-to-publish boundary after every protocol extension.