Setting Timing Constraints

You can define timing specifications for your design in the User Constraints File (UCF). The UCF gives you tight control of the overall specifications by giving you access to more types of constraints; the ability to define precise timing paths; and the ability to prioritize signal constraints. Furthermore, you can group signals together to simplify timing specifications. Some synthesis tools translate certain synthesis constraints to Xilinx implementation constraints. The translated constraints are placed in a special TIMESPEC component. For more information on timing specifications in the UCF file, refer to the Quick Start Guide for Xilinx Alliance Series, the Libraries Guide, and the Answers Database on the Xilinx Web site (http://www.xilinx.com).

Naming and Grouping Signals Together

You can name and group signals with TNMs (Timing Names) or with TIMEGRPs (Time groups). TNMs and TIMEGRPs are placed on these start and end points: ports, registers, latches, or synchronous RAMs. The new specification, TPSYNC, allows you to define an asynchronous node for a timing specification.

TNMs

Timing Names are used to identify a port, register, latch, RAM, or groups of these components for timing specifications. TNMs are specified from a UCF with the following syntax.

INST Instance_Name TNM=TNM_Name;

Instance_Name is the name given to the port, register, latch, or RAM in your design. The instance names for any port or instantiated component are provided by you in your HDL code. Inferred flip-flops and latch names can usually be determined from the log files. TNM_NAME is the arbitrary name you give the timing group.

You can include several of these statements in the UCF file with a common TNM_NAME to group elements for a timing specification as follows.

NET DATA TNM=INPUT_PORTS;

NET SELECT TNM=INPUT_PORTS;

The above example takes two ports, DATA and SELECT, and gives them the common timing name INPUT_PORTS.

TIMEGRPs

Time Groups are another method for specifying a group of components for timing specifications.

Time groups use existing TNMs or TIMEGRPs to create new groups or to define new groups based on the output net that the group sources. There are several methods to create TIMEGRPs in the UCF file, as follows.

TIMEGRP TIMEGRP_Name=TNM1:TNM2;

TIMEGRP TIMEGRP_Name=TNM3:EXCEPT:TNM4;

The Xilinx software recognizes the following global timing names.

• FFS - All flip-flops in your design
  
  
• PADS - All external ports in your design
  
  
• RAMS - All synchronous RAMs in your design
  
  
• LATCHES - All latches in your design
  
  

The following time group specifies the group name, FAST_FFS, which consists of all flip-flops in your design except for the ones with the TNM or TIMEGRP SLOW_FFS attribute.

TIMEGRP FAST_FFS=FFS:EXCEPT:SLOW_FFS;

TPSYNC Specification

In the latest version of the Xilinx software, you can define any node as a source or destination for a timing specification with the TPSYNC keyword. In synthesis designs, it is usually difficult to identify the net names for asynchronous paths of inferred logic. These net names can change from compile to compile, so it is not recommended to use this specification with inferred logic. However, with instantiated logic, the declared SIGNAL or WIRE name usually remains intact in the netlist and does not change from compile to compile. Some synthesis tools can preserve the signal/net name defined in the RTL through the optimization process. Check with your synthesis vendor for this capability. The UCF syntax is as follows.

NET Net_Name TPSYNC=TPSYNC_Name;

In the following NET statement, the TPSYNC is attached to the output net of a 3-state buffer, 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.

NET BUS3STATE TPSYNC=bus3;

TIMESPEC TSNewSpc3=FROM:PAD(ENABLE_BUS):TO:bus3:20ns;

Specifying Timing Constraints

After your design signals are specified with TNMs, TIMEGRPs, or global timing names, you can place a specification on the design paths. There are a few methods for specifying these timing paths and different specifications have different priorities.

Note: Current versions of the Xilinx implementation tools have improved methods for entering timing constraints. Refer to the Xilinx documentation for your version of the place and route tools for the latest constraints commands and styles.

Period Constraint

The Period constraint specifies a clock period or clock speed on a net or clock port. The Xilinx tools attempt to meet all Pad to Setup requirements, as well as all Clock to Setup delays for registers clocked by the specified clock net. This is equivalent to a create clock type of command in a synthesis tool script. Following are the two methods for specifying a period constraint.

NET Clock_Name PERIOD = Clock_Period ;

or

NET Clock_Name TNM=TNM_Name;

TIMESPEC TIMESPEC_Name = PERIOD:TNM_Name:Clock_Period ;

The following example specifies that the CLOCK port has a period of 50ns. All input paths to flip-flops clocked with this port are designated to operate at 50ns.

NET CLOCK PERIOD = 50;

FROM:TO Style Constraint

Specific paths can be specified with a FROM:TO style timing specification. These constraints are specified using global timing names, TNMs, TIMEGRPs, or TPSYNCs to connect the source and destination of the timing path, as well as the desired maximum delay of the path. An equivalent synthesis tool command is a set max delay type of command. A UCF example follows.

TIMESPEC TIMESPEC_Name =

FROM:Source_Name:TO:Desination_Name:Delay_Value ;

TIMESEPC_Name is specified with the TS identifier followed by a number, such as TS01.

The following example specifies a new timespec with the identifier TS01 so that all paths that are sourced by a port and end at a register grouped with the name DATA_FLOPS have a delay less than 30ns.

TIMESPEC TS01 = FROM:PADS:TO:DATA_FLOPS:30;

Offset Constraint

Note: The OFFSET constraint must be used with the clock PERIOD constraint.

The OFFSET constraint can be applied to ports defined in your code. 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 this constraint. This constraint is equivalent to the set input delay and set output delay type of commands in your synthesis tool.

NET Port_Name OFFSET = {IN | OUT} Time {BEFORE | AFTER} Clock_Name ;

IN | OUT specifies that the offset is calculated with respect to an input IOB or an output IOB.

For a bidirectional IOB, the IN | OUT syntax lets you specify the flow of data (input or output) on the IOB. BEFORE | AFTER indicates whether data is to arrive (input) or leave (output) the device before or after the clock input.

The following example specifies that the data on the output port, DATA_OUT, arrive on the output pin 20ns after the edge of the clock signal, CLOCK, arrives.

NET DATA_OUT OFFSET = OUT 20 AFTER CLOCK;

Ignoring Timing Paths

When a timespec is issued for a path that is not timing-critical, you can specify to ignore this path for one or all timing specifications. A TIG (Timing IGnore) can be specified on these particular nets. The synthesis tool equivalent is the Set False Path command. The UCF syntax is as follows.

NET Signal_Name TIG=TIMESPEC_Name ;

To ignore all timing constraints for a signal:

NET Signal_Name TIG;

To ignore an entire timing constraint:

TIG=TIMESPEC_Name;

In the following example, the SLOW_PATH net is set to ignore the timing constraint with the name TS01.

NET SLOW_PATH TIG=TS01;

Controlling Signal Skew

You can control the maximum allowed skew in your designs. The maximum skew (MAXSKEW) is the difference between the longest and shortest driver-to-load connection delays for a given net. The maximum and minimum delays are determined using worst case maximum delay values for each path. While this specification cannot guarantee that this maximum skew value is achieved in the actual device, it allows the software to minimize the amount of skew on the specified signal. This specification is useful for high-fanout nets when all available global buffers have been used for other critical signals. An example of the UCF syntax for this specification follows.

NET Signal_Name MAXSKEW=Skew_Value ;

The following example specifies that the CLOCK_ENABLE signal should not have a skew value greater than 4ns.

NET CLOCK_ENABLE MAXSKEW=4;

Timing Constraint Priority

Timing constraints can be assigned priorities when paths are overlapped by multiple timing constraints. Priorities can be directly specified to a timing constraint as follows.

TIMESPEC TIMESPEC_Name = FROM Group1 TO Group2

Delay_Value PRIORITY Priority_Level;

The lower the priority_level, the higher the precedence.

The following example sets a timespec where the source is a time group labeled THESE_FFS and the destination is labeled THOSE_FFS, with a delay value of 25ns and a priority level of 2.

TIMESPEC TS04=FROM:THESE_FFS:TO:THOSE_FFS:25 PRIORITY 2;

However, timing constraints have an inherent precedence that is based on the type of constraint and the site description provided to the tools. If two constraints are of the same priority and cover the same path, then the last constraint in the constraint file overrides any other constraints that overlap.

Inherent timing constraint priority is shown in the following table.

Note: You cannot assign a priority to override inherent timing constraint priority. You can set priorities for different timing within the same constraint type.

Table 3_1 Precedence of Constraints