FPGA Timing Constraint Strategies

from: http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0040_7.html

FPGA Timing Constraint Strategies

This section provides general guidelines that explain how to constrain the timing on designs when using the implementation tools for FPGAs.

For more information about timing constraints and strategies, go to the Xilinx home page, click Support. Then select Tech Tips Timing & Constraints.

Basic Implementation Tools Constraining Methodology

Creating global constraints for a design is the easiest way to provide coverage of the constrainable connections in a design and guide the tools to meet timing requirements for all paths. The global constraints constrain the whole design. If there are multi-cycle or static paths, you can constrain them using more specific constraints. A multi-cycle path is a path between two registers with a timing requirement that is a multiple of the clock period for the registers. A static path does not include clocked elements, for example, pad-to-pad paths.

Xilinx recommends specifying the exact value required for a path as opposed to over-tightening a specification. Specifying tighter constraints than required is not recommended because tighter constraints can lengthen PAR runtimes and cause degradation in the quality of results.

The Constraints Editor is designed around the methodology discussed in this chapter. The group names and TSids in the examples show how the Constraints Editor populates the grids and creates new groups and constraints. The Constraints Editor provides additional help; the clocks and IOs are supplied so you do not have to come up with the exact spelling of the names and only have to define the timing and not the syntax of the constraints. For more specific grouping, element names are provided, and exceptions to the global constraints can be made using those groups.

The first tab of the Constraints Editor shows all the global paths that need to be covered. If this tab is completed, all synchronous paths will be covered.

Note: All examples in this chapter show the UCF syntax.

Global Timing Assignments

Global timing assignments are overall constraints that cover all constrainable paths in a design. These assignments include clock definitions, input and output timing requirements, and combinatorial path requirements.

Following are some recommendations for assigning definitions.

Assigning Definitions for Clocks Driven by Pads

Define each clock in the design. Defining each clock covers all synchronous paths within each clock domain and paths that cross between related clock domains. Use a TNM_NET on each clock net (on the net attached to the pad, usually the port name in HDL) and then use the TIMESPEC PERIOD syntax with the TNM_NET group created. Using the TIMESPEC version of the PERIOD definition allows for greater path control later on when constraining paths between clock domains.

See “Assigning Definitions for DLL/DCM Clocks” if using a Virtex DLL/DCM.

Related Clocks Example

The following example design has two clocks. TNM_NETs identify the synchronous elements of each clock domain. TIMESPEC PERIOD gives the flexibility to describe inter clock domain path requirements. The clock, “clock2_in,” has twice the period of “clock1_in” which is shown in the following UCF example with the clock2_in PERIOD definition using a function of the “TS_clock1_in” specification (“TS_clock1_in” * 2).

NET “clock1_in” TNM_NET =  “clock1_in”;

TIMESPEC “TS_clock1_in” = PERIOD “clock1_in” 20 ns HIGH 10;

NET “clock2_in” TNM_NET = “clock2_in”;

TIMESPEC “TS_clock2_in” = PERIOD “clock2_in” “TS_clock1_in” * 2;

The Constraints Editor uses the clock pad net name for the group name and the TSid as show in the previous example. This feature is important if you want to override a constraint that was entered in the source.

PHASE Related Clocks Example

The following example shows how to specify two clocks related by a phase difference. The clock "clock" has a period of 10ns, "clock_90" is also 10 ns, but is shifted 90 degrees out of phase or is lagging "clock's" rising edge by 2.5 ns. You can use the keyword "PHASE" that allows you to identify this relationship. The timing tools use this information in OFFSET and cross-clock domain paths. See the following example.

NET "clock" TNM_NET = "clock";

TIMESPEC "TS_clock" = PERIOD "clock" 10 ns HIGH 50%;

NET "clock_90" TNM_NET = "clock_90";

TIMESPEC "TS_clock_90" = PERIOD "clock_90" "TS_clock" * 1 PHASE + 2.5ns;

Assigning Definitions for DLL/DCM Clocks

TRANSLATION (NGDBuild) propagates TNM_NET tags through DLLs and DCMs. NGDBuild creates new TNM_NETs for each of the DLL and DCM output taps and associated PERIOD statements. The code takes into account the phase relationship factor of the outputs for the DLL, and also performs the appropriate multiplication or division of the PERIOD value.

