There are two mechanisms that can improve the timing of your design:
When you create a new project in the Design Manager, it is configured by default to optimize primarily for speed rather than for density. The Optimize Speed template containing all the recommended fitter options to achieve best first-run speed is selected in the Options menu. With the Optimize Speed template selected, the fitter performs global timing optimization on logic paths in your design. Timing optimization will shorten your critical paths as much as it can. In general, timing optimization optimizes logic and allocates the fastest available resources for the longest paths in your design, assuming all paths are equally critical. In some cases, the fitter trades off density for a speed advantage.
If you want to optimize for density instead of speed, select the Optimize Density template in the Design Manager Options menu. In the Optimize Density template, Timing Optimization is turned off. If you are customizing your own template settings, you can directly turn timing optimization off:
OptionsThis section describes the basic methods for entering timing specifications.
The software provides a set of timing constraint commands that you can use to specify the timing requirements of your Xilinx design. After compiling your design, the Xilinx software reads both your design netlist and your timing constraint commands and performs timing optimization according to your specifications.
The following path types can be controlled using timing specifications:
| Pad-to-pad delay | Input port to an output port |
| Register setup time | Input port to the data pin of a flip-flop, including flip-flop setup requirements |
| Register-to-register | Clock pin of a flip-flop to the data pin of the same or different flip-flop, including flip-flop setup requirements |
| Clock-to-output delay | Clock pin of a flip-flop to an output port |
This section outlines the commands that you can use to create timing specifications for your Xilinx CPLD designs.
This following tells you how to create new timing constraints from the Global tab window, and the Ports tab window of the Constraints Editor.
To start the Contraints Editor from the Design Manager, simply click on the Contraints Editor Icon found on the right side of the Design Manager graphical interface. See the Constraints Editor User Guide for more information.
After a constraint is created, it appears syntactically in the Editable Constraints list the same way it appears in the UCF.
The following global constraints are created from the Global tab window of the Constraints Editor.
To create a new clock period constraint, open the Global tab window. Follow the steps below.
An alternate way to invoke the Clock Period dialog box: right click in any row or column (except the heading), then click Period from the pop-up window.
Pad to Setup creates a constraint which allows you to specify the timing relationship between an external clock and data at the pins of a device. The Global tab window generates a dialog box from which you can specify a pad to setup requirement for all inputs that are clocked by the clock net identified by the user.
An alternate way to invoke the Pad to Setup dialog box: right click in any row or column (except the heading), then click Pad to Setup from the pop-up window.
The Relative to Clock Net field contains the name that you selected in Step 1. You are not allowed to change this field.
This creates a constraint which allows you to specify the timing relationship between an external clock and data at the pins of a device. The Global tab window generates a dialog box from which you can specify a time requirement for a global clock.
An alternate way to invoke the Clock to Pad dialog box: right click in any row or column (except the heading), then click Clock to Pad from the pop-up window.
The Relative to Clock Net field contains the name that you selected in Step 1. You are not allowed to change this field.
Save.The following constraints are created from the Ports tab window of the Constraints Editor.
The Ports tab window generates a dialog box from which you can specify a time requirement for individual ports relative to a selected clock net.
An alternate way to invoke the Pad to Setup dialog box: right click in any row or column (except the heading), then click Pad to Setup from the pop-up window.
The Ports tab window generates a dialog box from which you can specify a time requirement for a port relative to a selected clock net.
An alternate way to invoke the Clock to Pad dialog box: right click in any row or column (except the heading), then click Clock to Pad from the pop-up window.
This generates the FROM/THRU/TO dialog box, which allows you to specify an explicit maximum delay between groups of elements and through intermediate points.
This is particularly useful for defining pad-to-pad propagation delays between specific device pins.
The TIMESPEC schematic primitive, as illustrated in the “TIMESPEC Primitive” figure, serves as a placeholder for timing specifications, which are called TS attribute definitions. Every TS attribute must be defined in a TIMESPEC primitive. Every TS attribute begins with the letters ``TS” and ends with a unique identifier that can consist of letters, numbers, or the underscore character (_).
Figure 3.2 TIMESPEC Primitive |  |
A TS attribute defines the allowable delay for paths in your design. The basic syntax for a TS attribute is:
TSidentifier=FROM:source_group:TO:dest_group:delay
where TSidentifier is a unique name for the TS attribute, source_group and dest_group are groups of start points and end points, and delay defines the maximum delay for the paths between the start points and end points. The delay parameter defines the maximum delay for the attribute. Nanoseconds are the default units for specifying delay time in TS attributes. You can also specify delay using other units, such as picoseconds or megahertz.
Keywords, such as FROM, TO, and TS appear in the documentation in upper case; however, you can enter them in the TIMESPEC primitive in either upper or lower case. You cannot enter them in a combination of lower and upper case.
The basic TS attribute is described in detail in the “Basic TIMESPEC Syntax” section. More detailed forms of the attribute are also described in that section.
You can enter timing specifications as constraints in a UCF file. When you then run the fitter on your design, your timing specifications will be added to the design database as part of the NGD file.
The basic syntax for a timing specification entered in a constraints file is the TS attribute syntax described in the “Basic TIMESPEC Syntax” section.
In a TS attribute, you specify the set of paths to be analyzed by grouping start and end points in one of the following ways:
The following sections discuss each method in detail.
You can refer to a group of flip-flops or pads by using the corresponding keywords.
| Keyword | Description |
|---|---|
| FFS | Macrocell or IOB flip-flops, including those used to implement transparent latch macros. |
| PADS | Input/output pads |
Timing specification From-To statements enable you to define timing specifications for paths between predefined groups. The following examples are TS attributes attached to a TIMESPEC primitive or are entered in the UCF. This method enables you to easily define default timing specifications for the design, as illustrated by the following examples:
TS01=FROM:FFS:TO:FFS:30
TS04=FROM:FFS:TO:PADS:55
A predefined group can also carry a name qualifier; the qualifier can appear any place where the predefined group is used. This name qualifier restricts the number of elements being referred to. The syntax used is as follows:
predefined group (name_qualifier [: name_qualifier ])
where name_qualifier is the full hierarchical name of the net that is sourced by the primitive being identified.
The name qualifier can include wildcard characters (* to indicate any number of characters or ? to indicate a single character) which allows the specification of more than one net or allows you to shorten the full hierarchical name to something that is easier to type.
A TNM (timing name) is an attribute that can be used to identify the elements that make up a group of end-points (pads and flops) which can then be used in a timing specification. A TNM is a flag that you place directly on elements in your schematic to identify specific flops and pads. All symbols tagged with the same TNM value are considered members of the same group. Place TNM attributes directly on your schematic using the following syntax:
TNM=identifier
where identifier is a group name that consists of any combination of letters, numbers, or underscores. Keep the TNM short for convenience and clarity.
WARNINGDo not use the reserved words FFS, LATCHES, PADS, RAMS, RISING, FALLING, TRANSHI, TRANSLO, or EXCEPT, as identifiers.
You can specify as many groups of end points as are necessary to describe the performance requirements of your design. However, to simplify the specification process and reduce the place-and-route time, use as few groups as possible.
You can attach a TNM attribute to a macro symbol, in which case the TNM is applied to all applicable primitives inside the macro.
A predefined group can be used to qualify the application of a TNM attribute using the following syntax:
TNM=predefined_group:identifier
where predefined_group is one of the groups, FFS or PADS, and identifier is any valid group name. Paths defined by the TNM are traced forward, through any number of gates or buffers, until they reach a member of the specified predefined_group. That element is added to the specified TNM group. This mechanism is called forward tracing.
A predefined group in a TNM statement can have a net name qualifier (for example, TMM=FFS:(FRED*):GRP_A), as described in the “Creating Groups by Pattern Matching” section. In this example, the TNM is forward traced until it finds all flops producing signals matching the name FRED*; each such flop is then added to the group name GRP_A.
You can use several methods for tagging groups of end points: placing identifiers on nets, macro or primitive pins, primitives, or macro symbols. Which method you choose depends on how the path end points are related in your design. For each of these elements, you can use the predefined group syntax described earlier in this section.
The following subsections discuss the different methods of placing TNMs in your design. The same TNM attribute can be used as many ways and as many times as necessary to get the TNM applied to all of the elements in the desired group.
You can place TNM attributes in either of two places: in the schematic as discussed in this section or in a constraints file (UCF or NCF). The syntax for specifying TNMs in a UCF or NCF constraints file is described in the “Attributes” appendix.
Placing TNMs on NetsThe TNM attribute can be placed on any net in the design. The attribute indicates that the TNM value should be attached to all valid elements fed by all paths that fan forward from the tagged net. Forward tracing stops at any flip-flop or pad.
A TNM placed on a net connected to the output of a flip-flop does not apply to that flip-flop, but is instead forward-traced to subsequent flops or pads.
The TNM attribute can be placed on any macro or component pin in the design if the design entry package allows placement of attributes on macro or primitive pins. The attribute indicates that the TNM value should be attached to all valid elements fed by all paths that fan forward from the tagged pin. Forward tracing stops at any flip flop or pad.
Placing TNMs on Primitive SymbolsYou can group individual logic primitives explicitly by flagging each symbol, as illustrated by the “TNM on Primitive Symbols” figure.
Figure 3.3 TNM on Primitive Symbols | |
In the “TNM on Primitive Symbols” figure, the flip-flops tagged with the TNM form a group called “`FLOPS.” The untagged flip-flop is not part of the group.
Place only one TNM on each symbol, load pin, or macro load pin. If you want to assign more than one identifier to the same symbol, include all identifiers on the right side of the equal sign (=) separated by a semicolon (;), as follows:
TNM=joe;fred
Placing TNMs on Macro SymbolsA TNM attribute attached to a macro symbol (either a library or user macro) indicates that all applicable elements inside the macro (at all levels of hierarchy below the tagged macro) are part of the named group.
When a macro contains more than one symbol type and you want to group only a single type, use the TNM identifier in conjunction with one of the predefined groups: FFS or PADS, as indicated by the following syntax examples:
TNM=FFS:identifier
TNM=PADS:identifier
If you want to place an identifier on more than one symbol type, separate each symbol type and identifier with a semicolon (;) as illustrated by the following example:
TNM=FFS:FLOPS;PADS:OPADS
If multiple symbols of the same type are contained in the same hierarchical block, you can simply flag that hierarchical symbol, as illustrated by the “TNM on Macro Symbol” figure. In the figure, all flip-flops included in the macro are tagged with the TNM ``FLOPS.” By tagging the macro symbol, you do not have to tag each underlying symbol individually.
Figure 3.4 TNM on Macro Symbol | |
You can easily group flip-flops by flagging a common input net, typically either a clock net or an enable net. If you attach a TNM to a net or load pin, that TNM applies to all flip-flops that are reached through the net or pin. That is, that path is traced forward, through any number of gates or buffers, until it reaches a flip-flop. That element is added to the specified TNM group.
Placing a TNM on a net is equivalent to placing that TNM attribute on every load pin of the net. Use pin TNM attributes when you need finer control.
The “TNM on Net Used to Group Flip-Flops” figure illustrates the use of a TNM on a net that traces forward to create a group of flip-flops. In the figure, the attribute TNM=FLOPS traces forward to the first two flip-flops, which form a group called FLOPS. The bottom flip-flop is not part of the group FLOPS
Figure 3.5 TNM on Net Used to Group Flip-Flops | |
The “TNM on Clock Pin Used to Group Flip-Flops” figure illustrates placing a TNM on a clock net, which traces forward to all three flip-flops and forms the group Q_FLOPS:
Figure 3.6 TNM on Clock Pin Used to Group Flip-Flops | |
The TNM parameter on nets or pins is allowed to have a qualifier.
For example:
TNM=FFS:data
A qualified TNM is traced forward until it reaches the first flip-flop. If that flip-flop matches the qualifier, the flip-flip is given that TNM value. Whether or not there is a match, the TNM is not traced through that flip-flop.
In addition to naming groups using the TNM identifier, you can also define groups in terms of other groups. You can create a group that is a combination of existing groups by defining a TIMEGRP attribute as follows:
newgroup=existing_grp1:existing_grp2 [:existing_grp3 . . .]
where newgroup is a newly created group that consists of existing groups created via TNMs, predefined groups, or other TIMEGRP attributes.
Mentor Users - You must specify a leading equal sign (=) when defining TIMEGRP attributes, for example, =newgroup. The preceding equal sign lets Mentor know that this is a user-defined attribute. Refer to the Mentor Graphics Interface/Tutorial Guide for more information.
TIMEGRP attributes reside in the TIMEGRP primitive, as illustrated in the “TIMEGRP Primitive” figure. Once you create a TIMEGRP attribute definition within a TIMEGRP primitive, you can use it in the TIMESPEC primitive. Each TIMEGRP primitive can hold up to eight group definitions. Since your design might include more than eight TIMEGRP attributes, you can use multiple TIMEGRP primitives.
Figure 3.7 TIMEGRP Primitive | |
You can place TIMEGRP attributes in either of two places: in the TIMEGRP primitive on the schematic as discussed in this section or in a constraints file (UCF or NCF). The syntax for specifying TNMs in a UCF or NCF constraints file is described in the “Attributes” appendix.
You can use TIMEGRP attributes to create groups using the following methods:
The following subsections discuss each method in detail.
You can define a group by combining other groups. The following syntax example illustrates the simple combining of two groups:
big_group=small_group:medium_group
In this syntax example, small_group and medium_group are existing groups defined using a TNM or TIMEGRP attribute. Within the TIMEGRP primitive, TIMEGRP attributes can be listed in any order; that is, you can create a TIMEGRP attribute that references another TIMEGRP attribute that appears after the initial definition.
WARNINGA circular definition, as shown below, causes an error when you run your design through NGDBUILD.
many_ffs=ffs1:ffs2
ffs1=many_ffs:ffs3
You can define a group that includes all elements of one group except the elements that belong to another group, as illustrated by the following syntax examples:
group1=group2:EXCEPT:group3
As illustrated by the following example, you can specify multiple groups to include or exclude when creating the new group.
group1=group2:group3:EXCEPT:group4:group5
The example defines a group1 that includes the members of group2 and group3, except for those members that are part of group3 or group4. All of the groups before the keyword EXCEPT are included, and all of the groups after the keyword are excluded.
Certain reserved words cannot be used as group names. These reserved words are described in the “Creating User-Defined Groups Using TNMs” section.
You can create subgroups using the keywords RISING and FALLING to group flip-flops triggered by rising and falling edges.
group1=RISING:ffs
group2=RISING:ffs_group
group3=FALLING:ffs
group4=FALLING:ffs_group
where group1 to group4 are new groups being defined. The ffs_group must be a group that includes only flip-flops.
Keywords, such as EXCEPT, RISING, and FALLING, appear in the documentation in upper case; however, you can enter them in the TIMESPEC primitive in either lower or upper case. You cannot enter them in a combination of lower and upper case.
The following example defines a group of flip-flops that switch on the falling edge of the clock.
falling_ffs=FALLING:ffs
When creating groups, you can use wildcard characters to define groups of symbols whose associated net names match a specific pattern.
How to Use Wildcards to Specify Net NamesThe wildcard characters, * and ?, enable you to select a group of symbols whose output net names match a specific string or pattern. The asterisk (*) represents any string of zero or more characters. The question mark (?) indicates a single character.
For example, DATA* indicates any net name that begins with “DATA,” such as DATA, DATA1, DATA22, DATABASE, and so on. The string NUMBER? specifies any net names that begin with ``NUMBER” and end with one single character, for example, NUMBER1, NUMBERS but not NUMBER or NUMBER12.
You can also specify more than one wildcard character. For example, *AT? specifies any net names that begin with any series of characters followed by ``AT” and end with any one character such as BAT1, CAT2, and THAT5. If you specify *AT??, you would match BAT11, CAT26, and THAT50.
Pattern Matching SyntaxThe syntax for creating a group using pattern matching is shown below:
group=predefined_group(pattern)
where predefined_group can only be one of the following predefined groups - FFS or PADS. The pattern is any string of characters used in conjunction with one or more wildcard characters.
For flip-flops specify the output net name. For pads, specify the name of the external net connected to the pad.
The following example illustrates creating a group that includes the flip-flops that source nets whose names begin with $1I3/FRED.
group1=ffs($1I3/FRED*)
The following example illustrates a group that excludes certain flip-flops whose output net names match the specified pattern:
this_group=ffs:EXCEPT:ffs(a*)
In this example, this_group includes all flip-flops except those whose output net names begin with the letter ``a.”
Additional Pattern Matching DetailsIn addition to using pattern matching when you create timing groups, you can specify a predefined group qualified by a pattern any place you specify a predefined group. The syntax below illustrates how pattern matching can be used within a timing specification:
TSidentifier=FROM:predefined_group(pattern):TO:predefined_group
(pattern):delay
Instead of specifying just one pattern, you can also specify a list of patterns separated by a colon (:) as illustrated below:
some_ffs=ffs(a*:b?:c*d)
The group some_ffs contains flip-flops whose output net names:
Within the TIMESPEC primitive, you use the following syntax to specify timing requirements between specific end points:
TSidentifier=FROM:source_group:TO:dest_group:delay
The From-To statements are TS attributes that reside in the TIMESPEC primitive. The parameters source_group and dest_group must be one of the following:
Predefined groups consist of FFS or PADS and are discussed in the “Using Predefined Groups” section. TNMs are introduced in the “Creating User-Defined Groups Using TNMs” section. TIMEGRP symbols are introduced in the “Creating New Groups from Existing Groups” section.
Keywords, such as FROM, TO, and TS appear in the documentation in upper case; however, you can enter them in the TIMESPEC primitive in either upper or lower case. You cannot enter them in a combination of lower and upper case.
The delay parameter defines the maximum delay for the attribute. Nanoseconds are the default units for specifying delay time in TS attributes. You can also specify delay using other units, such as picoseconds or megahertz. Refer to the “Specifying Time Delay in TS Attributes” section later in this chapter for more information on time delay.
The following examples illustrate the use of From-To TS attributes:
TS01=FROM:FFS:TO:FFS:30
TS_OTHER=FROM:PADS:TO:FFS:25
You can place TS attributes containing From-To statements in either of two places: in the TIMESPEC primitive on the schematic as discussed in this chapter or in a constraints (UCF) file. See the “Attributes” appendix for more information about specifying timing requirements in a constraints file.
Nanoseconds are the default units for specifying delay times in TS attributes. However, after specifying the maximum delay or minimum frequency numerically, you can enter the unit of measure by specifying the following:
As an alternate way of specifying time delay, you can specify one time delay in terms of another. This method is described in the next section.
Instead of specifying a time or frequency in a TS attribute definition, you can specify a multiple or division of another TS attribute. This is useful in a system where all clocks are derived from a master clock; in this situation, changing the timing specification for the master clock changes the specification for all clocks in the system.
Use the syntax below to specify a TS attribute delay in terms of another.
TSidentifier=specification:reference_TS_attribute[*|/]number
where number can be either a whole number or a decimal. The specification can be any From-To statement as illustrated by the following examples:
FROM:PADS:TO:PADS
FROM:group1:TO:group2
FROM:tnm_identifier:TO:FFS
Use “*” to represent multiplication and “/” to represent division. The specification type of the reference TS attribute does not need to be the same as the TS attribute being defined; however, it must not be specified in terms of AUTO or IGNORE.
There may be situations where two TIMESPECs at the same level of priority conflict. In these cases you can define the priority of a TIMESPEC using the following syntax:
normal_timespec_syntax : PRIORITY : integer
where normal_timespec_syntax is a legal TIMESPEC and integer represents the priority (the smaller the number, the higher the priority). The number can be positive, negative, or zero, and the value only has meaning when compared with other PRIORITY values.
See the “Controlling Timing Paths” section for more details.
A clock period specification checks timing clocked by the net (all paths that terminate at a register clocked by the specified net). The period specification is attached to the clock net. The definition of a clock period is unlike a FROM:TO style specification, because the timing analysis tools will automatically take into account any inversions of the clock net at register clock pins.
A PERIOD constraint on the clock net would generate a check for delays on all paths that terminate at a pin that has a setup or hold timing constraint relative to the clock net. This could include the data paths DI to MC1.D, MC1.Q to MC2.D, as well as the paths D0 to MC1.R and EN to MC2.EC (if the reset/enable were synchronous with respect to the clock).
Simple MethodA simple method of defining a clock period is to attach the following attribute directly to a net in the path that drives the register clock pins:
PERIOD = period : { HIGH | LOW }: [high_or_low_time]
where period is the required clock period. The default units are nanoseconds, but the timing number can be followed by ps, ns, us, or ms. Units may be entered with or without a leading space, and are case-insensitive. The high_or_low_time is the optional high or low time depending on the HIGH|LOW 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%. The default units for high_or_low_time is ns, but the number can be followed by %, ps, us or ms.
The PERIOD constraint is forward traced in exactly the same way a TNM would be and attaches itself to all of the flip flops that the forward tracing reaches. There are no rules about not tracing through certain elements. If a more complex form of tracing behavior is required (for example, where gated clocks are used in the design), you must place the PERIOD on a particular net, or use the preferred method described next.
Preferred MethodThe preferred method for defining a clock period allows more complex derivative relationships to be defined as well as a simple clock period. The following attribute is attached to a TIMESPEC symbol in conjunction with a TNM attribute attached to the relevant clock net.
TSidentifier=PERIOD: TNM_reference: period: {HIGH | LOW}: [high_or_low_time]
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 a TNM attribute, and period is the required clock period. The default units for period are nanoseconds, but the number can be followed by ps, ns, us, or ms. Units may be entered with or without a leading space, and are case-insensitive. High_or_low_time is the optional high or low time depending on the HIGH|LOW 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%. The default units for high_or_low_time is ns, but the number can be followed by %,, ps, ns, or mst.
To specify setup time using the OFFSET constraint, use the following syntax:
NET input_pad OFFSET=IN:delay:BEFORE:clock_pad;
OFFSET=IN:delay:BEFORE:clock_pad;
where delay is in nanoseconds.
To specify clock-to-output delay using the OFFSET constraint, use the following syntax:
NET output_pad OFFSET=OUT:delay:AFTER:clock_pad;
OFFSET=OUT:delay:AFTER:clock_pad;
where delay is in nanoseconds.
In some cases, two timing specifications will cover the same path. For cases where the two timing specifications are mutually exclusive, the following constraint rules apply:
If two constraints are in the same category, the user-defined priority described in the “Setting TIMESPEC Priorities” section is used to determine which constraint takes precedence.
The XC9000 architecture, like most CPLD devices, is organized as a large, variable-sized combinational logic resource (the AND-array and XOR gate) followed by a register. If you place combinational logic before a register in your design, the fitter maps the logic and register into the same macrocell. The output of the register is then directly available at an output pin of the device. If, however, you place logic between the output of a register and the device output pin, a separate macrocell must used to perform the logic, decreasing both the speed and density of your design. The “Reducing Levels of Logic” figure shows two functionally similar designs, one that is efficient for CPLD architectures and one that is inefficient.
Figure 3.8 Reducing Levels of Logic | |
By default, all internal nodes in an XC9500 design (those that remain after collapsing) are routed via the FastCONNECT structure. There are also higher-speed routing paths that feed back from each macrocell to the inputs of the same local function block. To use the local feedback path for a particular node in your design, both the source logic and the load logic on the node must be mapped to the same function block. If you entered timespecs for your design, the fitter will attempt to use local feedback where necessary to satisfy your timespecs. When the feedback path between two macrocells is involved in a timing-constrained path, and if the timing constraints cannot be met using FastCONNECT routing, the fitter will attempt to map both macrocells to the same function block and use the local feedback path.
If you want to explicitly control the use of local feedback routing, you must:
Hint: You can specify the value of 1 ns in your timespec to tell the fitter to use local feedback, even though the fitter will warn you that it cannot satisfy your timespecs.
As an alternative to applying a timing specification (#2), you can turn on the Use Local Macrocell Feedback option in the Design Manager. But, that would allow the local feedback path to be used for any other internal nodes in the design that run between two functions that happen to get mapped to the same function block.
Turning off the Use Local Macrocell Feedback option does not prevent the fitter from automatically using the local feedback path when necessary to satisfy your timespecs.
The XC9536 device does not have local feedback.
