Previous

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
Virtex









BLKNM

BLKNM = block_name
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









BUFG

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









CLKDV_DIVIDE

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









COLLAPSE

COLLAPSE
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









CONFIG
*
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

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









DOUBLE

DOUBLE
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









DRIVE

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

DROP_SPEC

TSidentifier=DROP_SPEC
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









DUTY_CYCLE_CORRECTION


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









EQUATE_F and EQUATE_G

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









FAST

FAST
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









FILE

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









HBLKNM

HBLKNM = block_name
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









HU_SET

HU_SET = set_name
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









INIT

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









INIT_0x

INIT_0x = value
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









INREG

INREG
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









IOB

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









KEEP

KEEP
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex







*
*Only at BEL level

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
Virtex









MAP

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

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









MAXSKEW

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









MEDDELAY

MEDDELAY
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









NODELAY

NODELAY
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









NOREDUCE

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









OPT_EFFORT

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









OPTIMIZE

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









OUTREG

OUTREG
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









PART

PART = part_type
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
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
Virtex









PROHIBIT

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









PWR_MODE

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









RLOC

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









RLOC_ORIGIN

RLOC_ORIGIN = RmCn
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









RLOC_RANGE

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









S(ave) - Net Flag Attribute

S
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









SLOW

SLOW
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









STARTUP_WAIT

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









TEMPERATURE

TEMPERATURE=value[C | F | K ]
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex
*
*
*
*

*
*
*
*Availability depends on the release of characterization data

TIG

TIG
or:
TIG= TSidentifier1 [, TSidentifier2, ... ,TSidentifiern]
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
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
Virtex









TNM

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









TNM_NET

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









TPSYNC

TPSYNC = identifier
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









TPTHRU

TPTHRU = identifier
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
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
Virtex









U_SET

U_SET = name
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









USE_RLOC

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









VOLTAGE

VOLTAGE=value[V]
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex
*
*
*
*

*
*
*
*Availability depends on the release of characterization data

WIREAND

WIREAND
XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex




*



* not supported for XC9500XL designs only

XBLKNM

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

Constraint/Attribute
Action when attached to a net
Action when attached to a macro
BASE
illegal
illegal
BLKNM
illegal
Note 4
BUFG
Note 3
illegal
CLKDV_DIVIDE
illegal
illegal
COLLAPSENote 3
illegal
CONFIG**
illegal
illegal
DECODE
Note 1
Note 4
DIVIDE1_BY and DIVIDE2_BY
Note 1
Note 4
DOUBLE
Note 1
Note 4
DRIVE
Note 6
Note4
DROP_SPEC
illegal
illegal
DUTY_CYCLE_CORRECTION
illegal
Note 4
EQUATE_F and EQUATE_G
illegal
illegal
FAST
Note 6
Note 4
FILE
illegal
Note 5
HBLKNM
illegal
Note 4
HU_SET
illegal
Note 4
INIT
FPGA: illegal
CPLD: Note 1
Note 4
INIT_0x
illegal
illegal
INREG
illegal
illegal
IOB
illegal
Note 4
KEEP
Note 3
illegal
LOC
FPGA: Note 6
CPLD: Note 1
Note 4
MAP
illegal
illegal
MAXDELAY
Note 3
illegal
MAXSKEW
Note 3
illegal
MEDDELAY
Note 6
Note 4
NODELAY
Note 6
Note 4
NOREDUCE
Note 3
illegal
OFFSET
Note 3
illegal
OPTIMIZE
illegal
Note 5
OPT_EFFORT
illegal
Note 5
OUTREG
illegal
illegal
PART
illegal
illegal
PERIOD
Note 3
illegal
PROHIBIT
illegal
illegal
PWR_MODE
Note 2
Note 4
RLOC
illegal
Note 4
RLOC_ORIGIN
illegal
Note 4
RLOC_RANGE
illegal
Note 4
S(ave) - Net Flag Attribute
Note 3
illegal
SLOW
Note 6
Note 4
STARTUP_WAIT
illegal
Note 4
TEMPERATURE
illegal
illegal
TIG
Note 2
Note 4
Time Group Attributes
illegal
illegal
TNM
Note 2
Note 4
TNM_NET
Note 2
illegal
TPSYNC
Note 3
illegal
TPTHRU
Note 3
illegal
TSidentifier
illegal
illegal
U_SET
illegal
Note 4
USE_RLOC
illegal
Note 4
VOLTAGE
illegal
illegal
WIREAND
Note 3
illegal
XBLKNM
illegal
Note 4
Note 1: Attaches to all applicable elements that drive the net.
Note 2: The attribute has a net form and so no special propagation is required.
Note 3: Attribute is a net attribute and any attachment to a macro is illegal.
Note 4: Propagated to all applicable elements in the hierarchy below the module.
Note 5: Attribute is a macro attribute and any attachment to a net is illegal.
Note 6: Attribute is illegal when attached to a net except when the net is connected to a pad. In this case, the attribute is treated as attached to the pad instance.
*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.

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.

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

Tag
BASE F
BASE FG
BASE FGM*
X
F, QX
F, QX
M, QX
Y
F, QY
G, QY
M, QY
DX
DI, F
DI, F, G
DI, M
DY
DI, F
DI, F, G
DI, M
CLK
K, NOT
K, NOT
K, NOT
RSTDIR
RD
RD
RD
ENCLK
EC
EC
EC
F
A,B,C,D,E,QX, QY
A,B,C,D,E,QX, QY
A,B,C,D,QX, QY
G
None
A,B,C,D,E,QX, QY
A,B,C,D,QX, QY
*For BASE FGM, M=F if E=0, and M=G if E=1

Table 12_4 XC3000 IOB Configuration Options

Tag
BASE IO
IN
I, IQ, IKNOT, FF, LATCH, PULLUP
OUT
O, OQ, NOT, OKNOT, FAST
TRI
T, NOT

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

Symbol
Boolean Equivalent
~
NOT
*
AND
@
XOR
+
OR
( )
Group expression

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
Addresses

