Analyzing IC Compiler II and
PrimeTime Timing Correlation
Version 2016.03, June 2016
Copyright Notice and Proprietary Information
© [Year] Synopsys, Inc. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc.
and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All
other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is
strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys company and certain product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.
Synopsys, Inc.
690 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com
ii
Contents
Introduction ................................................................................................................................ 4
Analyzing Timing Correlation ..................................................................................................... 5
Overriding IC Compiler II Application Options ........................................................................ 6
Disabling the Timer Consistency Settings .............................................................................. 7
Providing Additional Information for the PrimeTime Run ........................................................ 8
Saving and Reusing PrimeTime Sessions .............................................................................. 8
Analyzing Correlation for Specific Scenarios .......................................................................... 9
Generating a Verbose Correlation Report .............................................................................. 9
Generating Files for the PrimeTime Run .............................................................................. 11
Allocating Compute Resources ............................................................................................ 11
Ensuring Accurate Correlation Results ..................................................................................... 13
Resolving Moved or Missing .db Files .................................................................................. 13
Appendix .................................................................................................................................. 15
Output Directory Structure .................................................................................................... 15
iii
Introduction
You can analyze the timing correlation between the IC Compiler II and PrimeTime tool
by using the analyze_timing_correlation command in the IC Compiler II tool.
The analyze_timing_correlation command performs the following tasks:
1. For the current IC Compiler II settings, generates the design files necessary to run
the PrimeTime tool for each scenario.
2. Invoke the PrimeTime tool from the IC Compiler II tool, and generates a series
endpoint timing reports for minimum and maximum delay for all scenarios.
3. Generates the corresponding IC Compiler I endpoint timing reports for minimum and
maximum delay for all scenarios.
4. Compares the endpoint timing of those reports and calculates a set of correlation
metrics.
The tool compares the worst maximum and minimum delay slack between PrimeTime
(the golden or base timing report) and worst equivalent endpoint slack from the IC
Compiler II timing report across 200,000 timing endpoints per scenario.
Based on the following criteria, an endpoint is considered to be correlating within
tolerance, or not:
|𝑆𝑙𝑎𝑐𝑘𝑝𝑡 − 𝑆𝑙𝑎𝑐𝑘𝑖𝑐𝑐2 |
≤ 3%
𝑃𝑎𝑡ℎ 𝐿𝑒𝑛𝑔𝑡ℎ𝑝𝑡
The expectation is that 95% or more of the 200,000 endpoints that have a path length of
at least 3ps in each scenario are correlated for both maximum and minimum delay.
If less than 95% of the endpoints are within these criteria at the 3% threshold, the
scenario is not considered to be well correlated and further investigation is
recommended.
The following is a portion of an example output of the analyze_timing_correlation
command, which shows the slack correlation metrics:
Correlation Metric: slack
-------------------------------------------Correlation Metric
-------------------------------------------All Endpoints
Violating Endpoints
Absolute Slack Difference on Average
Absolute Slack Difference Standard Deviation
-------------------------Value
-------------------------96.186% at 3.00% Threshold
78.000% at 3.00% Threshold
-20.994 ps
32.156 ps
---------- ------ ------- --- ---------Context metric
WNStable,
TNS NVE Unique NVE
In this correlation
--------------- --------- ---------- of timing endpoints that are considered to be
 The first
row shows
the percentage
correlated
at the -1.252
specified
correlation
PT_auto
-24.817
442 threshold
329 (3%)
 The second row shows the same calculation when considering only endpoints that
-1.197value
-10.595
121 PrimeTime
8
have aNT_auto
negative slack
in either
or IC Compiler II
Difference -0.056 -14.222 321
321
4

The third and fourth rows are the mean and standard deviation of slack differences
across all endpoints. The slack difference is |𝑆𝑙𝑎𝑐𝑘𝑝𝑡 − 𝑆𝑙𝑎𝑐𝑘𝑖𝑐𝑐2 |
The following portion of an example report shows the timing QoR as reported in
PrimeTime and IC Compiler II tools.
---------- ------ ------- --- ---------Context
WNS
TNS
NVE Unique NVE
---------- ------ ------- --- ---------PT_auto
-1.252 -24.817 442
329
ICC2_auto -1.197 -10.595 121
8
Difference -0.056 -14.222 321
321
In this table, the column named Unique NVE (number of violation endpoint) shows how
many violating endpoints exist exclusively in either the PrimeTime or IC Compiler II tool.
According to this table, the design has 8 endpoints that were seen as non-violating and
321 endpoints that were seen as over-violating in the IC Compiler II tool, as compared
with the PrimeTime signoff timing analysis, which suggests that the IC Compiler II tool is
more pessimistic.
As more than 95% of all endpoints are within threshold, this scenario is considered to be
well correlated.
Analyzing Timing Correlation
Before you run the analyze_timing_correlation command, ensure that you follow
the recommended guidelines described in the IC Compiler II Timing Correlation
Methodology Kit Application Note.
With the analyze_timing_correlation command, you must specify

