Direct digital synthesis of square waves...

[Anthony William Sloman]

On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:

On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

<snip>

For a sine wave the zero crossing is the point where the function is perfectly linear.

I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It\'s not like this is a new problem.

The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

That\'s exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

Really fast 14--bit DACs aren\'t cheap, but once John Larkin specified his maximum frequency to be 15MHz, and his master clock frequency as 100MHz, slower cheaper DACs would be worth looking for, if there was any prospect that he\'d pay any attention.

--
Bill Sloman, Sydney

 

[Dimiter_Popoff]

On 8/22/2022 4:12, Joe Gwinn wrote:

On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:

On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:

On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

The output of the sine table is still coarse steps, with no filter to
interpolate them. May as well just use the MSB of the phase
accumulator and not mess with sine tables.

That\'s illogical. Firstly, the output of the sine table is parts-per-thousand steps,
not \'coarse\' in the voltage sense,

https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

looks pretty coarse to me. You only get small amplitude steps at low
frequencies... and then you get slow unfiltered time steps too. That\'s
the low frequency jitter problem. And in real life, low slopes reveal
comparator imperfections too.


and you can dither and interpose as many time
steps of alternating values as you care to. Coarse in time is a choice, not
a requireent.

Second, a filter does not \'interpolate\' a time sequence, it only has access
to the PAST of the signal.

Any real lowpass filter has time delay. So relative to its output, it
is blending past and future inputs.


As far as I can see you are going to do sine wave. In that case I would
do as much brute force as is practical - the is, as long a sine lookup
table as possible - and then interpolate. Those dsp sections they put
in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
it must be doable. And second or even third order interpolation
is not that hard - and can probably give you virtually error free
values even for the 1mHz case.
Easier said than done I suppose but that\'s the advantage of giving
an opinion and not having to deliver the goods.... .

It has been suggested that, at low frequencies, we interpolate between
sine table entries so we can keep approximating the sine wave at the
100 MHz clock rate, instead of making a step now and then as the
selected MS bits of the phase accumulator tick over. That does still
make a slow sine wave at the lowpass filter output.

Straight-line interpolation is probably good enough for short segments
of a sine. The interpolation slopes could be another lookup table.

The idea of making a perfect DDS clock is a deliciously complex
problem. Just thinking about it is educational.


I did a quick misuse of my filter editor to draw a sine wave and
see what interpolation looks like. 64 points, interpolated into
16384 points. You\'ll need a lot more than that but this might give
an idea. The linear interpolation looks edgy, but the difference
between second ad third order interpolation is practically invisible at
this scale.
http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
then a small region at the top:
http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation,
http://tgi-sci.com/misc/sine_2.gif> <-- second order,
http://tgi-sci.com/misc/sine_3.gif> <-- third order.

What about the zero-crossing region? That\'s the critical area. Cubic
may be best there.

Joe Gwinn

I\'ll screenshot it tomorrow, now I am briefly awake only...
[some noise woke me up, stopped when I turned on the light;
was very faint, I lay listening for may be 2-3 minutes.
May be some insect or something...).]
I looked at the zero crossing region, it is the steepest
and closest to linear. Perhaps the top was the least linear,
did not look too much though.
But if just the zero-crossing were the problematic area no sine
would be necessary anyway (which is what I thought once I knew
it was about just triggering something but John wants a perfect
sine).

 

[whit3rd]

On Sunday, August 21, 2022 at 5:41:06 PM UTC-7, bill....@ieee.org wrote:

On Sunday, August 21, 2022 at 1:35:49 PM UTC+10, whit3rd wrote:
On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

The output of the sine table is still coarse steps, with no filter to
interpolate them. May as well just use the MSB of the phase
accumulator and not mess with sine tables.

That\'s illogical. Firstly, the output of the sine table is parts-per-thousand steps,
not \'coarse\' in the voltage sense, and you can dither and interpose as many time
steps of alternating values as you care to.

Coarse in time is a choice, not a requirement.

Actually, it is fundamental to the digital domain. You have to start off with one low jitter clock, and every digital output is clocked out by that single clock.

The whole point of the low pass filter in a DDS set-up is to cope with with the fact that you\'ve only got one set of clock edges to play with.

