PrimeTime RC Delay Troubleshooting
PrimeTime RC Delay Troubleshooting
Version 1.1
TABLE OF CONTENTS
1 INTRODUCTION 4
5 RECOMMENDED READING 23
1 Introduction
PrimeTime is a chip-level static timing analysis (STA) tool for complex multi-million gate system-on-a-chip
(SoC) designs. PrimeTime’s powerful and accurate delay calculation engine allows users to perform analysis
using detailed parasitic data in SPEF or DSPF format. Library, tool, and flow qualification may include
calibration of the results from PrimeTime’s delay calculator with detailed parasitic annotation against
transistor-level simulation. In flows where users have access to SPICE sub-circuits and device models, users
may choose to perform SPICE simulation on critical paths identified by PrimeTime.
During the correlation process, users may encounter the following issues:
This application note is intended for users who have access to library characterization methods and data,
including SPICE subcircuits and device models. It is also useful for end users who want to achieve a better
understanding of delay calculation for interaction with the library provider. Prior to reading and applying the
techniques in this application note, it is highly recommended that you become familiar with the background
application notes listed in the “Recommended Reading” section.
Please note that the debugging techniques described in this application note are applicable to libraries using
nonlinear delay models (NLDMs). The techniques are not applicable to generic CMOS models. The part
related to driver_model is not applicable to CCS timing models either.
The information in this application note is related to versions 2004.06 and later.
Please note that in order to simplify the wording in this application note, transistor-level simulation will be
referred to as SPICE simulation.
Initially, we must find out if the source of the discrepancies is global due to SPICE simulation settings or
inconsistent setup between SPICE and PrimeTime.
Next, we consider the following specific situations in which discrepancies may occur:
Both PrimeTime and the SPICE simulation must use the same delay and transition time trip-points. The trip-
points determine the points on the waveform from which the delay and transition time are measured. For
example, transition time trip-points may be at 30%-70% of Vdd, and delay trip-point may be at 50% Vdd. If
different trip-points are used between PrimeTime and SPICE simulation, then the comparison is not valid.
Please note that in libraries where transition times are specified at 0%-100% of Vdd, library slew derating is
required for PrimeTime RC delay calculation. Please refer to the man page for the shell variable
rc_slew_derate_from_library.
Assuming that the previous checks have been done, what are some of the other causes of discrepancies
between PrimeTime and SPICE?
2.2.2 Are C-total and C-effective inside the library table boundaries?
Verify that the lumped capacitance (C-total) and effective capacitance (C-effective) are inside the boundaries
of the library table. These values are given by the PrimeTime command:
If C-total and C-effective are not inside the boundaries of the library table, the discrepancy may be due to
library data extrapolation. Whenever C-total and C-effective are not inside the library table, the cell delay and
output transition time must be calculated by using extrapolation techniques. In this case, one option is to
modify the design if the output capacitance value violates a design rule. This can be easily verified with:
Other option is to re-characterize the library to so that the actual output capacitance is inside the boundaries of
the lookup table.
2.2.3 Is input transition time inside the boundaries of the library table?
If the input transition time is not inside the library table, the discrepancy may also be due to library
extrapolation. Similar to C-total and C-effective, the design must be modified to meet design rule
specifications or the library must be re-characterized. In short, the cells must be used so that their operating
conditions are inside the characterization tables.
2.2.4 Is the characterization waveform applied on the input pin in SPICE simulation?
In deep sub-micron technologies, during the characterization process, a real waveform is applied on the input
of the cell to be characterized. When you do a comparison with a SPICE simulation, you must apply that
characterization waveform in the SPICE simulation, not an ideal waveform, even if the ideal waveform has
the same transition time. Otherwise, the ideal waveform could cause some significant differences in
calculated delay.
Ideal
100%
70%
50%
Real
30%
0%
Time
2.2.5 Do PrimeTime and the SPICE simulation results match for the same input transition
time at C-total or C-effective?
For a given input transition time, the user should run SPICE simulations with the output capacitance set to C-
total and C-effective. The cell delays in PrimeTime and SPICE simulation should match within about -/+1%.
This max error will allow the user to have a +/-5% max error for the sum of cell delay and interconnect delay
in PrimeTime.
If the cell delays do not match, this indicates a potential library data interpolation problem. One of the reasons
is that an insufficient number of indices have been used for characterization in the fast (nonlinear) region of
the library table. To minimize interpolation errors, the cell should be re-characterized with more table points
in the particular region of interest.
2.2.6 Do the simulations of the PrimeTime driver model and the transistor-level driver agree
for C-total and C-effective?
[Link] Background:
After back-annotation of the extracted parasitics from the layout, the PrimeTime delay calculator replaces the
instantiated driving cell with a driver model called SDM (Synopsys Driver Model). This model is a Thevenin
voltage source with a driving resistance. The parameters of this model are calculated so that the resulting
waveform (cell delay and slew) matches, as closely as possible, the actual cell output waveform when C-
effective is the load applied to that cell. For more information on this process, please refer to the PrimeTime
Delay Calculator white paper mentioned in the recommended reading paragraph.
Ceff
Cell Output Transition
Actual Driving cell Cell Input Transition
Volt
Rd
0
0 tz tz + Dt Time
Ceff
Thevenin Source
Simplified Driver
See paragraph 2.2.2 for information about the Ceff Ctotal values.
The resulting calculated model parameters rd, tz, and Dt can be obtained by the PrimeTime command:
****************************************
Report : driver_model
Driver : xxx/yy:B-->Z
Version: 2002.03
Date : Mon Mar 18 [Link] 2002
****************************************
Accuracy Settings: Rise Fall
slew_lower_threshold = 35% 35%
slew_upper_threshold = 65% 65%
input_threshold = 50% 50%
output_threshold = 50% 50%
slew_derate_from_library = 0.3
driver_model_max_error = 16%
lib_thresholds_per_lib = true
Library Inputs: (in library units)
Rising input slew = 0.370370
Falling input slew = 0.370370
Output load capacitance = 0.001881
Driver model for sense 'positive-unate':
(max) Rise Fall
--------------------------------------------------
load = 0.001881 0.001881 (pF)
delay = 0.263882 0.260043 (ns)
slew = 0.029534 0.025686 (ns without derate)
You can read in bold the four calculated values for rd, tz and dt for a max and min analysis and for a rising
and falling edge.
Another way to have this information in a more compact but less readable format is:
gives
get_att [get_pins xxx/Z] ceff_params_max
{ A {rd 2.416740e+01 2.154167e+01} {t0 2.344839e-01 2.338319e-01} {delta_t
7.828199e-02 6.975447e-02} {ceff 1.880544e-03 1.880544e-03}} { B {rd 2.267359e+01
1.972783e+01} {t0 1.92315e-01 1.97800e-01} {delta_t 7.343002e-02 6.388229e-02} {ceff
1.880544e-03 1.880544e-03}} and
The slight value differences that one might get between these two different commands are due to the fact that
in report_driver_model, we specify in the command line the input slew. So this is a round-off value. When
looking at the ceff_params_max/min attribute, the input transition is the one from the design, so the
accuracy is slightly higher.
[Link] Comparison:
After you get these parameters from PrimeTime, you can simulate in SPICE the actual driving cell loaded by
the lumped capacitance and the effective capacitance; and the driver model (voltage source with a serial Rd
resistance) loaded by the lumped capacitance and the effective capacitance. At this stage, the resulting
waveforms should really match, especially in the region between the trip points. User can take advantage of
PrimeTime SI command write_spice_deck for this task.
RC network delay is defined as the delay between a logic transition on the driving output pin to a logic
transition on an input load pin. When the RC network delay or the driver and load transition time between
PrimeTime and SPICE simulation do not match, it is called an RC network timing discrepancy. This section
describes several possible causes.
2.3.1 Is the driver cell timing discrepancy small?
If the driver cell timing between PrimeTime and SPICE simulation does not match within reasonable
expectations, this should be investigated first. Please refer to the previous section for more information.
2.3.2 Is the RC-network definition the same in both PrimeTime and the SPICE simulation?
It is possible that the units, such as for resistor and capacitor values, are not specified correctly either in the
parasitic file (SPEF or DSPF) or in the SPICE simulation file. The SPICE deck must contain the same
resistors and capacitors as the ones in the SPEF/DSPF file used by PrimeTime. The units must be also the
same in the .db file. A useful command in PrimeTime to check the units is report_units.
Units
---------------------------------------------
Capacitive_load_unit : 1e-12 Farad
Current_unit : 0.001 Amp
Resistance_unit : 1000 Ohm
Time_unit : 1e-09 Second
Voltage_unit : 1 Volt
*T_UNIT 1 NS
*C_UNIT 1 FF
*R_UNIT 1 OHM
*L_UNIT 1 HENRY
These units are the values used in Spice language.
2.3.3 Do PrimeTime and the SPICE simulation use the same driver arc?
In order for the comparison to be valid, PrimeTime and the SPICE simulation must use the same driver arc. If
the network driver has a fan-in of one, such as for an inverter or buffer, both the cell delay and output
transition are derived from the same arc. If the network driver has a fan-in of greater than one, such as for a
multi-input gate with multiple arcs, PrimeTime propagates only one of the arcs according to whether min or
max analysis is active and according to the slew propagation mode. Depending on the setting of the variable
timing_slew_propagation_mode , this can be worst slew propagation mode or worst arrival propagation
mode. For the worst slew mode, the worst input slew of multi-input gates is always propagated, i.e. this worst
input transition is used for the delay and slew calculation for that cell. For the worst arrival mode, the slew of
the latest-arrival input is used for delay and slew calculation for that cell. A SPICE simulation, on the other
hand, always uses the actual input slew of that cell.
So, once it has been verified that the cell timing matches with the SPICE simulation, the RC-network timing
must be verified using the same arc that was propagated by PrimeTime. One way to ensure this is by setting
the same side-inputs in both PrimeTime and the SPICE simulation. For more information, see the man pages
for the report_delay_calculation command and the timing_slew_propagation_mode variable.
This is done automatically if the user uses write_spice_deck utility in primetime.
IN
A
CLOCK
B
Side Input
timing optimism will be unavoidable in those cases. For example, if the actual waveform in setup analysis is
slower than the one used during characterization, the PrimeTime delay will be underestimated.
100%
70%
50%
30%
0%
time
Transition Time
Fastest waveform
Typical waveform
Slowest waveform
Figure 4: Characterization waveform
Some libraries are characterized with a pre-driver cell. For better correlation results this pre-driver cell must
be used as well in the design.
3.1.1 Discrepancies between a logical netlist and its associated parasitic data.
The logical netlist describes the connectivity of the leaf cells and hierarchical cells in design and is typically
in the form of a Verilog netlist. The parasitic data represents the physical characteristics (resistance,
capacitance, inductance) of the nets described in the logical netlist. This data is extracted from the physical
database and is typically in the form of a SPEF file.
There are valid sources of discrepancies between these two representations of the nets in the design, but these
discrepancies should be investigated. Encountering either of the following messages warrants a detailed
examination of the parasitic extraction flow/data to verify that these conditions are to be expected an not an
indication of a serious problem with the parasitic annotation data.
[Link] PARA-006 - Error: Driver/Load pin 'xx' is missing in the RC annotation for net 'xxx'.
Ignoring the incomplete RC annotation.
This is an error because a leaf or connected hierarchy pin is missing in the annotation file. PARA-006 causes
a wire load model to be used instead of the parasitic annotation for all net arcs driven by that cell.
The error PARA-006 indicates that PrimeTime has encountered a connection to a leaf cell pin that does not
have a corresponding complete network description in the SPEF file. There are two ways of resolving this
type of inconsistency. One is to complete the network using the either the -complete_with option to
read_parasitics or the complete_parasitics command. If you choose not to complete the parasitic network,
any SPEF annotation that exists for that net is discarded and the parasitic data for that net is retrieved from the
appropriate wire load model.
[Link] PARA-007- Warning: Unconnected hierarchy pin 'xx' is missing in the RC annotation for
net 'xxx’
The warning PARA-007 indicates that PrimeTime has encountered a connection to a hierarchical pin in the
logical netlist that does not have a corresponding network description in the SPEF file.
In this case, the assumption is that this segment does contribute to the parasitic effects of that net. The
contribution to the parasitics is derived from the appropriate wire load model, or as specified by the
complete_parasitics command or the -complete_with option to read_parasitics.
Unconnected
hierarchical Pin
PARA-007 Warning
PARA-006 Error
No Warning
BLOCK A
Figure 5: PARA-006/7 situations
Thresholds for rise/fall transition times and delay must be defined in the libraries. They can also be specified
with shell variables. However, in order to use several libraries defined with different set of trip points, it is far
better if they are defined in the library.
The rc_*_threshold_* variables specify the trip-points used for computing transition times and delays.
If this information is not in the library and you cannot find it anywhere, you need to get the information from
the library provider.
PrimeTime gets the threshold information using the following order of priority:
• Default case (when lib_thresholds_per_lib is true)
• Variables from the library containing the pin
• rc_*_ threshold_* variables if they are set
• main library (first library in the link path)
• Default values (20%/80% slew, 50% delay, 1 as slew-derate)
• lib_thresholds_per_lib is false
• rc_*_threshold_* variables if they are set
• main library (first library in the link path)
• Default values (20%/80% slew, 50% delay, 1 as slew-derate)
See the man page and section [Link] for more information on the lib_threshold_per_lib variable.
In addition, the RC delay calculation is not applied to a transition going to or from Z. So the RC-004 warning
never shows up for a disable or enable timing arc.
This message indicates that the library cell delay or output slew does not increase with increasing load
capacitance. The library issues must be resolved. You can use the report_driver_model command to test the
capacitance-sensitivity of the library data. It calculates the impact of an increase of the loading capacitance by
1% on the delay. The delay and the slew must increase in this case.
This problem can be caused by a library extrapolation, an incorrect value for the transition time trip-points, or
not enough significant digits in the NLDM tables.
Example:
The warning is issued because d-delay (increase of delay with respect to increase in load) is negative. A
methodology to analyze this issue is available in Appendix A. It is also recommended that the library be
analyzed with the Synopsys Liberty Screener. This tool screens the library with criteria such as non-
monotonic behavior, number of significant digits, min/max capacitance values, and min/max transitions
values. For more information on this tool, see Appendix C.
PrimeTime could not find driver-model parameters that effectively match the library delay, slew, and
sensitivity to capacitance. Usually this is because the trip-points are not set correctly or the library data is
inaccurate, with not enough precision when the library was characterized. If that case, you can increase the
value of the shell variable rc_ceff_delay_min_diff_ps from 0.25 to 0.5 or 1.0 until the library can be fixed.
This variable specifies the tolerance used by PrimeTime for determining the effective capacitance by looking
at the driver cell delay.
If doubling or quadrupling this value does not stop the RC-004 warnings, it is more likely that the problem is
due to incorrect trip point setting. Note that increasing the tolerance setting helps prevent calculation failures,
but also adversely impacts the accuracy of those calculations that previously did not fail. See the man page on
the variable for more information.
This can only happen if the read_parasitics command was incorrectly used with the ‘-pin_cap_included’
option. Obviously, if PrimeTime incorrectly subtracts the pin capacitance from the network, Ctotal can be
negative, which prevents the delay calculator from calculating Ceff.
This can only happen if the connectivity of the annotated parasitics does not match that of the design. Check
to see if there was an accompanying PARA-006/PARA-007 message (missing pin in the parasitics) or LNK
message (unconnected pin in the design) for the net.
[Link] Invalid pole-residue model
Warning: Failed to compute C-effective for the timing arc (xx/yyy) i1/A-->Z
(rising positive-unate) because the RC network has an invalid pole-residue
model[r/f inp_slew = 0.028226/0.028226, out_cap = 0.003015 (lib units)] (RC-
004)
This message indicates that the RC data is represented in terms of pi models R/C/R with additional poles and
residues. This model is used to compute the slew at the driver pin. This can only happen with wrong pi-model
data imported from RSPF or SPEF RNETs.
This can only happen if one of the drivers on a multi-driven net has an unconnected from-pin. In that case,
there is also a LNK-22 warning for the unconnected input and an RC-007 because of the multi-drive
structure.
As previously mentioned, the driver model consists of a voltage ramp in series with a resistor. The resistor
helps smooth out the voltage ramp so that the resulting driver waveform has similar curvature to that of an
actual transistor driver. An Rd adjustment takes place when the two following conditions are verified:
U1 U2
Rd=small U2
V(t)
Thevenin
Source
By default, PrimeTime obtains extra pessimism in min analysis mode by not using slew-degradation.
t70
t50
Network delay
Driver transition
time
Figure 8: RC-009 case: second condition
By default, this adjustment and the warning only take place when in addition to the first condition; the net
delay is greater than the driver slew, because it is in this case that the loss of accuracy occurs. Indeed this is
expected because the network delay depends upon the driver waveform near and beyond the later slew trip-
point. This is precisely the aspect of the waveform most affected by the drive resistance.
This is controlled with the shell variable rc_filter_rd_less_than_rnet.. See man page for more information
on that variable.
The RC-009 mechanism is controlled by a threshold parameter value that assumes high-resolution RC
extraction (i.e. many RC segments for very resistive nets). If low-resolution RC is used, then be sure to set
rc_filter_rd_less_than_rnet true to avoid too many RC-009 messages.
For users who are concerned with extremely high accuracy and wish to calculate the difference between
PrimeTime's driver and network timing results compared to transistor simulation (SPICE), these messages
can be used to pinpoint areas to investigate to determine the accuracy of the empirical driver models.
Notice usage of CCS models gets rid of this accuracy issue.
Otherwise, the RC-009 messages can be safely suppressed. Use the command 'suppress_message RC-009'.
The PrimeTime delay calculator uses a Reduced Order Model to model the behavior of the network. The
following warnings are related to some failure in the network calculation.
3.4.1 RC-005 Warning: Calculation Failure
Warning: Failed to compute the RC network delay
from the pin 'xxx/yy'
to the pin 'zzz/x'
in the network 'xx'. (RC-005)
Depending on which other warnings are produced by the delay calculator, you can find the reason why this
warning is showing up.
nom_process: 1.5;
nom_voltage : 1.62;
nom_temperature : 105.
Use:
In this example, we can obviously see that the Rail Voltage of the second library is erroneous.
You have to correct the library or use the main library set of trip-points by setting the variable:
lib_thresholds_per_lib to false (see man page for more information).
This appears as the most common condition for RC-005: the lib_thresholds_per_lib variable is true
and the driver voltage swing does not cover all the trip-points of a load pin.
Another common cause of this problem is using a library without a default operating condition. When this
occurs, you can either fix the library or use the set_operating_conditions command on the affected cells.
the multi-driven net 'IA1', so detailed RC delay calculation cannot be used. (RC-
002)
This RC-002 message indicates that net A1 is controlling the switching activity of only a subset of the drivers
of a multi-driven net. The switching activity of the remaining drivers is uncertain, so detailed RC delay
calculation cannot be used. A from-net (A1 in this case) does not cover all of the drivers on a multi-driven
net. This multi-drive condition is unsupported by PrimeTime. Instead, the load is assumed to be the total
capacitance of the multi-driven net divided by the number of drivers. Ensure all drivers are switched by each
from-net (i.e. that they are wired in parallel), or annotate delays and transition times if you seek greater
accuracy than the lumped fallback analysis can provide.
You may have RC-005 warning as well, as described in section [Link]. However, unsupported multi-drive
conditions will fail cell-arc delay calculation, but a valid driver-model is built for the fallback data at
Ctotal/zero and is used to drive the net. The RC-005 message is for problems specific to net delay calculation
only.
There can be an RC-008 message as well: see section 3.6 for more information.
This message indicates that a net connects to more than one pin on a driver of the multi-driven net. Therefore,
detailed RC delay calculation cannot be used. Instead, the load is assumed to be the total capacitance of the
multi-driven net divided by the number of drivers.
In case of one of the previously described failures, a fallback calculation has been selected to guarantee a
conservative analysis: C-total is used in max analysis mode and C-zero min analysis mode. However if
PrimeTime cannot determine that these fallback values are pessimistic, then it issues an RC-008 message. So
this is a supplemental warning that may be due for example to a multi-driven network switching faster than
the min delay for this cell or in case of a library extrapolation problem that would return a negative slew.
Users should fix the problems associated with the earlier delay calculation warnings, or fix the library or use
annotated delay and slew information obtained by circuit simulation.
4 Conclusion
This document can help you efficiently analyze, understand, and debug the most frequent issues encountered
in PrimeTime analysis with back-annotated detailed parasitics. All the errors and warnings described here can
result in the loss of accuracy and pessimism in the analysis, so it is important to carefully examine them. If
the existing data structure is unsupported and unavoidable, it is recommended that you use annotated delay
and slew information obtained by circuit simulation.
5 Recommended Reading
The following documents are recommended for a deeper understanding of PrimeTime’s RC Delay Calculator.
Please contact your Synopsys Applications Consultant for a copy.
[1] “Understanding Delay Calculation with Detailed Parasitics in PrimeTime”, PrimeTime white paper
from Synopsys, Inc.
[2] “Library Qualification Guidelines for PrimeTime”, PrimeTime Application Note, Synopsys, Inc.
If the PrimeTime delay calculator gives an RC-004 failure calculation message as described in step 1, you can
analyze the potential issues for the cell:
• Is this cell used within the boundaries of the library table (as required in section 2.2.3)?
• Does the cell have monotonic behavior (as required in section [Link])?
Step 1:
Look at one of the RC-004 messages from the log file:
Step 2:
pt_shell> remove_annotated_parasitics
Step 3:
pt_shell> set_annotated_transition -rise 0.0 ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_clk
pt_shell> set_annotated_transition -fall 0.0 ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_clk
Step 4:
pt_shell> set_load -subtract_pin_load 0.0784132 [get_nets -of_object \
[get_pins ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_rd_data[29]]]
We annotate the load that shows up in the warning message. We subtract the pin loads because PrimeTime
adds them automatically.
Step 5:
pt_shell> report_delay_calculation -from_rise 0.0 -from_fall 0.0 –from \
ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_clk –to \
ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_rd_data[29]
Step 6:
set_load -subtract_pin_load [expr 0.0784132*1.01] [get_nets -of_object \
[get_pins ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_rd_data[29]]]
Step7:
report_delay_calculation -from_rise 0.0 -from_fall 0.0 –from \
ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_clk –to \
ivg/ivg_comp_fifo0/ivg_comp_fifo_m1/p1_rd_data[29]
Step8:
Look at the reports from the delay calculations:
Rise Delay
Z = 1.2892
scaling result for operating conditions
multiplying by 1 gives 1.2892
Fall Delay
C = -1.2727 D = 18.1818
Z = 1.2892
scaling result for operating conditions
multiplying by 1 gives 1.2892
Cell Delay
rise: 1.2892
fall: 1.2892
Transition rise
transition = 0.0834543
Table is indexed by
(X) input_pin_transition = 0
(Y) output_net_total_cap = 0.0784132
Relevant portion of lookup table:
(X) 0.0900 (X) 0.1800
(Y) 0.0660 (Z) 0.0730 (Z) 0.0680
(Y) 0.1320 (Z) 0.1030 (Z) 0.0990
Z = 0.0834543
scaling result for operating conditions
multiplying by 1 gives 0.0834543
Transition fall
transition = 0.0834543
Table is indexed by
(X) input_pin_transition = 0
(Y) output_net_total_cap = 0.0784132
Relevant portion of lookup table:
(X) 0.0900 (X) 0.1800
(Y) 0.0660 (Z) 0.0730 (Z) 0.0680
(Y) 0.1320 (Z) 0.1030 (Z) 0.0990
Z = 0.0834543
scaling result for operating conditions
multiplying by 1 gives 0.0834543
Library: ‘custom_arrays’
Library Units: 1ns 1pF 1kOhm
Library Cell: ‘dual_64x64_ram_con0’
arc sense: falling_edge
arc type: cell
Units: 1ns 1pF 1kOhm
Rise Delay
Z = 1.2882
scaling result for operating conditions
multiplying by 1 gives 1.2882
Fall Delay
Z = 1.2882
scaling result for operating conditions
multiplying by 1 gives 1.2882
Cell Delay
rise: 1.2882
fall: 1.2882
Transition rise
transition = 0.0837988
Table is indexed by
(X) input_pin_transition = 0
(Y) output_net_total_cap = 0.0791973
Z = 0.0837988
scaling result for operating conditions
multiplying by 1 gives 0.0837988
Transition fall
transition = 0.0837988
Table is indexed by
(X) input_pin_transition = 0
(Y) output_net_total_cap = 0.0791973
Relevant portion of lookup table:
(X) 0.0900 (X) 0.1800
(Y) 0.0660 (Z) 0.0730 (Z) 0.0680
(Y) 0.1320 (Z) 0.1030 (Z) 0.0990
Z = 0.0837988
scaling result for operating conditions
multiplying by 1 gives 0.0837988
Furthermore, from the report you will also notice the following portion of the lookup table:
which says that (X), meaning the input pin transition, started from 0.0900, whereas in our case (look at the
RC-004 message) it is 0.0, which is outside of the above table. So the cell is not used in its characterization
range, and some extrapolation inaccuracy is expected. A cell must always been used in its characterization
range. See section 2.2.2 for more information on the characterization range.
These issues can also been analyzed by the Liberty Screener: see Appendix C for more information.
Because clock signals must typically drive a large number of loads, clocks are often buffered to provide the
drive strength necessary to reduce clock skew to an acceptable level. A large clock network might use a large
number of drivers operating in parallel. These drivers can be organized in a “mesh” or “spine” pattern to
distribute the signal throughout the chip. If a design has 1,000 drivers in parallel driving 1,000 loads,
PrimeTime must keep track of one million different timing arcs between the drivers and loads. Timing
analysis of such a network can consume a large amount of CPU and memory resources.
For better performance, PrimeTime can reduce the number of timing arcs that must be analyzed. When the
reduction feature is enabled, PrimeTime selects one driver in a parallel network and analyzes the timing arcs
through that driver only.
• timing_reduce_multi_drive_net_arcs
• timing_reduce_multi_drive_net_arcs_threshold
The first of these two variables can be set to true or false to enable or disable parallel driver reduction. By
default, it is set to false and no reduction is done. When it is set to true, during design linking,
PrimeTime checks for the presence of nets with multiple drivers. If it finds a net with driver-load
combinations exceeding the threshold specified by the threshold variable, it reduces the number of timing arcs
associated with the drivers of that net.
The threshold variable specifies the minimum number of timing arcs that must be present in order to trigger a
reduction. By default, it is set to 10,000, which means that PrimeTime reduces the timing arcs of a net if the
number of drivers multiplied by the number of loads on the net is more than 10,000. In typical designs, this
large number only occurs in clock networks.
PrimeTime performs driver reduction for a net when all of the following conditions are true:
• The number of driver-load combinations is more than the variable-specified threshold (10,000 by default).
• The driver cells are nonsequential library cells (not flip-flops or latches and not hierarchical).
• All drivers of the net are instances of the same library cell.
• All the drivers are connected to the same input and output nets.
After layout is complete and detailed parasitic information becomes available, it is not possible to annotate
this information on a reduced network. To get accurate results, you can use an external simulator such as
SPICE to get detailed delay information for the network.
Then you can annotate the clock latency values and transition times on the individual clock pins of the
sequential cells, while still allowing PrimeTime to treat the reduced network as ideal, with zero delay.
This technique provides reasonably accurate results, while being very efficient because the clock network
timing only needs to be analyzed once, even for multiple PrimeTime analysis runs.
If you back-annotate the design with the read_sdf command, any annotations on the reduced timing arcs are
ignored. PrimeTime issues a PTE-048 informational message when this happens. You can suppress these
messages with the following command:
If you write out SDF with the write_sdf command, no interconnect delays are generated for the reduced
network.
Reducing parallel drivers only affects the timing arcs analyzed by PrimeTime, not the netlist. Therefore, it
does not affect the output of the write_changes command.
The Liberty Screener is a utility available to check libraries. You must have access to the library source in
order to use this tool. Please note that the settings in the Liberty Screener should be adjusted to adapt to your
particular technology.
Please contact your Synopsys Applications Consultant for information on how to obtain the Liberty Screener.
Number of significant • Check whether table values have enough significant digits
digits
Usage:
Example: