...
This may be showing the jitter on the P2 sysclock ?
I would say so. The 10MHz reference clock generator shows 461fs(rms) of phase jitter (12-5000KHz) on the output I was using. See the "datashort" to see more details and some scope data.
I would say so. The 10MHz reference clock generator shows 461fs(rms) of phase jitter (12-5000KHz) on the output I was using. See the "datashort" to see more details and some scope data.
That's quite a decent source, but thinking on this some more, I'd expect that large number of samples (100,002) to average down the jitter ?
It may be that ~90ps is already averaged down ?
Picking one variance, 1254196-1253059 = 1137 counts difference in 10ms, over 100002 gate pulses.
There could be a low beat frequency between the 250 MHz sample rate and the input frequency that contributes to a varying duty cycle via gradual aperture shift.
I forgot to mention that I had to do some unorthodox things in order to get those measurements. For one, I didn't used any terminating resistor. Also, I hadn't used a ground return connecting the GR10M-S and the P2 Eval grounds, as that seemingly aided noise and introduced a very noticeable and very variable skew in the frequency and duty cycle readings. That makes me wonder.
I would say so. The 10MHz reference clock generator shows 461fs(rms) of phase jitter (12-5000KHz) on the output I was using. See the "datashort" to see more details and some scope data.
That's quite a decent source, but thinking on this some more, I'd expect that large number of samples (100,002) to average down the jitter ?
It may be that ~90ps is already averaged down ?
Picking one variance, 1254196-1253059 = 1137 counts difference in 10ms, over 100002 gate pulses.
I would place my bet on the fact that any deviation is mostly on the P2 Eval XO. However, expect some deviation on the GR10M-S side. Mind that the ±25ppb of stability does not translate to accuracy, as you may know. The free run accuracy of the OCXO used in the GR10M-S reference clock allows for a ±4.6ppm deviation, in the worst case scenario. As for jitter, i seriously doubt that the P2 Eval would be able to capture any. Even the possibility that it can capture wander is very dubious.
There could be a low beat frequency between the 250 MHz sample rate and the input frequency that contributes to a varying duty cycle via gradual aperture shift.
Yes, plotting the %H variances may give a clue.
Samuell's numbers suggest a ~16ppm offset, of P2 to his reference clock.
Maybe a better P2 clock source, or a trim-cap, can lower than ppm to reduce the beat frequency ?
There could be a low beat frequency between the 250 MHz sample rate and the input frequency that contributes to a varying duty cycle via gradual aperture shift.
Yes, plotting the %H variances may give a clue.
Samuell's numbers suggest a ~16ppm offset, of P2 to his reference clock.
Maybe a better P2 clock source, or a trim-cap, can lower than ppm to reduce the beat frequency ?
I was using crystal mode %10 (7.5pF). He could try %11 (15pF), or even %01 (no caps).
There could be a low beat frequency between the 250 MHz sample rate and the input frequency that contributes to a varying duty cycle via gradual aperture shift.
Yes, plotting the %H variances may give a clue.
Samuell's numbers suggest a ~16ppm offset, of P2 to his reference clock.
Maybe a better P2 clock source, or a trim-cap, can lower than ppm to reduce the beat frequency ?
I was using crystal mode %10 (7.5pF). He could try %11 (15pF), or even %01 (no caps).
These are my recorded Trim values, it looks like P2 is already 'too low' at the 'best' %10 and %01 does oscillate, but quite a long way off( +125~144ppm).
Notice the simple warming of the Xtal gives another variance, from the Xtal tempco.
%CC XI/XO caps Cooler, No PLL 180MHz/warming (Eval-A numbers)
%01 OFF +144 ppm +125.68 ppm
%10 15pF per pin -6.700 ppm -24.356 ppm
%11 30pF per pin -53 ppm -68.188 ppm
I would place my bet on the fact that any deviation is mostly on the P2 Eval XO.
Yes, any ppm is certainly mostly the Xtal, and that will also vary as the Xtal warms.
As an example, a NTC-included Xtal spec I have here, gives
First-order curve fitting coefficient -0.35 ~ -0.18 ppm/'C
ie roughly -3ppm every 11 degrees warming.
As for jitter, i seriously doubt that the P2 Eval would be able to capture any. Even the possibility that it can capture wander is very dubious.
It is certainly showing some variances
My numbers above show the wander in the Xtal, so P2 can easily capture that.
Derive of jitter is not as easy, as you cannot directly measure 90ps, but you can see the effects of apertures, and work back from there.
I'd expect most of the jitter to be in the PLL VCO side of P2, rather than the Xtal oscillator.
I will have to measure other 10MHz clock sources as well, and then compare results.
Do you have any faster, low jitter clock sources ? You could clock P2 from one of those, via the XI pin.
Then an A-B comparison with same-MHz done via PLL should be possible,
I will have to measure other 10MHz clock sources as well, and then compare results.
Do you have any faster, low jitter clock sources ? You could clock P2 from one of those, via the XI pin.
Then an A-B comparison with same-MHz done via PLL should be possible,
I have a faster, yet ultra jittery, clock source. The source you saw me using is the best I have. However, I see the need of using an ultra-low jitter clock generator.
Please, refer to my next post (yet to be created) to see my results when using a jittery clock source.
I've decided to use a different clock source, in order to compare results. So, I've used on of my function generators to generate a 10MHz CMOS 3.3V clock. Mind that this is a jittery clock source, and I'll explain its nature.
The function generator prototype you see in the photo has an analog output and a digital/clock output. The digital output signal is derived from the analog signal generated by the DDS, which is the AD9834. This signal gets filtered and pre-amplified before going into a very fast comparator. This is, of course, better than deriving a clock signal from the MSB of the NCO, but still, far from ideal, even though the signal is filtered with a 7-th order near Chebyshev filter. You can refer to the schematic attached.
The results are attached as well. They are, as intended, much worse than the previous ones. Still, I don't see much variance in the duty cycle, although, not surprisingly, is much farther from the ideal 50%. I've notice that it tends to 50% when decreasing the frequency, as expected.
The variance of the duty cycle values may be due to some granularity from the P2 itself. Believe me, the GR10M-S clock generator is much more precise and shows much less jitter when compared to the GF2 function generator. I can easily see the jitter from the latter on an oscilloscope, when said generator is generating 10MHz.
By the way, Chip's program uses the crystal and PLL, and so I'm using those too. No external clock is being fed to the P2. No modifications were made to the code. These tests were done just as a validation.
Jitter is high frequency, and erratic, it won't register in any significance with this method of measuring. The final sampling is what, one per second. And that goes for the duty too. It's one humongous average.
The variance of the duty cycle values may be due to some granularity from the P2 itself. Believe me, that the GR10M-S clock generator is much more precise and shows much less jitter when compared to the GF2 function generator. I can easily see the jitter from the latter on an oscilloscope, when it is generating 10MHz.
Curious. Are they both CMOS signals, with equally fast-rise drives into P2 ?
The frequency is very stable in both, because it is averaged over 10ms.
The gated-hi counts vary by more, because that is a tougher test, where P2 is gating an average of 12.99428 or 12.541709 SysCLK counts per gate.
The 13 or 16ppm shews in timebases, I calc will phase-walk a full SysCLK ~ 54 or 64 times respectively, during a measurement window.
If you have multi-stable 10.000MHz sources that are quite close, but not locked, it could be useful to feed one 10MHz ref into XI, (change code to /1 x25, to keep 250Mhz SysCLK) and the other into
test pin.
With that, a number of measurement frames should be stable, with rarer deviation ones interspersed.
Jitter is high frequency, and erratic, it won't register in any significance with this method of measuring. The final sampling is what, one per second. And that goes for the duty too. It's one humongous average.
The variance of the duty cycle values may be due to some granularity from the P2 itself. Believe me, that the GR10M-S clock generator is much more precise and shows much less jitter when compared to the GF2 function generator. I can easily see the jitter from the latter on an oscilloscope, when it is generating 10MHz.
Curious. Are they both CMOS signals, with equally fast-rise drives into P2 ?
The frequency is very stable in both, because it is averaged over 10ms.
The gated-hi counts vary by more, because that is a tougher test, where P2 is gating an average of 12.99428 or 12.541709 SysCLK counts per gate.
The 13 or 16ppm shews in timebases, I calc will phase-walk a full SysCLK ~ 54 or 64 times respectively, during a measurement window.
If you have multi-stable 10.000MHz sources that are quite close, but not locked, it could be useful to feed one 10MHz ref into XI, (change code to /1 x25, to keep 250Mhz SysCLK) and the other into
test pin.
With that, a number of measurement frames should be stable, with rarer deviation ones interspersed.
See the scope shots attached. The red trace represents the signal from the GR10M-S reference clock generator. The yellow trace represents the signal synthesized by the GF2 function generator. I had to use a 50Ω terminator near the scope, unlike in the previous tests using the P2 frequency counter, due to the long coax cables. The signals are therefore attenuated.
You can see that the yellow trace shows substantially more jitter. Of course the red trace shows some jitter too, but it should never be that visible. Some of the jitter (or any of the jitter seen in the red trace) is caused by the oscilloscope sampling itself. This is not the correct way to measure cycle-to-cycle jitter, by the way, but it is very telling in this case.
Thus, you can't really observe any jitter with the P2 frequency counter. Hardly, you can see jitter with a sub GHz oscilloscope, as it has to be huge to overcome the scope's own sampling jitter. The cycle-to-cycle jitter generated by the function generator is, most definitely, huge (in the range of 200ps).
Hmm, that's not showing jitter either - because you're locked to a single edge (the one on screen) for each pass. You need to include more edges per pass to show any momentary stretching of the clock.
Hmm, that's not showing jitter either - because you're locked to a single edge (the one on screen) for each pass. You need to include more edges per pass to show any momentary stretching of the clock.
Notice that I'm focused on the next ascending edge from where the trigger is. The trigger is actually set with a 100ns deviation (to the left, and not visible on the screen). The yellow trace is noticeably more jittery (persistence is on). Please, see the image attached.
They rises are all centre aligned, there's nothing to see.
Evidently, they are all center "aligned". Have you noticed that the time scale resolution is a huge 2ns per division? If they were grotesquely misaligned at that scale, then none of the signals couldn't even be considered clocks. Don't expect an huge skew after just one period (100ns).
However, did you noticed that the yellow trace is thicker where it crosses the trigger point? Yup, that's cycle-to-cycle jitter right there, and it is not the scope that is artifacting it.
I'm afraid this is getting off-topic. The scope shots were just to prove to jmg that the GF2 function generator is much more jittery than the GR10M-S reference clock initially used to test Chip's program. This going off-topic is, of course, my fault. I got too carried away.
Anyway, the jitter stats for the GR10M-S are already proven beyond doubt, as they were measured by an independent lab with top-notch equipment. Is not me with a cheap scope that is going to prove or disprove anything. By comparison, GF2 produces a much lower quality clock, that should not even be considered when a relatively low jitter is required.
The main point here, and you also agree with: Chip's program doesn't measure jitter, in any way, shape or form. I don't see a point on measuring jitter after 1000 cycles or so, because then the sampling jitter of the scope starts to dominate, if is not already doing so. The scope I'm using is just not able to do that kind of measurement. It is even useless when measuring jitter after a single cycle, unless the clock being measured is a disaster (the clock signal from the GF2 classifies as that). But I digress.
To be honest, I'm not 100% certain of my assertion any longer. I realise now that JMG was referencing multiple samples just by looking at the history in the screen shots. And using the min and max densities he eye-balled.
It's dawning on me that that might be a valid indicator after all. Albeit very low sample count.
But how does that translates to jitter? And how one can infer that a source is more jittery than the other, especially when direct measurements prove otherwise (at least concerning cycle-to-cycle jitter)?
Plus, can I extract a 10MHz clock generated by the P2, given that it is derived from the PLL, in the same conditions that it is being used by Chip's program?
I'm setting up a test here comparing that idea using my own previous, from the third link above, severe and repeatable example using the revA revB-globtop Eval Board as the generator. And using the revB-finished Eval Board and my scope to compare results ...
EDIT: Corrected board names. The testing in the link above is for revB, not revA.
Okay, nope, not even close. Attached is a bunch of consecutive densities (states) as reported by Chip's frequency counter program. Doing what JMG did gives about 180 ppm.
And I think I know why. In the attach screenshot I've increased the interval of full range view to see the jitter narrow again. It's about 1/10th the amount of jitter every 3.9 4.0 us. So that means, in this particular case, the crystal oscillator is stable but the PLL instability is causing very short oscillations back and forth across the ideal.
The absolute jitter of about 110 ns then fades wrt the long average (10 ms) of the frequency counter.
Not all jitter types will act that way though. And indeed 110ns / 10ms only equals 11 ppm so the counter is picking up something more.
OH ... the parts-per-million method is rubbish! It completely depends on the measurement interval. If the interval is halved then the effect is doubled.
And I though that GF2 was jittery. Now, that is jitter! The PLL seems to be re-syncing every four clocks of the output signal. This seems to be the consequence of coarse adjustments, leading to oscillations in phase. I'm not surprised if that causes problems related with HDMI.
Could you try the other way around? That is, using RevB as the signal generator, and RevA as the frequency counter. If we see worse results, then we know that PLL instability is very detrimental to the accuracy of the frequency counter.
I've been using my RevB board so far, but I could do the same test using the RevA and, again, the GR10M-S as the signal source.
...
Not all jitter types will act that way though. ...
Second that. The oscilloscope most probably captures low frequency jitter. You would need a very fast specialized oscilloscope to capture cycle-to-cycle jitter decently. The only thing we can get is "indications", but not actual measurements.
And I though that GF2 was jittery. Now, that is jitter! The PLL seems to be re-syncing every four clocks of the output signal. This seems to be the consequence of coarse adjustments, leading to oscillations in phase. I'm not surprised if that causes problems related with HDMI.
Could you try the other way around? That is, using RevB as the signal generator, and RevA as the frequency counter. If we see worse results, then we know that PLL instability is very detrimental to the accuracy of the frequency counter.
I've been using my RevB board so far, but I could do the same test using the RevA and, again, the GR10M-S as the signal source.
I named that wrongly, it is the revB. The revA looks a lot better in that config. I've corrected the naming in the earlier post now.
Don't worry, I am abusing the PLL to get that result, pushing it outside its spec and found a particularly bad spot.
PS: The setting is 20.5 MHz sys-clock with XDIVP = 1. Normally, XDIVP should be something like 4 when this low. This way the VCO in the PLL will be operating 4x faster.
... You would need a very fast specialized oscilloscope to capture cycle-to-cycle jitter decently. ...
Note the 20 GS/s at the top. It's a speciality of that scope. I've never used the feature till working the prop2 though.
EDIT: If you scroll up a little before the linked post, I described how it does that.
Comments
I would say so. The 10MHz reference clock generator shows 461fs(rms) of phase jitter (12-5000KHz) on the output I was using. See the "datashort" to see more details and some scope data.
Kind regards, Samuel Lourenço
It may be that ~90ps is already averaged down ?
Picking one variance, 1254196-1253059 = 1137 counts difference in 10ms, over 100002 gate pulses.
I would place my bet on the fact that any deviation is mostly on the P2 Eval XO. However, expect some deviation on the GR10M-S side. Mind that the ±25ppb of stability does not translate to accuracy, as you may know. The free run accuracy of the OCXO used in the GR10M-S reference clock allows for a ±4.6ppm deviation, in the worst case scenario. As for jitter, i seriously doubt that the P2 Eval would be able to capture any. Even the possibility that it can capture wander is very dubious.
Kind regards, Samuel Lourenço
Samuell's numbers suggest a ~16ppm offset, of P2 to his reference clock.
Maybe a better P2 clock source, or a trim-cap, can lower than ppm to reduce the beat frequency ?
I was using crystal mode %10 (7.5pF). He could try %11 (15pF), or even %01 (no caps).
These are my recorded Trim values, it looks like P2 is already 'too low' at the 'best' %10 and %01 does oscillate, but quite a long way off( +125~144ppm).
Notice the simple warming of the Xtal gives another variance, from the Xtal tempco.
As an example, a NTC-included Xtal spec I have here, gives
First-order curve fitting coefficient -0.35 ~ -0.18 ppm/'C
ie roughly -3ppm every 11 degrees warming.
It is certainly showing some variances
My numbers above show the wander in the Xtal, so P2 can easily capture that.
Derive of jitter is not as easy, as you cannot directly measure 90ps, but you can see the effects of apertures, and work back from there.
I'd expect most of the jitter to be in the PLL VCO side of P2, rather than the Xtal oscillator.
Kind regards, Samuel Lourenço
Then an A-B comparison with same-MHz done via PLL should be possible,
Please, refer to my next post (yet to be created) to see my results when using a jittery clock source.
Kind regards, Samuel Lourenço
I've decided to use a different clock source, in order to compare results. So, I've used on of my function generators to generate a 10MHz CMOS 3.3V clock. Mind that this is a jittery clock source, and I'll explain its nature.
The function generator prototype you see in the photo has an analog output and a digital/clock output. The digital output signal is derived from the analog signal generated by the DDS, which is the AD9834. This signal gets filtered and pre-amplified before going into a very fast comparator. This is, of course, better than deriving a clock signal from the MSB of the NCO, but still, far from ideal, even though the signal is filtered with a 7-th order near Chebyshev filter. You can refer to the schematic attached.
The results are attached as well. They are, as intended, much worse than the previous ones. Still, I don't see much variance in the duty cycle, although, not surprisingly, is much farther from the ideal 50%. I've notice that it tends to 50% when decreasing the frequency, as expected.
Kind regards, Samuel Lourenço
That seems to actually be better (less variance in Duty numbers), doing a quick scan for peak variances
This test :
1-1299192/1299454 = ~202ppm
Previous test
1-1254643/1252723 = ~1532ppm
( I think you still use the PLL inside P2 here, as no connections go to XI ? )
By the way, Chip's program uses the crystal and PLL, and so I'm using those too. No external clock is being fed to the P2. No modifications were made to the code. These tests were done just as a validation.
Kind regards, Samuel Lourenço
The frequency is very stable in both, because it is averaged over 10ms.
The gated-hi counts vary by more, because that is a tougher test, where P2 is gating an average of 12.99428 or 12.541709 SysCLK counts per gate.
The 13 or 16ppm shews in timebases, I calc will phase-walk a full SysCLK ~ 54 or 64 times respectively, during a measurement window.
If you have multi-stable 10.000MHz sources that are quite close, but not locked, it could be useful to feed one 10MHz ref into XI, (change code to /1 x25, to keep 250Mhz SysCLK) and the other into
test pin.
With that, a number of measurement frames should be stable, with rarer deviation ones interspersed.
See the scope shots attached. The red trace represents the signal from the GR10M-S reference clock generator. The yellow trace represents the signal synthesized by the GF2 function generator. I had to use a 50Ω terminator near the scope, unlike in the previous tests using the P2 frequency counter, due to the long coax cables. The signals are therefore attenuated.
You can see that the yellow trace shows substantially more jitter. Of course the red trace shows some jitter too, but it should never be that visible. Some of the jitter (or any of the jitter seen in the red trace) is caused by the oscilloscope sampling itself. This is not the correct way to measure cycle-to-cycle jitter, by the way, but it is very telling in this case.
Thus, you can't really observe any jitter with the P2 frequency counter. Hardly, you can see jitter with a sub GHz oscilloscope, as it has to be huge to overcome the scope's own sampling jitter. The cycle-to-cycle jitter generated by the function generator is, most definitely, huge (in the range of 200ps).
Kind regards, Samuel Lourenço
Another approach is use a reference that everything is meant to be phase locked to. eg: https://forums.parallax.com/discussion/comment/1464141/#Comment_1464141
Chip is using a very effective method I don't know here - http://18.223.231.191/discussion/comment/1475510/#Comment_1475510
Found the one I did - https://forums.parallax.com/discussion/comment/1478442/#Comment_1478442 The numbers for that example is 90 ns / 3000 ns = 0.03 or 30,000 ppm.
Kind regards, Samuel Lourenço
However, did you noticed that the yellow trace is thicker where it crosses the trigger point? Yup, that's cycle-to-cycle jitter right there, and it is not the scope that is artifacting it.
Kind regards, Samuel Lourenço
Looking now at Chip's example, it looks like that's exactly how he did it - The time at the top says 100 us, while the time scale is 50 ns/div.
I'm afraid this is getting off-topic. The scope shots were just to prove to jmg that the GF2 function generator is much more jittery than the GR10M-S reference clock initially used to test Chip's program. This going off-topic is, of course, my fault. I got too carried away.
Anyway, the jitter stats for the GR10M-S are already proven beyond doubt, as they were measured by an independent lab with top-notch equipment. Is not me with a cheap scope that is going to prove or disprove anything. By comparison, GF2 produces a much lower quality clock, that should not even be considered when a relatively low jitter is required.
The main point here, and you also agree with: Chip's program doesn't measure jitter, in any way, shape or form. I don't see a point on measuring jitter after 1000 cycles or so, because then the sampling jitter of the scope starts to dominate, if is not already doing so. The scope I'm using is just not able to do that kind of measurement. It is even useless when measuring jitter after a single cycle, unless the clock being measured is a disaster (the clock signal from the GF2 classifies as that). But I digress.
Kind regards, Samuel Lourenço
It's dawning on me that that might be a valid indicator after all. Albeit very low sample count.
Plus, can I extract a 10MHz clock generated by the P2, given that it is derived from the PLL, in the same conditions that it is being used by Chip's program?
Kind regards, Samuel Lourenço
EDIT: Corrected board names. The testing in the link above is for revB, not revA.
And I think I know why. In the attach screenshot I've increased the interval of full range view to see the jitter narrow again. It's about 1/10th the amount of jitter every 3.9 4.0 us. So that means, in this particular case, the crystal oscillator is stable but the PLL instability is causing very short oscillations back and forth across the ideal.
The absolute jitter of about 110 ns then fades wrt the long average (10 ms) of the frequency counter.
Not all jitter types will act that way though. And indeed 110ns / 10ms only equals 11 ppm so the counter is picking up something more.
Could you try the other way around? That is, using RevB as the signal generator, and RevA as the frequency counter. If we see worse results, then we know that PLL instability is very detrimental to the accuracy of the frequency counter.
I've been using my RevB board so far, but I could do the same test using the RevA and, again, the GR10M-S as the signal source.
Second that. The oscilloscope most probably captures low frequency jitter. You would need a very fast specialized oscilloscope to capture cycle-to-cycle jitter decently. The only thing we can get is "indications", but not actual measurements.
Kind regards, Samuel Lourenço
Don't worry, I am abusing the PLL to get that result, pushing it outside its spec and found a particularly bad spot.
PS: The setting is 20.5 MHz sys-clock with XDIVP = 1. Normally, XDIVP should be something like 4 when this low. This way the VCO in the PLL will be operating 4x faster.
Note the 20 GS/s at the top. It's a speciality of that scope. I've never used the feature till working the prop2 though.
EDIT: If you scroll up a little before the linked post, I described how it does that.