But, if you decide on a thousand-point table for the DAC to perform, all it takes is a
tiny bit of logic in a tight-time loop to weighted-sum two DAC outputs, one for the last sample
another for the next sample, in analog summing-junction style, thus actually doing an
interpolation as mentioned. Even though the points as DAC-generated number only
a thousand, you don\'t need to have a thousand-step staircase, it could also
be a finer staircase hitting those thousand marks, but microstepping between.

My preference would be to do that all analog, phase-locking to make the inner clock for the lowest
output frequencies. Needn\'t be any microstepping, if current-steering is run by a trianglewave
VCO.

 

[Ricky]

On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:

On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla....@highlandsniptechnology.com:
snip
For a sine wave the zero crossing is the point where the function is perfectly linear.

I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It\'s not like this is a new problem.

The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.
That\'s exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?

You can\'t just load the table with one set of values and expect it to generate the same slope for every frequency. If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.

Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.

--

Rick C.

+++ Get 1,000 miles of free Supercharging
+++ Tesla referral code - https://ts.la/richard11209

 

[Anthony William Sloman]

On Monday, August 22, 2022 at 2:07:08 PM UTC+10, Ricky wrote:

On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:
On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci..com> wrote:
On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:
snip
For a sine wave the zero crossing is the point where the function is perfectly linear.

I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It\'s not like this is a new problem.

The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

That\'s exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?

It\'s just arithmetic. Your programmable logic gets told how much time you want between each zero crossing and programs the counter to step the DAC along at maximum or minimum output until you want the ramp to start, then steps it through the ramp look-up table picking up the series of values that will put the zero-crossing in the right place.

> You can\'t just load the table with one set of values and expect it to generate the same slope for every frequency.

Actually you can. There are going to be a lot of different ramps in there - each with the same slope - each one putting the zero-crossings at different particular offsets from the clock, and the arithmetic engine has to pick the right set of sample to generate the right ramp.

If the clock ticks are the integral part of the delay, the offset of the zero-crossing from the clock tick is the fractional part, and you pick the set of DAC inputs you want to give you that offset, and step through just them.

> If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.

It might if you weren\'t thinking about what you were doing.

> Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.

Obviously not.

--
Bill Sloman, Sydney

 

[Ricky]

On Monday, August 22, 2022 at 1:07:49 AM UTC-4, bill....@ieee.org wrote:

On Monday, August 22, 2022 at 2:07:08 PM UTC+10, Ricky wrote:
On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:
On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:
snip
For a sine wave the zero crossing is the point where the function is perfectly linear.

I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It\'s not like this is a new problem.

The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency.

That\'s exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated. Same slope, same low pass filter. Massive simplification.

Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?
It\'s just arithmetic. Your programmable logic gets told how much time you want between each zero crossing and programs the counter to step the DAC along at maximum or minimum output until you want the ramp to start, then steps it through the ramp look-up table picking up the series of values that will put the zero-crossing in the right place.

What you are describing won\'t get you the timing alignment required. The point of the DDS is to provide a waveform that, once filtered, has accuracy better than the clock period. The sine generation uses additional resolution in amplitude to provide additional resolution in timing.

You can\'t just load the table with one set of values and expect it to generate the same slope for every frequency.
Actually you can. There are going to be a lot of different ramps in there - each with the same slope - each one putting the zero-crossings at different particular offsets from the clock, and the arithmetic engine has to pick the right set of sample to generate the right ramp.

I\'m not sure what \"logic\" you are describing. I think you have not looked at how the logic would need to operate if you aren\'t using a LUT.


> If the clock ticks are the integral part of the delay, the offset of the zero-crossing from the clock tick is the fractional part, and you pick the set of DAC inputs you want to give you that offset, and step through just them.

You \"pick\"? Yes, that\'s a good description if you aren\'t actually designing it. The phase accumulator controls the timing and selects the amplitude through the lookup table. I\'m not picturing how this would work usefully to generate a largely rectangular pulse with the same rise/fall times independent of frequency. So something else would need to be used. I\'m not sure how you get the appropriate fractional clock timing.

If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.
It might if you weren\'t thinking about what you were doing.

Typical Sloman response when he is in over his head. You don\'t actually know what you are doing at this point, so you criticize the person you are talking to. Ok, I get it.

Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.
Obviously not.

