Part 11 · Senior Prep · Intermediate

Reset & Phase Jump Interview Q&A

Model answers on reset_phase behavior, uvm_phase jump API, mid-simulation reset scenarios, and phase jump pitfalls.

Reset and phase jump fundamentals

Phase jump is an advanced topic — interviewers test whether you know when jump is appropriate vs resetting the entire simulation.

Q: What is a phase jump in UVM?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: What is phase jump?

A:
  MECHANISM:  uvm_phase::jump(target_phase) aborts current phase execution and resumes
              at target phase — components' phase tasks killed, phase tree rewound.
  MOTIVATION:  Mid-simulation reset (watchdog timeout, power cycle, error recovery)
              needs TB to return to reset/configure without restarting $finish/$start.
  WHEN:       Power transition tests, repeated reset stress, error recovery sequences
              requiring full TB re-initialization.
  PITFALL:    Jump without resetting component state — stale objections, pending seq
              items, scoreboard queues corrupt next phase cycle.
  EXAMPLE:    DUT watchdog fires → test jumps to reset_phase → all agents re-init →
              configure_phase reprograms CSRs → main_phase restarts traffic.

Q: Phase jump vs re-running the simulation?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Phase jump vs re-run simulation?

A:
  MECHANISM:  Jump rewinds phase scheduler in-process; re-run exits and restarts sim
              from time zero with fresh elaboration.
  MOTIVATION:  Jump saves elaboration overhead for repeated reset cycles within one
              test — useful for 1000x reset stress in one seed.
  WHEN:       Jump for in-test reset loops. Re-run for completely independent scenarios
              or when jump cleanup is too complex to trust.
  PITFALL:    Jump in complex SoC TB without comprehensive flush — subtle state leak
              across jump boundaries worse than clean re-run.
  EXAMPLE:    PCIe link retrain 50x in one test via jump to reset_phase — faster than
              50 separate sim invocations if flush protocol is solid.

Q: What must you clean up before a phase jump?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Cleanup before phase jump?

A:
  MECHANISM:  Kill outstanding sequences, flush scoreboard/predictor queues, reset
              objections to zero, clear TLM FIFOs, reset register model mirror.
  MOTIVATION:  Jump kills phase tasks but not necessarily component data structures —
              stale state poisons post-jump phases.
  WHEN:       Implement flush() on env called before jump; each agent resets driver
              state machine, sequencer arb queue, monitor counters.
  PITFALL:    Jump to reset_phase with active seq_item in driver — get_next_item /
              item_done handshake corrupted on resume.
  EXAMPLE:    pre_jump_flush: env.stop_sequences(); sb.flush(); reg_model.reset();
              then phase.jump(uvm_reset_phase::get());

Q: reset_phase in sub-phases vs phase jump to reset?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: reset_phase vs jump to reset?

A:
  MECHANISM:  reset_phase is first entry in normal sub-phase schedule at sim start.
              jump(target) returns to reset_phase mid-simulation after prior phases ran.
  MOTIVATION:  Initial reset_phase handles power-on reset; jump handles mid-test reset
              events without restarting simulation time from zero.
  WHEN:       Normal bring-up: reset_phase once at start. Stress/recovery: jump back
              after watchdog, hot reset, or power-cycle event detected.
  PITFALL:    Assuming reset_phase code re-runs identically on jump — components may
              need jump-aware branch (full flush vs initial power-on path).
  EXAMPLE:    Power-on: reset_phase waits POR. Mid-test: jump to reset_phase after
              detecting HRST assertion — includes extra FIFO flush not needed at POR.

Key takeaways

Phase jump rewinds scheduler in-process — requires explicit state flush.
Jump for repeated reset loops; re-run sim when flush complexity is too high.
reset_phase at start vs jump-to-reset mid-test need different cleanup paths.

Common pitfalls

Jump without flushing sequences, scoreboard, and register model.
Assuming killed phase tasks clean up their own data structures automatically.

Reset scenarios and jump debug

Q: How do objections behave during phase jump?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Objections during phase jump?

A:
  MECHANISM:  Jump kills active phase tasks — outstanding objections in killed phase
              are cleared as part of phase abort. New phase starts with zero count.
  MOTIVATION:  Prevents stale objections from pre-jump phase blocking post-jump phase —
              but only if jump completes cleanly.
  WHEN:       Verify zero objections after jump via display_objections before raising
              new ones in resumed reset_phase.
  PITFALL:    Component outside jumped domain still holds objection in its domain —
              multi-domain jump requires per-domain cleanup.
  EXAMPLE:    Jump from main_phase: main objections cleared. post_jump check shows
              PD-SW domain still holds objection — separate domain jump needed.

Q: Describe a power-cycle test using phase jump

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Power-cycle test with phase jump?

A:
  MECHANISM:  main_phase runs traffic → detect power-down event → flush → jump to
              reset_phase → power-up sequence in reset/post_reset → configure → main.
  MOTIVATION:  Validates DUT and TB recovery across power transitions in one seed —
              critical for mobile/IoT SoC sign-off.
  WHEN:       Low-power resume, watchdog recovery, thermal throttle reset scenarios.
  PITFALL:    Forgetting to re-set virtual interfaces or re-randomize cfg on jump —
              stale cfg from pre-power-down applied to post-power-up DUT state.
  EXAMPLE:    10x power cycle loop: each iteration flush env, jump reset, configure_phase
              programs retention regs, main_phase verifies data integrity.

systemverilog

// phase jump pattern — interview snippet
task main_phase(uvm_phase phase);
  phase.raise_objection(this, "main");
  run_traffic();
  if (watchdog_fired) begin
    env.pre_jump_flush();
    phase.jump(uvm_reset_phase::get());
  end
  phase.drop_objection(this, "main");
endtask

Q: How do you debug failed phase jumps?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Debug failed phase jump?

A:
  MECHANISM:  Jump failures manifest as hang in post-jump phase, stale data mismatches,
              or UVM_FATAL from phase state machine illegal transition.
  MOTIVATION:  Jump is fragile — systematic post-jump audit catches incomplete flush.
  WHEN:       After jump: display_objections all domains, print seq arb queue depth,
              scoreboard pending count, reg_model.get_reset(). Enable PHASE_TRACE.
  PITFALL:    Re-running only the jump iteration without capturing pre-jump state —
              cannot bisect which flush step was missed.
  EXAMPLE:    Post-jump scoreboard shows 3 pending txns from pre-jump — sb.flush()
              not called in pre_jump_flush, root cause in one debug iteration.

Q: Is phase jump supported in all UVM simulators equally?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Simulator support for phase jump?

A:
  MECHANISM:  Phase jump is in IEEE 1800.2 / UVM standard but simulator implementations
              vary in task kill semantics and time rollback behavior.
  MOTIVATION:  Teams must validate jump on each simulator — task kill may leave dangling
              fork branches on some tools.
  WHEN:       Prototype jump on target simulator early; maintain simulator-specific
              flush workarounds if needed.
  PITFALL:    Developing jump flow on Simulator A, failing silently on Simulator B
              at customer site — regression gap.
  EXAMPLE:    Questa vs Xcelium: different task kill cleanup — add explicit
              disable fork in agent flush() for portable jump support.

Key takeaways

Jump clears objections in jumped domain — verify all domains post-jump.
Power-cycle tests are canonical phase jump use case — flush is mandatory.
Validate jump portability on every target simulator.

Common pitfalls

Stale scoreboard/register state after jump — most common post-jump failure.
Assuming jump portability without per-simulator validation.

Practice this lessonQuestions tagged for this topic in the bank