Uncertainty

Uncertainties and Pessimism in
PrimeTime / PrimeTime-SI Analysis

Sidney Ng, Christophe Bouquet, Anand Shirwal, Siew-Kuan Tham
Infineon Technologies
8 Kallang Sector
Singapore 349282
sidney.ng@infineon.com
Tel: 6876 2086
Abstract
This paper discusses the sources of uncertainties and pessimism inherent in static timing
analysis (STA) and SI analysis, and new features in PrimeTime and PrimeTime-SI which
alleviate these problems.
Static timing analysis is long the de-facto methodology for signing-off multi-million-gate
designs. However, at ultra-deep submicron technologies, a lot of guesswork and experience
are involved in determining the margins for sign-off.
The main culprit is the inadequacies of present models in representing ultra-deep submicron
effects. New features in 2004 versions of PrimeTime such as location-based OCV,
composite-current source (CCS) model are useful for higher accuracy modeling. Another new
feature, path-based analysis and recalculation, is very useful for SI analysis and may reduce
the number of violating paths substantially.
All these will be discussed with specific reference to a 0.13-micron microcontroller-based
design developed in Infineon Singapore.
1. Introduction
Our design project, a microcontroller-based system-on-chip, uses PrimeTime / PrimeTime-SI
for both implementation and sign-off. We relate here experiences accumulated throughout the
course of this project to highlight the importance of choosing appropriate margins for
implementation phase and sign-off, and discuss why this is no trivial task. Impact on the
design could be several additional rounds of ECOs and area overhead due to extra buffering.
The design was completed several years ago with an earlier version of PrimeTime (PT).
Since then, many useful features have been introduced in recent PT versions. In this paper,
we are going to discuss several of these enhancements and perform a what-if analysis to
see what improvements we can obtain.
The paper will conclude with discussion of several exciting new features which may extract
further performance gain from the design.
2. Overview of the Design

Our microcontroller chip serves automotive applications in the power-train domain such as
engine management (eg. knock detection) and electronic transmission control (eg. ECAT,
CVT). The simplified system block diagram is shown in Figure 1.
The design includes a 32-bit super-scalar Tricore CPU, on-chip memories such as SRAM,
ROM and Flash. There is also a Peripheral Control Processor which serves as the interrupt
service provider for the peripherals, and a DMA engine which coordinates data transfer
between various blocks. A wide variety of peripherals has been integrated, which includes
serial communication links, multi-processor interfaces, controller-area-network (CAN),
micro-second bus, timing arrays, GPIOs, ADCs, JTAG and USB.
The design is fabricated using an Infineon 0.13 micron process with embedded Flash option.
As we are very early users of this process technology, there were unforeseen consequences to
be discussed later in this paper. The core voltage and pad voltage is 1.5V and 3.3V
respectively. System clock is set at 80 MHz and it is designed to work at temperature
between -40C and +125C. The gate count for the design is approximately 2 million gates
including memory. Development cycle for automotive chips is usually characterized by long
schedules due to demanding quality and reliability requirements.
Figure 1: System Block diagram
3. Implementation & Signoff

For static timing analysis, SI cross-talk analysis, and final signoff, PrimeTime version
2003.03-SP2-2 was used. The implementation strategy can best be summarized in Figure 2.
Figure 2: Margins for implementation and signoff
An additional implementation margin (yellow triangle) is added on top of the final sign-off
margin (green box). This margin is gradually reduced with time after a few rounds of
synthesis Place & Route STA iterations, so that the final implementation margin and
signoff criteria can converge. For example, we started with an initial synthesis of 20% above
the required clock frequency. This was then refined till the final sign-off margin is reached.
To summarize, the design achieved timing closure after six rounds of ECO iterations. The
sign-off criteria included both OCV and SI for STA. This was done using a graduated
approach:
a) Plain STA
b) STA + OCV
c) STA + OCV + SI
In the early design phase, constraints were developed using only plain STA (step a). Later
iterations when design was almost OCV clean then SI was turned on for STA (step c). Each
round of STA+OCV run took approximately 3-5 hours of run time on a server farm, while
STA run with both OCV and SI settings took approximately 1 day.
Though the clock speed in our design was not very high, achieving timing closure was still a
non-trivial task. To understand why, we listed here various margins, which account for
process and modeling uncertainties, in the sign-off criteria (see Table 1).
Type of Uncertainties
Wire load model
PLL jitter
Clock skew
Built-In Margin
Type of Margin
Set higher frequency for synthesis
Multiplicative
Add setup uncertainty
Additive
Add setup uncertainty /
Additive /
Use propagated clock
Not applicable
RC extraction accuracy
Additive
Setup / hold timing check Add setup / hold uncertainty
Additive
modeling
Process variation Tox, Vth, Libraries at different PVT corners
Not applicable
ID, W, L, Rsh
Pin cap variation
Libraries at different PVT corners
Not applicable
Net modeling accuracy
Wire-load, RC-lumped or distributed
Tool dependent
models
IR-drop,
temperature Cell and net OCV derating
Multiplicative
gradient
Cross-talk
Additive
Inter-die,
wafer-,
lot- Not applied for our design
Not applicable
variation
Total additive margin
500 ps setup, 50 ps hold
Additive
OCV derating margin
15% cell, 8% net
Multiplicative
Table 1: Margins for various modeling uncertainties and process variations.
Our design was an early adopter of Infineons 0.13 micron embedded flash process
technology, and several iterations of Table 1 occurred, before reaching the final set of signoff values.
Two types of margins are used: additive and multiplicative. Examples of the former are
uncertainties due to PLL jitter and setup/hold time modeling error. In total, we have 500ps
4
added for setup uncertainty and 50ps for hold uncertainty. A more directed approach is to use
multiplicative margin. Example of this is OCV derating. For OCV derating, we set 15% for
cell and 8% for net. As seen from Table 1, many sources of uncertainties need to be
accounted for. How do we set appropriate design margins without introducing undue
pessimism? That is a non-trivial task which requires experience and gut-feel, the
consequences we will examine in the next few Sections.
Below, we briefly discuss various uncertainties listed in Table 1 and how we deal with them.
Wire Load model
It is quite common practice to synthesize the design at higher than specified frequency, to
offset uncertainties in the wire load model. We use +20% over-constrain for Design
Compiler.
PLL jitter
This is process technology dependent and added using set_clock_uncertainty. We set this
according to the process guideline.
Clock skew
Used set_clock_uncertainty in early phase. Later switched to set_propagated_clock once a
stable clock tree structure is available.
RC extraction accuracy
RC parasitics were extracted using STARRC-XT. We needed to fine-tune setting to achieve a
compromise between accuracy, reasonable run time and file size.
RC modeling accuracy
Either wire-load model or tools internal RC model can be used. Whenever possible, the latter
was chosen for better accuracy.
Setup / Hold time modeling uncertainty
Strictly speaking, setup-time and hold-time checks should not be derated. So extra margin has
to be added using set_clock_uncertainty [-setup | -hold] .
Process Variations
Process variations such as gate oxide thickness, threshold voltage, and geometrical variations
are modeled with libraries characterized at different PVT corners. Cell variations were
available but not wire variation.
Besides worst case and best case corners, additional PVT corners were also analyzed.
Because of non-linear effects, location of the global maximum and minimum may not be at
the extreme corners [1] . If such library data were unavailable, then OCV derating was
applied. Pincap variation (modeling of Millers effect) was also modeled in the cell library.
IR-drop and Temperature Gradient

An independent analysis on IR-drop was performed using AstroRail, but this was meant for
reliability study rather than feedback into PrimeTime for timing closure. No detailed on-die
temperature profiling was done.
Inter-die, wafer- and lot-variations
OCV accounted for intra-die variation. Inter-die, wafer- and lot-variations were not modeled
since these parameters could be time-varying and fab-dependent (Figure 3), so only one set of
library data is provided.
Figure 3: Variation of process parameter with time due to process drift.
4. PrimeTime Analysis
In this section and next, we will examine some modeling practices and how these can
contribute to uncertainties and pessimism. We will also discuss how recent enhancements in
PrimeTime solve some of these problems. In this section, two main parameters are discussed:
OCV and CRPR.
4.1 Use of Derating Factors in OCV

