For the last few years what we
Identify the sampling rate of the system design in consideration. If it is more than a few MHz, FPGA is the natural choice. What is the data rate of the system? If it is more than perhaps 20-30Mbyte/second, then FPGA will handle it better. How many conditional operations are there? If there are none, FPGA is perfect. If there are many, a software implementation may be better. Does your system use floating point? If so, this is a factor in favor of the programmable DSP. Are libraries available for what you want to do? Both DSP & FPGA offer libraries for basic building blocks like FIRs or FFTs. However, more complex components may not be available, and this could sway your decision to one approach or the other. The table below shows a direct comparison table for performance criterion.
MMAC is the number of fixed-point-32-bit or single-precision floating-point multiply-and-accumulate operations that can be executed in units of millions per second
In some high-performance signal processing applications, for example, FPGAs can take advantage of their highly parallel architectures and offer much higher throughput than DSPs. As a result, FPGAs' overall energy consumption may be significantly lower than that of DSP processors, in spite of the fact that their chip-level power consumption is often higher. Unfortunately, there is a dearth of accurate, apples-to-apples energy consumption data for FPGAs and DSP processors, making it difficult to compare their energy efficiency.
3.Form factor and Size
When sample rates grow above a few MHz, a DSP has to work very hard to transfer the data without any loss. This is because the processor must use shared resources like memory busses, or even the processor core which can be prevented from taking interrupts for some time. An FPGA on the other hand dedicates logic for receiving the data, so can maintain high rates of I/O. A DSP is optimized for use of external memory, so a large data set can be used in the processing. FPGAs have a limited amount of internal storage so need to operate on smaller data sets. However FPGA modules with external memory can be used to eliminate this restriction. A DSP is designed to offer simple re-use of the processing units, for example a multiplier used for calculating an FIR can be re-used by another routine that calculates FFTs. This is much more difficult to achieve in an FPGA, but in general there will be more multipliers available in the FPGA. If a major context switch is required, the DSP can implement this by branching to a new part of the program. In contrast, an FPGA needs to build dedicated resources for each configuration. If the configurations are small, then several can exist in the FPGA at the same time. Larger configurations mean the FPGA needs to be reconfigured – a process which can take some time.
4.Design Reliability and Maintenance
This is one area where we can always debate which is better reliable and easier to maintain. Experts say that with similar expertise of 2 engineers one on FPGA and the other on DSP, FPGA based system would be better in terms of reliability and maintenance. The reasons behind this are due to differences in the digital signal processor and FPGA engineering development process. There is a fundamental challenge in developing complex software for any type of processor. In essence, the digital signal processor is a specialized processing engine, which is constantly reconfigured for many different tasks, some DSP related, others more control or protocol oriented. The complexity of each task is more or less equivalent, no matter whether the design uses digital signal processor or FPGA implementation. Both routes offer the option to use third-party implementations of common signal processing algorithms, interfaces, and protocols. Each also offers the ability to reuse existing intellectual property (IP) on future designs. FPGAs offer a more native implementation for most DSP algorithms. Each task is allocated its own resources, and runs independently. It intuitively makes more sense to process each step of a continuously streaming signal processing chain in an assembly line-like process, with dedicated resources for each step. By comparison, FPGA designs tend to be updated much less frequently, and it is generally an unusual event for a manufacturer to issue a field upgrade of a FPGA configuration file.
5.Cost: Development Time, Time to market and risk
This is another potential item of debate. Some are of the opinion that Programming FPGAs is difficult, usually requiring a hardware-oriented language such as Verilog or VHDL. FPGA solutions can take an order of magnitude longer to code than DSP solutions which impacts development costs and increases time to market. The DSP can take a standard C program and run it. This C code can have a high level of branching and decision making – for example, the protocol stacks of communications systems. This is difficult to implement within an FPGA. But at the same time one can argue with the fact that most signal processing systems start life as a block diagram of some sort. Actually translating the block diagram to the FPGA may well be simpler than converting it to C code for the DSP. So looks like it all depends on availability of expertise.
At the end choosing between an FPGA and a DSP is dependent on several other factors apart from those listed above. In fact there is no global recipe to decide this as it’s a tradeoff business. It is the job of the architect to choose a platform that best meets the requirements of a specific system. I tried to give some insight into choosing the appropriate device for your design and hope this helps.
So why isn’t everyone using FPGAs for DSP?
• Lack of experience using these devices for intense computational applications.
• Algorithms developed for microprocessors can be difficult to translate into hardware.
• Immaturity of design tools for FPGA based DSP design
• Success of an FPGA DSP design is heavily dependent on the experience of the designer, not only in implementing designs in FPGAs, but also in tailoring algorithms for hardware efficiency.