Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: john larkin <jl@glen--canyon.com>
Newsgroups: sci.electronics.design,comp.dsp
Subject: Re: DDS question: why sine lookup?
Date: Thu, 08 May 2025 16:24:51 -0700
Organization: A noiseless patient Spider
Lines: 150
Message-ID: <20eq1kdl90eus9gnh2dkans0brkaku3ge7@4ax.com>
References: <o3ak1k9ifikv6c1tmfnd89k6vfj4vigj37@4ax.com> <vvgcgp$16qbl$1@dont-email.me> <3uen1khfvdihaho4vv2hf9amb09vbg77tq@4ax.com> <681bfa8e$0$13$882e4bbb@reader.netnews.com> <1t4o1k1uo8qa244fcv7jr7dnljlvp72vmq@4ax.com> <4dadb4e2-f7aa-be3a-0a03-e282577614bb@electrooptical.net> <kfvp1klnjpkmn97m68b7aav40ke1oa2ico@4ax.com> <871d8836-8da0-acd8-d1d4-ded435241643@electrooptical.net> <666q1kp9mltjvdtr0h6gpr9q6lkmovebdv@4ax.com> <vvjb6o$2725h$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 May 2025 01:17:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="112eba3d6b1d29090363c311ebb0cdfb";
	logging-data="2363789"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/9wpAU7lvxxVMD9ZHtmywr"
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:1ooR9bud+fi/DHyXBEMR3m2gI0g=
Bytes: 7917