As discussed, OCV in PrimeTime is modeled using derating or K-factors. The reason for
using derating factor is its simple concept and ease of use. However, this need to be used
carefully as even a small percentage increase can blow up the area dramatically. Figure 4
shows the consequences of different margins and additional area overhead. With an OCV
derating of 14% for cell and 8% for net, about 1600+ buffers were needed to fix the
violations. A further small increase in derating factor, however, leads to the number of
buffers growing exponentially! At 20% cell and 20% net, there is a 3 fold increase in number
of violations and buffers.
Figure 4: Choice of OCV derating factors, and their effect on die area.
4.1.1 Whats wrong with K-factors?

While easy to apply, its primary drawback is the global scope. Derating applies to all clock
and data paths, regardless of how much slack the endpoints have. So every path is deemed to
be at the extreme corner at the same time, which is a really pessimistic assumption. Most
paths do not need so much margin, only a small percentage of critical paths does. Therefore a
7
more localized and directed way of derating is desirable.
4.1.2 Recent Enhancements for OCV Derating

New features from end-2003 to 2004 versions of PrimeTime have been introduced to enable a
localized way of derating. This includes instance specific derating, cell derating, net derating
and location-based OCV (LOCV), and summarized in Table 2.
Feature
Instance-based derating
Commands
Version Introduced
set_timing_derate [early|-late]
PT 2003.12
derate_value [object_list]
Specific cell derating
PT 2003.12
derate_value [get_cells ]
Specific net derating
PT 2004.06
derate_value [get_nets ]
Location based OCV compute_derate_list
PT 2004.12
(LOCV)
[-bounding_box]
[-pairwise]
paths
Table 2: List of new features in PrimeTime to solve global derating problem.
These commands are useful for re-analyzing timing of individual paths. For example, one of
our paths had a slight hold violation in the slow (worst-case) corner. A global derating factor
of 0.85 (highlighted in bold) was applied to the launch clock and data path:
Startpoint: .../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/add_busy_reg
(rising edge-triggered flip-flop clocked by fast_clock_pri)
Endpoint: .../inst_mpu/inst_tc1_core/inst_fpu/fpu_merge0/add_done_reg_reg
Path Group: fast_clock_pri
Path Type: min
Min Data Paths Derating Factor : 0.850
Min Clock Paths Derating Factor : 0.850
Max Clock Paths Derating Factor : 1.000
Min Timing Check Derating Factor: 1.000
Point
Incr
Path
-----------------------------------------------------------------------------clock fast_clock_pri (rise edge)
0.000
0.000
clock network delay (propagated)
5.385
5.385
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/add_busy_reg/CP (R150_SFD2QNSB)
0.000
5.385 r
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/add_busy_reg/QN (R150_SFD2QNSB)
0.194 &
5.579 f
.../inst_mpu/BH1_BUF17045/Z (R150_SBUF1)
0.133 &
5.711 f
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/u409_C1/Z (R150_SIVY2)
0.040 &
5.752 r
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_merge0/add_done_reg_reg/D (R150_SFD2QS)
0.000 &
5.752 r
data arrival time
5.752
clock fast_clock_pri (rise edge)
0.000
6.631
0.000
6.631
clock reconvergence pessimism

-0.994
5.637
clock uncertainty
0.050
5.687
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_merge0/add_done_reg_reg/CP (R150_SFD2QS)
5.687 r
library hold time
0.086
5.773
data required time
5.773
-----------------------------------------------------------------------------data required time
5.773
data arrival time
-5.752
-----------------------------------------------------------------------------slack (VIOLATED)
-0.021
Much of the clock path is common, as seen by the CRPR credit. But data path and capture
clock path are located very near to each other in the Tricore hardmacro, so a global 15%
derating for this data path is considered pessimistic. For a more realistic timing, all cells in
the data path are reset to 0% derating:
set_timing_derating cell_delay early 1.0 [get_cells */BH1_BUF17045 */u409_C1]
Removing pessimism in the data path with instance specific derating, timing for the path is
now clean. Delay changes are highlighted in bold.
Startpoint: .../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/add_busy_reg
Endpoint: .../inst_mpu/inst_tc1_core/inst_fpu/fpu_merge0/add_done_reg_reg
Path Type: min
Point
Incr
Path
-----------------------------------------------------------------------------clock fast_clock_pri (rise edge)
0.000
0.000
5.385
5.385
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/add_busy_reg/CP (R150_SFD2QNSB)
0.000
5.385 r
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/add_busy_reg/QN (R150_SFD2QNSB) <0.194 &
5.579 f
.../inst_mpu/BH1_BUF17045/Z (R150_SBUF1)
0.156 &
5.735 f
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_input0/u409_C1/Z (R150_SIVY2)
0.047 &
5.782 r
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_merge0/add_done_reg_reg/D (R150_SFD2QS)
0.000 &
5.782 r
data arrival time
5.782
0.000
0.000
6.631
6.631
-0.994
5.637
clock uncertainty
0.050
5.687
.../inst_mpu/inst_tc1_core/inst_fpu/fpu_merge0/add_done_reg_reg/CP (R150_SFD2QS)
5.687 r
library hold time
0.086
5.773
data required time
5.773
-----------------------------------------------------------------------------data required time
5.773
data arrival time
-5.782
-----------------------------------------------------------------------------slack (MET)
0.009
4.1.3 Further Discussion for OCV Derating

Despite the improvements, some points need to be further considered.
The above example shows localized derating is the right approach to remove pessimism.
However, it is not obvious what derating should apply to different blocks and hierarchies?
Except for standard cells and I/Os, other blocks like memories, analog macros, CPU may
not provide derating values. For large design with many instances and hierarchies,
individually setting derating for these is also tedious.
Not all parameters can be derated or scaled (Figure 5). For example, in setup/hold time
checks of a flip-flop, delays from Data pin or Clock pin to internal circuitry are not
available in the library model. Therefore, accuracy of derated timing checks cannot be
guaranteed. Likewise, given the PLL jitter in clock source, the output divided clock may
not scale by same ratio.
(a)
(b)
Figure 5(a) Internal path delay of flip-flop is not known. (b) Jitter of a divided clock is
not obvious.
We did not try location based OCV (LOCV), this being a very new feature and requires
much library preparation [2]. It works like the derating example above, except the
derating factor is calculated based on an instances distance from some reference point.
The STA engineer does not need to input derating factors! The LOCV approach can also
be extended to include IR-drop and temperature gradient. However, accuracy of this
method depends very much on quality of derating data prepared.
4.2 Clock Reconvergence Pessimism Removal (CRPR)

The CRPR feature was introduced into PrimeTime several years ago, and went a long way in
removing pessimism in STA [3]. However, occasional STARs on CRPR are still reported [4].
In fact, CRPR calculation is among the first things this author checks when evaluating a new
PrimeTime version. Common problems encountered were (Figure 6):
10
Figure 6: Components of CRPR calculation
Common clock path pessimism. Solved with introduction of CRPR. Note this is for
common clock path only, not reconvergent data path, a wrong assumption commonly
made [5].
CRP threshold. To tradeoff between accuracy versus run-time, we set a threshold of 20ps.
Separate derating factors for launch path, capture path, clock path and data path. Too
many separate settings can cause confusion [5, 6].
Finding the right common point. Sometimes, CRPR may not be able to find the common
point (see example below).
Figure 7 is one of the failing paths encountered during timing closure. Much logic denoted
by the Common path cloud is shared. In fact, paths between PLL and D flip-flop can be
considered common paths, since the branch-away logic are physically placed very close to
each other to ensure matching. In PT2003.03-SP2-2 which we used, CRPR calculated was
zero!
Figure 7: Schematic of path for CRPR evaluation. The two common path logic clouds
share much logic. In fact, paths leading up to the D flip-flop can be considered
common.
4.2.1 Recent enhancements in CRPR calculations

