There are additional properties and constraints you can specify for the timing analysis tools. They are the following.
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,
TIMEGRP and ALLCLOCKNETS are supported in PCF files only.
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.
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.
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.
| 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 ExamplesThe 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.
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.
