Advanced HDL synthesis

FPGA design tutorial contents

FPGA design implementation (Xilinx design flow)

In this chapter of the FPGA design tutorial Xilinx implementation flow is discussed in details.

Xilinx implementation flow

Xilinx ISE has three implementation steps: translate, map and place and route. These steps are specific for Xilinx: for example, Altera combines translate and map into one step executed by quartus_map.

Translate

Translate is performed by the NGDBUILD program.

During the translate phase an NGC netlist (an output of a synthesizer) is converted to an NGD netlist. The difference between them is in that NGC netlist is built around UNISIM component library, designed for behavioral simulation, and NGD netlist is dependent upon the SIMPRIM library. The NGDBUILD-produced netlist therefore containts some initial information about switching delays (but it is approximate).

Map

Mapping is performed by the MAP program.

During the map phase the SIMPRIM primitives from an NGD netlist are mapped on specific device resources: LUTs, flip-flops, BRAMs and other. The output of the MAP program is stored in the NCD format. In contains precise information about switching delays, but no information about propagation delays (since the layout hasn't been processed yet.

For Virtex-5 devices MAP also does placement (see below). For other devices placement is done by PAR. Routing is done by PAR for all devices.

Place and route

Placement and routing is performed by the PAR program.

Place and route is the most important and time consuming step of the implementation. It defines how device resources are located and interconnected inside an FPGA.

Placement is even more important than routing, because bad placement would make good routing impossible. In order to provide possibility for FPGA designers to tweak placement, PAR has a "starting cost table" option.

PAR accounts for timing constraints set up by the FPGA designer. If at least one constraint can't be met, PAR returns an error.

The output of the PAR program is also stored in the NCD format.

For Virtex-5 devices, placement is performed by MAP instead of PAR.

Timing constraints

In order to ensure that no timing violation (like period, setup or hold violation) will occur in the working design, timing constraints must be specified.

Basic timing constraints that should be defined include frequency (period) specification and setup/hold times for input and output pads. The first is done with the PERIOD constraint, the second - with the OFFSET constraint.

Timing constraints for the FPGA project are defined in the UCF file. Instead of editing the UCF file directly, an FPGA designer may prefer to use an appropriate GUI tool. However, the first approach is more powerful.

Specifying timing groups

Timing groups are sets of objects to which constraints should bу applied. There are some pre-defined groups, and more groups can be created by an FPGA designer.

There are many forms of timing constraints. Some of them will be discussed below, other can be found in Xilinx Constraints Guide.

One way to create a timing group is to link it with the particular net:

NET "net_name" TNM_NET = qualifier "tnm_name";

Here net_name is a name of clock net (signal), tnm_name is a name of the associated timing group, and qualifier is an optional condition which is used to include in the group only elements of particular types. Examples of qualifiers include FFS (for flip-flops), PADS (for pads), RAMS (for RAM modules).

TNM_NET example:

NET "CLK" TNM_NET = "clk_net";

This code defines a clk_net timing group associated with the CLK clock net and including all synchronous elements controlled by this net (since no qualifier has been specified).

Another way to define a timing group is to specify the name of the instance (module):

INST "inst_name" TNM = qualifier "tnm_name";

In this case all synchronous elements in inst_name (or those corresponding to qualifier when specified) are grouped in tnm_name group.

Specifying period

PERIOD constraint is used to define a clock period (or frequency) for the clock domain. Example:

NET "CLK" TNM_NET = "clk_net"; TIMESPEC "TS_clk_net" = PERIOD "clk_net" 10 ns;

This example defines a minimum period of 10 ns for CLK clock net (which corresponds to 100 MHz frequency). TS_clk_net is a constraint name, it can be any other.

Specifying offset

OFFSET constraint is used to specify external setup time for input pads or necessary hold time for output pads.

For input pads, OFFSET specifies a time before the (external) clock edge when the related data signals are set. Example:

OFFSET = IN 5 ns BEFORE "CLK";

For output pads, OFFSET specifies a minimum time after the clock edge when the related data signas can be deasserted. Example:

OFFSET = OUT 2 ns AFTER "CLK";

In this form, constraints are applied to all I/O pads related to CLK clock signal. There are also more specific timing constraints. For more information, see Xilinx Constraints Guide.

False paths

A false path is a path between two synchronous elements which formally exists, but by design won't be ever activated during the device operation. As such, false paths should be excluded from static timing analysis. It is done using the TIG constraint:

TIMESPEC "TSid" = FROM "from_grp" TO "to_grp" TIG;

Here TSid is an identifier of the constraint, and from_grp and to_grp are timing groups.

Multicycle paths

There are situatuions when a given combinational logic unit is designed to produce output after more than one clock cycles. Such paths must be defined as multicycle, otherwise implementation tools will try to fit them in one cycle, possible failing the place and route.

Example: imagine that we have a TS_clk_net TIMESPEC constraint for clock period. Then in order to define a multicycle path from the multi_start group to the multi_end group we should write:

TIMESPEC "TS_multicycle_01" = FROM "multi_start" TO "multi_end" TS_clk_net*2;

I/O pads assignment

I/O pads constraints should be specified in any real design. In the absence of these constraints the implementation tools will choose pads on its own. It is not that an FPGA designer usually need.

I/O pad constraints can be conveniently set up with the Assign Package Pins utility from Xilinx ISE.

The example of an UCF syntax for I/O pads constraints is:

NET "data_input" LOC = AK14 | IOSTANDARD = LVCMOS33 | SLEW = SLOW;

LOC constraint specifies a pin number (AK14). IOSTANDARD constraint specifies I/O standard (low-voltage CMOS 3.3V). SLEW constraint specifies slew rate (slope steepness). It is recommended to use SLOW slew rate whenever possible, since it reduces EMI (electromagnetic interference).

There are also other parameters that can be set for I/O pads.