With recent enhancements [7,8], CRPR calculation is more realistic. The CRPR
11
improvements can be seen in our example. Again referring to Figure 7, with PT2004.12, a
more reasonable value of 1.3 ns is obtained for CRPR, and of course the failed path is now
passing with much slack to spare.
4.2.2 Further Suggestions for CRPR

To further refine CRPR calculation, additional correlation information can be used to reduce
pessimism.
Using physical correlation to reduce pessimism
As Figure above indicates, some physically matching instances are not recognized by CRPR
algorithm as common logic. This is because PrimeTime lacks the location information to
make such decisions. Newer version of PrimeTime, such as PT2004.12, stores the location
coordinates for location based OCV. Therefore PrimeTime can make use of the same
information to reduce pessimism in CRPR further.
Even within a single library cell, the n- and p-transistors forming the CMOS logic gate are
strongly correlated (Figure 8). Luckily, this is the default setting for variable
timing_clock_reconvergence_pessimism.
Using logical correlation to reduce pessimism
Logically correlated instances, example bits of an address bus, could be tagged by users with
a correlated attribute, and set appropriate weightage for CRPR algorithm to consider during
analysis.
Figure 8: Correlation star of many process parameters. Thickness of the connecting line
indicates whether two parameters have high or low correlation.
12
5. PT-SI Analysis
A single round of PT-SI iteration is many times slower than a PT+OCV iteration, so it is
important that SI related violations and ECOs are minimized. Prevention is better than cure
is a sound strategy here. Several factors in PT-SI analysis could contribute to excessive
pessimism.
5.1.1 Setting the right window

Timing window
Many improvements in PT-SI have been made. Now it is default SI behaviour to consider
temporal alignment of aggressors and victim nets. Physically impossible situations are also
excluded from analysis. Where cross-talk contribution comes from multiple small aggressors,
some accuracy may be lost because of prior filtering during RC extraction.
When using set_clock_group command, beware of the subtle difference between
asynchronous and exclusive options, and their different effects on SI ! We also used
set_case_analysis to filter static or near-static nets.
Logic window
The variable si_analysis_logical_correlation_mode is enabled in our PT-SI analysis to reduce
pessimism. Example: input net and output net of an inverter always have opposite-sense
transitions, so their combined effect on a victim net is mitigated.
5.1.2 Nonlinear Transition, Extrapolation beyond limits
Though transition affects normal delay calculation, its effect on SI is even more
pronounced. A simple design rule setting such as set_max_transition can have serious
repercussions in SI !
We use set_max_transition to flag potential SI problems. Consult your ASIC vendor for
appropriate setting.
We also use set_max_fanout to limit loads connected to one cell, and prevent transitions
from exceeding look-up table limits. Consult your ASIC vendor for appropriate setting.
13
5.1.3 To set or not to setFalse Paths ?

Certain paths could be excluded from STA using set_false_path or set_clock_group
commands. These paths will not be timing optimized by Design Compiler and not analyzed
in PrimeTime. This saves some effort for the poor STA engineer, but could return to haunt
him in SI !
Because weaker drive strength cells could be placed along false paths, these paths would
meet normal PT timing but transition times may be close to allowable limits. In SI analysis,
such paths will have difficulty meeting timing! Prevention is always a good strategy for SI.
To circumvent potential SI problems, some false paths may be better set to true paths for
optimization. Sharper transition and smaller timing window would have less chances of
cross-talk.
Another factor to consider is DFT requirements. For example, many test clocks must be
declared for different test modes. But not all clocks will be active at once. How to disable
some test clocks? One solution is to activate only test clocks for that test mode. But different
test modes have to be run separately. Another solution is to post process timing reports and
filter off pessimistic paths, either by script or manually. Nevertheless, such clocks could
create pessimism in SI analysis.
5.2 Recent enhancements in PT-SI analysis

5.2.1 Path-based Analysis and Recalculation
One very useful feature introduced in PT 2004.06 version is a new methodology called path
based analysis and recalculation. It can calculate more realistic (hence less pessimistic)
delays with post-process runs. Main features in the recalculation are [9]:
Path specific slews are propagated instead of the default worst slews.
A single edge instead of an arrival window is now propagated down a path.
We tested this new feature with our tape-out database. Even at sign-off, there were many
failing endpoints after PT-SI, with several tens of picoseconds of negative slack, which
needed to be examined manually and waived-off through experience. This is a rather
tedious and error-prone process. If PrimeTime can report more realistic delays, then
turnaround time for STA can be improved, and false violations which needed ECO fix can
also be reduced. A tcl script for path-based recalculation is available in the same Solvnet
article [9]. To limit run-time, options max_paths and nworst can be used to restrict number
of iterations, and verbose option is also useful to monitor progress during recalculation.
Once the tcl script is sourced, it is just a straightforward command to start path recalculation:
14
pt_shell> report_recalculated_paths
-verbose -nworst 100
Processing the following path groups:

**async_default**
**clock_gating_default**
**default**
fast_clock_pri
fast_clock_vir
Obtaining timing paths to all failing endpoints... Done.

Recalculating 12 endpoint(s)... Done.
4 endpoints fail initial recalculation:
Path group 'fast_clock_vir':
endpoint
slack (orig -> recalc)
--------------------------------------------------------------------------------------------------------------------------z_brkin_n
-0.2133 -> -0.1147 (VIOLATED)
z_pson
-0.3241 -> -0.0819 (VIOLATED)
z_psop
-0.3236 -> -0.0813 (VIOLATED)
z_hdrst_n
-0.1978 -> -0.0612 (VIOLATED)
8 paths pass, peeling logic cones to look for failures...
Warning: limiting
100 paths.
Warning: limiting
to 100 paths.
Warning: limiting
to 100 paths.
Warning: limiting
100 paths.
Warning: limiting
to 100 paths.
Warning: limiting
100 paths.
analysis of 'inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/dou_s_reg/D' to
analysis of 'inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/cen_s_reg/EN'
analysis of 'inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/eoa_s_reg/EN'
analysis of 'inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/cen_s_reg/D' to
analysis of 'inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_21/cen_s_reg/EN'
analysis of 'inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_bpi/u_bpi_mux/fpi_d_o_s_regX9X/D' to
Iteration 1:
Processing a maximum of 5 paths per endpoint
628 paths remain to be recalculated and searched
# endpoint
group
#paths slack
----------------------------------------------------------------------------------------------------------------------------7 z_p5[12]
fast_clock_vir
16
0.1885
6 z_p5[9]
fast_clock_vir
12
0.4550
5 inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/dou_s_reg/D fast_clock_pri
100
0.8414
4 inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/cen_s_reg/EN fast_clock_pri
100
0.8893
3 inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/eoa_s_reg/EN fast_clock_pri
100
0.9960
2 inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/cen_s_reg/D fast_clock_pri
100
0.9996
1 inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_21/cen_s_reg/EN fast_clock_pri
100
1.0475
0 inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_bpi/u_bpi_mux/fpi_d_o_s_regX9X/D
fast_clock_pri
100
1.3503
Iteration 1 complete. Of 8 endpoints:
0 endpoints failed
0 endpoints passed exhaustively
8 endpoints remain for the next iteration
Final endpoint summary report:

==============================
Path group 'fast_clock_pri':
endpoint
--------------------------------------------------------------------------------------------------------------------------inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/dou_s_reg/D
-0.2644 ->
0.8414 (MET)
inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/cen_s_reg/EN -0.2085 ->
0.8893 (MET)
inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/eoa_s_reg/EN -0.1005 ->
0.9960 (MET)
inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_22/cen_s_reg/D
-0.1010 ->
0.9996 (MET)
inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_gpta0/ltcarray/ltc_21/cen_s_reg/EN -0.0380 ->
1.0475 (MET)
inst_leda/inst_core_sh/inst_core/inst_spb_sh/inst_gpta/u_bpi/u_bpi_mux/fpi_d_o_s_regX9X/D
-0.0874 ->
1.3503 (MET)
Path group 'fast_clock_vir':

