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
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
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
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
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
My favorite news service is
Thunderbird is has excellent support for news accounts and it's free.
-- Mike Treseler
Seconded!
Cheers, Martin
-- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
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.