Model Composer automatically compiles designs into low-level representations. Designs are compiled and simulated using the System Generator token. This topic describes how to use the block.
The System Generator token is a member of the Xilinx HDL Blockset's Tools library.
A design must contain at least one System Generator token, but can contain several System Generator tokens on different levels (one per level). A System Generator token that is underneath another in the hierarchy is a slave; one that is not a slave is a master. The scope of a System Generator token consists of the level of hierarchy into which it is embedded and all Subsystems below that level. Certain parameters (e.g., Simulink System Period) can be specified only in a master.
Once a System Generator token is added, it is possible to specify how code generation and synthesis should be handled. The System Generator Token dialog box is shown below:
Compilation Type and the Generate Button
Pressing the Generate button instructs Model Composer to compile a portion of the design into equivalent low-level results. The portion that is compiled is the sub-tree whose root is the Subsystem containing the block. (To compile the entire design, use a System Generator token placed at the top of the design.) The compilation type (under Compilation) specifies the type of result that should be produced. The possible types are:
- IP Catalog: Packages the design as an IP core that can be added to the Vivado IP catalog for use in another design.
- Hardware Co-Simulation (JTAG): Generates HW co-simulation library block to verify an algorithm in the hardware.
- Synthesized Checkpoint: Creates a design checkpoint file (synth_1.dcp) that can then be used in any Vivado IDE project.
- HDL Netlist: Generates VHDL or Verilog RTL designs.
Specifies a Xilinx, Partner, or Custom board you will use to test your design.
For a Partner board or a custom board to appear in the Board list, you must configure Model Composer to access the board files that describe the board. Board awareness in Model Composer is detailed in Specifying Board Support in Model Composer HDL Blockset.
When you select a Board, the Part field displays the name of the Xilinx device on the selected Board, and this part name cannot be changed.
|Defines the Xilinx part to be used. If you have selected a Board, the Part field will display the name of the Xilinx device on the selected Board, and this part name cannot be changed.
|Hardware description language
|Specifies the language to be used for HDL netlist of the design. The possibilities are VHDL and Verilog.
|Specifies the name of VHDL work library for code generation. The default name is xil_defaultlib.
|Use STD_LOGIC type for Boolean or 1 bit wide gateways
|If your design's Hardware Description Language (HDL) is VHDL, selecting this option will declare a Boolean or 1-bit port (Gateway In or Gateway Out) as a STD-LOGIC type. If this option is not selected, Model Composer will interpret Boolean or 1-bit ports as vectors.
|Defines where Model Composer should write compilation results. Because
Model Composer and the FPGA physical design tools typically create many files, it is best to
create a separate target directory, i.e., a directory other than the directory containing
your Simulink model files. The directory can be an
absolute path (e.g.
c:\netlist) or a path relative to the
directory containing the model (e.g.
|Choose a Synthesis strategy from the pre-defined strategies in the drop-down list.
|Choose an Implementation strategy from the pre-defined strategies in the drop-down list.
|Create interface document
|When this box is checked and the Generate button is activated for netlisting, Model Composer creates an HTM document that describes the design being netlisted. This document is placed in the netlist folder.
|This instructs Model Composer to create an HDL test bench. Simulating
the test bench in an HDL simulator compares Simulink
simulation results with ones obtained from the compiled version of the design. To construct
test vectors, Model Composer simulates the design in Simulink, and saves the values seen at gateways. The top HDL file for the test
bench is named
<name> is a name derived from the portion of the design
being tested and the extension is dependent on the hardware description language.
|FPGA clock period
|Defines the period in nanoseconds of the system clock. The value need not be an integer. The period is passed to the Xilinx implementation tools through a constraints file, where it is used as the global PERIOD constraint. Multi-cycle paths are constrained to integer multiples of this value.
|Clock pin location
|Defines the pin location for the hardware clock. This information is passed to the Xilinx implementation tools through a constraints file.
Simulink System Period
You must specify a value for Simulink system period in the System Generator token dialog box. This value tells the underlying rate, in seconds, at which simulations of the design should run. The period must evenly divide all sample periods in the design. For example, if the design consists of blocks whose sample periods are 2, 6, and 8, then the largest acceptable sample period is 2, though other values such as 1 and 0.5 are also acceptable. Sample periods arise in three ways: some are specified explicitly, some are calculated automatically, and some arise implicitly within blocks that involve internal rate changes. For more information on how the system period setting affects the hardware clock, refer to Timing and Clocking.
Before running a simulation or compiling the design, Model Composer verifies that the period evenly divides every sample period in the design.
It is possible to assemble a Model Composer model that is inconsistent because its periods cannot be reconciled. (For example, certain blocks require that they run at the system rate. Driving an up-sampler with such a block produces an inconsistent model.) If, even after updating the system period, Model Composer reports there are conflicts, then the model is inconsistent and must be corrected.
The period control is hierarchical. See Hierarchical Controls for details.
Block Icon Display
The options on this control affect the display of the block icons on the model. After compilation (which occurs when generating, simulating, or by pressing Ctrl-D) of the model various information about the block in your model can be displayed, depending on which option is chosen.
- Basic information about port directions are shown.
- Sample rates
- The sample rates of each port are shown like Normalized samples periods and Sample frequencies (MHz).
- Pipeline stages
- The number of pipeline stages are shown.
- HDL port names
- the names of the ports are shown
- Input data types
- The input data types for each port are shown.
- Output data types
- Output data types for each port are shown.
The Simulink System Period control (see the topic Simulink System Period above) on the System Generator token is hierarchical. A hierarchical control on a System Generator token applies to the portion of the design within the scope of the token, but can be overridden on other System Generator tokens deeper in the design. For example, suppose Simulink System Period is set in a System Generator token at the top of the design, but is changed in a System Generator token within a Subsystem S. Then that Subsystem will have the second period, but the rest of the design will use the period set in the top level.