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?
[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
[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?
[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).[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 atomicKey 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?
[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?
[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?
[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.