FPGA Processor for Signal Processing ?

You find at the web and in books implementations of processors for FPGA
=B4s and also processors like Picoblaze and Microblaze from firms like
Xilinx. Are there also implementations of processors special designed
for signal processing that realize things like FFT for example ?

Thanks for help

On May 3, 11:18 am, HansWernerMarsc...@web.de wrote:
> You find at the web and in books implementations of processors for FPGA
> =B4s and also processors like Picoblaze and Microblaze from firms like
> Xilinx. Are there also implementations of processors special designed
> for signal processing that realize things like FFT for example ?
>
> Thanks for help

If you're performing signal processing, straight FPGA logic is more
suited to this than using the resources to instantiate a general
purpose processor with built-in DSP extensions. Since most signal
processing applications can be performed in parallel, this can be
exactly realized in the FPGA fabric rather than attempted by having
"very fast" computational pipelines in a DSP processor.

If you are hard pressed on having a GPP, then why not look at DSP co-
processors to perform the functions you're looking for: FFT, L/HPF,
etc. Depending on the base architecture you start with you have
options like using the FSL on the Microblaze to have a low-latency
communication interface, or the ports on the Picoblaze. Although,
depending on the algorithm(s) you are planning on running it may be
difficult to get by with the standard Picoblaze because of its limited
instruction memory.

-- Mike

On Sat, 3 May 2008 08:18:33 -0700 (PDT), HansWernerMarschke@web.de wrote:

>You find at the web and in books implementations of processors for FPGA
>�s and also processors like Picoblaze and Microblaze from firms like
>Xilinx. Are there also implementations of processors special designed
>for signal processing that realize things like FFT for example ?

Yes and no. There are certainly components which realize FFT only, or FIR filter
only, etc. But I don't know of any "DSP oriented" CPU blocks. I believe these
would typically be larger than Microblaze etc, and typically much slower than a
pure FFT component. Therefore they would usually give you the worst of both
worlds.

The effort spent generating optimal code for such a DSP engine is probably
better spent generating optimal hardware to realize the same function; you are
likely to gain a lot in performance.

(I realize there are probably exceptions to this principle, but my perception is
they are relatively small niches).

- Brian

On 2008-05-04, Brian Drummond <brian_drummond@btconnect.com> wrote:
> The effort spent generating optimal code for such a DSP engine is probably
> better spent generating optimal hardware to realize the same function; you are
> likely to gain a lot in performance.
>
> (I realize there are probably exceptions to this principle, but my perception is
> they are relatively small niches).

In principle I agree with you, but in practice I can see quite a few advantages
to an FPGA optimized DSP processor. Consider for example a video conference
application with DVD quality video and audio. You probably want to have custom
hardware for most of the video encoding and perhaps decoding as well. However,
I don't think there is any need for custom hardware for audio encoding/decoding.
But it might make sense to use a specialized DSP processor for that encoding and
decoding so that more CPU time is available for other parts of the system (part
of the video decoder for example).

So in this case, instead of making custom hardware for both video encoding/
decoding and audio encoding/decoding, a generic DSP processor block can be used
for many tasks. This will most probably reduce the total logic area and it will
certainly reduce the design time of the application.

/Andreas