Asynchronous vs synchronous reset in FPGA

In short: Prefer a synchronous reset for the general FPGA fabric, but when you must use asynchronous reset always de-assert it synchronously through a two-flop reset synchronizer so recovery/removal timing is met and your design starts up cleanly.

Reset looks like the most trivial signal on a chip until a design intermittently boots into a bad state once every few thousand power-ups. On FPGAs, the choice between asynchronous and synchronous reset, and how that reset is released, is one of the highest-leverage reliability decisions you make. This article explains the real silicon behaviour, the recovery/removal timing checks that tools like Synopsys, Cadence and Siemens actually run, and the reset-synchronizer pattern every robust design should use.

Synchronous vs asynchronous: what the flip-flop sees

Every FPGA register has a data path and, optionally, a dedicated control input. A synchronous reset is just logic in front of the D input: the flop only changes on the active clock edge, so the reset is sampled like ordinary data. An asynchronous reset drives the flop's dedicated asynchronous clear/preset pin and forces the output low (or high) the instant it asserts, regardless of the clock.

On Xilinx (AMD) 7-series and UltraScale, and on Intel (Altera) Agilex/Stratix, the LUT register has both a synchronous (SR) and an asynchronous (CLR/PRE) capability, but you generally get one or the other cleanly — mixing them, or spraying async resets everywhere, costs routing resources and can block register packing into DSP/BRAM primitives.

The real hazard: releasing an async reset

Asserting an async reset is safe — the flop goes to its reset value no matter what. The danger is de-assertion. If the reset is released too close to a rising clock edge, the flop sees a changing control input inside its forbidden window and can go metastable, settling to an unpredictable value. Different flops in the same reset domain can then come out of reset on different cycles, producing a non-deterministic startup — the classic "works 999 times, hangs the 1000th" bug. This is the same physics behind metastability in FPGA clock-domain crossings.

Static timing tools model this with two checks: recovery time (reset must be released at least t_rec before the active edge) and removal time (reset must stay asserted at least t_rem after the edge). These are the reset-world analogues of setup and hold.

Recovery and removal, with numbers

Suppose a register has a recovery requirement of 0.35 ns and a removal requirement of 0.15 ns on a 300 MHz clock (3.33 ns period). The STA engine — Vivado's built-in timing engine, or Synopsys PrimeTime / Tempus for an ASIC prototype — computes the slack on the recovery and removal arcs just as it would for setup/hold. If your free-running, unsynchronized reset de-asserts asynchronously, these arcs are unconstrained and the tool reports them as failing or ignored — a silent reliability hole.

The reset synchronizer: best of both

The industry-standard solution is the asynchronous assert, synchronous de-assert reset synchronizer. Two flip-flops are chained; their asynchronous clear pins are tied to the raw reset, and their D inputs are tied to logic 1. When raw reset asserts, both flops clear immediately (fully asynchronous, works even before the clock is stable). When raw reset releases, the logic 1 ripples through the two flops over two clock edges, so the internal reset de-asserts synchronously and is guaranteed to meet recovery/removal on the fabric it feeds.

If FF1 goes metastable on the release edge, FF2 gives it one full clock period to resolve before the reset reaches the fabric, cutting the failure probability by many orders of magnitude (the MTBF scales exponentially with that settling time). For high-fanout resets, feed rst_sync through a dedicated reset buffer tree or a balanced fanout so skew does not re-introduce the staggered-release problem.

One synchronizer per clock domain. A single reset released into two different clock domains must be re-synchronized in each domain — otherwise you have reconverging reset skew, a cousin of the CDC bug.

Practical guidance for FPGA designs

• Default to synchronous reset for datapath and control logic — it packs better, avoids async routing, and plays well with retiming and shift-register (SRL) inference.
• Reserve async reset for the few places you truly need reset before the clock is reliable — power-on, PLL-not-locked, or safety shutdown.
• Never release a raw async reset directly into logic. Always pass it through a reset synchronizer.
• Constrain it. Mark the synchronizer input as a false/async path so STA checks recovery/removal only where meaningful, using set_false_path or an ASYNC_REG attribute in Vivado.
• Keep reset out of the hot loop. Many FPGA blocks (BRAM, DSP, FIFOs) initialize their contents on configuration and need no explicit reset at all — removing redundant resets frees routing and improves timing closure.

Teams building production FPGA and ASIC flows — from RTL through sign-off in Synopsys, Cadence and Siemens EDA toolchains — get this right by making the synchronizer a reusable, verified IP block rather than re-coding it per project. If you are architecting silicon rather than just configuring an FPGA, a design-services partner such as Avecas VLSI design services can help formalise reset strategy across clock and power domains.

For a deeper look at the related timing pitfalls, see our companion piece on clock-domain crossing in FPGA, and the full hands-on treatment in our FPGA and VLSI courses.

Want to design reset trees, CDC and timing closure with real tools on real boards? Explore CourseTron's FPGA Design & Timing Closure course and build production-grade RTL with confidence.

Frequently asked questions

Is asynchronous reset always bad on FPGAs?

No. It is essential when logic must reset before the clock is stable, such as at power-on or when a PLL has not locked. The rule is to assert asynchronously but de-assert synchronously via a reset synchronizer, which gives you early reset without the metastable-release hazard.

What are recovery and removal times?

They are the timing constraints on releasing an asynchronous reset relative to the clock edge. Recovery is the minimum time the reset must be de-asserted before the edge; removal is the minimum time it must stay asserted after the edge. They are the reset-domain equivalents of setup and hold, and STA tools check them explicitly.

Why two flip-flops in a reset synchronizer?

The first flop may go metastable on the release edge. The second flop gives it a full clock period to settle before the reset reaches the fabric, reducing the probability of propagating a metastable value by many orders of magnitude.

Do BRAMs and DSP blocks need an explicit reset?

Often not. FPGA memory and DSP primitives initialize at configuration, so adding an explicit reset can waste routing and hurt timing. Reset only the state that genuinely needs a known value at runtime.