If you say so.

Bottom line is, this complex goofy thing is not even needed. A programmable octave divider can follow a proper DDS using a 2:1 range to give the same timing precision and jitter from any frequency the DDS outputs down as low as you wish to go. No goofy complexities. Just a simple design that has been proven over and over again. If all the logic is implemented in the same FPGA, it can all be updated simultaneously to never cause a glitch in the pulse timing.

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209

 

[Anthony William Sloman]

On Monday, August 22, 2022 at 6:37:38 PM UTC+10, Ricky wrote:

On Monday, August 22, 2022 at 1:07:49 AM UTC-4, bill....@ieee.org wrote:
On Monday, August 22, 2022 at 2:07:08 PM UTC+10, Ricky wrote:
On Sunday, August 21, 2022 at 9:50:01 PM UTC-4, bill....@ieee.org wrote:
On Monday, August 22, 2022 at 11:35:47 AM UTC+10, Ricky wrote:
On Sunday, August 21, 2022 at 9:12:50 PM UTC-4, Joe Gwinn wrote:
On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 19:40, jla...@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <d...@tgi-sci.com> wrote:
On 8/21/2022 18:12, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:
On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

<snip>

For a sine wave the zero crossing is the point where the function is perfectly linear.

I think this train of thought is out of control. The easy and optimal solution is the bog standard DDS with a long phase accumulator, a well constructed tables for the sum of angles sine equation, and a quality DAC followed by a good low pass filter and comparitor. This only needs to operate over a 2:1 frequency range since all lower frequencies can be generated by a programmable divider from the DDS output. No fuss, no muss and it can be done by next week. It\'s not like this is a new problem.

The idea of generating a trapezoid waveform over a wide frequency range means reloading the lookup table every time you change the frequency..

That\'s exactly what it avoids.The sloped bits of the trapezoid were to have exactly the same slope no matter what frequency is being generated.. Same slope, same low pass filter. Massive simplification.

Sounds good on the downstream side, but how do you generate the samples to feed the DAC? If you want to have variable frequency, you need to adjust the lookup table for every frequency you choose. How else are you generating the DAC samples?

It\'s just arithmetic. Your programmable logic gets told how much time you want between each zero crossing and programs the counter to step the DAC along at maximum or minimum output until you want the ramp to start, then steps it through the ramp look-up table picking up the series of values that will put the zero-crossing in the right place.

What you are describing won\'t get you the timing alignment required.

It will.

> The point of the DDS is to provide a waveform that, once filtered, has accuracy better than the clock period. The sine generation uses additional resolution in amplitude to provide additional resolution in timing.

In John Larkin\'s application, you only need to get it right at the zero-crossing points, and the trapezium approach provides the extra resolution where you need it, and pretty much only where you need it.

You can\'t just load the table with one set of values and expect it to generate the same slope for every frequency.

Actually you can. There are going to be a lot of different ramps in there - each with the same slope - each one putting the zero-crossings at different particular offsets from the clock, and the arithmetic engine has to pick the right set of sample to generate the right ramp.

I\'m not sure what \"logic\" you are describing. I think you have not looked at how the logic would need to operate if you aren\'t using a LUT.

You are using look-up table. For a 14-bit DAC you\'d select one of 1024 possible 16-step ramps to get the zero -crossing at one of 1024 possible points between clock edges.

> > If the clock ticks are the integral part of the delay, the offset of the zero-crossing from the clock tick is the fractional part, and you pick the set of DAC inputs you want to give you that offset, and step through just them.

After each output edge you use an adder to work out exactly when the next output clock edge has to appear. You know where the last output clock edge was - to an integral number of clock ticks plus that fraction of the tick that you set up, and you just add the delay you want to get time location of the next output clock edge. The sum has integral number of clock ticks plus a fractional part. You start the ramp exactly eight clock ticks before the interval where you want to the zero crossing to happen, and the fractional part selects which of the 1024 possible ramps you chose to get the next clock edge in the right place.

It\'s just arithmetic.

> You \"pick\"? Yes, that\'s a good description if you aren\'t actually designing it.

It\'s a brief description that tells you what the design has to do. It doesn\'t seem to have told you enough.

