In many ways, the evolution of programming FPGAs has paralleled the programming of DSPs. In the early days of DSP, programs were written entirely in assembly language. Today, DSP programmers typically start with a high-level language such as C, and then optimize the "hot spots" using intrinsics or hand-coded assembly. Similarly, FPGA designs were once crafted in Verilog or VHDL. Today, FPGA designers often start with a high-level description in an ESL tool, and then optimize hot spots using IP blocks or hand-coded VHDL or Verilog.

This transition is a good thing. Five years ago, you couldn't build much of anything in an FPGA without hardcore FPGA skills. This put FPGAs out of reach for most DSP programmers. Thanks to ESL tools, the average DSP programmer can now make the leap to FPGA design with a reasonable amount of effort, and produce reasonably optimal designs.

However, FPGA tools have not replicated the evolution of DSP tools in one important area: DSP compilers have a common entry point, namely ANSI C. ANSI C code can be use with any compiler and any DSP. Granted, optimized DSP programs usually contain non-ANSI C code, but this common starting point makes it relatively easy to change tool chains and/or DSP platforms. What's more, a programmer only needs to learn C, and they will have the basic knowledge they need to program any DSP.

In contrast, ESL tools for FPGAs have many different entry points. Tools like Catapult C and Impulse C use C or C++ as an entry point. Xilinx's AccelDSP uses the MATLAB language. Other tools use a graphical dataflow, such as Simulink or LabView. What's worse, devices from different vendors have different (and incompatible) high-level tool flows. Since designers often use more than one tool flow—and may have to learn multiple unrelated "languages" to get the best results—the learning curve for FPGA design is still unnecessarily steep. Furthermore, if designers switch tool flows or FPGA vendors, they have to start the learning process all over again.

The need for a common design language has not gone unnoticed. The best candidate for such a language is SystemC, a set of C++ libraries and macros. SystemC is an open standard and is being promoted by Cadence, Synopsys, and Celoxica. In a recent report, the Open SystemC Initiative (OSCI) reported strong and growing adoption of SystemC. A survey conducted by the group shows 53% of survey respondents using SystemC in production today.

One problem with SystemC is that despite being based on C++, it is still essentially a hardware description language. This makes SystemC less accessible to software developers. However, SystemC could provide a language worth the learning curve—and it could allow tools to talk to each other. If SystemC continues to gain momentum it may bode well for FPGA development in the same way that the adoption of ANSI C has benefited DSP developers.