On Thu, 8 May 2025 22:28:40 -0000 (UTC), Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>john larkin <jl@glen--canyon.com> wrote:
>> On Thu, 8 May 2025 16:24:29 -0400, Phil Hobbs
>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>> 
>>> On 2025-05-08 14:58, john larkin wrote:
>>>> On Thu, 8 May 2025 14:20:21 -0400, Phil Hobbs
>>>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>>> 
>>>>> On 2025-05-07 22:21, john larkin wrote:
>>>>>> On Wed, 7 May 2025 20:27:58 -0400, bitrex <user@example.net> wrote:
>>>>>> 
>>>>>>> On 5/7/2025 4:01 PM, john larkin wrote:
>>>>>>>> On Wed, 7 May 2025 20:32:41 +0100, Martin Brown
>>>>>>>> <'''newspam'''@nonad.co.uk> wrote:
>>>>>>>> 
>>>>>>>>> On 06/05/2025 16:48, john larkin wrote:
>>>>>>>>>> A DDS clock generator uses an NCO (a phase accumulator) and takes some
>>>>>>>>>> number of MSBs, maps through a sine lookup table, drives a DAC and a
>>>>>>>>>> lowpass filter and finally a comparator. The DAC output gets pretty
>>>>>>>>>> ratty near Nyquist, and the filter smooths out and interpolates the
>>>>>>>>>> steps and reduces jitter.
>>>>>>>>>> 
>>>>>>>>>> But why do the sine lookup? Why not use the phase accumulator MSBs
>>>>>>>>>> directly and get a sawtooth, and filter that?
>>>>>>>>> 
>>>>>>>>> A saw tooth wave has a huge step like discontinuity in it which looks
>>>>>>>>> very ugly in the frequency domain with strong harmonics. Strong sharp
>>>>>>>>> features in time domain are broad in frequency space and vice versa.
>>>>>>>>> 
>>>>>>>>> If you wanted something a bit different then detecting the phase
>>>>>>>>> accumulator overflow and reversing the count sense to get a triangle
>>>>>>>>> wave might be an option (at half the frequency). Needs some very careful
>>>>>>>>> maths at the boundary flips to avoid introducing jitter.
>>>>>>>>> 
>>>>>>>>> From that triangle wave you can use HP's wizard diode shaping network
>>>>>>>>> trick to get a pretty good clean sine wave.
>>>>>>>> 
>>>>>>>> Yes, a triangle would be better than a sawtooth... fewer nasty
>>>>>>>> subharmonics. But we may as well stick with the classic boring sine
>>>>>>>> wave. The sine lookup is trivial in an FPGA.
>>>>>>>> 
>>>>>>> 
>>>>>>> A band-limited square wave is pretty space & computation-efficient, you
>>>>>>> just store the Gibbs phenomena portion of the wave to whatever harmonic
>>>>>>> level you desire, play it back, and then sit there and wait during the
>>>>>>> DC parts of the wave.
>>>>>>> 
>>>>>>> If you then integrate a band-limited square wave you get a band-limited
>>>>>>> triangle wave directly.
>>>>>> 
>>>>>> If I could make a square wave from the MSBs of the phase accumulator,
>>>>>> I might not need the DAC and filter and comparator.
>>>>>> 
>>>>>> Just using the MSB of the phase accumulator is the right frequency,
>>>>>> but it's very jitterey.
>>>>>> 
>>>>>> So, is there a way to examine some number of MSBs and make an edge
>>>>>> with high time resolution, all digitally, all inside the FPGA? To even
>>>>>> 1 clock resolution, preferably better?
>>>>>> 
>>>>>> There probably is.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Don't think so.  Since you have exactly two edges per cycle, it would
>>>>> have the same problem as the sawtooth, for the same reason.  You could
>>>>> interpolate the same sort of way as in a DDG.
>>>>> 
>>>>> Cheers
>>>>> 
>>>>> Phil Hobbs
>>>> 
>>>> If some N bits can be sent to a DAC and a filter, to interpolate to
>>>> better time accuracy than just using the MS bit, then the equivalent
>>>> interpolation should be possible digitally, inside the FPGA.
>>>> 
>>>> We can always spin up a PLL to get as fast a clock as the logic can
>>>> stand. And sub-clock tricks have been done.
>>>> 
>>> You still have the giant spike between the actual position of the edge 
>>> and where it ought to be for a subharmonic-free  signal.  That's less 
>>> than one clock wide, so there's no way to get rid of it digitally.  You 
>>> could maybe do some noise shaping thing to put the subharmonics 
>>> someplace else, but unless your increment is a factor of 2**(accumulator 
>>> width), they'll be there.
>>> 
>>> A full-width DAC, followed by a brickwall lowpass, followed by a 
>>> comparator, will get rid of the subharmonics, as would a ramp/threshold 
>>> analog delay  calculated on a per-cycle basis.
>>> 
>>> Cheers
>>> 
>>> Phil Hobbs
>> 
>> We could take the phase accumulator "dac" MSBs and stuff them into a
>> brickwall digital lowpass filter, maybe even do the sine mapping
>> first. The result would be a wide smooth waveform, similar to what the
>> analog comparator would see, only digital. The zero cross of that
>> would be our "DDS comparator output" clock, to one system clock
>> quantization. Going to half clock resolution wouldn't be hard.
>> 
>> If the phase accumulator clock is 160 MHz, half a clock gives us 3 ns
>> p-p jitter, and the RMS jitter is 900 ps. (Why square root of 12? We
>> live in a strange universe.)
>> 
>> That filter logic could be clocked faster than the phase accumulator
>> clock too. Some crazy PLL rate.
>> 
>> I don't want to drive a bunch of 20-bit parallel DACs, or make some
>> 13-pole LC filters, but bits are cheap inside an FPGA.
>> 
>> We know what the output frequency will be, so the digital filter can
>> be tuned for that. Maybe a narrow bandpass? Kills subharmonics?
>> 
>> Some truly terrible things have been done in FPGAs to get picosecond
>> resolution delays and time interval measuring.
>> 
>> Sounds like a good senior project.
>> 
>> 
>
>If the output frequency is known in advance, all ought to be
>straightforward—pick a clock frequency that’s an integer multiple.   
>
>One VCXO-based PLL should be able to make that. 
>
>Cheers 
>
>Phil Hobbs 

The gadget's output frequency is known when the user programs it, not
years in advance. When we know the frequency we have to do the math to
program the Fset register over our octave range, and program a
downstream divisor (for, say, a 12 Hz trigger rate) so we have time to
program a digital filter too.

An 8-bit R-2R network and a modest LC filter and an LVDS buffer as a
comparator isn't awful, but getting the entire DDS system inside the
FPGA would be cool.

I did consider having a fixed frequency clock and a divisor as our
internal trigger source, and telling the user he has to live with
Fxo/N as the possible choices, but even I have my limits of tackiness.