Attributes/Logical Constraints

Syntax Summary

This section summarizes attribute and logical constraints syntax. This syntax conforms to the conventions given in the “Conventions” section. A checkmark () appearing in a column means that the attribute/constraint is supported for architectures that use the indicated library. (Refer to the “Applicable Architectures” section of the “Xilinx Unified Libraries” chapter for information on the specific device architectures supported in each library.) A blank column means that the attribute/constraint is not supported for architectures using that library.

		BASE = {F | FG | FGM | IO}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		BLKNM = block_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		BUFG = {CLK | OE | SR}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		CLKDV_DIVIDE={ 1.5 | 2 | 2.5 | 3 | 4 | 5 | 8 | 16}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		COLLAPSE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

*		CONFIG = tag value [tag value]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
*The CONFIG attribute configures internal options of an XC3000 CLB or IOB. Do not confuse this attribute with the CONFIG primitive, which is a table containing PROHIBIT and PART attributes.

		DECODE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		DIVIDE1_BY = {4 | 16 | 64 | 256} DIVIDE2_BY = {2 | 8 | 32 | 128 | 1024 | 4096 | 16384 | 65536}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		DOUBLE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		XC4000X, SpartanXL: DRIVE = {12 |24} Virtex: DRIVE = {2 | 4 | 6 | 8 | 12 | 16 | 24}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
		*
* supported for XC4000XV and XC4000XLA designs only

		TSidentifier=DROP_SPEC
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

			DUTY_CYCLE_CORRECTION={TRUE | FALSE}
XC3000	XC4000E		XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		EQUATE_F = equation EQUATE_G = equation
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		FAST
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		FILE = file_name [.extension]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		HBLKNM = block_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		HU_SET = set_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		INIT ={S | R | value}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		INIT_0x = value
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		INREG
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		IOB={TRUE | FALSE}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		KEEP
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
							*
*Only at BEL level

		FPGAs: LOC=location1[,location2,... , locationn] or: LOC=location : location [SOFT ] CPLDs: LOC = {pin_name | FBnn | FBnn_mm}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		MAP = [PUC | PUO | PLC | PLO ]*
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
*Only PUC and PUO are observed. PLC and PLO are translated to PUC and PUO, respectively. The default is PUO.

		MAXDELAY = allowable_delay [units]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		MAXSKEW = allowable_skew [units]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		MEDDELAY
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		NODELAY
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		NOREDUCE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		OFFSET={IN | OUT} offset_time [units] {BEFORE | AFTER} "clk_net" [TIMEGRP "reggroup"] or: NET "name" OFFSET={IN | OUT} offset_time [units] {BEFORE | AFTER} "clk_net" [TIMEGRP "reggroup"] or: TIMEGRP "group" OFFSET={IN | OUT} offset_time [units] {BEFORE | AFTER} "clk_net" [TIMEGRP "reggroup"] or: TSidentifier= [TIMEGRP name] OFFSET = {IN|OUT} offset_time [units] {BEFORE|AFTER} "clk_net" [TIMEGRP "reggroup"]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		OPT_EFFORT= {NORMAL | HIGH}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		OPTIMIZE ={AREA | SPEED | BALANCE | OFF}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		OUTREG
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		PART = part_type
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		PERIOD = period[units] [{HIGH | LOW} [high_or_low_time [hi_lo_units]]] or: TSidentifier=PERIOD TNM_reference period[units] [{HIGH | LOW} [high_or_low_time [hi_lo_units]]]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		PROHIBIT = location1[, location2, ... , locationn] or: PROHIBIT = location : location
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		PWR_MODE ={LOW | STD}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		XC4000: RLOC = RmCn[.extension] XC5200, Virtex: RLOC = RmCn.extension
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		RLOC_ORIGIN = RmCn
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		RLOC_RANGE = Rm1Cn1:Rm2Cn2
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		S
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		SLOW
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		STARUP_WAIT={TRUE | FALSE}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		TEMPERATURE=value[C | F | K ]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
*	*	*	*		*	*	*
*Availability depends on the release of characterization data

		TIG or: TIG= TSidentifier1 [, TSidentifier2, ... ,TSidentifiern]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		new_group_name=[RISING | FALLING] group_name1 [EXCEPT group_name2... group_namen] or: new_group_name=[TRANSHI | TRANSLO] group_name1 [EXCEPT group_name2... group_namen]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		TNM = [predefined_group:] identifier
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		TNM_NET = [predefined_group:] identifier
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		TPSYNC = identifier
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		TPTHRU = identifier
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		TSidentifier=[MAXDELAY] FROM source_group TO dest_group allowable_delay [units] or: TSidentifier=FROM source_group TO dest_group allowable_delay [units] or: TSidentifier=FROM source_group THRU thru_point [THRU thru_point1... thru_pointn] TO dest_group allowable_delay [units] or: TSidentifier=FROM source_group TO dest_group another_TSid[/ | *] number or: TSidentifier=PERIOD TNM_reference period[units] [{HIGH | LOW} [high_or_low_time [hi_lo_units]]] or: TSidentifier=PERIOD TNM_reference another_PERIOD_identifier [/ | *] number [{HIGH | LOW} [high_or_low_time [hi_lo_units]]] or: TSidentifier=FROM source_group TO dest_group TIG or: TSidentifier=FROM source_group THRU thru_point [THRU thru_point1... thru_pointn] TO dest_group TIG NOTE: The use of a colon (:) instead of a space as a separator is optional.
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		U_SET = name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		USE_RLOC = {TRUE | FALSE}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

		VOLTAGE=value[V]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
