FPGA vs DSP

In which case I'd start with something like Wikipedia ( and ). These will give more of an idea about what they are and what they do. I would also investigate the links on those pages.

Andrew

A DSP is a microprocessor that's optimized to do vector dot products. If you're lucky it'll also do other math quickly. So it's a processor that runs machine code, just like an 8051, but unlike an 8051 it'll look up two numbers from memory, multiply them together, add the result to an extended-precision accumulator, increment the indexes of the two numbers, and check to see if it's done all in one clock cycle.

An FPGA is what it's name says: a field programmable gate array. It's got a bunch of undedicated logic elements (the gate array) on a chip that will connect them in a whole bunch of different ways (the programmable part), and instead of ordering it programmed from the manufacturer this configuration is done at power up or with a programmer (the field part).

So an FPGA has much more flexibility about what it can be made to do, but at the cost of more design time, a higher chip cost, and poor economies if you want to do something that's already done in dedicated silicon (like make a processor).

The more complex the algorithm and the more time you have to run it, the more you're going to want a DSP (or perhaps a really fast general purpose processor).

Two extremes that I've worked on are image uniformity correction and navigation solutions for integrating GPS and IMU. Both of these are DSP, but their complexity and speed requirements are vastly different.

The image uniformity correction fixes the output of an imager chip that has a pixel by pixel error in both gain and offset, so that after the imager is read out each pixel x{i} must be corrected with it's own individual correction algorithm: y{i} = a{i} * x{i} + b{i}. This means that for each pixel you have to read three different memory locations and write one (or you have to do so on average while juggling burst accesses).

If you did the image correction on a DSP chip (it can be done) you'd be constantly limited by the memory bandwidth, your algorithm would run out of less than 1% of the chip's ROM, and you'd never use more than 50% of the chip's logic to do your image correction.

The nav solution generally samples in the hundreds or tens of hertz. Often the GPS will sample at a different rate than the IMU. The data goes into a massive Kalman filter. The problem is quite nonlinear, so the filter is either nonlinear itself, or has a multiplicity of modes to deal with different facets of the solution.

If you tried to do this with an FPGA, either it would be huge, with huge swaths of logic that would lie idle for most of the time, only to get lit up briefly as the algorithm comes through. Or you would implement the filter as a huge state machine with some sort of a general-purpose ALU to do the math. Or you would implement a general-purpose or DSP processor on the FPGA, and write code for it in something sensible like C or C++ or Ada.

Because if you do floating point arithmetic 'correctly', i.e. if you dot all your 'i's and cross all your 't's it takes lots of logic and lots of work to get it right. By the time you're done you've used up a great deal of the FPGA for math that a floating point DSP chip already does for you, and that a fixed-point DSP chip can do with software emulation.

What image processing are you doing?

I thought it was asked because it was one of the assigned homework questions.

Jon

Take a seat over by the door. Your homework tutor will be with you in a minute...

In message , eryer writes

DSP is usually better than FPGA in most cases for commercial reasons.

I prefer to get my images from Public TV because they have fewer commercials.

Rick