The code also takes into account any of the PHASE taps adjustments. This means that for OFFSETs and cross-clock domain paths, the timing tools now know the relationship for PHASE shifts also.

DCM PERIOD Propagation Example

In this example, you only need to define the input clock to the DCM and the tools will generate all of the correct PERIODs for the output taps. Assume that the input clock (net "clock_in" with PERIOD 30 ns) DCM in this example uses the CLK0 (net "clock0") and CLK2X180 (net "clock2x180") output taps. When you define the input clock, the system performs all of the transformations.

For input clock “clock_in”:

NET "clock_in" TNM_NET = "clock_in";

TIMESPEC "TS_clock_in" = PERIOD "clock_in" 30 ns HIGH 50%;

Generated clock definitions:

NET "clock0" TNM_NET = "clock0";

TIMESPEC "TS_clock0" = PERIOD "TS_clock_in" * 1;

NET "clock2x180" TNM_NET = "clock2x180";

TIMESPEC "TS_clock2x180" = PERIOD "TS_clock_in" / 2 PHASE + 7.50 ns;

Assigning Definitions for Derived and Gated Clocks

For clocks that are created in the FPGA, such as the output of a register or a gated clock (the output of combinatorial logic), the net name from the output of the register or gate should be the name used for the TNM_NET group name and TSid.

See “OFFSETs with Derived or Gated Clocks”.

Assigning Input and Output Requirements

Constrain input and output timing requirements using the OFFSET constraints. Pad to Setup requirements use OFFSET IN BEFORE and for Clock to Out requirements use OFFSET OUT AFTER. You can specify OFFSETs in three levels of coverage.

The first, global OFFSET applies to all inputs or outputs for a specific clock.
The second, a group OFFSET form, identifies a group of inputs or outputs clocked by a common clock that have the same timing requirements.
The third, a specific OFFSET form, specifies the timing by each input or output.

OFFSET constraints of a more specific scope override a more general scope.

A group OFFSET overrides a global OFFSET specified for the same IOs. A specific OFFSET overrides both global and group OFFSETs if used. This priority rule allows you to start with global OFFSETs, then create group or specific OFFSETs for IOs with special timing requirements.

For memory usage and runtime considerations, use global and group OFFSETs and avoid specific OFFSETs whenever possible. Using wildcards in the specific OFFSET form creates multiple specific OFFSET constraints, not a group OFFSET.

Example:

NET bob* OFFSET = IN 5 AFTER clock;

Global Inputs Requirements

Use OFFSET IN BEFORE to define Pad to Setup timing requirements. OFFSET IN BEFORE is an external clock-to-data relationship specification and takes into account the clock delay, clock edge and DLL/DCM introduced clock phase when analyzing the setup requirements (data delay + setup - clock delay-clock arrival).). Clock arrival takes into account any clock phase generated by the DLL/DCM or clock edge. This strategy constrains all of the inputs clocked by the same clock to identical requirements.

Following is a global OFFSET IN BEFORE example:

OFFSET = IN value units BEFORE clock_pad_net;

OFFSET = IN 10 ns BEFORE “clock_in”;

where

value is the time allowed for the data to propagate from the pad to meet a setup requirement to the clock. This value is in relationship to the clocks initial edge at the pin of the chip. (The PERIOD constraint defines the clock initial edge.)
units is ms, us, ns (default) or ps
clock_pad_net is the name of the clock using the net name attached to the pad (This or the port name for HDL designs).

Global Outputs Requirements

Use OFFSET OUT AFTER to define Clock to Pad timing requirements. OFFSET OUT AFTER is an external clock-to-data specification and takes into account the clock delay, clock edge and DLL/DCM introduced clock phase when analyzing the setup requirements (clock delay + clock to out + data delay +clock arrival). Clock arrival takes into account any clock phase generated by the DLL/DCM or clock edge. This strategy constrains all of the outputs clocked by the same clock to the same requirement.

The following is a global OFFSET OUT AFTER example:

OFFSET = OUT value units AFTER clock_pad_net;

OFFSET = OUT 10 ns AFTER "clock_in";

where

