Designing in System Generator for DSP

System Generator is different from all other Xilinx tools in that it embeds in a pro- prietary third-party design environment called Simulink. The access to the tool is provided through a catalog of blocks available in the Simulink library browser as shown in Fig. 8.2 . The process of designing is through drag and drop of built-in blocks on the drawing canvas and connecting input and output ports. All System Generator blocks can be distinguished from Simulink blocks due to the presence of the Xilinx logo. 

Xilinx System Generator Blockset 

The blocks provided for designing and implementing a system (or a portion thereof) are organized into libraries. Basic blocks that model mathematical operations like addition, multiplication, division, etc., are collected together in the Math libraries . Abstractions of Xilinx DSP IP like FIR Compiler and DDS Compiler are available 

Fig. 8.2 Xilinx blocks with X watermark to distinguish from Simulink blocks

through the DSP Libraries. Blocks that provide rich functionality like Viterbi decoder help accelerate design creation, while low-level blocks like AddSub allow users to customize their algorithms. In wireless communication applications, clock speeds are often as high as 491 MHz. Many of these blocks, therefore, expose parameters that can be tuned to achieve these speeds. For example, the Mult Block allows user to tune the latency which helps with pipelining the multiplier. Another option provided on the Mult Block is to use embedded multipliers (same as DSP48 slice) which help to close timing at higher clock speeds than implementing it on fabric (Fig. 8.3 ). 

Gateway In and Gateway Out 

The Xilinx Blockset contains two special blocks called Gateway In and Gateway Out that mark the boundary between the portion of the Simulink model that forms the test bench and the portion of the Simulink model that forms the design under test. All System Generator blocks must be driven by other System Generator blocks except Gateway In which is driven by Simulink blocks. All System Generator blocks can only drive other System Generator blocks except Gateway Out which can drive a Simulink block 

In Fig. 8.4 , Gateway In brings data from one of Simulink’s stimulus generator (source) block called Sine Wave , and Gateway Out connects the output of the design to a Simulink visualizer called the Scope block. 

Fig. 8.3 System Generator blocks can be parameterized to extract maximum performance

System Generator Token 

The System Generator token is a special block in the Xilinx Blockset library that holds information about the System Generator model. It captures project informa- tion such as compilation targets including IP Catalog and Hardware Co-simulation (Sect. 8.3.2 ), the top level HDL (VHDL or Verilog) to be used, Xilinx Part to be used, Target Directory in which the results of compilation should be placed, etc. The fi rst tab of the user interface for System Generator has been reproduced in Fig. 8.5 . 

Sample Times and Cycle Accuracy 

Simulink provides a generic framework for sample time propagation that can be used to model a variety of different continuous and discrete time systems . All System Generator for DSP blocks except the Gateway In only accept and propagate discrete sample times. A discrete sample time is a double-precision number that specifi es a time step in seconds. It can either be associated with signals or blocks. The discrete sample time associated with a block tells the Simulink engine when to update the outputs and the internal states of the block. 

Most System Generator blocks specify the output sample times as function of the input sample times and block parameterization. In general (with some nota- 

Fig. 8.4 Gateway In and Gateway Out blocks mark the boundary of the design under test

Fig. 8.5 System Generator token and its user interface

ble exceptions), the Simulink engine executes blocks at time steps that is a mul- tiple of the greatest common divisor of the sample times of all the inputs and outputs. For example, if the sample times of the inputs of a Xilinx AddSub block are 2 and 4, then the AddSub block will specify the output sample time to be 2. This means that at least one of the inputs change at 0, 2, 4, 6, 8 … seconds and output also changes at 0, 2, 4, 6, and 8. Between these times the values on the signals are held constant. This is a very important abstraction that helps with hardware design. 

Most digital designs make use of a clock that keeps time. A cycle refers to a unit of time representing one clock period. The System Generator token has a fi eld called Simulink System Period ( Tsim ) which accepts a double-precision number. This number relates the time in simulation with the time in hardware. An advance in time in simulation equivalent to Tsim corresponds to an advance in time in hardware of one clock period. 

