Runtime Sub-Phases Interview Q&A

[INT][SENIOR][UVM] MODEL ANSWER

Q: Name the 12 runtime sub-phases?

A:
  MECHANISM:  pre_reset → reset → post_reset → pre_configure → configure →
              post_configure → pre_main → main → post_main → pre_shutdown →
              shutdown → post_shutdown. All parallel with run_phase in default domain.
  MOTIVATION:  Structured bring-up beats scattered #delay and @(posedge rst_n) in every
              component — shared schedule for reset release, prog, stimulus, shutdown.
  WHEN:       Any TB needing explicit reset sequencing, late config, or graceful shutdown
              before extract_phase. Skip sub-phases if simple single-reset block TB.
  PITFALL:    Using only run_phase with manual reset waits in driver — works once,
              breaks when reset domain added at chip level.
  EXAMPLE:    DUT reset released in reset_phase task; sequences start in main_phase;
              register save in shutdown_phase before power-off scenario.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Which sub-phase for sequences?

A:
  MECHANISM:  main_phase is the conventional stimulus window — test raises objection
              in main_phase, starts virtual sequences, drops after quiescence.
  MOTIVATION:  reset/configure phases complete before stimulus — ensures DUT in known
              state, clocks stable, registers programmed before traffic.
  WHEN:       main_phase for normal stimulus. pre_main for late config checks. shutdown
              for graceful drain before power transition tests.
  PITFALL:    Starting sequences in run_phase while also using reset_phase — race
              between reset deassert and first transaction.
  EXAMPLE:    configure_phase programs CSR defaults; main_phase runs traffic vseq;
              shutdown_phase waits for FIFO empty before reset assertion test.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Objections across sub-phases?

A:
  MECHANISM:  Each sub-phase has its own objection counter — raise in main_phase does
              not hold reset_phase open. Sub-phases execute sequentially in order.
  MOTIVATION:  Independent counters let reset_phase complete before main_phase begins
              even if a component still conceptually 'busy' — phase boundary is strict.
  WHEN:       Raise/drop within the same sub-phase where work occurs. Do not raise in
              reset_phase and drop in main_phase — crosses phase boundary incorrectly.
  PITFALL:    Raising objection in run_phase expecting it to hold main_phase — separate
              counters; main_phase starts with zero objections regardless of run_phase.
  EXAMPLE:    reset_phase: driver waits for reset deassert, drops. main_phase: test
              raises, runs vseq, drops. Each phase ends on its own objection balance.

[INT][SENIOR][UVM] MODEL ANSWER

Q: reset_phase vs post_reset_phase?

A:
  MECHANISM:  reset_phase: assert/wait reset, hold DUT in reset. post_reset_phase:
              first cycles after reset release — stabilization, initial sampling.
  MOTIVATION:  Split lets monitors configure catch-up behavior before reset vs after;
              drivers know not to drive during reset_phase.
  WHEN:       reset_phase for reset assertion/wait. post_reset_phase for idle bus
              checks, initial register read sanity, clock stability wait.
  PITFALL:    Driving stimulus in reset_phase — protocol violation before DUT ready.
  EXAMPLE:    reset_phase: wait(rst_n==0); wait(rst_n==1). post_reset_phase: verify
              bus idle 10 cycles. main_phase: start traffic.

[INT][SENIOR][UVM] MODEL ANSWER

Q: When skip sub-phases?

A:
  MECHANISM:  Sub-phases are optional — empty task bodies compile and complete
              immediately (no objection needed if no work).
  MOTIVATION:  Simple block TB with single reset in HDL top may not need structured
              sub-phases — run_phase alone suffices.
  WHEN:       Tiny directed block, single clock domain, reset handled in SV initial
              block. Skip when sub-phases add ceremony without coordination benefit.
  PITFALL:    Skipping at block then failing to add sub-phases at chip integration —
              reset races appear when multiple domains merge.
  EXAMPLE:    Block AXI VIP TB: run_phase only. Chip TB: reset_phase per power domain,
              main_phase after all domains report ready.

[INT][SENIOR][UVM] MODEL ANSWER

Q: shutdown vs post_shutdown?

A:
  MECHANISM:  shutdown_phase initiates graceful stop — drain FIFOs, finish outstanding
              transactions. post_shutdown verifies quiescent state before extract.
  MOTIVATION:  Power transition and hot-reset tests need orderly stop before reset
              assertion — shutdown sub-phases provide hook without custom sync events.
  WHEN:       shutdown for active drain (driver stops accepting items). post_shutdown
              for passive checks (all valid deasserted, no X on bus).
  PITFALL:    Skipping shutdown on error-injection test — DUT left mid-transaction,
              next test seed polluted by residual state.
  EXAMPLE:    Error test triggers NACK storm; shutdown_phase waits driver idle;
              post_shutdown asserts bus quiet before scoreboard final compare.

[INT][SENIOR][UVM] sub-phase stimulus map (whiteboard)

  reset_phase       → hold/wait reset
  configure_phase   → CSR program, mode select
  main_phase        → traffic vseq (primary objection here)
  shutdown_phase    → graceful drain
  post_shutdown     → quiescence check
  extract_phase     → scoreboard/coverage finalize (function phase)

[INT][SENIOR][UVM] MODEL ANSWER

Q: Sub-phases and RAL?

A:
  MECHANISM:  configure_phase is conventional home for reg_model reset() and default
              register programming before main_phase stimulus.
  MOTIVATION:  Separates programming from traffic — scoreboard and predictor expect
              known register state when main_phase transactions begin.
  WHEN:       configure_phase: reg_model.reset(); reg_model.default_map.read/write.
              main_phase: start sequences that assume programmed DUT mode.
  PITFALL:    Programming registers in main_phase mid-sequence — race with predictor
              mirror update and first monitored transaction.
  EXAMPLE:    configure_phase sets MODE=DMA; main_phase runs DMA vseq; predictor
              expects DMA mode from first monitored packet.