endpoint
--------------------------------------------------------------------------------------------------------------------------z_brkin_n
-0.2133 -> -0.1147 (VIOLATED)
z_pson
-0.3241 -> -0.0819 (VIOLATED)
z_psop
-0.3236 -> -0.0813 (VIOLATED)
z_hdrst_n
-0.1978 -> -0.0612 (VIOLATED)
z_p5[12]
-0.4624 ->
0.1885 (MET)
z_p5[9]
-0.1357 ->
0.4550 (MET)
15
As observed in the Final endpoint summary report, of the 12 violating endpoints selected
for recalculation, 8 passed with considerable slack and 4 remaining endpoints failed but with
substantially reduced negative slack. But what causes the wide difference in reported slack
before and after path recalculation? To understand, we look in detail at one endpoint
/u_gpta0/ltcarray/ltc_22/dou_s_reg/D which reported a difference of 1.1 ns
(-0.2644, 0.8414) before and after recalculation. The detailed timing reports are listed in the
Appendix. Segments of path with large differences highlighted in bold are discussed here.
DTrans (ns)
Trans (ns)
Delta (ns)
Before After Before After Before After
.../u_gpta0/ltcarray/ltc_1/u840_C2_1/A 0.041
0.007 0.129 0.094 0.104 0.022
.../u_gpta0/ltcarray/ltc_2/u937_C4/B
0.013 0.002 0.056 0.035 0.039 0.007
0.017 0.000 0.074 0.050 0.049 0.005
0.035 0.002 0.126 0.084 0.112 0.008
Table 3: Some PT-SI path segments with large differences spotted before and after path
recalculation.
Path Segment
From Table 3, the delta transition, transition time and delta delay after path recalculation are
always smaller. Because signal transition after recalculation is sharper, the timing window
where crosstalk can occur is now reduced. Hence timing delay due to SI can be substantially
reduced in some instances, giving a much less pessimistic delay. As seen here, the difference
for just one segment can amount to 100 ps. So for timing path which passes through many
stages, differences of 1 ns before and after recalculation is not difficult to understand.
Path recalculation is also performed for failing endpoints with PT+OCV but SI disabled
(Table 4). Generally, the difference is not as significant as those observed for SI.
Endpoint
Slack (ns)
Before After
.../inst_fpu/fpu_merge0/add_done_reg_reg/D
-0.021 -0.019
/inst_pcp/inst_pcp_mcds/qpc_guess_regX9X/D
-0.006 -0.005
.../inst_cpu/inst_cpu_ip/inst_cpu_ip_alx/mx_e2_special_sign_reg/EN
-0.005 +0.002
.../inst_pcp/inst_fpi_ms/inst_fpi_ms_datapath/mbo_data_regXDXX28X/D -0.000 +0.004
Table 4: Path recalculation with PT+OCV.
5.2.2 Fewer SI filtering options

Though a minor point, all SI filtering variables have been reduced to only two since PT
2004.06 version. This is easier to understand and removes some uncertainty. The only old
variable
left
is
si_filter_per_aggr_noise_peak_ratio,
while
new
variable
si_filter_accum_aggr_noise_peak_ratio is added.
16
5.3 Future Enhancements for PT-SI

We have seen how transition time can have a huge effect on SI. An example of such problem
is shown in Figure 9. Transition times along the path are well below the maximum limit, and
slack reported for PT+OCV is around 1 ns. Yet without any forewarning, after PT-SI, a
negative slack of -0.1 ns is reported. Much post-processing effort was needed to close timing
for such paths, by scrutinizing and waiving the violations manually (path recalculation was
not available then).
140
120
Max transition = 0.25 ns

Path Slack before SI ~ 1 ns
Slack after SI < 0 ns !
Frequency
100
80
60
40
20
0
0
0.02
0.04
0.06
0.08
0.1
0.12
Transition Time (ns)
Figure 9: Distribution of transition time for one path. Transitions and slack have much
safety margin, yet a violation is reported after SI.
A more fundamental solution for improving SI analysis is to get better slew estimates. This
means a more accurate driver model. The linear driver model has been in use for some time.
If you see many RC-009 warnings in your PrimeTime run, the transitions calculated may
have large uncertainties:
Warning: The drive-resistance for the timing arc
(starlib_reg_1v5/R150_SIV16) BW1_INV755/A-->Z (max rising & falling negative_unate)
is much less than the network impedance to ground;
PrimeTime has adjusted the drive-resistance to improve accuracy.
(RC-009)
A SI victim net voltage waveform may look like Figure 10. Using a linear driver model to
estimate transition time, measured at 40/60 or 20/80 trip point, could lead to a pessimistic
slew for SI analysis.
17
Figure 10: Using linear method to estimate slew may lead to pessimistic SI analysis.
The recently introduced Composite Current Source (CCS) model will help to improve slew
calculation [9, 10]. Unfortunately, at time of this writing, this model does not support PT-SI
yet. To summarize, the main improvements are:
Using a current source with infinite resistance as driver model.

Using current waveform instead of voltage waveform to derive output slew.
Besides the driver model, CCS model also includes a receiver model. With the CCS model,
Millers effect, which we now modeled with pin cap variation libraries, can be directly
calculated.
6. Conclusions and Recommendations

