To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS a minimum clock of >24, say 25 MHz, is required. To be able to go down to 0.5 mHz, a phase accumulator of at least 36 bits is required. This will give sub mHz resolution over the entire range. Nice for the low frequencies, but not of much use for MHz frequencies (in this application). Is there any objection to using a smaller phase accumulator and a clock pre-scaler to generate the lower frequencies? I see Analog Devices has DDS chips up to 48 bits, so 36 bits would not be a problem (except for cost maybe). But al of the DDS chips I find from Analog seem only to implement a fixed sine table/function. Do DDS chips exist that allow downloading an arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each? If no such standard chips exist, I expect I need to implement the DDS in an FPGA. Using a smaller accumulator would probably save some space in the FPGA. Or am I just optoimizing prematurely? -- Stef Baker's First Law of Federal Geometry: A block grant is a solid mass of money surrounded on all sides by governors.
Wide frequency range, arbitrary waveform DDS
Started by ●August 16, 2022
Reply by ●August 16, 20222022-08-16
On Tuesday, August 16, 2022 at 11:37:41 AM UTC-4, Stef wrote:> To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS==20> a minimum clock of >24, say 25 MHz, is required. To be able to go down=20 > to 0.5 mHz, a phase accumulator of at least 36 bits is required. This=20 > will give sub mHz resolution over the entire range. Nice for the low=20 > frequencies, but not of much use for MHz frequencies (in this=20 > application).=20 >=20 > Is there any objection to using a smaller phase accumulator and a clock==20> pre-scaler to generate the lower frequencies?=20There is a STRONG objection to shortening the phase word. It will cause pr= oblems with close in spurs (which can't be filtered) and reduces your resol= ution. See below. =20 Instead of a pre-scaler, use a post divider. A pre-scaler on the clock to= the DDS requires the analog filter to be adjusted to suit.=20> I see Analog Devices has DDS chips up to 48 bits, so 36 bits would not=20 > be a problem (except for cost maybe).=20 >=20 > But al of the DDS chips I find from Analog seem only to implement a=20 > fixed sine table/function. Do DDS chips exist that allow downloading an==20> arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each?=20If you are looking to generate a non-sine waveform, it is not needed, or us= eful.=20> If no such standard chips exist, I expect I need to implement the DDS=20 > in an FPGA. Using a smaller accumulator would probably save some space=20 > in the FPGA. Or am I just optoimizing prematurely?=20Do you work at Highland Technology? =20 I've posted about an appropriate solution more than once in s.e.d. Here i= s a fair summary... A 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 and a good filter after the DAC. It is importan= t to NOT shorten the phase word as that introduces spurs close to the frequ= ency being generated, which can not be filtered out. This is because the t= runcation of the phase word creates discontinuities which show up as close = in spurs. Keep the phase word long and round the sine output to suit a 16= bit DAC. This generates harmonics which are much easier to filter.=20 You don't need to use a single large table for the sine. sin(a+b) =3D sin= (a)cos(b) + cos(a)sin(b), where a is the msbs of the phase word and b is th= e lsbs. Use appropriately sized tables for sin(a), cos(b) and a single tab= le for the product cos(a)sin(b). This is practical if (a) and (b) are each= truncated a bit. Because sin(b) is always small, this term is always smal= l and does not need to be calculated with full resolution on a and b. This= product table also does not require the full word width. Three table look= ups, one multiply and one add.=20 A programmable divider then divides the top frequency by 2**N by counting u= p to a settable value. The top frequency can clock a final FF buffer register of your favorite tec= hnology to provide the actual pulse output with an appropriate jitter. The settings of these two units can both be changed on a single clock cycle= by writing to a buffer register and updating the actual operational regist= ers simultaneously on a cue. The DDS will continue from the present phase, = so will produce one top frequency clock pulse that is an intermediate perio= d. The programmable divider will continue from the current count, either tr= iggering right away, or continuing to count from the present value. Either = way it will produce one output pulse that is within the range of the two se= ttings, the prior setting and the new setting.=20 Does this make sense? Feel free to drop my name with your boss.=20 --=20 Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
Reply by ●August 17, 20222022-08-17
On 2022-08-17 gnuarm.del...@gmail.com wrote in comp.arch.fpga:> On Tuesday, August 16, 2022 at 11:37:41 AM UTC-4, Stef wrote: >> To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS >> a minimum clock of >24, say 25 MHz, is required. To be able to go down >> to 0.5 mHz, a phase accumulator of at least 36 bits is required. This >> will give sub mHz resolution over the entire range. Nice for the low >> frequencies, but not of much use for MHz frequencies (in this >> application). >> >> Is there any objection to using a smaller phase accumulator and a clock >> pre-scaler to generate the lower frequencies? > > There is a STRONG objection to shortening the phase word. It will cause problems with close in spurs (which can't be filtered) and reduces your resolution. See below. > > Instead of a pre-scaler, use a post divider. A pre-scaler on the clock to the DDS requires the analog filter to be adjusted to suit. >Ah yes, changing the clock would require adjustment of the output filter. Not something you would want to do. How would you post-divide the (arbitrary waveform) output? Or do you mean something else with the post-divide?> >> I see Analog Devices has DDS chips up to 48 bits, so 36 bits would not >> be a problem (except for cost maybe). >> >> But al of the DDS chips I find from Analog seem only to implement a >> fixed sine table/function. Do DDS chips exist that allow downloading an >> arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each? > > If you are looking to generate a non-sine waveform, it is not needed, or useful.Could you explain this? How would I generate an arbitrary waveform without using a table?>> If no such standard chips exist, I expect I need to implement the DDS >> in an FPGA. Using a smaller accumulator would probably save some space >> in the FPGA. Or am I just optoimizing prematurely? > > Do you work at Highland Technology?No, I do not.> I've posted about an appropriate solution more than once in s.e.d. Here is a fair summary... >I don't read there, so missed that. But are you now talking about an appropriate solution for a specific Highland Technology problem, or a general solution?> A 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 and a good filter after the DAC. It is important to NOT shorten the phase word as that introduces spurs close to the frequency being generated, which can not be filtered out. This is because the truncation of the phase word creates discontinuities which show up as close in spurs. Keep the phase word long and round the sine output to suit a 16 bit DAC. This generates harmonics which are much easier to filter. > > You don't need to use a single large table for the sine. sin(a+b) = sin(a)cos(b) + cos(a)sin(b), where a is the msbs of the phase word and b is the lsbs. Use appropriately sized tables for sin(a), cos(b) and a single table for the product cos(a)sin(b). This is practical if (a) and (b) are each truncated a bit. Because sin(b) is always small, this term is always small and does not need to be calculated with full resolution on a and b. This product table also does not require the full word width. Three table lookups, one multiply and one add. > > A programmable divider then divides the top frequency by 2**N by counting up to a settable value. > > The top frequency can clock a final FF buffer register of your favorite technology to provide the actual pulse output with an appropriate jitter. > > The settings of 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 top frequency 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 produce one output pulse that is within the range of the two settings, the prior setting and the new setting. > > Does this make sense?Not really. I don't need just a sin(a+b) signal, I need to implement arbitrary (not realy arbitrary, but various rather complex) waveforms. I don't see how your solution will do this, unless I totally misunderstood it.> Feel free to drop my name with your boss.I can do that, but I doubt it it will ring a bell, even with your full name. I believe we live on different continents, so I don't think we have ever met. -- Stef A sinking ship gathers no moss. -- Donald Kaul
Reply by ●August 17, 20222022-08-17
In comp.arch.embedded Stef <me@this.is.invalid> wrote:> To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS > a minimum clock of >24, say 25 MHz, is required. To be able to go down > to 0.5 mHz, a phase accumulator of at least 36 bits is required. This > will give sub mHz resolution over the entire range. Nice for the low > frequencies, but not of much use for MHz frequencies (in this > application). > > Is there any objection to using a smaller phase accumulator and a clock > pre-scaler to generate the lower frequencies?Well, your frequency will be less accurate. To see this let me derive formula for DDS. Let t be DAC clock, T be period of desired signal and assume that we have N samples at uniformly distributed points. At n-th tick of DAC clock real time is nt. In the scale of desired signal this corresponds to nt/T. To get position within period we drop integer part of this, that is take frac(nt/T). Then we need to round to closest sample point. Actually instead of rounding we can multiply by N, add 0.5 as bias and take integer part. So, sample index is: [N frac(nt/T) + 0.5] where [ ] denotes integer part. Assuming that N is power of 2, say 2^m and all arthmetic is in fixed point binary frac above is equvalent to dropping high bits, leaving only m bits before binary point. Integer part means dropping bits after bianary points. So formula simplified to [nNt/T + 0.5] = [n*a + b] where a = Nt/T and b = 0.5 is time shift. Note that taking phi_n = n*a + b we have phi_{n+1} = (n+1)*a + b = a + phi_n so single addition is enough to adjust phase. What is effect of using smaller number of bits to represent phase phi_n? Well, b needs only 1 bit, so if Nt/T fits into k bits with k bigger than m + 1, then calculation using k bits gives exactly the same result as calculation using infinite precision. In other words, using k bits we get exact result but possibly for wrong frequency. In general acceptable frequency error depends on application. But since good analog components are more expensive than digital ones, simple heuristic says that resuluting of phase accumulator should not degrade accuracy of oscilator. Assuming few ppm quartz oscilator as source of DAC clock, this means that we need about 20 significant bits in parameter a. OTOH, at moderate freqences we do not want to make big jumps, so parameter a should have m or more zero bits at start. With m = 10 we arrive at 30 bits. Add some margin for users that want slightly better results and we arrive at 36 bits. In fact, if you want 0.5 mHz without divisor on DAC clock you will have about 35 zero bits at start of paramter a, so 55 bits phase accumultor would be more appropriate. However, in in few hundreds Hertz range and below pre-divisor on DAC clock seem quite appropriate, so 36 bits + pre-divisor should be OK.> I see Analog Devices has DDS chips up to 48 bits, so 36 bits would not > be a problem (except for cost maybe). > > But al of the DDS chips I find from Analog seem only to implement a > fixed sine table/function. Do DDS chips exist that allow downloading an > arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each? > > If no such standard chips exist, I expect I need to implement the DDS > in an FPGA. Using a smaller accumulator would probably save some space > in the FPGA. Or am I just optoimizing prematurely?If you go for 25 MHz DAC clock your DDS should be doable using sufficiently fast processor. My rough guesstimate is that to produce single sample (addjust phase accumulator, extract bits and copy value) you need about 10 machine instructions, so 250 MIPS processor should be fast enough to generate samples. You probably need a DMA channel to transmit them to DAC. I am not aware of processor with fast enough DAC, but I think that there are processors capable of driving external DAC at that speed. OTOH with 12 MHz signal and 25 MHz DAC clock you essentially are limited to sinusoidal signals, to have more variety you need more samples per period, so either lower signal frequency or higher DAC clock. So you may end up with much higher DAC freqency and censequenty be forced to use FPGA. As I wrote earler, skimming bits on phase accumulator seems unwise, it is at most one instruction in critical loop in CPU realization and has _much_ smaller impact on FPGA (think about size of your tables, single counter is tiny compared to that). -- Waldek Hebisch
Reply by ●August 17, 20222022-08-17
On Wednesday, August 17, 2022 at 7:36:42 AM UTC-4, Stef wrote:> On 2022-08-17 gnuarm.del...@gmail.com wrote in comp.arch.fpga: > > On Tuesday, August 16, 2022 at 11:37:41 AM UTC-4, Stef wrote: > >> To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS > >> a minimum clock of >24, say 25 MHz, is required. To be able to go down > >> to 0.5 mHz, a phase accumulator of at least 36 bits is required. This > >> will give sub mHz resolution over the entire range. Nice for the low > >> frequencies, but not of much use for MHz frequencies (in this > >> application). > >> > >> Is there any objection to using a smaller phase accumulator and a clock > >> pre-scaler to generate the lower frequencies? > > > > There is a STRONG objection to shortening the phase word. It will cause problems with close in spurs (which can't be filtered) and reduces your resolution. See below. > > > > Instead of a pre-scaler, use a post divider. A pre-scaler on the clock to the DDS requires the analog filter to be adjusted to suit. > > > Ah yes, changing the clock would require adjustment of the output > filter. Not something you would want to do. > > How would you post-divide the (arbitrary waveform) output? Or do you > mean something else with the post-divide? > > > >> I see Analog Devices has DDS chips up to 48 bits, so 36 bits would not > >> be a problem (except for cost maybe). > >> > >> But al of the DDS chips I find from Analog seem only to implement a > >> fixed sine table/function. Do DDS chips exist that allow downloading an > >> arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each? > > > > If you are looking to generate a non-sine waveform, it is not needed, or useful. > Could you explain this? How would I generate an arbitrary waveform > without using a table?It's not without a table, but not one huge table, 2^n length where n is the number of phase bits. I described the process below.> >> If no such standard chips exist, I expect I need to implement the DDS > >> in an FPGA. Using a smaller accumulator would probably save some space > >> in the FPGA. Or am I just optoimizing prematurely? > > > > Do you work at Highland Technology? > No, I do not.Ok, someone there was inquiring about the exact same thing and often has one of his people enquire about such problems here when they potentially involve FPGAs. Sorry I mistook you for that.> > I've posted about an appropriate solution more than once in s.e.d. Here is a fair summary... > > > I don't read there, so missed that. But are you now talking about an > appropriate solution for a specific Highland Technology problem, or a > general solution?The DDS is general. A single sine table is fine if you have the memory for it. But you can do very well with numerical methods and much smaller tables as well.> > A 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 and a good filter after the DAC. It is important to NOT shorten the phase word as that introduces spurs close to the frequency being generated, which can not be filtered out. This is because the truncation of the phase word creates discontinuities which show up as close in spurs. Keep the phase word long and round the sine output to suit a 16 bit DAC. This generates harmonics which are much easier to filter. > > > > You don't need to use a single large table for the sine. sin(a+b) = sin(a)cos(b) + cos(a)sin(b), where a is the msbs of the phase word and b is the lsbs. Use appropriately sized tables for sin(a), cos(b) and a single table for the product cos(a)sin(b). This is practical if (a) and (b) are each truncated a bit. Because sin(b) is always small, this term is always small and does not need to be calculated with full resolution on a and b. This product table also does not require the full word width. Three table lookups, one multiply and one add. > > > > A programmable divider then divides the top frequency by 2**N by counting up to a settable value. > > > > The top frequency can clock a final FF buffer register of your favorite technology to provide the actual pulse output with an appropriate jitter. > > > > The settings of 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 top frequency 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 produce one output pulse that is within the range of the two settings, the prior setting and the new setting. > > > > Does this make sense? > Not really. I don't need just a sin(a+b) signal, I need to implement > arbitrary (not realy arbitrary, but various rather complex) waveforms. I > don't see how your solution will do this, unless I totally misunderstood > it.Ok, if you need an AWG, then you need a large memory. Your original post didn't seem to mention that. It only talked about sine waves.> > Feel free to drop my name with your boss. > I can do that, but I doubt it it will ring a bell, even with your full > name. I believe we live on different continents, so I don't think we > have ever met.Sorry, I was mistaken thinking you worked at Highland Tech. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
Reply by ●August 17, 20222022-08-17
On Wednesday, August 17, 2022 at 3:14:44 PM UTC-4, anti...@math.uni.wroc.pl wrote:> In comp.arch.embedded Stef <m...@this.is.invalid> wrote: > > To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS > > a minimum clock of >24, say 25 MHz, is required. To be able to go down > > to 0.5 mHz, a phase accumulator of at least 36 bits is required. This > > will give sub mHz resolution over the entire range. Nice for the low > > frequencies, but not of much use for MHz frequencies (in this > > application). > > > > Is there any objection to using a smaller phase accumulator and a clock > > pre-scaler to generate the lower frequencies? > Well, your frequency will be less accurate. To see this let me > derive formula for DDS. Let t be DAC clock, T be period of desired > signal and assume that we have N samples at uniformly distributed > points. At n-th tick of DAC clock real time is nt. In the > scale of desired signal this corresponds to nt/T. To get > position within period we drop integer part of this, that is > take frac(nt/T). Then we need to round to closest sample point. > Actually instead of rounding we can multiply by N, add 0.5 as > bias and take integer part. So, sample index is: > > [N frac(nt/T) + 0.5] > > where [ ] denotes integer part. Assuming that N is power of 2, > say 2^m and all arthmetic is in fixed point binary frac above > is equvalent to dropping high bits, leaving only m bits before > binary point. Integer part means dropping bits after bianary > points. So formula simplified to > > [nNt/T + 0.5] = [n*a + b] > > where a = Nt/T and b = 0.5 is time shift. Note that taking > > phi_n = n*a + b > > we have phi_{n+1} = (n+1)*a + b = a + phi_n so single addition > is enough to adjust phase. What is effect of using smaller > number of bits to represent phase phi_n? Well, b needs only > 1 bit, so if Nt/T fits into k bits with k bigger than m + 1, > then calculation using k bits gives exactly the same result > as calculation using infinite precision. In other words, > using k bits we get exact result but possibly for wrong > frequency. > > In general acceptable frequency error depends on application. > But since good analog components are more expensive than > digital ones, simple heuristic says that resuluting of > phase accumulator should not degrade accuracy of > oscilator. Assuming few ppm quartz oscilator as source > of DAC clock, this means that we need about 20 significant > bits in parameter a. OTOH, at moderate freqences we do not > want to make big jumps, so parameter a should have m or more > zero bits at start. With m = 10 we arrive at 30 bits. Add > some margin for users that want slightly better results and > we arrive at 36 bits. In fact, if you want 0.5 mHz without > divisor on DAC clock you will have about 35 zero bits > at start of paramter a, so 55 bits phase accumultor would > be more appropriate. However, in in few hundreds Hertz > range and below pre-divisor on DAC clock seem quite > appropriate, so 36 bits + pre-divisor should be OK. > > I see Analog Devices has DDS chips up to 48 bits, so 36 bits would not > > be a problem (except for cost maybe). > > > > But al of the DDS chips I find from Analog seem only to implement a > > fixed sine table/function. Do DDS chips exist that allow downloading an > > arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each? > > > > If no such standard chips exist, I expect I need to implement the DDS > > in an FPGA. Using a smaller accumulator would probably save some space > > in the FPGA. Or am I just optoimizing prematurely? > If you go for 25 MHz DAC clock your DDS should be doable using > sufficiently fast processor. My rough guesstimate is that > to produce single sample (addjust phase accumulator, extract > bits and copy value) you need about 10 machine instructions, > so 250 MIPS processor should be fast enough to generate > samples. You probably need a DMA channel to transmit them > to DAC. I am not aware of processor with fast enough DAC, > but I think that there are processors capable of driving > external DAC at that speed. > > OTOH with 12 MHz signal and 25 MHz DAC clock you essentially > are limited to sinusoidal signals, to have more variety > you need more samples per period, so either lower signal > frequency or higher DAC clock. So you may end up with > much higher DAC freqency and censequenty be forced to > use FPGA. > > As I wrote earler, skimming bits on phase accumulator seems > unwise, it is at most one instruction in critical loop > in CPU realization and has _much_ smaller impact on > FPGA (think about size of your tables, single counter > is tiny compared to that).In sine generation, it is often used in applications where spurs need to be minimized. A filter is good for a sine wave, but is limited on removing close in spurs. Truncation of the phase word (even just as an input to the sine generator) creates spurs close to the fundamental. It essentially creates phase discontinuities that manifest as close in spurs. These are virtually unfilterable. If jitter or close in spurs are not important, then shortening the phase word has other obvious limitations that can be evaluated readily. -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
Reply by ●August 17, 20222022-08-17
On Wednesday, August 17, 2022 at 10:20:09 PM UTC-4, gnuarm.del...@gmail.com wrote:> On Wednesday, August 17, 2022 at 7:36:42 AM UTC-4, Stef wrote: > > On 2022-08-17 gnuarm.del...@gmail.com wrote in comp.arch.fpga: > > > On Tuesday, August 16, 2022 at 11:37:41 AM UTC-4, Stef wrote: > > >> To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS > > >> a minimum clock of >24, say 25 MHz, is required. To be able to go down > > >> to 0.5 mHz, a phase accumulator of at least 36 bits is required. This > > >> will give sub mHz resolution over the entire range. Nice for the low > > >> frequencies, but not of much use for MHz frequencies (in this > > >> application). > > >> > > >> Is there any objection to using a smaller phase accumulator and a clock > > >> pre-scaler to generate the lower frequencies? > > > > > > There is a STRONG objection to shortening the phase word. It will cause problems with close in spurs (which can't be filtered) and reduces your resolution. See below. > > > > > > Instead of a pre-scaler, use a post divider. A pre-scaler on the clock to the DDS requires the analog filter to be adjusted to suit. > > > > > Ah yes, changing the clock would require adjustment of the output > > filter. Not something you would want to do. > > > > How would you post-divide the (arbitrary waveform) output? Or do you > > mean something else with the post-divide? > > > > > >> I see Analog Devices has DDS chips up to 48 bits, so 36 bits would not > > >> be a problem (except for cost maybe). > > >> > > >> But al of the DDS chips I find from Analog seem only to implement a > > >> fixed sine table/function. Do DDS chips exist that allow downloading an > > >> arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each? > > > > > > If you are looking to generate a non-sine waveform, it is not needed, or useful. > > Could you explain this? How would I generate an arbitrary waveform > > without using a table? > It's not without a table, but not one huge table, 2^n length where n is the number of phase bits. I described the process below.Opps, to correct myself... 2^(n-2) length table if you take advantage of the folding properties of the sine function.> > >> If no such standard chips exist, I expect I need to implement the DDS > > >> in an FPGA. Using a smaller accumulator would probably save some space > > >> in the FPGA. Or am I just optoimizing prematurely? > > > > > > Do you work at Highland Technology? > > No, I do not. > Ok, someone there was inquiring about the exact same thing and often has one of his people enquire about such problems here when they potentially involve FPGAs. Sorry I mistook you for that. > > > I've posted about an appropriate solution more than once in s.e.d. Here is a fair summary... > > > > > I don't read there, so missed that. But are you now talking about an > > appropriate solution for a specific Highland Technology problem, or a > > general solution? > The DDS is general. A single sine table is fine if you have the memory for it. But you can do very well with numerical methods and much smaller tables as well. > > > A 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 and a good filter after the DAC. It is important to NOT shorten the phase word as that introduces spurs close to the frequency being generated, which can not be filtered out. This is because the truncation of the phase word creates discontinuities which show up as close in spurs. Keep the phase word long and round the sine output to suit a 16 bit DAC. This generates harmonics which are much easier to filter. > > > > > > You don't need to use a single large table for the sine. sin(a+b) = sin(a)cos(b) + cos(a)sin(b), where a is the msbs of the phase word and b is the lsbs. Use appropriately sized tables for sin(a), cos(b) and a single table for the product cos(a)sin(b). This is practical if (a) and (b) are each truncated a bit. Because sin(b) is always small, this term is always small and does not need to be calculated with full resolution on a and b. This product table also does not require the full word width. Three table lookups, one multiply and one add. > > > > > > A programmable divider then divides the top frequency by 2**N by counting up to a settable value. > > > > > > The top frequency can clock a final FF buffer register of your favorite technology to provide the actual pulse output with an appropriate jitter. > > > > > > The settings of 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 top frequency 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 produce one output pulse that is within the range of the two settings, the prior setting and the new setting. > > > > > > Does this make sense? > > Not really. I don't need just a sin(a+b) signal, I need to implement > > arbitrary (not realy arbitrary, but various rather complex) waveforms. I > > don't see how your solution will do this, unless I totally misunderstood > > it. > Ok, if you need an AWG, then you need a large memory. Your original post didn't seem to mention that. It only talked about sine waves. > > > Feel free to drop my name with your boss. > > I can do that, but I doubt it it will ring a bell, even with your full > > name. I believe we live on different continents, so I don't think we > > have ever met. > Sorry, I was mistaken thinking you worked at Highland Tech.-- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
Reply by ●August 18, 20222022-08-18
On 2022-08-17 antispam@math.uni.wroc.pl wrote in comp.arch.embedded:> In comp.arch.embedded Stef <me@this.is.invalid> wrote: >> To generate frequencies from approximately 0.5 mHz to 12 MHz with a DDS >> a minimum clock of >24, say 25 MHz, is required. To be able to go down >> to 0.5 mHz, a phase accumulator of at least 36 bits is required. This >> will give sub mHz resolution over the entire range. Nice for the low >> frequencies, but not of much use for MHz frequencies (in this >> application). >> >> Is there any objection to using a smaller phase accumulator and a clock >> pre-scaler to generate the lower frequencies? > > Well, your frequency will be less accurate. To see this let me > derive formula for DDS.<snip detailed DDS math>>> >> If no such standard chips exist, I expect I need to implement the DDS >> in an FPGA. Using a smaller accumulator would probably save some space >> in the FPGA. Or am I just optoimizing prematurely? > > If you go for 25 MHz DAC clock your DDS should be doable using > sufficiently fast processor. My rough guesstimate is that > to produce single sample (addjust phase accumulator, extract > bits and copy value) you need about 10 machine instructions, > so 250 MIPS processor should be fast enough to generate > samples. You probably need a DMA channel to transmit them > to DAC. I am not aware of processor with fast enough DAC, > but I think that there are processors capable of driving > external DAC at that speed.That is assuming the processor has not much else to do and that only a single DDS channel is required. Both will not be true in the possible application, I'm affraid. The additional DDS channels can be a bit slower, so it may still be doable.> OTOH with 12 MHz signal and 25 MHz DAC clock you essentially > are limited to sinusoidal signals, to have more variety > you need more samples per period, so either lower signal > frequency or higher DAC clock. So you may end up with > much higher DAC freqency and censequenty be forced to > use FPGA.Yes, this is understood. Read the 10 MHz as bandwidth, not as the max frequency at which a complex waveform should be generated. So the waveform will degrade to a sine when sped up to 10 MHz.> As I wrote earler, skimming bits on phase accumulator seems > unwise, it is at most one instruction in critical loop > in CPU realization and has _much_ smaller impact on > FPGA (think about size of your tables, single counter > is tiny compared to that).FPGA have memory blocks to hold such tables. A simple ripple counter will indeed take a tiny amount of logic, a synchronous counter will take more, certainly at 55 bits. But I think you need an adder if you want variable accumulator steps and not only +1. Keeping the adder small enough to fit in something like a 48-bit DSP slice will probably save space. The above is probably quite Xilinx specific, as that is the last FPGA I have experience with. And even that was a while ago. But again, I may be worrying too much about space already. When it comes to it, I should first implement the 'best' solution. And then probably find that this uses less than 10% of my FPGA. :-) -- Stef Don't shout for help at night. You might wake your neighbors. -- Stanislaw J. Lem, "Unkempt Thoughts"
Reply by ●August 18, 20222022-08-18
On 2022-08-18 gnuarm.del...@gmail.com wrote in comp.arch.fpga:> On Wednesday, August 17, 2022 at 7:36:42 AM UTC-4, Stef wrote: >> On 2022-08-17 gnuarm.del...@gmail.com wrote in comp.arch.fpga: >> > On Tuesday, August 16, 2022 at 11:37:41 AM UTC-4, Stef wrote:<snip>>> >> But al of the DDS chips I find from Analog seem only to implement a >> >> fixed sine table/function. Do DDS chips exist that allow downloading an >> >> arbitrary lookup table with 2^10 - 2^16 entries of 10 - 16 bit each?'Hidden' AWG hint.>> > If you are looking to generate a non-sine waveform, it is not needed, or useful. >> Could you explain this? How would I generate an arbitrary waveform >> without using a table? > > It's not without a table, but not one huge table, 2^n length where n is the number of phase bits. I described the process below. > > >> >> If no such standard chips exist, I expect I need to implement the DDS >> >> in an FPGA. Using a smaller accumulator would probably save some space >> >> in the FPGA. Or am I just optoimizing prematurely? >> > >> > Do you work at Highland Technology? >> No, I do not. > > Ok, someone there was inquiring about the exact same thing and often has one of his people enquire about such problems here when they potentially involve FPGAs. Sorry I mistook you for that.I suspected something like this was the case, no problem. :-)> >> > I've posted about an appropriate solution more than once in s.e.d. Here is a fair summary... >> > >> I don't read there, so missed that. But are you now talking about an >> appropriate solution for a specific Highland Technology problem, or a >> general solution? > > The DDS is general. A single sine table is fine if you have the memory for it. But you can do very well with numerical methods and much smaller tables as well.Yes DDS is general. But your method seemed to be aimed specifically at a certain problem. But if I understand you correctly, the method you describe is a general solution to generate sine waves without large tables? <snip>> Ok, if you need an AWG, then you need a large memory. Your original post didn't seem to mention that. It only talked about sine waves.Re-reading my original post, I see that was a bit hidden in the text and may not have been clear to a reader not familiar with the application. Sorry about that.> >> > Feel free to drop my name with your boss. >> I can do that, but I doubt it it will ring a bell, even with your full >> name. I believe we live on different continents, so I don't think we >> have ever met. > > Sorry, I was mistaken thinking you worked at Highland Tech.I thought you might have. ;-) -- Stef Hey, I had to let awk be better at *something*... :-) -- Larry Wall in <1991Nov7.200504.25280@netlabs.com>1
Reply by ●August 18, 20222022-08-18
On Thursday, August 18, 2022 at 4:21:50 AM UTC-4, Stef wrote:> On 2022-08-17 anti...@math.uni.wroc.pl wrote in comp.arch.embedded:=20 > > In comp.arch.embedded Stef <m...@this.is.invalid> wrote:=20 > >> To generate frequencies from approximately 0.5 mHz to 12 MHz with a DD=S=20> >> a minimum clock of >24, say 25 MHz, is required. To be able to go down==20> >> to 0.5 mHz, a phase accumulator of at least 36 bits is required. This==20> >> will give sub mHz resolution over the entire range. Nice for the low==20> >> frequencies, but not of much use for MHz frequencies (in this=20 > >> application).=20 > >>=20 > >> Is there any objection to using a smaller phase accumulator and a cloc=k=20> >> pre-scaler to generate the lower frequencies?=20 > >=20 > > Well, your frequency will be less accurate. To see this let me=20 > > derive formula for DDS. > <snip detailed DDS math> > >>=20 > >> If no such standard chips exist, I expect I need to implement the DDS==20> >> in an FPGA. Using a smaller accumulator would probably save some space==20> >> in the FPGA. Or am I just optoimizing prematurely?=20 > >=20 > > If you go for 25 MHz DAC clock your DDS should be doable using=20 > > sufficiently fast processor. My rough guesstimate is that=20 > > to produce single sample (addjust phase accumulator, extract=20 > > bits and copy value) you need about 10 machine instructions,=20 > > so 250 MIPS processor should be fast enough to generate=20 > > samples. You probably need a DMA channel to transmit them=20 > > to DAC. I am not aware of processor with fast enough DAC,=20 > > but I think that there are processors capable of driving=20 > > external DAC at that speed. > That is assuming the processor has not much else to do and that only a=20 > single DDS channel is required. Both will not be true in the possible=20 > application, I'm affraid. The additional DDS channels can be a bit=20 > slower, so it may still be doable.You keep calling it a DDS, which apparently is correct in that it can be us= ed generically. But conventionally this refers to generating a sine wave. = The term, AWG (Arbitrary Waveform Generator) is more commonly used for wha= t you are doing.=20> > OTOH with 12 MHz signal and 25 MHz DAC clock you essentially=20 > > are limited to sinusoidal signals, to have more variety=20 > > you need more samples per period, so either lower signal=20 > > frequency or higher DAC clock. So you may end up with=20 > > much higher DAC freqency and censequenty be forced to=20 > > use FPGA. > Yes, this is understood. Read the 10 MHz as bandwidth, not as the max=20 > frequency at which a complex waveform should be generated. So the=20 > waveform will degrade to a sine when sped up to 10 MHz. > > As I wrote earler, skimming bits on phase accumulator seems=20 > > unwise, it is at most one instruction in critical loop=20 > > in CPU realization and has _much_ smaller impact on=20 > > FPGA (think about size of your tables, single counter=20 > > is tiny compared to that). > FPGA have memory blocks to hold such tables. A simple ripple counter=20 > will indeed take a tiny amount of logic, a synchronous counter will take==20> more, certainly at 55 bits. But I think you need an adder if you want=20 > variable accumulator steps and not only +1. Keeping the adder small=20 > enough to fit in something like a 48-bit DSP slice will probably save=20 > space.=20Ripple or synchronous would be the same, 1 FF and 1 LUT per bit. That's as= suming an FPGA that supports addition in the LUT/FF cell, which most do. E= ven if your increment is +1, that uses the same logic because it's still 1 = LUT. Of course, if you have other inputs, such as an enable or add/sub> The above is probably quite Xilinx specific, as that is the last FPGA I==20> have experience with. And even that was a while ago.=20 >=20 > But again, I may be worrying too much about space already. When it comes==20> to it, I should first implement the 'best' solution. And then probably=20 > find that this uses less than 10% of my FPGA. :-)=20Yes, unless you have *a lot* going on in the FPGA, you won't need to worry = about a 55 bit counter, running at 50 MHz. It won't be significant in your= greater design.=20 --=20 Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
