PPA Tradeoff Playbook: Debug Playbook

Debug playbook

Debug Playbook for PPA Tradeoff Playbook focuses on area-power-timing Pareto points, closure runtime, regression stability. The goal is to connect observed QoR movement to mechanism, ownership, and regression risk.

Synthesis debug finds the first causal drift, not the loudest downstream symptom.

Root-cause tree

ROOT-CAUSE TREE — PPA Tradeoff Playbook

area-power-timing Pareto points, closure runtime, regression stability regressed
        |
   same RTL/constraints tag?
     /              \
   no                yes
   |                  |
input drift      transform side-effect
 /    \             /         \
SDC    libs      mapping      physical estimate
diff   diff      choice       mismatch

1. Freeze baseline and regressed run manifests.

2. Verify RTL/SDC/library deltas before transform tuning.

3. Classify issue: constraints, mapping choice, physical estimate, or ECO side effect.

4. Pick one minimal reversible change.

5. Re-run full timing/area/power checks with ownership signoff.

Review memo template

STAFF SYNTHESIS REVIEW MEMO — Area, Power & Timing Tradeoffs / PPA Tradeoff Playbook

1. Symptom
   - Watched metric: area-power-timing Pareto points, closure runtime, regression stability
   - Affected compile run: <tag/build ID>
   - Impacted path/class: <critical group / power lane / area lane>
   - Database tags: <RTL, SDC, libs, switches>

2. Mechanism hypothesis
   - Primary mechanism: PPA closure is a constrained optimization problem: teams choose options by Pareto quality, not single-metric heroics.
   - Competing hypothesis: <constraint drift, mapping choice, physical estimate mismatch>
   - Missing evidence: <report diff, dashboard trend, ownership board>

3. Proposed action
   - Minimal reversible change: <constraint patch, compile knob, ECO cell move>
   - Expected movement: <timing / area / power delta>
   - Regression risk: hold, power spike, leakage drift, formal mismatch

4. Signoff
   - Re-run artifact: PPA matrix, QoR comparison table, decision memo
   - Required owners: synthesis lead, program owner, PD owner
   - Final decision: merge, rollback, or escalate

Synthesis deep dive

PPA closure is a constrained tradeoff problem, not a timing-only exercise.

Concept diagram

PPA TRIAD

timing target <-> power budget <-> area cap

Metric graph

PARETO PROGRESSION

early runs      o o
balanced point    o
over-tuned          o (risk)

Reports and artifacts

• VT mix

• leakage trend

• dynamic power trend

• PPA Pareto table

Mini case study

LVT-heavy fix recovered setup but violated leakage target; balanced VT strategy closed both.

Debug branches

• Timing-only claims need power check

• Validate hold on VT swaps

• Use Pareto memo

Senior review question

Ask: what evidence proves this QoR move is real and stable?

Key takeaways

• State exact run context (RTL, SDC, libs, switches) with every QoR claim.

• Re-run timing, area, and power regressions after each synthesis ECO.

Common pitfalls

• Comparing runs with mismatched constraints or library views.

• Timing-only fixes that violate power or area budgets.

• Skipping equivalence checks after structural changes.

Principal synthesis review addendum

PPA closure is a constrained optimization problem: teams choose options by Pareto quality, not single-metric heroics.

Metric: area-power-timing Pareto points, closure runtime, regression stability