Re: DDS question: why sine lookup?

On Sat, 10 May 2025 16:50:03 -0700, dplatt@coop.radagast.org (Dave
Platt) wrote:

In article <ad7v1kttjfhjulnameem9ta8gjst5cpa45@4ax.com>,
john larkin  <jl@glen--canyon.com> wrote:
>

Looks like the best way is logic in the FPGA doing classic sine DDS,
maybe 6 or 8 output pins driving an R-2R network, a 3 or 5-pole
Chebyshev LC filter, and an LVDS receiver as the comparator.

>
Be wary of that approach.
>
I tried something like it (sans comparator), while using a simple FPGA
to generate a (modulated) 10.7 MHz IF signal for an FM-stereo test
generator.  The results were ungood.

A good filter and a comparator could help, as in "FM Capture Effect."

>
The output waveform had some pretty horrible glitches, at the times of
the transitions between values.  There's enough variation in delay in
the signal paths inside the FPGA to create a significant (in
picoseconds and nanoseconds) delay between the transition times of the
R2R bits.  If you're trying to go from (for example) 0x7F to 0x81,
your MSB is going to be transitioning high when most of your LSBs are
transitioning low.  There's very likely to be a brief moment of time
when the effective value is 0xFF (if the MSB transitions first) or
0x00 (if it transitions last), or some random and unpredictable and
ever-changing mix of bits.  The resulting spikes are narrow, but can
have a pretty fierce amplitude to them.
>
As a result, unless your LC filter is extremely sharp, your
receiver/comparator is likely to generate occasional runt pulses,
or skew the zero-crossing time by one or more sample (adding jitter).
>
To make this scheme work, you really need to re-time the values going
into the R2R ladder to ensure near-as-gosh identical timing... some
form of very predictable latch with guaranteed low skew between the
pins.  The normal FPGA data path probably won't do this for you.  I
tried using the FPGA's own internal registered-output logic (driving
all of the latch clocks from the same internal signal) but even this
wasn't good enough... the internal propagation times were not zero,
alas :-( due to that cursed light-speed limit.

We'd at least retime the 8 outputs in output latches, in the same
region.

>
I switched over to using an Analog Devices DDS, shifting a new value
out into it from the FPGA via a serial interface once per sample time.
Far, far cleaner RF/IF as a result.
>
You could get a fairly clean 3-bit-equivalent output, using 8 pins and
8 equal-value resistors, and encoding things so that transitions are
always "change one or more bits from 0 to 1" or "change 1 or more bits
from 1 to 0".

I could buy an official clocked 8-bit DAC with a data latch. Some have
great glitch specs (and some are horrible.)

Parallel-load DDS chips are expensive, and serial interfaces are too
slow. And I'd like to allow for phase coherence between clocks on the
multichannel gadget.

Maybe some not-literally-sine waveform could have less glitches.

This is all interesting but potentially time consuming. I might add
some delays, like to the MSB, to my Spice model and see what happens.

If I have a project with an FPGA and a little spare room, I could try
the R-2R thing as an experiment.