The Static Timing Analysis (sometimes also referred to as Stability Analysis) is performed upon the UTD timing database. The user must provide a timing constraints file, typically an SDC (Synopsys Design Constraints) file, or its INF equivalent, which should at least provide the two following sets of information:
For the first set of information, clock defintions can be specified with functions create_clock, create_generated_clock and set_clock_latency.
For the second set of information, switching windows for the input connectors must be specified with function set_input_delay. Switching window definition for the inputs is mandatory to allow their propagation throughout the design. In addition, constraints on the output connectors can be specified with the set_output_delay function.
The STA engine is invoked with the function stb, taking as argument a pointer on the timing database (TimingFigure object). A pointer on a TimingFigure object can be obtained as the result of the hitas function. If the timing database has already been created and exists on disk (DTX and STM files), then a pointer on the TimingFigure object can be obtained with the ttv_LoadSpecifiedTimingFigure function. Here is an example of the launch of the STA with a minimal set of constraints:
set fig [ttv_LoadSpecifiedTimingFigure cpu] inf_SetFigureName cpu create_clock -period 900 -waveform {0 450} clk set_input_delay -rise 850 -clock clk * stb $fig |
The stb function first propagates the interface clocks onto the commands of the latches. Then it propagates the switching windows defined on input connectors through the elements of the database, either combinational or sequential, over one clock cycle.
When propagating through combinational elements (gates), stb calculates the switching window on the gate's output by just summing up the gate's intrinsic delays to the switching window on its inputs. Depending on the kind of analysis, detailed or not, (stbDetailedAnalysis), the tool merges or not disjoint switching windows on the gate's output (see diagram below). Detailed analysis has no impact on setup/hold calculations but is mandatory in subsequent crosstalk analysis
When propagating through sequential elements (latches or precharges), the tool calculates the switching window on the latch's output by propagating the switching window on its input, with regard to the arrival times of the clock on the latch.
Once the stb function terminates, the timing database is annotated with stability information, i.e. each reference point of the database (I/O connectors, latches, commands, precharge) is annotated with its propagated switching window.
The comparison of the switching windows on the latch nodes, to the arrival times of the clocks, define the setup/hold slacks on the latches. The comparison of the switching windows on the output connectors, to the set_output_delay constraints, define the setup/hold slacks on the output connectors.
With default behavior, the STA engine generates two files:
The slack report is also available through the Tcl function stb_DisplaySlackReport. This function generates the same kind of report as the .str file, but with more customizable and detailed information.
The next sections explain how timing checks are performed. They describe the more common situations one can be faced to, i.e.:
For each situation, an example of slack report is shown, and we explain the details of the timing checks calculation.
Regarding input specifications, the STA engine of HITAS makes the assumption that input data is coming from a latch clocked on the opposite phase of the one the data arrives on. In our flip-flop example, dff_m is opened on the high state of ck, so di is supposed to come from a latch opened on the low state of ck.
As a result, di should be specified as coming from ck falling, i.e. when the latch src opens. The corresponding SDC commands should look like:
create_clock -period 1000 -waveform {500 0} ck set_input_delay -clock -ck -clock_fall -min 200 di set_input_delay -clock -ck -clock_fall -max 300 di |
Diagram below illustrates the way set_input_delay directives are propagated throughout the design, and where timing checks are performed.
Input to latch setup slack report is described in the slack.rep file
Path (4) : Slack of 0.762 DATA VALID: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line ____________________________________________________________________________________ 0.300 0.000 0.200 R 0.034 di di 0.498 0.198 0.310 F 0.028 (L) dff_m dff_m master ____________________________________________________________________________________ 0.498 0.198 (total) DATA REQUIRED: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line __________________________________________________________________________________ 0.000 0.000 0.200 F 0.016 (C) ck ck 0.239 0.239 0.258 R 0.046 (CK) ckn ckn inv 0.340 0.101 0.140 F 0.036 (CK) ckp ckp inv 0.260 -0.081 [INTRINSIC SETUP] 1.260 +1.000 [NEXT PERIOD] __________________________________________________________________________________ 1.260 0.260 (total) |
The value of the setup slack is given by clock_path - data_path = 1260ps - 498ps = 762ps. The intrinsic setup corresponds to an additional delay which models the amount of time required for secure memorization of the data.
Input to latch hold slack report is described in the slack.rep file
Path (2) : Slack of 0.005 DATA VALID: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line ____________________________________________________________________________________ 0.200 0.000 0.200 F 0.034 di di 0.542 0.342 0.508 R 0.028 (L) dff_m dff_m master ____________________________________________________________________________________ 0.542 0.342 (total) DATA REQUIRED: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line __________________________________________________________________________________ 0.000 0.000 0.200 F 0.016 (C) ck ck 0.239 0.239 0.258 R 0.046 (CK) ckn ckn inv 0.537 +0.298 [INTRINSIC HOLD] __________________________________________________________________________________ 0.537 0.537 (total) |
The value of the hold slack is given by data_path - clock_path = 542ps - 537ps = 5ps. The intrinsic hold corresponds to an additional delay which models the amount of time required for ensuring that the next cycle's data is not memorized in the current cycle.
Latch to latch timing checks require no additional configuration, as they are based upon the signals already propagated from inputs, and upon the clock specification. The propagation of the s.w., and corresponding timing checks are described in the following timing diagram:
Latch to latch setup slack report is described in the slack.rep file
Path (3) : Slack of 0.284 DATA VALID: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line _____________________________________________________________________________________ -0.500 0.000 0.200 R 0.016 (C) ck ck -0.399 0.101 0.128 F 0.046 (CK) ckn ckn inv -0.236 0.164 0.169 R 0.036 (CK) ckp ckp inv -0.152 0.083 0.139 F 0.028 (L) dff_m dff_m master 0.090 0.242 0.189 R 0.040 n11 n11 inv 0.321 0.231 0.305 F 0.089 (L) dff_s dff_s slave _____________________________________________________________________________________ 0.321 0.821 (total) DATA REQUIRED: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line ___________________________________________________________________________________ 0.500 0.000 0.200 R 0.016 (C) ck ck 0.601 0.101 0.128 F 0.046 (CK) ckn ckn inv 0.605 +0.005 [INTRINSIC SETUP] ___________________________________________________________________________________ 0.605 0.105 (total) |
Latch to latch hold slack report is described in the slack.rep file
Path (3) : Slack of 0.146 DATA VALID: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line ____________________________________________________________________________________ -0.500 0.000 0.200 R 0.016 (C) ck ck -0.399 0.101 0.128 F 0.046 (CK) ckn ckn inv -0.281 0.119 0.177 R 0.028 (L) dff_m dff_m master -0.223 0.057 0.088 F 0.040 n11 n11 inv 0.106 0.329 0.447 R 0.089 (L) dff_s dff_s slave ____________________________________________________________________________________ 0.106 0.606 (total) DATA REQUIRED: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line __________________________________________________________________________________ 0.500 0.000 0.200 R 0.016 (C) ck ck 0.601 0.101 0.128 F 0.046 (CK) ckn ckn inv 0.764 0.164 0.169 R 0.036 (CK) ckp ckp inv 0.960 +0.196 [INTRINSIC HOLD] -0.040 -1.000 [PREVIOUS PERIOD] __________________________________________________________________________________ -0.040 0.460 (total) |
Still based on the flip-flop design described above, the timing propagation on output t is done as follow:
In order to get setup and hold slacks on the output, one must define timing constraints on t. These timing constraints are defined with the set_output_delay SDC function. The set_output_delay specifies propagation delays from output connector to the next memory element latching the data. As a result, min and max delays are defined as shown in the diagram below.
One must also define the edge the data will be latched by. Here, dff_s is closed on the high state of ck. The data launched by t is supposed to be latched by a memory element clocked on the opposite phase, i.e. closed on low state of ck. Therefore, constraints on t should be specified relative to falling edge of ck (when dst latch closes). The set_output_delay functions should be used as follow:
set_output_delay -clock ck -clock_fall -min 200 t set_output_delay -clock ck -clock_fall -max 400 t |
Latch to output setup slack report is described in the slack.rep file
Path (1) : Slack of 0.030 DATA VALID: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line ______________________________________________________________________________ 0.000 0.000 0.200 F 0.016 (C) ck ck 0.239 0.239 0.258 R 0.046 (CK) ckn ckn inv 0.340 0.101 0.140 F 0.036 (CK) ckp ckp inv 0.568 0.227 0.327 R 0.089 (L) dff_s dff_s slave 0.570 0.003 0.118 F 0.011 (S) t t inv ______________________________________________________________________________ 0.570 0.570 (total) -> Specification: Must be stable after 0.600 |
The setup time is calculated with the maximum set_output_delay value - maximum data path - which is 400ps. As the period is 1000ps, data must arrive before time 1000 - 400 = 600ps. The setup slack is given by 600 - 570 = 30ps.
Latch to output hold slack report is described in the slack.rep file
Path (5) : Slack of 0.635 DATA VALID: Delay Acc Delta R/F Cap[pf] Type Node_Name Net_Name Line _____________________________________________________________________________ 0.000 0.000 0.200 F 0.016 (C) ck ck 0.239 0.239 0.258 R 0.046 (CK) ckn ckn inv 0.385 0.146 0.235 F 0.089 (L) dff_s dff_s slave 0.435 0.050 0.082 R 0.011 (S) t t inv _____________________________________________________________________________ 0.435 0.435 (total) -> Specification: Must be stable before -0.200 |
The hold time is calculated with the minimum set_output_delay value - minimum data path - which is 200ps. The hold slack is given by data path - clock path = 435 + 200 - 0 (the clock is ideal in the set_output_delay definition) = 635ps.
When computing hold slack values between two latches, taking into account the clock skew on the full clock tree may lead to excessive pessimism.
The hold slack is the difference between the data arrival time and the clock arrival time on a latch. The data is supposed to remain stable until after the latch has closed, i.e. the data is supposed to arrive after the time the clock arrives. In the case of a master to slave data path, we have:
hold_slack = data_time - ck_to_slave |
The data comes from the opening of the master latch, so we can express the data arrival time as follow:
data_time = ck_to_master + master_to_slave |
All in all, we have: (minimized)
hold_slack = ck_to_master + master_to_slave - ck_to_slave hold_slack_min = ck_to_master_min + master_to_slave_min - ck_to_slave_max |
In this case, paths from clock to master and from clock to slave are almost identical, until the node where they diverge towards master and slave. However, static timing analysis hypothesis may lead to significant differences between min and max propagation delays on a given path (especially when crosstalk effects are taken into account).
In the case of a hold slack, we check a data coming out from a master latch (opening), against the memorizing event of a slave latch (closing). What should be emphasized here is that a single clock edge generates both the opening event of the master latch and the closing event of the slave latch. The signal is propagating through the common part of the clock-to-master and clock-to-slave paths, and diverges to the master and the slave. Therefore, considering min and max propagation delays on the clock paths only makes sense on the parts of the paths which are not common to the clock-to-master and clock-to-slave paths. The following diagram illustrates this situation:
HITAS supports this situation by a skew compensation mechanism. The global difference between clock-to-master (minimum) and clock-to-slave (maximum) is computed. The difference relative to the common part is removed afterwards. It appears in the slack report tagged as [SKEW COMPENSATION].
HITAS supports multicycle paths through the SDC commands set_multicycle_path as described in this section. Multicycle paths specifications typically allow the tool to perform timing checks for data which requires more than one clock cycle to reach its destination. Let's consider the diagram below, which summarizes what can be done with multicycle paths:
____ ____ ____ ____ ORIGIN_CK ___| |____| |____| |____| |____| 0 1 2 3 4 ____ ____ ____ ____ ____ DEST_CK ___| |____| |____| |____| |____| |____| 0 1 2 3 4 5 |
In the 1-cycle default case, checks are done as follow:
Let's consider a multicycle path of 5, if one just writes the command:
set_multicycle_path 5 -end -to DEST_DATA |
or its equivalent:
set_multicycle_path 5 -end -setup -to DEST_DATA |
This gives:
As you can see, by default the path multiplier (5 here) is applied to the setup check, effectively saying that the data is allowed 5x more clock cycles than the default of 1 to arrive at the destination latch. Note that changing the path multiplier for setup also affects the hold check since, by default, the hold check is 1 cycle before the setup check.
If you want to have the hold checks done as in the 1-cycle case, one must moves the hold check backwards by 4 cycles. This can be done by specifying a path multiplier of 4 for the hold chacks on the same paths as follows:
set_multicycle_path 4 -end -hold -to DEST_DATA |
This gives:
Since 2.7p6 release, there is a way to disable the setup/hold checks between master and slave latches, with a semi-manual method.
The SDC command set_false_path accepts the -hold and -setup options, so it is possible to disable setup/hold checks on specific latches through this command, for example:
set_false_path -setup -to "*.dff_s" set_false_path -hold -to "*.dff_s" |
This will disable setup/hold checks on all the latches matching the pattern *.dff_s (assuming the latch node's name is dff_s). This method assumes that you know the name of the latch node. Obviously it's not always the case, so HITAS also provides an automatic master/slave detection mechanism. This detection is done during the database construction (the hitas command), and is controlled by the following configuration:
avt_config yagleAutomaticFlipFlopDetection mark |
The effect of this configuration is to report master/slave information about the latches in the .rep file, as follow:
[WRN 33] Loop between 2 gates at 409 'm1.dff_m' (master latch found) [WRN 34] Loop between 2 gates at 411 'm1.dff_s' (slave latch found) |
It is possible to extract the SDC commands from the .rep file with an AWK script looking like:
#!/usr/local/bin/gawk -f { if ($2=="34]") { gsub ("'", "", $9); printf "set_false_path -setup -to "$9"\n" >"ms_chk.sdc"; printf "set_false_path -hold -to "$9"\n" >"ms_chk.sdc"; } } |
HITAS handles On-Chip Variation by considering additionnal margins on timing paths. An added margin is associated with a timing path and is defined by an absolute delta value and a relative factor value. The absolute value is an added or substracted propagation delay. The relative value is a percentage of the propagation delay of the timing path itself.
Both the absolute value and the relative value should be specified by the user, with the inf_DefinePathDelayMargin function:
path_delay + margin = path_delay * factor + delta |
Those margins can be specified either path by path or by group of paths (data paths, clock paths, paths arriving on special nodes...).
HITAS also considers positive and negative margins (if factor > 1, the margin is positive, else it is negative). Positive margins are used when considering max paths, negative margins are used when considering min paths (for example STA computes setup slacks by considering max data path vs. min clock path, and the other way round for hold slacks).
Under construction...
Under construction...
Under construction...