The phase accumulator controls the timing and selects the amplitude through the lookup table. I\'m not picturing how this would work usefully to generate a largely rectangular pulse with the same rise/fall times independent of frequency. So something else would need to be used. I\'m not sure how you get the appropriate fractional clock timing.

If you use the same LUT for a slow and fast output frequency, the fast output frequency would have a large enough step size through the LUT to literally skip over the ramp. At sufficiently low sample rates, the slow again turns into a slow ramp.

It might if you weren\'t thinking about what you were doing.

Typical Sloman response when he is in over his head. You don\'t actually know what you are doing at this point, so you criticize the person you are talking to.

I knew exactly what I was doing, but I was keeping the description short.

> Ok, I get it.

You clearly didn\'t.

Is this about no LUT at all? Just using the LSBs of the phase ramp? But that still gives you varying ramp slopes.

Obviously not.

If you say so.

I do say so, and I hope I\'ve given enough detail this time around so that it is now as obvious to you as it was to me.

> Bottom line is, this complex goofy thing is not even needed.

The fact that you didn\'t get it doesn\'t actually make it goofy, and it\'s less complex than a DDS because it\'s only making the square wave and leaving out the sine.

Analog Devices will sell you the whole DDS as a single (expensive) chip which would make life simpler for the designer, but it may not be the cheapest, or the lowest jitter solution.

> A programmable octave divider can follow a proper DDS using a 2:1 range to give the same timing precision and jitter from any frequency the DDS outputs down as low as you wish to go. No goofy complexities.

None that you are aware of.

> Just a simple design that has been proven over and over again. If all the logic is implemented in the same FPGA, it can all be updated simultaneously to never cause a glitch in the pulse timing.

If you use a DDS chip. most of the logic is implemented inside the chip, not in an FPGA. My impression was that John Larkin was planning on avoiding paying for an expensive DDS chip by doing his own logic in an FPGA and using it to drive a DAC, which is perfectly feasible, if rather fiddly.

--
Bill Sloman, Sydney

 

[Joe Gwinn]

On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

On 8/22/2022 4:12, Joe Gwinn wrote:
On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:

On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:

On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

The output of the sine table is still coarse steps, with no filter to
interpolate them. May as well just use the MSB of the phase
accumulator and not mess with sine tables.

That\'s illogical. Firstly, the output of the sine table is parts-per-thousand steps,
not \'coarse\' in the voltage sense,

https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

looks pretty coarse to me. You only get small amplitude steps at low
frequencies... and then you get slow unfiltered time steps too. That\'s
the low frequency jitter problem. And in real life, low slopes reveal
comparator imperfections too.


and you can dither and interpose as many time
steps of alternating values as you care to. Coarse in time is a choice, not
a requireent.

Second, a filter does not \'interpolate\' a time sequence, it only has access
to the PAST of the signal.

Any real lowpass filter has time delay. So relative to its output, it
is blending past and future inputs.


As far as I can see you are going to do sine wave. In that case I would
do as much brute force as is practical - the is, as long a sine lookup
table as possible - and then interpolate. Those dsp sections they put
in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
it must be doable. And second or even third order interpolation
is not that hard - and can probably give you virtually error free
values even for the 1mHz case.
Easier said than done I suppose but that\'s the advantage of giving
an opinion and not having to deliver the goods.... .

It has been suggested that, at low frequencies, we interpolate between
sine table entries so we can keep approximating the sine wave at the
100 MHz clock rate, instead of making a step now and then as the
selected MS bits of the phase accumulator tick over. That does still
make a slow sine wave at the lowpass filter output.

Straight-line interpolation is probably good enough for short segments
of a sine. The interpolation slopes could be another lookup table.

The idea of making a perfect DDS clock is a deliciously complex
problem. Just thinking about it is educational.


I did a quick misuse of my filter editor to draw a sine wave and
see what interpolation looks like. 64 points, interpolated into
16384 points. You\'ll need a lot more than that but this might give
an idea. The linear interpolation looks edgy, but the difference
between second ad third order interpolation is practically invisible at
this scale.
http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
then a small region at the top:
http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation,
http://tgi-sci.com/misc/sine_2.gif> <-- second order,
http://tgi-sci.com/misc/sine_3.gif> <-- third order.