value is the time allowed for the data to propagate from the synchronous element (clock to out, TCKO) to the pad. This value is in relationship to the clocks initial edge at the pin of the chip. (The PERIOD constraint defines the clock initial edge.)
units is ms, us, ns (default) or ps
clock_pad_net is the name of the clock using the net name attached to the pad or the port name for HDL designs.

Assigning Global Pad to Pad Requirements

Use a FROM PADS TO PADS constraint to globally constrain all combinatorial pin-to-pin paths. If you do not have any combinatorial pin-to-pin paths, ignore this constraint.

Following a global pad to pad example:

TIMESPEC “TSid” = FROM “PADS” TO “PADS” value units;

TIMESPEC “TS_P2P” = FROM “PADS” TO “PADS” 10 ns;

where

id is a user-specified unique identifier for the constraint
value is the time allowed for the data to propagate from an input pad to an output pad
units is ms, us, ns (default) or ps

Specific Timing Assignments

If there are paths that are static in nature, you can use TIG to eliminate the paths from timing consideration in Place and Route (PAR) and TRCE. If there are paths that require faster or slower specifications than the global requirements, you can create fast or slow exceptions for those paths. If multi-cycle paths exist, identify and constrain them.

Note: The tigs paths still show the longest delay for that constraint in the verbose timing report. Net tigs can be turned off in the Timing Analyzer to see the actual timing on these nets.

Ignored Paths (TIG)

You can specify false paths (paths to ignore) in two different ways—by nets and elements or by timing paths. Identifying false paths allows PAR to concentrate on more critical paths when placing components and when using routing resources. There might be less runtime because PAR does not have to meet a specific timing requirement. Creating a large number of path tigs can increase memory usage and possibly increase runtime due to the extra paths models that are created.

By Nets or Elements

These paths are ignored by both PAR and timing analysis and do not show up in the timing report. Also these paths are not included in the Connection Coverage statistic. See “Ignored Paths (TIG)” for more information.

False Paths by Net

You can define false paths for all paths that pass through a particular net using the following UCF syntax:

NET “net_name” TIG;

You can also define false paths for a specified set of paths that pass through a particular net using the following UCF syntax:

NET “net_name” TIG = TSid_list;

where

net_name is the name of the net that the paths are passing through.
TSid_list is a comma-delimited list of TIMESPEC identifiers to which the TIG applies.

False Paths by Instance

You can define false paths for all paths that pass through a particular instance using the following UCF syntax:

INST “inst_name” TIG;

You can also define false paths for a specified set of paths that pass through a particular instance using the following UCF syntax:

INST “inst_name” TIG = TSid_list;

where

inst_name is the name of the instance that the paths are passing through
TSid_list is a comma-delimited list of TIMESPEC identifiers to which the TIG should apply

False Paths by Pin

You can define false paths for all paths that pass through a particular instance pin using the following UCF syntax:

PIN “instance.pin_name” TIG;

You can also define false paths for a specified set of paths that pass through a particular instance pin using the following UCF syntax:

PIN “instance.pin_name” TIG = TSid_list;

where

instance.pin_name is the name of the instance and the pin identifier separated by a period that the paths are passing through
TSid_list is a comma-delimited list of TIMESPEC identifiers to which the TIG should apply

False Paths by Timing Path

You can create groups, use the FROM TO, FROM THRU TO, or open FROM or TO constraints, and then specify TIG as the path value. See “False Paths by Path” for syntax usage. These paths show up in a timing analysis report, but the timing is not considered. These paths are also included in the connection coverage statistics.

Following is a FROM TO TIG example:

TIMESPEC “TSid” = FROM “from_grp” TO “to_grp” TIG;

where

id is a user-specified unique identifier for the constraint
from_grp and to_grp are TIMEGRPs

Following is a FROM THRU TO TIG example:

TIMESPEC “TSid” = FROM “from_grp” THRU “thru_pt” TO “to_grp” TIG;

where

id is a user-specified unique identifier for the constraint
from_grp and to_grp are TIMEGRPs
thru_pt is a net, instance or pin

See “TPTHRU” for details on defining TPTHRU points.

Asynchronous Set/Reset Paths

