When are FPGAs the right choice?

i think FPGAs is a good choice when

1). there's lots of data parallelism inside the algorithm you gonna run on FPGAs. FPGAs is enabled to exploit such data parallelism and achieve amazing performance;

2). when your design needs to change frequently, FPGAs is a good choice b/c it can be configured tens of thousands of times without bothering PCB change;

3). also, low volume > I've been programming embedded micros for a long time, and have a

Hi Mike, Did you try Google? fpga vs microcontroller Please come back when you have a specific application in mind that a Google search does help with. Cheers, Syms.

p.s. It's very close on Googlefight!

Looking at an FPGA as a 'step up' from a MCU, the primary advantages are Speed, Parallelism and Pin count. The downsides are power consumption, power management ( multiple rails), packaging ( BGAs etc.) and availability (fewer parts routinely available off-the-shelf) .

e

Well, I wasn't really thinking in terms of fpga vs. micro, although I'm sure that's one tradeoff. I was asking more about fpga (with or without a soft core) vs. every other solution, and when fpgas are the right choice, and when they might not be the right choice. Does that make sense?

And I don't have any application in mind - just interested in expanding my horizons.

Mike

Googlefight!

Hi Mike, OK, in your OP you mentioned micros, that's why I replied as I did. I'm unsure what else you want to compare with. DSPs are the other old chestnut. Google works for that also! CPLDs? 74 series logic? Cheers, Syms.

When you cannot do the task with a Microcontroller alone. It is very common to have both, so then the question is one of task allocation, rather than "when an FPGA is the best choice".

Micros have advanced quite a bit in recent times, and Atmel are claiming above 200MIPS from flash with AT91SAM9XE series. This uses 128 bit fetch & starts at $7.30/10K

- so that device would make a good FPGA companion.

-jg

CPU's are serial, they do one thing at a time. One other thing is they can't be clocked by an external transition, ie. that their time to respond to an external event is VERY finite.

Something I have made a LOT of are quadrature encoder counters, where you don't want to miss transitions on the quadrature lines. I have the counter clocked at 1 MHz, so I can implement some digital filtering on the quadrature inputs. This allows the counter to count with absolutely guaranteed reliability up to at least 300,000 counts/second. One FPGA handles 4 channels like this with parallel logic. I'd challenge anyone to make a traditional microcontroller do this without dedicated logic on the CPU, just by sampling the input ports. This is a trivial exercise on an FPGA. I also generate PWM signals with 100 ns resolution. This could be done easily with counter/timer functions.

Jon

When you have algorithms that can benefit from: * Parallism * Pipelining * Tight I/O timing

FPGA might be an improvement over an asic microcontroller in these cases.

FPGA enables you to replicate a microcontroller in FPGA. And add instructions for special hardware operations such that you can combine the simple structure of an MCU with the performance of lowlevel gate operations.

FPGA gates are however slower compared to ASIC. So one challenge is to use it in a way that it doesn't matter.

The general answer is that the FPGA is the best fit when the FPGA-based solution is less costly than the non-FPGA-based solution. However, one usually has to consider development and support costs, not just the BOM cost of the hardware.

So how does one determine which will be less costly? The only way I've found is to do at least a rough block diagram and BOM for each.

For my designs, I've found that the choice isn't usually between an FPGA and something else, but rather between an FPGA alone, or a microcontroller with a smaller FPGA.

I think you could do it on a slightly non-traditional microcontroller, i.e. the Parallax Propeller, which would let you dedicate one cpu core to each set of I/O lines. Clocked at 80Mhz you would get up to 20 instructions per microsecond to deal with your 1 MHz event stream.

One of the primary design ideas of the Propeller seems to be that CPU cores are so cheap we don't need to support interrupts at all. You just dedicate a CPU to each external device and it basically operates synchronously with resepect to that device.

It's an interesting idea, and when mainstream processors start having

"throwing away" things like x86 cores in a similar fashion.

G.

Sounds reasonable. Is the more usual case then to have both micro(s) and FPGA(s) together, as opposed to FPGA without micro? Is FPGA without attached (or internal) micro an uncommon situation?

Mike

Surprisingly few uC have Quadrature inputs, given that the logic is not large in uC terms.

Winbond have just released a group (W79E22x), with encoder to 1/4 FCPU per half period ( so max INC/DEC rate is fCPU/2 I think )

The old 89C52 added DIRN, which allows a coarse quadrature support, of one INC/DEC per whole cycle, but that's only one quarter of the possible resolution. A small PLD can pre-condition to give the higher resolution.

ns resolution. > This could be done easily with counter/timer functions.

Or a CPLD, where it will fit.

A common weakness in uC, is that the Peripherals cannot clock faster than the core, so you can get situations where you need a fast CPU clock, just to run the peripherals (and get the power impact of that in the core)...

Of course, most modern FPGAs are not helping the power budgets at all... :(

-jg

Let's hope they throw away the whole x86 architecture. It's flawed from the start.

management ( multiple

available off-the-shelf) .

In terms of power per equivalent operation, the FPGA nearly always wins over the DSP micro. I find the FPGA (assuming an efficient implementation) is typically around 20% of the power of a DSP micro for a given process sample rate. In other words, the FPGA can operate a significantly lower clock rate than a DSP micro operating on the same data stream. The clock rate is a huge factor in power dissipation.

The biggest drawbacks for FPGAs are the relative immaturity of the tools and the relative scarcity of design talent. My usual recommendation is that if an application can be handled with a single DSP micro, that is the proper venue for it, as it is cheaper and easier to obtain the talent needed to bring the design through development.