Real examples of metastability causing bugs

-jg wrote:
> John_H wrote:
>> -jg wrote:
>>
>> Your argument was that two out of every three 300 MHz clock edges don't
>> even have a CHANCE of creating the metastable event.
> 
> Correct. You can roll the dice once, but not three times.
> 
>> 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.
> 
> I'm not sure I follow?. Peter's test circuit uses the clock for two
> different things.
> Once to sample the data stream and again to set the settling window,
> to decide
> if metastable events occured.
> Yes, this is nice and simple, but can give the illusion that the
> faster clock gives more transistion-settling-event samplings.

If you had a fixed delay to measure the metastability delay rather than 
the sampling clock, you remove that second clock from the situation.

If you think of statistics and imagine the capture window *is* 33 
femtoseconds then the chance of *any* random edge hitting that capture 
window in the 10 ns data period (provided by the 50 MHz clock being 
sampled) is 33fs/10ns.  If you could produce 300 million sampling edges 
(at any frequency, doesn't matter) where the edges increment in phase 
offset relative to the 10ns period by 33fs each step (assuming zero 
jitter *here*) then one and only one clock will cause a metastable 
event.  When 300 million edges are presented asynchronously, these 300 
million edges have a flat statistical distribution across the 10ns period.

>>   If your sample clock frequency could approach infinity, you would
>> *always* have a metastable event captured.
> 
> Yes, a good limit case (assuming zero jitter) : This case would have
> these events every 10ns (not every clock)  - you cannot have more
> transistion-settling-events than transistions :)

An infinite clock limit means metastability with or without jitter. 
Your assumption that jitter would be important in this limit case helps 
reinforce my view of your mathematical reasoning.

