Spectral Purity Measurement

[HpW-Works]

Am 19.12.2014 15:24, schrieb Tim Wescott:

No spectrum analyzer in the world has a 240dB dynamic
range

Hmm, yes analog based on the todays ADC limitations O

My PC based spectrum analyser supports more then an 240dB dynamic range,
while internal calculations are done using double float and even 80 bit
float O

Hp

www.hpw-works.com

 

[chrisabele]

On 12/21/2014 1:28 AM, rickman wrote:
<snip>

I understand there are open source
packages similar to Matlab. I may try using one of these.

snip

I've found Scilab (http://www.scilab.org/) to be a very functional and
well supported alternative to Matlab, at a compelling price point (free).

 

[Gerhard Hoffmann]

Am 21.12.2014 um 05:33 schrieb Allan Herriman:

On Sat, 20 Dec 2014 19:43:33 +0000, glen herrmannsfeldt wrote:

In comp.dsp Allan Herriman <allanherriman@hotmail.com> wrote:

1. Generate an "ideal" reference waveform. Use floating point
(but use it carefully).

My choice would be fixed point.

With fixed point, you know exactly how the rounding is done, and it is
done independent of the size of the values at any point in the
computation. You could, for example, use 64 bit fixed point instead of
64 bit floating point.

Rickman appears to be writing a testbench in VHDL. If that is the case,
he already has double precision floating point trig functions built in to
his simulator (in package ieee.math_real). To use fixed point would be
to reimplement and verify the trig functions from scratch - a task that
is possibly harder than the original problem he is trying to solve.

The test bed for my sine & cos functions on opencores can write
the time series generated by a DDS to a file that could be used
for further processing with matlab or whatever.

There are also functions to convert between float and un/signed
and fractional un/signed. They expect however, that
the floats are higher resolution than the signed vectors, they
will cease to work when one approaches 48 bit or whatever the
size of the mantissa happens to be.

Going via int/natural would be even more limiting (31 bit).

regards, Gerhard

< http://opencores.org/project,sincos >

 

[rickman]

On 12/21/2014 11:11 AM, Gerhard Hoffmann wrote:

Am 21.12.2014 um 05:33 schrieb Allan Herriman:
On Sat, 20 Dec 2014 19:43:33 +0000, glen herrmannsfeldt wrote:

In comp.dsp Allan Herriman <allanherriman@hotmail.com> wrote:

1. Generate an "ideal" reference waveform. Use floating point
(but use it carefully).

My choice would be fixed point.

With fixed point, you know exactly how the rounding is done, and it is
done independent of the size of the values at any point in the
computation. You could, for example, use 64 bit fixed point instead of
64 bit floating point.

Rickman appears to be writing a testbench in VHDL. If that is the case,
he already has double precision floating point trig functions built in to
his simulator (in package ieee.math_real). To use fixed point would be
to reimplement and verify the trig functions from scratch - a task that
is possibly harder than the original problem he is trying to solve.

The test bed for my sine & cos functions on opencores can write
the time series generated by a DDS to a file that could be used
for further processing with matlab or whatever.

There are also functions to convert between float and un/signed
and fractional un/signed. They expect however, that
the floats are higher resolution than the signed vectors, they
will cease to work when one approaches 48 bit or whatever the
size of the mantissa happens to be.

Going via int/natural would be even more limiting (31 bit).

regards, Gerhard

http://opencores.org/project,sincos

Thanks, I'll take a look.

--

Rick

 

[robert bristow-johnson]

On 12/19/14 11:04 PM, Eric Jacobsen wrote:

On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

anyway, in either case, the oscillator frequency is well defined and i
don't understand why rickman would just put in a simple sharp notch
filter tuned to the very same frequency and whack the sinusoid and
analyze (however he does) what is residual.




--

r b-j rbj@audioimagination.com

"Imagination is more important than knowledge."

 

[Tim Wescott]

On Sun, 21 Dec 2014 11:03:38 +0000, Allan Herriman wrote:

On Sun, 21 Dec 2014 01:28:00 -0500, rickman wrote:

A reasonable assumption although I couldn't find info that said that
reals were double precision (64 bit). In fact, the info I found said
they are only assured to be 32 bit, single precision. Is that wrong?

That's a good point. It's implementation dependent.

The old version of Modelsim that I have on this computer has this in the
source for the std library:

type real is range -1.0E308 to 1.0E308;

which is equivalent to 64 bit "double". I don't imagine that any
mainstream compiler would use less than 64 bits for real, but I could be
wrong.
OTOH, if you know that all the compilers you're using support 64 bit,
it's probably safe to rely on that.

If by "compiler" you mean VHDL, I can't speak to that.

