Real examples of metastability causing bugs

glen herrmannsfeldt wrote:
> -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.

Simplest delays can be either RC, or Variable Vcc on Buffers,
or you could use a LC system for a phase
shifter, which should have less phase jitter than RC.

-jg

Peter Alfke wrote:
<paste>
> I do not see how metastability could ever be a "useful" feature.

I can think of a couple of useful tasks :
One would be as a seed scheme, for simple random number generation
systems.
Another would be for comparing very low jitter systems.
A metastable capture, means the edges were within a _very_ narrow time
slot,
so it can give information.


<snip>
>  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.

 I can see areas  where the work can be extended :)

The measurements themselves I doubt anyone has issues with.

Suppose we extend this to consider peak rates (as opposed to
averages, which assumes non-correlated frequencies)

First, let's move into the time domain, (as this is really a time-
domain
problem) and look at phase velocities :
For simplicity of a first pass, (and nice round numbers) let's also
assume a 0.1fs metastable
window. and a 100fs jitter - so jitter is 1000x larger than the
window.
Also treat the jitter as a rectangular probability

Now consider a 1.00MHz data rate, and two possible clocks, both chosen
to give
the same phase velocity of 0.1fs/cycle
Using CCalc, we have
> (1/(1e6+.1e-3))-(1e-6)
ans = -99.99999999000000000100000e-18  (we'll call that 100 atto
seonds, 0.1fs )
So, that's 0.1mHz above (or below) 1MHz

Now, do the same with a 100MHz clock - note that only one clock in
every 100
can sample the data, so the phase velocity is 100as in 100 cycles

((1/(100E6+10e-3))-(10e-9))*100
ans = -99.99999999000000000100000e-18
so 10mHz above (or below) 100MHz
[or look at is as 0.1ppb]

These two clocks have identical peak error rates, and sweep the 0.1ps
jitter window,
in 1000 consecutive data times. - This 1ms time is the expected 'hot
zone'.
Outside this, we would not expect to see any events.
The 1MHz clock repeats this zone every 10^4 seconds, or appx once a
day.
The 100MHz clock only has to go to the next cycle, so repeats the zone
every
100 seconds - so the average event rate is 100x higher at 100MHz, even
tho the
phase-velocities and peak rates are the same.

The data-referred sample window size, should be identical in both
cases, as it
depends on the FF, not the clock speed.

A good test system for these clocks would add the ability to capture
consecutive events
which are possible at the data rate (not the clock rate) , as well as
log the time-stamp for each, which would then allow a 'sampling scope'
style density plot to be built up
over time. This would enable post-test verify of the phase velocity,
(and actual
frequency correlations) and allow a profile of the equivalent
jitter.window combination.

Assuming frequencies are un-correlated, and taking an average
probability seems to
be a common engineering approach, but as time progresses, and
frequency sources
get better and better, and PLL are more widespread, and things like
GPS spread a
'global standard', it may be better to also consider peaks as well.

Of course, as someone has mentioned, you could PLL this to
deliberately sit in the 'hot zone'
as much as possible - and this may even give a means to 'quality test'
a given PLL, if you have the means to seek the hot zone. 'slow PLLs'
may be able to do this

The holy grail of a Metastable-seeking-PLL, would be one event every
data-sample :)

-jg

Well, perhaps you can find somebody or some institution to dive into
this.

I am far too pragmatic. I think 99% of all metastability problems
(real and imaginary) deal with uncorrelated clock frequencies. That's
why I wanted (and did) establish numerical results, so that everybody
knows what to be (or not to be) afraid of.
Since that goal is met, I rather spend my part-time effort on
convincing our circuit designers to improve the gain x bandwidth
product, in order to reduce the metastable capture eye even more.

Good luck with your sophisticated plans. I hope somebody else will
translate them into practicality and reality.
Action counts more than words!
Peter Alfke

Jim, I am sorry if I sounded cold and aloof. I did not realize that
"jg" is Jim Granville.
If I had, I would have given the same answer, but in a much more
personable and friendly tone.
This newsgroup needs all the warmth it can get, and I was amiss.
Sorry
Peter

Peter Alfke wrote:
> Jim, I am sorry if I sounded cold and aloof. I did not realize that
> "jg" is Jim Granville.
> If I had, I would have given the same answer, but in a much more
> personable and friendly tone.
> This newsgroup needs all the warmth it can get, and I was amiss.
> Sorry
> Peter

No problems, I am roaming (as you can probably guess) and so I am
forced to
use Google groups. A klunkier interface than what I am used to and it
does
obfuscate the poster ID more than my usual news reader.

-jg

-jg wrote:

> ... I am forced to use Google groups. A klunkier interface 
> than what I am used to and it does
> obfuscate the poster ID more than my usual news reader.

My favorite news service is
http://news.individual.net/
It works well at home or through firewalls.
It's 10 euro a *year*, and well worth it
for the trouble-free service from anywhere.

Thunderbird is has excellent support
for news accounts and it's free.
http://www.mozilla.com/thunderbird/

    -- Mike Treseler

Mike Treseler <mike_treseler@comcast.net> writes:

> -jg wrote:
>
>> ... I am forced to use Google groups. A klunkier interface than what
>> I am used to and it does
>> obfuscate the poster ID more than my usual news reader.
>
> My favorite news service is
> http://news.individual.net/
> It works well at home or through firewalls.
> It's 10 euro a *year*, and well worth it
> for the trouble-free service from anywhere.

Seconded!

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html