Timing Constraints

This section describes the syntax for using timing constraints in a UCF file. Timing constraints allow you to specify the maximum allowable delay or skew on any given set of paths or nets in your design.

There are three steps for applying timing specifications to a design.

1. Add TNM attributes to symbols on your schematic to group them into sets. This step is not necessary if you are using only predefined sets. This step can be performed in the schematic or in a constraints file. See the “Entering Timing Specifications” section in the Development Systems Reference Guide for instructions.
   
   
2. Add a TIMEGRP symbol and add attributes to the symbol. These attributes can combine the sets defined in step 1 or by pattern matching into additional, more complex, sets, or they can match patterns. This step is optional. You can define these groups on the schematic or in the constraints file.
   
   
3. Add a TIMESPEC symbol and add attributes to the symbol, defining the timing requirements for the sets defined in steps 1 and 2. You can define the timing requirements on the schematic or in the constraints file.
   
   

TNM Attributes

Timing name (TNM) attributes can be used to identify the elements that make up a group and give them a name that can later be used in an actual timing specification. The value of the attribute can take several forms and there are several attachment mechanisms by which the attribute can identify the elements that make up a group.

TNM attributes can be attached to a net, an element pin, a primitive, or a macro.

TNMs on Nets

The TNM attribute can be placed on any net in the design. It is used to indicate 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, latch, RAM or pad. TNMs do not propagate across IBUFs if they are attached to the input pad net. (Use TNM_NET if you want to trace forward from an input pad net.)

TNMs on Macro or Primitive Pins

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. It is used to indicate 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, latch, RAM or pad.

TNMs on Primitives

Attaching a TNM attribute directly to a primitive defines that primitive as part of the named group.

TNMs on Macro Symbols

A TNM attribute attached to a macro indicates that all elements inside the macro (at all levels of hierarchy below the tagged macro) are part of the named group.

TIMEGRP Constraints

It is sometimes convenient to use existing TNMs to create new groups or to define a group based on the output nets that the group sources. A set of grouping mechanisms has been created to do this. The Timing Group primitive (TIMEGRP) serves as the host for these attributes. Because they contain no keyword, the attributes make no sense when used alone.

You can either attach a TIMEGRP constraint to the TIMEGRP schematic symbol or specify it with the TIMEGRP keyword in the UCF file. In the UCF file, the statement syntax is as follows.

TIMEGRP timegrp_name=timegrp_parameter

where timegrp_parameter is identical to the text you would attach to the TIMEGRP schematic symbol.

You can create groups using the following four methods.

1. Combine multiple groups into one; use the following syntax.
   
   new_group=group1: group2:... groupn
   
   where new_group is the group being defined; group1, group2, and so forth can be a valid TNM-defined group, predefined group (FFS, PADS, RAMS, LATCHES), or group defined with another TIMEGRP attribute. You can create a time group attribute that references another TIMEGRP attribute that appears after the initial definition. Do not use reserved words such as FFS, PADS, RISING, FALLING, or EXCEPT as group names.
   
   Example
   
   

   	Schematic	NEWGRP=OLD1:OLD2
   	UCF	TIMEGRP NEWGRP=OLD1:OLD2 ;

   
   
   
   
2. Create groups by exclusion; use the following syntax.
   
   new_group=group1:EXCEPT group2
   
   where new_group is the group being defined; group1 and group2 can be a valid TNM-defined group, predefined group (FFS, PADS, RAMS, LATCHES), or group defined with another TIMEGRP attribute. Do not use reserved words such as FFS, PADS, RISING, FALLING, or EXCEPT as group names.
   
   Example
   
   

   	Schematic	FFGRP2=FFS:EXCEPT FFGRP1
   	UCF	TIMEGRP FFGRP2=FFS:EXCEPT FFGRP1 ;

   
   
   
   You can also specify multiple groups to include or exclude when creating the new group.
   
   new_group=group1:group2:EXCEPT group3:... groupn
   
   where group1, group2, group3, and groupn can be a valid TNM-defined group, predefined group (FFS, PADS, RAMS, LATCHES), or group defined with another TIMEGRP attribute. Do not use reserved words such as FFS, PADS, RISING, FALLING, or EXCEPT as group names.
   
   
3. Define groups of flip-flops triggered by rising and falling clock edges; use the following syntax.
   
   new_group={RISING | FALLING group | ffs}
   
   where group must be a group that includes only flip-flops. FFS is a predefined group.
   
   Example
   
   Defining a group of flip-flops that switch on the falling edge of the clock.
   
   

   	Schematic	newfall=FALLING ffs
   	UCF	TIMEGRP newfall=FALLING ffs ;

   
   
   
   
