Difficulty: Easy · Puzzle 1 of 6 · Topic: Sequences and Sequencers
UVM 1.2. A driver polls for items with try_next_item so it can drive idle cycles. At the start no sequence has an item ready. What does the simulation do?
task run_phase(uvm_phase phase);
forever begin
seq_item_port.try_next_item(req);
if (req != null) begin
drive(req);
seq_item_port.item_done();
end
end
endtaskWhat does try_next_item do when nothing is waiting, and does the loop contain any wait?
1) try_next_item is non-blocking: if no item is available it returns at once with req == null (get_next_item would block instead).
2) The else path of the loop contains no delay or event wait, so the forever loop spins in zero time.
3) Simulation time never advances, so the sequence (which needs time to start) can not run, nothing is ever produced, and the simulator hangs at time 0. A UVM timeout does not help because it is a simulation-time timeout.
4) Fix: in the null case wait for a clock edge (`@(vif.cb)` or `#1`) and drive the idle value, or just use get_next_item when idle driving is not required.Answer: A zero-time infinite loop: time stays at 0 and the simulation hangs; add a clock wait in the null branch (or use get_next_item).
Checked by running the code in Verilator 5; the printed output supports the answer above. Hand-written model of the documented UVM 1.2 behaviour in plain SystemVerilog (Verilator), not the UVM library: a mailbox try_get loop stands for try_next_item: with no wait in the empty branch 1000 iterations take 0 time; with a delay the item that arrives at 35 is seen at 40.
The classic hang-with-no-log: a UVM timeout can not rescue it, because the watchdog counts simulation time and the loop never lets time advance.
If items are present, does the loop above still behave? Model answer: yes for the item path (drive() consumes time, item_done releases the sequence), but every time the queue is empty the loop spins again with no wait, so any idle gap reproduces the hang; the idle branch must always consume time.