4096 x 1
2048 x 2
1024 x 4
512 x 8
256 x 16
INIT_00
255 - 0
127 - 0
63 - 0
31 - 0
15 - 0
INIT_01
511 - 256
255 - 128
127 - 64
63 - 32
31 - 16
INIT_02
767 - 512
383 - 256
191 - 128
95 - 64
47 - 32
INIT_03
1023 - 768
511 - 384
255 - 192
127 - 96
63 - 48
INIT_04
1279 - 1024
639 - 512
319 - 256
159 - 128
79 - 64
INIT_05
1535 - 1280
767 - 640
383 - 320
191 - 160
95 - 80
INIT_06
1791 - 1536
895 - 768
447 - 384
223 - 192
111 - 96
INIT_07
2047 - 1792
1023 - 896
511 - 448
255 - 224
127 - 112
INIT_08
2303 - 2048
1151 - 1024
575 - 512
287 - 256
143 - 128
INIT_09
2559 - 2304
1279 - 1152
639 - 576
319 - 288
159 - 144
INIT_0A
2815 - 2560
1407 - 1280
703 - 640
351 - 320
175 - 160
INIT_0B
3071 - 2816
1535 - 1408
767 - 704
383 - 352
191 - 176
INIT_0C
3327 - 3072
1663 - 1536
831 - 768
415 - 384
207 - 192
INIT_0D
3583 - 3328
1791 - 1664
895 - 832
447 - 416
223 - 208
INIT_0E
3839 - 3584
1919 - 1792
959 - 896
479 - 448
239 - 224
INIT_0F
4095 - 3840
2047 - 1920
1023 - 960
511 - 480
255 - 240

INIT_0x usage rules

A summary of the rules for the INIT_0x attribute follows.

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.

Block RAM
(depth x width)
Address
(INIT_0C)
Contents
4096 x 1
3072
3073
3074
3075
.
3327
1
1
1
0
.
0

2048 x 2
1536
1537
1538
1539
.
1663
11
01
10
11
.
00



1024 x 4
768
769
770
771
.
831
0111
1110
1101
1100
.
0000



512 x 8
384
385
386
387
.
415
11100111
11001101
00001011
00000000
.
00000000


256 x 16
192
193
194
195
.
207
1100110111101111
0000000000001011
0000000000000000
0000000000000000
.
0000000000000000



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.

P12
IOB location (chip carrier)
A12
IOB location (pin grid)
B, L, T, R
Indicates edge locations (bottom, left, top, right) - applies to edge decoders only
LB, RB, LT, RT, BR, TR, BL, TL
Indicates half edges (left bottom, right bottom, and so forth) - applies to edge decoders only
TL, TR, BL, BR
Indicates a corner for global buffer placement
AA
CLB location for XC3000
CLB_R4C3
CLB location for XC4000, XC5200, or Spartans
CLB_R4C3 (or .S0 or .S1)
CLB location for Virtex
CLB_R6C8.F (or .G)
Function generator, RAM, ROM, or RAMS location for XC4000 or Spartans
CLB_R6C8.LC0 (or .LC1, .LC2, .LC3)
Function generator or register location for XC5200
CLB_R6C8.S0 (or .S1)
Function generator or register slice for Virtex
CLB_R6C8.LC0 (or .LC2)
F5_MUX location for XC5200
CLB_R6C8.FFX (or.FFY)
Flip-flop location for XC4000 or Spartans
TBUF_R6C7.1 (or.2)
TBUF location for XC4000 or Spartans
TBUF_R6C7.0 (or .1, .2, or .3)
TBUF location for XC5200
TBUF_R6C7 (or .0 or .1)
TBUF location for Virtex
RAMB4_R3C1
Block RAM location for Virtex
GCLKBUG0 (or 1, 2, or 3)
Global clock buffer location for Virtex
GCLKPAD0 (or 1, 2, or 3)
Global clock pad location for Virtex
DLL0 (or 1, 2, or 3)
Delay Locked Loop element location for Virtex

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

C*
Any CLB in row C of an XC3000 device
*D
Any CLB in column D of an XC3000 device
CLB_R*C5
Any CLB in column 5 of an XC4000, XC5200, or Spartan series device
CLB_R*C5
Any CLB in either slice in column 5 of a Virtex device


NOTE

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


The following are not supported.

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

Attribute
Description
LOC=P12
Place I/O at location P12.
LOC=B
Place decode logic on the bottom edge.
LOC=TL
Place decode logic on the top left edge, or global buffer in the top left corner.
LOC=AA
(XC3000)
Place logic in CLB AA.
LOC=TBUF.AC.2
(XC3000)
Place BUFT in TBUF above and one column to the right of CLB AC.
LOC=CLB_R3C5
(XC4000 or Spartans)
Place logic in the CLB in row 3, column 5.
LOC=CLB_R3C5
(Virtex)
Place logic in either slice of the CLB in row3, column 5.
LOC=CLB_R4C4.LC0
(XC5200)
Place logic in the lowest slice of the CLB in row 4, column 4.
LOC=CLB_R3C5.S0
(Virtex)
Place logic in the left slice of the CLB in row 1, column 1.
LOC=CLB_R4C5.ffx
(XC4000 or Spartans)
Place CLB flip-flop in the X flip-flop of the CLB in row 4, column 5.
LOC=CLB_R4C5.F
(XC4000 or Spartans)
Place CLB function generator in the F generator of row 4, column 5.
LOC=TBUF_R2C1.1
(XC4000 or Spartans)
Place BUFT in row 2, column 1, along the top.
LOC=TBUF_R4C4.3
(XC5200)
Place BUFT in the top buffer in row 4, column 4.
LOC=TBUF_R*C0
(XC4000, XC5200, Spartans)
Place BUFT in any row in column 0.
LOC=TBUF_R1C2.*
(Virtex)
Place both TBUFs in row 1, column 2.
RAMB4_R*C1
(Virtex)
Specifies any block RAM in column 1 of the block RAM array

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

Attribute
Description
LOC=T,B
(XC4000 or Spartans)
Place decoder (XC4000) on the top or bottom edge.
LOC=clb_r2c4, clb_r7c9
(XC4000 or Spartans)
Place the flip-flop in either CLB R2C4 or CLB R7C9.
LOC=clb_r4c5.s1, clb_r4c6.*
(Virtex)
Place the flip-flop in the right-most slice of CLB R4C5 or in either slice of CLB R4C6

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

