Speed test between FPGA and DSP or PC.

There are 3 kinds of lies: lies, damn lies, and benchmarks. ;-)

For instance, in FFT benchmarks, the quoted speeds for DSPs are produce from carefully-optimised Assembler sub-routines. For an FPGA, the spee will depend on how many multipliers are being used in parallel, and th pipelining of the data flow. The implementation is likely to be optima for one length of transform only.

The usual suspects for good results in FPGAs are:

- DNA pattern matching (smith-waterman algorithm)

- DES breaking

- logic simulation, especially fault modeling and ATPG

But essentially all these benchmarking in the hardware field only tests your grad studen vs. my grad student. For example have a look at commercially available AES or Reed-Solomon- Decoders. There is a variance in efficiency (processing power per LUT) of several orders of magnitude. So how do you compare that to a DSP implementation? The same DSP implementation might be 10x faster as one FPGA solution and 10x slower than another.

And this is essentially the result of past research in that area: For anything that does not fit perfactly on the MAC-Architecture of current DSPs the FPGA has the higher potential processing power. However, it is much easier to exploit the potential of an DSP compared to the potential of an FPGA. A large FPGA in the hands of someone like Ray Andraka is extremely fast. Your avarage EE Major however might be better of with a DSP.

Kolja Sulimma

What's wrong with that? Do you go hunt for some crappy code when you need a FFT routine? Do you avoid routines in the c library if they have been hand optomized?

It helps if they say what code they are using and how to get it. It's even better if it's open source.