Part 11 · Senior Prep · Intermediate

Interview Q&A: Handshake & Responses

Model answers on pull model, start_item/finish_item, get_next_item/item_done, pipelined reads, and response routing.

Pull model handshake

Q: Explain start_item / finish_item

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: start_item / finish_item?

A:
  MECHANISM:  Sequence offers item at start_item; driver get_next_item when ready;
              driver item_done completes transfer; finish_item unblocks sequence.
  MOTIVATION:  Driver owns pin timing; sequence owns scenario content — pull model.
  WHEN:       Every driven transaction through uvm_driver #(ITEM).
  PITFALL:    finish_item before driver item_done — races item reuse.
  EXAMPLE:    seq: start_item → randomize → finish_item blocks until drv item_done.

Q: What happens if the driver never calls item_done?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Missing item_done?

A:
  MECHANISM:  finish_item waits forever; sequence thread stuck; objection may never drop.
  MOTIVATION:  item_done is the completion contract — without it pull model breaks.
  WHEN:       Debug any hang at finish_item — first check driver run_phase loop.
  PITFALL:    return/break from drive task without item_done on all paths.
  EXAMPLE:    Driver waits for ready forever — add timeout + item_done with error flag.

Q: Why is this a pull model, not push?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Pull vs push?

A:
  MECHANISM:  Driver pulls when DUT ready (get_next_item); push would flood driver
              when DUT applies backpressure.
  MOTIVATION:  Matches ready/valid protocols — sequence cannot outrun driver capacity.
  WHEN:       Always for uvm_driver — seq_item_port is pull API.
  PITFALL:    Using put_port on seq_item_port — wrong API, compile or runtime failure.
  EXAMPLE:    AXI driver waits for awready before completing write item — pull natural.

diagram

[INT][SENIOR][UVM] handshake pairing (whiteboard)

  SEQUENCE          SEQUENCER           DRIVER
  start_item(req) → queue item    →   get_next_item(req)
  finish_item(req)← wait done     ←   item_done()

  PAIRING: one get_next_item ↔ one item_done per item
  VIOLATION: double get_next_item without item_done → corruption

Key takeaways

Pull model: driver requests when ready; finish_item blocks until item_done.
Missing item_done is the #1 sequence hang — check all driver exit paths.
Never use put() on seq_item_port — get_next_item/item_done only.

Common pitfalls

finish_item before randomize — driver may see stale fields.
Starting sequence before run_phase — driver not in get_next_item loop yet.

Responses and pipelining

Q: How do read responses get back to the sequence?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Read data back to sequence?

A:
  MECHANISM:  Driver samples rdata into req object during drive; item_done(req) passes
              same item handle back — sequence reads req.rdata after finish_item.
  MOTIVATION:  Single item object carries request + response fields round-trip.
  WHEN:       APB/AXI read: randomize addr in seq; driver fills rdata; seq checks after finish_item.
  PITFALL:    item_done() with no arg when req was modified — use item_done(req) explicitly.
  EXAMPLE:    apb_rd_seq: finish_item(req); if (req.rdata != exp) uvm_error(...).

Q: What is try_next_item / pipelining?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Pipelined items?

A:
  MECHANISM:  Driver may get_next_item next req before item_done prev — multiple
              in-flight items if protocol and sequencer allow.
  MOTIVATION:  High-throughput buses pipeline address and data phases.
  WHEN:       Explicit protocol support + driver designed for N in-flight items.
  NOT WHEN:   Simple APB — one item at a time, strict pairing.
  PITFALL:    Pipelining without sequencer arbitration awareness — item order bugs.
  EXAMPLE:    AXI outstanding writes: driver item_done(write) while read still on bus.

Q: How do objections relate to the handshake?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Objections and handshake?

A:
  MECHANISM:  Driver run_phase loop runs during run_phase task phase; test raises
              objection so run_phase (and driver) active before seq.start().
  MOTIVATION:  seq.start before run_phase → driver not pulling → hang at finish_item.
  WHEN:       Test run_phase: raise_objection → seq.start → drop after seq done.
  PITFALL:    Starting seq in connect_phase or build_phase — no driver execution yet.
  EXAMPLE:    base_test run_phase raises, starts seq, drops — driver loop concurrent.

Q: get_next_item vs try_next_item?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: get_next_item vs try_next_item?

A:
  MECHANISM:  get_next_item blocks until item available; try_next_item returns
              immediately with success/fail — non-blocking poll.
  MOTIVATION:  Driver needs idle cycles when no stimulus — try_next_item + delay.
  WHEN:       Optional stimulus injection alongside clock generation in same driver.
  PITFALL:    Busy-loop try_next_item without #delay — zero-time spin burns sim.
  EXAMPLE:    while (!try_next_item(req)) @(posedge vif.clk); // idle when no seq traffic

systemverilog

// read response pattern — expect in interviews
task drive_read(apb_item req);
  // drive addr phase, sample rdata into req
  req.rdata = vif.prdata;
  seq_item_port.item_done(req);  // same handle, now with rdata
endtask

Key takeaways

Read responses return via same item handle after finish_item unblocks.
Pipelining = multiple in-flight items — only when protocol supports it.
Raise objection before seq.start so driver run_phase is active.

Common pitfalls

item_done() without req arg when driver modified item — response lost.
seq.start in build_phase — classic handshake hang question.

Practice this lessonQuestions tagged for this topic in the bank