Puzzle

Difficulty: Hard · Puzzle 2 of 6 · Topic: Real Interview Rounds: End-to-End Debug Walkthrough

Interviewer says waveform looks idle and clean, but simulation never exits. Use objection-centric reasoning and close with a robust patch.

Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

task body();
  starting_phase.raise_objection(this);
  fork
    begin
      wait(cfg_done);
      run_traffic();
      starting_phase.drop_objection(this);
    end
    begin
      #1ms;
      if (!cfg_done) \`uvm_error("CFG", "timeout");
      disable fork; // bug: can kill drop path
    end
  join
endtask

Hint

Mention \`+UVM_OBJECTION_TRACE\` as first high-yield evidence.

Step-by-step solution

1) Symptom: run_phase stall despite no visible signal toggling issues.
2) Hypotheses: leaked objection, non-terminating thread, or blocked mailbox/semaphore.
3) Instrumentation: turn on \`+UVM_OBJECTION_TRACE\` and per-thread lifecycle logs.
4) Root cause: timeout branch disable fork kills thread that was supposed to drop objection.
5) Fix + validation: move drop_objection to guaranteed cleanup block and rerun timeout scenario.

Answer

Answer: Actual bug: disable fork can terminate the only drop_objection path. Fix: guarantee objection drop independently of fork race outcomes.

Why candidates get it wrong

Idle waveform does not imply no active objections.

Interviewer follow-up

How would you redesign timeout handling so it cannot bypass critical cleanup?

Related topics

• Back to Real Interview Rounds: End-to-End Debug Walkthrough

• Scenario & Debug Puzzles section