Ten high-frequency questions on the item handshake, item_done(rsp) and the response queue, pipelined drivers, lock versus grab, arbitration, virtual sequences, reset and randomization scope.
On this page
The sequences round is where interviewers dig for hands-on scars. "Explain start_item and finish_item" is a warm-up; the real questions are about what the sequencer does when you get the handshake slightly wrong: a missing item_done, a response nobody reads, a lock that waits behind the wrong thing, a reset that leaves a zombie sequence.
Senior answers name the handshake step by step, give the library's exact reaction (often a specific message), and know where UVM 1.2 and IEEE 1800.2 differ. The DMA bench supplies the examples: a virtual sequence with no virtual sequencer, an interrupt handler that grabs the APB sequencer, and a driver that forgets item_done on purpose.
The questions
Walk me through start_item, finish_item, get_next_item and item_done.
The driver calls item_done(rsp) for every read. What can go wrong?
How does a pipelined driver return responses out of the handshake?
lock() versus grab(): what is the difference?
You raised one sequence's priority and nothing changed. Why?
Do you need a virtual sequencer to run a virtual sequence?
A reset hits mid-test. How do you stop the running sequences?
A sequence does `req.randomize() with { len == len; }` and len is random every time. Why?
A child sequence's pre_body never runs. Why?
How should a test pass configuration to a sequence?
Rapid fire
Check yourselfA register sequence does 20 reads through a driver that calls item_done(rsp) and never calls get_response(). It passes on one simulator and errors on another. Why?
The response queue holds 8. UVM 1.2 reports the overflow from the 9th response; the IEEE 1800.2-2020 reference library has the report disabled by default and drops the overflow silently. Either read every response or call item_done() with no argument and read data from the request.
Check yourselfBackground traffic and a lock request are both waiting on the APB sequencer, and the background items were queued first. Who goes next once the driver finishes its current item?
The lock request. Locks and grabs are granted ahead of plain item requests, so the lock waits only for the item already in the driver, not for the queued items.
Check yourselfA virtual sequence uses p_sequencer.apb_sqr and is started with start(null). What happens?
There is no sequencer, so p_sequencer is never set and the first access dereferences a null handle. (DCLPSQ is the fatal for the other mistake: starting it on a sequencer of the wrong type.) A sequence started with start(null) must use handles it was given.