*	*	*	*		*	*	*
*Availability depends on the release of characterization data

		WIREAND
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
				*
* not supported for XC9500XL designs only

		XBLKNM = block_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Attributes/Constraints Applicability

Certain constraints can only be defined at the design level, whereas other constraints can be defined in the various configuration files. The following table lists the constraints and their applicability to the design, and the NCF, UCF, and PCF files. A check mark () indicates that the constraint applies to the item for that column.

Table 12_1 Constraint Applicability Table

Attribute/Constraint	Design	NCF	UCF	PCF
BASE
BLKNM
BUFG
CLKDV_DIVIDE
COLLAPSE
COMPGRP
CONFIG**
DECODE
DIVIDE1_BY
DIVIDE2_BY
DOUBLE
DRIVE
DROP_SPEC				*
DUTY_CYCLE_CORRECTION
EQUATE_F
EQUATE_G
FAST
FILE
FREQUENCY
HBLKNM
HU_SET
INIT
INIT_0x
INREG
IOB
KEEP
LOC				*
LOCATE
LOCK
MAP
MAXDELAY				*
MAXSKEW				*
MEDDELAY
NODELAY
NOREDUCE
OFFSET				*
OPT_EFFORT
OPTIMIZE
OUTREG
PATH
PART
PENALIZE TILDE
PERIOD				*
PIN
PRIORITIZE
PROHIBIT				*
PWR_MODE
RLOC
RLOC_ORIGIN
RLOC_RANGE
S(ave) - Net Flag attribute
SITEGRP
SLOW
STARTUP_WAIT
TEMPERATURE
TIG				*
Time group attributes
TNM
TNM_NET
TPSYNC
TPTHRU
TSidentifier				*
U_SET
USE_RLOC
VOLTAGE
WIREAND
XBLKNM
*Use cautiously - while constraint is available, there are differences between the UCF/NCF and PCF syntax. **The CONFIG attribute configures internal options of an XC3000 CLB or IOB. Do not confuse this attribute with the CONFIG primitive, which is a table containing PROHIBIT and PART attributes.

Macro and Net Propagation Rules

Not all constraints can be attached to nets and macros. The following table lists the constraints and stipulates whether they can be attached to a net, a macro, or neither.

Table 12_2 Macro and Net Propagation Rules

Syntax Descriptions

The information that follows describes in alphabetical order the attributes and constraints. A checkmark () appearing in a column means that the attribute/constraint is supported for architectures that use the indicated library. (Refer to the “Applicable Architectures” section of the “Xilinx Unified Libraries” chapter for information on the specific device architectures supported in each library.) A blank column means that the attribute/constraint is not supported for architectures that use that library.

The description for each attribute contains a subsection entitled “Applicable Elements.” This section describes the base primitives and circuit elements to which the constraint or attribute can be attached. In many cases, constraints or attributes can be attached to macro elements, in which case some resolution of the user's intent is required. Refer to the “Macro and Net Propagation Rules” section for a table describing the additional propagation rules for each constraint and attribute.

BASE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

CLB or IOB primitives

Description

The BASE attribute defines the base configuration of a CLB or an IOB. For an IOB primitive, it should always be set to IO. For a CLB primitive, it can be one of three modes in which the CLB function generator operates.

• F mode allows the CLB to implement any one function of up to five variables.
  
  
• FG mode gives the CLB any two functions of up to four variables. Of the two sets of four variables, one input (A) must be common, two (B and C) can be either independent inputs or feedback from the Qx and Qy outputs of the flip-flops within the CLB, and the fourth can be either of the two other inputs to the CLB (D and E).
  
  
• FGM mode is similar to FG, but the fourth input must be the D input. The E input is then used to control a multiplexer between the two four-input functions, allowing some six- and seven-input functions to be implemented.
  
  

CLB and IOB base configurations of the XC3000 family are illustrated in the “IOB and CLB Primitives for Base Configurations XC3000” figure. In this drawing, BASE F, FG, and FGM are for CLBs; BASE IO is for IOBs.

Figure 12.1 IOB and CLB Primitives for Base Configurations XC3000

In a schematic, BASE can be attached to any valid instance. Not supported for UCF, NCF, or PCF files.

Syntax

BASE=mode

where mode can be F, FG, or FGM for a CLB and IO for an IOB.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

N/A

BLKNM

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
1, 2, 3, 7, 8	2, 3, 4, 5, 7, 8, 9, 10, 11	2, 3, 4, 5, 7, 8, 9, 10, 11	2, 3, 4, 6, 7, 11		2, 3, 4, 5, 7, 8, 9, 10, 11	2, 3, 4, 5, 7, 8, 9, 10, 11

Applicable Elements

