6
$\begingroup$

Why is there no FPU (Floating Point Unit) on most DSP chips? I found several answers such as this one that explain advantages of fixed point approach such as smaller power consumption, higher speed and I can myself think of several other advantages such as smaller heat production or price but I have never seen any practical real life benchmarks. The questions I would like to know answers for are:

  • how much is FPU and what is the price difference between CPUs with an FPU and CPUs without an FPU?

  • how much heat can FPU produce?

  • how much power would FPU consume?

Improve this question
$\endgroup$
4
  • 4
    $\begingroup$ i am not sure how you are counting "most" DSP chips. it doesn't seem to me that most DSP chips lack an FPU. $\endgroup$ – robert bristow-johnson Dec 11 '19 at 19:32
  • $\begingroup$ @robertbristow-johnson I've added the term "most" to the title, otherwise it meant on "all" ?? $\endgroup$ – Fat32 Dec 11 '19 at 19:35
  • 2
    $\begingroup$ also, if your fixed-point DSP chip has a barrel shifter, so that shifting by N bits can occur in a single instruction, a careful DSP coder can do anything with a fixed-point DSP that another can do with an FPU. if you absolutely have to, you can do this technique we call "Block Floating-Point". but having an FPU is convenient if the NaNs, INFs, -0, and the denorms don't get you down. $\endgroup$ – robert bristow-johnson Dec 11 '19 at 19:35
  • $\begingroup$ It's not just about power, it's about complexity and footprint as well. $\endgroup$ – Mast Dec 12 '19 at 7:31
12
$\begingroup$

An 8086 used less than 30k transistors. The 8087, which is the FPU for the 8086, is reported to use 45k transistors. Faster FPUs can be even larger in terms of gate count. So the cost in silicon die area of an FPU can be significant (over 2X?). Power and thus heat is proportional on the order of the number of transistors toggling outputs at similar rates.

For real-time DSP, there is also the issue of deterministic latency. A simple integer multiply-accumulate unit has a fixed latency. A really simple floating point adder does not have a fixed latency (or is either not fast or not simple) due to the potential need to normalize up to twice and/or handle NaNs and denorms.

Improve this answer
$\endgroup$
8
  • 6
    $\begingroup$ besides NaNs, the denorms can be a problem in real-time DSP. $\endgroup$ – robert bristow-johnson Dec 11 '19 at 19:31
  • $\begingroup$ Just as a point of interest, the latest Intel/Altera FPGA architecture has DPS blocks that are 32-bit integer blocks by themselves, or that can be doubled up to make 32-bit floating point blocks. $\endgroup$ – TimWescott Dec 11 '19 at 21:05
  • $\begingroup$ +1. The first answer that mentions deterministic latency. Do you happen to know many mm2 can FPU take? Here realworldtech.com/forum/?threadid=9650&curpostid=9652 someone says Including an approximation unit for division and square root but not a register file, probably 1/3 to 1/2 million transistors. In terms of area, perhaps 1.5 to 2.0 mm2 in 0.13 um. $\endgroup$ – user1042840 Dec 11 '19 at 23:12
  • $\begingroup$ And here cpu-collection.de/?l0=co&l1=Intel&l2=FPU it say that circuit size is 3 what is the unit? $\endgroup$ – user1042840 Dec 11 '19 at 23:13
  • 3
    $\begingroup$ Can you back up the statement in the last paragraph? I tossed my databooks, but IIRC the C30/C40 was 100% deterministic with execution times for add, multiply, and MAC (and speedier when using via complete). C40 was 40 bit FP when in registers, and the 32 bit to memory. Compromise was FP didn't have IEEE semantics, but I never ran into this being a problem. $\endgroup$ – mpdonadio Dec 12 '19 at 0:53
6
$\begingroup$

Why not use floating point:

  • Floating point is big
  • Floating point is power-hungry
  • Floating point that is fast and fully IEEE compliant is really big and really power hungry, so most fast floating point units sacrifice IEEE compliance
  • Floating point is good when you have a problem where you don't know the range of the input data beforehand.
  • In many many DSP problems you know exactly the range of the input data beforehand.

Why use floating point:

It takes a lot more engineering to design the details of an algorithm (data path widths, scaling of intermediate values, etc.) to run in fixed point vs. floating point. To some extent floating point just works -- except where it doesn't, and the pitfalls of using floating point are more subtle, and they hit you much more often if you're using 32-bit (i.e. small and fast) floating point.

