Low Power Verification · All levels

Power Bug Triage: Debug Playbook

Debug Playbook for Power Bug Triage.

Debug playbook

Debug Playbook for Power Bug Triage is anchored on illegal transition rate, corruption incidence, and deterministic replay quality under low-power scenarios. Convert observations into mechanism-backed and owner-bound actions.

Freeze seed, metadata, and boundary under investigation.
Locate first persistent low-power phase divergence.
Classify mechanism: setup, transition, boundary, retention, or X-prop class.
Apply one focused reproducer and one bounded fix.
Re-run determinism and broader regression matrix.

Review memo template

diagram

LPV REVIEW MEMO - LPV Debug & Signoff / Power Bug Triage

1. Symptom
   - Failing metric: illegal transition rate, corruption incidence, and deterministic replay quality under low-power scenarios
   - Trigger context: <seed/mode/sequence>
   - First failing phase: <entry/off/exit/boundary>

2. Mechanism hypothesis
   - Candidate mechanism: Low-power bug triage must start from first power-intent divergence, not the final scoreboard mismatch, because symptoms can appear thousands of cycles after the causative transition. Practical triage stacks evidence in layers: power controller command and acknowledge timeline, domain/supply state traces, isolation and retention control behavior, then protocol and functional fallout. Classifying defects early into sequencing, intent-binding, structural insertion, or software orchestration issues avoids expensive cross-team ping-pong and speeds owner routing. Strong teams maintain reproducible minimal tests for each bug class and track escape patterns such as intermittent wake-up corruption, stale retained state, or cross-domain deadlock that only occurs under concurrent traffic and power events.
   - Competing hypotheses: setup, transition race, boundary bug, retention drift, X-prop noise
   - Missing evidence: <trace/assertion/report>

3. Proposed action
   - Smallest reversible change: <intent/RTL/checker/flow>
   - Expected movement: <failure trend/replay stability>
   - Regression risk: compatibility, coverage, signoff delay

4. Signoff
   - Required artifact: evidence packet for Power Bug Triage: transition timeline, assertions, and before-after replay summary
   - Required owners: LPV lead, power-intent owner, LPV Debug & Signoff owner
   - Final decision: ship, bounded rollout, rollback, or escalate

Low-power verification deep dive

Signoff confidence comes from triage discipline, reproducible proof, and explicit residual-risk decisions.

Concept diagram

diagram

LPV SIGNOFF LADDER

reproduce -> classify -> isolate boundary -> bounded fix -> replay -> signoff decision

Metric graph

diagram

SIGNOFF CONFIDENCE

open ambiguous failures  ██████
reproducible closures    ███████
residual-risk unknowns   ███

Metrics and artifacts to collect

X-prop triage classification report
bug root-cause closure packet
regression stability and recurrence trend
signoff checklist completion matrix

Mini case study

A signoff block cleared after the team replaced broad waivers with boundary-specific evidence and replay criteria.

Debug branches

Classify X behavior before broad waiving.
Capture one definitive artifact packet per closure claim.
Define residual risk and rollback path at signoff.

Senior review question

Ask: what exact low-power transition boundary failed first, and which artifact proves the closure claim reproducibly?

Key takeaways

Tie each LPV claim to a concrete transition boundary and one proving artifact.
Prefer minimal reversible fixes with explicit owner and rollback criteria.

Common pitfalls

Treating power-aware failures as random before boundary classification.
Waiving X-prop failures before proving impact and root cause.
Declaring closure without deterministic replay across key modes.

Debug ladder

Sequence: reproduce -> classify -> isolate boundary -> prove mechanism -> bounded fix.

Avoid mixed fixes before first-principles classification.

Practice this lesson