4. Use wildcard characters to define groups of symbols whose associated signal names match a specific pattern; use this syntax.
   
   

group=predefined_group pattern

where predefined_group can be one of the following predefined groups: FFS, PADS, RAMS, LATCHES.

pattern is the string characterizing the output net names of the blocks that you want to include in the new group. It can be any string of characters used with one or more wildcard characters, which can be either of the following.

An asterisk (*) matches any string of zero or more characters.

A question mark (?) matches one character.

Example

Group created by pattern matching.

TIMESPEC Constraints

After you have defined appropriate groups by attaching TNM attributes to symbols and, optionally, by combining these groups using the TIMEGRP symbol, the next step is to add the timing specifications to the constraints file with the TSidentifier constraint. You can define these timing requirements by the following means.

The actual timing specifications take the form of attributes that are attached to a timing specification (TIMESPEC) primitive. The TIMESPEC primitive acts as a place to attach attributes and keeps the attributes together. More than one TIMESPEC primitive can be used in a design at any level of the hierarchy.

The sources and destinations can be any synchronous point in the design. The timing allowance specified is used explicitly by the timing analysis tools. There is no hidden accounting for any clock inversions between registers clocked by the same clock, etc.

If paths are not specified, they are ignored for the purposes of timing analysis. The forms described here require the definition of a source and a destination for a specification.

Basic Form

Syntax for defining a maximum allowable delay is as follows.

TSidentifier=FROM:source_group:TO:dest_group allowable_delay[units]

where

identifier is an ASCII string made up of the characters A...Z, a...z, 0...9.

source_group and dest_group are user-defined or predefined groups.

allowable_delay is the timing requirement.

units is an optional field to indicate the units for the allowable delay. Default units are nanoseconds, but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or kHz to indicate the intended units.

In a schematic the timespec attribute is attached to the TIMESPEC symbol.

Defining Intermediate Points on a Path

It is sometimes convenient to define intermediate points on a path to which a specification applies. This defines the maximum allowable delay and has the following syntax.

TSidentifier=FROM:source_group THRU thru_point[THRU thru_point1... thru_pointn]:TO:dest_group allowable_delay[units]

where

identifier is an ASCII string made up of the characters A...Z, a...z, 0...9.

source_group and dest_group are user-defined or predefined groups.

thru_point is an intermediate point used to qualify the path, defined using a TPTHRU attribute.

allowable_delay is the timing requirement.

units is an optional field to indicate the units for the allowable delay. Default units are nanoseconds, but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or kHz to indicate the intended units.

Worst Case Allowable Delay (MAXDELAY)

Syntax for maximum delay is as follows.

TSidentifier=MAXDELAY FROM:source_group:TO:dest_group allowable_delay[units]

Syntax for maximum delay using a through point is as follows.

TSidentifier=MAXDELAY FROM:source_group THRU thru_point [THRU thru_point1... thru_pointn]:TO:dest_group allowable_delay[units]

where

identifier is an ASCII string made up of the characters A...Z, a...z, 0...9.

source_group and dest_group are user-defined or predefined groups.

thru_point is an intermediate point used to qualify the path, defined using a TPTHRU attribute.

allowable_delay is the timing requirement.

units is an optional field to indicate the units for the allowable delay.

Linked Specifications

This allows you to link the timing number used in one specification to another specification in terms of fractions or multiples.

NOTE

Circular links are not allowed.

Syntax is as follows.

TSidentifier=FROM:source_group:TO:dest_group another_Tsid [/ | *]number

where

identifier is an ASCII string made up of the characters A...Z, a...z, 0...9.

source_group and dest_group are user-defined or predefined groups.

another_Tsid is a the name of another timespec.

number is a floating point number.

Defining Priority for Equivalent Level Specifications

A conflict between two specifications at the same level of priority can be resolved by defining their priority. You can do this by adding the following text to each of the conflicting specifications.

normal_timespec_syntax PRIORITY integer

where

normal_timespec_syntax is the timing specification.

integer represents the priority. The smaller the number, the higher the priority.

Ignoring Paths

Paths exercising a certain net can be ignored because from a timing specification point of view, all paths through a net, instance, or instance pin may not be important.

Syntax is as follows.

TIG=TSidentifier

where identifier is the timing specification name of the specific timespec for which any paths through the tagged object should be ignored. The attribute can be attached to a net, macro pin or primitive pin. Paths that fan forward from the attribute's point of application are treated as if they don't exist from the viewpoint of timing analysis against the timing specification.

Examples

The following attribute would be attached to a net to inform the timing analysis tools that it should ignore paths through the net for specification TS43.

