Case Analysis - 2021.2 English

Vivado Design Suite User Guide: Using Constraints (UG903)

Document ID
UG903
Release Date
2021-11-17
Version
2021.2 English

In some designs, certain signals have a constant value in specific modes. For instance, in functional modes, the test signals do not toggle and are therefore tied either to VDD or VSS depending on their active level. This also applies to signals that do not toggle after the design has been powered up. In the same way, today's designs have multiple functional modes and some signals that are active in some of the functional modes might be inactive in other modes.

To help reduce the analysis space, runtime and memory consumption, it is important to let the Static Timing Engine know about the signals that have a constant value. This is also critical to ensure that non-functional paths and irrelevant paths are not reported.

A signal is declared as inactive to the timing engine with the set_case_analysis command. The command applies to pins and/or ports.

Note: After a case analysis is set on a pin, the timing arcs related to that pin are disabled. The timing engine does not report any path going through disabled timing arcs.
Video: For training on the advanced timing exceptions, including set_case_analysis, see the Vivado Design Suite QuickTake Video: Advanced Timing Exceptions - False Path, Min-Max Delay and Set_Case_Analysis.

The syntax of the set_case_analysis command is:

set_case_analysis <value> <pins or ports objects>

The parameter <value> can be any of the following:

0, 1, zero, one, rise, rising, fall, or falling

When the values rise, rising, fall, or falling are specified, this means that the given pins or ports should only be considered for timing analysis with the specified transition. The other transition is disabled.

A case value can be set on a port, a pin of a leaf cell, or a pin of a hierarchical module.

In the example below, two clocks are created on the input pins of the multiplexer clock_sel but only clk_2 is propagated through the output pin after setting the constant value on the selection pin S.

Figure 1. Clock Example

create_clock -name clk_1 -period 10.0 [get_pins clock_sel/I0] 
create_clock -name clk_2 -period 15.0 [get_pins clock_sel/I1] 
set_case_analysis 1 [get_pins clock_sel/S]

In the example below, the BUFG_GT has a dynamic clock division as its DIV[2:0] pins driven by some logic instead of being tied to VCC/GND.

Figure 2. BUFG_GT/DIV Example

In such case, the tool assumes the worst possible scenario for the output clock (divide by 1) and propagates the incoming clock to the buffer output. This worst-case scenario might be pessimistic and over-constrain the design if a clock division of 1 is never exercised. It is possible to control the auto-generated clock on the BUFG_GT output pin by setting the DIV[2:0] bus with a set_case_analysis constraint.

For example, if the worst-case clock divider is by 3, then the following case analysis should be applied to the BUFG_GT:

set_case_analysis 0 [get_pins bufg_gt_pclk/DIV[0] ] 
set_case_analysis 1 [get_pins bufg_gt_pclk/DIV[1] ] 
set_case_analysis 0 [get_pins bufg_gt_pclk/DIV[2] ]
Note: For UltraScale™ and UltraScale+™ devices, the GT_CHANNEL has multiple input clocks that propagate to the output of the GT_CHANNEL (such as TXOUTCLK) through multiple levels of internal muxes. The case analysis can be used in a similar way on the GT_CHANNEL clock muxing control signals (such as TXSYSCLKSEL, TXOUTCLKSEL) to select which of the input or internal clocks should be propagated to the output of the GT_CHANNEL.