This appendix discusses some of the more common constraints you can apply to your design to control the timing and layout of a Xilinx FPGA or CPLD; it describes how to use constraints at each stage of design processing.
This appendix contains the following sections.
For a complete listing of all supported constraints, refer to the Libraries Guide (Chapter 12, “Attributes, Constraints, and Carry Logic,”). For a more complete discussion of how timing constraints work in Foundation, refer to the Development System Reference Guide (“Using Timing Constraints,”). For information on all attributes, including timing constraints, used in CPLD designs, refer to the Foundation online help.
With the Foundation version of the Xilinx design implementation tools, you control the implementation of a design by defining constraints that affect the mapping and layout of the physical circuit. Additionally, you can specify the “path” timing requirements of the circuit to obtain the best results and allow the implementation tools to choose the layout which best satisfies these requirements.
The various design constraints available within Foundation can be entered at the time you create the design (i.e., the logical domain) or after the design is mapped (that is, the physical domain).
Constraints entered in the logical domain are created in the following ways
Constraints entered in the physical domain are entered directly into the Physical Constraints File (PCF). These constraints are conceptually the same as those entered during design creation; however, they are directly related to objects within the physical design database and are therefore applied using the PCF syntax.
The following figure illustrates the constraints entry approach for the Foundation version of the Xilinx tools.
Figure B.1 Constraint Entry Flow |  |
The process of implementing a design within the Foundation tools starts with a logical design file (NGD) that represents the design created by the NGDBuild application (as shown in the “Constraint Entry Flow” figure).
The NGD file contains all of the design's logic structures (gates) and constraints. The NGD file is produced through the NGDBuild process which controls the translation and merging of all of the related logic design files.
All design files are translated from industry standard netlists into intermediate NGO files by one of two netlist translation programs XNF2NGD or EDIF2NGD. The exception to this rule is logic, which is created through the use of LogiBLOX components. LogiBLOX components may be compiled directly in memory, and are, therefore never written to disk as a separate intermediate NGO file.
The Xilinx Constraints Editor is a Graphical User Interface (GUI) that provides a convenient way for you to create certain new constraints. Constraints created with the Constraints Editor are written to the UCF (User Constraints File). See the “User Constraint File (UCF)” section.
For more information on the Constraints Editor, see the DynaText online document, Constraints Editor User Guide.
The following subsections describe the User Constraint File and the Physical Constraints File.
The User Constraint File was developed to provide a convenient mechanism for constraining a logical design without returning to the design entry tools. UCF constraints intentionally overwrite constraints that are present in the netlist.
UCF constraints override any constraints contained within the netlist created by the schematic or synthesis tools. A constraint that is being applied via the UCF file must specify the complete hierarchical path name for the instance or net being constrained.
In the Foundation, UCF constraints are considered more significant because they appear later in the design flow and provide a mechanism for establishing or modifying logical design constraints without requiring you to re-enter a schematic or synthesis tool.
The process of building the complete logical design representation (NGD files) is the job of NGDBuild. In developing this complete design database, NGDBuild annotates design constraints with those it finds in a UCF file. If a UCF file exists with the same name as the top-level netlist then it will automatically be read. Otherwise, you must indicate a specific file for User Constraints in the Options dialog box. The syntax for the UCF constraints file is explained (on a per-constraint basis) in the “Timing Constraints” section.
Versions prior to M1.2 required the -uc switch to identify a User Constraint File that needed to be annotated to the design. Versions M1.2 and later allow UCF file annotation to be performed by default - if the UCF file has the same base name as the input.
(FPGA only.)The layout tools work on the physical design, so the PCF file is written in terms that these tools can readily interpret. Layout and timing constraints are written in terms of the physical design's components (COMPs), fractions of COMPs (BELs), and collections of COMPs (macros).
Because of this different design viewpoint, the PCF syntax is not necessarily the same as that used in the logical design constraint files (UCF/NCF). Furthermore, because the PCF file is written for the physical design implementation tools, its syntax may not be as intuitive as the UCF file. Regardless of the syntactical challenges associated with using a PCF file, many designers will choose to work at the physical level of design abstraction for the following reasons.
If you modify the PCF file, you should be certain that you enter your constraints after the line “SCHEMATIC END ;”. Otherwise, your constraints will be overwritten every time MAP is re-executed.
Since EDIF is a case-sensitive format, the Foundation constraints are case sensitive as well. Always specify the net names and instance names exactly as they are in your schematic or code. Be consistent when using TNMs and other user-defined names in your constraints file; always use the same case throughout. For site names (such as “CLB_R2C8” or “P2”), you should use only upper case letters, since site names within Xilinx devices are all upper case.
The following subsections discuss timing constraints. Many timing constraints can be created using the Constraints Editor. If a constraint can be created with the Constraints Editor, it will be noted in the sections that follow.
When using the From:To style of constraint, the path(s) that are constrained are specified by declaring the start point and end point, which must be a pad, flip-flop, latch, RAM, or user-specified sync point (see TPSYNC). To group a set of endpoints together, you may attach a TNM attribute to the object (or to a net that is an input to the object). With a macro, the TNM traverses the hierarchy to tag all relevant objects. A TIMEGRP is a method for combining two or more sets of TNMs or other TIMEGRPs together, or alternatively, to create a new group by pattern matching (grouping a set of objects that all have output nets that begin with a given string)
You can create a From:To timespec with the Constraints Editor.
You use TNMs to identify a group of design objects which are to be referenced within a Timespec. If a TNM is placed on a net, the Foundation tools determine TNM membership by tracing forward from the specified net to all the valid endpoints of the net. Refer to the Development System Reference Guide (“Using Timing Constraints”) for more information on this subject. The following schematic shows an example of TNM, TIMESPEC, and TIMEGRP statements.
The following file corresponds to the preceding figure.
#This is a comment line
# UCF FROM:TO style Timespecs
NET DATA_EN TNM = PIPEA ;
TIMEGRP BUSPADS = PADS(BUS*) ;
TIMESPEC TS01 = FROM:BUSPADS:TO:PIPEA:20 ;
#Spaces or colons (:) may be used as field separators
TIMESPEC TS02 = FROM FFS TO RAMS 15 ; The first line of the above example illustrates the application of the TNM (Timing Name) PIPEA to the net named DATA_EN. The second line illustrates the TIMEGRP design object formed using a pattern matching mechanism in conjunction with the predefined TIMEGRP “PADS”. In this example, the TIMEGRP named BUSPADS will include only those PADs with names that start with BUS.
Each of the user-defined Timegroups is then used to define the object space constrained by the timing specification (Timespec) named TS01. This timing specification states that all paths from each member of the BUSPADS group to each member of the PIPEA group need to have a path delay that does not exceed 20 nanoseconds (ns are the default units for time). The TIMESPEC TS02 constraint illustrates a similar type of timing constraint using the predefined groups FFS and RAMS.
All From:To Timespecs must be relative to a Timegroup. The above example illustrates that you can define Timegroups either explicitly (TIMEGRPs) or implicitly (TNMs), or they may be predefined groups (PADS, LATCHES, FFS, RAMS).
There is an additional keyword that you can add to the From:To specification that allows the user to narrow the set of paths that are covered - THRU. By using the From:Thru:To form of a Timespec, you are able to constrain only those paths that go through a certain set of nets, defined by the TPTHRU keyword, as shown in the following example.
# UCF example of FROM:TO Timespec using THRU
NET $1I6/thisnet TPTHRU=these ;
NET $1I6/thatnet TPTHRU=these ;
TIMEGRP sflops=FFS(DATA*) ;
TIMEGRP dflops=FFS(OUTREG*) ;
TIMESPEC TS23=FROM:sflops:THRU:these:TO:dflops:20 ; Here, only those paths that go from the Q pin of the sflops through the nets $1I6/thisnet and $1I6/thatnet and on to the D pin of dflops will be controlled by TS23.
(FPGA only.) In the Foundation design implementation tools, you can define any node as a source or destination for a Timespec with the TPSYNC keyword. The use of TPSYNC is similar to TPTHRU - it is a label that is attached to a set of nets, pins, or instances in the design.
For example, suppose a design has a PAD ENABLE_BUS that must arrive at the enable pin of several different 3-state buffers in less than a specified time. With the Foundation tools, you can now define that 3-state buffer as an endpoint for a timing spec. The following figure illustrates TPSYNC.
The following UCF file corresponds to the above example.
# TPSYNC example; pad to a 3-state buffer enable pin
# Note TPSYNC attached to 3-state buffer's output NET
NET BUS3STATE TPSYNC=bus3;
TIMESPEC TSNewSpc3=FROM:PAD(ENABLE_BUS):TO:bus3:20ns; In the NET statement shown above, the TPSYNC is attached to the output net of a 3-state buffer called BUS3STATE. If a TPSYNC is attached to a net, then the source of the net is considered to be the endpoint (in this case, the 3-state buffer itself). The subsequent TIMESPEC statement can use the TPSYNC name just as it uses a TNM name.
The next TPSYNC UCF file example shows you how to use the keyword PIN instead of NET if you want to attach an attribute to a pin.
# Note TPSYNC attached to 3-state buffer's enable PIN
PIN $1I6/BUSMACRO1/TRIBUF34.T TPSYNC=bus1;
TIMESPEC TSNewSpc1=FROM:PAD(ENABLE_BUS):TO:bus1:20ns; In this example, the instance name of the 3-state buffer is stated followed by the pin name of the enable (.T). If a TPSYNC is attached to a primitive input pin, then the primitive's input is considered the startpoint or endpoint for a timing specification. If it is attached to a output pin, then the output of the primitive is used.
The last TPSYNC example shows you how to use the keyword INST if you want to attach an attribute to a instance:
# Note TPSYNC attached to 3-state buffer INSTANCE (UCF # file)
INST $1I6/BUSMACRO2/BUFFER_2 TPSYNC=bus2;
TIMESPEC TSNewSpc2=FROM:PAD(ENABLE_BUS):TO:bus2:20ns; If a TPSYNC is attached to an instance, then the output of the instance is considered the startpoint or endpoint for a timing specification.
The TIMESPEC form of the PERIOD constraint allows flexibility in group definitions and allows you to define clock timing relative to another TIMESPEC.
You can create a Period constraint with the Constraints Editor.
The following schematic example illustrates the use of the PERIOD Timespec referenced to timegroups CLK2_GRP and CLK3.
The following syntax is the corresponding UCF file.
# UCF PERIOD style Timespecs
NET CLK2 TNM = CLK2_GRP ;
NET CLK3 TNM = CLK3 ;
TIMESPEC TS03 = PERIOD CLK2_GRP 50 ;
TIMESPEC TS04 = PERIOD CLK3 TS03 * 2 ; Furthermore, the example shows how constraints and nets may be given the same name because they occupy separate name-spaces. Also, it shows the constraint syntax whereby one Timespec is defined relative to another (the value of TS04 is declared to be two times that of TS03).
The PERIOD constraint covers all timing paths which start or end at a register, latch, or synchronous RAM that is clocked by the referenced net. The only exception to this rule are paths to output pads, which are not covered by the PERIOD constraint. (Input pads, which are the source of a “pad-to-setup” timing path for one of the specified synchronous elements, are covered by the PERIOD constraint.)
The flexibility of the TIMESPEC form of the PERIOD constraint arises from being able to modify the contents of the TIMEGRP once the design has been mapped. By adding or removing objects from the TIMEGRP, which are listed in the PCF file, you can alter the paths that are covered by the PERIOD constraint.
If you do not need the flexibility offered by the TIMESPEC form, you can use the NET form of the PERIOD constraint may be used. The syntax for the NET form of the PERIOD constraint is simpler than the TIMESPEC form, while continuing to provide the same path coverage. The following example illustrates the syntax of the NET form of the PERIOD constraint.
# NET form of the PERIOD timing constraint
# (no TSidentifier)
NET CLK PERIOD = 40 ; This is the recommendation of using PERIOD on a single clock design in which data does not pass between the clock domains.
With the Foundation 1.5 release, PERIOD will now include clock skew in the path analysis.
Use offsets to define the timing relationship between an external clock and its associated data-in or data-out-pin. Using this option, you can do the following.
You can create a Pad to Setup or Clock to Pad offset constraint with the Constraints Editor.
There are basically three types of offset specifications.
Since 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 Tsid. See the “Using Timing Constraints” chapter in the Development System Reference Guide for details.
In the following example, the OFFSET constraint is applied to a net that connects with a PAD (as shown in the figure later in this section). It defines the delay of a signal relative to a clock and is only valid for registered data paths. The OFFSET constraint specifies the signal delay external to the chip, allowing the implementation tools to automatically adjust relevant internal delays (CLK buffer and distribution delays) to accommodate the external delay specified with the following.
# Net form of the OFFSET timing constraint
NET ADD0_IN OFFSET = IN 14 AFTER CLK ; In analyzing OFFSET paths, the Xilinx timing tools adjust the PERIOD associated with the constrained synchronous element based on both the timing specified in the OFFSET constraint and the delay of the referenced clock signal. In the following figure, assume a delay of 8 ns for the signal CLK to arrive at the CLB, a 5 ns setup time for ADD0, and a 14 ns OFFSET delay for the signal ADD0. Assume a period of 40 ns is specified. The Foundation tools allocate 29 ns for the signal ADD0 to arrive at the CLB input pin (40 ns - 14 ns + 8 ns - 5 ns = 29 ns).
This same timing constraint could be applied using the FROM:PADS:TO:FFS timing constraint. However, using a From:To methodology would require you to know the intrinsic CLK net delay, and you would have to adjust the value assigned to the From:To Timespec. The internal CLK net delay is implicit in the OFFSET/PERIOD constraint. Furthermore, migrating the design to another speed grade or device would require modification of the From:To Timespec to accommodate the new intrinsic CLK net delay. An alternative solution is to use the flip-flop in the IOB of certain FPGA architectures (XC4000E/EX, for instance), as the clock-to-setup time is specified in the Programmable Logic Data Book.
Relative Timespecs can only be applied to similar Timespecs. For example, a PERIOD Timespec may be defined in terms of another PERIOD Timespec, but not a FROM:TO Timespec.
(FPGA only.) When you declare a a Timespec that includes paths where the timing is not important, the tools may create a less optimal route since there is more competition for routing resources. This problem can be alleviated by using a TIG (timing ignore) attribute on the non-critical nets. TIG causes all paths that fan out from the net or pin where it is applied to be “ignored” during timing simulation.
You can create a Timing Ignore constraint with the Constraints Editor.
The following syntax indicates that $1I456/slow_net should not have the Timespec TS01 or TS04 applied to it.
#Timespec-specific TIG example (UCF file)
NET $1I456/slow_net TIG=TS01, TS04 ;
On the other hand, the following syntax indicates that the layout tools should ignore paths through the $1I456/slow_net net for all known Timespecs.
#Global TIG example (UCF file)
NET $1I456/slow_net TIG (FPGA only.) Skew is the difference between the minimum and maximum of the maximum load delays on a net. You can control the maximum allowable skew on a net by attaching the MAXSKEW attribute directly to the net.
#MAXSKEW example (UCF file)
NET $1I345/net_a MAXSKEW=3 ; The above example indicates that 3 ns is the maximum skew allowed on $1I345/net_a. For a detailed example of how MAXSKEW works, see the “Additional Timing Constraints” section in the Development System Reference Guide.
A design may assign a precedence to Timespecs only within a certain class of constraints. For example, you may specify a priority for a particular From:To specification to be greater than another, but you may not specify a From:To constraint to have priority over a TIG constraint. The following example illustrates the explicit assignment of priorities between two same-class timing constraints, the lowest number having the highest priority.
# Priority UCF example
TIMESPEC TS01 = FROM GROUPA TO GROUPB 40 PRIORITY 4;
TIMESPEC TS02 = FROM GROUP1 TO GROUP2 35 PRIORITY 2; The following sections illustrate the order of precedence for the various types (and various sources) of timing constraints.
Across constraint sources, the following priorities apply
Within constraint sources, the following priorities apply.
Layout constraints also have an inherent precedence which is based on the type of constraint and the site description provided to the tools. If two constraints have the same priority and cover the same path, then the last constraint in the constraint file will override any other constraints that overlap.
(FPGA only.) The mapping constraints in the example below illustrate some of the capabilities to control the implementation process for a design. The OPTIMIZE attribute is attached to the block of logic associated with the instance “GLUE.”All of the combinatorial logic within the block GLUE will be optimized for speed (minimizing levels of logic) while other aspects of the design will be processed by the default mapping algorithms (assuming the design-based optimization switches are not issued).
# Mapping constraint
INST GLUE OPTIMIZE = SPEED ;
# Layout constraint
NET IOBLOCK/DATA0_IN LOC = P12 ; The layout constraint in the example above illustrates the use of a full hierarchical path name for the net named DATA0_IN in the application of the I/O location constraint. In this example, IOBLOCK is a hierarchical boundary that contains the net DATA0_IN. Location constraints applied to “pad nets” are used to constrain the location of the PAD itself, in this case to site P12.
If the design contains a PAD, the constraint could have been just as easily applied to it directly (some design flows do not provide explicit I/O pads in the design netlist).
The process of mapping translates a design from the logical design domain to the physical design domain. The MAP process creates both the physical design components (CLBs, IOBs, and so forth) and the physical design constraints (layout and timing). The physical design components are written into a Native Circuit Description (NCD) file. The physical design constraints are written into a Physical Constraints File (PCF).
As the design flow of the “Constraint Entry Flow” figure shows, MAP not only writes a PCF file, but also reads a specified pre-existing PCF file. MAP reads an existing PCF file in order to facilitate the overriding of constraints that are contained within another logic design using the “last one wins” resolution mechanism provided by the PCF file. The following subsection briefly describes this approach.
MAP creates new physical design constraints each time it converts a logical design into a physical design. The constraints that are created during this process are written into the “Schematic” section of the PCF file. This section is recreated each time MAP is run based on the constraints that are contained within the NGD file. The schematic section is always written at the top of the PCF file, and constraints that are in the PCF file but outside of the Schematic section (after the line “SCHEMATIC END”) are considered to be in the “User” section of the PCF file. The user section is read, syntactically checked, and rewritten each time MAP is run. Since these constraints always follow those written into the schematic section, they will always take precedence (following the “last-one-wins” rule).
If the design contains a PAD, the constraint could have been just as easily applied to it directly (some design flows do not provide explicit I/O pads in the design netlist).
There are some special considerations for constraints for the XC5200XL family.
The previous section described the mechanisms available for constraining a design's timing within the Foundation tools. The sections that follow summarize each of the constraints that are available.
The robust nature of the language enables you to define your design requirements at the highest level of abstraction first, and then fine tune the timing requirements by using more specific Timespecs, if needed. This is the methodology that will best describe your requirements to the tools.
The following observations help to illustrate the reasons why this methodology should be followed (from a tool runtime perspective).
In conclusion, overall design runtime is improved when a “qualified global” timing methodology is employed instead of a “thorough-detailed” timing methodology.
The following examples clearly identify the “preferred” mechanism for controlling the timing of your design. The preferred method assumes a goal of getting the required results in the fastest run time possible. If the design has a single clock and required I/O timing that equals the clock period, all that you need are the three constraints shown in the following example.
# Global UCF example
NET CLK1 PERIOD = 40 ;
NET OUT* OFFSET = OUT 13 AFTER CLK ;
TIMESPEC TS01 = FROM PADS TO PADS 40 ; When you use net name wild cards in OFFSETS, make sure that the name is unique to valid nets; otherwise processing errors will occur.
If you need to account for extra delay external to the FPGA, then you could add the following.
NET INPUT* OFFSET = IN 8 BEFORE CLK ;
The PERIOD constraint covers all pad-to-setup and clock-to-setup timing paths. The OFFSET constraint covers the clock-to-pad timing for each of the output nets beginning with OUT. Both the OFFSET and PERIOD constraints account for the delay of the Clock Buffer/Net in the I/O timing calculations.
The following PCF fragment illustrates the differences in syntax between the UCF and PCF languages. In addition to the syntactical changes, remember that net and instance names may change. As an example, one of the net matches resulting from the UCF “NET OUT*” constraint is now applied to “COMP OUT1_PAD”. The name OUT1_PAD is the name assigned to the pad instance. In addition to name changes, another difference is the verbosity of the PCF. In the PCF there is additional syntax for “MAXDELAY,” “TIMEGRP,” and “PRIORITY.” These are all optional qualifications of the Timespec within the UCF, but written explicitly to the PCF file illustrating the full flexibility of the language.
# Global PCF example
SCHEMATIC START;
. . .
NET PERIOD “CLK_IN” = 40 nS HIGH 50.00% ;
COMP “OUT1_PAD” OFFSET = OUT 40 ns AFTER COMP “CLK”;
COMP “OUT2_PAD” OFFSET = OUT 40 ns AFTER COMP “CLK”;COMP “INPUT1_PAD” OFFSET = IN 28 ns BEFORE COMP “CLK”;
TS01 = MAXDELAY FROM TIMEGRP “PADS” TO TIMEGRP “PADS”
40000 pS PRIORITY 0;
SCHEMATIC END; The next UCF example illustrates the use of both global constraints (PERIOD, OFFSET) to generally constrain the design and detailed Timespecs (FROM:THRU:TO) to provide fast and slow exceptions to the general timing requirements. Because the amount of constraints placed on a design directly impact runtime, Xilinx recommends that you first apply global constraints, then apply individual constraints only to those elements of the design that require additional constraints (or an exception to a constraint). The more global the constraints, the better the runtime performance of the tools.
# Sample UCF file
# Specify target device and package
CONFIG PART = XC4010e-PQ208-3 ;
# Global constraints
NET CLK1 PERIOD = 40 ;
NET DATA_OUT* OFFSET = OUT 15 AFTER DCLK ;
TIMESPEC TS01 = FROM PADS TO PADS 40 ;
# Layout constraints
NET SCLINF LOC = P125 ;
# Detailed constraints
# Exception to cover X_DAT and Y_DAT buses
# Ignore timing on reset net
NET RESET_N TIG ;
# Slow exception for data leaving INA FFs
TIMESPEC TS02 = FROM FFS(INA*) TO FFS 80 ;
# Faster timing required for data leaving RAM
TIMESPEC TS03 = FROM RAMS TO FFS 20 ;
# Form special timegroups related to RAMs
INST $1I64 TNM = SPDRAM ;
NET RAMBUS0 TPTHRU = RAMVIA ;
NET RAMBUS1 TPTHRU = RAMVIA ;
# Specify timing for this special timing path
TIMESPEC TS04 = FROM SPDRAM THRU RAMVIA TO FFS 45 ; The “Timing Symbols and Their Default Values” table lists the block delay symbols, each with their corresponding description. There is a one-to-many correspondence between these symbol names and the Programmable Logic Data Book symbol names. For those symbols listed with a disabled default, no timing analysis is performed on paths that have a segment composed of symbol path. For example, paths which have a set/reset to output path will not be analyzed. Any of the block delays (Symbol) listed in the table may be explicitly enabled or disabled using the PCF file.
The following example shows the PCF syntax that enables the path tracing for all paths that contain RAM data to out paths. This PCF directive is placed in the user section of the PCF.
SCHEMATIC END;
// This is a PCF comment line
// Enable RAM data to out path tracing
ENABLE = ram_d_o;
The following table summarizes all supported constraints; it also shows whether the constraint must be entered at the schematic level or whether it can be specified in one or more of the valid constraint file types (NCF, UCF, or PCF). For further explanation and examples of each of the constraints, see the online Libraries Guide (Chapter 12, “Attributes, Constraints, and Carry Logic”).
| Constraint | Origin of Constraint | ||
|---|---|---|---|
| Schematic | 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 | | | |
| *The UCF and NCF files use the same constraints with the exception of the INIT constraint, which can only be used in NCF files. INIT can be used flip-flops only in a CPLD design in both UCF and NCF files. **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. | |||
The following sections summarize the functions of timespecs.
The PERIOD spec covers all timing paths that start or end at a register, latch, or synchronous RAM which are clocked by the reference net (excluding pad destinations). Also covered is the setup requirement of the synchronous element relative to other elements (for example, flip flops, pads, and so forth).
The default unit for time is nanoseconds.
NET clk20MHz PERIOD = 50 ;
NET clk50mhz TNM = clk50mhz ;
TIMESPEC TS01 = PERIOD : clk50mhz : 20 ;
FROM:TO style timespecs can be used to constrain paths between time groups.
Keywords: RAMS, FFS, PADS, and LATCHES are predefined time groups used to specify all elements of each type in a design.
TIMESPEC TS02 = FROM : PADS : TO : FFS : 36 ;
TIMESPEC TS03 = FROM : FFS : TO : PADS : 36 ns ;
TIMESPEC TS04 = FROM : PADS : TO : PADS : 66 ;
TIMESPEC TS05 = FROM : PADS : TO : RAMS : 36 ;
TIMESPEC TS06 = FROM : RAMS : TO : PADS : 35.5 ;
To automatically include clock buffer/routing delay in your “PADS:TO: synchronous element or synchronous element :TO:PADS timing specifications, use OFFSET constraints instead of FROM:TO constraints.
If you can ignore timing of paths, use Timing Ignore (TIG).
The “*” character is a wild-card which can be used for bus names. A “?” character can be used to wild-card one character.
NET : reset_n : TIG ;
NET : mux_mem/data_reg* : TIG ;
NET : mux_mem/data_reg* : TIG = TS01 ;
NET : data?_sig : TIG ;
If your design has outputs that can be slower than others, you can create specific timespecs similar to this example for output nets named out_data(7:0) and irq_n.
TIMEGRP slow_outs = PADS(out_data* : irq_n) ;
TIMEGRP fast_outs = PADS : EXCEPT : slow_outs ;
TIMESPEC TS08 = FROM : FFS : TO : fast_outs : 22 ;
TIMESPEC TS09 = FROM : FFS : TO : slow_outs : 75 ;
If you have multi-cycle FF to FF paths, you can create a time group using either the TIMEGRP or TNM statements.
WARNINGMany VHDL/verilog synthesizers do not predictably name flip flop Q output nets. Most synthesizers do assign predictable instance names to flip flops, however.
TIMEGRP slowffs = FFS(inst_path/ff_q_output_net1* : inst_path/ff_q_output_net2*);
INST inst_path/ff_instance_name1_reg* TNM = slowffs ;
INST inst_path/ff_instance_name2_reg* TNM = slowffs ;
TNM attached to a net “forward traces” to any FF, LATCH, RAM, or PAD attached to the net.
NET ff_clock_enable_net TNM = slowffs ;
TIMESPEC TS10 = FROM : slowffs : TO : FFS : 100 ;
INST io_buf_instance_name LOC = P110 ;
NET io_net_name LOC = P111 ;
INST instance_path/BEL_inst_name LOC = CLB_R17C36 ;
CONFIG PROHIBIT = C26 ;
CONFIG PROHIBIT = CLB_R5C3 ;
INST obuf_instance_name FAST ;
INST obuf_instance_name SLOW ;
NET any_net_name MAXSKEW = 7 ;
NET any_net_name MAXDELAY = 20 ns;
MEDDELAY/NODELAY can be attached to a CLB FF that is pushed into an IOB by the “map -pr i” option.
INST input_ff_instance_name MEDDELAY ;
INST input_ff_instance_name NODELAY ;
Highest
1. Timing Ignore (TIG)
2. FROM : THRU : TO specs
3. FROM : TO specs lowest
4. PERIOD specs
See the on-line documentation (dtext 
Library Reference Guide) for additional timespec features or additional information.
In the M1 XSI (Xilinx Synopsys Interface) HDL methodology, whenever large blocks of RAM/ROM are needed, LogiBLOX RAM/ROM modules are instantiated in the HDL code. With LogiBLOX RAM/ROM modules instantiated in the HDL code, timing and/or placement constraints on these RAM/ROM modules, and the RAM/ROM primitives that comprise these modules, can be specified in a UCF file. To create timing and/or placement constraints for RAM/ROM LogiBLOX modules, knowledge of how many primitives will be used and how the primitives, and/or how the RAM/ROM LogiBLOX modules are named is needed.
When a RAM/ROM is specified with LogiBLOX, the RAM/ROM depth and width are specified. If the RAM/ROM depth is divisible by 32, then 32x1 primitives are used. If the RAM/ROM depth is not divisible by 32, then 16x1 primitives are used instead. In the case of dual-port RAMs, 16x1 primitives are always used. Based on whether 32x1 or 16x1 primitives are used, the number of RAM/ROM can be calculated.
For example, if a RAM48x4 was required for a design, RAM16x1 primitives would be used. Based on the width, there would be four banks of RAM16x1s. Based on the depth, each bank would have three RAM16x1s.
Using the example of a RAM48x4, the RAM primitives inside the LogiBLOX are named as follows.
| MEM0_0 | MEM1_0 | MEM2_0 | MEM3_0 |
| MEM0_1 | MEM1_1 | MEM2_1 | MEM3_1 |
| MEM0_2 | MEM1_2 | MEM2_2 | MEM3_2 |
Each primitive in a LogiBLOX RAM/ROM module has an instance name of MEMx_y, where y represents the primitive position in the bank of memory and where x represents the bit position of the RAM/ROM output.
For the next two items, refer to the Verilog/VHDL examples included at the end of this section. The Verilog/VHDL example instantiates a RAM32x2S, which is in the bottom of the hierarchy. The RAM32x2S was implemented with LogiBLOX. The next two items are written within the context of the Verilog examples but also apply to the VHDL examples as well.
LogiBLOX RAM/ROM modules in the HDL Flow are constrained via a UCF file. LogiBLOX RAM/ROM modules instantiated in the HDL code can be referenced by the full-hierarchical instance name. If a LogiBLOX RAM/ROM module is at the top-level of the HDL code, then the instance name of the LogiBLOX RAM/ROM module is just the instantiated instance name.
In the case of a LogiBLOX RAM/ROM, which is instantiated within the hierarchy of the design, the instance name of the LogiBLOX RAM/ROM module is the concatenation of all instances which contain the LogiBLOX RAM/ROM. The concatenated instance names are separated by a “_”. In the example, the RAM32X1S is named memory. The module memory is instantiated in Verilog module inside with an instance name U0. The module inside is instantiated in the top-level module test. Therefore, the RAM32X1S can be referenced in a .ucf file as U0/U0. For example, to attach a TNM to this block of RAM, the following line could be used in the UCF file.
INST U0_U0 TNM=block1 ; Since U0/U0 is composed of two primitives, a Timegroup called block1 would be created; block1 TNM could be used throughout the .ucf file as a Timespec end/start point, and/or U0/U0 could have a LOC area constraint applied to it. If the RAM32X1S has been instantiated in the top-level file, and the instance name used in the instantiation was U0, then this block of RAM could just be referenced by U0.
Sometimes it is necessary to apply constraints to the primitives that compose the LogiBLOX RAM/ROM module. For example, if you choose a floorplanning strategy to implement your design, it may be necessary to apply LOC constraints to one or more primitives inside a LogiBLOX RAM/ROM module.
Returning to the RAM32x2S example above, suppose that the each of the RAM primitives had to be constrained to a particular CLB location. Based on the rules for determining the MEMx_y instance names and using the example from above, each of the RAM primitives could be referenced by concatenating the full-hierarchical name to each of the MEMx_y names. The RAM32x2S created by LogiBLOX would have primitives named MEM0_0 and MEM1_0. So, for an HDL Flow project, CLB constraints in a UCF file for each of these two items would be.
INST U0_U0/MEM0_0 LOC=CLB_R10C10 ;
INST U0_U0/MEM0_1 LOC=CLB_R11C11 ; Following is a Verilog example.
module test(DATA,DATAOUT,ADDR,C,ENB);
input [1:0] DATA;
output [1:0] DATAOUT;
input [4:0] ADDR;
input C;
input ENB;
wire [1:0] dataoutreg;
reg [1:0] datareg;
reg [1:0] DATAOUT;
reg [4:0] addrreg;
inside U0 (.MDATA(datareg),.MDATAOUT(dataoutreg),
.MADDR(addrreg),.C(C),.WE(ENB));
always@(posedge C) datareg = DATA;
always@(posedge C) DATAOUT = dataoutreg;
always@(posedge C) addrreg = ADDR; endmodule module inside(MDATA,MDATAOUT,MADDR,C,WE);
input [1:0] MDATA;
output [1:0] MDATAOUT;
input [4:0] MADDR;
input C;
input WE;
memory U0 ( .A(MADDR), .DO(MDATAOUT),
.DI(MDATA), .WR_EN(WE), .WR_CLK(C));
endmodule INST “U0_U0” TNM = usermem;
TIMESPEC TS_6= FROM : FFS :TO: usermem: 50;
INST “U0_U0/mem0_0” LOC=CLB_R7C2; Following is a VHDL example.
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
entity test is
port(
DATA: in STD_LOGIC_VECTOR(1 downto 0);
DATAOUT: out STD_LOGIC_VECTOR(1 downto 0);
ADDR: in STD_LOGIC_VECTOR(4 downto 0);
C, ENB: in STD_LOGIC);
end test;
architecture details of test is
signal dataoutreg,datareg: STD_LOGIC_VECTOR(1 downto 0);
signal addrreg: STD_LOGIC_VECTOR(4 downto 0);
component inside
port(
MDATA: in STD_LOGIC_VECTOR(1 downto 0);
MDATAOUT: out STD_LOGIC_VECTOR(1 downto 0);
MADDR: in STD_LOGIC_VECTOR(4 downto 0);
C,WE: in STD_LOGIC);
end component;
begin
U0: inside port map(MDATA=>datareg.,MDATAOUT=>dataoutreg.,MADDR=>addrreg,C=>C,WE=>ENB);
process( C )
begin
if(Cevent and C=1) then
datareg <= DATA;
end if;
end process;
process( C )
begin
if(Cevent and C=1) then
DATAOUT <= dataoutreg;
end if;
end process;
process( C )
begin
if(Cevent and C=1) then
addrreg <= ADDR;
end if;
end process;
end details; entity inside is
port(
MDATA: in STD_LOGIC_VECTOR(1 downto 0);
MDATAOUT: out STD_LOGIC_VECTOR(1 downto 0);
MADDR: in STD_LOGIC_VECTOR(4 downto 0);
C,WE: in STD_LOGIC);
end inside;
architecture details of inside is component memory
port(
A: in STD_LOGIC_VECTOR(4 downto 0);
DO: out STD_LOGIC_VECTOR(1 downto 0);
DI: in STD_LOGIC_VECTOR(1 downto 0);
WR_EN,WR_CLK: in STD_LOGIC);
end component;
begin
U0: memory port map(A=>MADDR,DO=>MDATAOUT,
DI=>MDATA,WR_EN=>WE,WR_CLK=>C);
end details;
INST “U0_U0” TNM = usermem;
TIMESPEC TS_6= FROM : FFS :TO: usermem: 50;
INST “U0_U0/mem0_0” LOC=CLB_R7C2;
