SoC Connectivity and Pin-Mux Formal Checking: Debug Playbook

Debug playbook

Debug Playbook for SoC Connectivity and Pin-Mux Formal Checking is anchored on non-vacuous closure rate, counterexample turnaround, and residual-risk trend by requirement class. Convert outcomes into assumption-aware, evidence-backed actions.

1. Freeze assumptions, RTL hash, and engine metadata.

2. Locate first divergence cycle and classify source.

3. Classify mechanism: model mismatch, weak property, setup issue, or RTL defect.

4. Apply one focused reproducer and one bounded fix.

5. Re-run sibling properties and critical covers before closure.

Review memo template

FORMAL REVIEW MEMO - Formal Applications (Apps) / SoC Connectivity and Pin-Mux Formal Checking

1. Symptom
   - Failing metric: non-vacuous closure rate, counterexample turnaround, and residual-risk trend by requirement class
   - Trigger context: <mode/reset/env assumptions>
   - First divergence boundary: <model/property/rtl>

2. Mechanism hypothesis
   - Candidate mechanism: Connectivity apps prove that point-to-point signal intent is preserved through wrappers, tie-offs, and parameterized muxing across hierarchical integration.
   - Competing hypotheses: weak property, over-constraint, setup mismatch, rtl bug
   - Missing evidence: <trace, vacuity report, cover status>

3. Proposed action
   - Smallest reversible change: <assumption/property/rtl>
   - Expected movement: <closure quality, runtime, bug isolation>
   - Regression risk: hidden legal behavior, false pass, schedule churn

4. Signoff
   - Required artifact: closure packet for SoC Connectivity and Pin-Mux Formal Checking: assumptions audit, proof status matrix, and replay-ready divergence trace
   - Required owners: formal verification owner, rtl owner, Formal Applications (Apps) owner
   - Final decision: close, bounded closure, rollback, or escalate

Formal deep dive

Formal apps generate high confidence when app-specific assumptions mirror integration and firmware behavior.

Concept diagram

FORMAL APPS MAP

connectivity + csr + progress + reset/x checks -> integrated SoC confidence

Metric graph

APPS CLOSURE QUALITY

functional app closure   ███████
environment realism      █████
waiver pressure          ███

Metrics and artifacts to collect

• connectivity route reachability

• CSR semantic correctness matrix

• progress guarantee closure by interface

• reset/X convergence confidence

Mini case study

Deadlock traces were resolved by tightening fairness assumptions to architecture contracts, not by weakening liveness guarantees.

Debug branches

• Validate mode and configuration constraints for each app.

• Pair safety and liveness checks for progress-sensitive logic.

• Add first-transaction covers for reset-sensitive interfaces.

Senior review question

Ask: which requirement intent is proven, under which assumptions, and what residual risk remains?

Key takeaways

• Tie each proof claim to assumption boundaries and reachability evidence.

• Prefer minimal reversible fixes and preserve legal behavior visibility.

Common pitfalls

• Treating runtime reduction as proof-quality improvement without audits.

• Declaring closure while critical covers remain unreachable.

• Using broad waivers instead of first-divergence root-cause ownership.

Debug ladder

Sequence: reproduce -> classify -> isolate first divergence -> patch -> revalidate sibling properties.

Avoid mixing assumption and RTL fixes in the same experiment.