On Thursday, August 25, 2022 at 4:43:52 PM UTC+10, Ricky wrote:
> 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. 

Of course it isn't designed. I'm not going to put it into production, and John Larkin wouldn't pay me money to design it for him.

The detailed design phase is where you find and sort out a whole lot of - hopefully  - minor problems. Back when I was getting paid to do that kind of work I was pretty good at it, but that's a long time ago. What I've spelled out here strikes me as good beginning, but John Larkin may have some particularly rabid customer to satisfy, and he hasn't been all that forth-coming about the end application.

A lot of the point of having this kind of early stage design is to clarify what's going on and what needs to go on.

-- 
Bill Sloman, Sydney

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

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

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

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

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

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

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

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

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