However, there are a distressingly large number of C compilers for 8- and
16-bit machines that use 32-bit floating point even when you call out
"double".

This just torques me. While there is every reason for making
comprehensive libraries that work with 32-bit floating point numbers in
resource-constrained machines, you don't have to make non-ANSI-compliant
code to do it.

--
www.wescottdesign.com

 

[Tim Wescott]

On Sun, 21 Dec 2014 09:49:42 -0500, chrisabele wrote:

On 12/21/2014 1:28 AM, rickman wrote:
snip

I understand there are open source packages similar to Matlab. I may
try using one of these.

snip

I've found Scilab (http://www.scilab.org/) to be a very functional and
well supported alternative to Matlab, at a compelling price point
(free).

+1 on using Scilab, at least if you were incorrect on your 240dBc
calculation. At this point, I would prefer Scilab even if it were priced
the same as Matlab. It doesn't have Matlab's bells and whistle's, but it
does edge Matlab out in git-er-done utility.

--
www.wescottdesign.com

 

[Eric Jacobsen]

On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
<rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

anyway, in either case, the oscillator frequency is well defined and i
don't understand why rickman would just put in a simple sharp notch
filter tuned to the very same frequency and whack the sinusoid and
analyze (however he does) what is residual.

It could be because the phase accumulator/LUT architecture is general
and the range of operation of the output frequency is pretty broad.
A more generalized test approach is more flexible to testing over a
broader range of outputs.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

 

[rickman]

On 12/21/2014 7:13 PM, Eric Jacobsen wrote:

On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

Actually this started with a discussion is s.e.d about how bad the spurs
are with a typical DDS and how to mitigate them. That made me dig up my
memory of designing a DDS a few years back as part of a test set. It
didn't need to be anything special, but for grins I took a look at what
could be done in a rather small FPGA for audio frequencies. I
considered linear interpolation which gets around the close in spurs
from phase truncation (seems to be the major objection to using a DDS)
and with even a smallish LUT of 256 entries I get about 18 bit accuracy
in the sine values. With a 1024 entry table the accuracy is more than
10 times better or around 21 bits.

Of course quantization error will add to that, but this allows the close
in spurs to be *much* smaller than with straight LUTs.

anyway, in either case, the oscillator frequency is well defined and i
don't understand why rickman would just put in a simple sharp notch
filter tuned to the very same frequency and whack the sinusoid and
analyze (however he does) what is residual.

It could be because the phase accumulator/LUT architecture is general
and the range of operation of the output frequency is pretty broad.
A more generalized test approach is more flexible to testing over a
broader range of outputs.

I'm not sure I understand the question, notwithstanding the grammar
error. I think Robert meant "i don't understand why rickman
>>wouldn't<< just put in"...

I don't know why I wouldn't do that either. I am here asking what would
be the best way.

I seem to remember something similar being done in a digital receiver
test. A carrier is applied to the analog input and in the digital
domain (somewhere) a notch filter is used to drop out the carrier
leaving most of the artifacts. It's all very fuzzy at this point. I
think they also used a two tone test which shows the effects of
inter-modulation products, a real concern with real signals.

--

Rick

 

[Eric Jacobsen]

On Sun, 21 Dec 2014 19:30:48 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/21/2014 7:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

Actually this started with a discussion is s.e.d about how bad the spurs
are with a typical DDS and how to mitigate them. That made me dig up my
memory of designing a DDS a few years back as part of a test set. It
didn't need to be anything special, but for grins I took a look at what
could be done in a rather small FPGA for audio frequencies. I
considered linear interpolation which gets around the close in spurs
from phase truncation (seems to be the major objection to using a DDS)
and with even a smallish LUT of 256 entries I get about 18 bit accuracy
in the sine values. With a 1024 entry table the accuracy is more than
10 times better or around 21 bits.

Of course quantization error will add to that, but this allows the close
in spurs to be *much* smaller than with straight LUTs.


anyway, in either case, the oscillator frequency is well defined and i
don't understand why rickman would just put in a simple sharp notch
filter tuned to the very same frequency and whack the sinusoid and
analyze (however he does) what is residual.

It could be because the phase accumulator/LUT architecture is general
and the range of operation of the output frequency is pretty broad.
A more generalized test approach is more flexible to testing over a
broader range of outputs.

I'm not sure I understand the question, notwithstanding the grammar
error. I think Robert meant "i don't understand why rickman
wouldn't<< just put in"...

I don't know why I wouldn't do that either. I am here asking what would
be the best way.