Improve this answer
$\endgroup$
6
  • 1
    $\begingroup$ really big and really power hungry - do you know exact numbers? For examples, how many inches/mm it can take or how many watts it requires? $\endgroup$ – user1042840 Dec 11 '19 at 22:55
  • 1
    $\begingroup$ I don't, and if I did it would be different tomorrow. I do that often when I've encountered floating point used in a signal processing context it hasn't been fully IEEE 754 compliant, and when I've pressed vendors for why the answer was "do you know how much logic it takes to cover all the corner cases?" $\endgroup$ – TimWescott Dec 11 '19 at 23:05
  • 1
    $\begingroup$ Indeed! Get a fast prototype out quickly with floating point (or confirm algorithm etc). Design high volume low cost solution with fixed point. Also see one of my favorite "DSP Puzzle" questions: dsp.stackexchange.com/questions/38832/… $\endgroup$ – Dan Boschen Dec 12 '19 at 0:34
  • $\begingroup$ Now I'm curious--what specific bits of IEEE754 do they sacrifice for speed? I'm sure it's corner cases that you're unlikely to encounter in practice, but I'm curious which ones, if you know. $\endgroup$ – Hearth Dec 12 '19 at 15:10
  • 1
    $\begingroup$ @Hearth: I'm afraid I don't know to that level of detail. For me the conversation was along the lines of "some things aren't supported"; "what things?"; "stuff that happens when you screw up the algorithm"; "well then I won't screw up the algorithm!" -- end of conversation. Which, I admit, is kind of naively arrogant, but if you actually manage to never screw up the algorithm... $\endgroup$ – TimWescott Dec 12 '19 at 15:52
5
$\begingroup$

There are certainly FPUs on DSP chips such as the TMS320X family from TI or STM32F4xx series powerful microcontrollers from ST [see comment below]. These chips are powerful both in terms of FLOPS and also in terms of electrical power consumption (especially the former).

However, there are so many applications that are restricted by energy or power, such as embedded or mobile computing. For such applications fixed point arithmetic may be preferred, as it's computationally more efficient; requiring less power consumption (slower clock) at the same MAC count such as a Blackfin from ADI or similar from NXP.

Furthermore, FPU hardware is more complicated than the integer one and this will also effect the chip cost and pricing.

Therefore, unless it's absolutely necessary to use an FPU or unless it's available at little cost, FPU units may be replaced by fixed point units, leaving the complexity of fixed-point programming to DSP engineers.

How much is the difference? Depends on detailed chip architecture and that makes it difficult to answer precisely, unless you are the designer of the chip.

Improve this answer
$\endgroup$
7
  • 2
    $\begingroup$ The ARM Cortex M4 core (used in the STM32F4xx) has a floating point unit, and it has DSP extensions to the instruction set that let it do faster vector operations -- but unless I'm horribly mistaken those DSP extensions are for fixed-point only, and don't provide the one-clock-per-element vector multiply that I count as the hallmark of a true DSP chip. $\endgroup$ – TimWescott Dec 11 '19 at 21:09
  • $\begingroup$ @TimWescott yes that's a microcontroller, I added its name becuase of its versatil structure and the basic FPU functionality at an affordable cost. Thanks for the notification though. $\endgroup$ – Fat32 Dec 11 '19 at 21:27
  • $\begingroup$ Today's mobile phones come with powerful Cortex-A CPUs. Do they still use fixed-points DSPs for some purposes? $\endgroup$ – user1042840 Dec 11 '19 at 23:03
  • $\begingroup$ @user1042840 a very generic question... Today you have 100x GFLOP performance on laptop CPU's, but you can use fixed point arithmic if you wish, or better if that's worth. The same for the mobile too... You should ask this to individual app developers what they prefer. I believe %90+ will be using dedicated FPU though. $\endgroup$ – Fat32 Dec 11 '19 at 23:24
  • $\begingroup$ Unless ST got it wrong somehow, the STM32F[347]xx will use the FPU for DSP instructions. They point out that the 3&4 only use single precision and the 7 has dual, so on the 3&4 you might be better off with fixed. On page 5 of st.com/content/ccc/resource/technical/document/application_note/… $\endgroup$ – GB - AE7OO Dec 12 '19 at 20:47
1
$\begingroup$

