Interview Question · Code Reading

Lock vs Grab on a Busy Sequencer

L1 JuniorL2 Mid-Leveluvmsequencesarbitration

The interviewer asks

Two sequences share a sequencer when an urgent one arrives. Predict the order the driver sees with lock() and with grab().

systemverilog

// Sequences A and B each send 4 items on one sequencer, from time 0.
// At 25 ns an urgent sequence U starts and sends 2 items:
task body();                                // in urgent_seq
  if (use_grab) grab(); else lock();
  super.body();                             // send U0, U1
  if (use_grab) ungrab(); else unlock();
endtask
// The driver takes 10 ns per item. In what order does the driver see items?

Reveal the Model Answer

By the usual description, a grab takes the very next slot, while a lock waits behind B1, which was already queued. In both cases A1, already with the driver, finishes first. On uvm-core 2020.3.1 the run shows the same order for both: A0 B0 A1 U0 U1 B1. This library grants any lock request at the next arbitration unless another lock blocks it. Here, a grab differs only by going ahead of locks that are already waiting.

Where Lock and Grab Put a RequestThree sequences ask for a lock at different times. Arrows show lock requests entering the queue, and a grant putting a sequence on lock_list.

B locks0 ns (illustrative)
B's is the only lock request and nothing blocks it, so it is granted at once. B sends B0 to B3.
Follow the calls, values and waits
1. data B: Sequence B → Lock requests
2. data B: Lock requests → lock_list
A asks15 ns (illustrative)
lock() appends A's request to the back of the queue. B's lock blocks it, so A waits.
Follow the calls, values and waits
1. data A: Sequence A → Lock requests
2. Waiting: Sequence A — blocked by B
C asks with lock()25 ns (illustrative)
C's request goes behind A's. The queue holds A, then C.
Follow the calls, values and waits
1. data C: Sequence C → Lock requests
2. Waiting: Sequence C — blocked by B
B releases40 ns (illustrative)
B unlocks after B3. The first unblocked lock request in the queue is A's, so A goes next and C after it.
Follow the calls, values and waits
1. data A: Lock requests → lock_list
2. Waiting: Sequence C — blocked by A
3. Released: Sequence A
4. Released: Sequence C
Had C called grab()25 ns (illustrative)
grab() puts C's request at the front, ahead of A's. C still waits for B, then goes first: B, C, A.
Follow the calls, values and waits
1. data C, to the front: Sequence C → Lock requests
2. data C: Lock requests → lock_list
3. Waiting: Sequence A — blocked by C
4. Released: Sequence A
5. Released: Sequence C

Read the diagram as text

Sequence A: lock() at 15 ns
Sequence B: lock() at 0 ns
Sequence C: lock() or grab() at 25 ns
Lock requests: in the arbitration queue
lock_list: who holds a lock

Sequence A → Lock requests: request
Sequence B → Lock requests: request
Sequence C → Lock requests: request
Lock requests → lock_list: grant

Only other lock requests see the difference between lock and grab.

The same traffic on two sequencers: the urgent sequence uses lock() on one and grab() on the other.

RUNVerilator + UVM 2020.3.1 · simulator service

Edit the code, then run it

Expected among the UVM messages: lock: A0 B0 A1 U0 U1 B1 A2 B2 A3 B3 grab: A0 B0 A1 U0 U1 B1 A2 B2 A3 B3

`timescale 1ns/1ns
`include "uvm_macros.svh"
import uvm_pkg::*;
class bus_item extends uvm_sequence_item;
  `uvm_object_utils(bus_item)
  string tag;
  function new(string name = "bus_item"); super.new(name); endfunction
endclass
class tag_seq extends uvm_sequence #(bus_item);
  `uvm_object_utils(tag_seq)
  string prefix; int n;
  function new(string name = "tag_seq"); super.new(name); endfunction
  task body();
    for (int i = 0; i < n; i++) begin
      req = bus_item::type_id::create("req");
      start_item(req);
      req.tag = $sformatf("%s%0d", prefix, i);
      finish_item(req);
    end
  endtask
endclass
// Takes the sequencer for two items, with lock() or grab().
class urgent_seq extends tag_seq;
  `uvm_object_utils(urgent_seq)
  bit use_grab;
  function new(string name = "urgent_seq"); super.new(name); endfunction
  task body();
    if (use_grab) grab(); else lock();
    super.body();
    if (use_grab) ungrab(); else unlock();
  endtask
endclass
class log_driver extends uvm_driver #(bus_item);
  `uvm_component_utils(log_driver)
  string order;
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  task run_phase(uvm_phase phase);
    forever begin
      seq_item_port.get_next_item(req);
      #10 order = {order, " ", req.tag};
      seq_item_port.item_done();
    end
  endtask