I seem to remember something similar being done in a digital receiver
test. A carrier is applied to the analog input and in the digital
domain (somewhere) a notch filter is used to drop out the carrier
leaving most of the artifacts. It's all very fuzzy at this point. I
think they also used a two tone test which shows the effects of
inter-modulation products, a real concern with real signals.

--

Rick

Do a web search on "Analog Devices DDS", and in the first few entries
you should find links to some white papers that are good on details of
DDS architecture and analysis. Also, Qualcomm's "Synthesizer
Products Data Book" is also very good. Some of those documents are
from the 90s, and there are other public docs out there that go into
more detail on spur mitigation and analysis, but these are good
references.

BTW, Qualcomm was a leader in supplying stand-alone silicon DDS
products, which were called by the name DDS, even though they didn't
have an integrated DAC. Back then mixed-signal products weren't
really available.

For implementations where memory is very constrained, like potentially
in an FPGA, the phase resolution in the LUT can be increased 4x by
only storing a quarter of the wave. We've done this in the past with
good results.

DDS implementations can sometimes also benefit from dithering, at the
outputs of both the phase accumulator and the LUT, although the usual
tradeoffs apply.

There are a number of tricks that have been learned over the years,
and many are application dependent. e.g., different tricks may apply
for generating a low-jitter clock than generating a local oscillator.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

 

[Rob Doyle]

On 12/21/2014 5:13 PM, Eric Jacobsen wrote:

On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They pipeline
nicely and are therefore very fast, they require no multipliers [1],
they generate quadrature outputs for free, they can perform frequency
translations for free (again no multipliers), and they are simple prove
numerical accuracy.

[1] Maybe not a huge issue these days. The LUT-based NCOs requires two
multipliers to combine the coarse and fine LUTs (four multipliers if you
need a complex NCO output) and perhaps another four multipliers if you
need to do a frequency translation.

Rob.

anyway, in either case, the oscillator frequency is well defined and i
don't understand why rickman would just put in a simple sharp notch
filter tuned to the very same frequency and whack the sinusoid and
analyze (however he does) what is residual.

It could be because the phase accumulator/LUT architecture is general
and the range of operation of the output frequency is pretty broad.
A more generalized test approach is more flexible to testing over a
broader range of outputs.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

 

[robert bristow-johnson]

On 12/21/14 7:30 PM, rickman wrote:

On 12/21/2014 7:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

....
anyway, in either case, the oscillator frequency is well defined and i
don't understand why rickman would just put in a simple sharp notch
filter tuned to the very same frequency and whack the sinusoid and
analyze (however he does) what is residual.

It could be because the phase accumulator/LUT architecture is general
and the range of operation of the output frequency is pretty broad.
A more generalized test approach is more flexible to testing over a
broader range of outputs.

I'm not sure I understand the question, notwithstanding the grammar
error. I think Robert meant "i don't understand why rickman >>wouldn't
just put in"...

abstively correct. i often suffer from the "Wicked Bible" syndrome.

I don't know why I wouldn't do that either. I am here asking what would
be the best way.

I seem to remember something similar being done in a digital receiver
test. A carrier is applied to the analog input and in the digital domain
(somewhere) a notch filter is used to drop out the carrier leaving most
of the artifacts. It's all very fuzzy at this point. I think they also
used a two tone test which shows the effects of inter-modulation
products, a real concern with real signals.

okay, let's say that you have N points in your LUT. (if N is a power of
two, the table wrap-around is trivial.) and let's say that there is a
single cycle of a sine function in that LUT. and let's say your sample
rate is Fs. the phase increment for a frequency of f0 would be

phase_increment = N*(f0/Fs)

every sample the phase is incremented:

phase[n] = (phase[n-1] + phase_increment)modulo_N

and phase[n] is divided into its integer part that tells you where to go
in your LUT and a fractional part that tells you how you might interpolate.

integer_part = floor(phase[n])

fractional_part = phase[n] - integer_part

if you're doing no interpolation the waveform output is

x[n] = LUT[integer_part]

if you're doing linear interpolation the waveform output is

x[n] = LUT[integer_part]
+ fractional_part*(LUT[integer_part+1] - LUT[integer_part])

just make sure you have an extra point at the end of your LUT that is
the same as the zeroth point:

LUT[N] = LUT[0]


now, using that very same f0 and Fs and some Q or BW that you'll have to
decide (make the BW sorta tight), then implement a very simple biquad
notch filter:


y[n] = b0*x[n] + b1*x[n-1] + b2*x[n-2] - a1*y[n-1] - a2*y[n-2]

where

b0 = b2 = 1/( 1 + sin(w0)/(2Q) )
b1 = a1 = -2*cos(w0)/(1 + sin(w0)/(2Q))
a2 = ( 1 - sin(w0)/(2Q) )/( 1 + sin(w0)/(2Q) )