It depends on the application; with 3D math for graphics for example, early systems used integer DSPs/coprocessors (Playstation 1's Geometry Transform Engine, Sega Saturn were both fixed point) but there was rapid and universal adoption of floating point hardware in subsequent hardware generations.
You can build 3D systems using fixed point math but it's a real pain in the butt at times; you're constantly watching out for overflows or underflows and having to be careful about precision to avoid visual artifacts.

Improve this answer
$\endgroup$
0
$\begingroup$

My basic understanding is:

The biggest differentiation for a DSP is it's ability to do very fast multiply-and-accumulate functions. They do so by paralleling a lot of this in hardware. Implementing this kind of hardware adder is very simple (in speed and gate-count) for integers, but gets more complex for floating point.

In most practical cases in which such chips are used, pure integer implementations are both faster and practical, and are thus used. So if I'm using a special-purpose DSP to accelerate these specific operations, applying heat, transistors and power to functionality (floating point) which is moving me away from my end-goal (very fast multiply-and-accumulates) is the wrong way to go.

I am italicizing the word practical in that there certainly are cases where you might want to do this for floating-point, but in more-specific implementations of building radios, filters, etc for specific purposes and workloads - it generally all can be simplified and optimized with integer math.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I'm not sure MAC is really the divider. I would say the ability to loop an instruction group without needing to constantly check on a loop counter is what sets the true DSP apart from other platforms. While a lot of modern chips implement MAC, fused MAC, SMD, etc, group looping is almost unheard of outside of the "real" DSP chips. $\endgroup$ – GB - AE7OO Dec 12 '19 at 20:57
  • $\begingroup$ @GB-AE7OO: Ironically, TI's offshoot of the 3205x series omitted the zero-overhead looping features and delayed branches from that DSP. $\endgroup$ – supercat Dec 12 '19 at 22:14
  • $\begingroup$ @supercat Sometimes TI's actions almost make me believe that there is no one with a decent brain in charge. As another example, when TI got a hold of NatSemi, they went on massive search and replace through all of the docs. In some cases it was/is REAL obvious that it was done by machine. I've never been a fan TI sheets or notes, and lately it's gotten worse... $\endgroup$ – GB - AE7OO Dec 13 '19 at 9:33
0
$\begingroup$

DSPs are specialized devices and traditionally quite painful to work with compared to general purpose ones.

Much of that pain came from trying to get as much express-train multiply-accumulate performance out of a level of technology as possible, by sacrificing flexibility that could slow it down. In effect they were an intermediate between a traditional stored program "computer" and a set of a set of application-specific fixed-function computational paths in an FPGA or ASIC - almost a form of the latter setup for a common sort of signal processing task, with just enough programmable flexibility to allow it to be adapted to a task and maybe a little mode-tuning code on the side.

So in terms of traditional DSP's, you only even "went there" when a chip manufacturer's particular example of specialized hardware was a good fit for your application.

  • If you were willing to run a fixed point algorithm, you could buy a simple fixed point DSP.

  • If you insisted on running a floating point algorithm, you would buy a floating point DSP (yes, a few were made).

That said, what happened historically was that some DSPs (both fixed and floating point) started to gain more general purpose processor features, C compiler support that wasn't too ugly (hello reminder that a 16-bit char isn't illegal), etc. Meanwhile general purpose processors gained more DSP extensions, and in many cases enough raw speed to do DSP tasks using the ordinary computation paths. You still see DSP's in unique applications, but more and more you see general purpose processors (such as the Cortex-M4's mentioned by others) not infrequently letting the software designer consider either a fixed or floating point approach on the same hardware.

Improve this answer
$\endgroup$
0
$\begingroup$

The primary advantage of floating-point is that it will allow one piece of code to work with numbers of widely varying magnitude, without having excessive precision when numbers are large and insufficient precision when they are small. A disadvantage of floating-point for high-speed number crunching is that the transitive and distributive laws that are applicable to mathematical numbers or to computer-processed integers within their range do not apply to floating-point numbers. When using integers, a calculation like (((a+b)+c)+d) will yield the same result as ((a+b)+(c+d)); if a processor would be able to add (a+b) and (c+d) simultaneously, the latter calculation may be faster than the former while yielding the same result.

In many DSP applications, one can determine the amount of precision necessary to handle the smallest inputs, and integers that are scaled to accommodate those cases will be of reasonable size even when handling the largest possible inputs. The performance benefits from being able to exploit the transitive and distributive laws may offer greater benefits than would be received by processing a somewhat shorter significand.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.