1. IOB, CLB and CLBMAP (See the Note at the end of this list)
   
   
2. Flip-flop and latch primitives
   
   
3. Any I/O element or pad
   
   
4. FMAP
   
   
5. HMAP
   
   
6. F5MAP
   
   
7. BUFT
   
   
8. ROM primitive
   
   
9. RAM primitives
   
   
10. RAMS and RAMD primitives
    
    
11. Carry logic primitives
    
    

NOTE

You can also attach the BLKNM constraint to the net connected to the pad component in a UCF file. NGDBuild transfers the constraint from the net to the pad instance in the NGD file so that it can be processed by the mapper. Use the following syntax.

NET net_name BLKNM=property_value

Description

Assigns block names to qualifying primitives and logic elements. If the same BLKNM attribute is assigned to more than one instance, the software attempts to map them into the same block. Conversely, two symbols with different BLKNM names are not mapped into the same block. Placing similar BLKNMs on instances that do not fit within one block creates an error.

Specifying identical BLKNM attributes on FMAP and/or HMAP symbols tells the software to group the associated function generators into a single CLB. Using BLKNM, you can partition a complete CLB without constraining the CLB to a physical location on the device.

BLKNM attributes, like LOC constraints, are specified from the schematic. Hierarchical paths are not prefixed to BLKNM attributes, so BLKNM attributes for different CLBs must be unique throughout the entire design. See the “HBLKNM” section on the attribute for information on attaching hierarchy to block names.

The BLKNM attribute allows any elements except those with a different BLKNM to be mapped into the same physical component. Elements without a BLKNM can be packed with those that have a BLKNM. See the “XBLKNM” section on the attribute for information on allowing only elements with the same XBLKNM to be mapped into the same physical component.

For XC5200, a given BLKNM string can only be used to group a logic cell (LC), which contains one register, one LUT (FMAP), and one F5_MUX element. An error will occur if two or more registers, two or more FMAPs, or two or more F5_MUX elements have the same BLKNM attribute.

Syntax

BLKNM=block_name

where block_name is a valid LCA block name for that type of symbol. For a list of prohibited block names, see the “Naming Conventions” section of each user interface manual.

For information on assigning hierarchical block names, see the “HBLKNM” section elsewhere in this chapter.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement assigns an instantiation of an element named block1 to a block named U1358.

INST $1I87/block1 BLKNM=U1358;

BUFG

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Any input buffer (IBUF) that drives a CLK, OE, or SR pin or the pad net connected to the IBUF input

Description

Maps the tagged signal to a global net.

Syntax

BUFG={CLK | OE | SR}

where CLK, OE, and SR indicate clock, output enable, or set/reset, respectively.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement maps the signal named “fastclk” to a global net.

INST clkgen/fastclk BUFG;

CLKDV_DIVIDE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Any CLKDLL or CLKDLLHF instance

Description

Specifies the extent to which the CLKDLL or CLKDLLHF clock divider (CLKDV output) is to be frequency divided.

Syntax

CLKDV_DIVIDE={1.5 | 2 | 2.5 | 3 | 4 | 5 | 8 | 16}

The default is 2 if no CLKDV_DIVIDE attribute is specified.

Example

Schematic

Attached to a CLKDLL or CLKDLLHF instance.

UCF/NCF file

This statement specifies a frequency division factor of 8 for the clock divider foo/bar.

INST foo/bar CLKDV_DIVIDE=8;

COLLAPSE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Any internal net

Description

Forces a combinatorial node to be collapsed into all of its fanouts.

Syntax

COLLAPSE

Example

Schematic

Attached to a net.

UCF/NCF file

This statement forces net $1N6745 to collapse into all its fanouts.

NET $1I87/$1N6745 COLLAPSE;

CONFIG

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

IOB and CLB primitives

Description

Defines the configuration of the internal options of a CLB or IOB.

NOTE

Do not confuse this attribute with the CONFIG primitive, which is a table containing PROHIBIT and PART attributes. Refer to the “PROHIBIT” section for information on disallowing the use of a site and to the “PART” section for information on defining the part type for the design.

Syntax

CONFIG=tag value [tag value]

where tag and value are derived from the following tables.

Table 12_3 XC3000 CLB Configuration Options

Table 12_4 XC3000 IOB Configuration Options

Example

Schematic

Attached to a valid instance.

Following is an example of a valid XC3000 CLB CONFIG attribute value.

X:QX Y:QY DX:F DY:G CLK:K ENCLK:EC

UCF/NCF file

N/A

DECODE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

WAND1

Description

Defines how a wired-AND (WAND) instance is created, either using a BUFT or an edge decoder. If the DECODE attribute is placed on a single-input WAND1 gate, the gate is implemented as an input to a wide-edge decoder in XC4000 designs.

Syntax

DECODE

DECODE attributes can only be attached to a WAND1 symbol.

Example

Schematic

Attached to a WAND1 symbol.

UCF/NCF file

This statement implements an instantiation of a wired AND using the edge decoder $COMP_1

INST address_decode/$COMP_1 DECODE;

DIVIDE1_BY and DIVIDE2_BY

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

OSC5, CK_DIV

Description

Defines the division factor for the on-chip clock dividers.

