Hi,
assuming a circuit consisting of:
- a direct digital synthesizer (DDS) running inside an FPGA and producing a digital sinewave
- a DAC which converts the digital sinewave into an analog one
- a low-pass filter which filters the DAC output signal
- a comparator which generates a squarewave signal from the filtered analog sinewave
how do you estimate the jitter at the output of the comparator? or even the jitter of the filtered sinewave? Every publication about DDS mentions SFDR (spurious free dynamic range), i.e. how to estimate it and how to reduce it (e.g. using phase dithering), but I couldn't find any information about the relationship between SFDR and jitter.
Any clues?
Thanks,
Guy.
Hi Guy,
Although people like to use the generic term "jitter", understand that there are many different types of jitter. For example, the type of jitter in [1] is typically referred to as "time interval error" jitter in the industry, which is the variation of the location of an edge compared to some reference (e.g. ideal) edge location. The type of jitter in [2] is "period jitter", which is the variation of a period from its average value. You wouldn't know this by reading either article unless you've some experience. Many other types of jitter also exist (cycle-to-cycle jitter, phase jitter, N-cycle jitter, etc.).
The type of jitter that matters depends on the application. What is the comparator's output signal driving? For example, if the comparator connects to a PLL, then TIE matters, but if it connects to a digital circuit (e.g. synchronous logic) then period jitter matters (for computing setup and hold time equations), etc.
Once you figure out the type of jitter that matters for your application, you can think about measuring it. A real-time oscilloscope can be typically used for many different measures of jitter. Assuming the jitter output by the comparator is larger than the jitter noise floor of the scope, this is a good approach. Alternatively, really low-noise clocks require phase noise analysis (seems unlikely for your project).
For any given type of jitter, one can decompose the measured jitter values into random and deterministic components. If you were to look at a jitter spectrum, you can think of the random component of jitter as the smoothly changing noise floor amplitude versus frequency, and the deterministic component of jitter as being the spurious sine wave noise (e.g. spurs) popping above this floor. Only the spurs impact SFDR. Perhaps SFDR is a red herring though, if jitter is what you really need.
Hope that helps,
Gary
[1] https://www.maximintegrated.com/en/app-notes/index...
folks, fully agreeing to the fact that connecting SFDR to Jitter is difficult analytically. However, some connection can be established based on intuition which may be helpful for an engineer to move forward with his prototyping/testing task. PHD folks excuse...
With points in page 40 of [1] as the base, there are 2 factors which contributes to (phase) jitter of the comparator square wave output, viz.,
a. the accuracy of amplitude. in other word purity of the spectrum.
b. the consistency of the time unit, the uncertainty of the clock.
the lowpass filter prior to the comparator improves the THD by removing harmonics. however, it can't remove anything with respect the (instantaneous) change in the fundamental frequency possibly due to #b.
ie, jitter due to #a can be reduced by deploying appropriate filter(s). however, factor of jitter due to #b can't be removed by filterting or any such linear operations. dithering gives some statistical advantage, hopefully.
from a 1000ft view, only possibility to address #b factor is to take care of timing during FPGA design/implementation. [1] talks about this aspect in very detailed way, which I'm yet to cover :).
I assume jitter of sine wave equals that of its clock which may be reported by the fitter tool.
There are many parameters to this problem:
- FPGA clock jitter
- Frequency that is generated
- output jitter is input jitter * fclk/f0 (fpga clock/generated clock frequency)
- Number of bits of the phase counter
- Number of bits of the address (sin/cos in a BRAM)
- Number of bits of the DAC
Olivier
First, the relationship between any spectral analysis of the demodulated PM of a sine wave and the "jitter" of a waveform is a whole PhD career of its own.
Jitter, we must remember, is a very digital and time-domain subject. The digital clock is a "significant time event" domain signal. Only the transition time of the rising or falling edge of the clock matters at all. This subtlety is often lost in the conversation between an analog designer, a signal system designer and a digital designer.
The jitter roughly will be the RMS addition of:
The jitter mechanism of the DDS machine (I know that DDS pretty much specifies the math used to create the phase information of a waveform generator, but it's not the only one or the best) ... is it a frac-N converter, is it a phase accumulator, is it a double-precision modulo F*pi phase adder, is it a DLL with interpolator ... this is a huge subject for the first calculation. The inherent phase quantization and amplitude quantization are deep, deep subjects. A fractional-N style architecture does eliminate all time quantization but at the cost of not being able to provide arbitrary frequencies, only those that line up with the rational number system provided by M and N.
The second additive jitter source is the clock of the FPGA. It is folly to use the PLL of the FPGA as the final output clock of a low phase-noise synthesizer. One should have a low jitter clock outside the FPGA for the final output sampler using an I/O D-flop from that pin (can be inside the D/A also) to assure that the significant instants of data transfer of the sinusoid's amplitudes are low jitter.
Next is the jitter due to the D/A converter, which is typically not specified in a way that is readily usable to a digital designer's sense of jitter. This is where, once again, the PhD analysis is needed to convert SFDR (but more significantly, the near-in phase noise stochastic spectrum) into time-domain jitter.
Finally, the comparator on the sine wave will add some level of jitter. Comparator data sheets typically provide this in a digital designer's domain.
This is not a simple subject. The first order simple solution will come from the summation of the clock jitters enumerated above, but the Low Pass Filter after the DAC will need some significant signal analysis to convert the near-in AM/PM spectrum into a reasonable jitter number. Likewise the quantization of the synthesizer of choice.
I'm not sure that this is a PhD level subject -- in practical terms, a determined guy with a math-heavy master's degree can pursue the calculation beyond the point where the prediction will be swamped by un-modeled real-world effects.
If you have the math chops, I suggest that you do your best effort to model it with the parts you're planning on using, and if the answer is at least 20% lower than what you really need figure that you have a chance -- although I'd push for 50% lower myself, particularly if my production volumes were low and I didn't have time in the schedule for messing with board turns.
Figure that for all your ciphering, you'll still end up with a board that doesn't work to spec the first time around -- you can expect that you'll be deluged with unexpected results, at which point you'll need to revert to Eric's "tweak to spec" strategy.
I'll add a +1 that this isn't a trivial task if you want some degree of accuracy in the final jitter estimation. There are a number of tricks that you can do in the DDS to minimize this type of jitter, plus the jitter on the clock driving the DDS needs to be known. As previously mentioned, the characteristics of the DAC and the comparator/limiter will also have an influence.
This is a case where modelling can help a lot, or just build it and tweak to spec. ;)
Thanks to everyone who took the time to answer my question.
For the record, I will add this reference which I found quite useful: Analog Devices Application Note AN-823, Time Jitter in Direct Digital Synthesizer-Based Clocking Systems (link).
Regards,
Guy.
