Interview Q&A: Sequencer-Driver Handshake

[INT][SENIOR][UVM] MODEL ANSWER

Q: Sequencer-driver connection?

A:
  MECHANISM:  agent connect_phase: driver.seq_item_port.connect(sequencer.seq_item_export).
              seq_item_port is uvm_seq_item_pull_port on driver side.
  MOTIVATION:  TLM pull channel between arbitration (sqr) and execution (drv).
  WHEN:       Active agent only — passive agent has no seq_item connection.
  PITFALL:    Connecting in env instead of agent — breaks encapsulation.
  EXAMPLE:    agt.connect: if (cfg.is_active) drv.seq_item_port.connect(sqr.seq_item_export).

[INT][SENIOR][UVM] MODEL ANSWER

Q: get_next_item / item_done contract?

A:
  MECHANISM:  Exactly one item_done per get_next_item — pairs with sequence
              start_item/finish_item on other side of sequencer.
  MOTIVATION:  Invariant violation corrupts sequencer queue — mysterious hangs/crashes.
  WHEN:       Every item through standard uvm_driver — no exceptions on success path.
  PITFALL:    get_next_item twice without item_done — double grant corruption.
  EXAMPLE:    Loop: get → drive → item_done. Error path: get → timeout → item_done(status=ERR).

[INT][SENIOR][UVM] MODEL ANSWER

Q: seq_item_port vs mailbox?

A:
  MECHANISM:  seq_item_port integrates sequencer arbitration, sequence IDs, and
              finish_item blocking — mailbox is untyped FIFO with no UVM semantics.
  MOTIVATION:  UVM sequences need arbitration + objection context + response routing.
  WHEN:       Always for uvm_driver — mailbox breaks sequence library and lock semantics.
  NOT WHEN:   Non-UVM BFM outside component hierarchy — plain SV channel OK.
  PITFALL:    Custom mailbox between seq and drv — reimplements broken half of UVM.
  EXAMPLE:    VIP using mailbox instead of seq_item_port — seq.finish_item never unblocks correctly.

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

  SEQ.start_item → SQR queue → DRV.get_next_item(req)
  DRV.drive(req) → DRV.item_done(req) → SEQ.finish_item unblocks

  INVARIANT: one grant → one completion → one finish_item

[INT][SENIOR][UVM] MODEL ANSWER

Q: Driver-side hang debug?

A:
  MECHANISM:  Driver stuck in drive task wait OR never reached get_next_item OR
              run_phase not started (objection/objection phase issue).
  MOTIVATION:  Sequence sees finish_item hang — root cause often in drive wait.
  STEPS:      1) Last driver log line. 2) Which wait: reset, ready, grant?
              3) vif connected? 4) item_done on all exit paths? 5) UVM_HIGH on drv.
  PITFALL:    Blaming sequencer when driver infinite-waits on pready.
  EXAMPLE:    Log shows 'waiting pready' forever — DUT stall, not sequence bug.

[INT][SENIOR][UVM] MODEL ANSWER

Q: item_done with response?

A:
  MECHANISM:  Driver modifies req fields (rdata, status) before item_done(req);
              same handle returns to sequence after finish_item unblocks.
  MOTIVATION:  Request/response in one item object — no separate response port needed for simple buses.
  WHEN:       Read transactions, status/error flags back to sequence.
  PITFALL:    item_done() with no argument when req modified — use item_done(req) explicitly.
  EXAMPLE:    req.rdata = vif.rdata; req.status = OK; item_done(req);

[INT][SENIOR][UVM] MODEL ANSWER

Q: item_done from fork?

A:
  MECHANISM:  Discouraged — completion should occur in same thread flow as get_next_item
              unless protocol explicitly pipelines with careful ordering.
  MOTIVATION:  Race on seq_item_port state if multiple threads complete same item.
  WHEN:       Rare pipelined drivers with documented N-in-flight policy.
  PITFALL:    fork drive + main thread item_done — double completion or never complete.
  EXAMPLE:    Simple driver: no fork — linear get/drive/done in run_phase loop.

[INT][SENIOR][UVM] MODEL ANSWER

Q: put() on seq_item_port?

A:
  MECHANISM:  put() is push-side API — NOT used on standard uvm_driver seq_item_port.
              Driver uses get_next_item (pull) and item_done (complete).
  MOTIVATION:  Interview trap — wrong API name signals misunderstanding of pull model.
  WHEN:       Never on driver seq_item_port in canonical UVM.
  PITFALL:    Confusing with TLM put_port on other components — different context.
  EXAMPLE:    Interviewer asks 'driver put_port?' — correct: get_next_item/item_done pull API.