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		BASE = {F | FG | FGM | IO}
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

BLKNM		BLKNM = block_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

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

COLLAPSE		COLLAPSE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

CONFIG*		CONFIG = tag value [tag value]
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	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		DECODE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

DOUBLE		DOUBLE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

DROP_SPEC		TSidentifier=DROP_SPEC
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

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

FAST		FAST
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

HBLKNM		HBLKNM = block_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

HU_SET		HU_SET = set_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

INIT_0x		INIT_0x = value
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

INREG		INREG
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

IOSTANDARD		IOSTANDARD=iostandard_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

KEEPER		KEEPER
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

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

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

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

MEDDELAY		MEDDELAY
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

NODELAY		NODELAY
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

NOREDUCE		NOREDUCE
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

OFFSET		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	Spartan2	Virtex

ONESHOT		ONESHOT
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

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

OUTREG		OUTREG
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

PART		PART = part_type
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

PERIOD		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	Spartan2	Virtex

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

PULLDOWN		PULLDOWN
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

PULLUP		PULLUP
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

REG		REG={ CE | TFF }
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

RLOC_ORIGIN		RLOC_ORIGIN = RmCn
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

S(ave) - Net Flag Attribute		S
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

SLOW		SLOW
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

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

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

Time Group Attributes		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	Spartan2	Virtex

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

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

TPSYNC		TPSYNC = identifier
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

TPTHRU		TPTHRU = identifier
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

TSidentifier		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	Spartan2	Virtex

U_SET		U_SET = name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

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

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

WIREAND		WIREAND
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex
				*
* not supported for XC9500XL and XC9500XV designs

XBLKNM		XBLKNM = block_name
XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	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.

The CE column indicates which constraints can be entered using the Xilinx Constraints Editor, a GUI tool in the Xilinx Development System. The Constraints Editor passes these constraints to the implementation tools through a UCF file.

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	CE	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
IOSTANDARD
KEEP
KEEPER
LOC					*
LOCATE
LOCK
MAP
MAXDELAY					*
MAXSKEW					*
MEDDELAY
NODELAY
NOREDUCE
OFFSET					*
ONESHOT
OPT_EFFORT
OPTIMIZE
OUTREG
PATH
PART
PENALIZE TILDE
PERIOD					*
PIN
PRIORITIZE
PROHIBIT					*
PULLDOWN
PULLUP
PWR_MODE
REG
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 - although the 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. ***INIT is allowed in the UCF for CPLDs only.

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	Spartan2	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

Attach to a valid instance.

UCF/NCF file

N/A

Constraints Editor

N/A

BLKNM

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	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	1, 2, 3, 4, 7, 8, 9, 10, 11	1, 2, 3, 4, 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

BLKNM 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 section on the “HBLKNM” 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 section on the “XBLKNM” 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 in this chapter.

Example

Schematic

Attach 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;

Constraints Editor

N/A

BUFG

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

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

Description

When applied to an input buffer or input pad net, th BUFG attribute maps the tagged signal to a global net. When applied to an internal net, the tagged signal is brought out to a global device control pin and then routed to the connected internal control pins via a global net.

Syntax

BUFG={CLK | OE | SR}

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

Example

Schematic

Attach to an IBUF instance of the input pad connected to an IBUF input.

UCF/NCF file

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

NET fastclk BUFG=CLK;

Constraints Editor

N/A

CLKDV_DIVIDE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

Any CLKDLL or CLKDLLHF instance

Description

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

Syntax

CLKDV_DIVIDE={1.5 | 2.0 | 2.5 | 3.0 | 4.0 | 5.0 | 8.0 | 16.0}

The default is 2.0 if no CLKDV_DIVIDE attribute is specified.

Note: The CLKDV_DIVIDE value must be entered as a real number.

Example

Schematic

Attach 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;

Constraints Editor

N/A

COLLAPSE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

Any internal net

Description

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

Syntax

COLLAPSE

Example

Schematic

Attach to a logic symbol or its output net.

UCF/NCF file

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

NET $1I87/$1N6745 COLLAPSE;

Constraints Editor

N/A

CONFIG

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

IOB and CLB primitives

Description

CONFIG 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

Attach 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

Constraints Editor

N/A

DECODE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

WAND1

Description

DECODE 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

Attach 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;

Constraints Editor

N/A

DIVIDE1_BY and DIVIDE2_BY

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

OSC5, CK_DIV

Description

DIVIDE1_BY and DIVIDE2_BY define 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

Attach 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.

Constraints Editor

N/A

DOUBLE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

PULLUP components

Description

DOUBLE 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, Spartan, and SpartanXL, 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, Spartan, or SpartanXL 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

Attach to a PULLUP component only.

UCF/NCF file

N/A

Constraints Editor

N/A

DRIVE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex
		* 1				1	2	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, DRIVE programs the output drive current from High (24 mA) to Low (12 mA).

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

Syntax

XC4000XV, XC4000XLA, and SpartanXL

DRIVE={12 | 24}

Spartan2, Virtex

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

where 12 mA is the default.

Example

Schematic

Attach to a valid IOB output component.

UCF/NCF file

This statement specifies a High drive.

INST /top/my_design/obuf DRIVE=24 ;

Constraints Editor

DRIVE current can be selected for any output pad signal in the Ports tab (I/O Configuration Options).

DROP_SPEC

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

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

Description

DROP_SPEC 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;

Constraints Editor

N/A

DUTY_CYCLE_CORRECTION

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

Any CLKDLL, CLKDLLHF, or BUFGDLL instance

Description

DUTY_CYCLE_CORRECTION 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

Attach 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;

Constraints Editor

N/A

EQUATE_F and EQUATE_G

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

CLB primitive

Description

EQUATE_F and EQUATE_G 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

Attach 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

Constraints Editor

N/A

FAST

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	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

FAST 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

Attach 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;

Constraints Editor

FAST slew rate can be selected for any output pad signal in the Ports tab (I/O Configuration Options).

FILE

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

Macros that refer to underlying non-schematic designs

Description

FILE is attached to a macro (a custom symbol) that does not have an underlying schematic. It identifies the file to be looked at for the logic definition of that macro.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, EDN, NMC.

Schematic

Attach to a valid instance.

UCF/NCF file

N/A

Constraints Editor

N/A

HBLKNM

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	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

HBLKNM 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

Attach 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.

Constraints Editor

N/A

HU_SET

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	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	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

Attach 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;

Constraints Editor

N/A

INIT

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

Applicable Elements

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

Description

INIT 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. If the INIT attribute is not specified, the RAM is initialized with zero.

Note: For RAM32X1S and RAM32X1S_1, mapping of the upper and lower INIT values to the F and G function generators are handled differently for Virtex and Spartan2 than they are for XC4000E, XC4000X, Spartan, and SpartanXL. Lower INIT values get mapped to the F and upper INIT values get mapped to the G for XC4000E, XC4000X, Spartan, and SpartanXL. For Virtex and Spartan2, lower INIT values get mapped to the G function generator and upper INIT values get mapped to the F function generator.

S indicates Set and R indicates Reset for registers.

Note: For XC4000E, XC4000X, Spartan, and SpartanXL, 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

Attach 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.

Constraints Editor

N/A

INIT_0x

XC3000	XC4000E	XC4000X	XC5200	XC9000	Spartan	SpartanXL	Spartan2	Virtex

Applicable Elements

Block RAMs

Description

INIT_0x 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).