# Re: Thinking out loud about metastability - Page 3

#### Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

•  Subject
• Author
• Posted on
Re: Thinking out loud about metastability

Silly question: I don't see why an ANALOG flip-flop couldn't determine
that it is in the intermediate state at some fixed interval after the
clock, and then force the flop one way or another.  Of course, it
might double-glitch in the meantime (flop goes up before logic forces
it down), but it would make a flop with a fixed-maximum metastabel
interval.

Of course, it seems like such a massive headache to do.

The trick with asynchronous logic is that the longest stage WHICH IS
IN THE COMPUTATION is the critical path.  EG, if 9 of the stages take
1 ns, and the last takes 2ns, but the last only affects 1/2 the data,
with the asynchronous circuitry doing the shortcutting, it will be
considerably faster than the synchronous one.

The problem is: You can automatically balance the pipelining
(retiming) for a synchronous circuit, while asynchronous really playes
havoc with the CAD flow and testing.
--
Nicholas C. Weaver                                 snipped-for-privacy@cs.berkeley.edu

Re: Thinking out loud about metastability

DING DING DING

Nobody has been able to fix metastability yet.  If you really have
a fix, it's worth a Nobel Prize.

The usual problem with that sort of approach is that you get
a runt pulse on the fix-it signal in cases that would have worked
correctly without it.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

Yes, but the point is it would fix the maximum metastability window,
which is the key requirement, as "did the data come before or after
the clock edge" is really an irrelevant question at the metastable
capture point, you jsut want it to go to ONE or the other (not stick
around and make up its mind a half clock cycle later), and possibly to
tell you.

This isn't FIXING metastability, this is detecting and responding to
it, changing an exponentially decaying bounds into a fixed bounds.

Of course, it seems like way too big a headache to bother with.
--
Nicholas C. Weaver                                 snipped-for-privacy@cs.berkeley.edu

Re: Thinking out loud about metastability

If you could build a circuit with a "fixed bounds", that would solve
the metastability problem and you would be a hero.  (Just set your
clock period to that fixed bounds.)

I put metastability in the same category as perpetual motion.
I assume any proposal is wrong, even if I can't spot the problem
right away.   Best one I've ever heard of was a bicycle wheel
that ran off changes in air pressure.

If you have a circuit that you think will work, please send me
the schematic.  There is a reasonable chance I (or somebody here)
can find the bug in it.  No promises.  The thing I would look for is
runt pulses.

The best non EE-geek example of metastability I have seen is
rolling a ball over a speed bump.  Left of the bump is 0.  Right of
it is 1.  Give it a good shove and it goes over.  Give it a gentle
shove and it bounces back.  For some speed, the ball will teeter on
the top for a while, then fall off one side or the other.

The initial speed of the ball corresponds to meeting setup/hold times.
If the system is continuous, there is some value in the middle that will
cause troubles.  Setup/hold times and ball speed both seem continuous
to me.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

(snip)

One thing that I still remember from the first discussions about
metastability was that the sharper you make the peak, the smaller the chance
of getting into the metastable state, but the longer it stays when you get
there.   I don't know if the analogy is quite right, but consider a very
sharp speed bump.  It will deform the ball as it goes over, such that it
sticks more.

Not so long after that, I was taking a shower at a pool with a valve
designed not to stay on.  I managed to get it into the metastable (stay on)
state, so that I could wash with both hands.  (It worked just like the speed
bump, where on top of the bump the valve was on.)

-- glen

Re: Thinking out loud about metastability

It might be that you can change the shape of the probability vs. time curve,
while keeping the area constant.   That could reduce the probability of
metastability lasting too long for a given clock rate.

I don't know the physics well enough to say.  Also, it might be pretty
expensive to do that.

-- glen

Re: Thinking out loud about metastability

If you don't see the problem it is because you are not looking hard
enough.  The issue with metastability comes from trying to measure the
state of a FF or other digital voltage.  When a signal is at an
intermediate value a measurement can be inconclusive.  Your ANALOG FF
can be just as inconclusive as the digital FF.  Besides, the result is
always digital (or more accurately, discreet instead of continuous).

You are suggesting that you add a third state to the measurement, but
you get the same inconclusive measurement between the metastable state
and either the one or the zero states.  The result is that the output of
your ANALOG FF would be indeterminate which could result in
metastability in the next stage.

If I am not grasping your idea, then please provide more details.

Except that sync designs can do the same thing.  A multiply accumulate
typically takes twice as long as the other ops in a calculation.  So
they split it into two stages running at full speed.  Or if only half
the data needs the MAC, then they can do nothing since this will run at
full speed.

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

The flip flop core exists in one of THREE states: Vdd, Vss (the stable
points) and Vms +/- epsilon (the metastable range, in between Vdd and
Vss).

The analog circuitry in the flip flop measures the flip-flop state at
Tdelay after the clock edge.

If it is within Vms +/- a large epsilon (that is, metastable at this
point in time), the analog circuitry forces the flip-flop to Vss, and
also signals that a metastable capture/correction was performed.

This may cause a spurrious transition (eg, the metastable state is
measured, it goes high, and then the post-measurement kick drags it
back down to Vss).

The promise of the asynchronous is that this can occur on a much finer
grain, eg if all the ops are 1 ns, but the final one is either 1 or
1.5 ns.