Syntax

DIVIDE1_BY={4 | 16 | 64 | 256}

DIVIDE2_BY={2 | 8 | 32 | 128 | 1024 | 4096 | 16384 | 65536}

Examples

Schematic

Attached to a valid instance.

NCF file

This statement defines the division factor of 8 for the clock divider $1I45678.

INST clk_gen/$1I45678 divide2_by=8;

NOTE

DIVDE1_BY and DIVIDE2_BY are not supported in the UCF file.

DOUBLE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

PULLUPs

Description

Specifies double pull-up resistors on the horizontal longline. On XC3000 parts, there are internal nets that can be set as 3-state with two programmable pull-up resistors available per line. If the DOUBLE attribute is placed on a PULLUP symbol, both pull-ups are used, enabling a fast, high-power line. If the DOUBLE attribute is not placed on a pull-up, only one pull-up is used, resulting in a slower, lower-power line.

When the DOUBLE attribute is present, the speed of the distributed logic is increased, as is the power consumption of the part. When only half of the longline is used, there is only one pull-up at each end of the longline.

While the DOUBLE attribute can be used for the XC4000 and Spartans, it is not recommended. The mapper activates both pull-up resistors if the entire longline (not a half-longline) is used. When DOUBLE is used, PAR will not add an additional pull-up to achieve your timing constraints while routing XC4000 or Spartan series designs (refer to the “PAR - Place and Route” chapter of the Development System Reference Guide for information on PAR and timing optimization).

Syntax

DOUBLE

Example

Schematic

Attached to a PULLUP only.

UCF/NCF file

N/A

DRIVE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
		* 1				1	2
* supported for XC4000XV and XC4000XLA designs only

Applicable Elements

1. IOB output components (OBUF, OFD, etc.)
   
   
2. OBUF, OBUFT, IOBUF instances (with implied LVTTL standards)
   
   

Description

For the XC4000XV, XC4000XLA, and SpartanXL, programs the output drive current from High (24 mA) to Low (12 mA).

For Virtex, selects output drive strength (mA) for the components that use the LVTTL interface standard.

Syntax

XC4000XV, XC4000XLA, and SpartanXL

DRIVE={12 | 24}

Virtex

DRIVE={2 | 4 | 6 | 8 | 12 | 16 | 24}

where 12 mA is the default.

Example

Schematic

Attached to a valid IOB output component.

UCF/NCF file

This statement specifies a High drive.

INST /top/my_design/obuf DRIVE=24 ;

DROP_SPEC

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

All timing specifications. Should be used only in UCF or PCF files.

Description

Allows you to specify that a timing constraint defined in the input design should be dropped from the analysis. This constraint can be used when new specifications defined in a constraints file do not directly override all specifications defined in the input design, and some of these input design specifications need to be dropped.

While this timing command is not expected to be used much in an input netlist (or NCF file), it is not illegal. If defined in an input design this attribute must be attached to a TIMESPEC primitive.

Syntax

TSidentifier=DROP_SPEC

where TSidentifier is the identifier name used for the timing specification that is to be removed.

Example

Schematic

N/A

UCF/NCF file

This statement cancels the input design specification TS67.

TIMESPEC TSidentifier TS67=DROP_SPEC;

DUTY_CYCLE_CORRECTION

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Any CLKDLL, CLKDLLHF, or BUFGDLL instance

Description

Corrects the duty cycle of the CLK0 output.

Syntax

DUTY_CYCLE_CORRECTION={TRUE | FALSE}

where TRUE corrects the duty cycle to be a 50_50 duty cycle and FALSE does not change the duty cycle. The default is FALSE.

Example

Schematic

Attached to a CLKDLL, CLKDLLHF, or BUFGDLL instance.

UCF/NCF file

This statement specifies a 50_50 duty cycle for foo/bar.

INST foo/bar DUTY_CYCLE_CORRECTION=TRUE;

EQUATE_F and EQUATE_G

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

CLB primitive

Description

These attributes set the logic equations describing the F and G function generators of a CLB, respectively.

Syntax

EQUATE_F=equation

EQUATE_G=equation

where equation is a logical equation of the function generator inputs (A, B, C, D, E, QX, QY) using the boolean operators listed in the following table.

Table 12_5 Valid XC3000 Boolean Operators

Example

Schematic

Attached to a valid instance.

Here are two examples illustrating the use of the EQUATE_F attribute.

EQUATE_F=F=((~A*B)+D))@Q
F=A@B+(C*~D)

UCF/NCF file

N/A

FAST

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Output primitives, output pads, bidirectional pads

NOTE

You can also attach the FAST attribute to the net connected to the pad component in a UCF file. NGDBuild transfers the attribute from the net to the pad instance in the NGD file so that it can be processed by the mapper. Use the following syntax.

NET net_name FAST

Description

Increases the speed of an IOB output.

NOTE

The FAST attribute produces a faster output but may increase noise and power consumption.

Syntax

FAST

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement increases the output speed of the element  y2.

INST $1I87/y2 FAST;

This statement increases the output speed of the pad to which net1 is connected.

NET net1 FAST;

FILE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Macros that refer to underlying non-schematic designs

