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.
set_case_analysis
command. The command applies to pins
and/or ports.1
on a non-inverted pin is
equivalent to a case analysis value of 0
if the pin
is inverted (property IS_INVERTED=1
), and vice
versa. Vivado does not adjust the case analysis value based on the optional pin
inversion. It is the responsibility of the user to specify the correct case analysis
value. If the pin is inverted after the case analysis constraint is applied, the
case analysis value must be adjusted accordingly by the user.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
.
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.
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] ]
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.BUFGCTRL Example
S0
and S1
:set_case_analysis 0 [get_pins <BUFGCTRL/S0>]
set_case_analysis 1 [get_pins <BUFGCTRL/S1>]
The input pin S0
is driven by an inverter:
BUFGCTRL/S0
during some optimization, the case analysis value should
be updated by the user to account for the inversion on the input pin S0
:set_case_analysis 0 [get_pins <BUFGCTRL/S0>]