Analysis Ports & Subscribers: Broadcast Observability in UVM

Overview

Analysis TLM is the passive broadcast path in UVM. A producer such as a monitor calls write() on an analysis port, and all connected consumers receive that same transaction view.

This path is intentionally one-way and non-blocking. It is designed for observability components such as scoreboards, predictors, and coverage collectors that should not stall monitor collection.

Sub-lessons in this topic

1. analysis-port-broadcast - write() fan-out semantics and why there is no backpressure.

2. uvm_subscriber-base - extending uvm_subscriber and implementing write().

3. monitor-analysis-wiring - canonical monitor.ap -> scoreboard/coverage connect_phase wiring.

4. analysis_imp_decl - uvm_analysis_imp_decl macro pattern for multiple write channels.

5. multiple-subscribers - one monitor feeding many consumers safely and readably.

6. analysis-vs-put-get - choosing broadcast observability vs point-to-point flow control.

Big-picture architecture map

Legend: [MON] [TLM] [CHECK]

[MON] passive monitor collects bus observations
   │
   │ tr
   ▼
[TLM] monitor.ap.write(tr)
   │
   ├──────────────► [CHECK] scoreboard analysis_imp::write(tr)
   │
   ├──────────────► [CHECK] predictor analysis_imp::write(tr)
   │
   └──────────────► [CHECK] coverage subscriber write(tr)

all consumers see the same observation stream
none may block monitor collection

[TLM] analysis broadcast vs command path

  COMMAND PATH (active)                      OBSERVATION PATH (passive)
  sequence -> driver -> DUT                 monitor -> analysis_port -> subscribers
  may use put/get handshakes                always write() fan-out
  flow control can matter                   no backpressure by design
  mutates DUT state                         records/checks DUT behavior
  primary for stimulus                      primary for checking + coverage

Key takeaways

• Analysis ports are for passive observability, not active flow-controlled command transport.

• write() fan-out sends transactions to all connected subscribers in the analysis network.

• Monitor-to-scoreboard and monitor-to-coverage wiring is the core pattern to master.

• Use analysis_imp_decl when one component needs multiple typed write() channels.

Common pitfalls

• Treating analysis path as backpressured transport - this is not put/get.

• Mutating shared transaction objects in subscribers without clone discipline.

• Forgetting connect_phase wiring - monitor seems fine, checkers stay silent.

• Mixing command and observation responsibilities inside the same component.