The 12 Runtime Sub-Phases: reset, configure, main, shutdown

Overview

UVM's 12 runtime sub-phases provide fine-grained, cross-component coordination within the simulation run. They execute in parallel with run_phase but offer staged reset, configuration, main traffic, and shutdown — each stage gated by its own objection mechanism.

Use them when multiple agents must agree on intermediate milestones: everyone finishes reset before anyone configures registers, and configuration completes before main traffic begins.

Sub-lessons in this topic

1. twelve-phase-schedule — the complete ordered list and scheduler behavior.

2. reset-configure-main-shutdown — the four groups and what belongs in each.

3. pre-post-runtime-pairs — why pre_* and post_* phases exist and how to use them.

4. runtime-sequencer-order — how sequences start/stop across runtime phases.

5. runtime-use-cases — SoC bring-up, RAL config, VIP lifecycle, and shutdown drain.

6. runtime-subphase-debug — debugging stalled sub-phases and group transitions.

Architecture map

Legend: [PHASE] [RUN] [UVM]

[PHASE] run_phase (parallel bucket — often super-only when using sub-phases)
   ║
   ║  (same simulation time window)
   ║
   ▼
[PHASE] 12 RUNTIME SUB-PHASES (sequential groups, parallel within group)

  RESET grp        CONFIG grp       MAIN grp         SHUTDOWN grp
  pre_reset        pre_configure    pre_main         pre_shutdown
  reset      ───►  configure  ───►  main       ───►  shutdown
  post_reset       post_configure   post_main        post_shutdown

  each phase: task + objections → advances when count drains to 0

[PHASE][RUN] group transition rule

  reset group objections = 0
       │
       ▼ (scheduler moves to configure group)
  configure group objections = 0
       │
       ▼
  main group → shutdown group → done

Key takeaways

• 12 runtime sub-phases run in parallel with run_phase — pick one model per component.

• Four groups (reset/configure/main/shutdown) map to real bring-up stages.

• Each sub-phase has independent objections — same raise/drop rules as run_phase.

• Groups are sequential; components within a group run in parallel.

Common pitfalls

• Mixing run_phase activity and runtime sub-phase activity in the same component.

• Register programming in reset_phase instead of configure_phase.

• Forgetting raise/drop in a sub-phase — stalls only that phase, not all of run.

• Assuming main_phase starts at time 0 — reset and configure groups run first.