A working directory for correlation analysis by using the –work_dir option.
The working directory contains the intermediate files such as design netlist,
constraints, parasitics, and Tcl scripts generated for running the PrimeTime tool, and
also the timing reports generated for correlation analysis. For more information of the
directory structure of the working directory, see Output Directory Structure.
By default the tool does not overwrite any existing files in the working directory.
However, you can force the tool to overwrite any existing files by using the
-overwrite_work_dir option. You can also force the tool to remove all files in the
working directory at the end of the analyze_timing_correlation command by
using the -clear_work_dir option.

The path to the PrimeTime executable by using the –pt_exec_path option.
Specify the path to the PrimeTime version that you use for signoff analysis.
5
The following example analyzes the correlation using the default threshold of 3%:
icc2_shell> analyze_timing_correlation –work_dir Corr \
–pt_exec_path /SNPS_TOOLS/linux64/bin/pt_shell
After you run the initial correlation analysis with the default pass rate threshold of 3%,
you can rerun correlation analysis with a different pass rate threshold value and reuse
the initial correlation data as shown in the following example:
icc2_shell> analyze_timing_correlation –work_dir Corr -overwrite_work_dir \
–pt_exec_path /SNPS_TOOLS/linux64/bin/pt_shell
icc2_shell> analyze_timing_correlation –work_dir Corr –pass_rate_threshold 2
–pt_exec_path /SNPS_TOOLS/linux64/bin/pt_shell
In this case, the second run of the analyze_timing_correlation command generates
a correlation report for the specified threshold without regenerating either the IC
Compiler II or PrimeTime timing reports.
However, if you need secondary reports with a different timing environment, such as with
and without crosstalk as shown in the following example, the subsequent call to the
analyze_timing_correlation command removes the reports in the work directory,
recreates the PrimeTime configuration, reruns the PrimeTime tool, and generate new
reports from both tools.
icc2_shell> analyze_timing_correlation –work_dir Corr -overwrite_work_dir \
–pt_exec_path /SNPS_TOOLS/linux64/bin/pt_shell \
–si_enable_analysis false
icc2_shell> analyze_timing_correlation –work_dir Corr \
–pt_exec_path /SNPS_TOOLS/linux64/bin/pt_shell \
–si_enable_analysis true
Here, the contents of the working directory (./Corr) is overwritten regardless of whether
the –overwrite_work_dir option is specified or not.
Overriding IC Compiler II Application Options
By default, the value of the following four IC Compiler II application options are
converted to their equivalent PrimeTime application variables and specified for the
PrimeTime run:

time.delay_calculation_style

time.si_enable_analysis

time.waveform_analysis_mode

time.enable_ccs_rcv_cap
To analyze correlation with different values than what you use for IC Compiler II timing
analysis, you can do one of the following:
6

Change the application options directly before you run the
analyze_timing_correlation command.

