why floating point need to be avoided in Real Time Systems ?

Hi,
I read in some Design guidelines that floating point should be avoided in
Real Time systems. Why is it ?
Then how to maintain the required precision in that case ?

Regards,
shakes_ck

_____________________________________
Do you know a company who employs DSP engineers?  
Is it already listed at http://dsprelated.com/employers.php ?

shakes_ck wrote:
> Hi,
> I read in some Design guidelines that floating point should be avoided in
> Real Time systems. Why is it ?
> Then how to maintain the required precision in that case ?
> 
> Regards,
> shakes_ck
> 
> _____________________________________
> Do you know a company who employs DSP engineers?  
> Is it already listed at http://dsprelated.com/employers.php ?

Whether to use fixed point code or floating point code depends on the 
particular application and what computations you're doing.  Applications 
that do not have huge dynamic range can be implemented more efficiently 
and even more precisely using fixed point math.  Other applications may 
require very large dynamic range making them better suited to floating 
point code.

I think the more appropriate statement would be not to write floating 
point code to run on a fixed point processor.  In that particular case 
it will be implemented through function calls rather than native 
floating point instructions causing a HUGE performance hit and making it 
harder to meet real-time deadlines.

Brad

On Tue, 03 Apr 2007 07:18:22 -0500, shakes_ck wrote:

> 
> Hi,
> I read in some Design guidelines that floating point should be avoided in
> Real Time systems. Why is it ?

Probably just a guideline aimed particularly at PC users.  The main issue
is that on some floating point processors, certain ranges of values
(particularly the "denormals") cause the computation time to increase
dramatically, compared to the time for normalized numbers.

Unfortunately, some of the things that people like to do in DSP or control
systems involve recurrances that lead almost inevitably to sequences of
denormalised numbers when the input goes to zero for periods of time. 
These sequences can be inconvenient and/or expensive to avoid, in general,
and require at least some additional care.

Most modern PCs, though, and almost all floating point DSP chips do not
have this problem, because their floating point units can (or always do)
flush values to zero instead of denormalised, and so can guarantee that
the computation time will remain constant irrespective of the input
values.  This is the important condition that you need to be able to do
real-time work.

> Then how to maintain the required precision in that case ?
> 

If you avoid floating point, then you need to use a fixed point arithmetic
model with sufficient precision for your task.  Most DSP processors
provide this, and it is readily possible to arrange the same on regular PC
processors, too, but hardly necessary since those tend to have better
support for floating point...

Cheers,

-- 
Andrew

shakes_ck wrote:

> Hi,
> I read in some Design guidelines that floating point should be avoided in
> Real Time systems. Why is it ?

Never mind. This is the old superstition which has to do with the 
performance penalty and some other problems associated with the use of 
the floating point on the ancient CPUs.

Basically, the author of the guideline is trying to say that he is a 
cool guy because he can code the computations with the integers.

> Then how to maintain the required precision in that case ?

Floating point is not about the precision. It is about the range of 
representation.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote in news:PAsQh.5320
$Kd3.2328@newssvr27.news.prodigy.net:

> 
> Never mind. This is the old superstition which has to do with the 
> performance penalty and some other problems associated with the use of 
> the floating point on the ancient CPUs.

... and many current-day microcontrollers.

-- 
Scott
Reverse name to reply

Scott Seidman wrote:

>>Never mind. This is the old superstition which has to do with the 
>>performance penalty and some other problems associated with the use of 
>>the floating point on the ancient CPUs.
> 
> ... and many current-day microcontrollers.
> 

A low end microcontroller of today is equivalent to a desktop PC of 15 
years ago. In the majority of cases, there is no need to be a miser.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Hello,

In DSP applications, are there recoommended/ standard floating point to
fixed point conversion methods?

APS


_____________________________________
Do you know a company who employs DSP engineers?  
Is it already listed at http://dsprelated.com/employers.php ?

Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote in news:E6tQh.5329
$Kd3.2007@newssvr27.news.prodigy.net:

> 
> 
> Scott Seidman wrote:
> 
>>>Never mind. This is the old superstition which has to do with the 
>>>performance penalty and some other problems associated with the use of 
>>>the floating point on the ancient CPUs.
>> 
>> ... and many current-day microcontrollers.
>> 
> 
> A low end microcontroller of today is equivalent to a desktop PC of 15 
> years ago. In the majority of cases, there is no need to be a miser.
> 
> Vladimir Vassilevsky
> 
> DSP and Mixed Signal Design Consultant
> 
> http://www.abvolt.com
> 


There are many fine MCU's that don't have floating point processors.  The 
AVR Atmel and the PIC 18F spring immediately to mind, and flops take much 
more time than intops.  Many DSP's do support floats, but that is a fairly 
beefy upgrade in terms of cost and development time.  I'd think it would 
take less time to learn integer math than a new environment, as well.


-- 
Scott
Reverse name to reply

Scott Seidman wrote:


>>A low end microcontroller of today is equivalent to a desktop PC of 15 
>>years ago. In the majority of cases, there is no need to be a miser.
>>
> There are many fine MCU's that don't have floating point processors.  The 
> AVR Atmel and the PIC 18F spring immediately to mind, and flops take much 
> more time than intops.

I am very familiar with this stuff. Yes, for the AVRs and PICs the 
floating point is somewhat 20 times slower then the 16 bit integer. 
However it appears not to be a problem for many practical cases. What 
does matter is that the use of the floats requires a micro with 8k ROM 
at the least. This implies a MCU of $2 class, whereas the int 
arithmetics for the same functionality can probably be squeezed into the 
$1 class.

> Many DSP's do support floats, but that is a fairly 
> beefy upgrade in terms of cost and development time.

Actually, the use of floats greatly simplifies the development of the 
software. The DSPs with the hardware floating point are power hungry, 
and not designed to work as the standalone.

   I'd think it would
> take less time to learn integer math than a new environment, as well.
> 

I disagree. Optimizing the integer calculations, looking for overflows 
and bit losses is a tedious piece of work.


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

shakes_ck wrote:
> Hi,
> I read in some Design guidelines that floating point should be avoided in
> Real Time systems. Why is it ?

There is nothing generically bad about floating point for real time 
work. However, many processors slow down horribly for very small numbers 
which will not normalise. The Pentium processors are very bad for this. 
People use fudges in their code to try to stop numbers denormalising, 
but it can still happen. This means the runtime of the code is rather 
unpredictable. It may run real time for 99.999% of the time, and then 
hiccup badly on a few small numbers.

> Then how to maintain the required precision in that case ?

Integers will generally give greater precision for the same word length. 
I think you are confusing precision with dynamic range.

Steve