Attribute
Description
LOC=AA:FF
(XC3000)
Place CLB logic anywhere in the top left corner of the LCA bounded by row F and column F.
LOC=CLB_R1C1:CLB_R5C5
(XC4000, Spartans)
Place logic in the top left corner of the LCA in a 5 x 5 area bounded by row 5 and column 5.
LOC=CLB_R1C1:CLB_R5C5 PROHIBIT=CLB_R5C5
(must be specified in one continuous line)
(XC4000, Spartans)
Place CLB logic in the top left corner of the LCA in a 5 x 5 area, but not in the CLB in row 5, column 5.
LOC=CLB_R1C1.LC3:CLB_R4C4.LC0
(XC5200)
Place logic in any slice in the top left corner of the LCA bounded by row 4, column 4.
LOC=CLB_R1C1:CLB_R4C4
(Virtex)
Place logic in either slice in the top left corner of the LCA bounded by row 4, column 4.
LOC=TBUF_R1C1:TBUF_R2C8
(XC4000, XC5200, Spartans)
Place BUFT anywhere in the area bounded by row 1, column 1 and row 2, column 8.


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









Applicable Elements

Nets

Description

The MAXDELAY attribute defines the maximum allowable delay on a net.

Syntax

MAXDELAY=allowable_delay[units]

where units may be ps, ns, us, ms, GHz, MHz, or kHz. The default is ns.

Example

Schematic

Attached to a net.

UCF/NCF file

This statement assigns a maximum delay of 1 us to the net $SIG_4.

NET $1I3245/$SIG_4 MAXDELAY=1us;

MAXSKEW

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets

Description

Defines the allowable skew on a net.

Syntax

MAXSKEW=allowable_skew [units]

where units may be ps, ns, us, ms, GHz, MHz, or kHz. The default is ns.

Example

Schematic

Attached to a net.

UCF/NCF file

This statement specifies a maximum skew of 3 ns on net $SIG_6.

NET $1I3245/$SIG_6 MAXSKEW=3;

MEDDELAY

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Input register


NOTE

You can also attach the MEDDELAY constraint to a net that is connected to a 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 MEDDELAY

Description

Specifies a medium sized delay for the IOB register.

Syntax

MEDDELAY

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement specifies that the register in the IOB $COMP_6 will have a medium sized delay.

INST $1I87/$COMP_6 MEDDELAY;

This statement assigns a medium sized delay to the pad to which net1 is connected.

NET Net1 MEDDELAY ;

NODELAY

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Input register


NOTE

You can also attach the NODELAY constraint to a net connected to a 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 NODELAY

Description

The default configuration of IOB flip-flops in XC4000 and Spartan series designs includes an input delay that results in no external hold time on the input data path. However, this delay can be removed by placing the NODELAY attribute on input flip-flops or latches, resulting in a smaller setup time but a positive hold time.

The NODELAY attribute can be attached to the I/O symbols and the special function access symbols TDI, TMS, and TCK.

Syntax

NODELAY

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement specifies that IOB register inreg67 not have an input delay.

INST $1I87/inreg67 NODELAY;

This statement specifies that there be no input delay to the pad that is attached to net1.

NET net1 NODELAY ;

NOREDUCE

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Any net

Description

NOREDUCE prevents minimization of redundant logic terms that are typically included in a design to avoid logic hazards or race conditions. NOREDUCE also identifies the output node of a combinatorial feedback loop to ensure correct mapping. When constructing combinatorial feedback latches in a design, always apply NOREDUCE to the latch's output net and include redundant logic terms when necessary to avoid race conditions.

Syntax

NOREDUCE

Example

Schematic

Attached to a net.

UCF/NCF file

This statement specifies that there be no Boolean logic reduction or logic collapse from the net named $SIG_12 forward.

NET $SIG_12 NOREDUCE;

OFFSET

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Global, nets, time groups

Description

Specifies the timing relationship between an external clock and its associated data-in or data-out pin. Used only for pad-related signals and cannot be used to extend the arrival time specification method to the internal signals in a design.

OFFSET constraints allow you to do the following.

For CPLD designs, clock inputs referenced by OFFSET constraints must be explicitly assigned to a global clock pin (using either the BUFG symbol or applying the BUFG=CLK attribute to an ordinary input). Otherwise, the OFFSET constraint will not be used during timing-driven optimization of the design.

Syntax

Global method

The OFFSET constraint can be a "global" constraint that applies to all data pad nets in the design for the specified clock.

OFFSET={IN | OUT} offset_time [units] {BEFORE | AFTER} "clk_net" [TIMEGRP "reggroup"]

Net-Specific method

When the NET "name" specifier is used, the constraint is associated with a specific net.

NET "name" OFFSET={IN | OUT} offset_time [units] {BEFORE | AFTER} "clk_net" [TIMEGRP "reggroup"]

Group method

When the TIMEGRP "group" specifier is used, the constraint is associated with a group of data pad nets.

TIMEGRP "group" OFFSET={IN | OUT} offset_time [units] {BEFORE | AFTER} "clk_net" [TIMEGRP "reggroup"]

Alternate method

Because the global and group OFFSET constraints are not associated with a single data net or component, these two types can also be entered on a TIMESPEC symbol in the design netlist with TSidentifier.

TSidentifier=[TIMEGRP name] OFFSET = {IN|OUT} offset_time [units] {BEFORE|AFTER} "clk_net" [TIMEGRP "reggroup"]

where

group is the name of a time group containing IOB components or pad BELs.

offset_time is the external offset.

units is an optional field to indicate the units for the offset time. The default is nanoseconds, but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or kHz to indicate the intended units.

clk_net is the fully hierarchical netname of the clock net between the pad and its input buffer.

reggroup is a previously defined time group of register bels. Only registers in the time group clocked by the specified IOB component is checked against the specified offset time. The optional time group qualifier, TIMEGRP "reggroup," can be added to any OFFSET constraint to indicate that the offset applies only to registers specified in the qualifying group. When used with the "Group method," the "register time" group lists the synchronous elements that qualify which register elements clocked by "clk_net" get analyzed.


