# What is metastability?

From the Wikipedia article Metastability in electronics:

Metastability in electronics is the ability of a digital electronic system to persist for an unbounded time in an unstable equilibrium or metastable state. In metastable states, the circuit may be unable to settle into a stable '0' or '1' logic level within the time required for proper circuit operation. As a result, the circuit can act in unpredictable ways, and may lead to a system failure.

That seems to be a good definition, but what does it mean in an application?

From an electronics designer's standpoint, what are some examples of when this might occur and where should this type of failure be of concern?

Is there a more pragmatic or applied definition - something in more specific terms?

Quick Answer: If you violate the setup and hold time on the input of a flip flop, then the output will be unpredictable for some amount of time. That unpredictable output is called meta-stable (or metastability).

Long answer: When the output is unpredictable, I mean that it's unpredictable. It could be high, it could be low, it could be somewhere in between, or it could oscillate. After this metastable period the output will be high or low, but we don't know which way it'll go until it happens.

The amount of time that it's unpredictable is somewhat predictable, however. There are two main factors that determine the length of the metastable period: The speed of the flip-flop, and how "close to the edge" you got the timing.

Most of the metastable times are quite short, although the probability of having a long time is non-zero. Theoretically you could have a metastable time on the order of seconds, although the odds of that happening are incredibly rare. As the speed of the flip-flop increases, the average metastable time decreases-- all other things being equal.

There is an "imaginary" time in the flip-flop, relative to the clock edge, where you're most susceptible to metastability issues. Exactly when that is depends on lots of factors like temperature, voltage, process, phase of the moon, animal sacrifices, and what political party you affiliate with. Whenever that time is, the closer your data input edge is to that time the longer the metastability time will be.

The best way to deal with metastability is to make all of your logic synchronous, and not violate any of your setup and hold times. This is, of course, difficult to impossible for circuits of any complexity. So what we do is try to limit the places where metastability could be an issue and then deal with those places.

The normal method would be to "double-clock" the data. Meaning, have two D Flip-Flops in series with the output of the first feeding the input of the second. The hope is that if the first flip-flop goes metastable then the metastable period would be over before it violates the setup/hold time of the second. In practice this works fairly well. In super critical applications there might be some "triple-clocking" going on.

• Any dependencies on the type of animal sacrificed ? Jun 1, 2011 at 0:39

A metastable state is similar to an unstable equilibrium. A common example of an unstable equilibrium is an inverted pendulum. If you can balance the pendulum in a vertical position, that is a stable state. However, if anything pushes the lever to either side (air currents or ground vibrations, for example), the pendulum will not restore itself to the vertical position, it will fall down. Contrast with a regular pendulum, which if pushed to one side, will eventually settle back to vertical.

Stable equilibria are used in electrical systems to create storage elements. Unstable equlibria don't make good storage elements (since they lose their state easily), but often exist as a parasitic state.

A common digital storage element is a pair of cross-coupled inverters:

The storage element has two stable states, one where the node on left is at the supply voltage and the node on the right is at ground, and the other in the opposite condition. There is also an unstable state, in which each node is at some intermediate voltage.

To better understand how the unstable state arises, recall the transfer function for an inverter. The plot of the transfer function shows the output voltage of the inverter for a given input voltage.

The inverter is non-linear; one simple way to obtain an approximate solution of a non-linear circuit is to plot the circuit characteristics; the intersections of the plots are the solutions, or in other words, the points where the electrical characteristics of all components of the circuit are satisfied. Normally this is done with i-v plots as in this diode example at Wikipedia. However, for the inverters, we'll do it with v-v plots. Overlaying a second inverter transfer function on the plot (with the axes swapped, since the second inverter is backwards:

There are three intersections of the plots: one at (0, Vs), one at (Vs, 0), and one at (Vs/2, Vs/2). The (Vs/2, Vs/2) state is metastable. After a small perturbation of either node, the circuit will almost always settle to one of the stable states rather than returning to (Vs/2, Vs/2).

The way to write a value to the dual-inverter storage element is to force one of the nodes to the desired value using a driver that is stronger than the inverters. One common way to do this is with a pass transistor:

If you connect the gate of the pass transistor to the clock, you have a D latch (I'm leaving out the output structure). When the clock is high, enabling the pass transistor, the latch is transparent — input passes directly to output. When the clock is low, the latch holds the previous value. Metastability arises at the moment the latch samples. If the input is a stable high or low voltage when the latch samples, then it will work properly. However, if the input is around the Vs/2 point when the latch samples, there's a possibility the latch will end up in the metastable (Vs/2, Vs/2) state. Once it's in the metastable state, it can stay there indefinitely (assuming the latch isn't clocked again), but since it's an unstable equilibrium, something usually happens relatively quickly to knock it out of the metastable state.

## When to worry about metastability

If your storage elements are going metastable, then you're at the very least losing some of the timing budget for the downstream logic. The logic can't perform the desired evaluation until the metastable state resolves. In the worst case, the metastable state persists or propagates through logic, and downstream storage elements also go metastable, or multiple related storage elements capture inconsistent values.

Properly designed and functioning synchronous logic doesn't have problems with metastability. The clock period is longer than the evaluation time for the logic, all the flip-flop inputs are stable at the next clock edge (setup requirement satisfied), and they all load a valid value.

Some of the common situations where metastability is a concern are:

