Re: Real examples of metastability causing bugs

-jg wrote:

Peter Alfke wrote:
On Jan 11, 2:15�pm, -jg <Jim.Granvi...@xxxxxxxxx> wrote:
Yes it is small, but the analysis above seems a little suspect ?.

Of the 300MHz �edges, only one in every three has _any_ chance of
hitting
a metastable window, the others are effectively blanks.
Say one 300MHz edge is within 500ps, and so has some probability, the
next two
will be well clear of any window, and so have zero chance of
triggering an event.
So that would indicate 0.1fs, or 100 atto seconds. (still small)

You could verify that, by a change in the rate, and seeing if a drop
to 200MHz
did move the 'fire rate'.

-jg
Interesting argument, but it is wrong.
The easiest proof would be to imagine twice the clock rate, 600 MHz.
I know intuitively that the metastability rate would be much (very
much) higher, but by your reasoning, it would stay the same.

Very much ? - by your numbers it would only double ?
I think you are viewing this in terms of your test circuit, where the
clock does
more than one thing - it also checks for the failure, and in that case
yes, a faster clock would shrink the window, and so give (very much)
higher failure
rates.

My argument is a system only has a finitie number of data edges, and
so
one cannot sensibly claim to 'roll the metastable dice more often'
than that.
Well, one can, but the calculated result is unrealistically short :)

It should be possible to verify this on a test bench, but it would
need a test circuit
that did NOT change the metastable window snapshot, with clock
changes.

So, perhaps a Clock enable on the first register, that allowed 300MHz,
150MHz, 100MHz etc
samples of the 51MHz data (but other registers keep their window
sampling) ?

It is somewhat academic, I'll admit, as designers don't care if an
'apparent window' is
33 or 100 attoseconds wide - both values are well under any system
jitter.

Another interesting bench test, would be to see how many adjacent
samples could
be made to exceed a metastable window. With a slow phase velocity, and
good system jitters, a very small trigger window would say this would
be very rare. A wider trigger window would increase the probability of
two consecutive edges both failing.
If the jitter is 1000x as large as the trigger window, then the chance
of two consecutive failures is 1 in a million (assumes nominal phase
lock, just jitter errors )

-jg

Your argument was that two out of every three 300 MHz clock edges don't even have a CHANCE of creating the metastable event. Consider the "controlled" asynchronous version of this test where the 300 MHz clock is phase locked to the 50 MHz clock being sampled and the 300 MHz clock is phase shifted across the full 10ns of a single bit period. This 10 ns phase shift produces three capture window crossings. If you use a 200 MHz clock and shift those 10 ns, you will have two window crossings. If your sample clock frequency could approach infinity, you would *always* have a metastable event captured.

Peter's looked at this problem (measuring metastability) for a very, very long time with full experimental setups to verify his numbers. I don't believe the equations were created by him but have existed for ages. My first introduction to the theory and supporting equations was about 2 decades ago. Perhaps Peter Alfke authored that text.

- John_H
.

Relevant Pages

  • Re: Real examples of metastability causing bugs
    ... only one in every three has _any_ chance of ... a metastable window, ... The easiest proof would be to imagine twice the clock rate, ...
    (comp.arch.fpga)
  • Re: Power Consumption near Timing Failure Point
    ... Since the OP specifically asked about a window where setup violations ... Metastability can occur any where we have a feedback path in logic, ... The particular voltage of this ramp is predictable in time ...
    (comp.arch.fpga)
  • Re: HATE VISTA EVER MORE!!!
    ... FIRST OF ALL FUCKTARD, CHANGE YOUR CLOCK ... folder setup for a certain view, sorting, appearance, ... The window was resized and placed at a random location. ...
    (microsoft.public.windows.vista.general)
  • Re: Calling sysdm.cpl from MFC....
    ... I do the same thing with the clock. ... I tried it from control panel and noticed something ... temp window after launch (it's a blocking call so they probably need to kill ... lots and lots of balloons in that code, ...
    (microsoft.public.vc.mfc)
  • Window open / close vbscripting question
    ... When the clock ... What I want to do if possible, is when the server side asp vbscript is ... capable of coding server side script, I haven't done any client side ... Window A) Main server side script. ...
    (microsoft.public.scripting.vbscript)