Академический Документы
Профессиональный Документы
Культура Документы
Application Note
Introduction to
Advance Analysis Engine (AAE)
Release 12.0
Rev #2.1
Jan-2013
Table of Content
Purpose ............................................................................................................................... 3
Audience ............................................................................................................................. 3
Overview ............................................................................................................................. 4
Unified delay calculation for base and SI ......................................................................... 4
SI Delay annotated on cell arc and net arc individually .................................................. 5
High scalability with multi-CPU ........................................................................................ 6
High accuracy using advance delay calculation features .............................................. 6
Equivalent waveform model (EWM) ............................................................................ 6
Waveform Propagation ................................................................................................ 7
Supports all timing models in the industry ...................................................................... 8
Use Model ........................................................................................................................... 9
Migration from Signal Storm to AAE for Base delay ....................................................... 9
Migration from CeltIC to AAE for xtalk delay and glitch analysis ................................ 10
Library Models ........................................................................................................... 10
CeltIC cannot be run with AAE as the base delay calculator ..................................... 10
Delay Measurement difference .................................................................................. 10
Timing Iteration Difference......................................................................................... 10
Driving Cell Constraints ............................................................................................. 11
Slow Slew Propagation Difference ............................................................................ 11
CeltIC Compatibility Mode ......................................................................................... 11
Reporting Difference .................................................................................................. 11
Un-supported Flow Difference ................................................................................... 11
Ground all coupling capacitors for nominal delay ...................................................... 11
CeltIC to AAE variable mapping ................................................................................ 12
Delay Comparisons with Spice ....................................................................................... 16
ECSM-EWM-WFP vs. Spice...................................................................................... 16
ECSM-EWM vs. Spice ............................................................................................... 16
Without EWM/WFP .................................................................................................... 17
Purpose
This application note can be used as adoption guide for new advanced delay calcu-
lation engine in ETS. This document also cover advance delay calculation features
like Equivalent Waveform Model and Waveform Propagation which increase delay
computation accuracy in ETS release 12 or higher. This document also describes how
to enable these features.
Audience
This application note may be of interest to customers who are currently using or mi-
grating to ETS release 12 or higher. Also help customers in enabling advance delay
calculation features for accurate delay calculation at cost of about 10% increase in
runtime.
Overview
Advance Analysis Engine (AAE) is a new unified delay calculation engine in encounter
timing system that simultaneously computes nominal (base delay) and cross talk delays.
AAE architecture enables high scalability with multiple CPUs, thus provide fast
turn-around times in delay calculation. AAE also provide different options to trade off
between accuracy and runtime. AAE cross-talk delay annotation methodology reduces
pessimism and helps in timing closure.
AAE supports advanced features like waveform propagation and equivalent waveform
models to improve accuracy in delay calculation. Traditional delay calculators use the
delay as function of input slew and output load. This methodology cannot produce desired
accuracy that new technologies demand. To achieve accuracy, waveform shape is re-
quired to be factored into delay. The equivalent waveform model (EWM) computes an
equivalent response at each receiver based on the waveform shape at the receiver input
and adjusts the interconnect delay. This adjustment in delay compensates for inaccura-
cies that delay calculation incurs in the next stage due to lack of waveform shape infor-
mation. EWM provides a technique to improve accuracy with respect to Spice.
Waveform shape has a significant effect on delays. Traditionally, delay calculators use a
single normalized driver waveform for specific slew value at the cell input to compute
response on the output of the cell. This method is prone to error when driving
characteristics of actual driver in circuit is different than the input waveform used to
characterize the library cells. By preserving actual waveform and using it at an input,
improves delay accuracy significantly.
AAE supports CeltIC compatibility mode, in which AAE SI delays closely correlates with
CeltIC.
The traditional SI engine computes SI delay by measuring time difference between no-
minal and noisy waveforms. Nominal delay differences between separate base delay and
SI delay engines result into inaccuracies.
AAE unified delay calculation does not warrant nominal delay computation. Thus AAE
reports total delay in timing reports and does not report SI delay separated for data path.
However AAE has an option to report nominal and SI delays separated.
Most of industry SI engines annotates delay x2+y1 on the net driven by AND/Y pin. Thus,
path going through AND/A incur additional pessimism. However AAE is capable of an-
notating SI delay on corresponding cell arc thus reduce pessimism.
If the user wants to annotate total SI delay on net to correlate with other engines, they can
use following command.
AAE architecture allows parallelization very effectively, thus runtimes significantly im-
prove as number of CPUs increase. When switching from single CPU usage to four
CPUs, runtime improves by about 3.5 times. In the case of 8 CPUs, runtime improves by
7 times.
Normalized Actual
Driver Waveform
Waveform
Fig. 1 Delay Calculation without EWM
A predefined waveform (normalized driver waveform) from the library based on single
input slew value is used as stimulus when a stage is analyzed in delay calculation. This
input slew is measured out of an actual waveform computed during the previous stage
analysis, which may have entirely different characteristics compared to the normalized
driver waveform used in current stage. As a result, delay impact due to the waveform
shape differences are lost.
Actual
Fig. 2 Delay Calculation with EWM Waveform
When EWM is enabled, it computes the delay impact of waveform shape on the receiver
cell and adds this delay impact to the interconnect delay thus providing an overall im-
provement of path delay accuracy.
When EWM is enabled in SI analysis, it also provides a delay adjustment based on re-
ceiver noise response to the noisy transition. This helps to reduce SI pessimism that
would be reported if total delay was measured on a noisy waveform at a receiver input.
Waveform Propagation
Waveform shape has significant effect on delay. Traditionally, delay calculation uses a
single normalized driver waveform for specific slew value at the cell input to compute
response on the output of the cell. As shown in figure 3, different waveform shapes that
have same slew can produce different delays. Delay accuracy is a function of the input
waveform shape even if the waveform have same slew. If an input waveform shape is
different than the input waveform used for the cell characterization, delay accuracy is
affected significantly. For example, take two libraries characterized with predriver cells
BUFX16 and BUFX2. When the library where BUFx16 is used as a predriver, a more
accurate delay on all the instances driven by BUFX16 will be reported. In this example
instance I4 produces more accurate results as its input waveform matches with norma-
lized driver waveform. Accuracy of other cells is impacted due to difference in predriver
vs. actual driving cell. The waveform propagation feature addresses this problem by
storing the actual waveform rather than a single slew value at the input of each cell, thus
facilitating actual waveform propagation through the path.
Waveform propagation is supported in both graph based and path based analysis modes.
• ECSM, ECSM-Noise
• CCS, CCS-Noise
• NLDM
Waveform propagation using ECSM models will be more accurate with additional
receiver pincap points. Cadence recommends at least 8 pincap threshold points. These
points are 90%, 70%, 50%, 40%, 30%, 20%, 10% and 0.01% of VDD for fall transition and
10%, 30%, 50%, 60%, 70%, 80%, 90%, and 99.99% of VDD for rise transitions.
Use Model
AAE is the default delay calculation engine in ETS release 12.0. However, the user can
switch betweeen SignalStorm and AAE engines using following command
Default: false
• Default input transition is set to 0.1ps in Signal Strom and 4ps in AAE. This default
value can be changed using set_input_transition_delay command. Any value set
below 4ps is ignored by AAE.
• AAE can support driver and receivers at difference voltages. Slew and Delay
measurement threshold are scaled as per voltage ratio between driver and re-
ceiver. Signal Storm always assumes receiver is at same voltage as driver.
• Signal Storm uses default delay, when fanout for a net exceeds the value specified
by set_use_default_delay_limit command. AAE does not honor this command.
AAE always computes actual delay for high fanout nets as well.
• AAE and Signal Strom use different extrapolation algorithms. This result into delay
differences when input slew and/or output loads exceed maximum table range by
more than two times.
• If case of missing parasitic on a net, AAE perform RC extraction if physical data is
available. Signal Storm does not perform RC extraction. It uses wire load models
for those nets.
Migration from CeltIC to AAE for xtalk delay and glitch analysis
Library Models
CeltIC crosstalk analysis uses CDB models. AAE does not require CDB models. AAE
analysis is done based on ECSM and CCS models. Both CeltIC and AAE can use CDBs
for glitch analysis.
CeltIC crosstalk analysis requires SignalStorm as the base delay calculator. If the user
does not change the delay calculation engine to SignalStorm when trying to run CeltIC,
then an ERROR message will be issued telling the user to either run AAE for SI delay or
enable SignalStorm for base delay.
When CDBs are present, CeltIC propagates noisy waveform to first CCC (channel con-
nected component) of the receiver and measures the SI push-out based on the noisy
waveform at outpt of the first CCC of the receiver. This essentially accounts for the noise
response of receiving cell. The user needs to enable EWM in AAE for similar effect. EWM
is not enabled by default.
CeltIC measures SI delay on receiver inputs for cells which do not have CDB models.
However, AAE can perform EWM based analysis on ECSM/CCS models. In such cases,
users may potentially see pessimism in CeltIC delays.
When doing timing window iterations, CeltIC does one additional iteration than the
number specified by the user. If the user wants a total of 3 SI iterations, then they will
specify set_tw_convergence –iterations 2. AAE specifies the total number of desired SI
iterations. If the user wants a total of 3 SI iterations, they will specify set_si_mode
–num_si_iteration 3. The number specified for AAE should be CeltIC’s number plus one.
CeltIC crosstalk analysis asserts the default slew on the last CCC inside the specified
set_driving_cell constraint rather than the cell input pin when the specified cell is a mul-
ti-CCC driving cell. AAE asserts the default slew on the cell input pin, which is more
accurate. This can lead to slew differences on the primary inputs that propagate
throughout the downstream path and affect the SI result.
CeltIC crosstalk analysis propagates the input slew from the driver cell input to the input of
the victim’s driving CCC and uses that to calculate the victim’s slew. This slew propa-
gation can be less accurate in the cases of slow slew. AAE computes the slew at the
victim net due to the input slew of the driving cell, thus providing a more accurate slew in
cases of slow slews.
AAE supports CeltIC compatibility mode. AAE changes delay calculation algorithms to
match with CeltIC’s SI delay computation. AAE separates incremental delays for both
clock and data path in timing reports, when CeltIC compatibility mode is enabled. It also
lumps total SI delay on the stage and annotates on net to match with CeltIC methodology.
This mode is provided to help in migration from CeltIC to AAE. Cadence does not rec-
ommend using this mode for signoff. Some of algorithms in CeltIC compatibility mode are
slower than default mode.
Reporting Difference
AAE reports all the attackers to a particular victim net, whether they are active or filtered
attackers. CeltIC reports only active attackers in it’s SI report.
The read_sdf flow is not supported for AAE. CeltIC crosstalk analysis can use a base
SDF file and do SI-only analysis. AAE does not support SI-only delay calculation be-
cause it is a single delay calculation engine performing base plus SI delay calculation at
the same time when SI is enabled. The read_twf flow is not supported for AAE.
Celtic computes SI delay by computing time difference between nominal and noisy
waveforms. It does not ground coupling caps to compute nominal waveform. To match
AAE behavior ground all coupling caps using following celtic variable.
set_noise_parm delay_ground_all_coupling 1
caplimit No equivalent
slow_slew No equivalent
create_spice_deck create_spice_deck
get_delay_cal_mode
report_noise -delay max report_delay_calculation -max -si -from AAE requires a from/to for reporting
port_or_pin_name -to port_or_pin_name the SI delay information
report_noise -delay min report_delay_calculation -min -si -from AAE requires a from/to for reporting
port_or_pin_name -to port_or_pin_name the SI delay information
restore_noise_dc_tolerance No equivalent
set_glitch_check -data_limit <value> set_si_mode -receiver_peak_limit <value> There is only 1 receiver peak limit in
-latch_limit <value1> -clock_limit AAE, so this is equivalent to setting
<value1> all three limits in CeltIC to the same
value
set_glitch_check -dc_tolerance <val- set_si_mode -input_glitch_threshold <value> There is only 1 DC tolerance limit in
ue> AAE, so this is equivalent to setting
the single DC tolerance limit in
CeltIC
set_glitch_derate No equivalent
set_noise_dc_tolerance No equivalent
set_noise_lib_pin No equivalent
set_simwrap_mode set_simwrap_mode
set_skip_attacker set_quiet_attacker
set_tw_convergence -iterations value set_si_mode -num_si_iteration value The value specified in AAE should
be CeltIC’s value + 1
Without EWM/WFP
• Average Path Delay Difference -3.521%
• 3-Sigma : 8.673