Reset Release and Removal Recovery

1. Engineering intuition — the danger is letting go, not grabbing

Think of asynchronous reset like grabbing a moving part: grabbing (asserting) is fine at any instant — it stops immediately. Releasing is where timing matters: let go right as the clock edge arrives and the flip-flop cannot decide whether it was still reset or about to capture, so it can hover in an undefined middle state (metastable) and resolve unpredictably — and different flip-flops can resolve differently, leaving the design in an inconsistent state. So the rule is: assert reset whenever you like, but make sure it releases at a safe time relative to the clock.

2. Formal explanation — recovery and removal

-- Around a clock edge, an asynchronous reset's DE-ASSERTION must respect two windows:
--   RECOVERY time: reset must be de-asserted at least t_rec BEFORE the active clock edge
--                  (analogous to setup) so the flip-flop reliably resumes clocking.
--   REMOVAL  time: reset must stay de-asserted at least t_rem AFTER the edge
--                  (analogous to hold) so the release does not disturb that edge's capture.
-- Violating recovery/removal → the flip-flop may go METASTABLE on the release.

Recovery and removal are the reset-release analogues of setup and hold for data. They constrain when asynchronous reset may de-assert relative to the clock edge. An unsynchronised, free-running reset release has no relationship to the clock and will eventually violate them — so the release must be made synchronous.

3. Production RTL — the reset synchroniser

library ieee; use ieee.std_logic_1164.all;
-- Assert ASYNC (immediate), de-assert SYNC: clock a '1' through two flops after async reset releases.
reset_sync : process (clk, arst_n)        -- arst_n: active-low ASYNCHRONOUS reset in
begin
  if arst_n = '0' then                    -- async ASSERT: clear the synchroniser immediately
    sync_ff  <= '0';
    rst_n    <= '0';
  elsif rising_edge(clk) then             -- sync RELEASE: shift a '1' in over two edges
    sync_ff  <= '1';
    rst_n    <= sync_ff;
  end if;
end process;
-- 'rst_n' is the clean reset used by the rest of the domain: asserts immediately, releases on a clock edge.

What hardware does this become? Two flip-flops whose asynchronous reset pins are driven by the raw arst_n (so they clear instantly on assert), and whose data path shifts a constant '1' through them after reset releases. The output rst_n therefore asserts asynchronously (the instant arst_n goes low) but de-asserts synchronously two clock edges later — by which point the release is aligned to the clock and the two-flop depth lets any metastability on the first flop settle. rst_n then resets the whole domain.

4. Hardware interpretation — the two-flop synchroniser

5. Simulation interpretation — assert at once, release on the edge

6. Debugging example — the unsynchronised reset release

Expected: the design comes out of reset cleanly and identically every time. Observed: intermittent, seed/voltage/temperature-dependent start-up failures; occasionally some flip-flops act reset for one extra cycle while others do not, leaving an inconsistent initial state. Root cause: a raw asynchronous reset de-asserted with no relationship to the clock, violating recovery/removal on some flip-flops and driving them metastable, so they resolved unpredictably (and at slightly different times across the chip). Fix: route reset through a reset synchroniser per clock domain — assert async, de-assert sync — so every flip-flop leaves reset on a clean, common clock edge. Engineering takeaway: an asynchronous reset must be released synchronously; an unsynchronised release is a metastability bug that hides as flaky power-up behaviour.

-- Use the synchroniser output (rst_n), NOT the raw async reset, throughout the domain.
process (clk, rst_n) begin
  if rst_n = '0' then state <= IDLE;
  elsif rising_edge(clk) then state <= next_state; end if;
end process;

7. Common mistakes & what to watch for

• Releasing async reset without synchronising. The core bug; always de-assert synchronously via a reset synchroniser.
• One synchroniser shared across clock domains. Each clock domain needs its own (its clock defines the safe release); share none.
• Using a single flop. Two (or more) flops give the metastability on the release time to settle; one is not enough.
• Synchronising the assert. Assertion should be asynchronous (immediate); only the release is synchronised.
• Forgetting reset is like a CDC problem. Reset release is effectively an asynchronous-to-synchronous crossing; treat it with the same synchroniser discipline as clock-domain crossing.

8. Engineering insight & continuity

Reset release is a metastability problem in disguise: asserting an asynchronous reset is free, but releasing it near a clock edge violates recovery/removal exactly as a data change violates setup/hold. The reset synchroniser resolves it cleanly — assert asynchronously for immediacy, de-assert synchronously for safety — and it is required once per clock domain. This is the mechanism that makes the hybrid reset of the previous lesson robust. The module now closes by consolidating everything into a strategy: the final lesson, Reset Best Practices, covers polarity conventions, selective reset, distribution, and the per-domain synchroniser as a coherent reset methodology, before the curriculum moves to Finite State Machines.