I don't understand what a neat frequency is, either. Any periodic waveform at 1 MHz (the worst case) at 100 Msps update rate takes a 100 entry table.
I don't understand what a neat frequency is, either. Any periodic waveform at 1 MHz (the worst case) at 100 Msps update rate takes a 100 entry table.
But suppose you adjust to 0.99 MHz; do you now use a 101 entry table? And how about 0.995 MHz? The small-integer ratios for a given frequency don't support a fixed table size, and the 'update rate' might not be fine-adjustable enough. In contrast to a variable-LC tuning scheme, digital synthesis tables require... an exercise in ratios of integers to approximate a real number.
No, of course not :-). Of course it will take some "oversampling" etc., but it is still trivial. All it takes is say (for simplicity) a 2^16 long waveform lookup table, a factor being the quotient period/max. period normalized such that adding it to a sum each sample the sum it will be the offset to the next table entry to take. Obviously the sum is kept anded to $ffff and is never altered by other means; if we want to change the output frequency we only recalculate the quotient and keep adding.
With a DDS phase accumulator, the output frequency is
Fxo * N / M
where Fxo is the 100 MHz xtal oscillator
N is the frequency set word
M is the accumulator max count, say 2^48.
Frequency set resolution would be below 1 uHz in this case. Just load N.
The sine lookup table is addressed by some number of MSBs of the phase accumulator, 10 to 16 typically. It doesn't change in a given system.
I just want a programmable-frequency trigger generator that changes frequency on demand and doesn't stop for reprogramming and doesn't blow up someone's laser by generating any goofy triggers. In other words, goes smoothly from F1 to F2.
With low period jitter from, say, 1 mHz to 15 Mhz.
mHz resolution is good too.
<snip>
The period difference between 15 MHz and 14,999,999.999 Hz is 4.44E-15 seconds.
That would be demanding. 0.1% frequency setability should be impressive enough, and that would only demand a 70 psec increment in period at 15MHz.
You could get that out of an MC 100EP195
On a sunny day (Mon, 15 Aug 2022 19:26:28 -0700) it happened snipped-for-privacy@highlandsniptechnology.com wrote in snipped-for-privacy@4ax.com:
Well the antique way would be to mix 2 carriers. Say 100 MHz and 100 MHz mix and low pass the differnce. Now FM modulate one, from 100 MHz down to 90 MHz. (100 MHz just for example) Kids stuff.
Now I get it. I had misread mHz as MHz.... :D.
Perhaps you could shorten the lookup table to some manageable size if you do lookup-and-interpolate. Will still be huge... And division at 100 Msps may well be prohibitive.
tirsdag den 16. august 2022 kl. 04.26.40 UTC+2 skrev snipped-for-privacy@highlandsniptechnology.com:
add a frequency dependent gain and clamp to the sine to keep a reasonable slew rate?
possibly to the triangular wave input to the lookup table so you get sine edges with flat tops
Our FPGA will have at least a megabit of ram if we use the efinix, lots more if we use the Zynq. A sine table can be folded 2:1 or 4:1, so we can easily do 64K points of 16 bit data.
One of my guys proposed an architecture that uses more bits of the phase accumulator. A group of MS bits becomes the gate for a cluster of LS bits. Envision a spinner dial that mostly parks at 0 degrees and once in a while makes a single fast rotation. That essentially puts a divisor *before* a cosine lookup table and DAC.
Gotta simulate that somehow.
tirsdag den 16. august 2022 kl. 16.03.01 UTC+2 skrev snipped-for-privacy@highlandsniptechnology.com:
take you favorite programming language (or a spreadsheet) make a textfile with two columns time and value, a voltage source can load that as a pwl file
But if this is to be used as a trigger (similar to the sweep trigger on a scope, level knob etc.) can't you just do triangular instead of sine wave? Should even be better for that purpose - and no need for a lookup table at all...
That has been considered. But Claude Shannon is the evil stepmother lurking and plotting to keep us from living happily after.
The sampling frequency is async to the trigger rate that we want, so is a source of jitter. A triangle is not bandlimited to below the Nyquist rate, and we can't afford an ideal lowpass filter either.
A smaller sine/cos table might be used with
sine(a+b) = sine(a) cos(b) + cos(a)sine(b)
as in, with small deviations 'b' from major steps in the table, two multiplies and an add give you 2^20 different accurate sines from a 2^10 size sine table. Since cos(b) will always be near unity ( 1 plus order of 2^-20 when b is under 2^-10), you can make that one multiply and an add. Perhaps that's what the 'phase accumulator' is for, estimating the 'b'?
I guess I'm not seeing the problem. Ordinary DDS units with 48-bit accumulators can do just this, with phase continuity between the two frequencies, so no glitches. People implement arbitrary frequency-keyed waveforms this way.
The phase to trig converter typically uses only the upper 10 to 14 bits of the 48-bit accumulator. Converter implementations vary: table-lookup and CORDIC being very common approaches.
Perhaps it's time to bring the various discussion threads together and re-focus by restating the problem to be solved.
Joe Gwinn
tirsdag den 16. august 2022 kl. 19.46.45 UTC+2 skrev Joe Gwinn:
tirsdag den 16. august 2022 kl. 20.32.22 UTC+2 skrev John Larkin:
Or maybe someone could just read how it has been done for over a decade. This is all well traveled ground. I see people now repeating things I said days ago.
The DDS should be designed to generate a top frequency over a 2:1 range. This is easy stuff, with good accuracy and very low jitter if properly designed (use of a long phase word).
A programmable divider then divides by 2**N by counting up to the set value.
A final FF buffer register of your favorite technology will provide the actual pulse output with an appropriate jitter.
These two units can both be changed on a single clock cycle by writing to a buffer register and updating the actual operational registers simultaneously on a cue. The DDS will continue from the present phase, so will produce one clock pulse that is an intermediate period. The programmable divider will continue from the current count, either triggering right away, or continuing to count from the present value. Either way it will always produce an output pulse that is within the range of the two settings, the prior setting and the new setting.
But you can solve that by synthesising a trapezium wave rather than a sine wave, and sticking to a constant slope for the sloped bits of the trapezium wave.
Not to mention motherhood and apple pie.
A trigger clock that is always right can never be reprogrammed, because it's going to be wrong until the newly programmed frequency has been established,
You don't want to think about what you are asking for.
In the same sense as the sound of one hand clapping.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required