endclass
class lg_test extends uvm_test;
  `uvm_component_utils(lg_test)
  uvm_sequencer #(bus_item) sqr[2];
  log_driver drv[2];
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  function void build_phase(uvm_phase phase);
    foreach (sqr[i]) begin
      sqr[i] = uvm_sequencer #(bus_item)::type_id::create($sformatf("sqr%0d", i), this);
      drv[i] = log_driver::type_id::create($sformatf("drv%0d", i), this);
    end
  endfunction
  function void connect_phase(uvm_phase phase);
    foreach (sqr[i]) drv[i].seq_item_port.connect(sqr[i].seq_item_export);
  endfunction
  // Two A and B streams on one sequencer; an urgent sequence arrives at 25 ns.
  task traffic(int k, bit use_grab);
    tag_seq a = tag_seq::type_id::create("a");
    tag_seq b = tag_seq::type_id::create("b");
    urgent_seq u = urgent_seq::type_id::create("u");
    a.prefix = "A"; a.n = 4;
    b.prefix = "B"; b.n = 4;
    u.prefix = "U"; u.n = 2; u.use_grab = use_grab;
    fork
      a.start(sqr[k]);
      b.start(sqr[k]);
      #25 u.start(sqr[k]);
    join
  endtask
  task run_phase(uvm_phase phase);
    phase.raise_objection(this);
    fork
      traffic(0, 0);   // lock()
      traffic(1, 1);   // grab()
    join
    $display("lock:%s", drv[0].order);
    $display("grab:%s", drv[1].order);
    phase.drop_objection(this);
  endtask
endclass
module tb;
  initial run_test("lg_test");
endmodule

Self-Check

Tick each key point you covered in your answer.

Key point 1 By the usual description, a grab takes the very next slot, while a lock waits behind B1, which was already queued. Key point 2 In both cases A1, already with the driver, finishes first. Key point 3 On uvm-core 2020.3.1 the run shows the same order for both: A0 B0 A1 U0 U1 B1. Key point 4 This library grants any lock request at the next arbitration unless another lock blocks it. Key point 5 Here, a grab differs only by going ahead of locks that are already waiting.

What Interviewers Listen For (Junior)

A good junior answer says both give one sequence the driver alone until it unlocks. It adds that grab jumps the queue, while lock waits its turn.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

What IfProve ItBreak ItCompare

Lock vs Grab on a Busy Sequencer
CompareSequencer Arbitration ModesL2 Mid-Level
Compare the sequencer arbitration modes. When does a sequence's priority matter?
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

The default, UVM_SEQ_ARB_FIFO, grants requests in arrival order and ignores priority. UVM_SEQ_ARB_WEIGHTED picks randomly with priority as the weight. The strict modes always serve the highest priority first, by arrival or at random. UVM_SEQ_ARB_RANDOM ignores priority, and UVM_SEQ_ARB_USER calls your own function. Set the mode with set_arbitration().

One Queue, Two Rules for ChoosingThree sequences with priorities 100, 200 and 300, run once under FIFO and once under STRICT_FIFO. Arrows show requests entering the arbitration queue and granted items leaving it.

Three requests0 ns (illustrative)
The three sequences start in the same time step. Their requests enter the queue in the order A, B, C.
Follow the calls, values and waits
data A0: Sequence A → Arbitration queue
data B0: Sequence B → Arbitration queue
data C0: Sequence C → Arbitration queue
Waiting: Sequence A — waiting for a grant
Waiting: Sequence B — waiting for a grant
Waiting: Sequence C — waiting for a grant
FIFO: the oldest wins
The driver asks for an item. FIFO grants the oldest request, A0, without reading any priority.
Follow the calls, values and waits
call get_next_item: Driver → Arbitration queue
data A0: Arbitration queue → Driver
Released: Sequence A
A asks again, at the back
When A0 is done, A's next request joins the queue behind B0 and C0. B0 and C0 win next, so the three take turns: A0 B0 C0 A1 B1 C1 A2 B2 C2.
Follow the calls, values and waits
data A1: Sequence A → Arbitration queue
data B0: Arbitration queue → Driver
data C0: Arbitration queue → Driver
Released: Sequence B
Released: Sequence C
STRICT_FIFO: the same queue
The third scenario starts the same way. STRICT_FIFO counts only the highest-priority requests, so C0 wins although it is the newest.
Follow the calls, values and waits
data A0: Sequence A → Arbitration queue
data B0: Sequence B → Arbitration queue
data C0: Sequence C → Arbitration queue
data C0: Arbitration queue → Driver
Waiting: Sequence A — waiting for a grant
Waiting: Sequence B — waiting for a grant
Released: Sequence A
Released: Sequence B
Released: Sequence C
C keeps winning
C's next request is in the queue before each arbitration, so C1 and C2 follow. Then B, then A: C0 C1 C2 B0 B1 B2 A0 A1 A2.
Follow the calls, values and waits
data C1: Sequence C → Arbitration queue
data C1: Arbitration queue → Driver
data C2: Sequence C → Arbitration queue
data C2: Arbitration queue → Driver

Read the diagram as text
Sequence A: priority 100
Sequence B: priority 200
Sequence C: priority 300
Arbitration queue: oldest request first
Driver: one item per clock
Sequence A → Arbitration queue: start_item
Sequence B → Arbitration queue: start_item
Sequence C → Arbitration queue: start_item
Arbitration queue → Driver: granted item

The queue is the same in both runs. Only the rule that picks from it changed.

Self-Check
Tick each key point you covered in your answer.
Key point 1 The default, UVM_SEQ_ARB_FIFO, grants requests in arrival order and ignores priority. Key point 2 UVM_SEQ_ARB_WEIGHTED picks randomly with priority as the weight. Key point 3 The strict modes always serve the highest priority first, by arrival or at random. Key point 4 UVM_SEQ_ARB_RANDOM ignores priority, and UVM_SEQ_ARB_USER calls your own function. Key point 5 Set the mode with set_arbitration().
Misconception

"Priority always matters, even in the default mode."

FIFO, the default, sends items in request order whatever their priority.

Source Verification Academy, UVM Cookbook, Sequences/Arbitration (PDF p275)
- Lesson U5.1Arbitration and Priority
What IfStrict Priority and a Starving SequenceL2 Mid-Level
What if a high-priority sequence keeps asking under UVM_SEQ_ARB_STRICT_FIFO?

Reveal the Model Answer

Lower priorities wait until it stops asking, so they starve. That is fine for a short interrupt burst, but not for long background traffic. UVM_SEQ_ARB_WEIGHTED shares the driver in proportion to priority, with no bound on any one wait. If a low-priority sequence has a deadline, check it with a timeout.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Lower priorities wait until it stops asking, so they starve. Key point 2 That is fine for a short interrupt burst, but not for long background traffic. Key point 3 UVM_SEQ_ARB_WEIGHTED shares the driver in proportion to priority, with no bound on any one wait. Key point 4 If a low-priority sequence has a deadline, check it with a timeout.

Misconception

"Priorities work in the default mode."

FIFO, the default, never reads priorities. Set a strict or weighted mode with set_arbitration() first.

Source Lesson U5.1 key points
- Lesson U5.1Arbitration and Priority
- Problem U5.1.1Catch the Sequencers That Grant Out of Turn
What IfAn Interrupt Service SequenceL2 Mid-Level
What if the urgent sequence services an interrupt? How do you structure it?

Reveal the Model Answer

Run it in the background for the whole test. It waits for the interrupt, then grabs the bus sequencer and reads the status. It services the cause, clears the interrupt and ungrabs. Normal traffic pauses only for that window. Use grab when the interrupt must jump ahead of queued traffic, and lock when waiting a turn is acceptable.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Run it in the background for the whole test. Key point 2 It waits for the interrupt, then grabs the bus sequencer and reads the status. Key point 3 It services the cause, clears the interrupt and ungrabs. Key point 4 Normal traffic pauses only for that window. Key point 5 Use grab when the interrupt must jump ahead of queued traffic, and lock when waiting a turn is acceptable.

Wrong Altitude

"Poll the interrupt line from the main sequence between items."

It ties the main scenario to interrupt timing, and the response latency depends on how long each item takes.

Source Accellera, UVM 1.1 User's Guide, §6.5.1 Implementing Complex Scenarios: interrupt sequences (PDF p149)
Prove ItSolve U16.4.1: The Interrupt That Clears ItselfSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem U16.4.1
Break ItTwo Locks That DeadlockedL3 Senior
How can two virtual sequences that each lock two sequencers hang the test?
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

Sequence one locks the AXI sequencer, then asks for the UART one. Sequence two has already locked UART and now asks for AXI. Each lock() blocks until it is granted, so both wait forever. Always take locks in one fixed order across the bench, or take one lock at a time.

Two Processes, Two Keys, Opposite OrdersThe same cycle with plain semaphores: two processes take two keys in opposite orders. A dashed badge is a get(1) call; a solid badge is a key handed over or returned.

Each takes its first keyt=0 (illustrative)
P1 takes the bus key and P2 takes the mem key. Both succeed, because each semaphore had its key free.
Follow the calls, values and waits
data bus key: bus → P1
data mem key: mem → P2
Each asks for the other keyt=1 (illustrative)
P1 calls mem.get(1) and P2 calls bus.get(1). Each key is held by the other process, so both block.
Follow the calls, values and waits
call get(1): P1 → mem
call get(1): P2 → bus
Waiting: P1 — waiting for mem
Waiting: P2 — waiting for bus
Deadlockt=1 and later (illustrative)
Neither process can reach its put(), so neither key ever returns. If nothing else is scheduled, the simulation just ends here.
One order: both start with bust=0 (illustrative)
Now both processes take bus first. One of them, here P1, gets it. P2 blocks at bus while it holds nothing.
Follow the calls, values and waits
data bus key: bus → P1
call get(1): P2 → bus
Waiting: P2 — waiting for bus
Released: P1
Released: P2
P1 finishes, then P2 runst=1 and later (illustrative)
mem is free, so P1 takes it, finishes its work and returns both keys. P2 then gets bus, and mem after it.
Follow the calls, values and waits
data mem key: mem → P1
return mem key: P1 → mem
return bus key: P1 → bus
data bus key: bus → P2
Released: P2

Read the diagram as text
bus: semaphore, one key
P1: bus, then mem
P2: mem, then bus
mem: semaphore, one key
P1 → bus: get / put
P1 → mem: get / put
P2 → bus: get / put
P2 → mem: get / put

A deadlock needs a cycle of waits. Two sequences that lock two sequencers in opposite orders form the same cycle. One order for everyone breaks it.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Sequence one locks the AXI sequencer, then asks for the UART one. Key point 2 Sequence two has already locked UART and now asks for AXI. Key point 3 Each lock() blocks until it is granted, so both wait forever. Key point 4 Always take locks in one fixed order across the bench, or take one lock at a time.
Missed Corner

"UVM detects the deadlock and reports it."

Nothing detects it. lock() simply blocks, and the test runs until the timeout.

Source Verification Academy, UVM Cookbook, Sequences/LockGrab: lock is blocking until granted (PDF p284)
- Lesson U5.2Lock, Grab and Relevance
- Lesson U10.1Coordinate Two Sequencers
Prove ItSolve U5.1.1: Catch the Sequencers That Grant Out of TurnSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem U5.1.1

What People Get Wrong

Common wrong answers and why they fail.

Misconception

"grab() interrupts the item the driver is already driving."

Nothing takes back an item the driver already holds. In the run, A1 finishes before U0 starts.

Source Measured: the run on this question (A1 completes before U0), uvm-core 2020.3.1 on Verilator 5.052

Tool as Truth

"A lock always waits until every earlier request has been served."

That is how the Cookbook describes it. uvm-core 2020.3.1 grants an unblocked lock at the next arbitration, so B1 waited here.

Source uvm-core 2020.3.1 (IEEE 1800.2 library) source, seq/uvm_sequencer_base.svh, grant_queued_locks: find_first_index of any unblocked SEQ_TYPE_LOCK request

Missed Corner

Calls lock() and forgets unlock() on an error path.

The sequencer stays locked, and every other sequence waits forever.

Source Verification Academy, UVM Cookbook, Sequences/LockGrab: unlock must be called (PDF p284)

Half-Truth

"Just give the urgent sequence a higher priority instead."

Under the default FIFO arbitration, priority is ignored. It needs a strict or weighted mode, and it still is not exclusive.

Source Verification Academy, UVM Cookbook, Sequences/Arbitration: SEQ_ARB_FIFO ignores priority (PDF p275)

Find Your Next Track

Put Your Skills to Work

Prepare to Explain Your Thinking

An Idea to Try? Pick a Tool.

Lock vs Grab on a Busy Sequencer

Your Answer

Self-Check

What Interviewers Listen For (Junior)

What Interviewers Listen For (Mid-Level)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What People Get Wrong

Learn It, Then Prove It

The Question

Your Answer

Self-Check

What Interviewers Listen For (Junior)

What Interviewers Listen For (Mid-Level)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What People Get Wrong

Learn It, Then Prove It