Of couse, it has never really lived up to this promise, mostly because
the handshaking overhead can be severe, as well as the other problems
--
Nicholas C. Weaver                                 snipped-for-privacy@cs.berkeley.edu

Re: Thinking out loud about metastability

snipped-for-privacy@cs.berkeley.edu

The problem is that the analog circuitry that is trying to determine if
the flip-flop is in a metastable state can itself go metastable if the
flip-flop level is near Vms +/- epsilon.

Daniel Lang

Re: Thinking out loud about metastability

You are not accounting for the fact that the voltage is being measured
by the analog circuit and it can not distinguish between the metastable
state and the non-metastable states any better than the original FF
could distinguish the two valid states.  If the voltage is at the cusp
of the metastable range, the analog circuit will have an invalid or
indeterminate output and will not drive the FF to a valid state.  In
fact, it may drive the FF back toward a state with an even longer
transistion time.

This is very circular.  Each measurement has a range in which the
measurement is indeterminate within a given amout of time.  That is the
nature of metastability.  It is not just the state of the FF.  The FF
became metastable because it could not measure the input to be either a
1 or a 0.  Trying to measure the state of the FF has the same problem,

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability
The problem is with your three level "analog ff", instead of one metastable
region, you now have two, one at each side of your middle state.  All it
accomplishes is a redistribution of the metastable state at a cost of
considerably more complexity.  It doesn't fix anything at all.  As rickman and
others have stated, it comes down to a fundamental limitation in measuring a
quantity.  Measurement takes a finite amount of time to do.  If the transition
happens within that measurement window, you have a metastable event, which is
to say the measurement was indeterminate.  Works for digital logic,  works for
electron spins and so on.  If you really believe you have a work-around, then
you should publish it.  Be prepared to nurture your wounds though.  The paths
to the holy metastability grail is littered with bloodied bodies, many of whom
have followed the same trail you are considering.

"Nicholas C. Weaver" wrote:

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

It is possible -- I did it once for a FF design for another company.  It
requires a separate, combinational output signal ("metastable flag-out").
But, of course, there's no way to use this to kick the FF circuit itself out

The flag is generated by taking advantage of the fact that the latch going
metastable has a cross-coupled gate with a known threshold point during
metastability.  A 2-input logic gate with a different threshold can detect
that both inputs (ie, Q and Q-bar) are above (or below) it's own (different by
design) threshold point.

Cheers,
Ron Cline

Re: Thinking out loud about metastability

Why can't you use this flag to generate another (delayed) clock to the
same FF? It would continue to retrigger itself until it was in a
stable state. If you ORed all of these flags together in a register
you would have a data valid output.

Nothin like async logic to get your blood flowing!

Tom

Re: Thinking out loud about metastability

by

This newly-created feedback loop would have a much longer metastable
time-constant than had the original latch.  Better to leave well enough alone,
I think.

The flag wouldn't indicate a logic state (valid or not), only the presence of
metastability.  The logic state is indeterminant while the flag is active.

- Ron

Re: Thinking out loud about metastability

And what happens to the output of this MS-detector gate if one of the
voltages is right at the threshold of the gate?  Is it possible that the
output of the gate is at an intermediate voltage and is therefore
indeterminate?

Once again the problem comes from the measurement.  There is no knife
that is sharp enough to split every hair known to man or nature.

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability
I have never seen strange levels or oscillations ( well, 25 years ago we
had TTL oscillations). Metastability just affects the delay on the Q output.
Your suggestion seems to be to do exactly what one "should not do,"
namely use multiple synchronization flip-flops with tiny input routing
delay differences, and then do majority voting on the three outputs.
Seems like a smart idea, because it does not waste extra latency.

Peter Alfke, Xilinx
======================
"Nicholas C. Weaver" wrote:

Re: Thinking out loud about metastability

Well, just because the manufacturer isn't putting the info in the data
sheets, and don't
test for it, I suspect that you could get a rough description that could
Knowing, for instance, that the strobes will always follow a CPU clock
by at least
1 ns, and never change than 5 nS after the clock, would make designing a
synchronous
memory/peripheral controller running from the same clock a lot simpler.

If you can just get the roughest of descriptions of the clock vs.
strobes circuitry, you
can improve the system performance greatly, because you don't have to
have ranked
FFs on every strobe.

Now, on the high speed stuff, with clock multipliers, etc. it can get
quite complex, and
a CPU swap to the next higher speed can throw everything off due to a
change in clock
multiplier.  But, I gathered from the initial post that this wasn't a
clock multiplied CPU.

Jon

Re: Thinking out loud about metastability
Good luck even getting the structure out of the manufacturer though.  Even if
you do,
I think you'll find a good part of the delay is in the clock tree. Unless that is
characterized, you probably won't be able to infer much more than what the data
sheet
tells you.

Jon Elson wrote:

This

there

is

tell

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

Except that you don't know that this won't change if they tweek the chip
design.  It could very easily be 1 to 5 ns delay now and then change to
5 to 10 ns when they switch to a new process for cost savings.  The 5 to
10 ns delay will put it right at the falling edge where I would likely
be clocking it in with the old numbers.

Actually, yes the MCU runs at 8x or 4x the input clock.  But the output
is at the MCU rate and I will be clocking the FPGA with the 8x MCU
output clock.

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

What if one FF says '1', one FF says '0' and the last is someplace
inbetween?

--
Phil Hays