• Logic sampling an external input, for example, a switch on the front panel, or the output of monitor circuits that may transition at any time (undervoltage, overtemp).
• Logic using multiple clocks that don't have a synchronous relationship. This often arises with I/O interfaces that have particular clock requirements, but also occurs internally when different parts of a chip have different performance requirements. For example, not all of the logic in your 3 GHz CPU is actually running at 3 GHz. (A CPU is not a great example, though, since many of the clocks in a CPU are synchronous multiples of each other.)
• Mostly nice answer, but another thing to mention is that because of propagation delays, there's no single metastable state but rather a whole family of them, and there's no certain way to identify metastable states. One may design a circuit with a three-state output (high/low/metastable), and arrange things so that "high" will never be reported if the output may end up going low, or vice versa, but there's no guarantee the output won't bounce between 'high' and 'metastable' (ending up 'high'), or between 'low' and 'metastable' (ending up 'low'). May 31, 2011 at 16:31
• +1 This is good stuff but it makes more sense after reading @David Kessner's answer. +2 For the graphics. Jun 1, 2011 at 0:38

A metastable signal is one which may arbitrarily appear to be high or low in any arbitrary pattern for some arbitrary length of time. If the signal feeds multiple gates directly or indirectly it's possible that some of those gates will "see" it high while others see it low. Nasty stuff.

For systems with a single clock, metastable signals can often be dealt with by passing through two latches. A trickier issue comes when gating clocks. There are a lot of circuits (especially using RS latches) which would work wonderfully if metastability weren't possible, but which can, if metastability occurs, end up generating runt clock pulses (which in turn can cause downstream metastability).

Incidentally, another important point to make regarding metastability: a latch's propagation time indicates when, if sample and hold times are met, the output will be stable at its new value. If setup and hold times are not met, there is no guarantee as to if or when the output will or will not switch, until such time as the latch receives a valid clocking event. Even if the output 'seems' to switch cleanly, there's no guarantee it won't spontaneously switch back.

The classic case is if you violate setup/hold times for a synchronous latch, and is an issue you need to be aware of when designing FPGAs (I'm sure Xilinx and Altera will have appnotes on this). If a signal can come along at any random time, you can never be sure that when you clock it, it isn't changing within the setup/hold time window spec. What can happen is instead of the latch output going high or low at the specified time after the clock edge, it can dither about for a while before settling at a stable state. The normal way to prevent this is to use a 2-stage latch, either with the same clock or a delayed or out-of-phase clock depending on the balance between your latency requirements and probability of metastability. This allows the first latch time to stabilise before the second latch latches a stable state. Incidentally, this is something that microcontrollers have to deal with internally, as external I/O signals are usually asynchronous to the CPU clock, so I/O ports often have dual latching arrangements to avoid problems, and the software doesn't need to worry about it. A vaguely recall reading many years ago about a problem with the 6502, where a bus read of data which changed outside the setup/hold time spec could cause a branch to an address that was neither the branch target nor the next instruction, as some internal state went metastable. This video shows some examples : http://www.youtube.com/watch?v=tKHCwjWMMyg

An analogy is if you throw someone a ball - they mostly either catch it or drop/miss it, so after a given time from throwing, they will either be holding it or not. But occasionally they will fumble for a while before either catching or dropping it, so their state is neither holding nor dropped - this is the metastable state!

• I still work with 6502-based systems as a hobby. It'd be nice to know some particulars of metastability problems on bus data. I can certainly envision that if the accumulator holds $FF and one reads a value that's either$00 or \$01, the accumulator could end up with any possible value. Before any branch could be taken, though, I would expect two more cycles would have to elapse, during which the flags would get relatched twice. I can't imagine a metastable state remaining for that long. May 30, 2011 at 1:36
• This was something I heard second or third hand maybe 20 years ago, but it did originate from people that absolutely knew what they were doing - it was to do with the Tube interface on the 6502 second processor for the BBC Micro, and reading of status flags, and was a once-n-a-blue-moon occurrance but frequent enough that it delayed the product launch. It wouldn't have necessarily needed to last 2 cycles as signals are probably being latched internally at various stages of the pipeline. I think it was also the fastest 6502 variant available at the time - 3MHz 65C02 ISTR. May 30, 2011 at 8:49
• Interesting. [BTW, is there any way to use punctuation without StackExchange munging it?] In the normal behavior of e.g. "ADC 0xD000" the address would be output on phase 1 of the fourth cycle, and the data would be latched at the end of phase 2 of that cycle. The data would feed into the ALU in phase 1 of th next cycle (which would be the opcode fetch for the following instruction). The cycle after that would be the operand fetch. If things were still metastable at that point, the system could melt down, but that would seem unlikely since the dynamic registers would have been relatched twice. May 30, 2011 at 15:27
• I don't want to say it's impossible for data-bus metastability to affect the 6502, because I know there are some other weird behaviors I can't explain. For example, the data bus is latched during phase 2 of the clock, and acted upon during the following phase 1. It thus shouldn't matter if it changes during phase 2 provided it's stable at the end. There are a few undocumented instructions, however, whose behavior is affected by the contents of the data bus during the earlier part of the cycle (demonstrable on machines like the C64 and Apple that fetch video during phase 1). I don't know how... May 30, 2011 at 15:29
• ...the behavior of those instructions is actually getting affected by the early data bus behavior, but I suspect it's some sort of weird race condition. IIRC, one of the opcodes matches the decode patterns for LDA #imm, LDX #imm, and TAX, so the ALU's output is being mapped back to its input. Weird. May 30, 2011 at 15:31

I think it's worth noting that metastability is a manifestation of a law of nature: Buridan's Principle ("You can't in bounded time form a settled view of a continuous variable"). The best you can do is determine the probability of a failure and allow enough time (i.e. in this application, more sequential registers) for that probability to be low enough for your application.