The following is an excerpt from a recently published white paper. Click the link at the bottom of the excerpt to read the entire paper.

Efficient DSP Algorithm Development for FPGA and ASIC Technologies

Shiv Balakrishnan,Technical Marketing Engineer, and Chris Eddington, Senior Technical Marketing Manager, Synplicity, Inc.

Introduction

The use of Digital Signal Processing (DSP) in electronic products is increasing at a phenomenal rate. Field-Programmable Gate Arrays (FPGAs), with their multi-million equivalent gate counts and DSP-centric features can offer dramatic performance increases over standard DSP chips. They also offer an attractive alternative for small and medium volume production FPGAs also make very powerful prototyping and verification vehicles for realtime emulation of DSP algorithms [1].

This paper discusses the challenges and requirements of creating portable algorithmic IP for FPGAs and ASICs and illustrates how an ESL synthesis methodology using Synplicity's Synplify® DSP tool can significantly reduce the time and effort to implement either technology. The Synplify DSP tool automatically creates optimized logic implementations for both FPGAs and ASICs.

Challenges In Porting RTL Between FPGA and ASICs

The design team might ask: why is porting RTL between FPGAs and ASICs a problem? After all, isn't RTL (synthesizable Verilog and VHDL) supposed to make the design portable? The answer can be quite lengthy and varies depending on the type of design. But for DSP algorithms, a general answer is that the RTL often specifies the exact mapping of key operations like multipliers, adders, and storage. Another way of saying this is that although the RTL is portable at the logic level, it is not at the architectural level. If synthesized to a different target, the same RTL will yield less than ideal results; in a different target technology, the result may be functionally correct but very sub-optimal.

Choosing an algorithm architecture involves the basic question of how much pipelining, parallelization, or serialization is needed to meet the sample rate and throughput requirements of the algorithm. In addition, fundamental DSP functions like FIR, FFT, sine, cosine, divide, etc. may have different optimal implementations depending on the target technologies. A good example is the direct form versus the transposed form of a FIR filter - one may be better for a particular FPGA device [2], and the other may be better for an ASIC technology.

Different architectures are usually required to get good results from an FPGA versus an ASIC. It's commonly known that FPGA devices tend to be more register-centric, and many ASIC-to-FPGA porting guidelines recommend lots of pipelining, registering of all ports, and breaking combinatorial logic into smaller portions. This results in an area increase if done in the ASIC, but might be required to meet timing in the FPGA [2].

For an ASIC target, the opposite is often desired. Register minimization is recommended to reduce area and power. Higher clock speeds can be exploited using time-multiplexing and resource sharing techniques to minimize multipliers and other expensive operations. Recent designs for the consumer and wireless markets balance these demands carefully.

One of the inevitable differences between ASIC RTL and FPGA RTL is the use of memory. In an FPGA, standard memory types are built into the device. Depending on the FPGA tool flow and vendor, specific coding styles are required to describe storage arrays and memories. High quality FPGA synthesis tools automatically infer memory use from the RTL. However, in the ASIC world, there are many different memory options available from IP and fab library vendors. Users select and compile memory for a particular configuration, and instantiate it into the RTL design.

There are many articles and resources describing the coding styles and porting techniques needed to move IP between FPGAs and ASICs. [1, 3, 4] Such techniques include pipelining and building memory wrappers for handling resets, enables, and other differences between FPGA and ASIC memory interfaces. Suffice to say that it requires a significant amount of coding, verification, and expertise to move implementations between technology types.

Additional porting challenges arise in ASIC designs first prototyped in FPGAs. This occurs when real-time stimuli and at-speed verification are required. To support these requirements, it is necessary to maintain bit and sample accuracy between simulation models, in particular the FPGA implementation and the ASIC model. This can require a lot of effort especially if the implementations are different or changing rapidly, and the test harness must be manually modified, compared, and debugged.

Click Here to download the entire white paper (registration required).