What about the zero-crossing region? That\'s the critical area. Cubic
may be best there.

Joe Gwinn

I\'ll screenshot it tomorrow, now I am briefly awake only...
[some noise woke me up, stopped when I turned on the light;
was very faint, I lay listening for may be 2-3 minutes.
May be some insect or something...).]
I looked at the zero crossing region, it is the steepest
and closest to linear. Perhaps the top was the least linear,
did not look too much though.
But if just the zero-crossing were the problematic area no sine
would be necessary anyway (which is what I thought once I knew
it was about just triggering something but John wants a perfect
sine).

No, John L does not care if the sine is perfect. The issue is to
interpolate the zero crossing region to achieve picosecond time
accuracy despite using 100 MHz NCO clock.

Joe Gwinn

 

[server]

On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

On 8/22/2022 4:12, Joe Gwinn wrote:
On Sun, 21 Aug 2022 23:35:04 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:

On 8/21/2022 19:40, jlarkin@highlandsniptechnology.com wrote:
On Sun, 21 Aug 2022 19:27:33 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:

On 8/21/2022 18:12, jlarkin@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 20:35:45 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

On Saturday, August 20, 2022 at 6:04:32 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 20 Aug 2022 13:50:23 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 20. august 2022 kl. 22.35.00 UTC+2 skrev jla...@highlandsniptechnology.com:

The output of the sine table is still coarse steps, with no filter to
interpolate them. May as well just use the MSB of the phase
accumulator and not mess with sine tables.

That\'s illogical. Firstly, the output of the sine table is parts-per-thousand steps,
not \'coarse\' in the voltage sense,

https://www.dropbox.com/s/1xx7sz1e5rg6jsi/JLDDS_100M_4K.jpg?raw=1

looks pretty coarse to me. You only get small amplitude steps at low
frequencies... and then you get slow unfiltered time steps too. That\'s
the low frequency jitter problem. And in real life, low slopes reveal
comparator imperfections too.


and you can dither and interpose as many time
steps of alternating values as you care to. Coarse in time is a choice, not
a requireent.

Second, a filter does not \'interpolate\' a time sequence, it only has access
to the PAST of the signal.

Any real lowpass filter has time delay. So relative to its output, it
is blending past and future inputs.


As far as I can see you are going to do sine wave. In that case I would
do as much brute force as is practical - the is, as long a sine lookup
table as possible - and then interpolate. Those dsp sections they put
in fpga-s must be kept busy? 10 ns is not a lot of time to do it but
it must be doable. And second or even third order interpolation
is not that hard - and can probably give you virtually error free
values even for the 1mHz case.
Easier said than done I suppose but that\'s the advantage of giving
an opinion and not having to deliver the goods.... .

It has been suggested that, at low frequencies, we interpolate between
sine table entries so we can keep approximating the sine wave at the
100 MHz clock rate, instead of making a step now and then as the
selected MS bits of the phase accumulator tick over. That does still
make a slow sine wave at the lowpass filter output.

Straight-line interpolation is probably good enough for short segments
of a sine. The interpolation slopes could be another lookup table.

The idea of making a perfect DDS clock is a deliciously complex
problem. Just thinking about it is educational.


I did a quick misuse of my filter editor to draw a sine wave and
see what interpolation looks like. 64 points, interpolated into
16384 points. You\'ll need a lot more than that but this might give
an idea. The linear interpolation looks edgy, but the difference
between second ad third order interpolation is practically invisible at
this scale.
http://tgi-sci.com/misc/sine_all.gif> <-- the whole period
then a small region at the top:
http://tgi-sci.com/misc/sine_1.gif> <-- first order interpolation,
http://tgi-sci.com/misc/sine_2.gif> <-- second order,
http://tgi-sci.com/misc/sine_3.gif> <-- third order.

What about the zero-crossing region? That\'s the critical area. Cubic
may be best there.

Joe Gwinn

I\'ll screenshot it tomorrow, now I am briefly awake only...
[some noise woke me up, stopped when I turned on the light;
was very faint, I lay listening for may be 2-3 minutes.
May be some insect or something...).]
I looked at the zero crossing region, it is the steepest
and closest to linear. Perhaps the top was the least linear,
did not look too much though.
But if just the zero-crossing were the problematic area no sine
would be necessary anyway (which is what I thought once I knew
it was about just triggering something but John wants a perfect
sine).