If possible, use the latest version of PT / PT-SI to perform STA and sign-off.
We showed examples where our initial CRPR calculation and SI analysis gave false
violations, due to excessive pessimism. If the new PT / PT-SI features were available to us
then, our design could have taped-out faster with fewer violations and ECO iterations! Design
margins could also be reduced.
Look out for new features / enhancements / STARs in PT and PT-SI.
They give you clues on what your version of PrimeTime is currently lacking. Even without
using the new features, run-time for PT2004.x versions was generally faster than PT2003.x
versions.
Path-based analysis and recalculation is very useful and should be integrated into
PrimeTime.
Right now, path recalculation is post-processed using a tcl script. Since this is a very useful
feature especially for SI analysis, Synopsys could consider integrating this into future
PrimeTime releases.
Location based OCV (LOCV) is potentially a very useful feature.
We showed localized derating is the right approach for OCV. Location-based OCV differs
from other local derating methods as it relieves the STA engineer from making tough
decisions! Instead, onus is now on the ASIC vendor to provide realistic statistical data for
applying LOCV.
18
Composite Current Source (CCS) model is potentially another very useful feature.
Composite current source model is better equipped to handle non-linear driver characteristics
common in ultra-deep submicron logic gates. With this model, we will not need to use pin
cap variation libraries to account for Millers effect. Delay and slew will also be more
realistic. This is particularly important for SI, where hopefully the CCS model can remove
more pessimism from the analysis.
7. References
[1] C11 Timing Signoff, Infineon internal document, Dec 2004.
[2] Location-aware on-chip-variation in PrimeTime, Solvnet Doc Id 013562, Jan 2005.
[3] My head hurts, my timing stinks, and I dont love on-chip variation, Matt Weber,
SNUG Boston 2002.
[4] CRPR calculation incorrect, Solvnet Doc Id 014573, Dec 2004.
[5] How to determine the CRPR credit in paths from clock sources, Solvnet Doc Id
010459, Jan 2005.
[6] How to interpret PrimeTimes derating summary report, Solvnet Doc Id 015118, April
2005.
[7] PrimeTime 2003.12 Release Notes.
[8] PrimeTime 2004.12 Release Notes.
[9] Accurate signoff using path-based analysis, Solvnet Doc Id 012134, March 2005.
[10] PrimeTime Composite Current Source (CCS) delay calculation, Solvnet Doc Id
012082, March 2005.
[11] Synopsys announces industry wide support for Liberty Composite Current Source
(CCS) library models, http://www.synopsys.com, June 2005.
19
Appendix A
1. Violating PT-SI path before path recalculation (see highlighted lines in bold).
Startpoint: .../u_gpta0/pdl/ctr1_s_regX1X
Endpoint: .../u_gpta0/ltcarray/ltc_22/dou_s_reg
Path Type: max
Max Data Paths Derating Factor : 1.000
Max Timing Check Derating Factor: 1.000
Point
DTrans
Trans
Delta
Incr
Path
------------------------------------------------------------------------------------------------------------------------clock fast_clock_pri (rise edge)
0.000
0.000
7.124
7.124
.../u_gpta0/pdl/ctr1_s_regX1X/CP (R150_SFD6QSH)
0.063
0.000
7.124 r
.../u_gpta0/pdl/ctr1_s_regX1X/Q (R150_SFD6QSH)
0.073
0.426 &
7.551 r
.../u_gpta0/pdl/u630_C3/B (R150_SAN2IV)
0.006
0.078
0.015
0.017 &
7.568 r
.../u_gpta0/pdl/u630_C3/Z (R150_SAN2IV)
0.030
0.141 &
7.709 r
.../u_gpta0/pdl/u598_C3_6_C5_24/S (R150_SMXA02P)
0.000
0.030
0.000
0.001 &
7.709 r
.../u_gpta0/pdl/u598_C3_6_C5_24/Z (R150_SMXA02P)
0.032
0.137 &
7.846 r
.../u_gpta0/pdl/u598_C3_6_C5_27/A (R150_SOAN1I1P)
0.001
0.033
0.003
0.003 &
7.850 r
.../u_gpta0/pdl/u598_C3_6_C5_27/Z (R150_SOAN1I1P)
0.042
0.100 &
7.950 f
.../u_gpta0/pdl/u598_C3_6_C5_34/B (R150_SAOR2I2H)
0.000
0.042
0.000
0.000 &
7.950 f
.../u_gpta0/pdl/u598_C3_6_C5_34/Z (R150_SAOR2I2H)
0.103
0.261 &
8.210 r
.../u_gpta0/pdl/u657_C4_6_C4_3/A (R150_SOND1V)
0.000
0.104
0.000
0.007 &
8.218 r
.../u_gpta0/pdl/u657_C4_6_C4_3/Z (R150_SOND1V)
0.060
0.171 &
8.389 f
.../u_gpta0/dcm_block/dcm_2/u1423_C4_6_C4_12/A (R150_SOND1V)
0.004
0.077
0.014
0.067 &
8.456 f
.../u_gpta0/dcm_block/dcm_2/u1423_C4_6_C4_12/Z (R150_SOND1V)
0.051
0.163 &
8.619 r
.../u_gpta0/clk_gen/u754_C6_2/A (R150_SOAN1I2H)
0.002
0.054
0.011
0.026 &
8.645 r
.../u_gpta0/clk_gen/u754_C6_2/Z (R150_SOAN1I2H)
0.028
0.083 &
8.728 f
.../u_gpta0/clk_gen/u754_C6_4/A (R150_SOR2U)
0.000
0.028
0.000
0.001 &
8.729 f
.../u_gpta0/clk_gen/u754_C6_4/Z (R150_SOR2U)
0.013
0.104 &
8.833 f
.../BW1_INV87893/A (R150_SIV16)
0.000
0.013
0.000
0.000 &
8.834 f
.../BW1_INV87893/Z (R150_SIV16)
0.041
0.090 &
8.924 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_15/A (R150_SOAN1I2B)
0.003
0.061
0.009
0.072 &
8.996 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_15/Z (R150_SOAN1I2B)
0.020
0.063 &
9.059 f
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_6/A (R150_SAOR1I2P)
0.000
0.020
0.000
0.000 &
9.059 f
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_6/Z (R150_SAOR1I2P)
0.031
0.076 &
9.135 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_11/A2 (R150_SMX3H)
0.000
0.031
0.000
0.000 &
9.135 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_11/Z (R150_SMX3H)
0.026
0.144 &
9.279 r
.../u_gpta0/ltc_imux/limux_slice_1/u70_C3_8_C3_23_C5_3/A (R150_SANR1V)
0.000
0.026
0.000
0.001 &
9.280 r
.../u_gpta0/ltc_imux/limux_slice_1/u70_C3_8_C3_23_C5_3/Z (R150_SANR1V)
0.060
0.108 &
9.388 f
.../BW1_INV47405/A (R150_SIV16)
0.027
0.096
0.060
0.112 &
9.500 f
.../BW1_INV47405/Z (R150_SIV16)
0.044
0.136 &
9.637 r
.../u_gpta0/ltcarray/ltc_1/u938_C4_12_C5_4/S (R150_SMXI2FH)
0.018
0.071
0.044
0.080 &
9.717 r
.../u_gpta0/ltcarray/ltc_1/u938_C4_12_C5_4/Z (R150_SMXI2FH)
0.112
0.340 &
10.058 r
.../BW1_INV116713/A (R150_SIV16)
0.010
0.125
0.051
0.082 &
10.139 r
.../BW1_INV116713/Z (R150_SIV16)
0.046
0.134 &
10.273 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_4/A (R150_SOR2V)
0.023
0.091
0.052
0.129 &
10.402 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_4/Z (R150_SOR2V)
0.016
0.147 &
10.549 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_2/A (R150_SANR1H)
0.000
0.016
0.001
0.003 &
10.551 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_2/Z (R150_SANR1H)
0.031
0.068 &
10.619 r
.../u_gpta0/ltcarray/ltc_1/u937_C5_3_C4_3/A (R150_SOND1H)
0.000
0.030
0.000
0.000 &
10.619 r
.../u_gpta0/ltcarray/ltc_1/u937_C5_3_C4_3/Z (R150_SOND1H)
0.029
0.084 &
10.703 f
.../BW1_INV617191/A (R150_SIVY16)
0.001
0.030
0.003
0.008 &
10.712 f
.../BW1_INV617191/Z (R150_SIVY16)
0.032
0.091 &
10.803 r
.../BW1_INV617191_1/A (R150_SIV16)
0.038
0.095
0.098
0.170 &
10.973 r
.../BW1_INV617191_1/Z (R150_SIV16)
0.041
0.119 &
11.092 f
.../u_gpta0/ltcarray/ltc_1/u840_C2_1/A (R150_SANR1V)
0.041
0.129
0.104
0.223 &
11.315 f
.../u_gpta0/ltcarray/ltc_1/u840_C2_1/Z (R150_SANR1V)
0.036
0.123 &
11.438 r
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_13/S (R150_SMXI2V)
0.001
0.037
0.003
0.003 &
11.440 r
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_13/Z (R150_SMXI2V)
0.010
0.201 &
11.642 r
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_14/C (R150_SOND1I1B)
0.000
0.010
0.000
0.000 &
11.642 r
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_14/Z (R150_SOND1I1B)
0.030
0.082 &
11.724 f
.../u_gpta0/ltcarray/ltc_1/u851_C6_2_C4_1/A (R150_SOND1V)
0.000
0.030
0.000
0.000 &
11.725 f
.../u_gpta0/ltcarray/ltc_1/u851_C6_2_C4_1/Z (R150_SOND1V)
0.043
0.103 &
11.828 r
.../u_gpta0/ltcarray/ltc_2/u937_C4/B (R150_SAN2H)
0.013
0.056
0.039
0.045 &
11.873 r
.../u_gpta0/ltcarray/ltc_2/u937_C4/Z (R150_SAN2H)
0.018
0.121 &
11.995 r
.../u_gpta0/ltcarray/ltc_2/u937_C4_5_C4_4/A0 (R150_SMXI2FH)
0.000
0.018
0.000
0.000 &
11.995 r
0.039
0.093 &
12.088 f
0.003
0.042
0.009
0.011 &
12.099 f
0.049
0.132 &
12.231 r
.../u_gpta0/ltcarray/ltc_3/u936_C4_4_C4_11/A (R150_SAOR1I2H)
0.006
0.056
0.028
0.036 &
12.267 r
.../u_gpta0/ltcarray/ltc_3/u936_C4_4_C4_11/Z (R150_SAOR1I2H)
0.027
0.093 &
12.360 f
0.000
0.027
0.000
0.001 &
12.362 f
0.055
0.131 &
12.493 r
.../u_gpta0/ltcarray/ltc_4/m_i[0] (gpta4_ltc_test_59)
0.000
0.000 &
12.493 r
.../u_gpta0/ltcarray/ltc_4/u938_C4/B (R150_SAN2U)
0.017
0.074
0.049
0.068 &
12.560 r
.../u_gpta0/ltcarray/ltc_4/u938_C4/Z (R150_SAN2U)
0.014
0.131 &
12.692 r
.../u_gpta0/ltcarray/ltc_4/u938_C4_2/A (R150_SAOR1I2H)
0.000
0.014
0.000
0.000 &
12.692 r
.../u_gpta0/ltcarray/ltc_4/u938_C4_2/Z (R150_SAOR1I2H)
0.026
0.058 &
12.750 f
0.000
0.026
0.000
0.001 &
12.750 f
0.044
0.100 &
12.851 r
.../u_gpta0/ltcarray/ltc_4/m_o[0] (gpta4_ltc_test_59)
0.000
0.000 &
12.851 r
0.002
0.046
0.006
0.008 &
12.859 r
0.016
0.118 &
12.977 r
0.000
0.016
0.000
0.000 &
12.977 r
20
.../u_gpta0/ltcarray/ltc_7/u947_C4/B (R150_SAN2IH)
.../u_gpta0/ltcarray/ltc_7/u947_C4/Z (R150_SAN2IH)
.../u_gpta0/ltcarray/ltc_9/u947_C4_4_C4_3/A (R150_SOND1YH)
.../u_gpta0/ltcarray/ltc_9/u947_C4_4_C4_3/Z (R150_SOND1YH)
.../u_gpta0/ltcarray/ltc_9/u900_C6_2_C5_5_C5_3/A (R150_SAOR1I2H)
.../u_gpta0/ltcarray/ltc_9/u900_C6_2_C5_5_C5_3/Z (R150_SAOR1I2H)
.../u_gpta0/ltcarray/ltc_10/u880_C6_2_C5_6/B (R150_SAN2IY)
.../u_gpta0/ltcarray/ltc_10/u880_C6_2_C5_6/Z (R150_SAN2IY)
.../u_gpta0/ltcarray/ltc_10/u880_C6_2_C5_4/C (R150_SAOR1I2H)
.../u_gpta0/ltcarray/ltc_11/u889_C4/B (R150_SAN2IB)
.../u_gpta0/ltcarray/ltc_11/u889_C4/Z (R150_SAN2IB)
.../u_gpta0/ltcarray/ltc_11/u887_C6_2_C5_4/A (R150_SAOR1I2B)
.../u_gpta0/ltcarray/ltc_11/u887_C6_2_C5_4/Z (R150_SAOR1I2B)
.../u_gpta0/ltcarray/ltc_12/u864_C6_2_C5_4/C (R150_SAOR1I2P)
.../u_gpta0/ltcarray/ltc_12/u864_C6_2_C5_4/Z (R150_SAOR1I2P)
.../u_gpta0/ltcarray/ltc_19/u816_C6_1/A (R150_SAOR1I2B)
.../u_gpta0/ltcarray/ltc_19/u816_C6_1/Z (R150_SAOR1I2B)
.../u_gpta0/ltcarray/ltc_20/u856_C4/B (R150_SAN2IV)
.../u_gpta0/ltcarray/ltc_20/u856_C4/Z (R150_SAN2IV)
21
0.000
0.010
0.000
0.000
0.005
0.000
0.001
0.006
0.000
0.000
0.004
0.000
0.003
0.008
0.000
0.002
0.000
0.000
0.001
0.001
0.005
0.001
0.002
0.000
0.000
0.002
0.000
0.000
0.035
0.000
0.000
0.002
0.000
0.000
0.007
0.000
0.001
0.003
0.000
0.001
0.001
0.000
0.000
0.001
0.028
0.028
0.058
0.069
0.015
0.015
0.031
0.031
0.047
0.053
0.032
0.032
0.029
0.030
0.051
0.000
0.057
0.016
0.016
0.023
0.023
0.044
0.000
0.049
0.014
0.014
0.031
0.034
0.049
0.057
0.032
0.032
0.031
0.033
0.036
0.036
0.022
0.023
0.044
0.000
0.045
0.024
0.024
0.049
0.000
0.054
0.036
0.037
0.039
0.042
0.015
0.015
0.039
0.039
0.035
0.037
0.031
0.031
0.025
0.025
0.081
0.000
0.126
0.015
0.015
0.026
0.026
0.036
0.000
0.037
0.016
0.016
0.030
0.030
0.047
0.054
0.015
0.015
0.029
0.030
0.040
0.044
0.016
0.016
0.028
0.029
0.048
0.000
0.049
0.025
0.025
0.023
0.023
0.038
0.000
0.039
0.000
0.036
0.000
0.000
0.017
0.000
0.002
0.027
0.000
0.000
0.016
0.000
0.009
0.026
0.000
0.005
0.000
0.001
0.003
0.002
0.011
0.002
0.007
0.000
0.000
0.005
0.000
0.000
0.112
0.000
0.000
0.005
0.000
0.000
0.027
0.000
0.002
0.011
0.000
0.003
0.003
0.000
0.000
0.003
0.061
0.000
0.124
0.054
0.130
0.000
0.057
0.000
0.111
0.020
0.120
0.000
0.078
0.003
0.116
0.000
0.039
0.129
0.000
0.059
0.002
0.097
0.000
0.023
0.118
0.000
0.079
0.010
0.118
0.032
0.146
0.000
0.141
0.005
0.119
0.000
0.066
0.001
0.096
0.000
0.004
0.122
0.002
0.170
0.000
0.011
0.155
0.002
0.160
0.010
0.116
0.000
0.056
0.000
0.101
0.007
0.120
0.000
0.074
0.001
0.166
0.000
0.170
0.149
0.000
0.049
0.000
0.098
0.000
0.005
0.114
0.000
0.056
0.000
0.122
0.034
0.123
0.000
0.056
0.002
0.107
0.014
0.118
0.000
0.065
0.003
0.114
0.000
0.004
0.109
0.000
0.064
0.000
0.096
0.000
0.006
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
13.038
13.039
13.163
13.217
13.347
13.347
13.404
13.404
13.516
13.536
13.655
13.656
13.734
13.737
13.853
13.853
13.892
14.022
14.022
14.081
14.083
14.181
14.181
14.203
14.322
14.322
14.400
14.410
14.528
14.560
14.706
14.706
14.847
14.852
14.971
14.971
15.038
15.039
15.135
15.135
15.140
15.262
15.264
15.434
15.434
15.445
15.600
15.602
15.763
15.772
15.888
15.888
15.944
15.945
16.046
16.053
16.173
16.174
16.247
16.248
16.414
16.414
16.584
16.733
16.733
16.782
16.782
16.880
16.880
16.885
16.999
16.999
17.055
17.055
17.178
17.212
17.335
17.335
17.391
17.393
17.500
17.514
17.632
17.632
17.697
17.700
17.814
17.814
17.818
17.927
17.927
17.991
17.992
18.087
18.087
18.093
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
r
f
f
r
r
r
r
r
f
f
r
r
r
r
r
r
r
r
f
f
r
r
r
r
r
r
r
r
r
r
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
r
f
f
r
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
r
f
f
r
r
r
.../u_gpta0/ltcarray/ltc_22/u888_C4/B (R150_SAN2B)
.../u_gpta0/ltcarray/ltc_22/u888_C4/Z (R150_SAN2B)
.../u_gpta0/ltcarray/ltc_22/u870_C1/B (R150_SENH)
.../u_gpta0/ltcarray/ltc_22/u870_C1/Z (R150_SENH)
.../u_gpta0/ltcarray/ltc_22/dou_s_reg/D (R150_SFD6QS)
data arrival time
0.000
0.000
0.003
0.000
0.001
0.000
0.018
0.018
0.024
0.024
0.033
0.000
0.036
0.020
0.020
0.029
0.030
0.010
0.010
0.000
0.000
0.009
0.000
0.002
0.001
0.118
0.000
0.062
0.001
0.086
0.000
0.010
0.134
0.000
0.055
0.002
0.131
0.001
&
&
&
&
&
&
&
&
&
&
&
&
&
18.211
18.211
18.273
18.273
18.360
18.360
18.369
18.503
18.503
18.558
18.561
18.692
18.692
18.692
r
r
f
f
r
r
r
r
r
f
f
r
r

