Metastability is a condition in which a digital storage element (flip-flop, latch, or register) enters an indeterminate output state because a timing constraint was violated -- most commonly a setup or hold time -- or because an input signal was transitioning slowly through the threshold voltage at the moment of sampling, leaving the element unable to resolve to a valid logic level within a predictable time. The element will eventually settle to 0 or 1, but the settling time can be arbitrarily long with nonzero probability, and can exceed the clock period, causing downstream logic to sample an invalid value.
In practice
Metastability most commonly appears when a signal crosses a clock domain boundary -- for example, reading a GPIO pin, an asynchronous flag written by a different clock domain inside an FPGA or SoC, or an external interrupt input sampled near a clock edge. The receiving flip-flop may sample the signal right at its threshold voltage during a transition, entering an analog regime where internal feedback nodes drift slowly toward a valid rail rather than snapping to one immediately. The probability of failure decreases exponentially with time, which is why synchronizer chains (two or more flip-flops in series, clocked by the destination domain) are the standard mitigation on FPGAs and ASICs: each added stage multiplies the mean time between failures (MTBF) by a large factor, often enough to exceed the product lifetime.
On most FPGAs (Xilinx 7-series, Intel Cyclone/Arria, Lattice ECP5, etc.) the place-and-route tools can infer and optimize synchronizer registers when they are described correctly or instantiated through vendor primitives (e.g., Xilinx's ASYNC_REG attribute). These optimizations encourage the two registers to be placed in closely adjacent flip-flops with minimal routing delay between them, maximizing the resolution time available. Failing to use these attributes can leave the synchronizer looking identical to ordinary registers in the netlist, causing the tool to place them far apart and negate much of the benefit.
On microcontroller targets, metastability is usually less visible because most peripherals include internal synchronizers on asynchronous inputs. However, it can surface in bit-banged protocols, external interrupt inputs sampled very close to a clock edge, or when two processor cores in an AMP design share a flag register without proper synchronization hardware. Reading a shared variable protected only by a volatile qualifier, without a hardware synchronizer or handshake, does not eliminate metastability between asynchronous clock domains.
A key practical point is that metastability cannot be eliminated -- only managed. No combination of logic gates can guarantee a flip-flop will resolve within a fixed time if its timing constraints are violated. The correct engineering response is to make failure statistically improbable over the expected system lifetime through synchronizer design, not to assume the hardware "just works" because failures are rare.
Discussed on FPGARelated
Frequently asked
Can I prevent metastability by using a faster flip-flop or a higher-voltage process?
Faster technology reduces the characteristic resolution time constant (tau), which improves MTBF significantly -- but it does not eliminate the possibility of metastability. Any
flip-flop sampling an asynchronous signal can still enter a metastable state; the faster process just means it resolves more quickly on average, leaving more of the clock period as safe margin.
Why do two flip-flop synchronizers work? Why not just one?
The first
flip-flop may enter a metastable state, but it has the entire clock period (minus routing and setup of the second stage) to resolve. The probability that it is still metastable at the end of that period is very small. The second flip-flop then samples what is, with overwhelming probability, a valid logic level. A single flip-flop gives the downstream
combinational logic no extra resolution time, so a metastable output can propagate and corrupt results. Three stages are used when MTBF requirements are especially stringent or when the destination clock is fast relative to the source.
Does metastability only matter in FPGAs, or does it affect microcontrollers too?
It can affect both. Most MCU datasheets specify setup and hold times for GPIO and interrupt inputs relative to the internal sampling clock. If an external signal transitions within that window, the sampled value is undefined. Many MCU peripherals include built-in synchronizer stages or input filters to mitigate this, but bare-metal bit-bang I/O and inter-core shared-memory designs on dual-core MCUs (such as some STM32H7 or RP2040 configurations) require the developer to consider synchronization explicitly.
Is a volatile variable enough to safely share data between two clock domains or two cores?
No. volatile tells the compiler to always read/write the memory location and not cache it in a register, but it provides no hardware synchronization and no guarantee that a
flip-flop sampling the signal will not go metastable. For clock-domain crossings in
RTL, use proper synchronizer flip-flops. For multicore MCUs sharing SRAM, use memory barriers and atomic operations or hardware semaphores provided by the device (for example, the hardware spinlocks on the RP2040 or the HSEM peripheral on STM32H7).
How is MTBF calculated for a synchronizer, and what numbers are realistic?
MTBF is typically expressed as MTBF = exp(T_r / tau) / (f_dest * f_src * C), where T_r is the resolution time available (roughly one destination clock period minus setup and routing), tau is the
flip-flop's metastability time constant, and C is a process-dependent constant. Exact values for tau and C come from the silicon vendor's characterization data. For a well-placed two-stage synchronizer in a modern
FPGA running at 100 MHz, MTBF values in the range of millions to billions of years are achievable for typical asynchronous input rates -- but only if the synchronizer is placed and constrained correctly.
Differentiators vs similar concepts
Metastability is sometimes confused with a simple setup/hold violation or a logic
glitch. A setup/hold violation is the cause -- the condition that puts a
flip-flop at risk. Metastability is the resulting analog behavior: the flip-flop enters an indeterminate state and drifts slowly to a valid level. A glitch, by contrast, is a momentary spurious pulse in
combinational logic due to unequal propagation delays; it can trigger metastability if it reaches a flip-flop's data input near a clock edge, but glitches and metastability are distinct phenomena. Metastability is also distinct from a race condition in software, though both involve timing-dependent behavior; metastability is a hardware physics phenomenon rooted in analog circuit dynamics, not a scheduling or ordering problem in code.