Description

FILE is attached to a macro that does not have an underlying schematic. It identifies the file to be looked at for a logic definition. The type of file to be searched for is defined by the search order of the program compiling the design.

Syntax

FILE=file_name[.extension]

where file_name is the name of a file that represents the underlying logic for the element carrying the attribute. Example file types include EDIF, XTF, NMC.

Schematic

Attached to a valid instance.

UCF/NCF file

N/A

HBLKNM

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
1, 2, 3, 7, 8, 9, 10,12	2, 3, 4, 5, 7, 8, 10, 11, 12, 13, 14, 15	2, 3, 4, 5, 7, 8, 10, 12, 13, 14, 15	2, 3, 4, 6, 7, 10, 15		2, 3, 4, 5, 7, 8, 10, 11, 12, 13, 14, 15	2, 3, 4, 5, 7, 8, 10, 12, 13, 14, 15

Applicable Elements

1. IOB, CLB and CLBMAP (See Note below)
   
   
2. Registers
   
   
3. I/O elements and pads
   
   
4. FMAP
   
   
5. HMAP
   
   
6. F5MAP
   
   
7. BUFT
   
   
8. PULLUP
   
   
9. ACLK, GCLK
   
   
10. BUFG
    
    
11. BUFGS, BUFGP
    
    
12. ROM
    
    
13. RAM
    
    
14. RAMS and RAMD
    
    
15. Carry logic primitives
    
    

NOTE

You can also attach the HBLKNM constraint to the net connected to the pad component in a UCF file. NGDBuild transfers the constraint from the net to the pad instance in the NGD file so that it can be processed by the mapper. Use the following syntax.

NET net_name HBLKNM=property_value

Description

Assigns hierarchical block names to logic elements and controls grouping in a flattened hierarchical design. When elements on different levels of a hierarchical design carry the same block name and the design is flattened, NGDBuild prefixes a hierarchical path name to the HBLKNM value.

Like BLKNM, the HBLKNM attribute forces function generators and flip-flops into the same CLB. Symbols with the same HBLKNM attribute map into the same CLB, if possible. However, using HBLKNM instead of BLKNM has the advantage of adding hierarchy path names during translation, and therefore the same HBLKNM attribute and value can be used on elements within different instances of the same macro.

For XC5200, a given HBLKNM string can only be used to group a logic cell (LC), which contains one register, one LUT (FMAP), and one F5_MUX element. An error will occur if two or more registers, two or more FMAPs, or two or more F5_MUX elements have the same HBLKNM attribute.

Syntax

HBLKNM=block_name

where block_name is a valid LCA block name for that type of symbol.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement specifies that the element this_hmap will be put into the block named group1.

INST $I13245/this_hmap HBLKNM=group1;

This statement attaches the HBLKNM constraint to the pad connected to net1.

NET net1 HBLKNM=$COMP_0;

NOTE

Elements with the same HBLKNM are placed in the same logic block if possible. Otherwise an error occurs. Conversely, elements with different block names will not be put into the same block.

HU_SET

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
	1, 2, 3, 5, 7, 8, 9, 10, 12	1, 2, 3, 5, 7, 8, 9, 10, 12	1, 2, 4, 6, 7, 8, 12		1, 2, 3, 5, 7, 8, 9, 10, 12	1, 2, 3, 5, 7, 8, 9, 10, 12	1,2, 7, 11, 12

Applicable Elements

1. Registers
   
   
2. FMAP
   
   
3. HMAP
   
   
4. F5MAP
   
   
5. CY4
   
   
6. CY_MUX
   
   
7. Macro Instance
   
   
8. EQN
   
   
9. ROM
   
   
10. RAM
    
    
11. RAMS, RAMD
    
    
12. BUFT
    
    

Description

The HU_SET constraint is defined by the design hierarchy. However, it also allows you to specify a set name. It is possible to have only one H_SET constraint within a given hierarchical element (macro) but by specifying set names, you can specify several HU_SET sets.

NGDBuild hierarchically qualifies the name of the HU_SET as it flattens the design and attaches the hierarchical names as prefixes. The difference between an HU_SET constraint and an H_SET constraint is that an HU_SET has an explicit user-defined and hierarchically qualified name for the set, but an H_SET constraint has only an implicit hierarchically qualified name generated by the design-flattening program. An HU_SET set “starts” with the symbols that are assigned the HU_SET constraint, but an H_SET set “starts” with the instantiating macro one level above the symbols with the RLOC constraints.

For background information about using the various set attributes, refer to the “RLOC Sets” section.

Syntax

HU_SET=set_name

where set_name is the identifier for the set; it must be unique among all the sets in the design.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement assigns an instance of the register FF_1 to a set named heavy_set.

INST $1I3245/FF_1 HU_SET=heavy_set;

INIT

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
	1, 2, 3	1, 2, 3		3	1, 2, 3	1, 2, 3	2, 3, 4

Applicable Elements

1. ROM
   
   
2. RAM
   
   
3. Registers
   
   
4. LUTs, SRLs
   
   

Description

Initializes ROMs, RAMs, registers, and look-up tables. The least significant bit of the value corresponds to the value loaded into the lowest address of the memory element. For register initialization, S indicates Set and R indicates Reset. The INIT attribute can be used to specify the initial value directly on the symbol with the following limitation. INIT may only be used on a RAM or ROM that is 1 bit wide and not more than 32 bits deep.

Syntax

INIT={value | S | R}

where value is a 4-digit or 8-digit hexadecimal number that defines the initialization string for the memory element, depending on whether the element is 16-bit or 32-bit. For example, INIT=ABAC1234.

S indicates Set and R indicates Reset for registers.

NOTE

For XC4000 and Spartans, INIT cannot specify a register as Set if the reset pin is being used or as Reset if the set pin is being used.

Example

Schematic

Attached to a net, pin, or instance.

UCF/NCF file

INIT={S | R} is supported in both the NCF and UCF files. It is allowed in the UCF to control the startup state of registers (primarily for CPLDs).

INIT=value is supported in the NCF file only. This statement defines the initialization string for an instantiation of the memory element ROM2 to be the 16-bit hexadecimal string 5555.

INST $1I3245/ROM2 INIT = 5555;

NOTE

INIT=value is not supported in the UCF file.

INIT_0x

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Block RAMs

Description

Specifies initialization strings for block RAM components.

Syntax

INIT_0x=value

where

x is any hexadecimal value 0 through F that specifies which 256 bits (see the following table) of the 4096-bit block RAM to initialize to the specified value.

value is a string of hexadecimal characters up to 64 digits wide. If the INIT_0x attribute has a value less than the required 64 hex digits, the value will be padded with zeros from the most significant bit (MSB) side. This fills the 256 bits in the initialization string (4 bits per hexadecimal character * 64 characters).

INIT_0x usage rules

A summary of the rules for the INIT_0x attribute follows.

• If no INIT_0x attribute is attached to a block RAM, the contents of the RAM defaults to zero.
  
  
• Each initialization string defines 256 bits of the 4096-bit block RAM. For example, for a 4096-bit deep x 1-bit wide block RAM, INIT_00 assigns the 256 bits to addresses 0 through 255 and INIT_01 assigns the 256 bits to addresses 256 through 511. For a 2048-bit deep x 2-bit wide block RAMs, INIT_00 assigns the 256 bits to addresses 0 through 127 (a 2-bit value at each address) and INIT_01 assigns the 256 bits to addresses 128 through 255.
  
  
• If a subset of the INIT_00 through INIT_0F properties are specified for a block RAM, the remaining properties default to zero.
  
  
• In an initialization string, the least significant bit (LSB) is the right-most value.
  
  
• The least significant word of the block RAM is composed of the least significant bits of the block RAM.
  
  

INIT_0x on block RAMs of various widths

The initialization string "fills" the block RAM beginning from the LSB of the 256 bits for the specified INIT_0x addresses. The size of the word filling each address depends on the width of the block RAM being initialized - 1, 2, 4, 8, or 16 bits.

For example, if INIT_0C=bcde7, the corresponding binary sequence is as follows:

	1011	1100	1101	1110	0111	LSB
	b	c	d	e	7

The appropriate addresses in the RAM are initialized with the binary string content depending on the width of the RAM as shown in the following table.

Example

Schematic

Attached to a block RAM instance.

UCF/NCF file

The following statement specifies that the INIT_03 addresses in instance foo/bar be initialized, starting from the LSB, to the hex value aaaaaaaaaaaaaaaaaaaa (padded with 44 zeros from the MSB side).

INST foo/bar INIT_03=aaaaaaaaaaaaaaaaaaaa;

INREG

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Flip-flops, latches

Description

Because XC5200 IOBs do not have flip-flops or latches, you can apply this attribute to meet fast setup timing requirements. If a flip-flop or latch is driven by an IOB, you can specify INREG to enable PAR (Place and Route) to place the flip-flop/latch close to the IOB so that the two elements can be connected using fast routes. See also the “OUTREG” section.

Syntax

INREG

Example

Schematic

Attached to a latch or flip-flop instance.

UCF/NCF file

This statement directs PAR to place the flip-flop $I1 near the IOB driving it.

INST $I1 INREG;

IOB

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Non-INFF/OUTFF flip-flop and latch primitives, registers

Description

Indicates which flip-flops and latches can be moved into the IOB. The mapper supports a command line option (-pr i | o | b) that allows flip-flop/latch primitives to be pushed into the input IOB (i), output IOB (o), or input/output IOB (b) on a global scale. The IOB constraint, when associated with a flip-flop or latch, tells the mapper to pack that instance into an IOB type component if possible. The IOB constraint has precedence over the mapper "-pr" command line option.

Syntax

IOB={TRUE | FALSE}

where TRUE allows the flip-flop/latch to be pulled into an IOB and FALSE indicates not to pull it into an IOB.

Example

Schematic

Attached to a flip-flop or latch instance or to a register.

UCF/NCF file

This statement prevents the mapper from placing the foo/bar instance into an IOB component.

INST foo/bar IOB=TRUEE;

KEEP

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex

Applicable Elements

Nets

Description

When a design is mapped, some nets may be absorbed into logic blocks. When a net is absorbed into a block, it can no longer be seen in the physical design database. This may happen, for example, if the components connected to each side of a net are mapped into the same logic block. The net may then be absorbed into the block containing the components. The KEEP constraint prevents this from happening.

In Virtex, KEEP makes the signal visible at the BEL level, not the CLB level as in other architectures.

NOTE

The KEEP property is translated into an internal constraint known as NOMERGE when targeting an FPGA. Messaging from the implementation tools will therefore refer to the system property NOMERGE - not KEEP.

Syntax

KEEP

Example

Schematic

Attached to a net.

UCF/NCF file

This statement ensures that the net $SIG_0 will remain visible.

NET $1I3245/$SIG_0 KEEP;

LOC

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
1, 5, 6, 12	1, 2, 3, 5, 7, 9, 10, 11, 12, 13, 14, 15	1, 2, 3, 5, 7, 9, 10, 11, 12, 13, 14, 15	1, 2, 4, 5, 8, 12, 14	1, 5, 16	1, 2, 3, 5, 7, 9, 10, 11, 12, 13, 14, 15	1, 2, 3, 5, 7, 9, 10, 11, 12, 13, 14, 15	1, 2, 5, 6, 10, 11, 12, 13, 14, 15, 16, 17

Applicable Elements

1. Registers
   
   
2. FMAP
   
   
3. HMAP
   
   
4. F5MAP
   
   
5. IO elements
   
   
6. CLB and IOB primitives, CLBMAP
   
   
7. CY4
   
   
8. CY_MUX
   
   
9. ROM
   
   
10. RAM
    
    
11. RAMS, RAMD
    
    
12. BUFT
    
    
13. WAND
    
    
14. Clock buffers
    
    
15. Edge decoders
    
    
16. Any instance
    
    
17. RAMB4s
    
    

Description for FPGAs

Defines where a symbol can be placed within an FPGA. It specifies the absolute placement of a design element on the FPGA die. It can be a single location, a range of locations, or a list of locations. The LOC constraint can be specified from the schematic and statements in a constraints file can also be used to direct placement.

You can specify multiple locations for the same symbol by using a comma (,) to separate each location within the field. It specifies that the symbols be placed in any of the locations specified. Also, you can specify an area in which to place a symbol or group of symbols.

The legal names are a function of the target part type. However, to find the correct syntax for specifying a target location, you can load an empty part into EPIC (the design editor). Place the cursor on any block and click to display its location in the EPIC history area. Do not include the pin name such as .I, .O, or .T as part of the location.

You can use the LOC constraint for logic that uses multiple CLBs, IOBs, soft macros, or other symbols. To do this, use the LOC attribute on a soft macro symbol, which passes the location information down to the logic on the lower level. The location restrictions are applied to all blocks on the lower level for which LOCs are legal.

XC5200

The XC5200 CLB is divided into four physical site locations that each contain one flip-flop, one function generator, and one carry logic element. Therefore, for the XC5200, each LOC attribute can be used for only one register, one FMAP, one F5_MUX element, or one CY_MUX element. An error will occur if two or more registers, two or more FMAPs, two or more F5_MUX elements, or two or more CY_MUX elements have the same LOC attribute.

Virtex

The physical site specified in the location value is defined by the row and column numbers for the array, with an optional extension to define the slice for a given row/column location. The Virtex slice is composed of two LUTs (that can be configured as RAM or shift registers), two flip-flops (that can also be configured as latches), two XORCYs, two MULT_ANDs, one F5MUX, one F6MUX, and one MUXCY. Only one F6MUX can be used between the two adjacent slices in a specific row/column location. The two slices at a specific row/column location are adjacent to one another.

The block RAMs (RAMB4s) have a different row/column grid specification than the CLB and TBUFs. A block RAM located at RAMB4_R3C1 is not located at the same site as a flip-flop located at CLB_R3C1. Therefore, the location value must start with "CLB," "TBUF," or "RAMB4." The location cannot be shortened to reference only the row, column, and extension.The optional extension specifies the left-most or right-most slice for the row/column. While the XC4000 and Spartans allow extensions such as .FFX, .FFY, .F and .G to identify specific flip-flops and LUTs within the CLB, these extensions are not required or allowed for Virtex.

The location value for global buffers and DLL elements is the specific physical site names for available locations.

Description for CPLDs

For CPLDs, use the LOC=pin_name attribute on a PAD symbol or pad net to assign the signal to a specific pin. The PAD symbols are IPAD, OPAD, and IOPAD. You can use the LOC=FBnn attribute on any instance or its output net to assign the logic or register to a specific function block or macrocell, provided the instance is not collapsed.

Pin assignments and function block assignments are unconditional; that is, the software does not attempt to relocate a pin if it cannot achieve the specified assignment. You can apply the LOC constraint to as many symbols in your design as you like. However, each assignment further constrains the software as it automatically allocates logic and I/O resources to internal nodes and I/O pins with no LOC constraints.

The LOC=FBnn_mm attribute on any internal instance or output pad assigns the corresponding logic to a specific function block or macrocell within the CPLD. If a LOC is placed on a symbol that does not get mapped to a macrocell or is otherwise removed through optimization, the LOC will be ignored.