12.500
12.500
5.634
18.134
0.993
19.127
clock uncertainty
-0.500
18.627
.../u_gpta0/ltcarray/ltc_22/dou_s_reg/CP (R150_SFD6QS)
18.627 r
library setup time
-0.199
18.428
data required time
18.428
------------------------------------------------------------------------------------------------------------------------data required time
18.428
data arrival time
-18.692
-----------------------------------------------------------------------------------------------------------------------slack (VIOLATED)
-0.264
2. The same PT-SI path after path recalculation. Voila! The path passes with much to spare
(see highlighted lines in bold).
Startpoint: .../u_gpta0/pdl/ctr1_s_regX1X
Endpoint: .../u_gpta0/ltcarray/ltc_22/dou_s_reg
Path Type: max
Max Data Paths Derating Factor : 1.000
Max Timing Check Derating Factor: 1.000
Point
DTrans
Trans
Delta
Incr
Path
-----------------------------------------------------------------------------------------------------------------------clock fast_clock_pri (rise edge)
0.000
0.000
7.124
7.124
.../u_gpta0/pdl/ctr1_s_regX1X/CP (R150_SFD6QSH)
0.063
0.000
7.124 r
.../u_gpta0/pdl/ctr1_s_regX1X/Q (R150_SFD6QSH)
0.073
0.426 &
7.551 r
.../u_gpta0/pdl/u630_C3/B (R150_SAN2IV)
0.006
0.078
0.015
0.017 &
7.568 r
.../u_gpta0/pdl/u630_C3/Z (R150_SAN2IV)
0.026
0.141 &
7.709 r
.../u_gpta0/pdl/u598_C3_6_C5_24/S (R150_SMXA02P)
0.000
0.026
0.000
0.001 &
7.709 r
.../u_gpta0/pdl/u598_C3_6_C5_24/Z (R150_SMXA02P)
0.032
0.134 &
7.844 r
.../u_gpta0/pdl/u598_C3_6_C5_27/A (R150_SOAN1I1P)
0.001
0.033
0.003
0.003 &
7.847 r
.../u_gpta0/pdl/u598_C3_6_C5_27/Z (R150_SOAN1I1P)
0.028
0.099 &
7.946 f
.../u_gpta0/pdl/u598_C3_6_C5_34/B (R150_SAOR2I2H)
0.000
0.028
0.000
0.000 &
7.946 f
.../u_gpta0/pdl/u598_C3_6_C5_34/Z (R150_SAOR2I2H)
0.101
0.252 &
8.199 r
.../u_gpta0/pdl/u657_C4_6_C4_3/A (R150_SOND1V)
0.000
0.101
0.000
0.007 &
8.206 r
.../u_gpta0/pdl/u657_C4_6_C4_3/Z (R150_SOND1V)
0.059
0.170 &
8.376 f
.../u_gpta0/dcm_block/dcm_2/u1423_C4_6_C4_12/A (R150_SOND1V)
0.004
0.076
0.013
0.067 &
8.443 f
.../u_gpta0/dcm_block/dcm_2/u1423_C4_6_C4_12/Z (R150_SOND1V)
0.051
0.163 &
8.606 r
.../u_gpta0/clk_gen/u754_C6_2/A (R150_SOAN1I2H)
0.002
0.054
0.011
0.026 &
8.632 r
.../u_gpta0/clk_gen/u754_C6_2/Z (R150_SOAN1I2H)
0.023
0.083 &
8.715 f
.../u_gpta0/clk_gen/u754_C6_4/A (R150_SOR2U)
0.000
0.023
0.000
0.001 &
8.716 f
.../u_gpta0/clk_gen/u754_C6_4/Z (R150_SOR2U)
0.011
0.100 &
8.816 f
.../BW1_INV87893/A (R150_SIV16)
0.000
0.011
0.000
0.000 &
8.816 f
.../BW1_INV87893/Z (R150_SIV16)
0.041
0.088 &
8.904 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_15/A (R150_SOAN1I2B)
0.001
0.059
0.006
0.069 &
8.973 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_15/Z (R150_SOAN1I2B)
0.017
0.062 &
9.035 f
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_6/A (R150_SAOR1I2P)
0.000
0.017
0.000
0.000 &
9.035 f
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_6/Z (R150_SAOR1I2P)
0.023
0.074 &
9.109 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_11/A2 (R150_SMX3H)
0.000
0.023
0.000
0.000 &
9.109 r
.../u_gpta0/ltc_imux/limux_slice_1/u69_1_C12_18_C8_11/Z (R150_SMX3H)
0.022
0.139 &
9.248 r
.../u_gpta0/ltc_imux/limux_slice_1/u70_C3_8_C3_23_C5_3/A (R150_SANR1V)
0.000
0.022
0.000
0.001 &
9.248 r
.../u_gpta0/ltc_imux/limux_slice_1/u70_C3_8_C3_23_C5_3/Z (R150_SANR1V)
0.037
0.104 &
9.352 f
.../BW1_INV47405/A (R150_SIV16)
0.009
0.059
0.024
0.075 &
9.427 f
.../BW1_INV47405/Z (R150_SIV16)
0.036
0.111 &
9.538 r
.../u_gpta0/ltcarray/ltc_1/u938_C4_12_C5_4/S (R150_SMXI2FH)
0.015
0.060
0.035
0.071 &
9.609 r
0.111
0.336 &
9.945 r
.../BW1_INV116713/A (R150_SIV16)
0.004
0.117
0.032
0.063 &
10.008 r
.../BW1_INV116713/Z (R150_SIV16)
0.045
0.131 &
10.139 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_4/A (R150_SOR2V)
0.013
0.079
0.033
0.110 &
10.249 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_4/Z (R150_SOR2V)
0.015
0.142 &
10.390 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_2/A (R150_SANR1H)
0.000
0.015
0.001
0.003 &
10.393 f
.../u_gpta0/ltcarray/ltc_1/u609_C5_2/Z (R150_SANR1H)
0.022
0.067 &
10.460 r
.../u_gpta0/ltcarray/ltc_1/u937_C5_3_C4_3/A (R150_SOND1H)
0.000
0.022
0.000
0.000 &
10.460 r
.../u_gpta0/ltcarray/ltc_1/u937_C5_3_C4_3/Z (R150_SOND1H)
0.023
0.077 &
10.537 f
.../BW1_INV617191/A (R150_SIVY16)
0.001
0.023
0.002
0.007 &
10.544 f
.../BW1_INV617191/Z (R150_SIVY16)
0.031
0.084 &
10.628 r
.../BW1_INV617191_1/A (R150_SIV16)
0.029
0.085
0.065
0.137 &
10.766 r
.../BW1_INV617191_1/Z (R150_SIV16)
0.039
0.112 &
10.878 f
.../u_gpta0/ltcarray/ltc_1/u840_C2_1/A (R150_SANR1V)
0.007
0.094
0.022
0.141 &
11.019 f
22
.../u_gpta0/ltcarray/ltc_1/u840_C2_1/Z (R150_SANR1V)
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_13/S (R150_SMXI2V)
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_13/Z (R150_SMXI2V)
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_14/C (R150_SOND1I1B)
.../u_gpta0/ltcarray/ltc_1/u935_C4_5_C4_14/Z (R150_SOND1I1B)
.../u_gpta0/ltcarray/ltc_2/u937_C4_5_C4_4/A0 (R150_SMXI2FH)
.../u_gpta0/ltcarray/ltc_7/u947_C4/B (R150_SAN2IH)
.../u_gpta0/ltcarray/ltc_7/u947_C4/Z (R150_SAN2IH)
.../u_gpta0/ltcarray/ltc_9/u947_C4_4_C4_3/A (R150_SOND1YH)
.../u_gpta0/ltcarray/ltc_9/u947_C4_4_C4_3/Z (R150_SOND1YH)
.../u_gpta0/ltcarray/ltc_9/u900_C6_2_C5_5_C5_3/A (R150_SAOR1I2H)
.../u_gpta0/ltcarray/ltc_9/u900_C6_2_C5_5_C5_3/Z (R150_SAOR1I2H)
.../u_gpta0/ltcarray/ltc_12/u864_C6_2_C5_4/C (R150_SAOR1I2P)
.../u_gpta0/ltcarray/ltc_12/u864_C6_2_C5_4/Z (R150_SAOR1I2P)
23
0.000
0.000
0.000
0.002
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.005
0.000
0.000
0.001
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.004
0.000
0.000
0.000
0.000
0.001
0.000
0.000
0.002
0.000
0.000
0.001
0.000
0.000
0.000
0.032
0.031
0.010
0.010
0.025
0.025
0.032
0.035
0.016
0.016
0.027
0.028
0.042
0.042
0.024
0.024
0.047
0.050
0.013
0.013
0.016
0.016
0.032
0.032
0.012
0.012
0.017
0.017
0.045
0.051
0.013
0.013
0.016
0.016
0.035
0.036
0.021
0.021
0.019
0.019
0.039
0.041
0.014
0.014
0.016
0.016
0.032
0.033
0.012
0.012
0.023
0.023
0.037
0.037
0.032
0.032
0.031
0.027
0.025
0.025
0.016
0.016
0.031
0.031
0.024
0.024
0.043
0.047
0.036
0.036
0.039
0.039
0.012
0.012
0.015
0.015
0.027
0.028
0.025
0.025
0.019
0.019
0.070
0.084
0.013
0.013
0.013
0.013
0.030
0.031
0.012
0.012
0.015
0.015
0.040
0.041
0.000
0.000
0.000
0.007
0.000
0.000
0.000
0.000
0.005
0.000
0.000
0.000
0.000
0.000
0.020
0.000
0.000
0.003
0.000
0.000
0.001
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.009
0.000
0.000
0.000
0.000
0.002
0.000
0.000
0.008
0.000
0.000
0.003
0.000
0.000
0.000
0.110
0.000
0.195
0.000
0.082
0.000
0.099
0.013
0.112
0.000
0.091
0.002
0.120
0.008
0.086
0.001
0.128
0.023
0.121
0.000
0.056
0.001
0.092
0.002
0.109
0.000
0.058
0.000
0.115
0.038
0.122
0.000
0.056
0.000
0.098
0.006
0.111
0.000
0.070
0.001
0.108
0.013
0.120
0.000
0.057
0.002
0.092
0.007
0.108
0.000
0.076
0.001
0.109
0.006
0.137
0.000
0.141
0.001
0.116
0.000
0.061
0.000
0.091
0.001
0.114
0.000
0.169
0.009
0.152
0.000
0.160
0.003
0.114
0.000
0.054
0.000
0.082
0.004
0.115
0.000
0.070
0.001
0.161
0.065
0.135
0.000
0.048
0.000
0.087
0.004
0.110
0.000
0.052
0.000
0.109
0.007
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
11.129
11.129
11.324
11.324
11.407
11.407
11.506
11.519
11.632
11.632
11.723
11.725
11.845
11.853
11.938
11.940
12.068
12.092
12.213
12.213
12.270
12.270
12.362
12.364
12.474
12.474
12.532
12.532
12.647
12.685
12.807
12.807
12.863
12.863
12.961
12.968
13.078
13.079
13.149
13.149
13.257
13.270
13.391
13.391
13.448
13.450
13.542
13.548
13.657
13.657
13.733
13.735
13.843
13.849
13.986
13.986
14.127
14.128
14.244
14.244
14.305
14.305
14.396
14.397
14.511
14.511
14.680
14.689
14.842
14.842
15.001
15.004
15.119
15.119
15.173
15.173
15.255
15.258
15.374
15.374
15.444
15.445
15.606
15.671
15.806
15.807
15.854
15.854
15.941
15.945
16.055
16.056
16.108
16.108
16.217
16.225
r
r
r
r
f
f
r
r
r
r
f
f
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
r
r
r
r
f
f
r
r
r
r
r
r
r
r
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
.../u_gpta0/ltcarray/ltc_20/u856_C4/B (R150_SAN2IV)
.../u_gpta0/ltcarray/ltc_20/u856_C4/Z (R150_SAN2IV)
.../u_gpta0/ltcarray/ltc_22/u888_C4/B (R150_SAN2B)
.../u_gpta0/ltcarray/ltc_22/u888_C4/Z (R150_SAN2B)
.../u_gpta0/ltcarray/ltc_22/u870_C1/B (R150_SENH)
.../u_gpta0/ltcarray/ltc_22/u870_C1/Z (R150_SENH)
.../u_gpta0/ltcarray/ltc_22/dou_s_reg/D (R150_SFD6QS)
data arrival time
0.000
0.000
0.002
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.012
0.012
0.015
0.015
0.033
0.035
0.013
0.013
0.018
0.018
0.036
0.036
0.016
0.016
0.016
0.016
0.031
0.031
0.017
0.017
0.017
0.017
0.026
0.026
0.018
0.018
0.014
0.015
0.010
0.010
0.000
0.000
0.006
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.001
0.000
0.116
0.000
0.054
0.000
0.094
0.009
0.113
0.000
0.061
0.000
0.105
0.001
0.102
0.000
0.057
0.000
0.090
0.003
0.114
0.000
0.061
0.001
0.080
0.001
0.127
0.000
0.054
0.001
0.117
0.000
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
16.340
16.341
16.395
16.395
16.489
16.498
16.611
16.611
16.673
16.673
16.778
16.779
16.881
16.881
16.938
16.938
17.028
17.031
17.144
17.145
17.206
17.206
17.286
17.287
17.415
17.415
17.468
17.469
17.587
17.587
17.587
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r
r
r
f
f
r
r

