Chapter 1: Hardware Design Using System Generator
Hierarchical Controls
The Simulink System Period control (see the topic
Simulink System Period
above) on the
System Generator block is hierarchical. A hierarchical control on a System Generator block applies to the portion of the design within the scope of the block, but can be overridden on other System Generator blocks deeper in the design. For example, suppose Simulink
System Period
is set in a System Generator block at the top of the design, but is changed in a System Generator block 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.
Viewing ISE Reports
When the Compilation is finished, the Compilation status dialog box appears as shown below. If your compilation target wasBitstream or Timing and Power Analysis, you can click on the Show Reports button and the associated ISE Reports will be avilable for your viewing:
44
Compilation Results
In topic discusses the low-level files System Generator produces when HDL Netlist is selected on the System Generator block and Generate is clicked. The files consist of HDL,
NGC and EDIF that implement the design. In addition, System Generator produces auxiliary files that simplify downstream processing, e.g., bringing the design into Project
Navigator, simulating using an HDL simulator, and synthesizing using various synthesis tools. All files are written to the target directory specified on the System Generator block. If www.xilinx.com
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009
Automatic Code Generation
no testbench is requested, then the key files produced by System Generator are the following:
File Name or Type
<design>.vhd/.v
<design>_cw.vhd/.v
.edn
and .ngc files globals
<design>_cw.xcf (or .ncf)
<design>_cw.ise
hdlFiles synplify_<design>.prj, or xst_<design>.pr
vcom.do
Description
This contains most of the HDL for the design
This is a HDL wrapper for <design>_files.vhd/.v. It drives clocks and clock enables.
Besides writing HDL, System Generator runs CORE
Generator ™ (coregen) to implement portions of the design.
Coregen writes EDIF files whose names typically look something like multiplier_virtex2_6_0_83438798287b830b.edn
.
Other required files may be supplied as .ngc files.
This file consists of key/value pairs that describe the design.
The file is organized as a Perl hash table so that the keys and values can be made available to Pearl scripts using Perl evals.
This contains timing and port location constraints. These are used by the Xilinx synthesis tool XST and the Xilinx implementation tools. If the synthesis tool is set to something other than XST, then the suffix is changed to .ncf.
This allows the HDL and EDIF to be brought into the Xilinx project management tool Project Navigator.
This contains the full list of HDL files written by System
Generator. The files are listed in the usual HDL dependency order.
These files allow the design to be compiled by the synthesis tool you specified.
This script can be used in ModelSim to compile the HDL for a behavioral simulation of the design.
If a testbench is requested, then, in addition to the above, System Generator produces files that allow simulation results to be compared. The comparisons are between Simulink simulation results and corresponding results from ModelSim. The additional files are the following:
File Name or Type
Various .dat files
<design>_tb.vhd/.v
vsim.do
pn_behavioral.do, pn_postmap.do, pn_postpar.do, pn_posttranslate.do
Description
These contain the simulation results from Simulink.
This is a testbench that wraps the design. When simulated in
ModelSim, this testbench compares simulation results from
Simulink against those produced by ModelSim.
This script can be used in ModelSim to run a testbench simulation.
These files allow various ModelSim simulations to be started inside Project Navigator.
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009 www.xilinx.com
45
Chapter 1: Hardware Design Using System Generator
Using the System Generator Constraints File
When a design is compiled, System Generator produces a constraints file that tells downstream tools how to process the design. This enables the tools to produce a higher quality implementation, and to do so using considerably less time. Constraints supply the following:
•
The period to be used for the system clock;
•
The speed, with respect to the system clock, at which various portions of the design must run;
•
The pin locations at which ports should be placed;
•
The speed at which ports must operate.
The file format depends on the synthesis tool that is specified in the System Generator block. When XST is selected, the file is written in the XCF format; for Synplify and Synplify
Pro, the NCF format is used. The file name ends with.xcf or .ncf, as appropriate.
System Clock Period
The system clock period (i.e., the period of the fastest hardware clock in the design) can be specified in the System Generator block. System Generator writes this period to the constraints file. Downstream tools use the period as a goal when implementing the design.
Multicycle Path Constraints
Many designs consist of parts that run at different clock rates. For the fastest part, the system clock period is used. For the remaining parts, the clock period is an integer multiple of the system clock period. It is important that downstream tools know what speed each part of the design must achieve. With this information, efficiency and effectiveness of the tools are greatly increased, resulting in reduced compilation times and improved hardware realizations. The division of the design into parts, and the speed at which each part must run, are specified in the constraints file using multicycle path constraints.
IOB Timing and Placement Constraints
When translated into hardware, System Generator's Gateway In and Gateway Out blocks become input and output ports. The locations of these ports and the speeds at which they must operate can be entered in the Gateway In and Out parameter dialog boxes.
See the descriptions of the Gateway In block and the Gateway Out block for more information. Port location and speed are specified in the constraints file by IOB timing.
46
www.xilinx.com
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009
Automatic Code Generation
Constraints Example
The figure below shows a small multirate design and the constraints System Generator produces for it.
The up sampler doubles the rate, and the down sampler divides the rate by three. Assume the system clock period is 10 ns. Then the clock periods are 10 ns for the FIR, 20 ns for the input register, and 30 ns for the output register. The following text describes the constraints that convey this information.
The lines that indicate the system clock period is10 ns are the following:
# Global period constraint
NET "clk" TNM_NET = "clk_392b7670";
TIMESPEC "TS_clk_392b7670" = PERIOD "clk_392b7670" 10.0 ns HIGH 50 %;
To build timing constraints, the blocks in the design are partitioned into timing groups.
Two blocks are in the same timing group if and only if they run at the same sample rate. In this design there are three timing groups, corresponding to the three rates. The nature of constraints dictates that no name is needed for the fastest group. The remaining groups are named ce_2_392b7670_group and ce_3_392b7670_group; they correspond to periods 20 ns and 30 ns respectively.
The FIR runs at the system (i.e., fastest) rate and therefore is constrained using the global period constraint shown above. The logic used to generate clocks always runs at the system rate and is also constrained to the system rate.
The ce_2_392b7670_group consists of the blocks that operate at half the system rate, i.e., the input register and the up sampler. Every block in the group is driven by the clock enable net named ce2_sysgen. The constraints that define the group are the following:
# ce_2_392b7670_group and inner group constraint
Net "ce_2_sg_x0*" TNM_NET = "ce_2_392b7670_group";
TIMESPEC "TS_ce_2_392b7670_group_to_ce_2_392b7670_group" = FROM
"ce_2_392b7670_group" TO "ce_2_392b7670_group" 20.0 ns;
Note:
A wildcard character is added to the net name to constrain any additional copies of this net that may be generated when clock enable logic is replicated. The maximum fanout of a clock enable net can be controlled in the synthesis tool.
The ce_3_392b7670_group operates at one third the system rate. It contains the down sampler and the output register, and is defined in a similar manner to the ce2_group.
# ce_3_392b7670_group and inner group constraint
Net "ce_3_sg_x0*" TNM_NET = "ce_3_392b7670_group";
TIMESPEC "TS_ce_3_392b7670_group_to_ce_3_392b7670_group" = FROM
"ce_3_392b7670_group" TO "ce_3_392b7670_group" 30.0 ns;
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009 www.xilinx.com
47
Chapter 1: Hardware Design Using System Generator
Group to group constraints establish relative speeds. Here are the constraints that relate the speeds of ce_2_392b7670_group and ce_3_392b7670_group:
# Group-to-group constraints
TIMESPEC "TS_ce_2_392b7670_group_to_ce_3_392b7670_group" = FROM
"ce_2_392b7670_group" TO "ce_3_392b7670_group" 20.0 ns;
TIMESPEC "TS_ce_3_392b7670_group_to_ce_2_392b7670_group" = FROM
"ce_3_392b7670_group" TO "ce_2_392b7670_group" 20.0 ns;
Port timing requirements can be set in the parameter dialog boxes for gateways. These requirements are translated into port constraints such as those shown below. In this example, the 3-bit din input is constrained to operate at its gateway's sample rate
(corresponding to a period of 20 ns). The "FAST" attributes indicate the ports should be implemented using hardware that reduces delay. The reduction comes at a cost of increased noise and power consumption.
# Offset in constraints
NET "din(0)" OFFSET = IN : 20.0 : BEFORE "clk";
NET "din(0)" FAST;
NET "din(1)" OFFSET = IN : 20.0 : BEFORE "clk";
NET "din(1)" FAST;
NET "din(2)" OFFSET = IN : 20.0 : BEFORE "clk";
NET "din(2)" FAST;
Selecting Specify IOB Location Constraints for a gateway allows port locations to be specified. The locations must be entered as a cell array of strings in the box labeled IOB
Pad Locations
. Locations are package-specific; in this example a Virtex®-E 2000 in a FG680 package is used. The location constraints for the din bus are provided in the dialog box as
"{'D35', 'B36', 'C35' }". This is translated into constraints in the .xcf (or .ncf) file in the following way:
# Loc constraints
NET "din(2)" LOC = "D35";
NET "din(1)" LOC = "B36";
NET "din(0)" LOC = "C35";
Clock Handling in HDL
Clock Handling in HDL
This topic describes how System Generator handles hardware clocks in the HDL it generates. Assume the design is named <design>, and <design> is an acceptable HDL identifier. When System Generator compiles the design, it writes a collection of HDL entities or modules, the topmost of which is named <design>, and is stored in a file named <design>.vhd/.v.
The “Clock Enables” Multirate Implementation
Clock and clock enables appear in pairs throughout the HDL. Typical clock names are
clk_1, clk_2, and clk_3, and the names of the companion clock enables are ce_1, ce_2, and
ce_3 respectively. The name tells the rate for the clock/clock enable pair; logic driven by
clk_1 and ce_1 runs at the system (i.e., fastest) rate, while logic driven by (say) clk_2 and
ce_2 runs at half the system rate. Clocks and clock enables are not driven in the entity or module named <design> or any subsidiary entities; instead, they are exposed as top-level input ports
Of course, there must be a way to generate these clocks and clock enables. System
Generator produces a separate clock wrapper (written to a file named
<design>_cw.vhd/.v
) to do this. This wrapper is external to the files described above.
The idea is to make the HDL flexible. In some applications, the files described above are
48
www.xilinx.com
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009
Automatic Code Generation
added to a larger design, but the clock wrapper is omitted. In this case, you are responsible for generating clocks and clock enables, but a finer degree of control is obtained. If, on the other hand, the clock wrapper is suitable for the application, then include it.
The names of the clocks and clock enables in System Generator HDL suggest that clocking is completely general, but this is not the case. To illustrate this, assume a design has clocks named clk_1 and clk_2, and companion clock enables named ce_1 and ce_2 respectively.
You might expect that working hardware could be produced if the ce_1 and ce_2 signals were tied high, and clk_2 were driven by a clock signal whose rate is half that of clk_1. For most System Generator designs this does not work. Instead, clk_1 and clk_2 must be driven by the same clock, ce_1 must be tied high, and ce_2 must vary at a rate half that of clk_1 and
clk_2.
The clock wrapper consists of two components: one for the design itself, and one clock
driver component that generate clocks and clock enables. The clock driver is contained in a file named <design>_cw.vhd/.v. The logic within the <design>_cw generates the ce_x
signals. The optional ce_clr port would be generated if the design was generated by selecting Provide clock enable clear pin on the System Generator block. The ports that are not clocks or clock enables are passed through to the exterior of the clock wrapper.
Schematically, the clock wrapper looks like the diagram below.
Note:
The clock wrapper exposes a port named ce. The port does nothing except to serve as a companion to the clk port on the wrapper. The reason for having the port is to allow the clock wrapper to be used as a black box in System Generator designs.
The “Hybrid DCM-CE” Multirate Implementation
If the implementation target is an FPGA with a Digital Clock Manager (DCM), you can choose to drive the clock tree with a DCM. The DCM option is desirable when high fanout on clock enable nets make it difficult to achieve timing closure.
System Generator instantiates the DCM in a top-level HDL clock wrapper ( with a suffix
_dcm_mcw
) and configures the DCM to provide up to three clock ports at different rates for
Virtex®-4 and Virtex®-5 and up to two clock ports for Spartan-3A DSP
. If the design has more clock ports than the DCM can support, the remaining clocks are supported with the CE
(clock enable) configuration as described in the previous topic.
For a detailed examination of the files produced by this option, refer to the topic
Tutorial
Example: Using the Hybrid DCM-CE Option .
System Generator for DSP User Guide
UG640 (v11.4) December 2, 2009 www.xilinx.com
49
