Part 11 · Senior Prep · Intermediate

Interview Q&A: Driver & Monitor

Model answers on uvm_driver run_phase loop, uvm_monitor sampling, driver vs monitor responsibilities, reset discipline, and error handling.

Driver and monitor roles

Q: What is the driver's job vs the monitor's?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Driver vs monitor?

A:
  MECHANISM:  Driver converts seq items to pin wiggles (stimulus). Monitor samples
              pins and emits transaction objects (observation) — never drives in standard UVM.
  MOTIVATION:  Separation enables passive reuse — monitor sees same view whether
              driver or RTL drives the bus.
  WHEN:       Active TB: both. Passive chip TB: monitor only on RTL-driven interface.
  PITFALL:    Monitor that assigns to vif outputs — corrupts passive observation truth.
  EXAMPLE:    AXI driver drives awvalid; monitor samples awvalid/awready and writes txn to ap.

Q: Describe the driver run_phase loop

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Driver run_phase loop?

A:
  MECHANISM:  forever: seq_item_port.get_next_item(req); drive_protocol(req);
              seq_item_port.item_done(req);
  MOTIVATION:  Pull model — driver requests work when ready for next beat.
  WHEN:       Every uvm_driver subclass — loop in run_phase task.
  PITFALL:    break/return from drive without item_done — sequence hangs at finish_item.
  EXAMPLE:    apb_driver: get_next_item → wait pready → drive paddr/pwrite → item_done.

Q: How does the monitor create transactions?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Monitor transaction creation?

A:
  MECHANISM:  run_phase forever @(edge or clock): sample vif signals; on complete
              beat/frame assemble txn object; ap.write(txn) — often clone per subscriber need.
  MOTIVATION:  Downstream scb/cov consume structured txns, not raw wires.
  WHEN:       Protocol-defined sample point — e.g. penable high for APB complete transfer.
  PITFALL:    Sampling on wrong phase — partial txn or double-count.
  EXAMPLE:    axi_mon: on aw handshake complete build aw_txn; on w last build full write txn.

diagram

[INT][SENIOR][UVM] driver vs monitor data flow

  STIMULUS PATH:  seq → sqr → drv → vif → DUT
  OBSERVE PATH:   DUT pins → mon → ap.write(txn) → scb/cov/predictor

  Driver never calls ap.write for checking — monitor is ground truth for DUT-visible behavior

Key takeaways

Driver actuates; monitor observes — never swap roles.
Driver loop: get_next_item → drive → item_done on every path.
Monitor samples at protocol-complete boundary — not arbitrary clock.

Common pitfalls

Driver logging txn to scoreboard directly — bypasses monitor truth.
Monitor driving enable signals — breaks passive chip integration.

Reset, timing, and errors

Q: How should driver and monitor handle reset?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Reset discipline in drv/mon?

A:
  MECHANISM:  Wait reset deassert before main loop; idle pins during reset; monitor
              may flush partial txn or ignore samples while reset active.
  MOTIVATION:  Spurious transactions during reset pollute scoreboard and coverage.
  WHEN:       wait(!vif.rst_n) or wait for reset phase completion before loop entry.
  PITFALL:    Driver starts driving while rst_n low — X propagation and false scb mismatches.
  EXAMPLE:    drv run_phase: @(negedge vif.rst_n); forever get_next_item...

Q: How does the driver handle protocol errors or timeouts?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Driver error handling?

A:
  MECHANISM:  Bounded wait with timeout counter; on timeout set req.status=ERR,
              item_done(req), uvm_error — sequence can react or test fails.
  MOTIVATION:  Infinite wait(pready) causes finish_item hang — silent regression killer.
  WHEN:       Every wait on DUT-ready signal in driver — always bounded or fatal.
  PITFALL:    Infinite wait without timeout — nightly farm timeout with zero UVM_ERROR.
  EXAMPLE:    if (!wait_pready(1000)) begin req.status=TIMEOUT; item_done(req); return; end

Q: Should monitor and driver share the same virtual interface?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Shared vif for drv and mon?

A:
  MECHANISM:  Both get same virtual interface handle from config_db in build_phase.
  MOTIVATION:  Same pin view — monitor sees what driver drove (plus RTL response).
  WHEN:       Standard pattern: agent build sets/gets vif, passes to drv and mon.
  PITFALL:    Separate vif handles to different hierarchy paths — rare but breaks modport view.
  EXAMPLE:    agt build: get vif; uvm_config_db::set(this,"drv","vif",vif); same for mon.

Q: Clocking blocks — driver vs monitor?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Clocking blocks in drv/mon?

A:
  MECHANISM:  Interface clocking block defines drive (@cb) vs sample (@cb or #1step)
              regions for race-free pin access.
  MOTIVATION:  Avoid race between RTL and TB on same clock edge.
  WHEN:       Synchronous protocols — driver drives in output region, monitor samples input.
  PITFALL:    Mixing @(posedge clk) drive and sample on same edge — intermittent mismatches.
  EXAMPLE:    drv: vif.cb.awvalid <= 1; mon: sample awvalid/awready in cb input region.

systemverilog

// driver loop skeleton — whiteboard expectation
task run_phase(uvm_phase phase);
  @(negedge vif.rst_n);
  forever begin
    seq_item_port.get_next_item(req);
    drive(req);
    seq_item_port.item_done(req);
  end
endtask

Key takeaways

Reset wait before driver/monitor main loops — standard discipline.
Bounded waits in driver — every protocol ready check needs timeout path.
Shared vif via config_db; clocking blocks for race-free access.

Common pitfalls

Unbounded wait in drive task — #1 hang cause at finish_item.
Monitor sampling during reset — false scoreboard entries.

Practice this lessonQuestions tagged for this topic in the bank