Placement Constraints

This section describes the legal placement constraints for each type of logic element, such as flip-flops, ROMs and RAMs, FMAPs, F5MAPs, and HMAPs, CLBMAPs, BUFTs, CLBs, IOBs, I/Os, edge decoders, and global buffers in FPGA designs. Individual logic gates, such as AND or OR gates, are mapped into CLB function generators before the constraints are read and therefore cannot be constrained. However, if gates are represented by an FMAP, F5MAP, HMAP, or CLBMAP symbol, you can put a placement constraint on that symbol.

You can use the following constraints (described earlier in the “Attributes/Logical Constraints” section) to control mapping and placement of symbols in a netlist.

• BLKNM
  
  
• HBLKNM
  
  
• XBLKNM
  
  
• LOC
  
  
• PROHIBIT
  
  
• RLOC
  
  
• RLOC_ORIGIN
  
  
• RLOC_RANGE
  
  

Most constraints can be specified either in the schematic or in the UCF file.

In a constraints file, each placement constraint acts upon one or more symbols. Every symbol in a design carries a unique name, which is defined in the input file. Use this name in a constraint statement to identify the symbol.

Note: The UCF and NCF files are case sensitive. Identifier names (names of objects in the design, such as net names) must exactly match the case of the name as it exists in the source design netlist. However, any Xilinx constraint keyword (for example, LOC, PROHIBIT, RLOC, BLKNM) can be entered in either all upper-case or all lower-case letters; mixed case is not allowed.

The following sections describe various types of placement constraints, explains the method of determining the symbol name for each, and provides examples.

BUFT Constraint Examples

You can constrain internal 3-state buffers (BUFTs) to an individual BUFT location, a list of BUFT locations, or a rectangular block of BUFT locations. BUFT constraints all refer to locations with a prefix of TBUF, which is the name of the physical element on the device.

BUFT constraints can be assigned from the schematic or through the UCF file. From the schematic, LOC constraints are attached to the target BUFT. The constraints are then passed into the EDIF netlist file and after mapping are read by PAR. Alternatively, in a constraints file a BUFT is identified by a unique instance name.

In the XC3000, BUFT locations are not straightforward. View the device in the FPGA Editor to determine the exact BUFT names.

In XC4000, Spartan, or SpartanXL, BUFT locations are identified by the adjacent CLB. Thus, TBUF_R1C1.1 is just above CLB_R1C1, and TBUF_R1C1.2 is just below it. For XC4000, Spartan, or SpartanXL, use the following syntax to denote fixed locations.

TBUF_RrowCcol{.1 | .2}

where row is the row location and col is the column location; they can be any number between 0 and 99, inclusive. They must be less than or equal to the number of CLB rows or columns in the target device. The suffixes have the following meanings.

• 1 indicates that the instance should be placed above the CLB.
  
  
• 2 indicates that the instance should be placed below the CLB.
  
  

In the XC5200, BUFT locations are identified by the adjacent slice. From bottom to top, they are number 0, 1, 2, and 3. Thus, TBUF_R1C1.0 is located toward the bottom of the row. TBUF_R1C1.3 is located toward the top of the row. For an XC5200, Use the following syntax to denote fixed locations.

TBUF_RrowCcol{.0 | .1 | .2 | .3}

where row is the row location and col is the column location; they can be any number between 0 and 99, inclusive. They must be less than or equal to the number of CLB rows or columns in the target device. The suffixes have the following meanings.

• 0 indicates that the instance should be placed in the bottom buffer.
  
  
• 1 indicates that the instance should be placed in the buffer that is second from bottom.
  
  
• 2 indicates that the instance should be placed in the buffer that is second from top.
  
  
• 3 indicates that the instance should be placed in the top buffer.
  
  

For Virtex or Spartan2, use the following syntax to denote fixed locations.

TBUF_RrowCcol{.0 | .1}

where row is the row location and col is the column location; they can be any number between 0 and 99, inclusive. They must be less than or equal to the number of CLB rows or columns in the target device. The suffixes have the following meanings.

• 0 indicates one TBUF at the specific row/column.
  
  
• 1 indicates the second TBUF at the specific row/column.
  
  

For the XC4000, XC5200, Spartan, Spartan2, SpartanXL, or Virtex, use the following syntax to denote a range of locations from the lowest to the highest.

TBUF_RrowCcol TBUF_RrowCcol

The following examples illustrate the format of BUFT LOC constraints. Specify LOC= and the BUFT location.

The following statements place the BUFT in the designated location.

The next statements place BUFTs at any location in the first column of BUFTs. The asterisk (*) is a wildcard character.

The following statements place BUFTs within the rectangular block defined by the first specified BUFT in the upper left corner and the second specified BUFT in the lower right corner.

In the following examples, the instance names of two BUFTs are /top-72/rd0 and/top-79/ed7.

Example 1

This example specifies a BUFT adjacent to a specific CLB.

Place the BUFT adjacent to CLB R1C5. In XC4000, Spartan, and SpartanXL, PAR uses either the longline above the row of CLBs or the longline below. In an XC5200, PAR places the BUFT in one of the four slices of the CLB at row 1, column 5. In Virtex and Spartan2, PAR places the BUFT in one of two slices of the CLB at row 1, column 5.

Example 2

The following example places a BUFT in a specific location.

Place the BUFT adjacent to CLB R1C5. In an XC4000, Spartan, or SpartanXL device, .1 tag specifies the longline above the row of CLBs; the .2 tag specifies the longline below it. In an XC5200 device, the .1 tag specifies the longline associated with the slice above the bottom-most slice in the CLB at the location; the .1, .2, .3 tags specify slices above the .0 slice for the specified row and column. In Virtex and Spartan2, the .1 tag specifies the second TBUF in CLB R1C5.

BUFTs that drive the same signal must carry consistent constraints. If you specify .1 or .2 for one of the BUFTs that drives a given signal, you must also specify .1 or .2 on the other BUFTs on that signal; otherwise, do not specify any constraints at all.

Example 3

The next example specifies a column of BUFTs.

Place BUFTs in column 3 on any row. This constraint might be used to align BUFTs with a common enable signal. You can use the wildcard (*) character in place of either the row or column number to specify an entire row or column of BUFTs.

Example 4

This example specifies a row of BUFTs .

Place the BUFT on one of the longlines in row 7 for any column. You can use the wildcard (*) character in place of either the row or column number to specify an entire row or column of BUFTs.

CLB Constraint Examples

You can assign soft macros and flip-flops to a single CLB location, a list of CLB locations, or a rectangular block of CLB locations. You can also specify the exact function generator or flip-flop within a CLB. CLB locations are identified as CLB_RrowCcol for XC4000, XC5200, Spartan, Spartan2, SpartanXL, and Virtex or aa for XC3000, where aa is a two-letter designator. The upper left CLB is CLB_R1C1 (for XC4000, XC5200, Spartan, Spartan2, SpartanXL, and Virtex) or AA (for XC3000).

CLB locations can be a fixed location or a range of locations. Use the following syntax to denote fixed locations.

For XC4000, Spartan, SpartanXL:

CLB_R rowCcol{.F | .G | .FFX | .FFY }

For XC5200:

CLB_R rowCcol{.LC0 | .LC1 | .LC2 | .LC3 }

For Spartan2, Virtex:

CLB_R rowCcol{.S0 | .S1}

where

row is the row location and col is the column location; they can be any number between 0 and 99, inclusive, or *. They must be less than or equal to the number of CLB rows or columns in the target device. The suffixes have the following meanings.

.F means the CLB is mapped into the F function generator.

.G means the CLB is mapped into the G function generator.

.FFX indicates the X flip-flop in the CLB.

.FFY indicates the Y flip-flop in the CLB.

.LC0 means the bottom-most slice in the XC5200 CLB.

.LC1 means the slice above the .LC0 slice in the XC5200 CLB.

.LC2 means the slice above the .LC1 slice in the XC5200 CLB.

.LC3 means top-most slice in the XC5200 CLB.

.S0 means the right-most slice in the Virtex or Spartan2 CLB.

.S1 means the left-most slice in the Virtex or Spartan2 CLB.

Use the following syntax to denote a range of locations from the highest to the lowest.

CLB_Rrow1Ccol:CLB_Rrow2Ccol2

The following examples illustrate the format of CLB constraints. Enter LOC= and the pin or CLB location. If the target symbol represents a soft macro, the LOC constraint is applied to all appropriate symbols (flip-flops, maps) contained in that macro. If the indicated logic does not fit into the specified blocks, an error is generated.

The following statements place logic in the designated CLB.

The following statements place logic within the first column of CLBs. The asterisk (*) is a wildcard character.

The next two statements place logic in any of the three designated CLBs. There is no significance to the order of the LOC statements.

The following statements place logic within the rectangular block defined by the first specified CLB in the upper left corner and the second specified CLB towards the lower right corner.

The next statement places logic in the X flip-flop of CLB_R2C2. For the Y flip-flop, use the FFY tag.

You can prohibit PAR from using a specific CLB, a range of CLBs, or a row or column of CLBs. Such prohibit constraints can be assigned only through the User Constraints File (UCF). CLBs are prohibited by specifying a PROHIBIT constraint at the design level, as shown in the following examples.

Example 1

Do not place any logic in the CLB in row 1, column 5. CLB R1C1 is in the upper left corner of the device.

Example 2

Do not place any logic in the rectangular area bounded by the CLB R1C1 in the upper left corner and CLB R5C7 in the lower right.

Example 3

Do not place any logic in any row of column 3. You can use the wildcard (*) character in place of either the row or column number to specify an entire row or column of CLBs.

Example 4

Do not place any logic in either CLB R2C4 or CLB R7C9.

Delay Locked Loop (DLL) Constraint Examples (Virtex and Spartan2 Only)

You can constrain Virtex and Spartan2 DLL elements - CLKDLL and CLKDLLHF - to a specific physical site name. Specify LOC=DLL and a numeric value (0 through 3) to identify the location.

Following is an example.

Edge Decoder Constraint Examples (XC4000 Only)

In an XC4000 design, you can assign the decode logic to a specified die edge or half-edge. All elements of a single decode function must lie along the same edge; they cannot be split across two edges of the die. If you use decoder constraints, you must assign all decode inputs for a given function to the same edge. From the schematic, attach LOC constraints to the decode logic - either a DECODE macro or a WAND gate with the DECODE attribute. The constraints are then passed into the EDIF netlist and after mapping is read by PAR.

The format of decode constraints is LOC= and the decode logic symbol location. If the target symbol represents a soft macro containing only decode logic, for example, DECODE8, the LOC constraint is applied to all decode logic contained in that macro. If the indicated decode logic does not fit into the specified decoders, an error is generated.

To constrain decoders to precise positions within a side, constrain the associated pads. However, because PAR determines decoder edges before processing pad constraints, it is not enough to constrain the pads alone. To constrain decoders to a specific die side, use the following rule. For every output net that you want to constrain, specify the side for at least one of its input decoders (WAND gates), using one of the following.

The “Legal Edge Designations for Edge Decoders” table shows the legal edge designations.

Example 1

Place the decoder along the top edge of the die.

Example 2

Place the decoder logic along the left edge of the die.

Example 3

Place decoders along the top half of the left edge of the die. The first letter in this code represents the die edge, and the second letter represents the desired half of that edge.

Table 12_9 Legal Edge Designations for Edge Decoders

Note: The edges referred to in these constraints are die edges, which do not necessarily correspond to package edges. View the device in the FPGA Editor to determine which pins are on which die edge.

Flip-Flop Constraint Examples

Flip-flops can be constrained to a specific CLB, a range of CLBs, a row or column of CLBs, a specific half-CLB, or one of four specific slices of the XC5200 CLB. Flip-flop constraints can be assigned from the schematic or through the UCF file.

From the schematic, attach LOC constraints to the target flip-flop. The constraints are then passed into the EDIF netlist and are read by PAR after the design is mapped.

The following examples show how the LOC constraint is applied to a schematic and to a UCF (User Constraints File). The instance names of two flip-flops, /top-12/fdrd and /top-54/fdsd, are used to show how you would enter the constraints in the UCF.

Example 1

Place the flip-flop in the CLB in row 1, column 5. CLB R1C1 is in the upper left corner of the device.

Example 2

Place the flip-flop in the rectangular area bounded by the CLB R1C1 in the upper left corner and CLB R5C7 in the lower right corner.

Example 3

Place the flip-flops in any row of column 3. You can use the wildcard (*) character in place of either the row or column number to specify an entire row or column of CLBs.

In the following example, repeating the LOC constraint and separating each such constraint by a comma specifies multiple locations for an element. When you specify multiple locations, PAR can use any of the specified locations.

Example 4

Place the flip-flop in either CLB R2C4 or CLB R7C9.

Example 5

Place the flip-flop in CLB R3C5 and assign the flip-flop output to the XQ pin. (Use the FFY tag to indicate the YQ pin of the CLB.) If either the FFX or FFY tags are specified, the wildcard (*) character cannot be used for the row or column numbers.

Example 6

Do not place the flip-flop in any column of row 5. You can use the wildcard (*) character in place of either the row or column number to specify an entire row or column of CLBs.

The XC5200 CLB is divided into four specific slices for every row and column location on the array. In order to place a flip-flop in a specific slice, use the .LC0, .LC1, .LC2, or .LC3 extension on the location constraint as shown in the following example.

Example 7

Place the flip-flop in the top slice of the XC5200 CLB in row 1, column 5.

Global Buffer Constraint Examples

XC3000

You cannot assign placement to the GCLK or ACLK buffers in the XC3000 family, since there is only one each, and their placements are fixed on the die.

XC4000, XC5200, Spartan, SpartanXL

For the XC4000, XC5200, Spartan, and SpartanXL, you can constrain a global buffer - BUFG, BUFGP, BUFGS, BUFGLS, BUFGE, or BUFFCLK - to a corner of the die. From the schematic, attach LOC constraints to the global buffer symbols; specify LOC= and the global clock buffer location. The constraints are then passed into the EDIF netlist and after mapping are read by PAR.

Following is an example.

Place the global buffer in the top left corner of the die. The following table shows the legal corner designations.

Table 12_10 Legal Corner Designations for Global Buffers

If a global buffer is sourced by an external signal, the dedicated IOB for that buffer must not be used by any other signal. For example, if a BUFGP is constrained to TL, the PGCK1 pin must be used to source it, and no other I/O can be assigned to that pin.

Virtex, Spartan2

You can constrain a Virtex or Spartan2 global buffer - BUFGP, and IBUFG_selectIO variants - to a specific buffer site name or dedicated global clock pad in the device model. From the schematic, attach LOC constraints to the global buffer symbols. Specify LOC= and GCLKBUF plus a number (0 through 3) to create a specific buffer site name in the device model. Or, specify LOC= and GCLKPAD plus a number (0 through 3) to create a specific dedicated global clock pad in the device model.The constraints are then passed into the EDIF netlist and after mapping are read by PAR.

Following is an example.

I/O Constraint Examples

You can constrain I/Os to a specific IOB. You can assign I/O constraints from the schematic or through the UCF file.

From the schematic, attach LOC constraints to the target PAD symbol. The constraints are then passed into the netlist file and read by PAR after mapping.

Alternatively, in the UCF file a pad is identified by a unique instance name. The following example shows how the LOC constraint is applied to a schematic and to a UCF (User Constraints File). In the examples, the instance names of the I/Os are /top-102/data0_pad and /top-117/q13_pad. The example uses a pin number to lock to one pin.

Place the I/O in the IOB at pin 17. For pin grid arrays, a pin name such as B3 or T1 is used.

IOB Constraint Examples

You can assign I/O pads, buffers, and registers to an individual IOB location. IOB locations are identified by the corresponding package pin designation.

The following examples illustrate the format of IOB constraints. Specify LOC= and the pin location. If the target symbol represents a soft macro containing only I/O elements, for example, INFF8, the LOC constraint is applied to all I/O elements contained in that macro. If the indicated I/O elements do not fit into the specified locations, an error is generated.

The following statement places the I/O element in location P13. For PGA packages, the letter-number designation is used, for example, B3.

LOC=P13

You can prohibit the mapper from using a specific IOB. You might take this step to keep user I/O signals away from semi-dedicated configuration pins. Such prohibit constraints can be assigned only through the UCF file.

IOBs are prohibited by specifying a PROHIBIT constraint preceded by the CONFIG keyword, as shown in the following example.

Do not place user I/Os in the IOBs at pins 36, 37, or 41. For pin grid arrays, pin names such as D14, C16, or H15 are used.

Mapping Constraint Examples

Mapping constraints control the mapping of logic into CLBs. They have two parts. The first part is a FMAP, HMAP, or CLBMAP component placed on the schematic. The second is a LOC constraint that can be placed on the schematic or in the constraints file.

CLBMAP (XC3000 Only)

With the CLBMAP symbol, you can specify logic mapping at the schematic level for all XC3000 designs. It is used in conjunction with standard logic elements, such as gates and flip-flops. It implicitly specifies the configuration of a CLB by defining the signals on its pins. Use the CLBMAP symbol to control mapping when the default mapping is not acceptable.

Enter the CLBMAP symbol on the schematic and assign signals to its pins. MAP processes this symbol and maps the appropriate logic, as defined by the input and output signals, into one CLB. The easiest way to define a CLBMAP is to connect a labeled wire segment to each pin, which connects that pin to the net carrying the same label.

If a CLBMAP specifies an illegal CLB configuration, MAP issues an error explaining why the CLBMAP is illegal.

A CLBMAP can be either closed or open. A closed CLBMAP must specify both the input and output signals for that CLB. MAP maps a closed CLBMAP exactly as specified, unless the indicated configuration is illegal. MAP does not add any logic to a CLB specified with a closed CLBMAP.

An open CLBMAP specifies the minimum amount of logic to place within a CLB. MAP attempts to place more logic within the CLB as long as the CLB remains valid. MAP only adds logic on the inputs to the CLB. It does not add logic on the output signals. MAP assigns those signals to the CLB output pins and maps the source logic into the CLB as appropriate. Use an open CLBMAP to specify the minimum function of a CLB.

Specify whether a CLBMAP is open or closed by attaching the appropriate MAP attribute to the symbol. See the “Map Attributes for CLBMAP Symbols” table for the exact conventions.

The default configuration for a CLBMAP is unlocked and open.

Table 12_11 Map Attributes for CLBMAP Symbols

Note: Currently, pin locking is not supported. PLC and PLO are translated into PUC and PUO, respectively.

Example 1

Place the CLBMAP in CLB CLB_R1C1.

Example 2

Place the CLBMAP in the area bounded by CLB AA in the upper left corner and CLB EE in the lower right.

FMAP and HMAP

The FMAP and HMAP symbols control mapping in an XC4000, Spartan, or SpartanXL design. They are similar to the XC3000 CLBMAP symbol. The FMAP may also be used to control mapping XC5200, Spartan2, or Virtex designs.

FMAP and HMAP control the mapping of logic into function generators. These symbols do not define logic on the schematic; instead, they specify how portions of logic shown elsewhere on the schematic should be mapped into a function generator.

The FMAP symbol defines mapping into a four-input (F) function generator. The mapper assigns this function to an F or G function generator for XC4000, Spartan, and SpartanXL, so you are not required to specify whether it belongs in F or G. For the XC5200, the four-input function generator defined by the FMAP will be assigned to one of the four slices of the CLB. For Virtex and Spartan2, the four-input function generator defined by the FMAP will be assigned to one of the two slices of the CLB.

The HMAP symbol defines mapping into a three-input (H) function generator for XC4000, Spartan, and SpartanXL. If the HMAP has two FMAP outputs and, optionally, one normal (non-FMAP) signal as its inputs, The mapper places all the logic related to these symbols into one CLB.

An example of how to use these symbols in your schematic appears in the “FMAP and HMAP Schematics” figure and the “Implementation of FMAP and HMAP” figure.

For the FMAP symbol as with the CLBMAP primitive, MAP=PUC or PUO is supported, as well as the LOC constraint. (Currently, pin locking is not supported. MAP=PLC or PLO is translated into PUC and PUO, respectively.)

For the HMAP symbol, only MAP=PUC is supported.

Example 1

Place the FMAP or HMAP symbol in the CLB at row 7, column 3.

