Put, Get & Transport Interview Q&A

[INT][SENIOR][UVM] MODEL ANSWER

Q: analysis_port vs put_port?

A:
  MECHANISM:  analysis_port broadcast write() to all subscribers — non-blocking, no
              backpressure. put_port is point-to-point blocking — put() waits until
              implementer accepts.
  MOTIVATION:  Monitors fan out to scoreboard + coverage without knowing consumers.
              Driver/sequencer pull model uses blocking put/get for rate matching.
  WHEN:       analysis for observe-and-check pipelines; put/get for driver-style
              pipelines or TLM FIFO bridges between rate-mismatched components.
  PITFALL:    Expecting analysis_port to block — multiple subscribers, no grant protocol.
  EXAMPLE:    mon.ap → scb + cov (analysis). Producer put_port → uvm_tlm_fifo → consumer
              get_port (blocking rate match).

[INT][SENIOR][UVM] MODEL ANSWER

Q: Pull model handshake?

A:
  MECHANISM:  Driver seq_item_port.get_next_item(req) blocks until sequencer provides
              item. Driver drives bus, calls item_done(). Sequencer finish_item unblocks.
  MOTIVATION:  Driver owns pin timing; sequence owns content — pull ensures driver
              never gets next item until previous completed (unless pipeline config).
  WHEN:       Every uvm_driver #(ITEM) run_phase loop. Optional pipelined driver may
              get_next_item with outstanding before item_done for throughput.
  PITFALL:    finish_item before driver item_done — sequence races ahead, item reuse
              corruption on next randomize.
  EXAMPLE:    seq start_item → randomize → finish_item blocks until drv item_done after
              AW/W/B handshake completes on bus.

[INT][SENIOR][UVM] MODEL ANSWER

Q: transport port?

A:
  MECHANISM:  uvm_transport_port combines request and response in one transport() call —
              blocking bidirectional transaction in single method invocation.
  MOTIVATION:  Some protocols need request→response atomically (register read returns
              data in same call) — transport models RPC-style interaction.
  WHEN:       Register adapter layers, memory model RPC, TLM-2.0 style approximations
              in UVM 1.x transport idiom.
  PITFALL:    Using transport where simple put/get suffices — adds coupling and debug
              complexity without benefit for one-way monitor streams.
  EXAMPLE:    reg_adapter transport: frontdoor read sends addr, returns data in same
              transport call to bus model.

[INT][SENIOR][UVM] MODEL ANSWER

Q: blocking vs non-blocking?

A:
  MECHANISM:  Blocking: put/get/transport wait for completion. Non-blocking: try_put/
              try_get return immediately with status flag. Analysis write is effectively
              non-blocking broadcast (no wait for subscriber processing).
  MOTIVATION:  Rate matching needs blocking; fire-and-forget observation needs non-blocking.
  WHEN:       Blocking for driver-sequencer and FIFO bridges. Non-blocking for high-
              throughput models where drop/retry acceptable. Analysis always non-blocking.
  PITFALL:    Non-blocking put in loop without checking status — silent transaction drop
              when FIFO full.
  EXAMPLE:    try_put to bounded FIFO: if (FULL) retry next cycle — models backpressure
              without blocking entire simulation thread incorrectly.

[INT][SENIOR][UVM] MODEL ANSWER

Q: uvm_tlm_fifo put/get?

A:
  MECHANISM:  FIFO implements both put_export and get_export — producer put_port connects
              to fifo put_export; consumer get_port connects to fifo get_export. FIFO
              buffers between rate-mismatched producer and consumer.
  MOTIVATION:  Monitor produces every cycle; scoreboard compares at slower rate — FIFO
              prevents loss without blocking monitor (bounded FIFO + try_put policy).
  WHEN:       Clock domain bridge, rate mismatch, pipeline between generator and driver.
  PITFALL:    Unbounded FIFO masks backpressure bug — memory blowup on long sims;
              bounded FIFO with try_put exposes flow control need.
  EXAMPLE:    mon write → analysis_fifo → scb get loop — decouples sample rate from
              compare rate across clock domains via metastability-safe FIFO.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Pipelined driver outstanding items?

A:
  MECHANISM:  Driver calls get_next_item before item_done on previous — multiple req
              handles in flight if protocol supports pipeline (AXI outstanding xactions).
  MOTIVATION:  Throughput — waiting for item_done before next get_next_item underutilizes
              bus bandwidth on pipelined protocols.
  WHEN:       AXI, PCIe, any protocol with outstanding transaction IDs. Driver tracks
              id→item map; item_done per response beat not per request only.
  PITFALL:    Pipeline depth unlimited — memory and scoreboard ordering complexity;
              cfg.max_outstanding limits pipeline depth.
  EXAMPLE:    AXI driver: 8 outstanding AW before any B — each B triggers item_done for
              corresponding item; sequencer finish_item per completed xaction.

[INT][SENIOR][UVM] MODEL ANSWER

Q: put/get instead of analysis for monitor?

A:
  MECHANISM:  put/get adds backpressure — monitor put blocks if scoreboard cannot accept.
              analysis write never blocks monitor.
  MOTIVATION:  If scoreboard must apply backpressure to slow monitor (rate limit test,
              bounded buffer DUT model), put/get enforces flow control.
  WHEN:       Rare in standard VIP — almost always analysis for monitor→scb. put/get
              when explicit rate matching or FIFO backpressure required.
  PITFALL:    Using put/get for standard monitor→scb — monitor blocks on scb compare
              latency, distorts cycle-accurate sampling timing.
  EXAMPLE:    Stress test with bounded DUT buffer: monitor put to scb blocks when DUT
              full — models real backpressure; analysis would overflow silently.