Re: pulling some crystals
the ultimate clock is used as a sample rate clock for ADC, DAC, FPGA . this
drives everything. I can tweak say frequency offset of the system channels
that I generate with internal FPGA DDS, but producing a Part PerBillion
accurate sample rate conversion running at 393 MHz sample rate would be a
whole world of pain,
Running a fast DDS in a FPGA is pretty easy once you see it. "Carry save
adder" is the buzzword.
The problem is how to make a wide adder go fast. The trick for a DDS is that
all you need is the carry out of the adder. So put FFs along in the carry
chain as needed to meet timing. That will delay the carry out by a cycle per
FF but that doesn't matter for a DDS.
Consider a 16 bit adder with one FF half way along the carry chain. When that FF is a 1, the high bits in the adder and the carry out will be a cycle behind the low bits. The next cycle they catch up. The carry out, the DDS signal, has the same pattern. It's just shifted in time. If you fed it to a spectrum analyzer you couldn't tell the difference.
A part per billion is only 30 bits.
--
These are my opinions. I hate spam.
frequency tweaks of generated signals is easy as you point out . (I have
DDS carrier generators in the fabric for generating baseband signal
sources )
But - one cannot use DDS generated clocks for high fidelity ADC/DAC from
the FPGA outputs because the jitter on those generated clocks due to
various internal processes is too high. Needs a crystal clock (which si
how I do it) .
*******but my problem this is about system sample rate. (requirement
for pulling the system clocks to ppb)
What about sample rate conversion in hardware ??? Well ! Spur free / low
distortion sample rate conversion to ppb at 400 MHz needs a fair bit of
power and heat to do it with precision/ low spurious (and all my
spurious must be > 120dB down ) .
Best option for that is probably a Farrow interpolation filter, which
essentially involves, each sample , (re) calculating the interpolated
point . But it isnt cheap to do well over a large f/fs ratio, and if
done over small spectrum slabs at high sample rate, generates unwanted
artifacts elsewhere (they look like shark's teeth) .
So, its easier just to get the sample rate clock lined up....
-glen
On 16/12/2023 9:36 am, Hal Murray wrote:
the ultimate clock is used as a sample rate clock for ADC, DAC, FPGA . this
drives everything. I can tweak say frequency offset of the system channels
that I generate with internal FPGA DDS, but producing a Part PerBillion
accurate sample rate conversion running at 393 MHz sample rate would be a
whole world of pain,
Running a fast DDS in a FPGA is pretty easy once you see it. "Carry save
adder" is the buzzword.
The problem is how to make a wide adder go fast. The trick for a DDS is that
all you need is the carry out of the adder. So put FFs along in the carry
chain as needed to meet timing. That will delay the carry out by a cycle per
FF but that doesn't matter for a DDS.
Consider a 16 bit adder with one FF half way along the carry chain. When that FF is a 1, the high bits in the adder and the carry out will be a cycle behind the low bits. The next cycle they catch up. The carry out, the DDS signal, has the same pattern. It's just shifted in time. If you fed it to a spectrum analyzer you couldn't tell the difference.
A part per billion is only 30 bits.
Hi
A DDS is typically limited by two things:
-
The “linear binary” to sine (or cosine) conversion process.
-
The accuracy (and bit depth) of the ADC you use.
This is on top of the more normal Nyquist stuff that you would expect of any digital gizmo. Tossing a square wave in on top of the Nyquist issues normally turns things into a major mess spur wise.
Bob
On Dec 15, 2023, at 5:36 PM, Hal Murray via time-nuts time-nuts@lists.febo.com wrote:
the ultimate clock is used as a sample rate clock for ADC, DAC, FPGA . this
drives everything. I can tweak say frequency offset of the system channels
that I generate with internal FPGA DDS, but producing a Part PerBillion
accurate sample rate conversion running at 393 MHz sample rate would be a
whole world of pain,
Running a fast DDS in a FPGA is pretty easy once you see it. "Carry save
adder" is the buzzword.
The problem is how to make a wide adder go fast. The trick for a DDS is that
all you need is the carry out of the adder. So put FFs along in the carry
chain as needed to meet timing. That will delay the carry out by a cycle per
FF but that doesn't matter for a DDS.
Consider a 16 bit adder with one FF half way along the carry chain. When that FF is a 1, the high bits in the adder and the carry out will be a cycle behind the low bits. The next cycle they catch up. The carry out, the DDS signal, has the same pattern. It's just shifted in time. If you fed it to a spectrum analyzer you couldn't tell the difference.
A part per billion is only 30 bits.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
That’s true for a vanilla phase accumulator -> lookup -> DAC flavor of DDS. These days, in FPGA implementations register lengths aren’t so much a problem, there are clever sin/cos calculation/lookup schemes to make them fit, etc.
Once you’re through that, there’s a whole raft of clever techniques to reduce or move spurs around. If you are lucky enough to have slowly varying frequency/phase commands, you can do quite a bit of computation and load quite a few registers when you do an update, so you can have things like variable length sin/cos tables, multiple NCOs, varying coefficients in error filters.
I would think that for a disciplined oscillator application, where the update rate might be “seconds”, there’s a lot of potential schemes that might not be feasible if you were modulating FM with a 1 MHz signal, or doing fancy PSK/FSK multitones. Fortunately, the latter probably doesn’t have “need no spurs within 1 kHz of carrier” kind of requirements.
On Sat, 16 Dec 2023 09:30:07 -0500, Bob kb8tq via time-nuts time-nuts@lists.febo.com wrote:
Hi
A DDS is typically limited by two things:
-
The “linear binary” to sine (or cosine) conversion process.
-
The accuracy (and bit depth) of the ADC you use.
This is on top of the more normal Nyquist stuff that you would expect of any digital gizmo. Tossing a square wave in on top of the Nyquist issues normally turns things into a major mess spur wise.
Bob
On Dec 15, 2023, at 5:36 PM, Hal Murray via time-nuts wrote:
the ultimate clock is used as a sample rate clock for ADC, DAC, FPGA . this
drives everything. I can tweak say frequency offset of the system channels
that I generate with internal FPGA DDS, but producing a Part PerBillion
accurate sample rate conversion running at 393 MHz sample rate would be a
whole world of pain,
Running a fast DDS in a FPGA is pretty easy once you see it. "Carry save
adder" is the buzzword.
The problem is how to make a wide adder go fast. The trick for a DDS is that
all you need is the carry out of the adder. So put FFs along in the carry
chain as needed to meet timing. That will delay the carry out by a cycle per
FF but that doesn't matter for a DDS.
Consider a 16 bit adder with one FF half way along the carry chain. When that FF is a 1, the high bits in the adder and the carry out will be a cycle behind the low bits. The next cycle they catch up. The carry out, the DDS signal, has the same pattern. It's just shifted in time. If you fed it to a spectrum analyzer you couldn't tell the difference.
A part per billion is only 30 bits.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
On fast counter/adder implementations.
40 years ago, when I had to fight off the dinosaurs around the PC we did our FPGA designs on, we would use various schemes based on Linear Feedback Shift Registers to do fast DDS/NCO/Arbitrary Waveform generators. While fast counters are tricky in an FPGA (or discrete logic) because of the carry propagation issues. It’s easy to make a LFSR clock at the basic flipflop rate (since you can use distributed feedback to the stages, rather than a big XOR tree). So you load your waveform memory at memory locations corresponding to successive states of the LFSR.
Then, you can also use the shift/add property of LFSRs (two identical LFSRs with a difference in phase/state can be added, to create the same sequence, but shifted by a different amount in time) to quickly modulate the instantaneous phase of the waveform. For instance, if you have a 20 bit LFSR, you can get any of 20 different phases with a 20:1 mux. If you have 2 20 bit LFSRs, you’ve got 400 different combinations of phases selectable in one clock.
On Fri, 15 Dec 2023 14:36:43 -0800, Hal Murray via time-nuts time-nuts@lists.febo.com wrote:
the ultimate clock is used as a sample rate clock for ADC, DAC, FPGA . this
drives everything. I can tweak say frequency offset of the system channels
that I generate with internal FPGA DDS, but producing a Part PerBillion
accurate sample rate conversion running at 393 MHz sample rate would be a
whole world of pain,
Running a fast DDS in a FPGA is pretty easy once you see it. "Carry save
adder" is the buzzword.
The problem is how to make a wide adder go fast. The trick for a DDS is that
all you need is the carry out of the adder. So put FFs along in the carry
chain as needed to meet timing. That will delay the carry out by a cycle per
FF but that doesn't matter for a DDS.
Consider a 16 bit adder with one FF half way along the carry chain. When that FF is a 1, the high bits in the adder and the carry out will be a cycle behind the low bits. The next cycle they catch up. The carry out, the DDS signal, has the same pattern. It's just shifted in time. If you fed it to a spectrum analyzer you couldn't tell the difference.
A part per billion is only 30 bits.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
On Sat, 16 Dec 2023 10:19:47 +1100, glenlist via time-nuts time-nuts@lists.febo.com wrote:
frequency tweaks of generated signals is easy as you point out . (I have
DDS carrier generators in the fabric for generating baseband signal
sources )
But - one cannot use DDS generated clocks for high fidelity ADC/DAC from
the FPGA outputs because the jitter on those generated clocks due to
various internal processes is too high. Needs a crystal clock (which si
how I do it) .
—-> Yes, the raw DDS output is pretty ratty - typically, you’d use that to lock a nice quiet crystal with good close in, but sufficient pull range (recognizing that this is sort of counter to each other - good close in implies high Q, pull range implies low Q). We fought this for years at JPL with DROs trying to make something that would have 100 MHz (or even 50 MHz) tuning range at 7 and 8.4 GHz, and have good close in phase noise for good ranging performance.
Interesting on the DRO. what is dirty is any clock or signal that comes
out of an FPGA pin (it is subject to internal path jitter) . That's why
we always retime the data and frame clocks into a DAC with a clean
separate clock.
BTW I bought a PN2060 Rev 1.1 , it will arrive in another week. WHile I
built myself a cross-correlative phase noise analyser using my junkbox,
this product at USD650 inc shipping is just too easy...
On 18/12/2023 7:00 am, Jim Lux via time-nuts wrote:
On Sat, 16 Dec 2023 10:19:47 +1100, glenlist via time-nutstime-nuts@lists.febo.com wrote:
frequency tweaks of generated signals is easy as you point out . (I have
DDS carrier generators in the fabric for generating baseband signal
sources )
But - one cannot use DDS generated clocks for high fidelity ADC/DAC from
the FPGA outputs because the jitter on those generated clocks due to
various internal processes is too high. Needs a crystal clock (which si
how I do it) .
—-> Yes, the raw DDS output is pretty ratty - typically, you’d use that to lock a nice quiet crystal with good close in, but sufficient pull range (recognizing that this is sort of counter to each other - good close in implies high Q, pull range implies low Q). We fought this for years at JPL with DROs trying to make something that would have 100 MHz (or even 50 MHz) tuning range at 7 and 8.4 GHz, and have good close in phase noise for good ranging performance.
time-nuts mailing list --time-nuts@lists.febo.com
To unsubscribe send an email totime-nuts-leave@lists.febo.com