> With a difference of 3:1 between CLK and Edge rates, the distinction I
> am trying to make
> is not large on the scale of metastable values, but I would derive a
> different window-size than Peter, from the same data.
> 
> Should be easy enough to verify, and also get better test vehicles for
> more accurate
> window sizes. If I was making chips, I'd like to know that number as
> precisely as possible
> (even tho it is way below any jitter, and some would say 'who
> cares?')  because it could indicate if a new process was actually
> better than an older one.
> 
> -jg

So do the darned verifications!  You appear not to believe the many 
verifications that Peter HAS DONE.  Your nay-saying an expert on this 
issue is silly and annoying.  I wouldn't bother trying to underscore the 
validity after these first attempts if this was just a private 
discussion.  I'm concerned that people who don't know much about 
metastability would see this conversation as an indication that the 
issues aren't clear.

Are there any other well defined issues you'd like to cast doubt upon? 
I mean... while we're at it.

- John_H

John_H wrote:

> I'm concerned that people who don't know much about
> metastability would see this conversation as an indication that the
> issues aren't clear.

I agree.
This same discussion is dug up about once a year.
This is where electronics meets quantum mechanics.
Many smart people have been fooled on this subject.

       -- Mike Treseler

John_H wrote:
>
> So do the darned verifications!  You appear not to believe the many
> verifications that Peter HAS DONE.  Your nay-saying an expert on this
> issue is silly and annoying.

You do not seem to be reading what I am writing.

I have no issue with Peter's measurements, or his test circuits,
but I do have a small issue with the derived window size, that he
then calculates from those measurements.

As I have already stated it is somewhat academic, and does
an end user care if it is 33 atto seconds, or 100 atto seconds ?

Both are very small numbers.
.
-jg

-jg wrote:
> 
> John_H wrote:
>> So do the darned verifications!  You appear not to believe the many
>> verifications that Peter HAS DONE.  Your nay-saying an expert on this
>> issue is silly and annoying.
> 
> You do not seem to be reading what I am writing.
> 
> I have no issue with Peter's measurements, or his test circuits,
> but I do have a small issue with the derived window size, that he
> then calculates from those measurements.
> 
> As I have already stated it is somewhat academic, and does
> an end user care if it is 33 atto seconds, or 100 atto seconds ?
> 
> Both are very small numbers.
> .
> -jg

And the discussion on why those numbers are valid appears to escape you. 
  Just because 2 of the three clocks "never have a chance" of causing an 
event doesn't let you limit the even statistical distribution of edge 
position within the period to the "single edge closest to the window."

If the two clocks were different by a factor of 100 rather than a factor 
of 3, your suggestion on calculating the window size would be much less 
than academic.

I know you have an issue with the derived window size.  I have read your 
posts.  I see why your view of the approach is wrong.  I've tried to 
give you different directions to look at the problem to see why your 
observations are less than complete.

I like to see people understand.  I don't see it here.

- John_H

John_H wrote:
>
> And the discussion on why those numbers are valid appears to escape you.
>   Just because 2 of the three clocks "never have a chance" of causing an
> event doesn't let you limit the even statistical distribution of edge
> position within the period to the "single edge closest to the window."
>
> If the two clocks were different by a factor of 100 rather than a factor
> of 3, your suggestion on calculating the window size would be much less
> than academic.
>
> I know you have an issue with the derived window size.  I have read your
> posts.  I see why your view of the approach is wrong.  I've tried to
> give you different directions to look at the problem to see why your
> observations are less than complete.
>
> I like to see people understand.  I don't see it here.

There are also two error types, the average one, and the peak one.
Sometimes in engineering, we like to think about worst case, as
well as averages.

Someone else mentioned a locked metastable generation system,
ie one that deliberately tries to be metastable.

Suppose I have a 1MHz data rate, and choose a 1MHz (+ErrN) Clock,
-or- a 100MHz(+ErrM), and assume a 'nominally' real system with
nice round numbers of a 0.1fs window, and 0.1ps jitter

Q1: Can these widely variant clocks ever give the same peak error
rates ?
Q2: Can the error rate ever go above one per microsecond  ?

-jg

On Jan 12, 10:24=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> -jg wrote:
>
> > John_H wrote:
> >> So do the darned verifications! =A0You appear not to believe the many
> >> verifications that Peter HAS DONE. =A0Your nay-saying an expert on this=

> >> issue is silly and annoying.
>
> > You do not seem to be reading what I am writing.
>
> > I have no issue with Peter's measurements, or his test circuits,
> > but I do have a small issue with the derived window size, that he
> > then calculates from those measurements.
>
> > As I have already stated it is somewhat academic, and does
> > an end user care if it is 33 atto seconds, or 100 atto seconds ?
>
> > Both are very small numbers.
> > .
> > -jg
>
> And the discussion on why those numbers are valid appears to escape you.
> =A0 Just because 2 of the three clocks "never have a chance" of causing an=

> event doesn't let you limit the even statistical distribution of edge
> position within the period to the "single edge closest to the window."
>
> If the two clocks were different by a factor of 100 rather than a factor
> of 3, your suggestion on calculating the window size would be much less
> than academic.
>
> I know you have an issue with the derived window size. =A0I have read your=

> posts. =A0I see why your view of the approach is wrong. =A0I've tried to
> give you different directions to look at the problem to see why your
> observations are less than complete.
>
> I like to see people understand. =A0I don't see it here.
>
> - John_H

This discussion is not about politics or religion: This is science,
and there is only ONE correct answer. But the newsgroup is a poor
vehicle to convince someone who does not want to "get it". This debate
should not go on forever...

On a related subject: It amazes me that there is so much talk and fear
about metastability, but  nobody gets his fingers dirty and performs
real measurements.
I published "my" original  circuit 18 years ago (!), and to my
knowledge no university has picked this up as a simple challenge. Any
competent student can grasp the concept in less than a week, and
anybody with the skill to configure FPGAs or CPLDs can duplicate these
experiments in a short time with simple equipment, ( an eval board, a
variable clock source, and a stop watch), and every experiment usually
runs for less than an hour. Why does nobody try to PROVE me (and
Xilinx) right or wrong?
I have publicly (in this newsgroup) offered my assistance, but nobody
responded.

IC manufacturers (including Xilinx) do not seem to see metastabilty as
a very important subject.
There are always more burning design issues, like raw speed,
functionality, size and power consumption that take precedence.
Further "metastability-hardening" might compromise some of the other
important aspects. FPGAs have up to hundreds of thousands of flip-
flops, and only a few of them will ever be challenged with
metastability.

We all know that we can never avoid metastability, but I wanted to
have quantitative proof that we can live with it, and have ways to
design around it.
Is a one-man effort sufficient for that ? Thanks for your trust, but
it feels a bit lonely...
Peter Alfke

-jg wrote:
> 
> John_H wrote:
>> And the discussion on why those numbers are valid appears to escape you.
>>   Just because 2 of the three clocks "never have a chance" of causing an
>> event doesn't let you limit the even statistical distribution of edge
>> position within the period to the "single edge closest to the window."
>>
>> If the two clocks were different by a factor of 100 rather than a factor
>> of 3, your suggestion on calculating the window size would be much less
>> than academic.
>>
>> I know you have an issue with the derived window size.  I have read your
>> posts.  I see why your view of the approach is wrong.  I've tried to
>> give you different directions to look at the problem to see why your
>> observations are less than complete.
>>
>> I like to see people understand.  I don't see it here.
> 
> There are also two error types, the average one, and the peak one.
> Sometimes in engineering, we like to think about worst case, as
> well as averages.
> 
> Someone else mentioned a locked metastable generation system,
> ie one that deliberately tries to be metastable.
> 
> Suppose I have a 1MHz data rate, and choose a 1MHz (+ErrN) Clock,
> -or- a 100MHz(+ErrM), and assume a 'nominally' real system with
> nice round numbers of a 0.1fs window, and 0.1ps jitter
> 
> Q1: Can these widely variant clocks ever give the same peak error
> rates ?
> Q2: Can the error rate ever go above one per microsecond  ?
> 
> -jg

There's a minute possibility the error can happen on several consecutive 
clock cycles so yes - the instantaneous rate can far exceed one event 
per statistically-even distribution of edges because they have 
probabilities of hitting the window, not certainties.  Over a long 
enough period of time (high enough population) the error will approach 
the statistical expectations.

If your example is the MLL - the Metastability Locked Loop - then jitter 
has a strong impact but to determine the actual error rate, the jitter 
distribution has to be part of the equation.  There are too many ways to 
describe jitter.  If the MLL is ideally centered, then the percent of 
population of the 0.1fs window has to be determined relative to the 
"0.1ps" jitter distribution.  The 0.1ps could be RMS or peak-to-peak 
with any of several multiplying factors from RMS.

But IT DOESN'T MATTER.  For determining the sampling window size, an 
even statistical distribution across a fixed period will give you the 
best statistical results.

Even in the totally asynchronous case, the possibility of hitting the 
same window multiple times in a row exists; it's just a very small 
probability.

If you want to think "peak error rates" you could envision a system 
similar to the originally proposed 300MHz/50MHz system (that produces an 
average of 1 event per second) and have the relative frequency offset be 
so small that it take a minute for the sampling window to be visited by 
the "next" consistently located edge in this nearly synchronous design. 
  In that situation, the events will "burst" about 60 errors in a short 
period of time.  In an asynchronous system, the probability that the two 
signals are that close in frequency for such a long period of time is 
extremely small.

If you want to continue serious discussion on this topic, please mail me 
directly.  I figure others in this group are starting to glaze over when 
they see this thread belabored more and more.  I may need to dig up some 
resources to start talking specific population ratios for jitter 
distributions but I could deliver the math.

- John_H

>On a related subject: It amazes me that there is so much talk and fear
>about metastability, but  nobody gets his fingers dirty and performs
>real measurements.
>I published "my" original  circuit 18 years ago (!), and to my
>knowledge no university has picked this up as a simple challenge. Any
>competent student can grasp the concept in less than a week, and
>anybody with the skill to configure FPGAs or CPLDs can duplicate these
>experiments in a short time with simple equipment, ( an eval board, a
>variable clock source, and a stop watch), and every experiment usually
>runs for less than an hour. Why does nobody try to PROVE me (and
>Xilinx) right or wrong?

Maybe you did a good enough job that the area isn't interesting
any more?

I'd like to see data for different temperature, voltage,
and rise times.  I'm a bit surprised a university hasn't
jumped on that one.

The rise times are hard to measure and control inside a FPGA.
Maybe just long routing vs short routing would be interesting.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

On Jan 13, 3:40=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >On a related subject: It amazes me that there is so much talk and fear
> >about metastability, but =A0nobody gets his fingers dirty and performs
> >real measurements.
> >I published "my" original =A0circuit 18 years ago (!), and to my
> >knowledge no university has picked this up as a simple challenge. Any
> >competent student can grasp the concept in less than a week, and
> >anybody with the skill to configure FPGAs or CPLDs can duplicate these
> >experiments in a short time with simple equipment, ( an eval board, a
> >variable clock source, and a stop watch), and every experiment usually
> >runs for less than an hour. Why does nobody try to PROVE me (and
> >Xilinx) right or wrong?
>
> Maybe you did a good enough job that the area isn't interesting
> any more?
Nice assumption...
>
> I'd like to see data for different temperature, voltage,
> and rise times. =A0I'm a bit surprised a university hasn't
> jumped on that one.
>
> The rise times are hard to measure and control inside a FPGA.
> Maybe just long routing vs short routing would be interesting.


Hal, XAPP094 shows the (not-surprising) effect of different voltages.
I am sure that the external rise time would be totally swamped out by
the gain in the clock buffering.
Routing delays just move the time laterally, have no effect on the
measurements.
Don't expect newer families to be any better. The lowering of supply
voltages has a bad impact...
(But no need to cry, metastable delays are short enough for almost all
cases; and smart users know the remedies for the remaining extreme
cases)
The obviously better total systems performance of the newer families
comes from architecture and systems improvementss, not from a faster
gain x bandwidth product in the flip-flops.
 IMHO, somewhat of a guess...
Peter Alfke

-jg wrote:

(snip)

> There are also two error types, the average one, and the peak one.
> Sometimes in engineering, we like to think about worst case, as
> well as averages.

> Someone else mentioned a locked metastable generation system,
> ie one that deliberately tries to be metastable.

> Suppose I have a 1MHz data rate, and choose a 1MHz (+ErrN) Clock,
> -or- a 100MHz(+ErrM), and assume a 'nominally' real system with
> nice round numbers of a 0.1fs window, and 0.1ps jitter

I had originally thought of it based on a PLL, which would have
jitter.  That would be part of the measurement.

There is a web site in another post that uses one clock with a
variable delay.  That may help as far as jitter.

> Q1: Can these widely variant clocks ever give the same peak error
> rates ?
> Q2: Can the error rate ever go above one per microsecond  ?

That is still a lot faster than without a lock system.

-- glen