SoC Integration · All levels
Clock/Reset + DFT Interactions: Comparison Matrix
Comparison Matrix for Clock/Reset + DFT Interactions.
Comparison matrix
Clock/reset choices trade robustness, testability, and closure margin.
+------------------+----------------+----------------+----------------+
| Approach | Strength | Weakness | Best when |
+------------------+----------------+----------------+----------------+
| Strict | predictable | slower early | new program |
| Balanced | practical | needs rigor | stable teams |
| Aggressive | fast | escape risk | late schedule |
| Re-architect | durable | expensive | recurring failures |
+------------------+----------------+----------------+----------------+When to choose each approach
Pick the approach based on residual silicon risk, not only schedule pressure.
Review traps
Policy-only arguments without artifact evidence
Unbounded waivers
Evidence comparison
INTEGRATION EVIDENCE MATRIX — Clock/Reset + DFT Interactions
+-------------------+------------------------+--------------------------+-------------------------+
| Evidence | Tells you | Does not prove | Next action |
+-------------------+------------------------+--------------------------+-------------------------+
| Manifest diff | baseline changed | root cause itself | isolate first delta |
| Domain trace | where behavior diverged| ownership accountability | map to contract owner |
| Signoff dashboard | closure posture | reproducibility quality | verify source artifacts |
| Bring-up logs | software-visible symptom| physical/timing cause | correlate with HW trace |
| Waiver register | accepted residual risk | technical closure | review expiry criteria |
+-------------------+------------------------+--------------------------+-------------------------+SoC deep dive
Clock/reset assumptions must be globally consistent across functional and test modes.
Concept diagram
CLOCK/RESET FLOW
pll lock -> clock enable -> reset release -> domain readyMetric graph
BOOT STABILITY
stable boots ████████
reset hangs ███Reports and artifacts
clock architecture report
reset release timing
mode matrix
boot trace summary
Mini case study
Intermittent boot hang traced to one domain releasing reset before dependent clock was stable.
Debug branches
Check mode-specific constraints
Trace reset dependencies
Correlate firmware sequencing
Senior review question
Ask: what baseline, owner, and artifact prove this topic is truly closed?
Key takeaways
State baseline manifest and owner with every closure metric.
Run cross-domain regression after every top-level fix.
Common pitfalls
Comparing results across different manifests.
Unowned issues slipping through review cycles.
Waiving risks without expiry and validation plan.
Principal SoC review addendum
Functional and test clocks/resets share infrastructure; missing mode-specific constraints and mux assumptions often break ATPG or silicon bring-up.
Metric: scan mode timing escapes, test-mode bring-up issues