fft in fpga using polar form

i understand that representing large number of twiddle factors that are required in a fft with large number of points is an issue when using fixed point scheme. To my understanding (which could be very wrong as i am new to this),the issue is large dynamic range that is needed to represent real and imaginary parts of the complex numbers. Would the use of polar form to represent them solve this problem, as for all twiddle factors, the absolute value will be one and the argument will change from 0 to 360? (or should the argument be specified in radians always?)

 

[glen herrmannsfeldt]

jack.pett.son@gmail.com wrote:

i understand that representing large number of twiddle factors
that are required in a fft with large number of points is an
issue when using fixed point scheme.

As far as I know, that isn't a problem.

To my understanding
(which could be very wrong as i am new to this),the issue is
large dynamic range that is needed to represent real and
imaginary parts of the complex numbers.

No matter how you do it, you can't have a large dynamic
range with the FFT. (Or, even worse usually, the non-fast
DFT.) Enough addition and subtraction is done that the
dynamic range is pretty much whatever precision the computation
is done at.

Would the use of
polar form to represent them solve this problem, as for
all twiddle factors, the absolute value will be one and
the argument will change from 0 to 360?

I don't believe that helps. For the usual twiddle factors,
all you need is a small (or big) lookup table. In polar
coordinates, with any angular measure, you need to compute
sines and cosines at each step.

Well, if all you needed to do was rotations in polar
coordinates, then yes. But you also have to add and subtract
values at different rotations.

(or should the argument be specified in radians always?)

More obvious to me, binary fractions of a whole rotation.

-- glen

 

[glen herrmannsfeldt]

jack.pett.son@gmail.com wrote:

Would the use of polar form to represent them solve this problem?

Which reminds me of a different question I have wondered
about for a while:

Why do so few high-level languages provede trigonometric
functions in degrees in their math libraries?

The only one I know of is PL/I, not so commonly used these days.

I know the reasons for doing trigonometry in radians, and have
no complaint against doing it in radians, but reasonably often it
is convenient to do in a unit that is a rational fraction of a
whole rotation.

Now, the same arguments against degrees could be used against
supplying a log10 function, but many systems do supply that one.

Usually the first thing that non-inverse trigonometric routines
do is argument reduction after dividing by some multiple of pi.
If one actually wants a nice fraction of a whole circle, it is
extra work and precision loss to multiply by some multiple of pi
just before the routine divides by a multiple of pi.

-- glen