NOTE

CPLD designs do not support the "Group Method" or the TIMEGRP options in the other methods described above.


Example

Schematic

N/A

UCF/NCF file

This statement specifies that the data will be present on input43 at least 20 ns before the triggering edge of the clock signal CLOCK.

NET input43 OFFSET=IN 20 BEFORE CLOCK;

For a detailed description of OFFSET, please see the “OFFSET Timing Specifications” section in the Development System Reference Guide.

OPT_EFFORT

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Any macro or hierarchy level

Description

Defines an effort level to be used by the optimizer.

Syntax

OPT_EFFORT={NORMAL | HIGH}

Example

Schematic

Attached to a macro.

UCF/NCF file

This statement attaches a High effort of optimization to all of the logic contained within the module defined by instance $1I678/adder.

INST $1I678/adder OPT_EFFORT=HIGH;

OPTIMIZE

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Any macro or hierarchy level

Description

Defines whether optimization is performed on the flagged hierarchical tree. The OPTIMIZE attribute has no effect on any symbol that contains no combinational logic, such as an input/output buffer.

Syntax

OPTIMIZE={AREA | SPEED | BALANCE | OFF}

Example

Schematic

Attached to a macro.

UCF/NCF file

This statement specifies that no optimization be performed on an instantiation of the macro CTR_MACRO.

INST /$1I678/CTR_MACRO OPTIMIZE=OFF;

OUTREG

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 requirements. If a flip-flop or latch is driving an IOB, you can specify OUTREG 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 “INREG” section.

Syntax

OUTREG

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 that it is driving.

INST $I1 OUTREG;

PART

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

  1. Global

  2. Attached to CONFIG symbol in schematics

Description

Defines the part type used for the design.

Syntax

PART=part_type

where part_type can be device-speed-package or device-package-speed. For example, 4028EX-PG299-3 or 4028EX-3-PG299

The package string must always begin with an alphabetic character - never with a number.

The speed string must always begin with an numeric character - never with an alphabetic character.

The text XC is an optional prefix to the whole part_type string.

In a constraints file, the PART specification must be preceded by the keyword CONFIG.

Example

Schematic

Global or attached to the CONFIG symbol.

UCF/NCF file

This statement specifies a 4005E device, a PQ160C package, with a speed of 5.

CONFIG PART=4005E-PQ160C-5;

PERIOD

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets that feed forward to drive flip-flop clock pins

Description

Provides a convenient way of defining a clock period for registers attached to a particular clock net.

PERIOD controls pad-to-setup and clock-to-setup paths but not clock-to-pad paths. Refer to the “Using Timing Constraints” chapter in the Development System Reference Guide for more information on clock period specifications.

Syntax

Simple method

PERIOD=period[units] [{HIGH | LOW} [high_or_low_time[hi_lo_units]]]

where

period is the required clock period.

units is an optional field to indicate the units for a clock period. The default is nanoseconds (ns), but the timing number can be followed by ps, ns, or us to indicate the intended units.

HIGH or LOW can be optionally specified to indicate whether the first pulse is to be High or Low.

high_or_low_time is the optional High or Low time, depending on the preceding keyword. If an actual time is specified, it must be less than the period. If no High or Low time is specified, the default duty cycle is 50 percent.

hi_lo_units is an optional field to indicate the units for the duty cycle. The default is nanoseconds (ns), but the High or Low time number can be followed by ps, us, ms, or % if the High or Low time is an actual time measurement.

Alternate method

TSidentifier=PERIOD TNM_reference period [units] [{HIGH | LOW} [high_or_low_time [hi_lo_units]]]

where

identifier is a reference identifier that has a unique name.

TNM_reference is the identifier name that is attached to a clock net (or a net in the clock path) using the TNM attribute.

period is the required clock period.

units is an optional field to indicate the units for a clock period. The default is nanoseconds (ns), but the timing number can be followed by ps, ms, us, or % to indicate the intended units.

HIGH or LOW indicates whether the first pulse is to be High or Low.

high_or_low_time is the optional High or Low time, depending on the preceding keyword. If an actual time is specified, it must be less than the period. If no High or Low time is specified, the default duty cycle is 50 percent.

hi_lo_units is an optional field to indicate the units for the duty cycle. The default is nanoseconds (ns), but the High or Low time number can be followed by ps, us, ms, or % if the High or Low time is an actual time measurement.

Example

The following examples are for the “simple method.”

Schematic

Attached to a net.

PERIOD=40 HIGH 25;

UCF/NCF file

This statement assigns a clock period of 40 ns to the net named $SIG_24, with the first pulse being High and having a duration of 25 nanoseconds.

NET $SIG_24 PERIOD=40 HIGH 25;

PROHIBIT

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Attached to CONFIG symbol

Description

Disallows the use of a site within PAR, EPIC, and the CPLD fitter.

Location Types

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

P12
IOB location (chip carrier)
A12
IOB location (pin grid)
B, L, R, T
Indicates edge locations (bottom, left, top, right) - applies to edge decoders only
LB, RB, LT, RT, BR, TR, BL, TL
Indicates half edges (left bottom, right bottom, and so forth) - applies to edge decoders only
TL, TR, BL, BR
Indicates a corner for global buffer placement
AA
CLB location for XC3000
CLB_R4C3
CLB location for XC4000 or XC5200
CLB_R4C3 (or .S0 or .S1)
CLB location for Virtex
CLB_R6C8.LC0 (or 1, 2, 3)
Function generator or register location for XC5200
CLB_R6C8.S0 (or .S1)
Function generator or register location for Virtex
CLB_R6C8.LC0 (or 2)
F5_MUX location for XC5200
TBUF_R6C7.1 (or.2)
TBUF location for XC4000
TBUF_R6C7.0 (or.1,.2, or.3)
TBUF location for XC5200
TBUF_R6C7 (or .0 or .1)
TBUF location for Virtex
RAMB4_R3C1
Block RAM location for Virtex
GCLKBUG0 (or 1, 2, or 3)
Global clock buffer location for Virtex
GCLKPAD0 (or 1, 2, or 3)
Global clock pad location for Virtex
DLL0 (or 1, 2, or 3)
Delay Locked Loop element location for Virtex

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