I don\'t want a perfect sine, but a classic sine-output DDS is easy to
understand and changes frequency coherently.

Here\'s a minor revelation:

At lower frequencies, using more MS bits of the phase accumulator (ie,
a bigger sine lookup table) and more DAC bits makes a surprisingly
clean sine wave in my sim. 15 bits of lookup and 12 bits of dac look
great for output frequencies from 15 MHz to well below 150K, which is
two decades of frequency.

But the sine slope gets low at low frequencies. Using a single-end
terminated lowpass filter helps 2:1, at least. But the comparator may
well be the jitter limit.

Our old product uses an AD9850 DDS chip. It has a max output voltage
of 1.5 unipolar; divide by 2 for a double-loaded LC filter. What\'s
worse is that we used the chip\'s internal comparator, which is on the
same chip as all the clocked logic, and crosstalk will be hideous.

So, a good DDS needs good analog bits.

 

[Clifford Heath]

On 23/8/22 00:57, Joe Gwinn wrote:

On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:
I looked at the zero crossing region, it is the steepest
and closest to linear. Perhaps the top was the least linear,
did not look too much though.
But if just the zero-crossing were the problematic area no sine
would be necessary anyway (which is what I thought once I knew
it was about just triggering something but John wants a perfect
sine).

No, John L does not care if the sine is perfect. The issue is to
interpolate the zero crossing region to achieve picosecond time
accuracy despite using 100 MHz NCO clock.

With that succinct restatement of the OP, I\'ll repeat my answer.

Use only the top bit of the DDS phase accumulator, with as many as you
can of the following bits stuffed into a digital delay generator that\'s
triggered by that top bit.

John already knows how to do a good DDG. It needs to be linear, of
course, or be fed through a lookup table that\'s calibrated.

Clifford Heath.

 

[server]

On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
<no_spam@please.net> wrote:

On 23/8/22 00:57, Joe Gwinn wrote:
On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <dp@tgi-sci.com
wrote:
I looked at the zero crossing region, it is the steepest
and closest to linear. Perhaps the top was the least linear,
did not look too much though.
But if just the zero-crossing were the problematic area no sine
would be necessary anyway (which is what I thought once I knew
it was about just triggering something but John wants a perfect
sine).

No, John L does not care if the sine is perfect. The issue is to
interpolate the zero crossing region to achieve picosecond time
accuracy despite using 100 MHz NCO clock.

With that succinct restatement of the OP, I\'ll repeat my answer.

Use only the top bit of the DDS phase accumulator, with as many as you
can of the following bits stuffed into a digital delay generator that\'s
triggered by that top bit.

John already knows how to do a good DDG.

The concept is sound, but it would need a delay generator that has
picosecond accuracy and can be reloaded about every 60 ns. Some
pipelining would be involved, which is OK for a frequency source.

Gotta think about that.

 

[Anthony William Sloman]

On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:

On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
no_...@please.net> wrote:

On 23/8/22 00:57, Joe Gwinn wrote:
On Mon, 22 Aug 2022 05:18:22 +0300, Dimiter_Popoff <d...@tgi-sci.com
wrote:
I looked at the zero crossing region, it is the steepest
and closest to linear. Perhaps the top was the least linear,
did not look too much though.
But if just the zero-crossing were the problematic area no sine
would be necessary anyway (which is what I thought once I knew
it was about just triggering something but John wants a perfect
sine).

No, John L does not care if the sine is perfect. The issue is to
interpolate the zero crossing region to achieve picosecond time
accuracy despite using 100 MHz NCO clock.

With that succinct restatement of the OP, I\'ll repeat my answer.

Use only the top bit of the DDS phase accumulator, with as many as you
can of the following bits stuffed into a digital delay generator that\'s
triggered by that top bit.

John already knows how to do a good DDG.
The concept is sound, but it would need a delay generator that has
picosecond accuracy and can be reloaded about every 60 ns. Some
pipelining would be involved, which is OK for a frequency source.

Gotta think about that.

