How to spec jitter for a digital NCO
in [DSP]
|
Prev: Kenlighten - A social network for knowledge seekers and providers
Next: LMS to remove the unknown sinusoidal signal
From: Rob Gaddi on 2 Jun 2010 19:39 On 6/2/2010 4:23 PM, gretzteam wrote: >>> >>> Exactly right. You're calling the PTP jitter 1 clock, you're hearing > +/- >>> 1/2 clock, same thing. It sounds like you've got some downstream logic >>> that you want to trigger periodically. And you're planning to use the >>> overflow from the phase accumulator as a single input clock wide pulse >>> to trigger that logic, all of which is on the same input clock. >>> >>> Yep that works, yep it jitters, yep if you can push the clock frequency >>> high enough you can often manage to not care about the jitter. If > that's >>> not feasible you'll need to go to extreme measures, either an external >>> PLL with an analog VCO or a sine wave DDS -> DAC -> filter -> > comparator >>> -> new clock input. Either of these techniques will mean that your new >>> clock is on a clock domain that will have to be treated entirely >>> asynchronously. The data handoff problems that creates are a real pain, >>> but not insurmountable so long as you're willing to pay serious >>> attention at each handoff. >>> >> >> One more note. If you are trying to do what I described above, then >> depending on what frequencies you need to generate there is a >> zero-jitter way of doing it. Instead of using an NCO and triggering off >> of the carry out, you just use a modulo-N counter. Personally I tend to >> use downcounters so that the borrow out = the reload signal = the >> trigger out, but I think that's more an article of religious faith than >> anything that matters to the implementation. >> >> For an N of the same length this changes the frequencies you're able to >> synthesize. With DDS the frequencies are evenly spaced. A divide-by-N >> counter spaces them hyperbolically; the choices for frequency become, >> every clock, every other, every third, etc, which means that you've got >> more resolution at lower frequencies but way less at frequencies near >> the clock rate. Still, this allows you to hit on the head frequencies >> that you can't get to exactly via an NCO, and does so with zero jitter. >> >> -- >> Rob Gaddi, Highland Technology >> Email address is currently out of order > > Hi, > Thanks for all the answers! That leaves me a lot to think about. > I should have said that this is for a purely digital application. I'm not > trying to generate a sine wave, and don't have a LUT, won't go through > analog back and forth etc... > I was just trying to calculate how much jitter I get for a given NCO > depending on M, N and the input clock. > > Say we have a 200MHz clock and want to generate a 32MHz clock. The ratio is > 6.25. We could set an NCO with N=4 and M=25. What I mean by this is a > modulo-25 counter that increments by 4 every cycle. The overflow rate would > be 32MHz. The sequence in terms of input clock cycle goes like: > 7 6 6 6 7 6 6 6 7 6 6 6 > The ideal sequence would have been: > 6.25 6.25 6.25 6.25 > And we can calculate the timing jitter (peak-peak or RMS) from this. > > Now if we divide this 32MHz by two, the sequence becomes > 13 12 13 12 13 12...we could calculate the jitter again. > > Then if we divide by two again, the sequence becomes > 25 25 25 25...jitter is gone! > > So basically, if the original 'period' of the NCO sequence is a power of 2, > there is a divide ratio that would yield a jitter free clock. This was not > obvious to me. > > Still struggling to find an analytical solution for the jitter given M and > N. Not sure this is possible without actually calculating the period. > > Diego > While I don't have too much time to think about the analysis right now, there's a promising line of attack in which you consider the overflow of a counter defined as A = (A + B) mod C. For a divide-by-N type system, B is 1 and C is the division ratio. For an NCO type system, B is variable and C is 2^(bits in phase accumulator). You introduce jitter to the clock if B is not a factor of C. -- Rob Gaddi, Highland Technology Email address is currently out of order
From: Mark on 3 Jun 2010 13:22
On Jun 2, 7:23 pm, "gretzteam" <gretzteam(a)n_o_s_p_a_m.yahoo.com> wrote: > >> Exactly right. You're calling the PTP jitter 1 clock, you're hearing > +/- > >> 1/2 clock, same thing. It sounds like you've got some downstream logic > >> that you want to trigger periodically. And you're planning to use the > >> overflow from the phase accumulator as a single input clock wide pulse > >> to trigger that logic, all of which is on the same input clock. > > >> Yep that works, yep it jitters, yep if you can push the clock frequency > >> high enough you can often manage to not care about the jitter. If > that's > >> not feasible you'll need to go to extreme measures, either an external > >> PLL with an analog VCO or a sine wave DDS -> DAC -> filter -> > comparator > >> -> new clock input. Either of these techniques will mean that your new > >> clock is on a clock domain that will have to be treated entirely > >> asynchronously. The data handoff problems that creates are a real pain, > >> but not insurmountable so long as you're willing to pay serious > >> attention at each handoff. > > >One more note. If you are trying to do what I described above, then > >depending on what frequencies you need to generate there is a > >zero-jitter way of doing it. Instead of using an NCO and triggering off > >of the carry out, you just use a modulo-N counter. Personally I tend to > >use downcounters so that the borrow out = the reload signal = the > >trigger out, but I think that's more an article of religious faith than > >anything that matters to the implementation. > > >For an N of the same length this changes the frequencies you're able to > >synthesize. With DDS the frequencies are evenly spaced. A divide-by-N > >counter spaces them hyperbolically; the choices for frequency become, > >every clock, every other, every third, etc, which means that you've got > >more resolution at lower frequencies but way less at frequencies near > >the clock rate. Still, this allows you to hit on the head frequencies > >that you can't get to exactly via an NCO, and does so with zero jitter. > > >-- > >Rob Gaddi, Highland Technology > >Email address is currently out of order > > Hi, > Thanks for all the answers! That leaves me a lot to think about. > I should have said that this is for a purely digital application. I'm not > trying to generate a sine wave, and don't have a LUT, won't go through > analog back and forth etc... > I was just trying to calculate how much jitter I get for a given NCO > depending on M, N and the input clock. > > Say we have a 200MHz clock and want to generate a 32MHz clock. The ratio is > 6.25. We could set an NCO with N=4 and M=25. What I mean by this is a > modulo-25 counter that increments by 4 every cycle. The overflow rate would > be 32MHz. The sequence in terms of input clock cycle goes like: > 7 6 6 6 7 6 6 6 7 6 6 6 > The ideal sequence would have been: > 6.25 6.25 6.25 6.25 > And we can calculate the timing jitter (peak-peak or RMS) from this. > > Now if we divide this 32MHz by two, the sequence becomes > 13 12 13 12 13 12...we could calculate the jitter again. > > Then if we divide by two again, the sequence becomes > 25 25 25 25...jitter is gone! > > So basically, if the original 'period' of the NCO sequence is a power of 2, > there is a divide ratio that would yield a jitter free clock. This was not > obvious to me. > > Still struggling to find an analytical solution for the jitter given M and > N. Not sure this is possible without actually calculating the period. > > Diego- Hide quoted text - > > - Show quoted text - if your input clock is 200 MHz then the input edges are spaced at 5ns and since it is a pure digital system the output edges must coencide with the input edges, and unless there is an integer relationship between the input and output freqs, then the output edges are in general going to be off in time from the ideal location and the max they will be off by is 5ns, so if i am not mistaken the output jitter is determined by the input clock and is therefore 5ns p-p. No? Mark |