C*
Any CLB in row C of an XC3000 device
*D
Any CLB in column D of an XC3000 device
CLB_R*C5
Any CLB in column 5 of an XC4000 or XC5200 device
CLB_R*C5
Any CLB in either slice in column 5 of a Virtex device


NOTE

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


The following are not supported.

Syntax

Single location

PROHIBIT=location

Multiple single locations

PROHIBIT=location1, location2, ... , locationn ;

Range of locations

PROHIBIT=location:location

In a constraints file, the PROHIBIT specification must be preceded by the keyword CONFIG.


NOTE

CPLDs do not support the "Range of locations" form of PROHIBIT.


Example

Schematic

Unattached attribute or attached to a CONFIG symbol.

UCF/NCF file

This statement prohibits use of the site P45.

CONFIG PROHIBIT=P45;

This statement prohibits use of the CLB located in Row 6, Column 8.

CONFIG PROHIBIT=CLB_R6C8 ;

This statement prohibits use of the site TBUF_R5C2.2.

CONFIG PROHIBIT=TBUF_R5C2.2 ;

PWR_MODE

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

  1. Nets

  2. Any instance

Description

Defines the mode, Low power or High performance (standard power) of the macrocell that implements the tagged element.


NOTE

If the tagged function is collapsed forward into its fanouts, the attribute is not applied.


Syntax

PWR_MODE={LOW | STD}

Example

Schematic

Attached to a net or an instance.

UCF/NCF file

This statement specifies that the macrocell that implements the net $SIG_0 will be in Low power mode.

NET $1187/$SIG_0 PWR_MODE=LOW;

RLOC

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex


1, 2, 3, 5, 7, 8, 9, 10, 11

1, 2, 3, 5, 7, 8, 9, 10, 11

1, 2, 4, 6, 10


1, 2, 3, 5, 7, 8, 9, 10

1, 2, 3, 5, 7, 8, 9, 10

1, 2, 8, 9, 10, 12

Applicable Elements

  1. Registers

  2. FMAP

  3. HMAP

  4. F5MAP

  5. CY4

  6. CY_MUX

  7. ROM

  8. RAM

  9. RAMS, RAMD

  10. BUFT. (Can only be used if the associated RPM has an RLOC_ORIGIN that causes the RLOC values in the RPM to be changed to LOC values.)

  11. WAND primitives that do not have a DECODE attribute attached

  12. LUTs, F5MUX, F6MUX, MUXCY, XORCY, MULT_AND, SRL16, SRL16E

Description

Relative location (RLOC) constraints group logic elements into discrete sets and allow you to define the location of any element within the set relative to other elements in the set, regardless of eventual placement in the overall design. See the “Physical Constraints” section for detailed information about this type of constraint.

For XC5200, the RLOC attribute must include the extension that defines in which of the four slices of a CLB the element will be placed (.LC0, .LC1, .LC2, .LC3). This defines the relationship of the elements in the set and also specifies in which of the four slices the element will eventually be placed.

For Virtex, the RLOC attribute must include the extension that defines in which of the two slices of a CLB the element will be placed (.S0, .S1).

Syntax

XC4000 or Spartans

RLOC=RmCn[.extension]

XC5200 or Virtex

RLOC=RmCn.extension

where

m and n are integers (positive, negative, or zero) representing relative row numbers and column numbers, respectively.

extension uses the LOC extension syntax as appropriate; it can take all the values that are available with the current absolute LOC syntax.

For the XC4000 and Spartans, the available extensions are FFX, FFY, F, G, H, 1, and 2. The 1 and 2 values are available for BUFT primitives, and the rest are available for primitives associated with CLBs. See the “LOC” section for more details.

For the XC5200, extension is required to define in which of the four slices of a CLB the element will be placed (.LC0, .LC1, .LC2, .LC3).

For Virtex, extension is required to define the spatial relationships (.S0 is the left-most slice; .S1 is the right-most slice) of the objects in the RPM.

The RLOC value cannot specify a range or a list of several locations; it must specify a single location. See the “Guidelines for Specifying Relative Locations” section for more information.

Example

Schematic

Attached to an instance.

UCF/NCF file

This statement specifies that an instantiation of FF1 be placed in the CLB at row 4, column 4.

INST /4K/design/FF1 RLOC=R4C4;

This statement specifies that an instantiation of elemA be placed in the X flip-flop in the CLB at row 0, column 1.

INST /$1I87/elemA RLOC=r0cl.FFX;

RLOC_ORIGIN

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Instances or macros that are members of sets

Description

An RLOC_ORIGIN constraint fixes the members of a set at exact die locations. This constraint must specify a single location, not a range or a list of several locations. For more information about this constraint, refer to the “Fixing Members of a Set at Exact Die Locations” section.

The RLOC_ORIGIN constraint is required for a set that includes BUFT symbols. The RLOC_ORIGIN constraint cannot be attached to a BUFT instance.

Syntax

RLOC_ORIGIN=RmCn

where m and n are positive integers (including zero) representing relative row and column numbers, respectively.

Example

Schematic

Attached to an instance that is a member of a set.

UCF/NCF file

This statement specifies that an instantiation of FF1, which is a member of a set, be placed in the CLB at R4C4 relative to FF1. For example, if RLOC=R0C2 for FF1, then the instantiation of FF1 is placed in the CLB that occupies row 4 (R0 + R4) , column 6 (C2 + C4).

INST /archive/designs/FF1 RLOC_ORIGIN=R4C4;

RLOC_RANGE

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Instances or macros that are members of sets

Description

The RLOC_RANGE constraint is similar to the RLOC_ORIGIN constraint except that it limits the members of a set to a certain range on the die. The range or list of locations is meant to apply to all applicable elements with RLOCs, not just to the origin of the set.

Syntax

RLOC_RANGE=Rm1Cn1:Rm2Cn2

where the relative row numbers (m1 and m2) and column numbers (n1 and n2) can be positive integers (including zero) or the wildcard (*) character. This syntax allows three kinds of range specifications, which are defined in the “Fixing Members of a Set at Exact Die Locations” section.

