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 |
+------------------+----------------+----------------+----------------+Pick the approach based on residual silicon risk, not only schedule pressure.
Policy-only arguments without artifact evidence
Unbounded waivers
INTEGRATION EVIDENCE MATRIX — Reset Distribution & Sequencing
+-------------------+------------------------+--------------------------+-------------------------+
| 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 |
+-------------------+------------------------+--------------------------+-------------------------+Clock/reset assumptions must be globally consistent across functional and test modes.
CLOCK/RESET FLOW
pll lock -> clock enable -> reset release -> domain readyBOOT STABILITY
stable boots ████████
reset hangs ███clock architecture report
reset release timing
mode matrix
boot trace summary
Intermittent boot hang traced to one domain releasing reset before dependent clock was stable.
Check mode-specific constraints
Trace reset dependencies
Correlate firmware sequencing
Ask: what baseline, owner, and artifact prove this topic is truly closed?
State baseline manifest and owner with every closure metric.
Run cross-domain regression after every top-level fix.
Comparing results across different manifests.
Unowned issues slipping through review cycles.
Waiving risks without expiry and validation plan.
Reset trees and release sequencing must match power/clock dependencies to prevent metastability, deadlock, and phantom boot failures.
Metric: reset release violations, bring-up reset bug rate
This content block can't be displayed here.
Block type: unknown
This content block can't be displayed here.
Block type: unknown
This content block can't be displayed here.
Block type: unknown