The tools do not automatically analyze asynchronous set/reset paths. Automatic analysis is controlled by the path tracing controls. See “DISABLE” and “ENABLE”.

Multi-Cycle and Fast or Slow Timing Assignments

These path assignments include multi-cycle paths and fast or slow exceptions. First create timing groups to define start point and end points for the paths. These groups are used in the FROM TO timing constraints to override the PERIOD constraints for these specific paths. The following sections describe different exception types.

Cross-Clock Domain Constraining

The timing tools no longer include domain paths in the destination register clock domain if the clocks are not defined as related. Related clock domains are defined in the system as a function of other clock TIMESPECs. The TRANSLATE (NGDBuild) phase automatically relates clocks from the outputs of a DLL/DCM. If the paths between two "related" clocks are false or require a different time requirement than calculated, then create a FROM:TO constraint with a TIG or the correct value. If the clocks are unrelated but have valid paths between them, then create FROM TO constraints to constrain them. To constrain paths between two clocks and use the groups created by each clock domain, create a FROM TO for each direction that paths pass between the two clock domains, then specify the time requirement according to the path requirement. See “Related Clocks Example” to see how the groups were created.

Following is a cross-clock domain TIMESPEC example:

TIMESPEC “TS_clock1_in_2_clock2_in” = FROM “clock1_in” TO “clock2_in” 10 ns;

User Group Creation

You can create groups to identify path end points. There are three basic methods allowed for creating groups.

By connectivity
By hierarchy
By elements

The types of elements that can be grouped are FFS, PADS, RAMS, BRAMS_PORTA, BRAMS_PORTB, CPUS, MULTS, HSIOS and LATCHES. These are considered reserved keywords that define the types of synchronous elements in FPGAs and pads.

There are four different basic ways to create user groups.

Identifying Groups by Connectivity

Identifying groups by connectivity allows you to group elements by specifying nets that eventually drive synchronous elements and pads. This method is a good way to identify multi-cycle paths elements that are controlled by a clock enable. This method uses TNM_NET on a net.

The TNM_NET syntax for identifying groups by connectivity is:

NET “net_name” TNM_NET = qualifier “tnm_name”;

where

net_name is the name of a net propagated by the tools to the element ends.
tnm_name is the user-assigned name for the group created by the TNM_NET. Multiple nets can be assigned the same tnm_name.
An optional qualifier of FFS, PADS, RAMS, BRAMS_PORTA, BRAMS_PORTB, CPUS, MULTS, HSIOS or LATCHES may be used when the net_name contains wildcards.

Identifying Groups by Hierarchy

Identifying groups by hierarchy allows you to group by traversing the hierarchy of a module and tagging all predefined elements with the TNM. This method uses a TNM on a block. The TNM syntax for identifying groups by hierarchy is:

INST “inst_name” TNM = qualifier “tnm_name”;

where

inst_name is the hierarchical name of a macro or module to be traversed by the tools to identify underlying elements for the group labeled by the tnm_name label.
An optional qualifier of FFS, PADS, RAMS, BRAMS_PORTA, BRAMS_PORTB, CPUS, MULTS, HSIOS or LATCHES may be used.

Identifying Specific Elements by Instance Name

Identifying elements directly allows you to group by tagging predefined elements with a TNM. Multiple instances can be given the same tnm_name.

The TNM syntax for identifying groups by instance is:

INST “inst_name” TNM = qualifier “tnm_name”;

where

inst_name is the predefined instance name for the group labeled by the tnm_name label.
An optional qualifier of FFS, PADS, RAMS, BRAMS_PORTA, BRAMS_PORTB, CPUS, MULTS, HSIOS or LATCHES may be used when the inst_name contains wildcards.

Identifying Elements for Groups using Element Output Net Names

This method is mainly used by schematic users who generally name nets, not instances. Identifying elements individually is used for singling out elements or identifying elements by output net name. This method uses TIMEGRP and allows the use of wildcards (*, ?) for filtering elements. This method is best used for schematics where the instance names are rarely known but the output nets generally are.

The TIMEGRP syntax for identifying groups by element output net name is:

TIMEGRP “tgrp_name” = qualifier (output_net_name);

where

tgrp_name is the name assigned by you to the group
qualifier is a (FFS, PADS, RAMS, BRAMS_PORTA, BRAMS_PORTB, CPUS, MULTS, HSIOS, LATCHES) keyword
output_net_name is the output net name for each element that you would like to group. You can use wildcards with output_net_name.

Specific OFFSET Constraints Using PAD and or Register Groups

You can use grouping with OFFSET. Grouping includes both register groups and pad groups. Grouping allows you to group pads to set the same path delay requirements and group registers for identifying paths that have different requirements from or to single pads. You can group and constrain the single pads and registers all at once. This is useful if a clock is used on the rising and falling edge for inputs or outputs. These two groups will require different constraints.

Group OFFSET IN Example

TIMEGRP “pad_group” OFFSET = IN time units BEFORE “clock_pad_net” TIMEGRP “register_group”;

where

pad_group is the user- created group of input pads
time is the time allowed for the data to propagate from the pad to meet a setup requirement to the clock. This value is in relationship to the clocks initial edge at the pin of the chip. (The PERIOD constraint defines the clock initial edge.)
units is ms, us, ns (default) or ps
clock_pad_net is the name of the clock using the net name attached to the pad
register_group is the user-created group of synchronous elements

Group OFFSET OUT Example

TIMEGRP “pad_group” OFFSET = OUT time units AFTER “clock_pad_net” TIMEGRP “register_group”;

where

pad_group is the user- created group of output pads
time is the time allowed for the data to propagate from the pad to meet a setup requirement to the clock. This value is in relationship to the clocks initial edge at the pin of the chip. (The PERIOD constraint defines the clock initial edge.)
units is ms, us, ns (default) or ps
clock_pad_net is the name of the clock using the net name attached to the pad
register_group is the user-created group of synchronous elements

FROM TO Syntax

This group includes FROM, TO, and FROM TO. FROM specifies the source group, and TO specifies the destination group. Using just a FROM assumes all destinations are TO points and using just a TO assumes all sources are FROM points. The FROM TO syntax is used in the following path assignments and is defined as follows in the UCF:

TIMESPEC “TSid” = FROM “from_grp” TO “to_grp” value units;

where

id is a user-specified unique identifier for the constraint
from_grp and to_grp are TIMEGRPs
value is a specific time, a (*,?) function of another TSid (that is, TS_01 *2), or TIG. The allowable operations are: “*” (multiply) and “/” (divide).
units is ms, us, ns (default) or ps

Open FROM to TO example:

TIMESPEC “TSid” = FROM “from_grp” value units;

where

id is a user specified unique identifier for the constraint
from_grp is TIMEGRP
value is the time requirement
units is ms, us, ns (default) or ps

FROM THRU TO Syntax

You can further narrow down paths by using TPTHRU and FROM THRU TO. You can also specify multiple THRUs. See “TPTHRU”. Again, the FROM or TO are optional.

Multi-Cycle Paths Assignments

You can specify multi-cycle path assignments by identifying the start point and end point groups and then applying a FROM TO constraint for that path. For elements controlled by clock enables, use a TNM_NET on the clock enable to identify all of the elements. You can specify timing requirements as a function of the clock. Be aware of your specified units on the originating TSid. If in "MHz", "*" used as multiplication will make the new clock specification faster, if in "ns", "*" will make new clock specification slower.

TIMESPEC “TSid” = FROM “from_grp” TO “to_grp” TS_01*2;

Slow or Fast Exception Paths

Specify slow or fast path assignments by identifying the start point and end point groups and then applying a FROM TO constraint with a specific value for that path.

TIMESPEC “TSid” = FROM “from_grp” TO “to_grp” value units;

False Paths by Path

Create groups, specify the FROM TO constraint, and then use TIG as the path value.

TIMESPEC “TSid” = FROM “from_grp” TO “to_grp” TIG;

Special Case Path Constraining

Special case path constraining allows you to further refine path specifications or define asynchronous points as a path endpoint. TPTHRU allows the further refinement of a FROM TO path. With TPSYNC, you can specify an asynchronous point as a path start or end point.

TPTHRU

TPTHRU narrows the paths constrained by a FROM TO constraint. It specifies nets or instances that the paths must pass through. You can specify multiple TPTHRU points for a set of paths.