Example

Schematic

Attached to an instance that is a member of a set.

UCF/NCF file

This statement specifies that an instantiation of the macro MACRO4 be placed within a region that is enclosed by the rows R4-R10 and the columns C4-C10.

INST /archive/designs/MACRO4 RLOC_RANGE=R4C4:R10C10;

S(ave) - Net Flag Attribute

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets

Description

Attaching the net flag attribute to nets affects the mapping, placement, and routing of the design.

Syntax

S

The S (save) net flag attribute prevents the removal of unconnected signals. If you do not have the S attribute on a net, any signal not connected to logic and/or an I/O primitive is removed.

Example

Schematic

Attached to a net.

UCF/NCF file

This statement specifies that the net named $SIG_9 will not be removed.

NET $SIG_9 S;

SLOW

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Output primitives, output pads, bidirectional pads


NOTE

You can also attach the SLOW 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 SLOW

Description

Stipulates that the slew rate limited control should be enabled. This is the default.

Syntax

SLOW

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement establishes a slow slew rate for an instantiation of the element  y2.

INST $1I87/y2 SLOW;

This statement establishes a slow slew rate for the pad to which net1 is connected.

NET net1 SLOW;

STARTUP_WAIT

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Any CLKDLL, CLKDLLHF, or BUGDGLL instance

Description

Controls whether the DONE signal (device configuration) can go HIGH (indicating that the device is fully configured).

Syntax

START_WAIT={TRUE | FALSE}

where

TRUE specifies that the DONE signal cannot go High until the instance assigned this property locks.

FALSE, the default, specifies that the locking of the instance has no impact on the DONE signal.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement specifies that the DONE signal cannot go High until the foo/bar instance locks.

INST foo/bar STARTUP_WAIT=TRUE;

TEMPERATURE

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex
*
*
*
*

*
*
*
*Availability depends on the release of characterization data

Applicable Elements

Global

Description

Allows the specification of the operating junction temperature. This provides a means of prorating device delay characteristics based on the specified temperature. Prorating is a scaling operation on existing speed file delays and is applied globally to all delays.


NOTE

Each architecture has its own specific range of valid operating temperatures. If the entered temperature does not fall within the supported range, the constraint is ignored and an architecture-specific default value is used instead. Also note that the error message for this condition does not appear until PCF processing.


Syntax

TEMPERATURE=value[C |F| K]

where

value is real number specifying the temperature.

C, K, and F are the temperature units. F is degrees Fahrenheit, K is degrees Kelvin, and C is degrees Celsius, the default.

Example

Schematic

Unattached attribute.

UCF/NCF file

This statement specifies that the analysis for everything relating to speed file delays assumes a junction temperature of 25 degrees Celsius.

TEMPERATURE=25C;

TIG

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets, pins

Description

Paths that fan forward from the point of application are treated as if they do not exist (for the purposes of the timing model) during implementation.

A TIG may be applied relative to a specific timing specification.

Syntax

TIG

or

TIG=TSidentifier1,..., TSidentifiern

where identifier refers to a timing specification that should be ignored.

Example

Schematic

Attached to a net or pin.

UCF/NCF file

This statement specifies that the timing specifications TS_fast and TS_even_faster will be ignored on all paths fanning forward from the net $Sig_5.

NET $1I567/$Sig_5 TIG=TS_fast, TS_even_faster;

For more on TIG, see the “Ignoring Selected Paths (TIG)” section in the Development System Reference Guide.

Time Group Attributes

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

  1. Global in constraints file (preceded by the keyword TIMEGRP)

  2. Time group primitive

Description

Time group properties (attributes) are a set of grouping mechanisms that use existing TNMs (Timing Names) to create new groups or to define new groups based on the output net that the group sources. The timing group primitive (TIMEGRP) exists for the purpose of hosting these properties. In a constraints file, the specification of these properties must be preceded with the keyword TIMEGRP.


NOTE

When entering time group properties into a TIMEGRP symbol, some property names may conflict with the predefined property names of the TIMEGRP primitive.


The standard procedure for adding a property to a symbol is to use the following format.

PROPERTY=property_name VALUE=value

However, some property names are reserved, and should not be used because they cause a conflict. Hence, for property_name you must not use any of the system reserved names LIBVER, INST, COMP, MODEL, or any other names reserved by your schematic capture program. Please consult your schematic capture documentation to become familiar with reserved property names.


NOTE

For more on the TIMEGRP symbol, see the “TIMEGRP” section in the Design Elements chapter.


Syntax

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]

where

group_names can be

predefined_group name qualifier1... name_qualifiern

RISING or FALLING applies to the rising or falling edge sensitive elements of a group of flip-flops to be referred to as a subset.

TRANSHI or TRANSLO is the form of the constraint applied to latches.

EXCEPT excludes the object group.

Example 1

Schematic

The following attribute would be attached to a TIMEGRP primitive to combine the elements in two groups to form a new group.

big_group=little_group other_group

UCF/NCF file

The same constraint could appear in a User Constraints File (UCF) as follows.

TIMEGRP big_group=little_group other_group;

Example 2

Schematic

The following constraints would be attached to a TIMEGRP primitive to define new groups by exclusion.

input_pads=pads except output_pads

UCF/NCF file

The same constraint could appear in a UCF as follows.

TIMEGRP input_pads=pads EXCEPT output_pads;

For more on Time Group Attributes, see the “Entering Timing Specifications” section in the Development System Reference Guide. See also the “Syntax Summary” section in the same chapter.

TNM

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets, instances, macros


NOTE

You can attach the TNM 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 TNM=property_value

Description

Tags specific flip-flops, RAMs, pads, and latches as members of a group to simplify the application of timing specifications to the group.

TNMs (Timing Names) applied to pad nets do not propagate forward through the IBUF/ OBUF. The TNM is applied to the external pad. This case includes the net attached to the D input of an IFD. See the “TNM_NET” section if you want the TNM to trace forward from an input pad net.

TNMs applied to the input pin of an IBUF/ OBUF will propagate the TNM to the next appropriate element.

TNMs applied to the output pin of an IBUF/OBUF will propagate the TNM to the next appropriate element.

