Speeding DSP solutions with FPGAs
Speeding DSP solutions with FPGAs
By Susannah Martin, Senior Design Engineer, Xilinx Inc., San Jose, Calif., EE Times
December 9, 2002 (2:19 p.m. EST)
URL: http://www.eetimes.com/story/OEG20021206S0012
FPGAs can provide a fast, cost effective solution to many of today's complex demands for DSP functionality. However, many DSP engineers have traditionally focused on software, and may not know where to start when it comes to hardware. Essentially, there are three distinct design methodologies that DSP engineers can consider: design with Intellectual Property (IP), traditional design with Hardware Description Languages (HDLs), and compiling the C programming language into hardware using some of today's new tools. There are a few reasons that you might consider for using an FPGA to implement DSP solutions. The first is for increased performance. Even though today's DSP processors are fast and are useful for many DSP applications, there are applications out there that need a little extra boost of performance and FPGAs provide increased performance. For example, the FPGA will be programmed with a custom hardware design therefor e control logic can be implemented in the hardware. Precious clock cycles will not be used implementing control functionality. Also, FPGAs allow extra performance by tailoring the hardware architecture. If the most important design consideration is speed, then a fully parallel approach for the processing algorithm can be designed in an FPGA. One of the most popular applications for DSPs in today's FPGAs is video processing. Other applications that benefit from the performance boost include radar, ultrasound, and high speed modems. Another reason for using an FPGA for digital signal processing is that many of today's systems already contain an FPGA for protocol translation, glue logic, or some other system function. If that FPGA is not being fully used, pulling DSP functionality into it could provide cost savings for the system. And, there is no risk associated with FPGAs if a standard changes. The configuration files for FPGAs can be updated much like software, since they must be stored in non-volati le memory in the system. If at all possible when designing with an FPGA, it is desirable to stick with a fixed-point number system. There are several reasons . The first is that all embedded logic (multipliers, accumulators) within the FPGA has been designed to function as fixed-point elements, as have most cores that have been designed for FPGA use. Secondly, floating-point implementations are complicated and quite large in hardware. The expense of a floating-point solution in development cost and per-piece cost is probably not worth it. Finally, the fixed-point format within an FPGA should provide enough flexibility for the user since the number of bits used to represent a number can be chosen by the user, and the user may design truncation and rounding wherever necessary to make a fixed-point implementation practical. When determining how many bits should be used in the fixed-point implementation, keep in mind that every extra bit used provides approximately 6dB of increased signal to nois e ratio. Just as there are many software languages and some are more appropriate than others for different situations there are many ways to create your FPGA design. The first design technique is designing with IP cores. This is the easiest technique since the cores have already been designed and optimized. This technique usually offers the best end result, since experts have designed each core to use the best implementation for an application and the architecture of the FPGA. Most of today's cores are very configurable, for example, parallel versus serial implementations and symmetry exploitation. So, it is very likely that a core can be found to match most requirements. Some tool vendors and FPGA vendors even offer cores that can be implemented using traditional DSP system design software (tools such as Matlab), so that the learning curve is not so steep. Many cores that are common, such as FIR filters and multipliers, are free to the user. More complicated cores often requi re a licensing fee most of the time, this is a one-time fee. Overall, this is the best technique if the designer has little experience in FPGA design and can find a core to suit his needs at a proper price. Finding the right core However, it is not always possible to find a core that meets the particular needs of a system. Or the cores found only cover part of the functionality of the design. In this case, it is necessary to design hardware using one of the available HDLs. The traditional HDLs are VHDL and Verilog. However, C is also becoming an HDL, and more tools are beginning to support hardware synthesis from C code. HDLs allow you to fully customize your design, and can also be used along with IP cores the IP core is simply instantiated or "called" within the HDL code. Along with learning HDLs, the designer will need to learn to use a logic synthesizer, which takes the HDL code and maps it to actual hardware. The traditional HDLs, VHDL and Verilog, have b etter tool support but might require new learning on the designer's part. Most DSP engineers already know C, but the software support is not as robust and the optimum design performance might be harder to reach. If C is decided upon as the HDL, it is important to not just re-use C code that has been used for a software implementation of DSP and try to map it into hardware. This will result in a very non-optimum implementation. The C language should only be used for the convenience of using a language that is already familiar to the designer. The code should be written after the implementation has been decided upon, so that the code reflects the implementation. Since it is possible and desirable to do parallel operations in hardware, and this is not possible in the C language which was created for software which operates purely sequentiall ways have been devised to allow the C language to support parallel operation. The designer should learn how to efficiently write parallel constructs in the C language before attempting to design hardware. These constructs vary slightly from tool vendor to tool vendor. You now have a starting point to implement your DSP function within an FPGA. The most important things to remember in implementing your design:
Related Articles
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |