The HDL Coder is a MATLAB toolbox used to generate synthesizable Verilog and VHDL codes for various FPGA and ASIC technologies. The Xilinx System Generator, on the other hand, is a Xilinx product used to generate parameterizable cores, specifically targeting Xilinx FPGAs. This application note draws a comparison between the design flows with these two toolboxes, especially in context of Software Defined Radios (SDRs), which all come with onboard FPGAs.
With the rapid advancement in FPGA design technologies, hardware and software providers have been working towards producing more advanced and user friendly tools for designing and testing FPGA programs. The emphasis lies on rapid prototyping of the FPGA design, even with minimal knowledge of Verilog and VHDL programming languages. To this end, two commonly used tools include MATLAB HDL Coder and Xilinx System Generator Blockset, both of which can be used with MATLAB Simulink. Both these tools enable the developers to use Simulink model environment, with drag and drop blocksets, for designing their algorithms without having to write a single line of VHDL code, even for very large and complex designs. In this brief article, we outline the design workflows using these toolboxes in context of SDRs.
MATLAB HDL Coder
The HDL Coder, provided by Mathworks, is a MATLAB toolbox which generates target-independent, portable and synthesizable Verilog and VHDL codes, which can then be used for FPGA programming and ASIC designing. The toolbox works with different MATLAB functions, Simulink Models and Stateflow charts, converting the MATLAB design into equivalent Verilog and HDL codes. In context of SDRs, especially Nutaq SDRs, the Simulink design environment is recommended for rapid prototyping. While designing with HDL Coder in Simulink, the first step is to filter the Simulink Library Browser, such that it only shows the model blocks that are compatible with the HDL Coder. To this end, by typing “hdllib” in MATLAB command prompt, one gets the Simulink Library Browser showing only the supported blocks. At present, HDL Coder supports over 200 Simulink blocks, including Stateflow charts. Using these blocks, one can design the required communication and signal processing logic as a Simulink model file, by dragging and dropping various blocks into the design. HDL coder automatically converts floating point numbers into fixed-point. Furthermore, functions written in MATLAB mcode can also be integrated into the design. To check design results via simulations, different MATLAB tools could be used, including scopes, displays, etc. Blocks from Simulink Sources library can be used to generate test signals for the design.
Once the design results have been verified through simulations, the next step is to generate the HDL codes, which is done through Workflow Advisor, which comes with HDL coder. Through the Workflow Advisor, one can select different parameters for the design, including the Target workflow, the targeted platform, the targeted FPGA, declaring the external ports for the design, etc. In context of SDRs, the targeted workflow gives the option to select a customizable SDR platform, as shown in the Fig. 1 below, while the target platform gives the option to select the specific SDR platform, provided that the platform is supported by HDL coder. Lastly, HDL Coder can also generate VHDL and Verilog test benches for verifying the HDL design. However, to generate and use these test benches, an additional toolbox, HDL Verifier is required, which is explained later.
If the goal is to simply generate the HDL codes, HDL Coder can do that as a standalone tool within MATLAB. However, if one needs to synthesize the HDL code and generate a bitstream for the FPGA, third party synthesis tools, such as Xilinx ISE and Vivado, or Altera Quartus are required. To this end, Fig. 2 summarizes the design flow in a three step process. The first step refers to the model design using MATLAB functions and Simulink blocks. At the end of this step, HDL codes are generated which can then be synthesized using third party tools, like those mentioned above, and the bitstream is generated. Finally, the bitstream is downloaded onto the FPGA. HDL Coder has the ability to integrate the third party tools within Workflow Advisor, using the Synthesis tool option as shown in Fig. 1 above, thus providing a uniform and integrated environment (Simulink Environment) for all the processes, starting from model design all the way down to bitstream generation.
At this point, it is also imperative to mention that if one wanted to simulate and verify the generated the HDL codes, the HDL Coder alone is not sufficient and an additional toolbox, namely, HDL Verifier is required. With HDL Verifier, again, third party simulation tools such as Questa and ModelSim will be required. HDL Verifier provides an elegant and integrated environment for running HDL cosimulations with Simulink and third party tools. Additionally, it also provides “FPGA in the loop” feature, enabling the developers to test the design on actual hardware from within the Simulink environment. HDL cosimulation with HDL Verifier lets one verify that the HDL code matches the MATLAB algorithms and Simulink models by providing visibility into the HDL code. One can assess how differences between expected results and HDL simulation could affect the design at the system level.
Xilinx System Generator
Xilinx System Generator is an FPGA programming tool provided by Xilinx. It is specifically focussed on Xilinx FPGAs, enabling the developers to work in Simulink environment and to generate parametrized cores particularly optimized for Xilinx FPGAs. The tool comes built in with Xilinx ISE Design Suite (System Edition) and Xilinx Vivado HL (System Edition). By default, the Xilinx Blockset contains over 90 DSP blocks, ranging from simple adders, multipliers etc. to complex blocks such as Forward Error Correction blocks, FFTs, filters and memories, etc. Some of these blocks also support floating-point DSP. The Floating-Point library provided by Xilinx lists such blocks. Moreover, the System Generator also includes the mcode and Black Box blocks, which can be used to integrate mcode and HDL codes, respectively, directly into the Simulink design environment.
The system generator blocks do not automatically convert the Simulink floating-point numbers to fixed-point. Unlike the HDL Coder, where the floating-point numbers are automatically converted to fixed-point, the System Generator utilizes the Gateway In and Gateway Out Blocks to convert from floating-point to fixed-point and vice-versa, respectively, as shown in Fig. 3. The downside to having to use Gateway In and Gateway Out blocks is the potential to make mistakes during this conversion. For example, the designer has to be careful when selecting the number of fixed-point bits, whether the fixed-point number is signed or unsigned as well as the placement of binary point. Additionally, it is also time consuming, for example, when connecting Simulink scopes for design verification, as shown in Fig. 3, each input to the scope has to be passed through the Gateway Out block in order to convert from fixed-point back to the floating point.
As far as the rest of the modeling design process is concerned, the System Generator works quite similar to HDL Coder, i.e., users drag and drop various blocks into the Simulink environment in order to design the overall system. Users can then use MATLAB scopes and other sinks as well as elements of Sources library to check the design results. Since System Generator is already part of Xilinx ISE or Vivado HS, no additional synthesis tools are required and the users can generate the bitstream directly from within the Simulink environment. To this end, the System Generator token, shown as the red block in Fig. 4 below, needs to be added to the design. The System Generator token provides the users with functionality quite similar to HDL Coder’s Workflow Advisor, in that it allows users to select specific target workflow and platform, as shown in Fig. 4.
In order to check and verify the HDL codes through simulations, the System Generator can be used to invoke the default HDL simulator from Xilinx, which comes as part of the design suite and here again, unlike HDL Coder and HDL Verifier; no third-party HDL simulation tool is required. Nevertheless, System Generator is also compatible with third party simulation tools such as ModelSim, thus providing an integrated flow. Lastly, the System Generator also supports “Hardware in the loop” feature, which is the equivalent of “FPGA in the loop” feature of HDL Coder and HDL Verifier. To this end, the Hardware Co-Simulation drop-down menu within the System Generator token enables the users to perform tests on real hardware directly from within Simulink.
MATLAB HDL Coder and Xilinx System Generator both enable rapid prototyping of the FPGA design by utilizing MATLAB and Simulink environment. Both of these packages come with their associated pros and cons. The HDL Coder provides a complete integrated environment for the design flow. It supports a larger number of MATLAB Functions and Simulink Blocks. It also automatically converts the floating point numbers to fixed-point. Furthermore, HDL coder provides the means to generating target-independent Verilog and VHDL codes, which can then be synthesized for various FPGA platforms. On the downside, the HDL Coder alone is insufficient for synthesizing, simulating and verifying the HDL codes. Additional MATLAB toolboxes and third-party software are required to achieve these goals. The Xilinx System Generator comes as part of Xilinx design suits and is specifically tailored for Xilinx products. It also supports a sufficiently large number of DSP blocks, including those that support mcode, HDL codes, and floating-point DSP. Other than MATLAB itself, no third party software is needed, neither for generating HDL codes from Simulink blocks, nor for synthesizing and verifying the generated codes. On the downside, it is only limited to Xilinx products and requires manual conversion of Simulink floating-point numbers to fixed-point, which can be a time consuming and error-prone process.
04-11-2016, Auon Akhtar, PhD, Field Application Engineer