VLSI DV Interview Puzzles · All levels
Sequence get_response Stall
Sequence hangs on get_response only when DUT returns error responses. Normal responses complete. Determine the missing piece.
Puzzle
Difficulty: Hard · Puzzle 5 of 6 · Topic: Testbench Debug Puzzles: Why Did the Test Hang?
Sequence hangs on get_response only when DUT returns error responses. Normal responses complete. Determine the missing piece.
Code
class rsp_seq extends uvm_sequence #(my_item);
virtual task body();
my_item req, rsp;
repeat (20) begin
\`uvm_do(req)
get_response(rsp); // hangs on error cases
end
endtask
endclass
virtual task my_driver::run_phase(uvm_phase phase);
my_item req, rsp;
forever begin
seq_item_port.get_next_item(req);
rsp = my_item::type_id::create("rsp");
rsp.set_id_info(req);
if (req.inject_err) begin
seq_item_port.item_done();
continue; // bug: no put_response on this path
end
seq_item_port.item_done(rsp);
end
endtaskHint
Compare response-path behavior for success and error branches.
Step-by-step solution
1) Add response queue depth trace in the sequence around get_response calls.
2) Correlate hangs to requests with inject_err asserted.
3) Inspect driver branch and confirm error path never sends response object back.
4) Return an explicit error response (or stop waiting for response by contract).
5) Add sequence-level timeout for get_response to expose future response-contract breaks.Answer
Answer: Bug: driver does not put/send response on error path, but sequence always waits for one. Fix: always return a response (including error status) or change sequence contract to not call get_response for no-rsp flows.
Why candidates get it wrong
Debugging only successful traffic misses the path that violates the response contract.
Interviewer follow-up
How would you encode in the item whether a response is mandatory so sequence behavior is explicit?