Example 2

Place the FMAP or HMAP symbol in either the CLB at row 2, column 4 or the CLB at row 3, column 4.

Example 3

Place the FMAP or HMAP symbol in the area bounded by CLB R5C5 in the upper left corner and CLB R10C8 in the lower right.

Example 4 (XC4000, Spartan, SpartanXL)

Place the FMAP in the F function generator of CLB R10C11. The .G extension specifies the G function generator. An HMAP can only go into the H function generator, so there is no need to specify this placement explicitly.

The XC5200 CLB is divided into four specific slices for every row and column location in the array. In order to place a function generator in a specific slice, use the .LC0, .LC1, .LC2., or LC3 extension on the location constraint on the FMAP as shown in the following example.

Example 5 (XC5200)

Place the FMAP in the top slice of the XC5200 CLB in row 10, column 11.

The Virtex or Spartan2 CLB is divided into two specific slices for every row and column location in the array. In order to place a function generator in a specific slice, use the .S0 (right-most slice) or .S1 (left-most slice) extension on the location constraint on the FMAP as shown in the following example.

Example 6 (Virtex, Spartan2)

Place the FMAP in the right-most slice of the Virtex or Spartan2 CLB in row 10, column 11.

Figure 12.2 FMAP and HMAP Schematics

Figure 12.3 Implementation of FMAP and HMAP

RAM and ROM Constraint Examples

You can constrain a ROM or RAM to a specific CLB, a range of CLBs, or a row or column of CLBs. Memory constraints can be assigned from the schematic or through the UCF file.

From the schematic, attach the LOC constraints to the memory symbol. The constraints are then passed into the netlist file and after mapping they are read by PAR. For more information on attaching LOC constraints, see the appropriate interface user guide.

Alternatively, in the constraints file a memory is identified by a unique instance name. One or more memory instances of type ROM or RAM can be found in the input file. All memory macros larger than 16 x 1 or 32 x 1 are broken down into these basic elements in the netlist file.

In the following examples, the instance name of the ROM primitive is /top-7/rq. The instance name of the RAM primitive, which is a piece of a RAM64X8 macro, is /top-11-ram64x8/ram-3.

Example 1

Place the memory in the CLB in row 1, column 5. CLB R1C1 is in the upper left corner of the device. You can only apply a single-CLB constraint such as this to a 16 x 1 or 32 x 1 memory.

Example 2

Place the memory in either CLB R2C4 or CLB R7C9.

Example 3

Place the LogiBlox module in the rectangular area bounded by the CLB R1C1 in the upper left corner and CLB R5C7 in the lower right.

From the schematic, attach the LOC constraint to the LogiBlox symbol for the bigram block.

In the UCF file, the /* is appended to the end of the LogiBlox symbol instance. The wildcard (*) character here specifies all instances that begin with the /top-17/bigram/ prefix, that is, all RAM elements within the LogiBlox block.

Example 4

Do not place the memory in any column of row 5. You can use the wildcard (*) character in place of either the row or column number in the CLB name to specify an entire row or column of CLBs.

RAMB4 (Block RAM) Constraint Examples (Virtex, Spartan2 Only)

You can constrain a Virtex or Spartan2 block RAM to a specific CLB, a range of CLBs, or a row or column of CLBs. Memory constraints can be assigned from the schematic or through the UCF file. From the schematic, attach the LOC constraints to the memory symbol. The constraints are then passed into the netlist file and after mapping they are read by PAR. For more information on attaching LOC constraints, see the appropriate interface user guide. Alternatively, in the constraints file a memory is identified by a unique instance name.

A Virtex or Spartan2 block RAM has a different row/column grid specification than CLBs and TBUFs. It is specified using RAMB4_RnCn where the numeric row and column numbers refer to the block RAM grid array. A block RAM located at RAMB4_R3C1 is not located at the same site as a flip-flop located at CLB_R3C1.

For example, assume you have a device with two columns of block RAM, each column containing four blocks, where one column is on the right side of the chip and the other is on the left. The block RAM located in the upper left corner is RAMB4_R0C0. Because there are only two columns of block RAM, the block located in the upper right corner is RAMB4_R0C1.