An unsynchronised reset release fails only on some power-up sequences and passes on others, so testing alone cannot sign it off. The RDC flow pairs a static check of every reset crossing with targeted simulation, and it starts from written reset intent so the checks know what correct looks like.
Stage | Question it answers | Output |
|---|---|---|
1. Reset intent | Which resets exist, what each one resets, and in what order they release? | A reviewed list of resets, domains, and release ordering. |
2. Structural analysis | Where does reset cross from one domain to another, and is each release synchronised? | A report of reset-domain crossings with synchroniser status. |
3. Classification | Which findings are defects and which are acceptable with evidence? | Every finding dispositioned: fix, waive with evidence, or accept. |
4. Fix | How is each defect removed: synchroniser, re-parented reset, or new sequencing? | Changed RTL plus updated intent, re-analysed. |
5. Dynamic checks | Does the design behave under real reset sequences: mid-operation, partial, and ordered release? | Passing reset-aware tests and assertions. |
6. Signoff | Is everything closed on the final RTL? | The closure evidence package. |
Structural analysis generally looks for three things: registers whose reset comes from a different reset domain than their clock, asynchronous deassertion with no reset synchroniser on the path, and reset signals that fan out across clock domains without synchronised release. The review looks at the intent first: if the intent is incomplete or unreviewed, the report is noise and the team fixes the intent before anything else.
For design background on what a correct reset network looks like, see Reset domain crossing and Reset strategies. This topic assumes that background and covers how to sign it off.
Re-run the structural analysis after every fix, on the final RTL, with the final intent: a clean report on stale RTL proves nothing. Pair it with reset-aware simulation of the release sequences the analysis cannot see, such as mid-operation assertion and ordered release across domains. Track both in the signoff dashboard so a passing stage cannot silently go stale.
No. With no intent the analysis had nothing to check against, so a clean report means nothing. Write and review the intent, then re-run.
The structural analysis must be re-run on the changed RTL with the updated intent, and the relevant dynamic checks must pass again.