and

w0 = 2*pi*f0/Fs

1/Q = 2*sinh( ln(2)/2 * BW * w0/sin(w0) ) (BW in octaves)


straight outa da cookbook.


whatever comes out at y[n] is whatever is impure in your sinusoidal output.



--

r b-j rbj@audioimagination.com

"Imagination is more important than knowledge."

 

[Eric Jacobsen]

On Mon, 22 Dec 2014 15:17:23 -0700, Rob Doyle <radioengr@gmail.com>
wrote:

On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They pipeline
nicely and are therefore very fast, they require no multipliers [1],
they generate quadrature outputs for free, they can perform frequency
translations for free (again no multipliers), and they are simple prove
numerical accuracy.

CORDICs are fine when and where they make sense, but they are often
not the best tradeoff. If you have no memory, no multipliers, or
gates are way cheaper than memory, and if the latency is tolerable,
then a CORDIC may be a good option.

Maybe not a huge issue these days. The LUT-based NCOs requires two
multipliers to combine the coarse and fine LUTs (four multipliers if you
need a complex NCO output) and perhaps another four multipliers if you
need to do a frequency translation.

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

As is often the case, there are many ways to get the job done.
Sometimes the complications aren't necessary, they're just convenient.

Rob.

anyway, in either case, the oscillator frequency is well defined and i
don't understand why rickman would just put in a simple sharp notch
filter tuned to the very same frequency and whack the sinusoid and
analyze (however he does) what is residual.

It could be because the phase accumulator/LUT architecture is general
and the range of operation of the output frequency is pretty broad.
A more generalized test approach is more flexible to testing over a
broader range of outputs.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

 

[rickman]

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:

On Mon, 22 Dec 2014 15:17:23 -0700, Rob Doyle <radioengr@gmail.com
wrote:

On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They pipeline
nicely and are therefore very fast, they require no multipliers [1],
they generate quadrature outputs for free, they can perform frequency
translations for free (again no multipliers), and they are simple prove
numerical accuracy.

CORDICs are fine when and where they make sense, but they are often
not the best tradeoff. If you have no memory, no multipliers, or
gates are way cheaper than memory, and if the latency is tolerable,
then a CORDIC may be a good option.

[1] Maybe not a huge issue these days. The LUT-based NCOs requires two
multipliers to combine the coarse and fine LUTs (four multipliers if you
need a complex NCO output) and perhaps another four multipliers if you
need to do a frequency translation.

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

As is often the case, there are many ways to get the job done.
Sometimes the complications aren't necessary, they're just convenient.

Yes, there is more than one way to skin a goose. But they all have
their issues.

CORDIC for example, has no multiplier... but has an iteration that is
essentially the same as multiplication by iteration.

--

Rick

 

[Eric Jacobsen]

On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:
On Mon, 22 Dec 2014 15:17:23 -0700, Rob Doyle <radioengr@gmail.com
wrote:

On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They pipeline
nicely and are therefore very fast, they require no multipliers [1],
they generate quadrature outputs for free, they can perform frequency
translations for free (again no multipliers), and they are simple prove
numerical accuracy.

CORDICs are fine when and where they make sense, but they are often
not the best tradeoff. If you have no memory, no multipliers, or
gates are way cheaper than memory, and if the latency is tolerable,
then a CORDIC may be a good option.

[1] Maybe not a huge issue these days. The LUT-based NCOs requires two
multipliers to combine the coarse and fine LUTs (four multipliers if you
need a complex NCO output) and perhaps another four multipliers if you
need to do a frequency translation.

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

Not sure what you're asking. You a need a LUT, but just one in many
cases. Having a dual-ported single LUT is easy in an FPGA and
usually in silicon as well.

What makes a multiplier necessary? I've never found the need, but my
apps are limited to comm.

As is often the case, there are many ways to get the job done.
Sometimes the complications aren't necessary, they're just convenient.

Yes, there is more than one way to skin a goose. But they all have
their issues.

CORDIC for example, has no multiplier... but has an iteration that is
essentially the same as multiplication by iteration.

Yup.

--

Rick

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

 

[rickman]

On 12/23/2014 4:48 PM, Eric Jacobsen wrote:

On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:
On Mon, 22 Dec 2014 15:17:23 -0700, Rob Doyle <radioengr@gmail.com
wrote:

On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They pipeline
nicely and are therefore very fast, they require no multipliers [1],
they generate quadrature outputs for free, they can perform frequency
translations for free (again no multipliers), and they are simple prove
numerical accuracy.

