- Microchip 32-bit Microcontrollers Gain High-Precision Floating Point Capabilities
- Jeff Bier’s Impulse Response—Why Do Embedded Processor Software Development Tools Suck? It’s the Unknown Knowns
- Case Study: BDTI's Expert, Independent Analysis Enables Optimum Vision Processor Selection
- Texas Instruments Sitara SoCs Integrate Diverse Processing Resources
- CEVA Software Framework Brings Deep Learning to Embedded Vision Systems
MathWorks' HDL Coder and Verifier: High-Level Synthesis Expands to MATLAB Users
In one of last month's InsideDSP articles, I wrote:
As FPGAs have evolved, the means by which engineers create FPGA designs have also evolved. In particular, design techniques employing increasingly higher levels of abstraction have been required to address the increasing chip capabilities. Initial FPGA design flows were schematic-based. These later gave way to HDLs (hardware description languages) such as VHDL and Verilog. And more recently, C-language-based high-level synthesis has entered the mainstream, after years' worth of research and development and early-adopter experimentation. Effective high-level-language-based FPGA design flows have become desirable (by implementers) and sought after (by suppliers), since at least in theory they can enable big gains in design and verification productivity.
At the time, I was specifically referring to the cost-effective C-language-based design flow built directly into Xilinx's latest-generation Vivado toolset, versus the multi-thousand-dollar C-language add-in for Xilinx's precursor ISE toolset. But the description is more generally applicable to all FPGA (and ASIC, for that matter) designs, as well as to multiple high-level synthesis languages. Additionally, as I wrote last month:
C-language-based flows are particularly attractive in that they offer the potential for relatively straightforward hardware acceleration of functions that would alternatively run in software on a system processor. Enabling flexible (and rapid) movement of the hardware-versus-software partition in order to assess design alternatives becomes increasingly attractive once the FPGA fabric and the microprocessor share the same sliver of silicon.
Another desirable development flow attribute is the ability to directly migrate from the toolset and language used for algorithm and system modeling purposes into the methodology used to implement the design within a FPGA (Figure 1).
Figure 1. A unified development environment leveraging a common description language for both modeling and design is increasingly appealing as application and silicon complexities increase and time-to-market schedules decrease
All of these characteristics are evident in MathWorks' product line evolutions of recent years. The company's MATLAB and Simulink products commonly find use, respectively, for algorithm modeling and development, and for system simulation and model-based design. According to Ken Karnofsky, Senior Strategist at MathWorks, Simulink has supported simulation-to-C language capabilities since the early 1990s. Similarly, MATLAB has provided C language generation facilities since 2007.
However, if FPGA fabric is the implementation destination, C code represents a superfluous intermediate step in the process. As such, MathWorks added direct-to-HDL facilities to Simulink in late 2006. And earlier this year, the company did the same thing for MATLAB (the more commonly used of the company's two primary products, for digital signal processing algorithm development purposes), enabling the generation of portable, synthesizable VHDL and Verilog (Figure 2).
Figure 2. HDL Coder, which has supported direct Simulink-to-VHDL and Verilog generation capabilities for more than five years, added MATLAB support earlier this year (top) via a straightforward user interface scheme (bottom)
HDL Coder for MATLAB underwent a year-plus beta program ahead of its release in March, beginning with two early-adopter customers and later expanding to approximately a dozen more. Automatic floating-to-fixed point conversion capabilities are built into the toolset. And Karnofsky claims that the HDL efficiency results are, on average, within 20% of those delivered by hand-crafted HDL code, similar to the efficiency of HDL Coder for Simulink. However, HDL Coder doesn't currently support IP library blocks provided by IC manufacturers such as Altera and Xilinx.
MathWorks has also expanded the product formerly known as EDA Simulator Link (in its Simulink-only form) to also comprehend MATLAB, renaming it HDL Verifier. As its name implies, it aspires to automate Verilog and VHDL verification by using MATLAB or Simulink to stimulate HDL code and analyze its response. The approach, MathWorks claims, eliminates the need to author standalone test benches. HDL Verifier now supports more than 15 evaluation boards from Altera and Xilinx, as well as co-simulation via both Mentor Graphics' ModelSim and Cadence's Incisive simulators. And you can feed HDL Verifier both the output of HDL Coder and your hand-written HDL code (Figure 3).
Figure 3. HDL Verifier validates both HDL Coder-created and handcrafted HDL code against MATLAB and Simulink design models (top), interacting with both software co-simulation products and FPGA manufacturers' evaluation boards (middle). HDL Coder and HDL Verifier combine to form a closed-loop, MathWorks-centric development environment (bottom)
The list price for HDL Coder, now a unified product supporting both MATLAB and Simulink, begins at $10,000. MATLAB, along with the fixed-point toolbox and HDL Coder, costs approximately $20,000, according to Karnofsky. And the pricing for HDL Verifier, also now a unified product supporting both MATLAB and Simulink, begins at $3,500. Clearly, HDL Coder (for example) is pricier than the C-language support built into the earlier-mentioned Vivado toolset from Xilinx.
However, given the enduring popularity of both Simulink and (especially for InsideDSP readers) MATLAB in the design community, HDL Coder and HDM Verifier may still prove to be a compelling combination as their feature sets mature (supporting silicon vendor-supplied and third-party IP cores in the future, for example) and if the company's HDL efficiency claims bear out under real-life scrutiny. The products will be particularly attractive to companies that prefer chip-vendor-independent tools and are unwilling to buy from small suppliers due to risk, whether actual or just perceived.