Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Parallel

Fixed vs. Floating Point: A Surprisingly Hard Choice


[Editor's note: For an intro to floating-point math, see Tutorial: Floating-point arithmetic on FPGAs. For an intro to fixed-point math, see Fixed-Point DSP and Algorithm Implementation.]

The advantages of floating-point processors are well known. Without a doubt, floating point implementations of many algorithms take fewer cycles to execute than fixed point code (assuming, of course, that the fixed-point code offers similar precision). Floating-point processors are also often much easier to program in assembly code. However, neither of these advantages matter all that much to the end designer. With the quality of compilers getting better and better each day, hardly anyone codes in assembly anymore—and writing code in C is nearly equally simple, be it fixed or floating point. Moreover, in C one can certainly write floating point code for a fixed point processor, although it will take a significant performance hit. What does matter to the end designer is the final system's performance, cost and time to market. These are the metrics that I will try to estimate in the analysis below.

There is a myriad of processors out there, both fixed- and floating-point. Doing an analysis on each one would turn this paper into something comparable in size to an encyclopedia. So I will restrict my comparative analysis to two ADI processors—Blackfin from the fixed point camp and SHARC as its floating point nemesis. We'll choose two members that are similarly priced—ADSP-21531 Blackfin and ADSP-21375 SHARC, both selling at around $5 per part in reasonable quantities at the time of this writing.

One may think that, given a similar silicon price, one should choose the floating-point processor, simply because it can do the floating point, in case it is ever needed. But similar price of the silicon does not always translate into a similar price of the end system. For example, SHARC's power consumption for a similar fixed-point task is higher than that of the Blackfin, which results in more expense in the power supply design, among other things. In any case, a single application would, most likely, favor one processor or the other. Thus, to be fair, we'll consider four separate applications:

  • Military radar
  • Mobile TV
  • Professional audio effects processor
  • Automatic echo canceller in hands-free portable device

The choice of these applications is not entirely random. I tried to select an application that is a clear winner for each approach, one where the answers are not quite so clear and require a more in-depth analysis, and one which can be misleadingly simple.

I would also like to add that no real world analysis would be complete without a consideration of ASIC hardware co-processors (on and off-chip) and FPGAs to offload some of the signal processing tasks from the DSP. The discussion of these options is completely outside of the scope of this paper, but one has to keep in mind that the study below should, in real world, be a part of an analysis with a much greater scope.

Military Radar
We might as well start with an easy choice. In military radar, you will frequently use a floating-point processor. Why? Because floating point performance in this application is essential. Radar relies on finding maximal absolute value of a self-ambiguity function. This function arises as the result of the cross-correlation of a sent test signal with the received echo. Such a function is given by

This is an integral of a function against an exponential. Such an integral can be computed using FFT techniques. Floating point is greatly helpful when computing large FFTs, and there are no drawbacks to using a floating-point processor here. Power is not a major issue, as long as the heat can be vented out (i.e., the processor is not glowing red). The cost of the device is not a major issue either, because the processors comprise only a small fraction of the overall system cost. As a matter of fact, one would be unlikely to choose even the ADSP-21367 SHARC for such a task since one goal of this application is to pack as much processing power as possible into every square millimeter. Thus, the high performance ADSP-TS201 from ADI's TigerSHARC family of products would be more appropriate for this application.

Mobile TV
This is another easy choice. There is simply no need for the floating-point processing in mobile TVs. The bulk of the signal chain processing is in the standard decoders, such as MPEG-2, MPEG-4, JPEG-2000 and H.264. These algorithms were designed to be performed in fixed-point. Not only is the greater precision and dynamic range of floating point non-helpful, it can't be used at all, because the algorithms are, in general, bit exact.

For example, the transform used to go to frequency domain in video codecs is some form of a DCT (Discrete Cosine Transform). On the surface, it would appear that floating point is more suited to DCT computations, just like in the case of FFTs above. Indeed, floating-point computations would produce a more precise DCT. Unfortunately, the DCTs in video codecs are designed to be performed on a fixed-point processor and are bit-exact—so more precision is simply wrong here.

What's more, much of the video codec workload lies in the control code—no need for the floating point there, either. For example, the entropy encoders used in video codecs account for a significant fraction of the overall workload. (This is particularly true for the CABAC encoder used in H.264.)

In the two processors considered here, the correct choice is made even more clear by the fact that Blackfin processors have instructions designed specifically to accelerate the performance of video algorithms. In contrast, the SHARC processors have no video-specific instructions. In addition to this, power is critically important in the mobile market, pretty much ruling floating-point processors out. This makes the choice obvious.

The rest of the application examples will require a much more in-depth analysis before the correct processor choice can be made.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.