CORDICs are fine when and where they make sense, but they are often
not the best tradeoff. If you have no memory, no multipliers, or
gates are way cheaper than memory, and if the latency is tolerable,
then a CORDIC may be a good option.

[1] Maybe not a huge issue these days. The LUT-based NCOs requires two
multipliers to combine the coarse and fine LUTs (four multipliers if you
need a complex NCO output) and perhaps another four multipliers if you
need to do a frequency translation.

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

Not sure what you're asking. You a need a LUT, but just one in many
cases. Having a dual-ported single LUT is easy in an FPGA and
usually in silicon as well.

What makes a multiplier necessary? I've never found the need, but my
apps are limited to comm.

Maybe we aren't on the same page. The multiplier is there for the fine
adjustment. If you are happy with some -60 or -80 dB spurs one LUT is
fine. But if you want better performance the single LUT approach
requires *very* large tables.

--

Rick

 

[robert bristow-johnson]

this did not seem to get posted so i am reposting. sorry for any
repeated post.

On 12/22/14 5:17 PM, Rob Doyle wrote:

On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am wondering if
an FFT
is the best way to do this. I'm mainly concerned with the "close in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are the
differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)? or
can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and
with appropriate initial states, y[-1] and y[-2] to result in the
amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT, since
it is easily implemented in hardware. That's a general architecture
that is well-known and can be adjusted to produce very clean local
oscillators. If somebody tried to sell me a block of IP with an
"NCO" built some other way I'd be asking a lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They pipeline
nicely and are therefore very fast, they require no multipliers [1],

???

i don't s'pose Ray Andraka is hanging around (he was Dr. CORDIC here a
while back), but i always thought that CORDIC did essentially

x[n] = cos(2*pi*f0/Fs) * x[n-1] - sin(2*pi*f0/Fs) * y[n-1]
y[n] = sin(2*pi*f0/Fs) * x[n-1] + cos(2*pi*f0/Fs) * y[n-1]

or, as complex numbers:

(x[n] + j*y[n]) = exp(j*2*pi*f0/Fs) * (x[n-1] + j*y[n-1])

doesn't that require a few multiplications?

they generate quadrature outputs for free, they can perform frequency
translations for free (again no multipliers), and they are simple prove
numerical accuracy.

[1] Maybe not a huge issue these days. The LUT-based NCOs requires two
multipliers to combine the coarse and fine LUTs

even for linear interpolation? i think one multiplier is enough. the
higher order the interpolation, the more multipliers needed (and the
fewer points int he LUT are needed).

(four multipliers if you need a complex NCO output) and perhaps another
four multipliers if you need to do a frequency translation.

--

r b-j rbj@audioimagination.com

"Imagination is more important than knowledge."

 

[Rob Doyle]

On 12/23/2014 6:10 PM, robert bristow-johnson wrote:

this did not seem to get posted so i am reposting. sorry for any
repeated post.

On 12/22/14 5:17 PM, Rob Doyle wrote:
On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am
wondering if an FFT is the best way to do this. I'm
mainly concerned with the "close
in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are
the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase
accumulator)? or can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the
sinusoid and with appropriate initial states, y[-1] and y[-2]
to result in the amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be
LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT,
since it is easily implemented in hardware. That's a general
architecture that is well-known and can be adjusted to produce
very clean local oscillators. If somebody tried to sell me a
block of IP with an "NCO" built some other way I'd be asking a
lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They
pipeline nicely and are therefore very fast, they require no
multipliers [1],

???

i don't s'pose Ray Andraka is hanging around (he was Dr. CORDIC here
a while back), but i always thought that CORDIC did essentially

x[n] = cos(2*pi*f0/Fs) * x[n-1] - sin(2*pi*f0/Fs) * y[n-1]
y[n] = sin(2*pi*f0/Fs) * x[n-1] + cos(2*pi*f0/Fs) * y[n-1]

Yes. So far. So good. These are my notes if anyone is interested...

[snip]

Assume theta = 2*pi*f0*t/fs, i.e., theta is the output of a phase
accumulator for an NCO application.

Factor out the cos(theta):

x[n] = cos(theta) {x[n-1] - y[n-1] tan(theta)}
y[n] = cos(theta) {y[n-1] + x[n-1] tan(theta)}

If you select tan(theta) from the set of 1/(2**i) then [1] this becomes:

x[n] = cos(theta) {x[n-1] - y[n-1] / 2**i}
y[n] = cos(theta) {y[n-1] + x[n-1] / 2**i}

At this point you might be thinking "Holy crap. That's one heck of a
constraint!" Yeh... but keep reading anyway.

You can drop the cos(theta) common term. It's just a gain term that
rapidly converges to 1.647. Therefore the gain of a CORDIC is not 0 dB.