TIG=TS43

The following attribute would be created in a UCF file to inform the timing analysis tools that it should ignore paths through the net $1I567/sometimes_slow for specification TS_fast and TS_really_fast.

NET $1I567/sometimes_slow TIG=TS_fast , TS_really_fast;

Ignoring Paths Through Primitives

The tracing rules for how PAR's timing analysis handles the traversal of primitives are the same as those used for user driven timing analysis. If a user wishes to override the default behavior for an element, the element can be tagged with an override attribute in the PCF file. For more information, see the “Ignoring Selected Paths (TIG)” section in the Development System Reference Guide.

Defining a Clock Period

A clock period specification is used to define to the timing analysis tools the allowable time for paths between elements clocked by the flagged clock signal.

NOTE

The definition of a clock period is different from a FROM:TO style specification, because the timing analysis tools will automatically take into account any inversions of the clock signal at register clock pins.

There are two methods for specifying clock periods.

1. The quick, convenient way to define the clock period for registers attached to a particular clock net is to attach the following parameter directly to a net in the path that drives the register clock pin(s).
   
   PERIOD=period[units] [{HIGH | LOW} [high_or_low_time [hi_lo_units]]]
   
   where
   
   period is the required clock period.
   
   units is an optional field to indicate the units for the clock period. The default units are nanoseconds, but the timing number can be followed by ps, ns, us, or ms to indicate the intended units.
   
   HIGH or LOW can be optionally specified to indicate whether the first pulse is to be High or Low.
   
   high_or_low_time is the optional High or Low time depending on the preceding 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%.
   
   hi_lo_units is an optional field to indicate the units for the duty cycle. The default is nanoseconds (ns), but the High or Low time number can be followed by ps, us, ms, or % if the High or Low time is an actual time measurement.
   
   The PERIOD constraint is forward-traced in exactly the same fashion as 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 you need a more complex form of tracing behavior, for example, where gated clocks are used in the design, you must place the PERIOD on a particular net, or use the preferred method as described in the following paragraphs.
   
   
2. The 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[units][{HIGH | LOW} [high_or_low_time [hi_lo_units]]]

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.

period is the required clock period.

units is an optional field to indicate the units for the clock period. Default units are nanoseconds, but the timing number can be followed by ps, ns, us, or ms to indicate the intended units.

HIGH or LOW can be optionally specified to indicate whether the first pulse is to be High or Low.

high_or_low_time is the optional High or Low time depending on the preceding 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 percent.

hi_lo_units is an optional field to indicate the units for the duty cycle. The default is ns, but the High or Low time number can be followed by ps, ns, us, ms, or % if the High or Low time is an actual time measurement.

Example

Clock net sys_clk has the attribute tnm=master_clk attached to it and the following attribute is attached to a TIMESPEC primitive.

TS_master=PERIOD master_clk 50 HIGH 30

Specifying Derived Clocks

The preferred method of defining a clock period uses an identifier, allowing another clock period specification to reference it. To define the relationship in the case of a derived clock, use the following syntax.

TSidentifier=PERIOD TNM_reference another_PERIOD_identifier [/ | *] number [{HIGH | LOW} [high_or_low_time [hi_lo_units]]]

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.

another_PERIOD_identifier is a the name of the identifier used on another period specification.

number is a floating point number.

HIGH or LOW can be optionally specified to indicate whether the first pulse is to be High or Low.

high_or_low_time is the optional High or Low time. This must be less than the period, depending on the preceding keyword. The default duty cycle is 50 percent.

hi_lo_units is an optional field to indicate the units for the duty cycle. The default is nanoseconds (ns), but the High or Low time number can be followed by ps, us, ms, or % if the High or Low time is an actual time measurement.

Example

Clock net sub_clk has the attribute tnm=slave_clk attached to it and the following attribute is attached to a TIMESPEC primitive.

ts_slave1=PERIOD slave_clk master_clk * 4

Controlling Net Skew

You can control the maximum allowable skew on a net by attaching the MAXSKEW attribute directly to the net. Syntax is as follows.

MAXSKEW=allowable_skew [units]

where

allowable_skew is the timing requirement.

units is an optional field to indicate the units for the allowable delay. Default units are nanoseconds, but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or kHz to indicate the intended units.

Controlling Net Delay

You can control the maximum allowable delay on a net by attaching the MAXDELAY attribute directly to the net. Syntax is as follows.

MAXDELAY=allowable_delay [units]

where

allowable_delay is the timing requirement.

units is an optional field to indicate the units for the allowable delay. Default units are nanoseconds, but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or kHz to indicate the intended units.