Going back to the AddSub example, if Tsim was set to 1, a hardware designer’s interpretation would be that one of the inputs to the AddSub is held constant for two clock cycles, while the other input to the AddSub is held constant for four clock cycles. It also follows that Tsim for this particular example cannot be greater than 2 as any signal in an idealized (ignoring logic delays and clock skews) synchronous clock design cannot change between rising edges of clocks. In essence, Tsim time steps represent behavior of the system just after each rising edge of the clock in hardware. All Xilinx System Generator blocks provide a cycle accurate simulation behavior. 

Data Types 

The default built-in data type in Simulink is double , and many of the original built- in stimulus generators were only capable of producing double-precision data types (this has changed since the introduction of Fixed-Point Toolbox now known as Fixed-Point Designer). However, double precision is unsuitable for implementing many common DSP algorithms including audio and video signal processing in an FPGA because of the large number of resources it consumes. 

To address this issue, System Generator introduces two new data types in the Simulink environment: 

• Fixed- point data type 

• Floating- point data type 

Fixed-Point Data Type 

Fixed-point data-type format is characterized by the number of bits and binary- point location as shown in Fig. 8.6 . 

In many digital designs, interpretation of bits as numbers is important; however, it is not necessary to have a large dynamic range that double precision offers. For example, the output of a counter limited to a count of 15 can be represented using 

Fig. 8.6 Bit layout of an example fi xed-point number with number of bits set to 16 and binary point located at 13

Fig. 8.7 Specifying output type on the AddSub block to keep bit growth under check

four bits. Modeling values as fi xed-point data type introduces quantization errors and loss of dynamic range (when compared to double precision), but the resource saving afforded by fi xed-point type far outweighs these drawbacks. 

Most of the System Generator blocks operate on fi xed-point data type and on compilation propagate binary-point alignment as well as bit growth to ensure no loss in precision. For example, if an AddSub block confi gured as an Adder has two 16 bit inputs with binary points located at 8, by default the output bit width would be set to 17 with binary-point location at 8. This can have an undesired increase in resources due to bit growth. Therefore, many of these blocks also have options to specify what the output type should be to keep the bit growth in check. Figure 8.7 shows the user interface to specify the output type on some of the typical operators that show bit growth. 

Floating-Point Data Type 

System Generator also supports fl oating- point data type including double precision (64 bits), single precision (32 bits), as well as arbitrary precision. This is particularly useful in converting golden Simulink models to System Generator models as well as developing applications that require high dynamic range, for example, matrix inversion. To exploit the fl exibility offered by FPGAs, arbitrary precision fl oating- point data types are also supported wherein the user can explicitly manage the num- ber of bits for exponent as well as mantissa . 

Note that the support for fl oating-point data types is not as extensive as fi xed- point data types (i.e., only the blocks in the Xilinx fl oating-point library actually support fl oating-point data type), and conversion from fl oating-point block to fi xed- point block is supported using the convert block. 

Compilation , Code Generation, and Design Flow

Compilation of a System Generator design refers to the process of validating all the parameters on all the blocks in the design, performing rate, and type propagation and validating the results of rate and type propagation. This can be likened to the elaboration phase in HDL compilers. Compilation of a System Generator design is invoked anytime the Simulink model containing a System Generator design is simu- lated or code generation through the System Generator token is invoked. As part of the compilation process: 

• The tool confi rms that a System Generator token is placed at the root of the System Generator module. 

• User parameters on each of the blocks including MATLAB expressions are eval- uated and validated. 

• Connectivity is established and there are no undriven ports in System Generator module. 

• The type and sample time propagation engine is invoked, and sample times of each block and signals as well as types of the signals are resolved. 

Code generation refers to the process of transforming the Simulink model con- taining a System Generator subsystem into RTL and IP that can be synthesized. Following compilation either simulation can be performed or code generation can be performed. In general, if the compilation is successful, it should be possible to perform code generation or simulation. The general design flow is presented as a flowchart in Fig. 8.8 .