That\'s what the trapezium slope generator seems to offer. If you wanted pico-second resolution you\'d need at least a 500Mhz clock and a 16 -bit DAC. My example envisaged a 2.5GHz clock and 14-bit DAC and had a 0.4psec granularity. The clock and the DAC would have to be pretty good to offer that kind of accuracy.

--
Bill Sloman, Sydney

 

[Clifford Heath]

On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:

On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
no_...@please.net> wrote:
Use only the top bit of the DDS phase accumulator, with as many as you
can of the following bits stuffed into a digital delay generator that\'s
triggered by that top bit.

John already knows how to do a good DDG.
The concept is sound, but it would need a delay generator that has
picosecond accuracy and can be reloaded about every 60 ns. Some
pipelining would be involved, which is OK for a frequency source.

Gotta think about that.

Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that\'s just me, I never claimed to be a picosecond guy.

Clifford Heath

 

[Anthony William Sloman]

On Tuesday, August 23, 2022 at 2:53:08 PM UTC+10, Clifford Heath wrote:

On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
no_...@please.net> wrote:
Use only the top bit of the DDS phase accumulator, with as many as you
can of the following bits stuffed into a digital delay generator that\'s
triggered by that top bit.

John already knows how to do a good DDG.
The concept is sound, but it would need a delay generator that has
picosecond accuracy and can be reloaded about every 60 ns. Some
pipelining would be involved, which is OK for a frequency source.

Gotta think about that.

Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that\'s just me, I never claimed to be a picosecond guy.

It\'s not the picoseconds per se that are the problem, but the accuracy, Buying the ADC to make the ramp buys you a lot of accuracy. Making a linear ramp that\'s accurate to a picosecond over a nanosecond or two is doable, but it\'s a better than 0.1% accurate current into a better than 0.1% stable capacitor, and when I last did something like it back in around 1988 we autocalibrated the system every ten minutes to keep it accurate. It only took a few milliseconds but it\'s a considerable complication. The ADC saves you from that.

--
Bill Sloman, Sydney

 

[Joe Gwinn]

On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath
<clifford.heath@gmail.com> wrote:

On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
no_...@please.net> wrote:
Use only the top bit of the DDS phase accumulator, with as many as you
can of the following bits stuffed into a digital delay generator that\'s
triggered by that top bit.

John already knows how to do a good DDG.
The concept is sound, but it would need a delay generator that has
picosecond accuracy and can be reloaded about every 60 ns. Some
pipelining would be involved, which is OK for a frequency source.

Gotta think about that.

Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that\'s just me, I never claimed to be a picosecond guy.

It occurs to me that one gets to choose which accumulator bit (or bit
field) to use, and each bit alternates trice as fast as the next most
significant bit. From the NCO frequency control word, we know exactly
what frequency is being generated.

This allows us to compute the pre-trigger phase angle, used to
generate the pre-trigger signal needed to know when to start the
interpolator hardware, and what period it is to interpolate over
(which is loaded into the interpolator ahead of the trigger).

This also allows us to compute which accumulator bit alternates at the
correct rate. When this bit changes, the interpolator commences its
run, yielding a delayed trigger that is intended to be at the actual
zero crossing. The use of the pre-trigger removes the which-cycle
ambiguity of a fast-alternating accumulator bit.

The above is the bare-bones approach. One can also use multiple
accumulator bits to trigger the run-up steps before the interpolator
run.

One can also approximate Phil H\'s 1/f scheme in the above, largely by
choice of accumulator bits to use.

Joe Gwinn

 

[Ricky]

On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:

On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath
cliffor...@gmail.com> wrote:

On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath
no_...@please.net> wrote:
Use only the top bit of the DDS phase accumulator, with as many as you
can of the following bits stuffed into a digital delay generator that\'s
triggered by that top bit.

John already knows how to do a good DDG.
The concept is sound, but it would need a delay generator that has
picosecond accuracy and can be reloaded about every 60 ns. Some
pipelining would be involved, which is OK for a frequency source.

Gotta think about that.

Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that\'s just me, I never claimed to be a picosecond guy.
It occurs to me that one gets to choose which accumulator bit (or bit
field) to use, and each bit alternates trice as fast as the next most
significant bit. From the NCO frequency control word, we know exactly
what frequency is being generated.
This allows us to compute the pre-trigger phase angle, used to
generate the pre-trigger signal needed to know when to start the
interpolator hardware, and what period it is to interpolate over
(which is loaded into the interpolator ahead of the trigger).

