Jeff Bier’s Impulse Response—Brainy FPGA Tools?

I’m starting to wonder if executives at FPGA companies are having conversations like those of the cartoon characters in “Pinky and the Brain”:

Pinky: “Gee, Brain, what are we going to do today?”
Brain: “The same thing we do every day, Pinky—try to take over the world!”

Clearly FPGA vendors are no longer content to provide a little glue logic here and there. A few years ago they started pushing hard into the multi-billion-dollar DSP space, and now (as I wrote in the April 2006 Impulse Response) they seem intent on having their chips taken seriously as embedded processors.

DSP is my home turf, so I’ve been watching the FPGA developments in this area quite closely. The FPGA vendors (and their tool-vendor partners) have recently been trying to attract DSP engineers by rolling out a slew of high-level DSP-oriented synthesis tools.

These tools promise to simplify the process of implementing a DSP algorithm or application on an FPGA. For some of us, they evoke a sense of déjà vu; ten years ago there was a similar wave of high-level synthesis tools targeting ASICs. Unfortunately, those tools never caught on. They promised more than they could deliver, and required engineers to do their work in new and unfamiliar ways—by using new languages, for example.

Sure, the new FPGA tools make for a good demo, but having witnessed a similar cycle ten years ago I’d ask some hard questions before signing a contract. Questions like:

1. For tools that support designs expressed in C, is it standard C, or some weird version of C that’s not actually portable and that no-one else knows? Can I use my existing C algorithm representation, or will I effectively have to rewrite my code to use the tool?
2. What level of efficiency is sacrificed by using high-level synthesis rather than doing the work by hand with traditional, RTL-based design?
3. What is the scope of applications that the synthesis tools are intended to handle? Are they geared mainly for signal processing, or can they also handle packet processing? Or databases?
4. How much of my design can the tools implement? For example, tool vendors often show how efficient their tools are at generating FIR filters from high-level requirements. That’s useful, but I’ll need to get data into and out of that filter, perhaps using chip I/O pins, buffering, bitstream parsing, or other steps. Do the tools handle my complete design?
5. What building blocks are provided? If my application relies on unique blocks not supplied by the vendor, what are the implications for productivity and quality of results?

My colleagues and I will be trying to get some answers to these questions in a study we’ve just launched on FPGAs for DSP applications. In “Pinky and the Brain,” Brain’s plans for world domination always go awry. Will the FPGA vendors be more effective in realizing their goals? Stay tuned!

Jennifer Eyre of BDTI contributed to this column.