From: _tomislav on
Hi,

I'm looking for an implementation of fast floating point FFT algorithm. I
found application notes (http://tiny.cc/EE185, Analog Devices) describing
addition and multiplication of fast floating point numbers. cftt function
inside VisualDSP library performs N-point radix-2 complex input FFT using
fract16 format. Could I find somewhere implementation for fastfloat16
format?

I haven't used VisualDSP, so I'm not quite familiar with VisualDSP
libraries






From: Tim Wescott on
On Tue, 20 Oct 2009 09:05:47 -0500, _tomislav wrote:

> Hi,
>
> I'm looking for an implementation of fast floating point FFT algorithm.
> I found application notes (http://tiny.cc/EE185, Analog Devices)
> describing addition and multiplication of fast floating point numbers.
> cftt function inside VisualDSP library performs N-point radix-2 complex
> input FFT using fract16 format. Could I find somewhere implementation
> for fastfloat16 format?
>
> I haven't used VisualDSP, so I'm not quite familiar with VisualDSP
> libraries

If fastfloat16 really fits into 16 bits then you're probably just giving
up too much precision to make an FFT worthwhile -- even a 16-bit
fractional type is getting slim on precision unless your data isn't that
wide and your number of bins isn't too great.

I would assume that for a well-scaled fixed point algorithm you'd want at
least your input precision, plus log2 of your number of bins, plus two or
three bits for good measure -- that'll add up to 16 pretty darn quick,
much less whatever is available for a mantissa in fastfloat16.

--
www.wescottdesign.com
From: Vladimir Vassilevsky on


_tomislav wrote:

> Hi,
>
> I'm looking for an implementation of fast floating point FFT algorithm.

Why would you need that?
Why can't you use block floating point?

> I
> found application notes (http://tiny.cc/EE185, Analog Devices) describing
> addition and multiplication of fast floating point numbers. cftt function
> inside VisualDSP library performs N-point radix-2 complex input FFT using
> fract16 format. Could I find somewhere implementation for fastfloat16
> format?

Which VDSP? For what processor?

> I haven't used VisualDSP, so I'm not quite familiar with VisualDSP
> libraries


Redefine a floating point FFT like that:
template <class T> void FFT(T *data);
Then define class float_16 and use it.
This is definitely not the most efficient implementation; however it is
going to be faster then the standard float if there is no FPU.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
From: _tomislav on
>If fastfloat16 really fits into 16 bits then you're probably just giving
>up too much precision to make an FFT worthwhile -- even a 16-bit
>fractional type is getting slim on precision unless your data isn't that

>wide and your number of bins isn't too great.
>
>I would assume that for a well-scaled fixed point algorithm you'd want at

>least your input precision, plus log2 of your number of bins, plus two or

>three bits for good measure -- that'll add up to 16 pretty darn quick,
>much less whatever is available for a mantissa in fastfloat16.

Fastfloat16 can't fit into 16 bits - format provides one 16-bit word for
exponent and one 16-bit word for fraction. Signed twos-complement notation
is used both for exponent and fraction. So, precision is equal to 2^-15.

Fastfloat16 gives a good precision and range. Let's assume that well
optimized FFT algorithm has a complexity of O(Nlog10). On a fixed point DSP
like BF532 16-bit multiplication/addition is completed in one cycle. So, N
is equal to cycle number. If fastfloat16 multiplication needs, lets say, 30
cycles in average for multiplication/addition I think this outperforms
floating point format on fixed point machine.

From: Tim Wescott on
On Wed, 21 Oct 2009 03:11:46 -0500, _tomislav wrote:

>>If fastfloat16 really fits into 16 bits then you're probably just giving
>>up too much precision to make an FFT worthwhile -- even a 16-bit
>>fractional type is getting slim on precision unless your data isn't that
>
>>wide and your number of bins isn't too great.
>>
>>I would assume that for a well-scaled fixed point algorithm you'd want
>>at
>
>>least your input precision, plus log2 of your number of bins, plus two
>>or
>
>>three bits for good measure -- that'll add up to 16 pretty darn quick,
>>much less whatever is available for a mantissa in fastfloat16.
>
> Fastfloat16 can't fit into 16 bits - format provides one 16-bit word
> for exponent and one 16-bit word for fraction. Signed twos-complement
> notation is used both for exponent and fraction. So, precision is equal
> to 2^-15.
>
> Fastfloat16 gives a good precision and range. Let's assume that well
> optimized FFT algorithm has a complexity of O(Nlog10). On a fixed point
> DSP like BF532 16-bit multiplication/addition is completed in one cycle.
> So, N is equal to cycle number. If fastfloat16 multiplication needs,
> lets say, 30 cycles in average for multiplication/addition I think this
> outperforms floating point format on fixed point machine.

The gist of what I was trying to get across still stands -- floats use
more memory for the precision they give, and they use time.

Why use a data type that gives you less than 16 bits of precision and
takes 30 clock ticks (at best) for a MAC when you can use the same amount
of memory, get better than 30 bits precision, and use four clock ticks
per MAC?

--
www.wescottdesign.com
 |  Next  |  Last
Pages: 1 2
Prev: rahasia uang 250 ribu
Next: using FFT as a channelizer