XPost: comp.arch.fpga

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, August 16, 2022 at 11:37:42 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?

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?

See my response in comp.arch.fpga

--

Rick C.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.arch.fpga

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.arch.fpga

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)