TNMs applied to an IBUF or OBUF element stay attached to that element.

TNMs applied to a clock-pad-net will not propagate forward through the clock buffer.

When TNM is applied to a macro, all the elements in the macro will have that timing name.

See the “Entering Timing Specifications” section in the Development System Reference Guide for detailed information about this attribute.

Syntax

TNM=[predefined_group:] identifier;

where

predefined_group can be

predefined_group name_qualifier1... name_qualifiern

identifier can be any combination of letters, numbers, or underscores. Do not use reserved words, such as FFS, LATCHES, RAMS, or PADS for TNM identifiers.

Example

Schematic

Attached to a net or a macro.

UCF/NCF file

This statement identifies the element register_ce as a member of the timing group the_register.

NET $1I87/register_ce TNM=the_register;

TNM_NET

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets

Description

Tags specific flip-flops, RAMs, pads, and latches as members of a group to simplify the application of timing specifications to the group. NGDBuild never transfers a TNM_NET constraint from the attached net to a pad, as it does with the TNM constraint.

TNM_NETs applied to pad nets propagate forward through the IBUF/ OBUF.

TNM_NETs applied to a clock-pad-net propagate forward through the clock buffer.

When TNM_NET is applied to a macro, all the elements in the macro will have that timing name.

See the “Entering Timing Specifications” section in the Development System Reference Guide for detailed information about this attribute.

Syntax

TNM_NET=[predefined_group:]identifier

where

predefined_group can be

predefined_group name_qualifier1... name_qualifiern

identifier can be any combination of letters, numbers, or underscores. Do not use reserved words, such as FFS, LATCHES, RAMS, or PADS for TNM identifiers.

Example

Schematic

Attached to a net.

UCF/NCF file

This statement identifies all flip-flops fanning out from the PADCLK net as a member of the timing group FFGRP.

NET PADCLK TNM_NET=FFS(*):FFGRP;

TPSYNC

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets, instances, pins

Description

Flags a particular point or a set of points with an identifier for reference in subsequent timing specifications. You can use the same identifier on several points, in which case timing analysis treats the points as a group. See the “Time Group Attributes” section.

Defining synchronous points

When the timing of a design must be designed from or to a point that is not a flip-flop, latch, RAM, or I/O pad, the following rules apply if a TPSYNC timing point is attached to a net, macro pin, output or input pin of a primitive, or an instance.

Syntax

TPSYNC=identifier

where identifier is a name that is used in timing specifications in the same way that groups are used.

All flagged points are used as a source or destination or both for the specification where the TPSYNC identifier is used.


NOTE

The name for the identifier must be different from any identifier used for a TNM attribute.


Example

Schematic

Attached to a net, instance, or pin.

UCF/NCF file

This statement identifies latch as a potential source or destination for timing specifications for the net logic_latch.

NET $1I87/logic_latch TPSYNC=latch;

TPTHRU

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Nets, pins, instances

Description

Flags a particular point or a set of points with an identifier for reference in subsequent timing specifications. You can use the same identifier on several points, in which case timing analysis treats the points as a group. See the “Time Group Attributes” section.

Defining through points

The TPTHRU attribute is used when it is necessary to define intermediate points on a path to which a specification applies. See the “TSidentifier” section.

Syntax

TPTHRU=identifier

where identifier is a name used in timing specifications for further qualifying timing paths within a design.


NOTE

The name for the identifier must be different from any identifier used for a TNM attribute.


Example

Schematic

Attached to a net, instance, or pin.

UCF/NCF file

This statement identifies the net on_the_way as an intermediate point on a path to which the timing specification named “here” applies.

NET $1I87/on_the_way TPTHRU=here;

TSidentifier

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

  1. Global in constraints file

  2. TIMESPEC primitive

Description

TSidentifier properties beginning with the letters “TS” are placed on the TIMESPEC symbol. In a constraints file, the specification of these properties can be preceded with the optional keyword TIMESPEC. The value of the TSidentifier attribute corresponds to a specific timing specification that can then be applied to paths in the design.

Syntax


NOTE

All the following syntax definitions use a space as a separator. The use of a colon (:) as a separator is optional.


Defining a maximum allowable delay

TSidentifier=[MAXDELAY] FROM source_group TO dest_group allowable_delay [units]

or

TSidentifier=FROM source_group TO dest_group allowable_delay [units]

Defining intermediate points

NOTE

This form is not supported for CPLDs.


TSidentifier=FROM source_group THRU thru_point [THRU thru_point1... thru_pointn] TO dest_group allowable_delay [units]

where

identifier is an ASCII string made up of the characters A-Z, a-z, 0-9, and _.

source_group and dest_group are user-defined or predefined groups.

thru_point is an intermediate point used to qualify the path, defined using a TPTHRU attribute.

allowable_delay is the timing requirement.

units is an optional field to indicate the units for the allowable delay. The default units are nanoseconds (ns), but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or kHz to indicate the intended units.

Defining a linked specification

This allows you to link the timing number used in one specification to another specification.

TSidentifier=FROM source_group TO dest_group another_TSid[/ | *] number

where

identifier is an ASCII string made up of the characters A-Z, a-z, 0-9, and _.

source_group and dest_group are user-defined or predefined groups.

another_Tsid is the name of another timespec.

number is a floating point number.

Defining a clock period

This allows more complex derivative relationships to be defined as well as a simple clock period.

TSidentifier=PERIOD TNM_reference period[units] [{HIGH | LOW} [high_or_low_time [hi_lo_units]]]

where

identifier is a reference identifier with a unique name.

TNM_reference is the identifier name attached to a clock net (or a net in the clock path) using a TNM attribute.

period is the required clock period.

units is an optional field to indicate the units for the allowable delay. The default units are nanoseconds (ns), but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or kHz to indicate the intended units.

HIGH or LOW can be optionally specified to indicate whether the first pulse is to be High or Low.

high_or_low_time is the optional High or Low time, depending on the preceding keyword. If an actual time is specified, it must be less than the period. If no High or Low time is specified, the default duty cycle is 50 percent.

hi_lo_units is an optional field to indicate the units for the duty cycle. The default is nanoseconds (ns), but the High or Low time number can be followed by ps, us, ms, or % if the High or Low time is an actual time measurement.

Specifying derived clocks

TSidentifier=PERIOD TNM_reference another_PERIOD_identifier [/ | *] number [{HIGH | LOW} [high_or_low_time [hi_lo_units]]]

where

TNM_reference is the identifier name attached to a clock net (or a net in the clock path) using a TNM attribute.

another_PERIOD_identifier is the name of the identifier used on another period specification.

number is a floating point number.

HIGH or LOW can be optionally specified to indicate whether the first pulse is to be High or Low.

high_or_low_time is the optional High or Low time, depending on the preceding keyword. If an actual time is specified, it must be less than the period. If no High or Low time is specified, the default duty cycle is 50 percent.

hi_lo_units is an optional field to indicate the units for the duty cycle. The default is nanoseconds (ns), but the High or Low time number can be followed by ps, us, ms, or % if the High or Low time is an actual time measurement.

Ignoring paths

NOTE

This form is not supported for CPLDs.


There are situations in which a path that exercises a certain net should be ignored because all paths through the net, instance, or instance pin are not important from a timing specification point of view.

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

where

identifier is an ASCII string made up of the characters A-Z, a-z 0-9, and _.

source_group and dest_group are user-defined or predefined groups.

thru_point is an intermediate point used to qualify the path, defined using a TPTHRU attribute.

Example

Schematic

Attached to a TIMESPEC primitive.

UCF/NCF file

This statement says that the timing specification TS_35 calls for a maximum allowable delay of 50 ns between the groups “here” and “there”.

TIMESPEC TS_35=FROM here TO there 50;

This statement says that the timing specification TS_70 calls for a 25 ns clock period for clock_a, with the first pulse being High for a duration of 15 ns.

TIMESPEC TS_70=PERIOD “clock_a” 25 high 15;

For more information, see the “Timing Constraints” section.


NOTE

In either example above, a colon can be used instead of a space as the separator. (Additional spaces entered before or after the colon are ignored.) The statements then become as follows.


TIMESPEC TS_35=FROM:here:TO:there:50;

TIMESPEC TS_70=PERIOD:”clock_a”:25:high:15;

U_SET

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex


1, 2, 3, 5, 7, 8, 9, 10, 11, 12

1, 2, 3, 5, 7, 8, 9, 10, 11, 12

1, 2, 4, 6, 7, 8, 12


1, 2, 3, 5, 7, 8, 9, 10, 11, 12

1, 2, 3, 5, 7, 8, 9, 10, 11, 12

1, 2, 7, 8, 10, 11, 12, 13

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 (Can only be used for Virtex if the associated RPM has an RLOC_ORIGIN that causes the RLOC values in the RPM to be changed to LOC values.)

  13. LUTs, F5MUX, F6MUX, MUXCY, XORCY, MULT_AND, SRL16, SRL16E

Description

The U_SET constraint groups design elements with attached RLOC constraints that are distributed throughout the design hierarchy into a single set. The elements that are members of a U_SET can cross the design hierarchy; that is, you can arbitrarily select objects without regard to the design hierarchy and tag them as members of a U_SET. For detailed information about this attribute, refer to the “RLOC Sets” section.

Syntax

U_SET=name

where name is the identifier of the set. This name is absolute. It is not prefixed by a hierarchical qualifier.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

This statement specifies that the design element ELEM_1 be in a set called JET_SET.

INST $1I3245/ELEM_1 U_SET=JET_SET;

USE_RLOC

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex









Applicable Elements

Instances or macros that are members of sets

Description

Turns on or off the RLOC constraint for a specific element or section of a set. For detailed information about this constraint, refer to the “Toggling the Status of RLOC Constraints” section.

Syntax

USE_RLOC={TRUE | FALSE}

where TRUE turns on the RLOC attribute for a specific element, and FALSE turns it off. Default is TRUE.

Example

Schematic

Attached to a member of a set.

UCF/NCF file

INST $1I87/big_macro USE_RLOC=FALSE;

VOLTAGE

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex
*
*
*
*

*
*
*
*Availability depends on the release of characterization data

Applicable Elements

Global

Description

Allows the specification of the operating voltage. This provides a means of prorating delay characteristics based on the specified voltage. Prorating is a scaling operation on existing speed file delays and is applied globally to all delays.


NOTE

Each architecture has its own specific range of supported voltages. If the entered voltage does not fall within the supported range, the constraint is ignored and an architecture-specific default value is used instead. Also note that the error message for this condition appears during PCF processing.


Syntax

VOLTAGE=value[V]

where

value is a real number specifying the voltage.

V indicates volts, the default voltage unit.

Example

Schematic

Unattached attribute.

UCF/NCF file

This statement specifies that the analysis for everything relating to speed file delays assumes an operating power of 5 volts.

VOLTAGE=5;

WIREAND

XC3000
XC4000E
XC4000X
XC5200
XC9000
Spartan
SpartanXL
Virtex




*



* not supported for XC9500XL designs

Applicable Elements

Any net

Description

Forces a tagged node to be implemented as a wired AND function in the interconnect (UIM and Fastconnect).

Syntax

WIREAND

Example

Schematic

Attached to a net.

UCF/NCF file

This statement specifies that the net named SIG_11 be implemented as a wired AND when optimized.

NET $I16789/SIG_11 WIREAND;

XBLKNM

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

  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

Description

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

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

XBLKNM attributes, like LOC constraints, are specified from the schematic. Hierarchical paths are not prefixed to XBLKNM attributes, so XBLKNM attributes for different CLBs must be unique throughout the entire design.

The BLKNM attribute allows any elements except those with a different BLKNM to be mapped into the same physical component. XBLKNM, however, allows only elements with the same XBLKNM to be mapped into the same physical component. Elements without an XBLKNM cannot be not mapped into the same physical component as those with an XBLKNM.

For XC5200, a given XBLKNM 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 XBLKNM attribute.

Syntax

XBLKNM=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.

Example

Schematic

Attached to a valid instance.

UCF/NCF file

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

INST $1I87/flip_flop2 XBLKNM=U1358;

Next