x[n] = x[n-1] - y[n-1] / 2**i
y[n] = y[n-1] + x[n-1] / 2**i

or (assuming twos complement math) - simply:

x[n] = x[n-1] - y[n-1] >> i
y[n] = y[n-1] + x[n-1] >> i

where >> is a shift right operation

[1] As this point it seems as if an *extreme* limitation has been placed
on the selection of rotation angles. The equation above only describes
how to rotate an input signal by tan(theta) = 1/(2**i) - or by one of
the following angles:

atan(1) (45.000000000000000000000000000000 degrees)
atan(1/2) (26.565051177077989351572193720453 degrees)
atan(1/4) (14.036243467926478582892320159163 degrees)
atan(1/8) (7.1250163489017975619533008412068 degrees)
atan(1/16) (3.5763343749973510306847789144588 degrees)
atan(1/32) (1.7899106082460693071502497760791 degrees)

....and so forth.

The equation above does not describe how to rotate an input signal an
arbitrary angle! Although this is true; all is not lost.

Notice that in general that theta/2 < tan(theta).

This truth allows the CORDIC to be used iteratively to rotate any input
to any angle with any precision. IMO this is the genius of the CORDIC.

I probably should have mentioned that you swap the rotation direction by
flipping the additions and subtractions.

The term z[n] is introduced to accumulate the angle as the CORDIC
iterates. The term d[n] swaps the direction of rotation. Finally the
familiar recursive CORDIC equation can be written as follows:

x[n] = x[n-1] - d[n] y[n-1] >> i
y[n] = y[n-1] + d[n] x[n-1] >> i
z[n] = z[n-1] - d[n] tan(1/2**i)

where:

d[n] is +1 for z[n-1] < theta. Clockwise rotation next.
d[n] is -1 for z[n-1] > theta. Counter-clockwise rotation next.

No multiplies here.

The CORDIC simply does a successive approximation to the angle -
rotating the angle clockwise or counter-clockwise by these limited
selection of angles as necessary to converge on the desired angle. Each
time the iteration occurs, the angle error is reduced by at least half.

> doesn't that require a few multiplications?

Nope. Just adds/subtracts - the sign of the angle error determines which
direction to rotate on the next iteration. If this is pipelined, the
shifts aren't real - they just select which bits of the previous
iteration are used on the next iteration. The tan(1/2**i) term is a
constant for each iteration.

As an implementation detail, it saves hardware if you iterate from
the angle toward zero instead of from zero toward the angle. If you do
that, the sign of z is the direction of rotation. It saves a
magnitude compare for each iteration.

Rob.

 

[rickman]

On 12/23/2014 11:02 PM, Rob Doyle wrote:

On 12/23/2014 6:10 PM, robert bristow-johnson wrote:

this did not seem to get posted so i am reposting. sorry for any
repeated post.

On 12/22/14 5:17 PM, Rob Doyle wrote:
On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am
wondering if an FFT is the best way to do this. I'm
mainly concerned with the "close
in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are
the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase
accumulator)? or can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the
sinusoid and with appropriate initial states, y[-1] and y[-2]
to result in the amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be
LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT,
since it is easily implemented in hardware. That's a general
architecture that is well-known and can be adjusted to produce
very clean local oscillators. If somebody tried to sell me a
block of IP with an "NCO" built some other way I'd be asking a
lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They
pipeline nicely and are therefore very fast, they require no
multipliers [1],

???

i don't s'pose Ray Andraka is hanging around (he was Dr. CORDIC here
a while back), but i always thought that CORDIC did essentially

x[n] = cos(2*pi*f0/Fs) * x[n-1] - sin(2*pi*f0/Fs) * y[n-1]
y[n] = sin(2*pi*f0/Fs) * x[n-1] + cos(2*pi*f0/Fs) * y[n-1]

Yes. So far. So good. These are my notes if anyone is interested...

[snip]

Assume theta = 2*pi*f0*t/fs, i.e., theta is the output of a phase
accumulator for an NCO application.

Factor out the cos(theta):

x[n] = cos(theta) {x[n-1] - y[n-1] tan(theta)}
y[n] = cos(theta) {y[n-1] + x[n-1] tan(theta)}

If you select tan(theta) from the set of 1/(2**i) then [1] this becomes:

x[n] = cos(theta) {x[n-1] - y[n-1] / 2**i}
y[n] = cos(theta) {y[n-1] + x[n-1] / 2**i}

At this point you might be thinking "Holy crap. That's one heck of a
constraint!" Yeh... but keep reading anyway.

