1. Limitations of STA, Slew of a waveform, Skew between Signals
Submitted by
Arpitha K

2. Static Timing Analysis
It is one of the technique available to verify the timing of a digital design.
An alternate approach used to verify the timing is the timing simulation which can verify the functionality as well as the timing of the design.

3. Limitations of STA
Reset sequence: To check if all flip-flops are reset into their required logical values after an asynchronous or synchronous reset. The chip may not come out of reset. This is because certain declarations such as initial values on signals are not synthesized and are only verified during simulation.
X-handling: An unknown value X in the design causes indeterminate values to propagate through the design, which cannot be checked with STA. Even though the noise analysis within STA can analyse and propagate the glitches through the design, the scope of glitch analysis and propagation is very different than the X handling as part of the simulation based timing verification for nano meter designs.

4. PLL settings: PLL configurations may not be loaded or set properly.
Asynchronous clock domain crossings: STA does not check if the correct clock synchronizers are being used. Other tools are needed to ensure that the correct clock synchronizers are present wherever their is area synchronous clock domain crossings.
IO interface timing: It may not be possible to specify the IO interface requirements in terms of STA constraints only. For example, the designer may choose detailed circuit level simulation for the DDR1 interface using SDRAM simulation models. The simulation is to ensure that the memories can be read from and written to with adequate margin.

5. FIFO pointers out of synchronization: STA cannot detect the problem when two finite state machines expected to be synchronous are actually out of synchronization. During functional simulations, it is possible that the two FSM are always synchronized and change together in lock-step. After delays are considered, it is possible for one of the FSM to be out of synchronization with the other because one FSM comes out of reset sooner than the other. Such a situation cannot be detected by STA.
Clock synchronization logic: STA cannot detect the problem of clock generation logic not matching the clock definition. STA assumes that the clock generator will provide the waveform as specified in the clock definition.

6. There could be a bad optimization performed on the clock generator logic that causes, for example, a large delay to be inserted on one of the paths that may not have been constrained properly. Alternately, the added logic may change the duty cycle of the clock. The STA cannot detect either of these potential conditions.
Functional behaviour across clock cycles: The static timing analysis cannot model or simulate functional behaviour that changes across clock cycles.

7. Slew of a waveform A slew rate is defined as a rate of change.
The slew is typically measured in terms of the transition time, i.e. the time it takes for a signal to transition between two specific levels.
The transition time is actually inverse of the slew rate - the larger the transition time, the slower the slew, and vice versa.
The transition time is defined with respect to specific threshold levels. For example, the slew threshold settings can be:

8. # Falling edge thresholds:
slew_lower_threshold_pct_fall : 30.0;
slew_upper_threshold_pct_fall : 70.0;
# Rising edge thresholds:
slew_lower_threshold_pct_rise : 30.0;
slew_upper_threshold_pct_rise : 70.0;
These values are specified as a percent of Vdd. The threshold settings specify that falling slew is the difference between the times that falling edge reaches 70% and 30% of Vdd. Similarly the settings for rise specify that rise slew is the difference in times that the rising edge reaches 30% and 70% of Vdd.

9. Figure 1 shows this pictorially.
Fig.1 Rise and fall transition times.
Figure 2 shows another example where the slew on a falling edge is measured20-80(80%to20%)andthatontherisingedgeismeasured10-90 (10% to90%).
Fig.2 Another example of slew measurement

10. # Falling edge thresholds: slew_lower_threshold_pct_fall : 20
# Falling edge thresholds: slew_lower_threshold_pct_fall : 20.0; slew_upper_threshold_pct_fall : 80.0; # Rising edge thresholds: slew_lower_threshold_pct_rise : 10.0; slew_upper_threshold_pct_rise : 90.0;

11. Skew between Signals
Skew is the difference in timing between two or more signals, maybe data, clock or both. For example, if a clock tree has 500 end points and has a skew of 50ps, it means that the difference in latency between the longest path and the shortest clock path is50ps.
Figure 3 shows an example of a clock tree.
Clock tree typically is a node where a clock is defined. The end points of a clock tree are typically clock pins of synchronous elements, such as flip-flops.
Clock latency is the total time it takes from the clock source to an end point.
Clock skew is the difference in arrival times at the end points of the clock tree.

12. Fig.3 Clock tree, clock latency and clock skew.
An ideal clock tree is one where the clock source is assumed to have an infinite drive, i.e. the clock can drive infinite sources with no delay.
In addition, any cells present in the clock tree are assumed to have zero delay. In an ideal clock tree, clock skew is 0ps by default.

13. Latency of a clock tree can be explicitly specified using the set_clock_latency command.
The following example models the latency of a clock tree:
set_clock_latency 2.2 [get_clocks BZCLK]
# Both rise and fall latency is 2.2ns.
# Use options -rise and -fall if different.
Clock skew for a clock tree can also be implied by explicitly specifying its value using the set_clock_uncertainty command:
set_clock_uncertainty setup [get_clocks BZCLK]
set_clock_uncertainty hold [get_clocks BZCLK]

14. The set_clock_uncertainty specifies a window within which a clock edge can occur. The uncertainty in the timing of the clock edge is to account for several factors such as clock period jitter and additional margins used for timing verification.
The clock period jitter is determined by the type of clock generator utilized.
Before the clock tree is implemented, the clock uncertainty must also include the expected clock skew of the implementation.
One can specify different clock uncertainties for setup checks and for hold checks. The hold checks do not require the clock jitter to be included in the uncertainty and thus a smaller value of clock uncertainty is generally specified for hold.

15. Figure4 shows an example of a clock with a setup uncertainty of 250ps.
Figure 4(b) shows how the uncertainty takes away from the time available for the logic to propagate to the next flip-flop stage. This is equivalent to validating the design to run at a higher frequency.
(a) At clock source.
(b) At clock pin of flip-flop.
Fig.4 Clock setup uncertainty

16. As specified above, the set_clock_uncertainty can also be used to model any additional margin. For example, a designer may use a 50ps timing margin as additional pessimism during design. This component can be added and included in the set_clock_uncertainty command.
set_clock_latency 2.0 [get_clocks USBCLK]
set_clock_uncertainty 0.2 [get_clocks USBCLK]
# The 200ps may be composed of 50ps clock jitter
# 100ps clock skew and 50ps additional pessimism.