The days where FPGAs were performing only glue logic are long gone. Thanks to impressive innovation allowing increased processing power, reduced power consumption, and device cost reduction, FPGAs are now everywhere, and are clearly gaining ground on the default processor used for such tasks : digital signal processors (DSPs).
Considering the huge amount of DSP-compatible legacy C code previously present in many industries, and the importance of building on top of this legacy code in order to release products to market quickly while minimizing risks, one has to admit that the value added of FPGAs had to be quite significant for it to be adopted in new projects. Yet, it happened.
It is impressive to consider the initial development environment early FPGA designers had access to. Forget about block diagrams, you just had to get your hands dirty if you wanted it to work. Those early adopters were literally going through a nightmare in order to get their projects implemented. They REALLY needed the extra processing power FPGAs had to offer. But as we look at the market offering right now, we are forced to admit that FPGA vendors and members of their partner network did put a lot of effort in resolving this issue. The development environment is now quite elaborated and does not only allow creating FPGA-based products without coding a single line of VHDL, then even now allow porting of thoses projects from a vendor to another (and even to an ASIC), and are also coping with ARM/PPC/CPU integration. Let’s have a look at the range of tools available.
Vendor Specific Tools : Xilinx System Generator / Altera DSPBuilder
I still remember when we were asked to evaluate the first version of Xilinx System Generator for DSP something like 12 years ago (or more?). No VHDL anymore, just connect blocks together and you are done. At the time, it simply did not work. How could we possibly recommend this to our customers? We did not.
Soon, Altera also followed with their DSPBuilder tool. In the next years, the tools evolved as did the market demand (people could not wait to get out of VHDL), and very quickly they matured and became much more reliable. As multichannel FPGA systems vendors, we were at the first stage to see the mutation in demand happening, integrating to such model-based design tool was now a must if we wanted to serve our customers well. This is especially true since most FPGA algorithms became more and more complex. Developers for Wireless systems, MIMO Radar, In Vivo Imaging, Luggage Inspection, and similar applications definitely needed any help they can get to make their life easier.
Regardless of the evolution, there are still limitations present today. One example is that both tools still have a hard time coping with multi clock domain designs. Also, both Xilinx System Generator for DSP and Altera DSPBuilder are device-specific. A major problem for any company requiring the flexibility to move from one vendor to another, or even the possibly go toward the ASIC option, should volume justify it.
Enters The Mathworks : HDL Coder
The Mathworks is a company famous for their MATLAB product. They also pioneered the model-based design approach and automatic code generation, thanks to their Real-Time Workshop tool, which generated C code automatically from a Simulink block diagram.
Hence, initially, focus was mostly on C-based processors (DSPs, GPPs, PPCs, CPUs, etc). Several hardware boards (including Nutaq) were integrated to this tool over the years, with great success especially for the the CPU side and their xPC Target solution.
Completing this offering for the FPGA side, The Mathworks also came up with HDL Coder™ a few years ago (http://www.mathworks.com/products/hdl-coder/), a tool that ‘’ generates portable, synthesizable Verilog® and VHDL® code from MATLAB® functions, Simulink® models, and Stateflow® charts.’’ As previously stated, this clearly resolves a major concern in the industry. If legacy code reuse plays a key role in product development and risk management, who wants to design their next flaghship product around an FPGA vendor they will be forced to use for the remaining 10 years or more? For those not willing to lock themselves that early in the design process, HDL Coder™ is the solution.
Team Work : GNU Radio
Another reality most multichannel FPGA system developers are now facing is that of co-processor integration. FPGAs seldom operate alone in a system. In some cases, they are hooked up to a DSP processors, in other cases, with an ARM processor, and so on. In those cases, having a homogeneous development environment, entirely based on the model-based design approach, is highly valuable. This allows exploring algorithms at a higher level before having to involve a C code programmer.
Simulink such C-based simulation, but a more popular option nowadays is GNU Radio, a free and open source development environment which became highly popular mostly thanks to a striving wireless community user base.
Figure 2 : Example of a GNU Radio block diagram
Several hardware vendors are now interfacing their hardware to the GNU Radio environment, some of which are FPGA-based (like Nutaq – surprise!). Currently, it seems each community has its own ‘GNU Radio’ since it is tightly linked to the final application (as an example, particle accelerators have EPICS). However, we expect GNU Radio to expand to other markets such as radar for example. Only time will tell if it gets adopted beyond wireless centric markets, but for the moment, it is definitely a key tool to consider for any hardware system vendor.
The arrival of such an elaborated software development offering is a huge advantage to the system developers. Product line managers can now create prototypes without having the R&D team code a single line, enabling quick feedback from their potential customers early in the design stage. The positioning of each software tool can be resumed as :
- Xilinx System Generator for DSP and Altera DSP Builder allow device-specific model-based design
- The Mathworks HDL Coder provides extra flexibility by generating synthesizable Verilog® and VHDL® code
- GNU Radio and Simulink handle the host PC/CPU/GPP/ARM side of things
What was complex to implement 10 years ago, is now doable within minutes. This is not to say that developers’ life is now easy.
Just like for video games, time which was then spent on code optimisation is now spent on integration of several processors performing tasks significantly more demanding than what they once where. The new tools are only there to make the challenger bigger, not easier.