put/get/transport Hub: Flow-Controlled Point-to-Point TLM

Overview

UVM point-to-point TLM gives a flow-controlled way to move transactions between exactly one initiator and one target. It models readiness and back-pressure directly, unlike analysis write() broadcast channels that are intentionally non-blocking and one-to-many.

This topic goes from basic method semantics to production integration: when to block, when to poll, when to inspect without consuming, when to use request-response transport, and how these ideas appear in sequencer-driver plumbing.

Sub-lessons in this topic

1. blocking-put-get - blocking_put and blocking_get semantics with natural back-pressure.

2. nonblocking-put-get - try_put/try_get and can_put/can_get polling patterns.

3. peek-vs-get - inspecting without consuming, then consuming deterministically.

4. transport-combined - transport() as one-call request+response abstraction.

5. sequencer-driver-tlm - seq_item_port/export pull handshake in drivers.

6. producer-consumer-patterns - decoupled pipeline designs with FIFO-like staging.

Method family map

Legend: [UVM] [TLM]

[TLM] point-to-point method families

blocking:
  put(t)            // producer waits until target accepts
  get(t)            // consumer waits until data available
  peek(t)           // waits, but does not consume
  transport(req,rsp)// waits for response

non-blocking:
  try_put(t) -> bit
  can_put() -> bit
  try_get(t) -> bit
  can_get() -> bit
  try_peek(t) -> bit
  can_peek() -> bit

[UVM][TLM] where this fits

monitor -> analysis_port.write() -> scoreboard/coverage   (broadcast, no flow control)
producer -> put/get/peek/transport target                 (point-to-point, flow controlled)
driver <-> sequencer seq_item_port/export                 (specialized pull TLM pattern)

choose based on communication contract:
  "deliver to many listeners quickly"       -> analysis
  "coordinate one producer and one target"  -> put/get/transport

Key takeaways

• Point-to-point TLM models readiness and back-pressure explicitly.

• Blocking methods consume simulation time while waiting; non-blocking methods return immediately.

• peek() inspects without consume; get() consumes.

• transport(req,rsp) bundles request and response in one abstraction.

Common pitfalls

• Using analysis write() where request-response semantics are required.

• Ignoring return values of non-blocking methods and silently dropping work.

• Treating peek() as consume and creating duplicate processing bugs.