Mastering Asynchronous Resets in ASICs/FPGAs

We’ve seen in the last few posts mastering Clock Domain Crossing (CDC)—learning how to safely move single bits, multi-bit buses, and fleeting pulses across different clock domains without triggering metastability.

Today, we are looking at a signal that goes to almost every single flip-flop in your entire design: The Reset Signal.

In academia, the reset is just a theoretical switch that initializes your system. In the real world, releasing a reset at the wrong time will send your entire chip or FPGA into a catastrophic, unrecoverable metastable state. Let’s explore why this happens and how industry experts fix it.

Synchronous vs. Asynchronous Resets

When designing RTL, you generally have two choices for how to implement your resets:

1. Synchronous Resets: The flip-flop only clears its value on the active edge of the clock.

   • Pros: Completely immune to metastability from the reset signal itself.

   • Cons: If your clock is turned off (e.g., to save power), you cannot reset the chip!

2. Asynchronous Resets: The flip-flop clears its value the instant the reset signal is asserted, regardless of what the clock is doing.

   • Pros: Works perfectly even if the clocks are stopped or haven't stabilized yet.

   • Cons: Extremely dangerous when you release the reset.

Because modern System-on-Chips (SoCs) use aggressive clock-gating to save power, Asynchronous Resets are the industry standard. But they come with a massive hidden trap.

The Trap: Recovery and Removal Time Violations

We know from our previous CDC posts that data signals have Setup and Hold times. If data changes too close to a clock edge, the flip-flop goes metastable.

Asynchronous resets have the exact same physical limitations, but they go by different names: Recovery Time and Removal Time.

Asserting an asynchronous reset is perfectly safe. It forces the flip-flop to 0 immediately. The danger happens when you de-assert (release) the reset. If you release the reset button at the exact moment the clock edge is ticking, the flip-flop’s internal transistors get confused. Should they stay at 0 (because of the reset) or should they capture the new incoming D data (because of the clock)?

Just like a setup/hold violation, the flip-flop goes metastable. But unlike a data path where a single bad bit might corrupt a packet, a metastable reset signal means your state machines boot into illegal states. Your chip is effectively dead on arrival.

The Industry Solution: "Async Assertion, Sync De-assertion"

To get the best of both worlds—the ability to reset without a clock, but the safety of a synchronous release—engineers use a specific circuit topology called a Reset Synchronizer.

The rule of thumb for this architecture is: Asynchronous Assertion, Synchronous De-assertion.

Here is how the circuit works:

1. The Assertion (Asynchronous): When the external reset button is pressed, the signal bypasses the synchronizer's clock entirely and routes directly to the asynchronous clear pins of the reset synchronizer's flip-flops. The reset propagates instantly across the whole chip.

2. The Wait: The input data pin (D) of the first synchronizer flip-flop is permanently tied to 1 (or VDD).

3. The De-assertion (Synchronous): When the external reset is released, the chip doesn't wake up immediately. Instead, on the next clock edge, the first flip-flop captures that permanently tied 1. On the following clock edge, the second flip-flop captures it.

4. Safe Wakeup: The clean, synchronized 1 finally reaches the rest of your design, releasing the whole clock domain from reset perfectly aligned with the clock edge.

Why You Need a Tree

You cannot just use one reset synchronizer for your entire SoC. If you have 10 different clock domains (e.g., 1GHz, 400MHz, 50MHz), you must instantiate a dedicated Reset Synchronizer for each clock domain.

The raw external reset goes to all of them, but each domain wakes up perfectly aligned to its own specific clock frequency. This distributed architecture is known as a Reset Tree.

Takeaway

Treating a reset signal like a simple wire is a classic beginner mistake. In reality, a reset is a massive, high-fanout network that requires just as much architectural planning as your clock tree.

Whenever you are writing Verilog or SystemVerilog for a new module:

• Use asynchronous resets for your registers.

• Never feed an external reset directly into your main logic.

• Always pass your raw reset through a Reset Synchronizer clocked by that module's specific domain before letting it touch your functional flip-flops.