Datapath Debug: Debug Playbook

Debug playbook

Debug Playbook for Datapath Debug focuses on datapath QoR regression rate, functional mismatch escapes, root-cause latency. 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 — Datapath Debug

datapath QoR regression rate, functional mismatch escapes, root-cause latency 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 — Datapath & Retiming / Datapath Debug

1. Symptom
   - Watched metric: datapath QoR regression rate, functional mismatch escapes, root-cause latency
   - 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: Datapath regressions often stem from inference misses, boundary constraints, or retiming blockers; debug flow ties symptom to transform stage.
   - 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: inference miss report, retiming blocker list, debug memo
   - Required owners: synthesis owner, RTL owner, formal owner
   - Final decision: merge, rollback, or escalate

Synthesis deep dive

Datapath and retiming gains are only real if formal and timing remain clean.

Concept diagram

DATAPATH + RETIME

operator inference -> stage balancing -> formal proof -> QoR validation

Metric graph

FREQUENCY VS LATENCY

Fmax gain   ████████
latency cost ████

Reports and artifacts

• retiming report

• datapath inference log

• equivalence status

• latency impact sheet

Mini case study

Retiming met frequency target, but missing formal hooks delayed closure by two days.

Debug branches

• Check retime blockers

• Formal first for aggressive moves

• Compare with pipeline option

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

Datapath regressions often stem from inference misses, boundary constraints, or retiming blockers; debug flow ties symptom to transform stage.

Metric: datapath QoR regression rate, functional mismatch escapes, root-cause latency