Q077FreeDesign Verification
UVM get_next_item and item_done Handshake
Question
What is wrong with this driver loop?
Code to inspect
forever begin
seq_item_port.get_next_item(req);
drive(req);
seq_item_port.get_next_item(req);
endAnswer choices
- A. The driver must call item_done exactly once for the first get_next_item before requesting another item
- B. Nothing; get_next_item implicitly completes the prior item
- C. drive must be a function rather than a task
- D. A driver may call get_next_item only once in its lifetime
Short answer
The loop requests a second item before completing the first. After each successful `get_next_item(req)`, the driver must finish driving that request and call `item_done()` exactly once before another `get_next_item`. Otherwise the sequencer-driver handshake can stall or report a protocol violation.
Why this reasoning works
`get_next_item` grants the driver access to one sequence item while the sequencer retains an outstanding handshake for it. Driving the pins does not tell the sequencer that processing is complete. The explicit `item_done` call closes that transaction and allows the sequence’s completion path and sequencer arbitration to progress.
The usual loop is therefore get, drive, then complete before repeating. Error and reset branches must preserve that pairing as well; abandoning a granted item can leave the originating sequence blocked. APIs such as `get` use different completion semantics, but they should be chosen deliberately rather than mixed with an incomplete `get_next_item` protocol.
Interview takeaways
- One item may be outstanding
- Driving does not complete it
- Call item_done before repeating