Professional Documents
Culture Documents
CRPR
CRPR
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
1 Glossary of Acronyms
The following abbreviations are used in this article. CRP :Clock Reconvergence Pessimism CRPR :Clock Reconvergence Pessimism Removal SI :Signal Integrity
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
2 Introduction
The following are the main points of this application note. Each point is explained in more detail in the following article. What is CRPR?
PrimeTimes original implementation of CRPR was of the Path based type. This technique has inherent limitations. This section explains the relative merits of path based CRP calculations versus graph based approaches, and how it can miss critical timing paths. All versions of PrimeTime after 2001.08 utilize a graph based CRP solution.
CRPR Command and variable overview
The value of CRP reported by report_timing may be less than the value of CRP reported by report_crpr, with a lower bound set by the CRPR variable <var name> (see variables and commands below).
CRPR & Latches. CRPR & SI analysis.
An explanation of how CRPR works with the multi-voltage flow in PrimeTime T2002.09 is given, including an explanation of how CRP removal will automatically and accurately account for delay and slew differences due to annotated cell rail voltage values in the CRP calculation, as part of the IR drop flow.
CRPR & Multiplexed Clocks. The support of related and combined clocking structures is explained for the V-2003.12 release CPU & Memory Performance. Performance and memory improvements are explained and discussed for the V2003.12 release Understanding calculation pessimism introduced by the CRPR threshold Performance and memory improvements are explained and discussed for the V2003.12 release Known Issues References
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
3 What is CRPR ?
CRPR is the removal of artificially induced pessimism from a timing report between a launching and capturing device. If the same clock drives both devices, then the launching and capturing paths will share a common sub path before branching. We refer to this sub path as the common portion. CRP itself is the difference along this common portion of the clock tree, between the minimum and maximum arrival times at the common point, of the clock signal. The common point is defined as the output pin of the last cell in the common portion on the clock tree. (See Figure 1 below). CRPR is mainly applicable in on-chip variation mode, where the worst possible timing variation may occur throughout the chip. It may also be present in single operating condition, or best case / worst case analysis, as it is an STA effect that is circuit topology dependent. However, timing variation seen in the clock network will not be as severe in these modes, and hence the resulting CRP value will not be as significant to the paths of interest in the analysis. The following table illustrates the variety of timing data in on-chip variation mode. Operating Condition BEST CASE WORST CASE SETUP(MAX) CHECK Capture Data Early Late Early Late HOLD (MIN) CHECK Capture Data Late Early Late Early
Table 1: Variety of timing data in on-chip variation mode The entries in italics signify the selection made by on-chip variation mode for static calculation purposes. The terms late and early in the table have the following meanings: Late(max) ......................... The latest possible time for data to either leave a pin, or for data to arrive at a pin. This is also referred to as the max path, where max, in this context refers to delay alone, and is not to be confused with the MAX (setup check) type. Early(Min) ........................ The earliest possible time for data to either leave a pin or to arrive at a pin This is also referred to as the min path, where min, in this context refers to delay alone, and is not to be confused with the MIN (hold check) type. As can be observed from the table: A setup check consists of the latest possible data launch time, combined with the earliest possible capture time and the longest possible (max)delay on the data path. A hold check consists of the earliest possible data launch time, the latest possible capture time and the shortest possible (min) data path.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Phone: 650-584-4200, OR: 1-800-245-8005 This is illustrated in the diagram below for a setup check. Late(max) Launching Device Latest Launch Path Data Path Capturing Device OUT
FF1 U1 U2
FF2
CLK CLK
U3
Latest Earliest
Latest Earliest
CLK
Figure 1: CRPR definition for setup check As is observed in the diagram above, where we are considering a setup check, we have a common portion in the clock network. During STA the setup timing report calculation is constructed from the launching clock path, data path and the capturing clock path. The launching clock path and data path both consider LATE signal propagation times, whilst the capturing clock path considers the EARLY signal propagation time. In a physical design, however, the cells along the common portion of the clock tree cannot simultaneously achieve their maximum and minimum delay values. Thus there will be a single value of delay to the common point that will be propagated to both the launching and capturing devices. This conflicts with STA since we utilise two sets of delay values at the common point. Therefore our timing report contains artificially introduced pessimism that is derived from our usage of EARLY and LATE arrival times for the launching and capturing paths along this common portion of the clock network. The value of this pessimism, is the difference between the EARLY and LATE arrival times at the common point in the clock network. Hence it is valid to remove, from the final slack calculation, the pessimism artificially introduced during the slack calculation. Clock Reconvergence Pessimism (CRP) CRP = Latest Arrival time@common point Earliest arrival time time@common point
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Phone: 650-584-4200, OR: 1-800-245-8005 The situation is identical for hold checks, since we are using the EARLY values for the launch path and the LATE values for the capture path. Therefore the CRP value calculated at the common point will be identical to that calculated for a setup check.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
: For small critical path sets, relatively quick : By default, non exhaustive CRP analysis - can cause critical paths to be missed : Exhaustive analysis is infeasible : Has inherent limitations in support of certain structures : Cannot be used for sign-off : Exhaustive CRP analysis - will not miss critical paths : Can support arbitrarily complex structures : Requires more memory and CPU than path based
2.
4.2 History
Prior to release 2001.08 of PrimeTime, the computation of CRP was performed using path based methods. Starting with the release 2001.08 the calculation method was modified to be graph based.
-max_paths
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
If the critical path set is small, then so will be the runtime and memory usage.
Graph based methods evaluate CRP in the following way When update_timing is called 1. Exhaustively process the entire design calculating slack considering the CRP for every path endpoint in the design. 2. Generate the path critical path set .
In graph based approaches, at the most general level, the runtime and memory usage is a function of the design size, however the analysis mode and the threshold setting also significantly affect performance. CPU / MEM usage =
If the design has a large number of instances then this will lead to a large runtime and memory usage In addition if the clock network is in the pre-layout stage, then this will also cause a very large runtime. Note that in this cases CRP analysis in general is invalid also. Typically runtime and memory usage with CRPR ON is expected to be approximately 2-3X the runtime for standard PrimeTime, depending upon processing conditions and design style..
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
The correct result for the above example is If CRP is OFF then path1 is the path giving the worst endpoint slack at the capturing Flip-Flop If CRPR is ON and if we consider both paths together then path 2 is the path giving the worst endpoint slack at the capturing Flip-Flop A sample calculation is as follows.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
With CRPR OFF if we execute a command of the form pt_shell> report_timing nworst 1 maxpaths 10,000 (in other words, list the worst endpoint slack out of up to 10,000 paths terminating at that endpoint) Path1 is reported correctly as the worst path However, when CRPR is ON the results from the 2 methods of CRP removal will differ Path Based Path 1 will still be reported (incorrectly) as the worst path. This is because the method relies on gathering the critical path set and then post-processing to recalculate the path slacks considering CRP. If path 2 is not returned, as it would not be in the above case, then the path based method would not find the critical path The only way to get path based methods to catch this type of condition is for the entire design is to have every path reported and processed as a critical path. This is obviously not a feasible approach. i.e. report_timing nworst
-max_paths
Graph based Since the entire design is considered in the calculation of CRP, Path 2 will be correctly reported as the worst path.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
10
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
11
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Where mismatch means that there is more than 1 transition type (i.e. rising & falling) required at the common point to drive the launching and capturing registers. If we take the case where both the launching and capturing devices are triggered on the same edge of the clock signal, this means that during propagation one of the paths between the common point and either the launching or capturing register experiences an inversion Alternatively a mismatch can occur where neither of the paths from the common point to the launching and capturing devices has experienced an inversion, but the devices themselves are activated by different edges of the clock signal.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
12
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Determines how much pessimism that the CRP value used in report timing can leave in the report. See the explanation below of differences between report_crpr / report_timing CRP values for more details. Note that this variable can have an exponential effect on runtime. Setting a large value in this variable will (in some cases) considerably speed up the CRP calculation in update_timing, but will lead to a corresponding loss of accuracy. Hence this mechanism provides the opportunity for the user to trade-off runtime against accuracy of the calculated CRP value. The effect of this variable is to reduce or increase the computational cost of the CRP calculation, as alluded to above. The value of this variable determines the level of common point1 compression (i.e. merging) where the value of the CRP threshold calculated for an adjacent common point is less than the specified value of timing_crpr_threshold_ps. This means that there are a set of points in the clock network that are removed from the computation, where the value of CRP calculated is not more than the specified threshold value. Hence for the report of interest, the value of CRP in report_timing may differ from the actual amount of CRP (as will be reported by report_crpr see section entitled report_timing & report_crpr may show slightly different values below) by the threshold value. i.e. CRP in report_timing range[ (actual CRP - timing_crpr_threshold_ps), (actual CRP)] In the case of SI analysis, this variable plays a more crucial role in determining the complexity of the CRP calculation, since, there are 2 sets of arrival times under consideration; delta free & delta inclusive arrival times. When comparing the difference in CRP between 2 adjacent points, both CRP values are checked, one calculated from crosstalk delta free arrivals, the other from crosstalk delta inclusive arrivals. In addition, depending upon the value of the variable and the values of the SI delta delays considered, the level of common point compression in the CRP calculation with SI on may well be smaller than with SI off. This will lead to correspondingly higher memory and runtime requirements with SI on. This will result in a difference between the values of CRP calculated with SI analysis turned on and SI analysis turned off. However, both values are guaranteed to be within the specified threshold value. Please refer to the section titled CRPR & SI analysis for more details on this topic. Having read the above, the astute reader will have surmised that setting the threshold to a very small value impacts runtime and memory very significantly. However, in utilizing the threshold variable for setup and hold analysis, different values may be used for the relative runs. For hold checks, setting the threshold value to a minimal value will give a better quality analysis, since a more accurate value of CRP will be used in assessing the slack for latch to latch paths that are temporally extremely close. For example, if two registers are very close (temporally closer than the CRP threshold then they are considered to be the same point as far as the CRP analysis goes. Reducing the threshold value gives greater accuracy for these critical path analysis. In this case, the setup check is not of concern.
The common point is defined as the output pin of the last cell in the common portion of the clock network.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
13
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Phone: 650-584-4200, OR: 1-800-245-8005 For setup checks, the problem occurs on longer paths. In this case a larger value of threshold could be used without affecting the result too much, since it is highly unlikely that a pair of registers in the critical path set of interest will be temporally closer that the CRP threshold. In this case, hold check is not of concern. It is of course up to the user to determine the value of the threshold for each type of run. Additionally, indiscriminate usage of this variable can have a serious effect on CPU runtime and memory usage. Please see the section entitled CPU & Memory Performance for more details
Same Transition
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
14
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
15
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Report_crpr will always report the ACTUAL CRP value. Its calculation is based upon processing a single from -to pair. Hence this is not computationally expensive, since it can only ever be between a pair of sequential device clock pins. It is therefore the most accurate way to measure CRP in a design. The CRP value utilized by report timing must be computed by update_timing, which involves (in many cases) significant computational effort, as it must calculate CRP values over the entire design. This requires building a complete picture of the entire clock network & assessing the CRP values for all startpoints and endpoints that are required for reporting. The reporting sets themselves may be very large. In order to reduce the computational cost, we use the variable timing_crpr_threshold_ps (default = 20ps) to help reduce the size of the computation. This introduces common point2 compression (i.e. merging) where the value of the CRP threshold calculated for an adjacent common point is less than the specified value of timing_crpr_threshold_ps. This means that there are a set of points in the clock network that are removed from the computation, where the value of CRP calculated is not more than the specified threshold value. Hence, for the report of interest the value of CRP in report_timing may vary from the actual amount of CRP by the threshold value. i.e. CRP in report_timing range[ (actual CRP - timing_crpr_threshold_ps), (actual CRP)] Therefore the CRP value produced by report_timing and the CRP value produced by report_crpr will differ by a value not greater than the timing_crpr_threshold_ps value. In order for the CRP values in report_timing & report_crpr to agree for every path in the design, no two adjacent common points in the clock network should have a CRP value differing by less than the value set on the variable timing_crpr_threshold_ps. Setting timing_crpr_threshold_ps to the minimum value is not recommended since the additional runtime expense is rarely justified in the face of alternate sources of greater inaccuracy within the timing analysis itself. The selection of the value for timing_crpr_threshold_ps value should be based on a consideration of the level of inaccuracy acceptable to the user.
The common point is defined as the output pin of the last cell in the common portion of the clock network.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
16
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
17
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Victim As stated above, in considering SI analysis, delta delays, are calculated from aggressor networks. It is only valid to factor delta delays into the CRPR analysis under the following condition. Aggressor switching must affect both the launching and capturing signal at the same time. Note that under some circumstances a difference may be seen between the CRP results with SI on and SI off. This is caused by the threshold value (timing_crpr_threshold_ps) being at too high a setting. This is explained further in section III CRPR command and variable overview, in the subsection describing the variable timing_crpr_threshold_ps. Aggressor switching must affect both the launching and capturing signal at the same time If the launch and capture signals for a particular path are a clock edge apart, and delta delays crucially depend upon the temporal relationship between victim and aggressor, then in reality, the delta delays affecting the launching and capturing signals will be different. Indeed, different aggressors, switching in different ways may well affect the launching and capturing signals. This will lead to different delta delay values that will either speed up or slow down the victim network. How the victim is affected is therefore entirely dependent upon the aggressor switching cycle. This effect can be observed in the figure below. Vh
Vl
Capture t Unaffected
max? 18
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
As a further example, let us consider the diagram below, where we have a victim (clk) and an aggressor signal agg1. Let us say that there is another signal in the aggressor set, that we shall call agg2, and additionally that during clock cycle n aggressor1 is active and aggr2 is stable, and that at clock cycle n+1 that the situation is reversed, that is, agg1 is stable and agg2 is active. Then, the delta delay given to the victim network during clock cycle n, will be different from the delta delay given to the victim at clock cycle n+1. Obviously, the forgoing is extensible, as depicted by the signal agg3, which is influencing the same network during the next clock cycle
agg1 agg3
?1
C1=10 clk U1
?3
C3=20
?2
C2=20
U2 Common point
agg2
agg3
agg2
agg1
clk
?1
?2 Capture
?3 Launch
Launch
PrimeTime & PrimeTime SI (U-2003.03 onwards) has been enhanced to ensure that the dynamic properties of SI delta delays are considered correctly in the CRP calculation. In PrimeTime T-2002.09 and earlier, delta delays are handled in the same way as regular delays in the CRPR analysis. This implementation does not account for the dynamic nature of delta delays. It is therefore not recommended to use CRPR with SI, for sign-off analysis, in this and previous releases. In PrimeTime U-2003.03 and later the fact that delta delays are dynamic is accounted for correctly. For a given timing check, any CRP arising due to delta delays can only be removed provided that precisely the same clock edge drives both the launching and capturing devices. Such checks are broadly classified as zero cycle checks. The zero cycle behaviour itself may be intentional or accidental. In all cases, PrimeTime considers the delta delays from SI analysis as part of the CRP calculation. This is a valid approach because (as per the previous section) in order for delta delays from SI analysis the following must hold; Aggressor switching must affect both the launching and capturing signal at the same time.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
19
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Phone: 650-584-4200, OR: 1-800-245-8005 Zero cycle behavior occurs most frequently in hold timing checks, however there are a subset of corner cases in which it also applies. The following (non-exhaustive) list gives examples of these circuit topologies / checks. 1. In standard hold checks, as mentioned above, and the hold check corner cases mentioned in the subsections below. a. Where there is feedback from the output of a register back to its input (intentional or otherwise). i. Intentional feedback would be a direct feedback path from !Q (inverse of Q) to the data input (D) of a latch, as in a generated divide by 2 clock for instance. ii. Unintentional feedback would be via crosstalk coupling that may couple the output of a sequential device back to its own input. b. Where clock skew is employed to drive both the launching and capturing clock signals. In this case, it is necessary to set a multicycle path of 0 along the data path of interest. In certain setup checks where transparent latches are involve or where a multicycle constraint of zero has been set on the data path.
2.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
20
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
V1 max/min
V2 max/min
FF1
FF2
CLK CL
U1
U2
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
21
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
In the V-2003.12 release of PrimeTime, you can still use case analysis to specify the exact conditions for CRPR analysis. However, the CRPR algorithm now explicitly considers related generated clocks in its determination of the common node, even in the absence of case analysis.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
22
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Additionally, In the V-2003.12 release, the report_crpr command was modified slightly to support the analysis of related generated clocks. The option -clock clock_name are replaced by two new options, -from_clock clock_name -to_clock clock_name. The two options specify the names of the clocks that fan out to the from and to latches, respectively.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
23
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
The above 2 points conspired to create significant requirement to improve both CPU runtime and Memory utilization, as well as enhanced infrastructure. In V-2003.12 release of PrimeTime and beyond, significant improvements have been made to the algorithmic engine used in processing the CRPR calculation. This modification, in conjunction with significant infrastructure enhancements have resulted in significantly improved algorithmic performance of this feature. Additionally, the sensitivity of the timing_crpr_threshold_ps with respect to CPU runtime and memory usage has been significantly affected. This is clearly shown in the tabular performance data shown below, which for both Table1 and Table 2 gives performance comparison data against the U-2003.03 release of PrimeTime. For example, where the figure 3.62 appears in the top left hand corner of Table 1, this means that there was a 3.62X scalar performance increasing in CPU for a threshold setting of 50ps. In table 2 where the figure 2.72 appears in the top left hand corner of the table, this means that memory usage was 2.72 times less in U2003.12, when compared against V-2003.12 for a threshold setting of 50ps. Table 1 : CPU Gain in V-2003.12 Vs U-2003.03 CRPR threshold (Picoseconds) Design 50 20 10 5 s156664 s160471 s136512 s123351 s162512 s134557 Average: 3.62 3.12 6.77 2.36 2.25 4.29 3.74 14.01 6.52 14.57 4.16 1.55 7.52 8.06 13.91 6.54 13.75 2.08 3.38 9.28 8.16 13.91 6.63 15.02 1.94 3.18 7.15 7.97
0.2
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
24
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Phone: 650-584-4200, OR: 1-800-245-8005 s156664 s160471 s136512 s123351 s162512 s134557 Average: 2.72 2.74 2.62 1.45 1.50 5.12 2.69 19.90 8.06 5.69 5.63 1.28 8.02 8.10 19.81 8.05 3.80 4.16 3.00 10.19 8.17 19.83 8.04 4.05 3.15 3.11 8.00 7.70 19.79 7.17 4.64 4.49 4.06 7.45 7.93 19.79 3.12 5.02 4.39 4.10 6.64 7.18 12.70 2.98 9.08 11.57 3.69 6.70 7.79
Peak Gain CPU : 20.42X Mem : 19.8X Average Gain CPU : 3.7 - 8.1X Mem : 2.6 - 8.1X
Users should note that how the new algorithm performs is highly design style dependent. This is shown in the following graphs, for the STARS 156664 and 123351. It should be noted that setting the CRP value close to zero will give a scalar gain of 1X (no gain) in all cases.
20
15
Gain
10 5 0 50 20 10 5 2 1 0.5 0.2 timing_crpr_threshold_ps
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
25
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Gain CPU
20
Gain Memory
15
Gain
10 5 0 50 20 10 5 2 1 0.5 0.2 timing_crpr_threshold_ps
It can be clearly seen from the above illustrations that how a particular design performs with a particular threshold setting is entirely dependent upon the design style itself.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
26
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
27
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Phone: 650-584-4200, OR: 1-800-245-8005 For example, clock jitter is one such property that a designer must consider. Clock latency is also figure that is subject to some error value, as is the datapath delay value. Static Timing Analysis typically operates in an environment having a numerical accuracy that is 0 to 3% of SPICE. We can show that the error introduced by the CRP threshold value into the slack calculation is far less than other sources of error inherent to STA. This can be achieved with a simple calculation. For example Consider the following design scenarios, where we examine the datapath of a fast design, with a critical (or near critical) datapath in min and max analysis (as in a setup check). We also consider a tight maximum calculation error with respect to SPICE, in order to make the analysis realistic. Clock Speed : Clock period : CRPR threshold Maximum STA Versus SPICE calculation error : SPICE simulated maximum delay along a datapath : SPICE simulated minimum delay along a datapath : 500Mhz design, 2 nano seconds 1 pico second 3% 1.9 nano seconds 1.2 nano seconds
This is the maximum total STA error we would see in the slack calculation with respect to SPICE for this datapath, if we performed an exact calculation of CRP with report_crpr Total STA Error = Normal STA Error + maximum CRP threshold error = .057 + .001 = .058ns This is the maximum total STA error we would see in the slack calculation with respect to SPICE for this datapath if we performed a CRP calculation with report_timing. Note that the minimum total STA error is the same in both cases, as the minimum CRP threshold error is 0 . % of the maximum possible error in slack calculation due to CRPR threshold : .051% Normal STA Error: 3% Total STA Error: 3.051% Min calculation Normal STA Error = SPICE datapath timing * STA V SPICE calculation error = 1.2ns * .03 = .036ns (36 ps)
This is the maximum total STA error we would see in the slack calculation with respect to SPICE for this datapath, if we performed an exact calculation of CRP with report_crpr
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
28
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
Phone: 650-584-4200, OR: 1-800-245-8005 Total STA Error = Normal STA Error + maximum CRP threshold error = .036 + .001 = .037ns This is the maximum total STA error we would see in the slack calculation with respect to SPICE for this datapath if we performed a CRP calculation with report_timing. Note that the minimum total STA error is the same in both cases, as the minimum CRP threshold error is 0 . % of the maximum possible error in slack calculation due to CRPR threshold : .027% Normal STA Error: 3% Total STA Error: 3.027% Hence we can state that for this datapath, the error range introduced into the CRP calculation in considering minimum and maximum datapath analysis is; Range [ .027% (minpath analysis) :.051% (maxpath analysis) ] In both types of analysis, the inherent STA error that we see (3% in this case) in the datapath is far greater than the maximum error introduced by the minimum CRPR threshold (1 Pico second). The only way to remove the error from the datapath calculation is to perform transient (SPICE) simulation. Error due to imprecise delay calculation will always be presents in STA, and there is no current known method of removing it, other than performing transient simulation. So it is unrealistic that in any real design analysis scenario, the error in the CRP calculation should determine the pass or failure of a particular path.
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
29
timing_crpr_threshold_ps
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
30
SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
14 References;
1. Zejdaj, J., and Frain, P 2002 General Framework for removal of clock network pessimism Design Automation Conference 2002 proceedings 2. Transparent Latch Enhancements, application note for PrimeTime 2003.03
PrimeTime Document
Proprietary Information-Not for distribution without Synopsys Approval
31