Specify one or more of the following options of the analyze_timing_correlation
command:
-delay_calculation_style zero_interconnect|auto
-si_enable_analysis true|false
-waveform_analysis_mode disabled|full_design
-enable_ccs_rcv_cap true|false
If you do not specify these options, the tool uses the current setting specified by the
corresponding application option. If you use the -delay_calculation_style
zero_interconnect option setting, the tool ignores the settings of the
-si_enable_analysis and –waveform_analysis_mode options. However, it does
not ignore the setting of the –enable_ccs_rcv_cap option. It is recommended that
you use the -enable_ccs_rcv_cap true option setting (or its equivalent app
option) for correlation analysis.
The benefit of using these options of the analyze_ analyze_timing_correlation
command to specify the settings for correlation analysis is that the tool
1. Modifies the corresponding application option settings to the specified values
2. Generates the required timing reports
3. Returns the application options to their original settings
The following example shows this behavior:
icc2_shell> get_app_option_value –name time.si_enable_analysis
false
icc2_shell> analyze_timing_correlation –work_dir Corr -overwrite_work_dir \
–save_pt_session –pt_exec_path /SNPS_TOOLS/linux64/bin/pt_shell \
–si_enable_analysis true
icc2_shell> get_app_option_value –name time.si_enable_analysis
false
The benefit of using the application options to specify the settings for correlation analysis
is that when you run multiple analyze_timing_correlation commands back-to-back,
such as when looping through scenarios manually, the application options remain
unchanged between each run of the command.
Disabling the Timer Consistency Settings
By default, the analyze_timing_correlation command invokes the
check_consistency_settings command to ensure that the environment for the timer
is consistent between the IC Compiler tool and the PrimeTime tool.
7
The consistent setttings include enabling some nondefault features in the PrimeTime
tool to match the default behavior in the corresponding feature in the IC Compiler II tool,
and disabling some default features in PrimeTime that do not exist in the IC Compiler II
tool. Using consistent settings allows for measurement of the best correlation currently
achievable.
To see the correlation with sign-off-centric PrimeTime settings, you can disable the use
of the consistency setting by specifying the -disable_compatibility_settings
option with the analyze_timing_correlation command. Using this option prevents
the tool from modifying the correlation related IC Compiler II and PrimeTime settings and
the two tools remain in their user-specified configurations.
Consistency setting
L-2016.03-SPx IC Compiler II
K-2015.12 PrimeTime
New latch modeling
Default behavior and cannot
be disabled
Enabled for correlation,
which is not the default
Crosstalk aggressor timing
windows
Not supported
Disabled for correlation,
which is also the default
The table above shows the two most common settings that are different between the
user-specified configuration of the IC Compiler II tool and the PrimeTime tool.
Providing Additional Information for the PrimeTime Run
By default, the tool generates the files necessary to run the PrimeTime tool. However,
you can specify additional or alternate information to use as follows:

To specify a script that should be sourced before linking the design in the PrimeTime
tool, use the -pt_pre_link_script option.

To specify a script that should be sourced after linking the design in the PrimeTime
tool, use the -pt_post_link_script option.

To specify a script that should be used to generate the PrimeTime reports, instead of
using the script that the tool generates, use the -pt_user_script option. When you
use this option, the tool ignores the -pt_pre_link_script and
-pt_post_link_script option settings.

To specify additional search paths to use when linking the design in the PrimeTime
tool, use the -pt_search_paths option.
Saving and Reusing PrimeTime Sessions
You can save the PrimeTime session so that it can be used in a subsequent run of the
analyze_timing_correlation command by using the –save_pt_session option.
The tool saves the PrimeTime sessions in the working directory.
To reuse a previously saved PrimeTime session, use the -use_pt_save_session
option with the analyze_timing_correlation command.
8
The PrimeTime save sessions must exist under the work_dir/saved_sessions/
subdirectory with the following name style :
<module_name>_<scenario_name>_<pt_tool_version>_auto.pt_save_session
For example
leon3mp_Func::Hot_RCworst_K-2015.06_auto.pt_save_session
Analyzing Correlation for Specific Scenarios
By default, the analyze_timing_correlation command analyzes and generates a
correlation report for every scenario in the design. However, you can limit it to specific
scenarios by using the –scenarios option. When you use this option, the tool generates
the files needed to run the PrimeTime tool for all scenarios in the design. However, it
generates the timing data and performs the correlation analysis only for the specified
scenarios.
For example, assume that your design has five active setup scenarios names Scen1,
Scen2, Scen3, Scen4, and Scen5. To analyze correlation for only the scenarios named
Scen1, Scen2, Scen3, and Scen4, use the following command:
icc2_shell> analyze_timing_correlation –scenarios {Scen1 Scen2 Scen3 Scen4} \
–work_dir Corr -overwrite_work_dir –clear_work_dir
For this example, the tool generates the files necessary to run the PrimeTime tool for all
five scenarios. However, it generates the PrimeTime timing data and performs the
correlation analysis only for the four specified scenarios.
The single analyze_timing_correlation command usage in this example is
equivalent to the following set of commands:
icc2_shell> analyze_timing_correlation –work_dir Corr –scenario Scen1 \
–overwrite_work_dir
icc2_shell> analyze_timing_correlation –work_dir Corr –scenario Scen2
icc2_shell> analyze_timing_correlation –work_dir Corr –scenario Scen3
icc2_shell> analyze_timing_correlation –work_dir Corr –scenario Scen4 \
–clear_work_dir
Generating a Verbose Correlation Report
To generate a more detailed correlation report, use the –verbose option with the
analyze_timing_correlation command.
The verbose report has four categories of endpoints, which are as follows:

All Endpoints, which includes all timing endpoints regardless of their slack or path
length value.

Threshold Endpoints, which includes only the timing endpoints for which the
absolute difference in their slack divided by the PrimeTime path length is greater
or equal to the Pass rate threshold (3%)

Violating and Non-Violating
9

