Not every reset means the same thing. A power-on reset starts from an unknown world: no clocks, unknown flop states, uninitialised memories. A warm or soft reset restarts operation while the chip is alive: clocks run, configuration is programmed, and some state must survive. Treating them identically either clears state that should survive or keeps state that should be rebuilt.
Power-on reset | Warm / soft reset | Domain-specific reset | |
|---|---|---|---|
When | Supply ramps, chip starts | Firmware or watchdog restarts operation | One block restarts while neighbours run |
Clocks | May not exist yet | Running and stable | Running |
Must clear | All control state, FSMs, valid bits | Protocol state, datapath valids, error sticky bits per spec | That block's protocol and control state |
Must preserve | Nothing can be assumed | Programmed configuration, calibration, debug trace | Shared configuration and neighbour state |
Release basis | After stabilised clocks plus ordered sequence | Quick, but still synchronised per domain | Sequenced against the blocks it talks to |
A warm reset that clears configuration forces a full reprogramming cycle the system did not budget for, and the first transactions after release use default settings instead of tuned ones.
A warm reset that keeps protocol state resumes a conversation the other side has forgotten: sequence numbers, credits, or handshake phase disagree from the first word.
A domain-specific reset without isolation and release ordering hits its running neighbours with reset values and early traffic, the failures the previous three lessons describe.
The practical rule is to list, per reset kind, which registers it touches and which it must leave alone, and to review that list like an interface: every preserved register is a promise to the next power-up or the next warm boot, and every cleared one is a promise that nothing downstream depended on its old value.
The sides disagree about available credit: one side believes the link is empty while the other still counts old grants, so transfers stall or overflow. Warm resets must return shared protocol state to a mutually known point.
Because its neighbours keep running: they see its reset values during the reset and its first traffic after release. Without isolation during, and ordering after, the reset corrupts live neighbours exactly like a badly sequenced power-up.