Additional Timing Constraints

Development System Reference GuideChapter 6: Using Timing Constraints

Additional Timing Constraints

There are additional properties and constraints you can specify for the timing analysis tools. They are the following.

Net skew control (MAXSKEW)
Net delay control
Path tracing control
The DROP_SPEC constraint

Controlling Net Skew (MAXSKEW)

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. Syntax is as follows.

skew_item MAXSKEW=allowable_skew [units];

allowable_skew is the timing requirement.

The default units for allowable_skew are nanoseconds, but the timing number can be followed by ps, ns, us, ms, GHz, MHz, or KHz to indicate the intended units.

skew_item is one of the following,

NET “net_name”
TIMEGRP “group_name” (PCF only)
ALLCLOCKNETS (PCF only)

Note: TIMEGRP and ALLCLOCKNETS are supported in PCF files only.

It is important to understand exactly what MAXSKEW defines. Consider the following example.

Figure 6.21 MAXSKEW

In the preceding diagram, for t_a(1,2), 1 ns is the minimum delay and 2 ns is the maximum delay for the Register A clock. For t_b(2,4), 2 ns is the minimum delay and 4 ns is the maximum delay for the Register B clock. MAXSKEW defines the maximum of t_b minus the maximum of t_a, that is, 4-2=2. Since the data delay is greater than MAXSKEW (DD is 2.5 while MAXSKEW is 2), no race condition occurs. However, MAXSKEW does not account for the circumstance where one of the registers is operating at minimum delay (for example, t_a=1) while a second register is operating at maximum delay (for example, t_b=4). Under those conditions, the skew is 3 ns (t_b - t_a= 3). Since the data delay (DD= 2.5) is less than the skew, a race condition exists.

Controlling Net Delay (MAXDELAY)

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

NET net_name MAXDELAY=path_value [PRIORITY integer];

TSidentifier=MAXDELAY= path path_value [PRIORITY integer];

path MAXDELAY=path_value [PRIORITY integer];

net_delay_item MAXDELAY=delay_time [units] [PRIORITY integer];

path is one of the following,

PATH “path_name”
ALLPATHS
FROM group_item THRU group_item1... group_itemn
FROM group_item THRU group_item1... group_itemn TO group_item
THRU group_item1... group_itemn TO group_item

path_value is one of the following,

delay_time [units]

units defaults to nanoseconds, but the delay time number can be followed by ps, ns, us, or ms (picoseconds, nanoseconds, microseconds, or milliseconds) to specify the units
frequency units

units can be specified as GHz, MHz, or KHz (gigahertz, megahertz, or kilohertz)
TSidentifier [{/ |*} real_number]

net_delay_item is one of the following.

NET “net_name”
TIMEGRP “group_name”
ALLCLOCKNETS

Controlling Path Tracing

Path tracing controls allows you to enable or disable specific paths within device components (for example, CLBs and IOBs) for timing analysis. These constraints can only be entered in a PCF file; they cannot be applied during design entry or in a UCF or NCF file.

This constraint can be applied at a global or group scope. The path tracing syntax is as follows.

[TIMEGRP predefined_group] {ENABLE | DISABLE} = symbol;

symbol is a component delay symbol, and predefined_group (which is optional) represents the name of a previously-defined time group. If there is no TIMEGRP predefined_group qualifier, the path tracing control applies to all logic cells in the design.

The symbol, which is case-insensitive, can be either of the following.

A standard component delay symbol name (for example, reg_sr_q or tbuf_i_o, as described in the following table).

There is a one-to-many correspondence between these symbol names and data book symbol names, and the data book symbols to which each standard block delay signal applies varies from one device family to another.
A component delay specified in the Xilinx Programmable Logic Data Book (for example, T_ILO (entered as TILO) or T_CCK (entered as TCCK)).

The following table describes the standard block delay symbols.

Table 6_1 Standard Block Delay Symbols for Path Tracing

Symbol	Path Type	Default
reg_sr_q	Set/Reset to output propagation delay	Disabled
reg_sr_clk	Set/Reset to clock setup and hold checks	Disabled
lat_d_q	Data to output transparent latch delay	Disabled
ram_d_o	RAM data to output propagation delay	Disabled
ram_we_o	RAM write enable to output propagation delay	Enabled
tbuf_t_o	TBUF tristate to output propagation delay	Enabled
tbuf_i_o	TBUF input to output propagation delay	Enabled
io_pad_i	IO pad to input propagation delay	Enabled
io_t_pad	IO tristate to pad propagation delay	Enabled
io_o_i	IO output to input propagation delay. Disabled for tristated IOBs.	Enabled
io_o_pad	IO output to pad propagation delay	Enabled

The IOB configuration for Virtex and Spartan2 is somewhat different than the IOB configuration for other architectures. See the following figure.

Figure 6.22 Simplified IOB Configurations and io_t_pad

For the Virtex and Spartan2 IOBs, there is no default path. If a latch is used (latch mode), then io_t_pad controls the D to Q path through the latch. By default D to Q is enabled which is different than other internal latches. The clock to Q of the latch is not disabled by io_t_pad.

If a register is used instead of a latch, the clock to Q of the register is not disabled by io_t_pad.

Path Tracing Examples

The PCF file constraint below prevents timing analysis on any path that includes the I to O delay on a TBUF component. The constraint applies to all TBUF components in the design.

DISABLE = "tbuf_i_o";

The PCF file constraint below disables the I to O delay on the TBUF components in the group mygroup, if applicable.

TIMEGRP "mygroup" DISABLE = "tbuf_i_o";

The PCF file constraint below disables the T_ILO databook component delay in the group mygroup, if applicable.

TIMEGRP "mygroup" DISABLE = "TILO";

The delay symbol names in the Xilinx Programmable Logic Data Book do not always agree with the delay names reported in TRACE (the Xilinx timing analyzer). To ensure your path tracing constraints are processed correctly and to allow your constraints to be portable from one device to another, use the delay names reported by TRACE instead of the databook names.

You can control path tracing for a single instance by creating a group containing only the instance, then specifying this group in a path tracing constraint.

The DROP_SPEC Constraint

A constraint specified in a UCF constraints file takes precedence over one with the same name in the input design. This allows you to redefine or modify constraints without having to edit the input design. The DROP_SPEC constraint allows you to specify that a timing constraint defined in the input design should be dropped from the analysis. The UCF syntax is as follows.

TS identifier = DROP_SPEC

identifier is the identifier name used with another timing specification. This constraint can be used when new specifications defined in a constraints file do not directly override all specifications defined in the input design, and some of these input design specifications need to be dropped.

While this timing command is not expected to be used much in an input netlist (or NCF file), it is not illegal. If defined in an input design this attribute must be attached to a TIMESPEC primitive.