floating point design careabouts

>Rule 1:  Floating point is a resource hog.  This isn't an issue if 
>you're using a PC or other 'big iron' machine, because floating point is 
>already built in and hogging resources even when you're not using them. 
>  But if you're designing a small system with a fixed-point processor, 
>or a system built around an FPGA, it counts in either low speed, large 
>silicon area, or some combination thereof.

What about the case where one needs a very large dynamic range but not
necessarily a lot of precision?  With fixed point arithmetic a large
dynamic range forces huge bitwidths.  With floating point you have some
freedom to trade precision for dynamic range assuming you can create your
own floating point implementation.  I do agree that IEEE 754 is a hog in
FPGAs.

>Recently while coding sample rate convertor I had real bad
>experience with floating point numbers in Matlab. I guess it
>will be same even if we use C or any other language. Actually
>2.0 was represented as 1.9999999999 so the phase selection logic
>advanced by one step while the previous value was picked for
>data computation.
>
>Anyone have similar experieces about floating point handling?
>Is there any good document on same?
>
>Regards
>Bharat

Oh and yes I have had this happen to me in Matlab.  I had a variable that
looked like an integer and Matlab even displayed the value as an integer
when I printed it to the screen.  I had to change Matlab's formatting to
long e (format long e) to see that the value was not an integer.  I'm
assuming you had several floating point calculations that should have
resulted in the integer "2" but didn't due to the quantization error that
may occur during every floating point operation.

Impoliticus <swiston@n_o_s_p_a_m.uiuc.edu> wrote:

>>Rule 1:  Floating point is a resource hog.  This isn't an issue if 
>>you're using a PC or other 'big iron' machine, because floating point is 
>>already built in and hogging resources even when you're not using them. 
>>  But if you're designing a small system with a fixed-point processor, 
>>or a system built around an FPGA, it counts in either low speed, large 
>>silicon area, or some combination thereof.
 
> What about the case where one needs a very large dynamic range but not
> necessarily a lot of precision?  With fixed point arithmetic a large
> dynamic range forces huge bitwidths.  With floating point you have some
> freedom to trade precision for dynamic range assuming you can create your
> own floating point implementation.  

This is true.  But many problems don't have all that large a dynamic
range, but people are sometimes lazy.  Well, part is that very few
programming languages support scaled fixed point.  One is expected
to do the scaling, and with no help for I/O.  

> I do agree that IEEE 754 is a hog in FPGAs.

Very true.  The pre/post normalization for an adder is much bigger 
than the adder itself.  In many cases, bigger than a floating point
multiplier!  

-- glen