This also allows us to compute which accumulator bit alternates at the
correct rate. When this bit changes, the interpolator commences its
run, yielding a delayed trigger that is intended to be at the actual
zero crossing. The use of the pre-trigger removes the which-cycle
ambiguity of a fast-alternating accumulator bit.

The above is the bare-bones approach. One can also use multiple
accumulator bits to trigger the run-up steps before the interpolator
run.

One can also approximate Phil H\'s 1/f scheme in the above, largely by
choice of accumulator bits to use.

That\'s all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?

--

Rick C.

---+ Get 1,000 miles of free Supercharging
---+ Tesla referral code - https://ts.la/richard11209

 

[Anthony William Sloman]

On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:

On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:
On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:

<snip>

> That\'s all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?

Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don\'t have to buy or program the FPGA.

The reason that John Larkin isn\'t doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you\'ve got to that point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

--
Bill Sloman, Sydney

 

[Ricky]

On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:

On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor...@gmail.com> wrote:
On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:
snip
That\'s all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?
Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don\'t have to buy or program the FPGA.

The reason that John Larkin isn\'t doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you\'ve got to that point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.

There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS update. So this might need a bit of thought to make sure there are no glitches during a rate transition.

--

Rick C.

--+- Get 1,000 miles of free Supercharging
--+- Tesla referral code - https://ts.la/richard11209

 

[Anthony William Sloman]

On Thursday, August 25, 2022 at 1:24:55 PM UTC+10, Ricky wrote:

On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:
On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor....@gmail.com> wrote:
On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:
snip
That\'s all true in theory, but there are a lot of details to work out.. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?

Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don\'t have to buy or program the FPGA.

The reason that John Larkin isn\'t doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design).. Once you\'ve got to that point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.

Have you any idea how the Analog Devices chips work? Or what\'s being asked for? The Analog Devices part produce a continuous signal through a frequency transition so one transition is going to be in the wrong place in terms of either frequency regime, but that\'s inevitable, unless you make the transition on an output clock edge. which would take work.

> There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS update. So this might need a bit of thought to make sure there are no glitches during a rate transition.

The trapezium ramp scheme wouldn\'t need an \"octave divider\" so it wouldn\'t have that problem.

--
Bill Sloman, Sydney

 

[Ricky]

On Thursday, August 25, 2022 at 12:50:47 AM UTC-4, bill....@ieee.org wrote:

On Thursday, August 25, 2022 at 1:24:55 PM UTC+10, Ricky wrote:
On Wednesday, August 24, 2022 at 10:30:13 PM UTC-4, bill....@ieee.org wrote:
On Thursday, August 25, 2022 at 6:30:11 AM UTC+10, Ricky wrote:
On Wednesday, August 24, 2022 at 10:14:05 AM UTC-4, Joe Gwinn wrote:
On Mon, 22 Aug 2022 21:53:03 -0700 (PDT), Clifford Heath <cliffor....@gmail.com> wrote:
On Tuesday, August 23, 2022 at 12:12:41 PM UTC+10, jla...@highlandsniptechnology.com wrote:
On Tue, 23 Aug 2022 11:21:00 +1000, Clifford Heath <no_...@please.net> wrote:
snip
That\'s all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?

Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don\'t have to buy or program the FPGA.

The reason that John Larkin isn\'t doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you\'ve got to that point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.

It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.
Have you any idea how the Analog Devices chips work? Or what\'s being asked for? The Analog Devices part produce a continuous signal through a frequency transition so one transition is going to be in the wrong place in terms of either frequency regime, but that\'s inevitable, unless you make the transition on an output clock edge. which would take work.
There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS update. So this might need a bit of thought to make sure there are no glitches during a rate transition.
The trapezium ramp scheme wouldn\'t need an \"octave divider\" so it wouldn\'t have that problem.

The \"trapezium\" scheme has the problem that it isn\'t designed and may have other problems.

--

Rick C.

--++ Get 1,000 miles of free Supercharging
--++ Tesla referral code - https://ts.la/richard11209