Retiming Fundamentals: Debug Playbook

Debug playbook

Debug Playbook for Retiming Fundamentals focuses on retimed register count, critical path depth change, equivalence pass rate. 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 — Retiming Fundamentals

retimed register count, critical path depth change, equivalence pass rate 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 / Retiming Fundamentals

1. Symptom
   - Watched metric: retimed register count, critical path depth change, equivalence pass rate
   - 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: Retiming moves registers across combinational logic to rebalance stage delay while preserving functionality under reset and enable constraints.
   - 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: retiming report, stage-depth histogram, equivalence log
   - Required owners: synthesis owner, formal owner, STA 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

Retiming moves registers across combinational logic to rebalance stage delay while preserving functionality under reset and enable constraints.

Metric: retimed register count, critical path depth change, equivalence pass rate