Monitor vs Driver: Enforcing Observe/Drive Separation

Boundary model

Driver executes intended stimulus; monitor reports observed behavior. Scoreboards compare intent model vs monitor-observed truth.

[DRV] intent stream: sequence item before drive
[MON] observed stream: what pins actually did

never substitute intent for observation in checkers

function void build_phase(uvm_phase phase);
  mon = my_monitor::type_id::create("mon", this);
  if (is_active == UVM_ACTIVE) begin
    sqr = my_sequencer::type_id::create("sqr", this);
    drv = my_driver::type_id::create("drv", this);
  end
endfunction

• Passive mode reuse depends on strict role separation.

• Monitor must not call checker APIs directly in run loop.

• Driver should not publish itself as observed truth.

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.