Avoiding meta stability?

This misconception may be caused by not understanding that almost all modern logic is buffered. If the FF or latch is buffered, as almost all other modern packaged logic is, the buffering will hide the metastable level from observation. Old stuff like original TTL wasn't buffered, and the metastable state of latches was observable with an analog storage scope. For old TTL FFs, all sorts of amusing glitches, odd voltages, and variations in delay between Q and Q_bar could be observed. Buffering a latch is a very good thing, as it makes the metastable condition resolve faster by reducing the loading on the cross coupled gates that are the latch. If you build a latch or FF out of gates, FETs or transistors, you could observe the metastable state(s), as the metastable levels would be voltages on the wires between the components of the circuit. All sort of amusing behavior may be observed, depending on design details, if the setup/hold time requirements are not respected.

In case anyone wants to know, old TTL (74LS) needed about 20 ns excess delay for the same factor of a million reduction in metastability probability. To get the change of failure down to just once per 1000 years with a single FF you needed about 100 ns of excess delay.

See Figure 8 in:

Well, veterans of the TTL days (and I am one of them) can exchange horror stories about weird metastable behavior, but the modern CMOS flip-flops that I have tested repeatedly during the past 17 years behave much better. See XAPP094. The problem with metastability is not the unpredictable 0 or 1 outcome (who cares, either result is as justified as the other) or the strange level ( does not exist in buffered CMOS, or if it existed it could easily be fixed by biasing the buffer). The real, and unsolvable, problem is that metastability will cause a logic-level change at an uncontrollable moment. Most of the time just delayed by picoseconds or one or a few ns. But, very rarely, it can be more nanoseconds. Novices, with their eyes glued to a simulator, must be told that X just stands for "I do not know enough to tell you what it is", and not for "strange electrical level". Peter Alfke, Xilinx Applications

I just tried to instantiate the above module multiple times (for different async inputs), like this:

module tsync(input clk, input in1, input in2, output out1, output out2); test t1(.clk(clk), .in_sig(in1), .out_sig(out1)); test t2(.clk(clk), .in_sig(in2), .out_sig(out2)); endmodule

And I got a MAP error in XST:

Section 1 - Errors

------------------ ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=hset, RLOC=X0Y0) which require the combination of the following symbols into a single SLICE component: FLOP symbol "t1/ss_0" (Output Signal = t1/ss) FLOP symbol "t1/ss_1" (Output Signal = t1/ss) FLOP symbol "t2/ss_0" (Output Signal = t2/ss) FLOP symbol "t2/ss_1" (Output Signal = t2/ss) There are more than two registers. Please correct the design constraints accordingly.

Rookie mistake, I'm sure... but I'm stuck!! Help!

Regards, Paul.

I first heard about metastability in a discussion about the PDP-10 (KA10), which apparently had no metastability problem. The solution to metastability is asynchronous logic (also called self-timed logic).

That doesn't seem to have convinced very many people, though.

-- glen

Hi Glen, Are you joking around? If not, I'll bite.

I challenge you to design a metastability free traffic light controller from 'metastability solved' asynchronous logic. The lights are at a crossroads out in the sticks with low traffic volume. They are nomally both set RED until a car comes along. The lights then go GREEN in the direction from which a vehicle comes from. Make sure your logic doesn't go metastable when two cars arrive simultaneously from two orthogonal directions. Your controller must work no matter with whatever time difference the two cars arrive, and must work on EVERY occasion for EVERY car arrival timing scenario. Even one mistake in the lifetime of the universe is FAR, FAR too often for this junction!

Good luck, Syms.

p.s. I'm really in two minds about posting this, these threads grow like wildfire, and I don't want to be the arsonist. Needless to say, asynchronous design is NOT the 'solution' to metastability. Metastability always has a non-zero probability.

The D-flop is also an asynchronous circuit.

-- Mike Treseler

It's amusing that there is, in the strictest sense, no such thing as a completely synchronous circuit.

Indeed, it is the asynchronous nature of a FF that is the root cause of metastability ;)

Cheers

PeteS

Mike, That's a much better reply than mine! Thanks. Cheers, Syms.

(snip on asynchronous (self timed) logic)

I went back to see what I wrote before. I didn't say that it never went metastable, only that it wasn't a problem. I was told that sometimes one would see the console lights stop for a little while until the metastability was resolved. For the traffic light I would expect a possible delay from when the cars arrived until one of the lights turned green. As long as both lights can't turn green at the same time, you are still safe.

But current FPGAs are not very well designed for self timed logic. All the flip-flops are completely useless! It has been many years since I thought about actual designs (when KA-10's were around).

-- glen