The symptom is corruption with a clock: the first transaction after reset misbehaves, occasionally or on some boards only, and everything afterwards runs cleanly. Engineers chase the transaction logic for weeks because the bug never reappears once the system is up. The cause left the station one cycle after reset released.
First, release timing: an asynchronously asserted reset that deasserts near a destination clock edge violates the recovery and removal needs of the release flops, so some flops leave reset a cycle later than others and the domain wakes into a half-reset state. The deassertion-hazards lesson shows this shape, and the reset-synchroniser lesson gives the structure that prevents it: release synchronised through a chain in each destination clock. Second, release ordering: domains released in an order the design does not tolerate, for example a consumer released before the producer driving its inputs, so the first transaction samples uninitialised or pre-reset values. The release-order lesson states the discipline.
Suspect release when the failure is confined to the window just after reset and never recurs without a fresh reset. Confirm timing versus ordering by staggering the releases in the testbench: if delaying one domain's release moves or removes the failure, the order matters; if the failure follows one domain regardless of order, suspect that domain's release synchronisation. A waveform of the release edge against the destination clock settles timing questions directly: release transitions inside the recovery window are guilty on sight.
Structural RDC analysis reports unsynchronised deassertion and ordering violations as its own classes, and the debug playbook of the reset section maps symptoms to these causes. As with tearing, ask whether the finding was absent or waived: a missing reset definition hides every release in that domain, and a waived ordering finding without a release-sequence proof is the waiver process failing.
Fix timing with a reset synchroniser per destination clock and no logic that can glitch the release path; fix ordering with a sequenced release the design documents and owns. The guard is reset-aware simulation with staggered and skewed releases in regression, plus reset coverage that proves every domain was released last, first, and simultaneously against every other. A testbench that releases all resets together on one edge tests exactly one of those combinations.
Transaction logic would fail on later transactions too. A fault confined to the post-reset window implicates the state the design woke in: release timing or ordering.
Ordering: the failure depends on the relative release sequence, not on one edge landing near one clock. The design needs a documented release order, not just synchronised releases.