FPGAs doing floating point

[shaiko]

I've heard many times that FPGA's aren't well suited for floating-point arithmetic.
Please elaborate - WHY ?

 

[FvM]

I know that you are dealing with digital logic and FPGA since longer time. So I would ask first, what's your own opinion and possibly experience in this regard?

Floating point arithmetic can be of course implemented in FPGA when needed. In this case, FPGA are perfectly suited, I think. On the other hand, floating point is surely not the first choice for most FPGA applications. So we need to talk about applications and the characteristic qualities of FPGA.

 

[shaiko]

I know that you are dealing with digital logic and FPGA since longer time. So I would ask first, what's your own opinion and possibly experience in this regard?

My only thought is that implementing a full blown FPU on an FPGA would require very deep pipelining with a big latency penalty...putting real-time performance out of reach.

 

[FvM]

Although a FPU can be implemented in FPGA (there are various projects that designed FPUs with special features in FPGA), it's essentially a function block dedicated to sequential data processing.

As you can implement a processor in FPGA, you can also implement a FPU. But FPGA data processing has many data pathes, each with it's own arithmetic elements. So one FPU might be not enough.

 

[shaiko]

So, you do agree that an FPU implemented on a high end FPGA (think Stratix V) would have poor performance compared to an embedded CPU (think ARM Cortex A9 for example) ?

 

[TrickyDicky]

Remember that a FPU on a CPU will be a highly optimised ASIC specifically designed for this purpose.
FPGAs are much better at number crunching than they are at being co-processors. But in the past (about 7 years ago) I was putting floating point units on a V2Pro running at 100-200MHz. It was part of trigonometric pipelines so just crunching large packets of data (data was coming via gigabit ethernet, so thats quite a lot of data to crunch).

All embedded multipliers are really designed for fixed point multiply accumulate. With floating point you cant really use this specialised resource, but I think they're starting to accept floating point applications.

 

[FvM]

So, you do agree that an FPU implemented on a high end FPGA (think Stratix V) would have poor performance compared to an embedded CPU (think ARM Cortex A9 for example) ?

No, the FPGA FPU can achieve higher performance, and also be taylored for specific operations. I say, a usual FPU doesn't help much for the way of data processing implemented in FPGA.

 

[shaiko]

I say, a usual FPU doesn't help much for the way of data processing implemented in FPGA.

But today "data processing implemented in FPGA" may take the form of a soft-processor (one or many) deviating from the traditional hardware blocks approach.

 

[TrickyDicky]

But today "data processing implemented in FPGA" may take the form of a soft-processor (one or many) deviating from the traditional hardware blocks approach.

But now Both Altera and Xilinx are putting hard ARM cores in their chips, probably to get back to allowing FPGAs to become specialised co-processors again.

 

[shaiko]

I'm more interested in the soft-processor option.having many of them with each doing a specific task.
The hardened ARM is more of a "do it all" application processor intended to run an OS.

With the OS overhead penalty, I doubt that the ARM way (even though being hardened) would have better real-time performance then many OS-less soft processors each doing a very specialized single task.

What do you think ?

 

[TrickyDicky]

Where hard arm chips (and external arm previously) really help is with comms. Running an OS maybe an overhead but it takes a lot of the comms IP out of the FPGA, with linux drivers readily available. Means you dont need a large USB and ethernet core in your FPGA. You also get video decoders/encoders on arm cores now, again taking burdens off the FPGA to a degree.

Also remember power requirements. A load a soft cores in a large FPGA is probably going to use a load more power than a hard core in a small fpga, and even more so than an external asic.

--edit - apparently s uck is a rude word!?

 

[shaiko]

I really don't think that an FPGA with a cortex A9 would be a good choise for me.
My application is VERY HARD Real-Time and involves controlling 4-8 motors.
The motor control algorithm is very complex - so implementing it in pure RTL would take too much time. The software approach however uses floating point arithmetic.

I thought about having a single soft core control a single motor (the number of processors would equal the numbers of motors in the system).
I also want the solution to be plattform independent so I avoid using Nios or Microblaze.
The options I thought about are: LEON 4 or OpenRISC.

What do you think about this approach ?
Ever tried doing FP on a soft-processor ?

 

[FvM]

But today "data processing implemented in FPGA" may take the form of a soft-processor (one or many) deviating from the traditional hardware blocks approach.

Soft processor and FPU for soft procesor is a different topic. It should be clearly distinguished from a discussion about floating point in FPGA.

 

[shaiko]

Soft processor and FPU for soft procesor is a different topic. It should be clearly distinguished from a discussion about floating point in FPGA.

Why ?
Should an FPU intended for general purpose be any different from one use as a co-processor for a soft core ?

 

[TrickyDicky]

Yes. The power of the FPGA is the ability to massively parrallelise the floating point arithmatic. you wouldnt get that with soft cores.

 

[shaiko]

TrickyDicky,

Why can't a soft-processor use a massively parrallelised FPU ?

 

[FvM]

A soft-processor is operating sequntially and won't take advantage from parallel arithmetic.

In particular, soft processors are usually slower (in terms of instruction frequency) than hardware processors residing on the same silicon technolgy, This is e.g. illustrated by the ARM9 hardware processors available with Cyclone V. Nevertheless, software processors can compensate this restrictions by implementing specfic operations in dedicated (programmable) hardware, the technique is called hardware acceleration. You can also impelemt custom instructions for specific operations.

Without referring to specific data processing applications, the discussion seems somehow bloodless to me. If you imagine an application that demands "real time" floating point operations, we should discuss it specifically.

 

[shaiko]

I agree.
I'll start a new post.
BTW, I'll appreciate if you give your inputs to my last question in this post:

https://www.edaboard.com/threads/280461/