Part 7 · Environment & Tests · Intermediate

Startup Sequence Walkthrough: Checkpoint-Driven Bring-Up Debug

Use explicit startup checkpoints from elaboration to first compare to localize failures quickly.

Core Contract

Keep this startup boundary deterministic, observable, and fail-fast.

Treat startup as reusable infrastructure: ownership, ordering, and liveness checks must be explicit.

diagram
[UVM][ENV] startup timeline

T-ELAB: static elaboration
T0: set config + run_test
T1: build_phase consumes startup state
T2: connect_phase establishes data paths
T3: first traffic and first checker compare
diagram
[UVM][ENV] boundary model

boundary A: ownership and lifecycle
boundary B: publication and path scope
boundary C: first-activity liveness proof

fix the first broken boundary first
  • Document ownership and ordering assumptions in code, not only slides.

  • Make startup diagnostics actionable and low-noise.

  • Prefer deterministic startup defaults over convenience shortcuts.


Reference Implementation

systemverilog
task run_phase(uvm_phase phase);
  phase.raise_objection(this, "startup walkthrough");

  env.wait_reset_release();
  env.assert_startup_ready();

  startup_vseq vseq = startup_vseq::type_id::create("vseq");
  vseq.start(env.v_sqr);

  env.wait_first_monitor_publish(2000ns);
  env.wait_first_scoreboard_compare(2000ns);

  phase.drop_objection(this, "startup walkthrough done");
endtask
diagram
[ENV] implementation audit

- critical startup assumptions validated?
- missing-state paths fail immediately?
- diagnostics include component path and context?
- minimal smoke seed can exercise this boundary?
diagram
[UVM][ENV] startup observability

track timestamps/counters for:
  reset release
  first sequence launch
  first monitor publish
  first checker compare

these markers reduce triage latency dramatically
  • Keep startup code simple enough to audit in code review.

  • Use fatal failures for non-recoverable startup contract violations.

  • Expose startup metrics in report_phase for CI artifacts.


Debug Workflow

Triage order

  1. Reproduce with one seed and startup tracing enabled.

  2. Verify startup boundary counters and first-activity markers.

  3. Classify failure by boundary before deep waveform analysis.

  4. Fix root boundary and rerun identical seed to confirm.

bash
simv +UVM_TESTNAME=smoke_test        +UVM_VERBOSITY=UVM_LOW        +UVM_CONFIG_DB_TRACE        +UVM_OBJECTION_TRACE
diagram
[UVM][ENV] quick diagnosis

fails before build:
  run_test/factory/config publish issue

build passes, no traffic:
  reset/sequence launch gating issue

monitor active, checker idle:
  connect/subscriber pipeline issue

Key takeaways

  • Time-ordered checkpoints turn startup failures into bounded bugs.

  • First-publish and first-compare markers validate real liveness.

  • Boundary-first triage is faster than blind waveform analysis.

  • A deterministic startup workflow improves regression trust and team velocity.

Common pitfalls

  • Declaring startup healthy before checker activity begins.

  • No checkpoint logs, forcing guess-based debugging.

  • Changing startup order without updating tests/checklists.

  • Skipping startup smoke and finding setup regressions only in long runs.


Applied Patterns

Use this reusable grid before landing startup-related changes.

diagram
[UVM][ENV] startup pattern grid

contract:
  ownership + ordering + liveness documented

implementation:
  fail-fast checks and deterministic defaults

observability:
  milestone counters and concise logs

verification:
  smoke seed + boundary-first triage + closure checklist
systemverilog
function void startup_health_report();
  `uvm_info("STARTUP_SUMMARY",
    $sformatf("rst=%0t seq=%0t mon=%0t cmp=%0t",
      first_reset_release_time,
      first_sequence_start_time,
      first_monitor_publish_time,
      first_scoreboard_compare_time),
    UVM_LOW)
endfunction
  • Treat startup updates as infrastructure API changes.

  • Keep code and checklist language aligned.

  • Require stable startup summaries in regression logs.