You can drop the cos(theta) common term. It's just a gain term that
rapidly converges to 1.647. Therefore the gain of a CORDIC is not 0 dB.

x[n] = x[n-1] - y[n-1] / 2**i
y[n] = y[n-1] + x[n-1] / 2**i

or (assuming twos complement math) - simply:

x[n] = x[n-1] - y[n-1] >> i
y[n] = y[n-1] + x[n-1] >> i

where >> is a shift right operation

[1] As this point it seems as if an *extreme* limitation has been placed
on the selection of rotation angles. The equation above only describes
how to rotate an input signal by tan(theta) = 1/(2**i) - or by one of
the following angles:

atan(1) (45.000000000000000000000000000000 degrees)
atan(1/2) (26.565051177077989351572193720453 degrees)
atan(1/4) (14.036243467926478582892320159163 degrees)
atan(1/8) (7.1250163489017975619533008412068 degrees)
atan(1/16) (3.5763343749973510306847789144588 degrees)
atan(1/32) (1.7899106082460693071502497760791 degrees)

...and so forth.

The equation above does not describe how to rotate an input signal an
arbitrary angle! Although this is true; all is not lost.

Notice that in general that theta/2 < tan(theta).

This truth allows the CORDIC to be used iteratively to rotate any input
to any angle with any precision. IMO this is the genius of the CORDIC.

I probably should have mentioned that you swap the rotation direction by
flipping the additions and subtractions.

The term z[n] is introduced to accumulate the angle as the CORDIC
iterates. The term d[n] swaps the direction of rotation. Finally the
familiar recursive CORDIC equation can be written as follows:

x[n] = x[n-1] - d[n] y[n-1] >> i
y[n] = y[n-1] + d[n] x[n-1] >> i
z[n] = z[n-1] - d[n] tan(1/2**i)

where:

d[n] is +1 for z[n-1] < theta. Clockwise rotation next.
d[n] is -1 for z[n-1] > theta. Counter-clockwise rotation next.

No multiplies here.

But this is the same as a multiply in terns of complexity, no? One
large difference is that a multiply can be supported in commonly
available hardware while this algorithm requires dedicated hardware or
iterative software.

The CORDIC simply does a successive approximation to the angle -
rotating the angle clockwise or counter-clockwise by these limited
selection of angles as necessary to converge on the desired angle. Each
time the iteration occurs, the angle error is reduced by at least half.

doesn't that require a few multiplications?

Nope. Just adds/subtracts - the sign of the angle error determines which
direction to rotate on the next iteration. If this is pipelined, the
shifts aren't real - they just select which bits of the previous
iteration are used on the next iteration. The tan(1/2**i) term is a
constant for each iteration.

As an implementation detail, it saves hardware if you iterate from
the angle toward zero instead of from zero toward the angle. If you do
that, the sign of z is the direction of rotation. It saves a
magnitude compare for each iteration.

Rob.

--

Rick

 

[Rob Doyle]

On 12/23/2014 9:40 PM, rickman wrote:

On 12/23/2014 11:02 PM, Rob Doyle wrote:
On 12/23/2014 6:10 PM, robert bristow-johnson wrote:

this did not seem to get posted so i am reposting. sorry for any
repeated post.

On 12/22/14 5:17 PM, Rob Doyle wrote:
On 12/21/2014 5:13 PM, Eric Jacobsen wrote:
On Sun, 21 Dec 2014 14:52:40 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
rbj@audioimagination.com> wrote:

On 12/19/14 10:06 AM, rickman wrote:
I want to analyze the output of a DDS circuit and am
wondering if an FFT is the best way to do this. I'm
mainly concerned with the "close
in"
spurs that are often generated by a DDS.

i still get the concepts of DDS and NCO mixed up. what are
the differences?

One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase
accumulator)? or can it be algorithmic? like

y[n] = (2*cos(omega_0))*y[n-1] - y[n-2]

where omega_0 is the normalized angular frequency of the
sinusoid and with appropriate initial states, y[-1] and y[-2]
to result in the amplitude and initial phase desired.

is that an NCO that can be used in this DDS? or must it be
LUT?

Generally NCO or DDS refers to a phase accumulator with a LUT,
since it is easily implemented in hardware. That's a general
architecture that is well-known and can be adjusted to produce
very clean local oscillators. If somebody tried to sell me a
block of IP with an "NCO" built some other way I'd be asking a
lot of questions.

I have built NCOs using CORDIC rotators. No lookup tables. They
pipeline nicely and are therefore very fast, they require no
multipliers [1],

???

i don't s'pose Ray Andraka is hanging around (he was Dr. CORDIC here
a while back), but i always thought that CORDIC did essentially