Violating Only
The following is a portion of an example report that shows correlation metrics for two
categories of endpoints, violating and nonviolating endpoints and violating endpoints
only.
Correlation Metric: slack
-------------------- ------------------------ ------------All Endpoints
3.0% Threshold Endpoints All Endpoints
-------------------- ------------------------ ------------Correlation%
96.186
0.437
Total Ep Count
1135
29756
Differing Ep Count
1135
29626
Absolute Average %
4.107
0.946
Absolute Stddev %
2.816
1.112
Relative Average ps
-88.063
-20.994
Relative Stddev ps
86.575
32.156
-------------------- ------------------------ ------------Violating Endpoints 3.0% Threshold Endpoints All Endpoints
-------------------- ------------------------ ------------Correlation%
78.000
0.000
Total Ep Count
99
450
Differing Ep Count
99
450
Absolute Average %
8.953
3.248
Absolute Stddev %
7.460
4.672
Relative Average ps
-128.772
-59.103
Relative Stddev ps
226.383
113.690
This portion of the example report gives the values for a set of metrics that are
measured considering:

The endpoints in the category that meet the specified threshold, which is 3% for this
example. These values are in the second column.

All endpoints in the category, regardless of whether the endpoint meets the threshold
criteria or not. These values are in the third column.
The following table provides the definitions of these different metrics in this portion of the
example report.
Metric
Definition
Correlation
Percentage of considered endpoints that meet or exceed the
correlation criteria at the specified threshold
Total_Ep_Count
Number of endpoints considered for correlation (endpoints will
be dropped if they exceed the threshold criteria)
Differing_Ep_Count
Number of endpoints whose slack difference between the two
reports exceeds 0ps
Absolute_Average_%
The average of all percentage differences exceeding 0ps
across all considered endpoints.
10
Absolute_Stdev_%
The standard deviation of percentage differences exceeding 0
ps across all considered endpoints.
Relative_Average_ps
The average of the absolute slack difference between reports
across all considered endpoints in picoseconds.
Relative_Stdev_ps
The standard deviation of slack differences from the mean
slack difference, across all considered endpoints, in
picoseconds
The verbose report also contains information on the top five least correlated endpoints
ordered by the slack difference (in picoseconds). Negative differences indicate optimism
in IC Compiler II and positive differences indicate pessimism in IC Compiler II, as
compared with PrimeTime. The length value shown is the path length as calculated by
endpoint arrival time minus startpoint launch time.
Violating Endpoints
------------------Endpoint slack Correlation
--------- ------ ------------- ------------- -------------- -------------- ---------------------------------Diff (ps) Diff % PT_auto Slack NT_auto Slack PT_auto Length NT_auto Length Endpoint
--------- ------ ------------- ------------- -------------- -------------- ----------------------------------847.400
32.41
-0.3505
+0.4969
1.7920
2.5898 u_m/u_m_pd/pci0/pr_reg_AD__0_/D
-797.700
38.01
-0.9669
-0.1692
1.3292
2.0705 u_m/u_m_pd/pci0/pr_reg_AD__20_/D
-785.800
32.79
-0.5423
+0.2435
1.6355
2.3715 u_m/u_m_pd/pci0/pr_reg_AD__18_/D
-581.300
22.54
-0.0979
+0.4834
1.9978
2.5785 u_m/u_m_pd/sdc/r_reg_HRDATA__30_/D
-561.800
26.24
-0.6727
-0.1109
1.6069
2.1129 u_m/u_m_pd/pci0/pr_reg_AD__15_/D
Generating Files for the PrimeTime Run
To generate the design files required for the PrimeTime run, but not generate timing data
or perform the correlation analysis, use the -script_only option.
Then the analyze_timing_correlation command exits after creating the design files
for the PrimeTime run. You can use these files and run the PrimeTime tool stand-alone
as shown in the following example:
% pt_shell –f work_dir/pt_scripts/BLK1_SCN1.tcl
Allocating Compute Resources
When the analyze_timing_correlation command launches the PrimeTime tool, it
allocates the same cores to the PrimeTime run as you have allocated to the IC Compiler
II run with the set_host_options -max_core command.
11
As shown in the following graph, the IC Compiler II tool sits idle when the PrimeTime tool
is running. This means that no more than the cores allocated for the IC Compiler II run
are used, and these cores are fully utilized.
CPU usage (4 Core) of analyze_timing_correlation
500
% CPU
400
300
200
100
0
Runtime
ICC2
PT
Usually, the PrimeTime tool requires less memory than the IC Compiler II tool. However,
because both tools are simultaneously active during correlation analysis, it requires
twice the memory that the IC Compiler II tool requires for performing timing analysis on
the design, as shown in the following graph.
Memory Consumed
Memory consumption of analyze_timing_correlation
Runtime
ICC2
PT
Total
As the analyze_timing_correlation command does not use more cores than were
allocated in IC Compiler II tool, there is no need to increase the number of cores when
running this command. There is however a need to increase the amount of memory
allocated to IC Compiler II tool when running this command.
The recommendation would be to increase the memory allocation by 60% to ensure that
the command does not exceed the allocation.
12
Ensuring Accurate Correlation Results
If you correlation results are bad, before you proceed to identify possible correlation
issues, you need to ensure that the correlation analysis results are accurate.
To achieve accurate correlation results, you need to ensure that the PrimeTime timing
data is generated correctly. If the PrimeTime timing data is not generated from a fully
linked and constrained design that is comparable to the IC Compiler II design, the
correlation results will not be accurate.
The following are possible issues that could prevent accurate correlation results:







