setting up clocks, specifying IO timing characteristics, and specifying false paths and multicycle paths
1.Specifying Clocks
create_clock
set_clock_transition：This specification applies only for ideal clocks and is disregarded once the clock trees are built。
set_clock_uncertainty：The uncertainty can be used to model various factors that can reduce the effective clock period. These factors can be the clock jitter and any other pessimism that one may want to include
for timing analysis.Note that the clock uncertainty for setup effectively reduces the available clock period by the specified amount as illustrated in Figure 7-7. For hold checks, the clock
uncertainty for hold is used as an additional timing margin that needs to be satisfied。
clock uncertainty 里面对建立时间的检查需要考虑时钟抖动，而对保持时间检查时不需要考虑时钟抖动，知道为啥吗？呵呵。
set_clock_latency：There are two types of clock latencies: network latency and source latency. Network latency is the delay from the clock definition point (create_clock) to
the clock pin of a flip-flop. Source latency, also called insertion delay, is the delay from the clock source to the clock definition point. Source latency
could represent either on-chip or off-chip latency. Figure 7-9 shows both the scenarios. The total clock latency at the clock pin of a flip-flop is the
sum of the source and network latencies.
Here are some example commands that specify source and network latencies.
# Specify a network latency (no -source option) of 0.8ns for
# rise, fall, max and min:
set_clock_latency 0.8 [get_clocks CLK_CONFIG]
# Specify a source latency:
set_clock_latency 1.9 -source [get_clocks SYS_CLK]
# Specify a min source latency:
set_clock_latency 0.851 -source -min [get_clocks CFG_CLK]
# Specify a max source latency:
set_clock_latency 1.322 -source -max [get_clocks CFG_CLK]
One important distinction to observe between source and network latency is that once a clock tree is built for a design, the network latency
can be ignored (assuming set_propagated_clock command is specified). However, the source latency remains even after the clock tree is built.
The network latency is an estimate of the delay of the clock tree prior to clock tree synthesis. After clock tree synthesis, the total clock
latency from clock source to a clock pin of a flip-flop is the source latency plus the actual delay of the
clock tree from the clock definition point to the flip-flop.
create_generated_clock：A generated clock is a clock derived from a master clock. A master clock is a clock defined using the create_clock specification.For example, if there is a
divide-by-3 circuitry for a clock, one would define a generated clock definition at the output of this circuitry.This definition is needed as STA does
not know that the clock period has changed at the output of the divide-by logic, and more importantly what the new clock period is.Can a new clock, that is, a
master clock, be defined at the output of the flipflop instead of a generated clock? The answer is yes, that it is indeed possible. However, there are some disadvantages. Defining a
master clock instead of a generated clock creates a new clock domain. This is not a problem in general except that there are more clock domains to deal with
in setting up the constraints for STA. Defining the new clock as a generated clock does not create a new clock domain, and the generated clock is considered
to be in phase with its master clock. Another important difference between a master clock and a generated
clock is the notion of clock origin. In a master clock, the origin of the clock is at the point of definition of the master clock. In a generated clock, the
clock origin is that of the master clock and not that of the generated clock. This implies that in a clock path report, the start point of a clock path is always the master clock
definition point. This is a big advantage of a generated clock over defining a new master clock as the source latency is not automatically included for the case of a new master clock.
create_clock -period 10 -waveform {0 5} [get_ports MIICLK]
create_generated_clock -name MIICLKDIV2 -source MIICLK \
-edges {1 3 5} [get_pins UMIICLKREG/Q]
# Create a divide-by-2 clock.
create_generated_clock -name MIIDIV2 -source MIICLK \
-edges {1 1 5} -edge_shift {0 5 0} [get_pins UMIIDIV/Q]
# Creates a divide-by-2 clock with a duty cycle different
# from the source clock's value of 50%.
Clock Latency for Generated Clocks：Clock latencies can be specified for generated clocks as well. A source latencyspecified on a generated clock specifies the latency from the definition
of the master clock to the definition of the generated clock. The total clock latency to a clock pin of a flop-flop being driven by a generated clockis thus the sum of the source latency of
the master clock, the source latency of the generated clock and the network latency of the generated clock. This is shown in Figure 7-19.
A generated clock can have another generated clock as its source, that is, one can have generated clocks of generated clocks, and so on. However, a
generated clock can have only one master clock.
Typical Clock Generation Scenario：Figure 7-20 shows a scenario of how a clock distribution may appear in a typical ASIC. The oscillator is external
to the chip and produces a low frequency (10-50 MHz typical) clock which is used as a reference clock by the on-chip PLL to generate a high-frequency
low-jitter clock (200-800 MHz typical). This PLL clock is then fed to a clock divider logic that generates the required clocks for the ASIC.
2.Constraining Input Paths
This section describes the constraints for the input paths. The important point to note here is
that STA cannot check any timing on a path that is not constrained. Thus, all paths should be
constrained to enable their analysis.
The clock definition for CLKA specifies the clock period, which is the total amount of time available between the two flip-flops UFF0 and UFF1. The
time taken by the external logic is Tclk2q, the CK to Q delay of the launch flip-flop UFF0, plus Tc1, the delay through the external combinational logic.
Thus, the delay specification on an input pin INP1 defines an external delay of Tclk2q plus Tc1. This delay is specified with respect to a clock,
CLKA in this example.
Here is the input delay constraint.
set Tclk2q 0.9
set Tc1 0.6
set_input_delay -clock CLKA -max [expr Tclk2q + Tc1] \
[get_ports INP1]
The constraint specifies that the external delay on input INP1 is 1.5ns and this is with respect to the clock CLKA. Assuming the clock period for CLKA
is 2ns, then the logic for INP1 pin has only 500ps (= 2ns - 1.5ns) available for propagating internally in the design. This input delay specification
maps into the input constraint that Tc2 plus Tsetup of UFF1 must be less than 500ps for the flip-flop UFF1 to reliably capture the data launched by
flip-flop UFF0. Note that the external delay above is specified as a max quantity.
Let us consider the case when we want to consider both max and min delays, as shown in Figure 7-22. Here are the constraints for this example.
create_clock -period 15 -waveform {5 12} [get_ports CLKP]
set_input_delay -clock CLKP -max 6.7 [get_ports INPA]
set_input_delay -clock CLKP -min 3.0 [get_ports INPA]
The max and min delays for INPA are derived from the CLKP to INPA delays. The max and min delays refer to the longest and shortest path delays
respectively. These may also normally correspond to the worst-case slow (max timing corner) and the best-case fast (min timing corner). Thus, the
max delay corresponds to the longest path delay at the max corner and the min delay corresponds to the
shortest path delay at the min corner. In our
example, 1.1ns and 0.8ns are the max and the min delay values for the Tck2q. The combinational path delay Tc1 has a max delay of 5.6ns and a
min delay of 2.2ns. The waveform on INPA shows the window in which the data arrives at the design input and when it is expected to be stable.
The max delay from CLKP to INPA is 6.7ns (= 1.1ns + 5.6ns). The min delay is 3ns (= 0.8ns + 2.2ns). These delays are specified with respect to the active
edge of the clock. Given the external input delays, the available setup time internal to the design is the min of 8.3ns (= 15ns - 6.7ns) at the slow corner
and 12ns (= 15ns - 3.0ns) at the fast corner. Thus, 8.3ns is the available time to reliably capture the data internal to the DUA.
3.Constraining Output Paths
Example A
The period for the clock CLKQ defines the total available time between the flip-flops UFF0 and UFF1. The external logic has a total delay of Tc2 plus
Tsetup. This total delay, Tc2 + Tsetup, has to be specified as part of the output delay specification.
Note that the output delay is specified relative to
the capture clock. Data must arrive at the external flip-flop UFF1 in time to meet its setup requirement.
output delay：在时钟边沿到来之前数据稳定所需要的时间；
input delay：在时钟边沿后数据稳定所需要的时间；
set Tc2 3.9
set Tsetup 1.1
set_output_delay -clock CLKQ -max [expr Tc2 + Tsetup] \
[get_ports OUTB]
This specifies that the max external delay relative to the clock edge is Tc2
plus Tsetup; and should correspond to the delay of 5ns. A min delay can be
similarly specified.
Example B
Figure 7-24 shows an example with both min and max delays. The max path delay is 7.4ns (= max Tc2 plus Tsetup = 7 + 0.4). The min path delay is
-0.2ns (= min Tc2 minus Thold = 0 - 0.2). Therefore the output specifications are:
create_clock -period 20 -waveform {0 15} [get_ports CLKQ]
set_output_delay -clock CLKQ -min -0.2 [get_ports OUTC]
set_output_delay -clock CLKQ -max 7.4 [get_ports OUTC]
The waveforms in Figure 7-24 show when OUTC has to be stable so that it is reliably captured by the external flip-flop. This depicts that the datamust
be ready at the output port before the required stable region starts and must remain stable until the end of the stable region. This maps into a requirement
on the timing of the logic to the output port OUTC inside the DUA.
Example C
Here is another example that shows input and output specifications. This block has two inputs, DATAIN and MCLK, and one output DATAOUT.
Figure 7-25 shows the intended waveforms.
create_clock -period 100 -waveform {5 55} [get_ports MCLK]
set_input_delay 25 -max -clock MCLK [get_ports DATAIN]
set_input_delay 5 -min -clock MCLK [get_ports DATAIN]
set_output_delay 20 -max -clock MCLK [get_ports DATAOUT]
set_output_delay -5 -min -clock MCLK [get_ports DATAOUT]
4.Modeling of External Attributes
For inputs, one needs to specify the slew at the input. This information can be provided using:
• set_drive1
• set_driving_cell
• set_input_transition
For outputs, one needs to specify the capacitive load seen by the output pin. This is specified by
using the following specification:
• set_load
Modeling Drive Strengths
The set_drive and set_driving_cell specifications are used to model the drive strength of the external
source that drives an input port of the block.In absence of these specifications, by default, all inputs are assumed to
have an infinite drive strength. The default condition implies that the transition time at the input pins is 0.
The set_drive explicitly specifies a value for the drive resistance at the input pin of the DUA. The smaller the drive value, the higher the drive strength.
A resistance value of 0 implies an infinite drive strength.
set_drive 100 UCLK
# Specifies a drive resistance of 100 on input UCLK.
# Rise drive is different from fall drive:
set_drive -rise 3 [all_inputs]
set_drive -fall 2 [all_inputs]
The drive of an input port is used to calculate the transition time at the first cell. The drive value specified is also used to compute the delay from the
input port to the first cell in the presence of any RC interconnect.
Delay_to_first_gate =
(drive * load_on_net) + interconnect_delay
The set_driving_cell specification offers a more convenient and accurate approach in describing the drive capability of a port. The set_driving_cell
can be used to specify a cell driving an input port.
set_driving_cell -lib_cell INV3 \
-library slow [get_ports INPB]
# The input INPB is driven by an INV3 cell
# from library slow.
set_driving_cell -lib_cell INV2 \
-library tech13g [all_inputs]
# Specifies that the cell INV2 from a library tech13g is
# the driving cell for all inputs.
Like the drive specification, the driving cell of an input port is used to calculate the transition time at the first cell and to compute the delay from the
input port to the first cell in the presence of any interconnect.
As an alternate to the above approaches, the set_input_transition specification offers a convenient way of expressing the slew at an input port. A
reference clock can optionally be specified. Here is the specification for the example shown in Figure 7-30 along with additional examples.
set_input_transition 0.85 [get_ports INPC]
# Specifies an input transition of 850ps on port INPC.
set_input_transition 0.6 [all_inputs]
# Specifies a transition of 600ps on all input ports.
set_input_transition 0.25 [get_ports SD_DIN*]
# Specifies a transition of 250ps on all ports with
# pattern SD_DIN*.
# Min and max values can optionally be specified using
# the -min and -max options.
In summary, a slew value at an input is needed to determine the delay of the first cell in the input path. In
the absence of this specification, an ideal
transition value of 0 is assumed, which may not be realistic.
Modeling Capacitive Load
The set_load specification places a capacitive load on output ports to model the external load being driven by the output port. By default, the capacitive
load on ports is 0. The load can be specified as an explicit capacitance value or as an input pin capacitance of a cell.
set_load 5 [get_ports OUTX]
# Places a 5pF load on output port OUTX.
set_load 25 [all_outputs]
# Sets 25pF load capacitance on all outputs.
set_load -pin_load 0.007 [get_ports {shift_write[31]}]
# Place 7fF pin load on the specified output port.
# A load on the net connected to the port can be
# specified using the -wire_load option.
# If neither -pin_load nor -wire_load option is used,
# the default is the -pin_load option.
It is important to specify the load on outputs since this value impacts the delay of the cell driving the output. In the absence of such a specification, a
load of 0 is assumed which may not be realistic.
5.Design Rule Checks
Two of the frequently used design rules for STA are max transition and max
capacitance. These rules check that all ports and pins in the design meet the
specified limits for transition time1 and capacitance. These limits can be
specified using:
• set_max_transition
• set_max_capacitance
set_max_transition 0.6 IOBANK
# Sets a limit of 600ps on IOBANK.
set_max_capacitance 0.5 [current_design]
# Max capacitance is set to 0.5pf on all nets in
# current design.
The capacitance on a net is calculated by taking the sum of all the pin capacitances
plus any IO load plus any interconnect capacitance on the net.
There are other design rule checks that can also be specified for a design.
These are: set_max_fanout (specifies a fanout limit on all pins in design),
set_max_area (for a design); however these checks apply for synthesis and
not for STA.
6.Virtual Clocks
A virtual clock is a clock that exists but is not associated with any pin or
port of the design. It is used as a reference in STA analysis to specify input
and output delays relative to a clock.
create_clock -name VIRTUAL_CLK_SAD -period 10 -waveform {2 8}
create_clock -name VIRTUAL_CLK_CFG -period 8 \
-waveform {0 4}
create_clock -period 10 [get_ports CLK_CORE]
set_input_delay -clock VIRTUAL_CLK_SAD -max 2.7 \
[get_ports ROW_IN]
set_output_delay -clock VIRTUAL_CLK_CFG -max 4.5 \
[get_ports STATE_O]
7.Refining the Timing Analysis
Four common commands that are used to constrain the analysis space are:
i. set_case_analysis: Specifies constant value on a pin of a cell, or on
an input port.
ii. set_disable_timing: Breaks a timing arc of a cell.
iii. set_false_path: Specifies paths that are not real which implies that
these paths are not checked in STA.
iv. set_multicycle_path: Specifies paths that can take longer than one
clock cycle.
set_case_analysis
In a design, certain signals have a constant value in a specific mode of the chip. For example, if a chip has DFT logic in it, then the TEST pin of the
chip should be at 0 in normal functional mode. It is often useful to specify such constant values to STA. This helps in reducing the analysis space in
addition to not reporting any paths that are irrelevant. For example, if the TEST pin is not set as a constant, some odd long paths may exist that
would never be true in functional mode. Such constant signals are specified by using the set_case_analysis specification.
If a design has many functional modes and only one functional mode is being
analyzed, case analysis can be used to specify the actual mode to be analyzed.
set_case_analysis 1 func_mode[0]
set_case_analysis 0 func_mode[1]
set_case_analysis 1 func_mode[2]
Note that the case analysis can be specified on any pin in the design. Another common application of case analysis is when the design can run on
multiple clocks, and the selection of the appropriate clock is controlled by multiplexers. To make STA analysis easier and reduce CPU run time, it is
beneficial to do STA for each clock selection separately.Figure 7-36 shows an example of the multiplexers selecting different clocks with different settings.
set_case_analysis 1 UCORE/UMUX0/CLK_SEL[0]
set_case_analysis 1 UCORE/UMUX1/CLK_SEL[1]
set_case_analysis 0 UCORE/UMUX2/CLK_SEL[2]
Breaking Timing Arcs in Cells
Every cell has timing arcs from its inputs to outputs, and a timing path may go through one of these cell arcs. In some situations, it is possible that
a certain path through a cell cannot occur. For example, consider the scenario where a clock is connected to the select line of a multiplexer and the
output of the multiplexer is part of a data path. In such a case, it may be useful to break the timing arc between the select pin and the output pin of
the multiplexer. An example is shown in Figure 7-37. The path through the select line of multiplexer is not a valid data path. Such a timing arc can be
broken by using the set_disable_timing SDC command.
One should use caution when using the set_disable_timing command as it removes all timing paths through the specified pins. Where possible, it is
preferable to use the set_false_path and the set_case_analysis commands.
8.Point-to-Point Specification
Point-to-point paths can be constrained by using the set_min_delay and set_max_delay specifications. These constrain the path delay between the
from-pin and the to-pin to the values specified in the constraint. This constraint overrides any default single cycle timing paths and any multicycle
path constraints for such paths. The set_max_delay constraint specifies the maximum delay for the specified path(s), while the set_min_delay constraint
specifies the minimum delay for the specified path(s).
set_max_delay 5.0 -to UFF0/D
# All paths to D-pin of flip-flop should take 5ns max.
set_max_delay 0.6 -from UFF2/Q -to UFF3/D
# All paths between the two flip-flops should take a
# max of 600ps.
set_max_delay 0.45 -from UMUX0/Z -through UAND1/A -to UOR0/Z
# Sets max delay for the specified paths.
set_min_delay 0.15 -from {UAND0/A UXOR1/B} -to {UMUX2/SEL}
One can also specify similar point-to-point constraints from one clock to
another clock.
set_max_delay 1.2 -from [get_clocks SYS_CLK] \
-to [get_clocks CFG_CLK]
# All paths between these two clock domains are restricted
# to a max of 1200ps.
set_min_delay 0.4 -from [get_clocks SYS_CLK] \
-to [get_clocks CFG_CLK]
# The min delay between any path between the two
# clock domains is specified as 400ps.
If there are multiple timing constraints on a path, such as clock frequency, set_max_delay and set_min_delay, the most restrictive constraint is the one
always checked. Multiple timing constraints can be caused by some global constraints being applied first and then some local constraints applied later.
