Real examples of metastability causing bugs

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

Reply to
-jg
Loading thread data ...

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.

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

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

Reply to
-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

Reply to
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

Reply to
Peter Alfke

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

Reply to
-jg

My favorite news service is

formatting link
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.

formatting link

-- Mike Treseler

Reply to
Mike Treseler

Seconded!

Cheers, Martin

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

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.