TPTHRU Syntax:

There are three forms of the TPTHRU syntax: one identifies THRU points that pass through nets, one identifies THRU points through instances and, finally, one identifies THRU points of specific instance pins. Be careful when placing TPTHRU points as they can get subsumed into components and may not resolve uniquely. The use of the KEEP attribute on the net may be needed to preserve the TPTHRU tag.

NET Form (UCF)

NET “net_name” TPTHRU = “thru_name”;

where

net_name is the name of the net the paths pass through
thru_name is the user name for the THRU point

INSTANCE Form (UCF)

INST “inst_name” TPTHRU = “thru_name”;

where

inst_name is the name of the instance the paths pass through
thru_name is the user name for the THRU point

Pin Form (UCF)

PIN “instance.pin_name” TPTHRU = “thru_name”;

where

instance.pin_name is the name of the specific instance pin the paths pass through
thru_name is the user name for the THRU point

FROM THRU TO Syntax (UCF):

TIMESPEC “TSid” = FROM “from_grp” THRU “thru_point” TO “to_grp” value units;

where

id is a user specified unique identifier for the constraint
from_grp and to_grp are TIMEGRPs
thru_point is specified by the TPTHRU tag
value is a number or a (*,/) function of another TSid (i.e. TS_01 *2) or a TIG
units is (ms, us, ns (default) or ps)

You can specify multiple sequential THRU points for any FROM TO specification.

TPSYNC

TPSYNC identifies asynchronous points in the design as endpoints for paths. You may want to use TPSYNC when specifying timing to a non-synchronous point in a path, such as a TBUF or to black box macro pins. You can identify non-synchronous elements or pins as a group, and then use either FROM or TO points.

TPSYNC Syntax:

INST “inst_name” TPSYNC = “tpsync_name”;

PIN “inst_name.pin_name” TPSYNC = “tpsync_name”;

where

tpsync_name represents the user label for the group that is created by the TPSYNC statement.
pin_name must match the name used in the HDL code or from the library.

Output Slew Rate Constraint

You can use a slew rate of FAST in architectures that support this feature. Outputs are defined as SLOW by default. You can speed up timing by using the FAST property, but this may cause ringing or noise problems.

Following is the slew rate syntax:

INST “pad_inst_name” FAST;

NET “pad_net_name” FAST;

where

pad_inst_name is the name of the pad instance
pad_net_name is the name of the pad net. (The port name in HDL code.)

Path Coverage Statistics

A connection is a driver/load pin combination, which is connected by a signal. There are situations where connections are not valid or do not show up in the coverage statistic.

Ignored Paths (TIG)

The most common reason for connection coverage not hitting 100% is that elements in the design have NET TIGs. If the timing tool encounters a TIG’d element when tracing a path, the trace will stop there, possibly leaving connections on the "other side" of the element uncovered. On the other hand, a FROM TO TIG on a path will have all of its connections accounted for in the coverage statistic as those paths are enumerated in the timing report.

STARTUP Paths

There are other reasons for less than 100% coverage. One is that the total number of connections in a design includes some which cannot be covered by constraints. An example is the connections on the STARTUP component.

Static Paths

A static pin can drive a LUT which combines with no other signals and then drives other logic. This can happen at the start of a carry chain where a FORCE mode is used from a logic 1 or 0.

Also if terms for carry logic are connected to a CLB, but are not used within the CLB, these connections will never be traced. These are just obscure cases that are not handled.

Path Tracing Controls

Certain categories of paths are turned off using path tracing controls. Paths that are turned off due to path tracing controls will not be covered. See the ENABLE constraint for more information.

OFFSETs with Derived or Gated Clocks

If the clock that clocks a synchronous element does not come through an input pad -- for example, it is derived from another clock -- then OFFSET will fail to return any paths. Use FROM TOs for these paths, taking into account the clock delay.

Following is an example for pad to setup:

If the global clock delay is 1 ns and the Pad to Setup requirement is 30 ns, then identify the PADs and registers that are clocked by a derived or gated clock and group them accordingly. Then create a similar timing constraint to the following:

TIMESPEC “TS_P2S_halfclock” = FROM “halfclock_pads” TO “halfclock_ffs” 31 ns;