Hardware interview practice
UVM get_next_item and item_done Handshake
What is wrong with this driver loop?
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
Concise answer
The answer and the key reason
Deeper explanation
Work through the implementation and tradeoffs
`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.
What to remember
- One item may be outstanding
- Driving does not complete it
- Call item_done before repeating
Practice the complete prompt