NOTE

Pin assignment using the LOC attribute is not supported for bus pad symbols such as OPAD8.

Location Types

Use the following location types to define the physical location of an element.

The wildcard character (*) can be used to replace a single location with a range as shown in the following examples.

NOTE

The wildcard character is not supported for Virtex global buffer or DLL locations.

The following are not supported.

• Dot extensions on ranges. For example, LOC=CLB_R0C0:CLB_R5C5.G. However, for the XC5200, range locations will be expanded to include extensions, CLB_R0C0.*:CLB_R5C5.*, for example, when the mapper passes a range constraint to the PCF file.
  
  
• B, L, R, T used to indicate IO edge locations (bottom, left, top, right)
  
  
• LB, RB, LT, RT, BR, TR, BL, TL used to indicate IO half edges (left bottom, right bottom, etc.)
  
  
• Wildcard character for Virtex global buffer, global pad, or DLL locations.
  
  

Syntax for FPGAs

Single location

LOC=location

where location is a legal LCA location for the LCA part type. Examples of the syntax for single LOC constraints are given in the “Single LOC Constraint Examples” table.

Table 12_6 Single LOC Constraint Examples

Multiple locations

LOC=location1,location2,...,locationn

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. Examples of multiple LOC constraints are provided in the “Multiple LOC Constraint Examples” table.

Table 12_7 Multiple LOC Constraint Examples

Range of locations

LOC=location:location [SOFT]

You can define a range by specifying the two corners of a bounding box. Specify the upper left and lower right corners of an area in which logic is to be placed. Use a colon (:) to separate the two boundaries. The logic represented by the symbol is placed somewhere inside the bounding box. The default is to interpret the constraint as a “hard” requirement and to place it within the box. If SOFT is specified, PAR may place the constraint elsewhere if better results can be obtained at a location outside the bounding box. Examples of LOC constraints used to specify an area (range) are given in the “Area LOC Constraint Examples” table.

Table 12_8 Area LOC Constraint Examples

NOTE

For area constraints, LOC ranges can be supplemented by the user with the keyword SOFT.

Syntax for CPLDs

LOC=pin_name

or

LOC=FBnn

or

LOC=FBnn_mm

where

pin_name is Pnn for PC packages; nn is a pin number. The pin name is nn (row number and column number) for PG packages. See the appropriate data book for the pin package names, for example, p12. Examples are LOC=P24 and LOC=G2. This form is valid only on pad instances.

nn is a function block number and mm is a macrocell within a function block number. This form is valid on any instances.

Examples

Refer to the “Placement Constraints” section for multiple examples of legal placement constraints for each type of logic element (flip-flops, ROMs and RAMs, block RAMS, FMAPs and HMAPs, CLBMAPs, BUFTs, CLBs, IOBs, I/Os, edge decoders, global buffers) in FPGA designs.

Schematic

Attached to an instance.

UCF/NCF file

This specifies that an instance of the element BUF1 be placed above the CLB in row 6, column 9. For XC4000 or Spartan series devices, you can place the TBUF above or below the CLB. For XC5200 devices, you can place the TBUF in one of four locations (.0-.3).

INST /DESIGN1/GROUPS/BUF1 LOC=TBUF_R6C9.1 ;

This specifies that each instance found under “FLIP_FLOPS” is to be placed in any CLB in column 8.

INST /FLIP_FLOPS/* LOC=CLB_R*C8;

This specifies that an instantiation of MUXBUF_D0_OUT be placed in IOB location P110.

INST MUXBUF_D0_OUT LOC=P110 ;

This specifies that the net DATA<1> be connected to the pad from IOB location P111.

NET DATA<1> LOC=P111 ;

MAP

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex
4	1, 2	1, 2	1, 3		1, 2	1, 2	1

Applicable Elements

1. FMAP
   
   
2. HMAP
   
   
3. F5MAP
   
   
4. CLBMAP
   
   

Description

Placed on an FMAP, F5MAP, HMAP, or CLBMAP to specify whether pin swapping and the merging of other functions with the logic in the map are allowed. If merging with other functions is allowed, other logic can also be placed within the CLB, if space allows.

Syntax

MAP=[PUC | PUO | PLC | PLO]

where

PUC means that the CLB pins are unlocked, ad the CLB is closed.

PUO means that the CLB pins are unlocked, and the CLB is open.

PLC means that the CLB pins are locked, and the CLB is closed.

PLO means that the CLB pins are locked, and the CLB is open.

“Unlocked” in these definitions means that the software can swap signals among the pins on the CLB; “locked” means that it cannot. “Open” means that the software can add or remove logic from the CLB; conversely, “closed” indicates that the software cannot add or remove logic from the function specified by the MAP symbol.

The default is PUO.

NOTE

Currently, only PUC and PUO are observed. PLC and PLO are translated into PUC and PUO, respectively.

Example

Schematic

Attached to a map symbol instance.

UCF/NCF file

This statement allows pin swapping and ensures that no logic other than that defined by the original map will be mapped into the function generators.

INST $1I3245/map_of_the_world map=puc;

MAXDELAY

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Virtex