TLM Interface Type Families: uvm_*_port/export/imp Overview

Family overview

UVM provides multiple endpoint families because communication patterns differ: push, pull, bidirectional request/response, and broadcast. Choose family by interaction semantics, then pick port/export/imp role objects.

[UVM][TLM] family map

put:
  initiator pushes transaction to provider

get/peek:
  initiator requests transaction from provider

transport:
  request and response in one interface call

analysis:
  write() broadcast to many observers, no flow control

[TLM] endpoint naming pattern

uvm_<family>_<flavor>_port   #(types...)
uvm_<family>_<flavor>_export #(types...)
uvm_<family>_<flavor>_imp    #(types..., IMP_CLASS)

example:
uvm_blocking_put_port #(pkt_t)
uvm_analysis_imp #(pkt_t, scoreboard_t)

• Select family by protocol semantics, not by whichever class is familiar.

• Blocking/non-blocking flavor is part of the API contract.

• Role objects remain the same concept across families.

put/get/peek families

put is producer-driven; get/peek are consumer-driven. put typically suits active senders, while get/peek suits pull-based schedulers and demand-driven consumers.

[UVM][TLM] push vs pull comparison

put:
  caller says "take this item now"
  target controls acceptance via blocking or try_put

get:
  caller says "give me next item"
  target controls item availability

peek:
  caller inspects next item without consuming

// push family
uvm_blocking_put_port   #(pkt_t) p_port;
uvm_blocking_put_export #(pkt_t) p_exp;
uvm_blocking_put_imp    #(pkt_t, sink_t) p_imp;

// pull family
uvm_blocking_get_port   #(pkt_t) g_port;
uvm_blocking_get_export #(pkt_t) g_exp;
uvm_blocking_get_imp    #(pkt_t, src_t) g_imp;

// non-consuming inspect
uvm_blocking_peek_port  #(pkt_t) k_port;

[TLM] choosing guideline

if producer owns data timing:
  choose put

if consumer decides when to fetch:
  choose get/peek

if both request and response must be coupled:
  consider transport

• Use get/peek when demand-side pacing is primary behavior.

• Use put when source-side pacing and backpressure handling is primary.

• Keep interface choice aligned with how your DUT protocol behaves conceptually.

transport and analysis families

Transport combines request and response in one interface, useful for function-like service interactions. Analysis is fundamentally different: fire-and-forget broadcast for passive observation.

[UVM][TLM] transport semantics

transport(req, rsp):
  initiator sends request
  provider returns response in same interaction contract

good for:
  abstract service models
  memory/model query style interactions

uvm_blocking_transport_port   #(req_t, rsp_t) t_port;
uvm_blocking_transport_export #(req_t, rsp_t) t_exp;
uvm_blocking_transport_imp    #(req_t, rsp_t, service_t) t_imp;

virtual task transport(req_t req, output rsp_t rsp);
  // service implementation
endtask

[UVM][TLM] analysis semantics

analysis_port.write(tr):
  one publisher -> many subscribers
  no return status
  no flow-control handshake

canonical use:
  monitor publishes observations to scoreboard + coverage

uvm_analysis_port #(pkt_t) mon_ap;
uvm_analysis_export #(pkt_t) env_exp;
uvm_analysis_imp #(pkt_t, score_t) sb_imp;

function void write(pkt_t t);
  // scoreboard consumes observation
endfunction

• Transport is request-response; analysis is observation broadcast.

• Do not use analysis where backpressure or response is required.

• Use analysis for monitors and passive telemetry paths.

Interface-family selection playbook

When uncertain, decide from behavior first: does caller push, pull, request+response, or broadcast observation? Then choose family and endpoint roles.

[TLM] family chooser checklist

Need backpressure and source push?
  -> put family

Need consumer-driven fetch?
  -> get/peek family

Need coupled request/response abstraction?
  -> transport family

Need observer fan-out with no return channel?
  -> analysis family

[UVM][TLM] anti-pattern detector

if design uses analysis write() but expects ack/flow status:
  wrong family likely

if design uses put/get for monitor fan-out:
  wrong family likely

if design wraps request and response into separate ad-hoc endpoints:
  transport may simplify contract

Key takeaways

• TLM families encode interaction semantics; choose by behavior model first.

• Role objects port/export/imp are consistent across families and preserve call/provider intent.

• Transport and analysis solve very different needs despite both carrying transactions.

• Correct family choice reduces boilerplate adapters and debug complexity.

Common pitfalls

• Using analysis for flow-controlled command paths.

• Using put/get for passive monitor fan-out that should be analysis.

• Ignoring blocking vs non-blocking flavor in API contracts.

• Choosing family by habit rather than communication semantics.