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
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:
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
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
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
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 ] set_case_analysis 1 [get_pins bufg_gt_pclk/DIV ] set_case_analysis 0 [get_pins bufg_gt_pclk/DIV ]
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
TXOUTCLKSEL) to select which of the input or internal clocks should be propagated to the output of the GT_CHANNEL.