Previous

Additional Timing Constraints

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

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,

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

Figure 4.20 MAXSKEW

In the preceding diagram, for ta(1,2), 1 ns is the minimum delay and 2 ns is the maximum delay for the Register A clock. For tb(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 tb minus the maximum of ta, 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, ta=1) while a second register is operating at maximum delay (for example, tb=4). Under those conditions, the skew is 3 ns (tb - ta= 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_value is one of the following,

net_delay_item is one of the following.

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.

The following table describes the standard block delay symbols.

Table 4_1 Standard Block Delay Symbols for Path Tracing

Symbol
Path Type
Default
reg_sr_q
Set/Reset to output propagation delay
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 is somewhat different than the IOB configuration for other architectures. See the following figure.

Figure 4.21 Simplified IOB Configurations and io_t_pad

For the Virtex IOB, 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 TILO 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.

Next