x[n] = cos(2*pi*f0/Fs) * x[n-1] - sin(2*pi*f0/Fs) * y[n-1]
y[n] = sin(2*pi*f0/Fs) * x[n-1] + cos(2*pi*f0/Fs) * y[n-1]

Yes. So far. So good. These are my notes if anyone is interested...

[snip]

Assume theta = 2*pi*f0*t/fs, i.e., theta is the output of a phase
accumulator for an NCO application.

Factor out the cos(theta):

x[n] = cos(theta) {x[n-1] - y[n-1] tan(theta)}
y[n] = cos(theta) {y[n-1] + x[n-1] tan(theta)}

If you select tan(theta) from the set of 1/(2**i) then [1] this becomes:

x[n] = cos(theta) {x[n-1] - y[n-1] / 2**i}
y[n] = cos(theta) {y[n-1] + x[n-1] / 2**i}

At this point you might be thinking "Holy crap. That's one heck of a
constraint!" Yeh... but keep reading anyway.

You can drop the cos(theta) common term. It's just a gain term that
rapidly converges to 1.647. Therefore the gain of a CORDIC is not 0 dB.

x[n] = x[n-1] - y[n-1] / 2**i
y[n] = y[n-1] + x[n-1] / 2**i

or (assuming twos complement math) - simply:

x[n] = x[n-1] - y[n-1] >> i
y[n] = y[n-1] + x[n-1] >> i

where >> is a shift right operation

[1] As this point it seems as if an *extreme* limitation has been placed
on the selection of rotation angles. The equation above only describes
how to rotate an input signal by tan(theta) = 1/(2**i) - or by one of
the following angles:

atan(1) (45.000000000000000000000000000000 degrees)
atan(1/2) (26.565051177077989351572193720453 degrees)
atan(1/4) (14.036243467926478582892320159163 degrees)
atan(1/8) (7.1250163489017975619533008412068 degrees)
atan(1/16) (3.5763343749973510306847789144588 degrees)
atan(1/32) (1.7899106082460693071502497760791 degrees)

...and so forth.

The equation above does not describe how to rotate an input signal an
arbitrary angle! Although this is true; all is not lost.

Notice that in general that theta/2 < tan(theta).

This truth allows the CORDIC to be used iteratively to rotate any input
to any angle with any precision. IMO this is the genius of the CORDIC.

I probably should have mentioned that you swap the rotation direction by
flipping the additions and subtractions.

The term z[n] is introduced to accumulate the angle as the CORDIC
iterates. The term d[n] swaps the direction of rotation. Finally the
familiar recursive CORDIC equation can be written as follows:

x[n] = x[n-1] - d[n] y[n-1] >> i
y[n] = y[n-1] + d[n] x[n-1] >> i
z[n] = z[n-1] - d[n] tan(1/2**i)

where:

d[n] is +1 for z[n-1] < theta. Clockwise rotation next.
d[n] is -1 for z[n-1] > theta. Counter-clockwise rotation next.

No multiplies here.

But this is the same as a multiply in terns of complexity, no? One
large difference is that a multiply can be supported in commonly
available hardware while this algorithm requires dedicated hardware or
iterative software.

I agree that the CORDIC has the same complexity as a multiply. I agree
that table-based algorithms using multipliers use less FPGA fabric.

I was simply pointing out that there might be places where a CORDIC has
advantages over LUT-based NCOs.

Especially if have ROM or multiplier limitations.

I also wanted to point out that if you need to do a 20-bit (using your
120dB example) complex downconversion for example, the CORDIC still
requires zero multipliers.

If you want to do a 20-bit complex downconversion using a table-based
NCO followed by a complex mixer, you might need a *lot* of multipliers.
If you only have an 18-bit multiplier, each multiplication requires
(maybe up to) 4 multiplier blocks and you need 8 multiplications.

I also /suspect/ that for any given device technology the CORDIC will
execute at higher speeds.

Thats all...

The CORDIC simply does a successive approximation to the angle -
rotating the angle clockwise or counter-clockwise by these limited
selection of angles as necessary to converge on the desired angle. Each
time the iteration occurs, the angle error is reduced by at least half.

doesn't that require a few multiplications?

Nope. Just adds/subtracts - the sign of the angle error determines which
direction to rotate on the next iteration. If this is pipelined, the
shifts aren't real - they just select which bits of the previous
iteration are used on the next iteration. The tan(1/2**i) term is a
constant for each iteration.

As an implementation detail, it saves hardware if you iterate from
the angle toward zero instead of from zero toward the angle. If you do
that, the sign of z is the direction of rotation. It saves a
magnitude compare for each iteration.

Rob.