Part 11 · Senior Prep · Intermediate

Interview Q&A: Sequencer Arbitration

Model answers on why arbitration exists, FIFO default interleaving, lock/grab/unlock, set_arbitration modes, priority, and starvation triage.

Arbitration fundamentals

Q: Why does one sequencer need arbitration?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Why sequencer arbitration?

A:
  MECHANISM:  One driver, one interface — many sequences may run concurrently on
              the same sequencer; arbiter picks which start_item proceeds next.
  MOTIVATION:  Background traffic + directed setup on same bus without separate drivers.
  WHEN:       Multiple seq.start(sqr) on one agent — stress + prog + default seq.
  PITFALL:    Assuming sequences run serially — default FIFO interleaves at item boundary.
  EXAMPLE:    bg_axi_seq and reg_prog_seq both on axi_sqr — items interleave unless locked.

Q: Explain lock vs grab

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: lock vs grab?

A:
  MECHANISM:  lock() blocks other sequences from winning arbitration until unlock();
              grab() is like lock but lower priority sequences already mid-item may finish.
  MOTIVATION:  Atomic multi-beat register programming — no background item between beats.
  WHEN:       lock() for strict atomic block (poll status loop); grab() when soft exclusion OK.
  PITFALL:    Forgotten unlock() — all other sequences block forever at start_item.
  EXAMPLE:    prog_seq: lock  4× start_item (burst)  unlock; bg_seq blocked entire window.

Q: What does set_arbitration control?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: set_arbitration modes?

A:
  MECHANISM:  UVM_SEQ_ARB_FIFO (default), WEIGHTED, RANDOM, STRICT_FIFO, USER —
              determines how pending start_item requests compete.
  MOTIVATION:  FIFO for fair interleave; WEIGHTED when background should lose often;
              STRICT_FIFO when order of sequence arrival must be preserved exactly.
  WHEN:       Default FIFO for most TBs; WEIGHTED when high-priority traffic must dominate.
  PITFALL:    Changing arbitration to 'fix' a lock bug — usually forgotten unlock instead.
  EXAMPLE:    sqr.set_arbitration(UVM_SEQ_ARB_WEIGHTED); bg_seq.set_priority(-1).
diagram
[INT][SENIOR][UVM] arbitration timeline (whiteboard)

  bg_seq:     [item1]     [item2]     [item3]
  prog_seq:       [lock][i1][i2][i3][unlock]
  test_seq:   [item1]              [item2]

  Without lock: prog beats interleave with bg — register corruption risk
  With lock:    prog window is atomic

Key takeaways

  • One driver = serialized items; multiple sequences = arbitration at start_item.

  • lock/grab for atomic multi-item windows; unlock is mandatory.

  • Default FIFO interleaves — do not assume sequence-level serialization.

Common pitfalls

  • Forgotten unlock — #1 arbitration hang cause.

  • Using lock for entire test duration — starves background traffic unnecessarily.


Priority and starvation debug

Q: How do you debug sequence starvation?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Sequence starvation debug?

A:
  MECHANISM:  Starvation = sequence blocked at start_item — another seq holds lock,
              or priority/arb mode never selects it, or driver not consuming items.
  MOTIVATION:  Distinguish arbitration stall from driver hang from objection leak.
  WHEN:       Hang after adding lock, new background seq, or priority change.
  STEPS:      1) UVM sequencer verbosity — who holds lock? 2) display_objections.
              3) Driver get_next_item log. 4) Audit unlock on all paths including break.
  PITFALL:    Increasing timeout instead of finding forgotten unlock in error branch.
  EXAMPLE:    prog_seq catch block exits without unlock — bg_seq starves forever.

Q: When would you raise sequence priority?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Sequence priority?

A:
  MECHANISM:  set_priority(int) influences WEIGHTED/STRICT arbitration selection.
  MOTIVATION:  Interrupt handler seq must preempt background bulk traffic occasionally.
  WHEN:       WEIGHTED arbitration + latency-sensitive seq alongside filler seq.
  NOT WHEN:   FIFO default with lock for atomic work — priority adds confusion.
  PITFALL:    High priority on everything — priority becomes meaningless.
  EXAMPLE:    irq_resp_seq.set_priority(10); bulk_seq.set_priority(-5); WEIGHTED arb.

Q: Can two sequencers share one driver?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Two sequencers, one driver?

A:
  MECHANISM:  No — one seq_item_port per driver; one sequencer per driver pair.
  MOTIVATION:  Arbitration is per-sequencer queue; sharing would break pull model.
  WHEN:       Need two streams — use two agents (different interfaces) or one sequencer
              with arbitration/lock on the single shared bus.
  PITFALL:    Trying to connect two sequencers to one driver — unsupported, race bugs.
  EXAMPLE:    Dual AXI masters = two agents, two drivers, two sequencers — not one driver.

Key takeaways

  • Starvation triage: lock holder → driver pull → objections — in that order.

  • Priority matters only with non-FIFO arbitration modes.

  • One sequencer per driver — use lock for shared-bus atomicity.

Common pitfalls

  • unlock missing in exception path — use try/finally pattern mentally.

  • Blaming driver when prog_seq still holds lock from 1000 cycles ago.