Incompatible IC Compiler II and PrimeTime settings.
If the tool identifies IC Compiler II settings that are not recommended for correlation
consistency, it issues a CORR-812 error message.
Unresolved references when linking the design in the PrimeTime tool
If there are unresolved references during linking, the PrimeTime tool issues LNK-003
information messages.
Failure to fully annotate the IC Compiler II parasitics onto the netlist in the PrimeTime
tool
Mismatches in the PrimeTime save-session versions , when the –save_pt_session
and -use_pt_save_session options are used with the
analyze_timing_correlation command
Failure to annotate the constraints in the PrimeTime tool.
For example, some IC Compiler II constraints on library objects are not supported in
the PrimeTime tool. These constraints will be dropped.
Missing or incorrectly resolved constraints.
Different logical library .db files are specified for the PrimeTime run using the
–pt_search_path option of the analyze_timing_correlation command, than
those used to create the IC Compiler II reference libraries.
After you run the analyze_timing_correlation command and generate the
correlation results, you should
1. Check the IC Compiler II log file for any error messages.
2. Check in the PrimeTime log files, which are in the <work_dir>/pt_logs/ directory, for
any error messages.
If the PrimeTime log files are zero length, which indicates the PrimeTime tool was
not launch successfully,
a. Check the <work_dir>/dump_pt/<block_name>_design_files.<int>/ directory
to see if the design files required for the PrimeTime run were generated.
These design files include, the netlist, parasitics, and constraints.
b. Launch the PrimeTime tool stand-alone, using the
<work_dir>/dump_pt/pt_scripts/scenario_<scenario_name>_auto.tcl script, to
debug interactively/.
Resolving Moved or Missing .db Files
The analyze_timing_correlation command runs the PrimeTime tool and therefore
has a dependency on the library .db files required to link the design in the PrimeTime
tool.
13
The analyze_timing_correlation command tool uses the information stored in the IC
Compiler II reference libraries (.ndm database) to determine where the .db files were
located when each reference library was compiled. This information is then used when
generating the design files for the PrimeTime run.
If the IC Compiler II reference library was compiled from .lib files rather than .db files, the
analyze_timing_correlation command is unable to resolve the necessary reference
libraries for PrimeTime.
If the locations of the .db files stored in the IC Compiler II reference library is not visible
or the .db files have moved since the reference library was created, the
analyze_timing_correlation command issues the following message when it creates
the design files for the PrimeTime run:
"The original db-file '/my/reflibs/mylib.db' has been moved or deleted”
Use one of the following methods to resolve this issue:

Specify the location of the .db files by using the –pt_search_path option of the
analyze_timing_correlation command. If you do so, the tool issues the
following message during the analyze_timing_correlation command:
"Found missing db-file '/my/reflibs/mylib.db', successfully resolve
to '/your/reflibs/mylib.db”

Recreate the IC Compiler II reference libraries using the .db files that are currently
available, which is the preferred method. This ensures that the same .db files used to
create the IC Compiler II reference libraries will also be used for the PrimeTime run.
14
Appendix
Output Directory Structure
The following is the directory structure of the working directory created by the
analyze_timing_correlation command.
<work_dir>/
dump_pt/
pt_scripts/
<block>_<scenario>_<date>.pt.tcl
<scenario>_app_vars.<checksum>.pt
<block>_design_files_<checksum>/
Netlist, parasitics, and constraint files
pt_logs/
<block>_<scenario>_<date>.log
saved_sessions/
<block>_<scenario>.<pt-version>.save_session
reports/
<block>_<scenario>_min.<tool>*rpt
<block>_<scenario>_max.<tool>*rpt
saved_status/
<tool>.recommended_app_vars.tcl
15