Context, kept generic: a multi-clock control block programmed once by firmware at boot, then started. About one boot in twenty hangs before the first transaction, always in the same downstream state machine, with no error flag. Power-cycling usually clears it. The symptom never appears in directed simulation.
The hang correlates with nothing in firmware: identical images hang or boot cleanly at random. When it hangs, the downstream controller sits in a wait state whose entry condition depends on a mode field programmed across a clock boundary during the boot sequence. Reading the mode register back after a hang shows a legal value, because the torn sample was transient and the register settled correctly one cycle later; only the state machine saw the wrong one.
Hypothesis | Evidence sought | Verdict |
|---|---|---|
Firmware races the start bit before configuration completes. | Boot logs with timestamps on every write. | Killed: the start bit always follows the last write by a wide margin. |
The destination clock is unstable at boot. | Clock-stable status at the hang point. | Killed: the clock is stable long before configuration begins. |
The mode word tears across its per-bit synchronisers. | Capture the synchroniser outputs on a hang; check the report. | Survives: see evidence below. |
Lengthening the gap between the mode write and the start bit reduces the hang rate but never removes it, which fits a timing window, not a race. The report history then settles it: the mode bus was flagged as a multi-bit crossing without a protocol, and waived as quasi-static on the argument that firmware writes it once. But the waiver never showed the value held stable across the synchroniser latency around the sampling moment, and the boot sequence rewrites the field on some boots, so the signal is not static where it matters.
Root cause: a multi-bit mode word crossing on per-bit synchronisers with no holding protocol, tearing on the occasional boot when the transition lands inside the capture window. The fix is a load pulse with held data: firmware writes the mode, the held value settles, a synchronised pulse tells the destination to capture, and the state machine starts only after the acknowledge. The torn-bus lesson of this section describes the same signature; the qualification lesson states the holding proof the waiver lacked.
The structural finding existed and was waived without the evidence the waiver policy requires, so the analysis did its job and the review did not. The process change is a rule, not a reminder: quasi-static waivers must attach the stability argument with timing, showing the value stable across synchroniser latency at every sampling moment, and any rewrite path voids the waiver automatically. The boot sequence now carries a directed test that rewrites the mode field at the worst moment and checks the captured value.
The register settled to the new value a cycle after the tear; only the state machine sampled the transient mix. The evidence has already corrected itself, which is why this bug needs the report history, not the lab readback.
The review: the analysis produced exactly the finding it should have, and the waiver accepted it without the required stability evidence.