Switching the clock source changes the timing of everything downstream at once. Resets are the tool that makes the change survivable: hold the affected logic in reset across the switch, then release it into the new clock in the same disciplined way as any reset release.
Assert before the switch. Put the downstream logic into reset while the old clock still runs, so it enters the switch from a known state rather than mid-transaction.
Switch, then wait for the clock to stabilise. The mux needs its synchroniser delay plus the dead time; a free-running source needs its own start-up time. Count both before doing anything downstream.
Release synchronously to the new clock. A reset released asynchronously into the new domain re-creates the deassertion hazard the reset synchroniser exists to prevent (see reset strategies and reset-domain crossing).
Flush the synchronisers. After release, allow two to three cycles of the new clock before trusting any crossed signal, so stale pre-switch values drain out of every chain.
Restart protocols from idle. Handshakes return to their idle state and FIFOs to empty on the switch; never resume a transfer that straddled the change.
Step | Clock needed | Done when |
|---|---|---|
1. Assert reset | Old clock running | Reset observed asserted in the old domain. |
2. Switch source | None (output may pause) | Mux enables confirm the new side (en_b style check). |
3. Wait | New clock stable | Source stable plus mux dead time elapsed. |
4. Release reset | New clock running | Release synchronised to the new clock. |
5. Flush and restart | New clock running | Two to three quiet cycles, protocols from idle. |
The reviewer asks for the switch sequence as a written procedure with the wait counts filled in, then checks that reset assertion is independent of the clock being switched (an asynchronous assert, or a reset from a domain that stays alive). A sequence that releases reset into a clock that might still be starting is sent back.
First, the counter runs on the unproven clock, so the wait is meaningless if the clock is dead or glitching. Second, a fixed delay is not a release synchronised to the new clock; the release itself can violate recovery and needs a reset synchroniser on the new domain.