Logical constraints are found in a Netlist Constraint File (NCF), an ASCII file generated by synthesis programs, and in a User Constraint File (UCF), an ASCII file generated by the user. This section describes the rules for entering constraints in a UCF or NCF file.
It is preferable to place any user-generated constraint in the UCF file - not in an NCF or PCF file.
The UCF and NCF files are case sensitive. Identifier names (names of objects in the design, such as net names) must exactly match the case of the name as it exists in the source design netlist. However, any Xilinx constraint keyword (for example, LOC, PERIOD, HIGH, LOW) may be entered in either all upper-case or all lower-case letters; mixed case is not allowed.
Each statement is terminated by a semicolon (;).
No continuation characters are necessary if a statement exceeds one line, since a semicolon marks the end of the statement.
You can add comments to the UCF/NCF file by beginning each comment line with a pound (#) sign. Following is an example of part of a UCF/NCF file containing comments.
# file TEST.UCF
# net constraints for TEST design
NET $SIG_0 MAXDELAY 10 ;
NET $SIG_1 MAXDELAY 12 ns ;
Statements do not have to be placed in any particular order in the UCF/NCF file.
The constraints in the UCF/NCF files and the constraints in the schematic or synthesis file are applied equally; it does not matter whether a constraint is entered in the schematic or synthesis file or in the UCF/NCF files. If the constraints overlap, however, UCF/NCF constraints override the schematic constraint. Refer to the “Constraints Priority” section of the Development System Reference Guide for additional details on constraint priorities.
If by mistake two or more elements are locked onto a single location, the mapper detects the conflict, issues a detailed error message, and stops processing so that you can correct the mistake.
The syntax for constraints in the UCF/NCF files is as follows.
{NET | INST | PIN} full_name constraint ;
or
SET set_name set_constraint ;
where
full_name is a full hierarchically qualified name of the object being referred to. When the name refers to a pin, the instance name of the element is also required.
constraint is a constraint in the same form as it would be used if it were attached as an attribute on a schematic object. For example, LOC=P38 or FAST, and so forth.
set_name is the name of an RLOC set. Refer to the “RLOC Sets” section for more information.
set_constraint is an RLOC_ORIGIN or RLOC_RANGE constraint.
To specify attributes for the CONFIG or TIMEGRP primitives (tables), the keywords CONFIG or TIMEGRP precede the attribute definitions in the constraints files.
CONFIG PROHIBIT=CLB_R6C8 ;
TIMEGRP input_pads=pads EXCEPT output_pads ;
For the TIMESPEC primitive (table), the use of the keyword TIMESPEC in the constraints files is optional.
In all of the constraints files (NCF, UCF, and PCF), instance or variable names that match internal reserved words will be rejected unless the names are enclosed in double quotes. It is good practice to enclose all names in double quotes.
For example, the following entry would not be accepted because the word net is a reserved word.
NET net OFFSET=IN 20 BEFORE CLOCK;
Following is the recommended way to enter the constraint.
NET “net” OFFSET=IN 20 BEFORE CLOCK;
or
NET “$SIG_0” OFFSET=IN 20 BEFORE CLOCK;
Inverted signal names, for example ~OUTSIG1, must always be enclosed in double quotes as shown in the following example.
NET “~OUTSIG1” OFFSET=IN 20 BEFORE CLOCK;
You can use the wildcard characters, * and ?, in constraint statements as follows. The asterisk (*) represents any string of zero or more characters. The question mark (?) indicates a single character.
In net names, the wildcard characters enable you to select a group of symbols whose output net names match a specific string or pattern. For example, the following constraint increases the output speed of the pads to which nets with names that begin with any series of characters followed by "AT" and end with one single characters are connected.
NET *AT? FAST ;
In an instance name, a wildcard character by itself represents every symbol of the appropriate type. For example, the following constraint initializes an entire set of ROMs to a particular hexadecimal value, 5555.
INST $1I3*/ROM2 INIT=5555 ;
If the wildcard character is used as part of a longer instance name, the wildcard represents one or more characters at that position.
In a location, you can use a wildcard character for either the row number or the column number. For example, the following constraint specifies placement of any instance under the hierarchy of loads_of_logic in any CLB in column 8.
INST /loads_of_logic/* LOC=CLB_r*c8 ;
Wildcard characters can be used in dot extensions.
CLB_R1C3.*
Wildcard characters cannot be used for both the row number and the column number in a single constraint, since such a constraint is meaningless.
Top-level block names (design names) are ignored when searching for instance name matches.
You can use the asterisk wildcard character (*) to traverse the hierarchy of a design within a UCF or NCF file. The following syntax applies (where level1 is an example hierarchy level name).
| * | Traverses all levels of the hierarchy | |
| level1/* | Traverses all blocks in level1 and below | |
| level1/*/ | Traverses all blocks in the level1 hierarchy level but no further |
Consider the following design hierarchy.
With the example design hierarchy, the following specifications illustrate the scope of the wildcard.
INST * => <everything>
INST /* => <everything>
INST /*/ => <$A1,$B1,$C1>
INST $A1/* => <$A21,$A22,$A3,$A4>
INST $A1/*/ => <$A21,$A22>
INST $A1/*/* => <$A3,$A4>
INST $A1/*/*/ => <$A3>
INST $A1/*/*/* => <$A4>
INST $A1/*/*/*/ => <$A4>
INST /*/*22/ => <$A22,$B22,$C22>
INST /*/*22 => <$A22,$A3,$A4,$B22,$B3,$C22,$C3>
By default, NGDBuild reads the constraints file that carries the same name as the input design with a .ucf extension; however, you can specify a different constraints file name with the -uc option when running NGDBuild. NGDBuild automatically reads in the NCF file if it has the same base name as the input XNF or EDIF file and is in the same directory as the XNF or EDIF file.
The implementation tools (NGDBuild, MAP, PAR, etc.) require file name extensions in all lowercase (.ucf, for example) in command lines.
Because the statements in the constraints file concern instances and blocks, these entities are defined here.
An instance is a symbol on the schematic. An instance name is the symbol name as it appears in the EDIF or XNF netlist. A block is a CLB, an IOB, or a TBUF. You can specify the block name by using the BLKNM, HBLKNM, or the XBLKNM attribute; by default, the software assigns a block name on the basis of a signal name associated with the block.