12.500
12.500
5.634
18.134
0.993
19.127
clock uncertainty
-0.500
18.627
.../u_gpta0/ltcarray/ltc_22/dou_s_reg/CP (R150_SFD6QS)
18.627 r
library setup time
-0.199
18.428
data required time
18.428
------------------------------------------------------------------------------------------------------------------------data required time
18.428
data arrival time
-17.587
------------------------------------------------------------------------------------------------------------------------slack (MET)
0.841
24

Uncertainty

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uncertainty

Enviado por

Direitos autorais:

Formatos disponíveis

Uncertainties and Pessimism in

PrimeTime / PrimeTime-SI Analysis

2. Overview of the Design

Figure 1: System Block diagram

3. Implementation & Signoff

Figure 2: Margins for implementation and signoff

IR-drop and Temperature Gradient

Figure 3: Variation of process parameter with time due to process drift.

4.1 Use of Derating Factors in OCV

4.1.1 Whats wrong with K-factors?

more localized and directed way of derating is desirable.

4.1.2 Recent Enhancements for OCV Derating

clock reconvergence pessimism

4.1.3 Further Discussion for OCV Derating

4.2 Clock Reconvergence Pessimism Removal (CRPR)

Figure 6: Components of CRPR calculation

4.2.1 Recent enhancements in CRPR calculations

4.2.2 Further Suggestions for CRPR

5.1.1 Setting the right window

5.1.2 Nonlinear Transition, Extrapolation beyond limits

5.1.3 To set or not to setFalse Paths ?

5.2 Recent enhancements in PT-SI analysis

-verbose -nworst 100

Processing the following path groups:

Obtaining timing paths to all failing endpoints... Done.

Final endpoint summary report:

Path group 'fast_clock_vir':

5.2.2 Fewer SI filtering options

5.3 Future Enhancements for PT-SI

Max transition = 0.25 ns

Transition Time (ns)

Using a current source with infinite resistance as driver model.

6. Conclusions and Recommendations

clock fast_clock_pri (rise edge)

clock fast_clock_pri (rise edge)

Você também pode gostar