PrimeTime

Variables
Version F-2011.12, December 2011
Copyright Notice and Proprietary Information
Copyright © 2011 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.

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.
Registered Trademarks (®)
Synopsys, AEON, AMPS, ARC, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, Certify, Chipidea,
CHIPit, CODE V, CoMET, Confirma, CoWare, Design Compiler, DesignSphere, DesignWare, Eclypse, Formality, Galaxy
Custom Designer, Global Synthesis, HAPS, HapsTrak, HDL Analyst, HSIM, HSPICE, Identify, Leda, LightTools, MAST,
MaVeric, METeor, ModelTools, NanoSim, NOVeA, OpenVera, ORA, PathMill, Physical Compiler, PrimeTime, SCOPE,
SiVL, SNUG, SolvNet, Sonic Focus, STAR Memory System, Syndicated, Synplicity, Synplify, Synplify Pro, Synthesis
Constraints Optimization Environment, TetraMAX, the Synplicity logo, UMRBus, VCS, Vera, and YieldExplorer are
registered trademarks of Synopsys, Inc.
Trademarks (™)
AFGen, Apollo, ASAP, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, Columbia-CE, Cosmos,
CosmosLE, CosmosScope, CRITIC, CustomExplorer, CustomSim, DC Expert, DC Professional, DC Ultra, Design
Analyzer, Design Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon Access, Discovery, EMBED-IT!, Encore,
EPIC, Galaxy, HANEX, HDL Compiler, Hercules, Hierarchical Optimization Technology, High-performance ASIC
plus
Prototyping System, HSIM , i-Virtual Stepper, IICE, in-Sync, iN-Tandem, Intelli, Jupiter, Jupiter-DP, JupiterXT,
JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Macro-PLUS, Magellan, Mars, Mars-Rail, Mars-Xtalk,
Milkyway, ModelSource, Module Compiler, MultiPoint, ORAengineering, Physical Analyst, Planet, Planet-PL, Polaris,
Power Compiler, Raphael, RippledMixer, Saturn, Scirocco, Scirocco-i, SiWare, Star-RCXT, Star-SimXT, StarRC, System
Compiler, System Designer, Taurus, TotalRecall, TSUPREM-4, VCSi, VHDL Compiler, VMC, and Worksheet Buffer are
trademarks of Synopsys, Inc.

Service Marks (SM)

MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
Saber is a registered trademark of SabreMark Limited Partnership and is used under license.
All other product or company names may be trademarks of their respective owners.

PrimeTime Variables, version F-2011.12 ii

Table of Contents 1

arch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
auto_link_disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
auto_wire_load_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
bus_naming_style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
case_analysis_log_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
case_analysis_propagate_through_icg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
case_analysis_sequential_propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
ccs_noise_small_bump_threshold_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
collection_result_display_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
create_clock_no_input_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
dbr_ignore_external_links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
default_oc_per_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
delay_calc_enable_waveform_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
delay_calc_waveform_analysis_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
disable_case_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
disable_case_analysis_ti_hi_lo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
eco_alternative_area_ratio_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
eco_alternative_cell_attribute_restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
eco_enable_more_scenarios_than_hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
eco_enable_old_fixing_technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
eco_estimation_output_columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
eco_instance_name_prefix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
eco_net_name_prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
eco_strict_pin_name_equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
 eco_write_changes_prepend_libfile_to_libcell . . . . . . . . . . . . . . . . . . . . . . . . . . 28
eco_write_changes_prepend_libname_to_libcell. . . . . . . . . . . . . . . . . . . . . . . . 30
enable_license_auto_reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
enable_page_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
extract_model_capacitance_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
extract_model_clock_transition_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
extract_model_data_transition_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
extract_model_db_naming_compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
extract_model_enable_report_delay_calculation . . . . . . . . . . . . . . . . . . . . . . . . 37
extract_model_gating_as_nochange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
extract_model_include_ideal_clock_network_latency . . . . . . . . . . . . . . . . . . . . 39
extract_model_include_upf_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
extract_model_keep_inferred_nochange_arcs . . . . . . . . . . . . . . . . . . . . . . . . . 41
extract_model_lib_format_with_check_pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
extract_model_merge_clock_gating. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
extract_model_noise_iv_index_lower_factor . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
extract_model_noise_iv_index_upper_factor . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
extract_model_noise_width_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
extract_model_num_capacitance_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
extract_model_num_clock_transition_points . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
extract_model_num_data_transition_points. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
extract_model_num_noise_iv_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
extract_model_num_noise_width_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
extract_model_single_pin_cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
extract_model_single_pin_cap_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
extract_model_split_partial_clock_gating_arcs . . . . . . . . . . . . . . . . . . . . . . . . . 54
extract_model_status_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
extract_model_suppress_three_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
extract_model_use_conservative_current_slew. . . . . . . . . . . . . . . . . . . . . . . . . 58
extract_model_with_3d_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
extract_model_with_clock_latency_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
extract_model_with_min_max_delay_constraint . . . . . . . . . . . . . . . . . . . . . . . . 61
extract_model_write_case_values_to_constraint_file . . . . . . . . . . . . . . . . . . . . 62
extract_model_write_verilog_format_wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . 64
hier_modeling_version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
hier_scope_check_defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
hierarchy_separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
ilm_ignore_percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

iv
in_gui_session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
library_pg_file_pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
link_allow_design_mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
link_create_black_boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
link_force_case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
link_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
link_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
link_path_per_instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
lp_default_ground_pin_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
lp_default_power_pin_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
model_validation_capacitance_tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
model_validation_ignore_pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
model_validation_output_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
model_validation_pba_clock_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
model_validation_percent_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
model_validation_reanalyze_max_paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
model_validation_report_split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
model_validation_section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
model_validation_significant_digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
model_validation_sort_by_worst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
model_validation_timing_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
model_validation_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
multi_core_allow_overthreading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
multi_core_skip_unsupported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
multi_core_use_32bit_slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
multi_core_working_directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
multi_scenario_fault_handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
multi_scenario_merged_error_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
multi_scenario_merged_error_log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
multi_scenario_message_verbosity_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
multi_scenario_working_directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
mv_input_enforce_simple_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
mw_design_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
mw_logic0_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
mw_logic1_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
parasitic_variation_default_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
parasitics_cap_warning_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
parasitics_log_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

v
 parasitics_rejection_net_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
parasitics_res_warning_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
parasitics_warning_net_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
pba_aocvm_only_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
pba_derate_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
pba_enable_path_based_physical_exclusivity. . . . . . . . . . . . . . . . . . . . . . . . . 120
pba_enable_xtalk_delay_ocv_pessimism_reduction . . . . . . . . . . . . . . . . . . . . 121
pba_exhaustive_endpoint_path_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
pba_path_recalculation_limit_compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
pba_recalculate_full_path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
port_search_in_current_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
power_analysis_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
power_calc_use_ceff_for_internal_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
power_check_defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
power_clock_network_include_clock_gating_network . . . . . . . . . . . . . . . . . . . 131
power_clock_network_include_register_clock_pin_power. . . . . . . . . . . . . . . . 132
power_default_static_probability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
power_default_toggle_rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
power_default_toggle_rate_reference_clock . . . . . . . . . . . . . . . . . . . . . . . . . . 137
power_domains_compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
power_enable_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
power_enable_clock_scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
power_enable_leakage_variation_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
power_enable_multi_rail_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
power_estimate_power_for_unmatched_event . . . . . . . . . . . . . . . . . . . . . . . . 144
power_include_initial_x_transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
power_limit_extrapolation_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
power_match_state_for_logic_x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
power_model_preference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
power_rail_output_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
power_rail_static_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
power_read_activity_ignore_case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
power_report_leakage_breakdowns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
power_reset_negative_extrapolation_value . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
power_reset_negative_internal_power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
power_scale_dynamic_power_at_power_off . . . . . . . . . . . . . . . . . . . . . . . . . . 156
power_table_include_switching_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
power_x_transition_derate_factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

vi
pt_ilm_dir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
pt_model_dir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
pt_shell_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
pt_tmp_dir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
ptxr_root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
ptxr_setup_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
rc_adjust_rd_when_less_than_rnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
rc_always_use_max_pin_cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
rc_cache_min_max_rise_fall_ceff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
rc_ceff_use_delay_reference_at_cpin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
rc_degrade_min_slew_when_rd_less_than_rnet . . . . . . . . . . . . . . . . . . . . . . . 174
rc_driver_model_mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
rc_filter_rd_less_than_rnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
rc_rd_less_than_rnet_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
rc_receiver_model_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
read_parasitics_load_locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
report_capacitance_use_ccs_receiver_model . . . . . . . . . . . . . . . . . . . . . . . . . 182
report_default_significant_digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
sdc_save_source_file_information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
sdc_version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
sdc_write_unambiguous_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
sdf_align_multi_drive_cell_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
sdf_align_multi_drive_cell_arcs_threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
sdf_annotate_cond_specific_delays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
sdf_enable_cond_start_end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
sdf_enable_port_construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
sdf_enable_port_construct_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
search_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
sh_eco_enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
sh_enable_line_editing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
sh_fast_analysis_mode_enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
sh_high_capacity_effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
sh_high_capacity_enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
sh_launch_dir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
sh_limited_messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
sh_line_editing_mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
sh_message_limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
sh_output_log_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

vii
 si_analysis_logical_correlation_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
si_ccs_aggressor_alignment_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
si_ccs_use_gate_level_simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
si_enable_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
si_filter_accum_aggr_noise_peak_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
si_filter_per_aggr_noise_peak_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
si_filter_per_aggr_to_average_aggr_xcap_ratio . . . . . . . . . . . . . . . . . . . . . . . 213
si_filter_per_aggr_xcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
si_filter_per_aggr_xcap_to_gcap_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
si_filter_total_aggr_xcap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
si_filter_total_aggr_xcap_to_gcap_ratio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
si_ilm_keep_si_user_excluded_aggressors. . . . . . . . . . . . . . . . . . . . . . . . . . . 225
si_noise_check_show_user_driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
si_noise_composite_aggr_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
si_noise_effort_threshold_beyond_rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
si_noise_effort_threshold_within_rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
si_noise_endpoint_height_threshold_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
si_noise_immunity_default_height_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
si_noise_limit_propagation_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
si_noise_slack_skip_disabled_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
si_noise_total_effort_threshold_beyond_rails . . . . . . . . . . . . . . . . . . . . . . . . . 234
si_noise_total_effort_threshold_within_rails. . . . . . . . . . . . . . . . . . . . . . . . . . . 235
si_noise_update_status_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
si_use_driving_cell_derate_for_delta_delay . . . . . . . . . . . . . . . . . . . . . . . . . . 237
si_xtalk_composite_aggr_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
si_xtalk_composite_aggr_noise_peak_ratio. . . . . . . . . . . . . . . . . . . . . . . . . . . 239
si_xtalk_composite_aggr_quantile_high_pct . . . . . . . . . . . . . . . . . . . . . . . . . . 240
si_xtalk_delay_analysis_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
si_xtalk_double_switching_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
si_xtalk_exit_on_max_iteration_count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
si_xtalk_exit_on_max_iteration_count_incr . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
si_xtalk_reselect_clock_network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
si_xtalk_reselect_delta_delay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
si_xtalk_reselect_delta_delay_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
si_xtalk_reselect_max_mode_slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
si_xtalk_reselect_min_mode_slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
si_xtalk_reselect_time_borrowing_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
svr_enable_vpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

viii
svr_keep_unconnected_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
timing_all_clocks_propagated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
timing_allow_short_path_borrowing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
timing_aocvm_analysis_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
timing_aocvm_enable_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
timing_aocvm_ocv_precedence_compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 261
timing_bidirectional_pin_max_transition_checks . . . . . . . . . . . . . . . . . . . . . . . 262
timing_calculation_across_broken_hierarchy_compatibility. . . . . . . . . . . . . . . 263
timing_check_defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
timing_clock_gating_check_fanout_compatibility. . . . . . . . . . . . . . . . . . . . . . . 265
timing_clock_gating_propagate_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
timing_clock_reconvergence_pessimism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
timing_crpr_enable_adaptive_engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
timing_crpr_minimize_grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
timing_crpr_remove_clock_to_data_crp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
timing_crpr_remove_muxed_clock_crp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
timing_crpr_threshold_ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
timing_disable_bus_contention_check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
timing_disable_clock_gating_checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
timing_disable_cond_default_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
timing_disable_floating_bus_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
timing_disable_internal_inout_cell_paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
timing_disable_internal_inout_net_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
timing_disable_recovery_removal_checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
timing_dynamic_loop_breaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
timing_early_launch_at_borrowing_latches . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
timing_enable_clock_propagation_through_preset_clear . . . . . . . . . . . . . . . . 284
timing_enable_clock_propagation_through_three_state_enable_pins . . . . . . 285
timing_enable_cross_voltage_domain_analysis . . . . . . . . . . . . . . . . . . . . . . . 286
timing_enable_max_capacitance_set_case_analysis . . . . . . . . . . . . . . . . . . . 287
timing_enable_preset_clear_arcs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
timing_enable_pulse_clock_constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
timing_gclock_source_network_num_master_registers. . . . . . . . . . . . . . . . . . 290
timing_ideal_clock_zero_default_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
timing_include_available_borrow_in_slack . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
timing_input_port_default_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
timing_keep_loop_breaking_disabled_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
timing_port_clock_and_data_compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

ix
 timing_prelayout_scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
timing_propagate_interclock_uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
timing_propagate_through_non_latch_d_pin_arcs . . . . . . . . . . . . . . . . . . . . . 298
timing_reduce_multi_drive_net_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
timing_reduce_multi_drive_net_arcs_threshold . . . . . . . . . . . . . . . . . . . . . . . . 301
timing_reduce_parallel_cell_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
timing_remove_clock_reconvergence_pessimism . . . . . . . . . . . . . . . . . . . . . . 303
timing_report_always_use_valid_start_end_points . . . . . . . . . . . . . . . . . . . . . 305
timing_report_fast_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
timing_report_maxpaths_nworst_reached . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
timing_report_recalculation_status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
timing_report_status_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
timing_report_unconstrained_paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
timing_report_use_worst_parallel_cell_arc . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
timing_save_pin_arrival_and_required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
timing_save_pin_arrival_and_slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
timing_si_exclude_delta_slew_for_transition_constraint . . . . . . . . . . . . . . . . . 316
timing_simultaneous_clock_data_port_compatibility . . . . . . . . . . . . . . . . . . . . 317
timing_slew_threshold_scaling_for_max_transition_compatibility . . . . . . . . . . 319
timing_update_effort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
timing_update_status_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
timing_use_constraint_derates_for_pulse_checks. . . . . . . . . . . . . . . . . . . . . . 323
timing_use_zero_slew_for_annotated_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
variation_analysis_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
variation_derived_scalar_attribute_mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
variation_enable_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
variation_pba_use_worst_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
variation_report_timing_increment_format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
wildcards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
write_script_include_library_constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
write_script_output_lumped_net_annotation . . . . . . . . . . . . . . . . . . . . . . . . . . 335

x
arch
This is a synonym for the read-only sh_arch variable.

SEE ALSO
sh_arch(3)

arch
1
auto_link_disable
Disables the autolink process.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When false (the default), many PrimeTime commands automatically attempt to link the
current design for you. For example, the set_load command invokes the linker if the
current design is not linked. Automatic linking occurs only if the design is
completely unlinked. If the current design is partially linked and has unresolved
references, automatic linking does not occur. If the current design is totally
linked, there is no need for an autolink, so it is not attempted.

Setting the auto_link_disable variable to true disables the autolink process. You
can use this setting, along with the link_design command, to achieve the best
possible performance when you have a large script that contains thousands of
commands. Follow these steps:

1. Link the design manually with the link_design command.

2. Set the auto_link_disable variable to true.

3. Source the script.

4. Reset the auto_link_disable variable to false.

Note that setting the auto_link_disable variable to true is intended to be used in

conjunction with a manual link step.

To determine the current value of this variable, type printvar auto_link_disable or

echo $auto_link_disable

SEE ALSO
link_design(2)

auto_link_disable
2
auto_wire_load_selection
Enables the automatic selection of wire load models.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When true (the default), enables the automatic selection of wire load models, used
to estimate net capacitances and resistances from the net fanout. When you set this
variable to false, automatic selection of the wire load model is disabled.

The wire load models are described in the technology library. With the automatic
selection of the wire load model, if the wire load mode is segmented or enclosed,
the wire load model is chosen based on the area of the block containing the net
either partially (for segmented) or fully (for enclosed). If the wire load mode is
top, the wire load model is chosen based on the area of the top level design for all
nets in the design hierarchy.

When you manually select a wire load model for a block (using the
set_wire_load_model command), automatic wire load selection for that block is
disabled.

To determine the current value of this variable, use the following command:

pt_shell> printvar auto_wire_load_selection

SEE ALSO
printvar(2)
report_wire_load(2)
set_wire_load_min_block_size(2)
set_wire_load_selection_group(2)

auto_wire_load_selection
3
bus_naming_style
Sets the naming format for a specific element of a bus.

TYPE

string

DEFAULT

DESCRIPTION

This variable is used by the native Verilog reader to set the naming format for a
specific element of a bus. This is the way that the names of the individual bits of
the bus appear in the application.

The default value is "%s[%d]". For example, for bus A and index 12, the name would
be A[12].

To determine the current value of this variable, type one of the following commands:

printvar bus_naming_style

echo $bus_naming_style

SEE ALSO
printvar(2)
read_verilog(2)

bus_naming_style
4
case_analysis_log_file
Specifies the name of the file into which the details of case analysis propagation
are written.

TYPE

string

DEFAULT

"" (empty)

DESCRIPTION

Specifies the name of a log file to be generated during propagation of constant

values from case analysis or from nets tied to logic zero or to logic one. The log
file contains the list of all nets and pins that propagate constants. The constant
propagation algorithm is an iterative process that propagates constants through nets
and cells starting from a list of constant pins. The algorithm finishes when no more
constants can be propagated. The format of the log file follows the constant
propagation algorithm. For each iteration of the propagation process, the log file
lists all nets and cells that propagate constants.

By default, this variable is set to an empty string, and no log file is generated
during constant propagation.

To determine the current value of this variable, use the following command:

printvar case_analysis_log_file

SEE ALSO
remove_case_analysis(2)
report_case_analysis(2)
report_disable_timing(2)
set_case_analysis(2)
disable_case_analysis(3)

case_analysis_log_file
5
case_analysis_propagate_through_icg
Determines whether case analysis is propagated through integrated clock gating
cells.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When false (the default), constants propagating throughout the design stops
propagating when an integrated clock gating cell is encountered. Regardless of
whether the integrated clock gating cell is enabled or disabled, no logic values
propagate in the fanout of the cell.

When set to true, constants propagated throughout the design propagates through an
integrated clock gating cell provided the cell is enabled. An integrated clock
gating cell is enabled when its enable pin (or test enable pin) is set to a hi logic
value. If the cell is disabled, the disable logic value for the cell is propagated
in its fanout. For example, when the latch_posedge ICG is disabled, it propagates a
logic 0 in its fanout.

To activate logic propagation through all integrated clock gating cells, you must
set the following prior to using the update_timing command.

pt_shell> set case_analysis_propagate_through_icg true

To determine the current value of this variable, type one of the following commands:

printvar case_analysis_propagate_through_icg

echo $case_analysis_propagate_through_icg

SEE ALSO
set_case_analysis(2)
remove_case_analysis(2)

case_analysis_propagate_through_icg
6
case_analysis_sequential_propagation
Determines whether case analysis is propagated across sequential cells.

TYPE

fIstringfP

DEFAULT

never

DESCRIPTION

Determines whether case analysis is propagated across sequential cells. Allowed

values are never (the default) or always. When set to never, case analysis is not
propagated across the sequential cells. When set to always, case analysis is
propagated across the sequential cells.

The one exception to sequential propagation occurs when dealing with sequential
integrated clock gating cells. These types of ICG cells will only propagate logic
values when the case_analysis_propagate_through_icg variable is set to true.

To determine the current value of this variable, type one of the following commands:

printvar case_analysis_sequential_propagation

echo $case_analysis_sequential_propagation

SEE ALSO
case_analysis_propagate_through_icg(3)
printvar(2)
set_case_analysis(2)

case_analysis_sequential_propagation
7
ccs_noise_small_bump_threshold_ratio
Specifies the user-override threshold for the summation of noise bump height
introduced by all aggressors at a quiet victim node divided by Vcc, above which the
net becomes eligible to be analyzed by the gate-level simulation engine.

TYPE

float

DEFAULT

1.0

DESCRIPTION

Note : This variable is in the proccess of obsoletion in 2008.12.

Specifies the user-override threshold for the summation of noise bump height
introduced by all aggressors at a quiet victim node divided by Vcc. The default is
1.0. This variable is used exclusively in the CCS Noise based noise analysis flow.
In this flow, PrimeTime-SI determines whether detailed noise calculation engine is
necessary depending on an estimate of the total noise bump height on the victim net
as well as the noise immunity levels of the receiving cells. This variable allows
user to override the above engine selection behavior and send more nets to be
analyzed using the gate-level simulation engine.

The aggressor nets, along with their coupling capacitors, become eligible to be
analyzed by the gate-level simulation engine when the summation of peak voltage
bumps induced on the quiet victim net divided by Vcc is more than the value of
ccs_noise_small_bump_threshold_ratio.

To determine the current value of this variable, type printvar

ccs_noise_small_bump_threshold_ratio.

SEE ALSO

set_noise_parameters (2).

ccs_noise_small_bump_threshold_ratio
8
collection_result_display_limit
Sets the maximum number of objects that can be displayed by any command that
displays a collection.

TYPE

integer

DEFAULT

100

DESCRIPTION

Sets the maximum number of objects that can be displayed by any command that
displays a collection. The default is 100.

When a command, such as the add_to_collection) command, is issued at the command

prompt, the result is implicitly queried, as though the query_objects command was
called. You can limit the number of objects displayed by setting the
collection_result_display_limit variable to an appropriate integer. A value of -1
displays all objects; a value of 0 displays the collection handle ID instead of the
object names in the collection.

To determine the current value of this variable, type the following:

printvar collection_result_display_limit

SEE ALSO
collections(2)
query_objects(2)

collection_result_display_limit
9
create_clock_no_input_delay
Affects delay propagation characteristics of clock sources created using the
create_clock command.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable impacts the delay propagation characteristics of clock sources created
using the create_clock command. When set to its default of false, the clock sources
used in the data path are established as timing startpoints. The clock sources in
the design propagates rising delays on every rising clock edge and propagates
falling delays on every falling clock edge. Disable this behavior by setting the
create_clock_no_input_delay variable to true.

To determine the current value of this variable, type the following:

printvar create_clock_no_input_delay

SEE ALSO
create_clock(2)

create_clock_no_input_delay
10
dbr_ignore_external_links
Determines whether to ignore external links when reading in database files.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, if the read_db command encounters
an external link when reading a database (db) file, it extracts as much information
as possible from the database (db) file so that the linker can restore the link.
When you set this variable to true, the read_db command ignores external links and
searches for an object by name only in the libraries set using the link_path
command.

External links are written by Design Compiler for objects (for example, wire load
models and operating conditions), when there is a link from a design to another
object in a library. The external link records information about the library to
which the wire load was linked. For example, if the TOP design has an external link
for a wire load model named B100 in the nominal.db library, by default the linker
attempts to load a nominal.db library. If it is not already loaded, the tool looks
in that library for a wire load model named B100. To override this default behavior
and use B100 instead from min.db, set the dbr_ignore_external_links variable to true
and specify min.db in the link_path variable.

To determine the current value of this variable, type one of the following:

printvar dbr_ignore_external_links

echo $dbr_ignore_external_links

SEE ALSO
link_design(2)
read_db(2)
link_path(3)
search_path(3)

dbr_ignore_external_links
11
default_oc_per_lib
Enables the use of a default operating condition per individual library.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Enables the use of a default operating condition per individual library. When this
variable is set to its default of true, each cell that does not have an explicitly-
set operating condition (on the cell itself, on any of its parent cells, or on the
design) is assigned the default operating condition of the library to which the cell
belongs.

When set to false all cells that do not have any explicitly-set operating condition
are assigned the default operating condition of the main library (the first library
set in the link_path command).

The recommended flow is to explicitly set operating conditions on the design or on

each hierarchical block that is powered by the same voltage (also called the voltage
island).

This variable is mainly for obtaining backward compatibility for the corner case of
using default conditions in PrimeTime version T-2002.09 and earlier releases.

To determine the current value of this variable, type the following:

printvar default_oc_per_lib

SEE ALSO
set_operating_conditions(2)
link_path(3)

default_oc_per_lib
12
delay_calc_enable_waveform_analysis
Enables or disables CCS based waveform analysis feature for uncoupled and SI
calculation.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When true, it turns on CCS-based waveform analysis. By default, this variable is set
to false. This feature requires CCS data so libraries need to contain either CCS
timing or both CCS timing and CCS noise data.

A PrimeTime SI license is required for this feature including uncoupled calculation.

But user does not need to set si_enable_analysis for uncoupled analysis.

For complete information about the CCS-based waveform analysis feature, see the
PrimeTime SI User Guide.

This variable will be obsolete in a future release, please use

delay_calc_waveform_analysis_mode that provides more options.

To determine the current value of this variable, type the following command:

printvar delay_calc_enable_waveform_analysis

SEE ALSO
update_timing(2)
report_timing(2)
si_enable_analysis(3)

delay_calc_enable_waveform_analysis
13
delay_calc_waveform_analysis_mode
Controls usage of CCS-based waveform analysis for uncoupled and signal integrity
calculation.

TYPE

string

DEFAULT

disabled

DESCRIPTION

You can set this variable to disabled , clock_network, or full_design. When set to
clock_network or full_design, it turns on CCS-based waveform analysis and applies it
to the clock network or the entire design. By default, this variable is set to
disabled. This feature requires CCS data, so libraries need to contain CCS timing
data, CCS noise data, or both.

A PrimeTime SI license is required for this feature, including uncoupled

calculation. However, you do not need to set the si_enable_analysis variable for
uncoupled analysis.

For complete information about the CCS-based waveform analysis feature, see the
PrimeTime SI User Guide.

The delay_calc_enable_waveform_analysis variable has been deprecated and will be

obsolete in a future release.

To determine the current value of this variable, type the following command:

printvar delay_calc_waveform_analysis_mode

SEE ALSO
update_timing(2)
report_timing(2)
si_enable_analysis(3)

delay_calc_waveform_analysis_mode
14
disable_case_analysis
Specifies whether case analysis is disabled.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, constant propagation is performed
in the design from pins either that are tied to a logic constant value or for those
specified using the case_analysis command. For example, a typical design has several
pins set to a constant logic value. By default, this constant value propagates
through the logic to which it connects. When you set the disable_case_analysis
variable to true, case analysis and constant propagation are not performed.

If you set the disable_case_analysis_ti_hi_lo variable to true, constant propagation

from pins that are tied to a logic constant value are not performed.

To determine the current value of this variable, type the following:

printvar disable_case_analysis

SEE ALSO
remove_case_analysis(2)
report_case_analysis(2)
set_case_analysis(2)
disable_case_analysis_ti_hi_lo(3)

disable_case_analysis
15
disable_case_analysis_ti_hi_lo
Specifies if logic constants should be propagated from pins that are tied to a logic
constant value.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, constant propagation is performed
from pins that are tied to a logic constant value. For example, a typical design has
several pins set to a constant logic value. By default, this constant value
propagates through the logic to which it connects. When you set this variable to
true, constant propagation is not performed from these pins.

This current value of this variable does not alter the propagation of logic values
from pins where the logic value has been set by the set_case_analysis command.

If you set the disable_case_analysis variable to true, all constant propagation is

disabled regardless of the current value of the disable_case_analysis_ti_hi_lo
variable.

To determine the current value of this variable, type the following:

printvar disable_case_analysis_ti_hi_lo

SEE ALSO
remove_case_analysis(2)
report_case_analysis(2)
set_case_analysis(2)
disable_case_analysis(3)

disable_case_analysis_ti_hi_lo
16
eco_alternative_area_ratio_threshold
Specifies the maximum allowable area increase of a cell resize operation during the
fixing process.

TYPE

float

DEFAULT

DESCRIPTION

This variable specifies the maximum allowable area increase of a cell resize
operation during the fixing process. The default value of zero (0) means that no
limit is imposed on upsizing. However, if there is a specific requirement on the
maximum size increase of a resized cell, you can control the area increase by
setting this variable to a positive value which specifies the maximum upsize area
increase as a ratio. By setting this variable to 2, upsizes would be limited to
twice the area of the original cell. Imposing an upsize area limit can increase the
timing predictability after physical implementation of the engineering change orders
(ECO), as the smaller cell size increases are less likely to perturb layout during
incremental placement and routing. However, more changes might mean more runtime is
required to achieve the needed slack improvement.

To determine the current value of this variable, type the following:

printvar eco_alternative_area_ratio_thresholdfP

SEE ALSO
fix_eco_timing(2)

eco_alternative_area_ratio_threshold
17
eco_alternative_cell_attribute_restrictions
Specifies lib_cell attributes used to restrict cell sizing.

TYPE

string

DEFAULT

""

DESCRIPTION

This variable is used to restrict the choice of alternative library cells for the
purposes of cell sizing. The variable accepts a whitespace delimited list of
application or user-defined attributes on the lib_cell objects. A pair of library
cells are considered equivalent if value of each of the attributes specified match.
Note that the implicit cell equivalency checks performed by PrimeTime must also
match. This variable affects all PrimeTime commands that perform cell sizing.

The following example of a usage model restricts cells to the same area (an
application-defined attribute) and the same family (a user-defined attribute):

pt_shell> define_user_attribute -classes lib_cell -type string family

pt_shell> set eco_alternative_cell_attribute_restrictions "area family"

To determine the current value of this variable, type the following:

printvar eco_alternative_cell_attribute_restrictions

SEE ALSO
define_user_attribute(2)
get_alternative_lib_cells(2)
report_alternative_lib_cells(2)
set_user_attribute(2)
size_cell(2)

eco_alternative_cell_attribute_restrictions
18
eco_enable_more_scenarios_than_hosts
Enables ECO fixing with more scenarios than available hosts.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, the fix_eco_timing and
fix_eco_drc commands require an equal number of scenarios and hosts.

In some cases, the default behavior might not be desirable, and the number of
scenarios exceeds the number of available hosts. When you set this variable to true,
the fix_eco_timing and fix_eco_drc commands allow more scenarios than hosts and
continue to fix timing violations. However, the runtime and quality of results (QoR)
might be impacted because of limited resources.

This variable is effective only when the eco_enable_old_fixing_technology variable

is false.

To determine the current setting of this variable, use the following command:

printvar eco_enable_more_scenarios_than_hosts

SEE ALSO
fix_eco_timing(2)
fix_eco_drc(2)
eco_enable_old_fixing_technology(3)

eco_enable_more_scenarios_than_hosts
19
eco_enable_old_fixing_technology
Enables the use of the fixing technology that was available in version E-2010.12 and
earlier releases.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, PrimeTime uses the next
generation ECO guidance technology for fix_eco_timing and fix_eco_drc.

In some cases, the default behavior might not be desirable. When you set this
variable to true, PrimeTime uses the previous fixing technology.

This variable will be obsoleted and removed from future releases of PrimeTime
starting with 2012.06.

To determine the current setting of this variable, use the following command:

printvar eco_enable_old_fixing_technology

SEE ALSO
fix_eco_timing(2)
fix_eco_drc(2)

eco_enable_old_fixing_technology
20
eco_estimation_output_columns
Specifies output columns to be printed by the estimate_eco command for nonverbose
reporting.

TYPE

string

DEFAULT

{area stage_delay arrival slack}

DESCRIPTION

This variable controls which output columns are printed by the estimate_eco command
for nonverbose reporting.

The following keywords are available:

• area - Area of the specified lib_cell

• stage_delay - Delay from the input pin of the current cell to the most slack-
critical load pin

• arrival - Arrival time at the most slack-critical load pin

• slack - Timing slack at the most slack-critical load pin

• transition - Transition time at the most slack-critical load pin

• min_transition - Worst min_transition design rule checking (DRC) for any pin in
the estimated stage

• min_capacitance - Worst min_capacitance DRC for any pin in the estimated stage

• max_transition - Worst max_transition DRC for any pin in the estimated stage

• max_capacitance - Worst max_capacitance DRC for any pin in the estimated stage

• max_fanout - Worst max_fanout DRC for any pin in the estimated stage

eco_estimation_output_columns
21
The DRC keywords return the worst DRC value for all pins in the stage, including all
load pins. For example, to see only area, slack, and maximum transition information,
set the eco_estimation_output_columns variable to area slack max_transition.

To determine the current value of this variable, type one of the following:

printvar eco_estimation_output_columns

echo $eco_estimation_output_columns

SEE ALSO
estimate_eco(2)

eco_estimation_output_columns
22
eco_instance_name_prefix
Specifies the prefix used in generating cell instance names that the insert_buffer
command uses.

TYPE

string

DEFAULT

DESCRIPTION

This variable specifies the instance name prefix to be used by the insert_buffer
command when creating new buffer and inverter cells. An instance number is appended
to this prefix to form the new cell name. If the resulting cell name is already
used, the instance number is incremented until an unused instance name is found. The
default value of this variable is {U}, which causes the insert_buffer command to
create the follwoing instances: U1, U2, U3, etc.

The rules for the eco_instance_name_prefix variable are:

• The first character must be A->Z or a->z

• Subsequent characters must be A->Z, a->z, 0->9, or _

Consider the case where the engineering change order (ECO) is made during the second
iteration of timing closure. This variable can be set so that newly-created buffer
and inverter instances are named in an easily-identifiable manner. For example,

pt_shell> set eco_instance_name_prefix {Ueco2_}

Ueco2_
pt_shell> insert_buffer U2/Y slow/BUFX2
Information: Inserted ’Ueco2_1’ at ’U2/Y’. (NED-046)
{"Ueco2_1"}
pt_shell> insert_buffer U2319/A slow/BUFX2
Information: Inserted ’Ueco2_2’ at ’U2/A’. (NED-046)
{"Ueco2_2"}

Changing the value of this variable does not impact the current value of the
incrementer.

To determine the current value of this variable, type one of the following:

pt_shell> printvar eco_instance_name_prefix

pt_shell> echo $eco_instance_name_prefix

eco_instance_name_prefix
23
SEE ALSO
insert_buffer(2)
eco_net_name_prefix(3)

eco_instance_name_prefix
24
eco_net_name_prefix
Specifies the prefix used in generating insert_buffer net names.

TYPE

string

DEFAULT

net

DESCRIPTION

This variable specifies the net name prefix to be used by the insert_buffer command
when creating new nets. A net number is appended to this prefix to form the new net
name. If the resulting net name is already used, the net number is incremented until
an unused net name is found. The default value of this variable is {net}, which
causes the insert_buffer to create nets net1, net2, net3, etc.

The rules for the eco_net_name_prefix variable are:

• The first character must be A->Z or a->z

• Subsequent characters must be A->Z, a->z, 0->9, or _

Consider a case where the engineering change order (ECO) changes are being made
during the second iteration of timing closure. This variable can be set so that
newly-created buffer and inverter nets are named in an easily-identifiable manner.
For example,

pt_shell> set eco_net_name_prefix {NETeco2_}

NETeco2_
pt_shell> insert_buffer U2/Y slow/BUFX2
Information: Inserted ’U1’ at ’U2/Y’. (NED-046)
{"U1"}
pt_shell> all_connected [get_pins U1/Z]
{"NETeco2_1"}

Changing the value of this variable does not affect the current value of the
incrementer.

To determine the current value of this variable, type one of the following:

printvar eco_net_name_prefix

echo $eco_net_name_prefix

eco_net_name_prefix
25
SEE ALSO
insert_buffer(2)
eco_instance_name_prefix(3)

eco_net_name_prefix
26
eco_strict_pin_name_equivalence
Descides whether only cells with identical pin names are equivalent for cell sizing.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, PrimeTime can size cells even if
the pin names of the cells are not identical. PrimeTime uses other library cell
information to match the pins of each cell.

In some cases, this behavior might not be desirable. When you set this variable to
true, cells are only considers to be equivalent if the pin names on each cell match
precisely.

To determine the current value of this variable, type the following:

printvar eco_strict_pin_name_equivalence

SEE ALSO
get_alternative_lib_cells(2)
report_alternative_lib_cells(2)
size_cell(2)

eco_strict_pin_name_equivalence
27
eco_write_changes_prepend_libfile_to_libcell
Prepend link library file name information to library cell references in the
write_changes command change list.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, references to library cells in
the write_changes command output contains only the library name and reference cell
name information. For example,

pt_shell> write_changes
create_cell {U1} {slow/BUFX1}
insert_buffer [get_pins {U2320/Y}] slow/BUFX4 -new_net_names {net1} -
new_cell_names {U2}
size_cell {U2} {slow/BUFX2}

When you set this variable to true, the library’s file name information is prepended
to the library name to fully specify the library cell reference. For example,

pt_shell> write_changes
create_cell {U1} {slow.db:slow/BUFX1}
insert_buffer [get_pins {U2320/Y}] slow.db:slow/BUFX4 -new_net_names {net1} -
new_cell_names {U2}
size_cell {U2} {slow.db:slow/BUFX2}

This can be useful in multilibrary flows, such as voltage islands, to fully specify
the library that should be used to link the new instances. Only the library file
name itself is prepended; the full file system path to the library is not included.

Note that this variable controls whether the library file name information is saved
at the time of the ECO operation. Changing the value of the variable does not modify
the create_cell, insert_buffer, or size_cell command, which has already been
executed and recorded.

Note that variable has no impact if the eco_write_changes_prepend_libname_to_libcell

variable is set to false. In this case, neither library name nor library file name
are prepended.

To determine the current value of this variable, type the following:

printvar eco_write_changes_prepend_libfile_to_libcell

eco_write_changes_prepend_libfile_to_libcell
28
SEE ALSO
create_cell(3)
eco_write_changes_prepend_libfile_to_libcell(3)
insert_buffer(3)
size_cell(3)

eco_write_changes_prepend_libfile_to_libcell
29
eco_write_changes_prepend_libname_to_libcell
Prepend link library information to library cell references in the write_changes
change list.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When you set this variable to true, references to library cells in the write_changes
output contain library name and reference cell name information:

By default, the library’s name is not prepended to the library name:

pt_shell> write_changes
create_cell {U1} {BUFX1}
insert_buffer [get_pins {U2320/Y}] BUFX4 -new_net_names {net1} -new_cell_names {U2}
size_cell {U2} {BUFX2}

When this variable is set to true, the library’s name is prepended to the library
name:

pt_shell> write_changes
create_cell {U1} {slow/BUFX1}
insert_buffer [get_pins {U2320/Y}] slow/BUFX4 -new_net_names {net1} -
new_cell_names {U2}
size_cell {U2} {slow/BUFX2}

Note that the variable controls whether the library name information is saved at the
time of the engineering change order (ECO) operation. Changing the value of this
variable does not modify the create_cell, insert_buffer, or size_cell command that
has already been executed and recorded.

To determine the current value of this variable, type the following:

printvar eco_write_changes_prepend_libname_to_libcell

SEE ALSO
create_cell(3)
eco_write_changes_prepend_libfile_to_libcell(3)
insert_buffer(3)
size_cell(3)

eco_write_changes_prepend_libname_to_libcell
30
enable_license_auto_reduction
Determines whether or not the master returns licenses to the license server after a
slave has finished using them.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When a slave finishes processing a task, it returns the licenses it used to the
master. When the enable_license_auto_reduction variable is set to its default of
false, the master keeps the licenses checked out for future slave usage. When you
set this variable to true, the master returns the licenses it receives from the
slaves back to the license server unless another slave has already requested usage
of that license.

The enable_license_auto_reduction variable should be enabled with care. When the

master returns the licenses to the license server it might not be able to acquire
them again. This reduces the number of slaves that can execute concurrently leading
to a degradation in performance during the subsequent analysis.

The enable_license_auto_reduction variable only has an impact if the master was

launched with incremental license handling enabled. Incremental license handling can
be enabled by setting the SNPSLMD_ENABLE_INCREMENTAL_LICENSE_HANDLING UNIX
environmental variable to 1. For more information, see the PrimeTime Distributed
Multi-Scenario Analysis User Guide and the PrimeTime Fundamentals User Guide.

To activate automatic license reduction, set the variable to true. For example,

pt_shell> set enable_license_auto_reduction true

To determine the current value of this variable, type one of the following:

printvar enable_license_auto_reduction

echo $enable_license_auto_reduction

enable_license_auto_reduction
31
enable_page_mode
This is a synonym for the sh_enable_page_mode variable.

DEFAULT

false

SEE ALSO
sh_enable_page_mode(3)

enable_page_mode
32
extract_model_capacitance_limit
Defines the maximum bound on the capacitance value for output ports of the netlist.

TYPE

float

DEFAULT

64.0

DESCRIPTION

Specifies the maximum permissible capacitance (load) at an output port. The

extract_model command characterizes circuit timing from zero to the value specified
by this variable. Setting a tight capacitance bound through this variable improves
the accuracy of the extracted delay tables for a range of anticipated capacitive
load. If a gate in the design does not have a max_capacitance attribute in its
library definition, the extract_model command uses the value of the
extract_model_capacitance_limit variable when adding a max_capacitance design rule
attribute to output pins of the model. If the design rule is already defined in
library, the extract_model_capacitance_limit variable is used to establish a more
constraining design rule in the resulting timing model.

To determine the current value of this variable, type the following:

printvar extract_model_capacitance_limit

SEE ALSO
extract_model(2)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_num_capacitance_points(3)

extract_model_capacitance_limit
33
extract_model_clock_transition_limit
Defines the maximum bound on the transition time (slew) for ports that transitively
drive the CLK pins of registers.

TYPE

float

DEFAULT

DESCRIPTION

Defines the maximum bound on the transition time (slew) for ports that transitively
drive the CLK pins of registers. Extracted timing tables are characterized for a
transition range from zero to the specified bound. Specifying a tight bound for this
variable improves the accuracy of extracted timing tables for a specified transition
time range. The default value for this variable is 5.0ns.

If a gate in the design whose input pin is connected to a clock port does not have a
max_transition design rule in its library definition, the extract_model command uses
the value of the extract_model_data_transition_limit variable when defining a
max_transition design rule for the input port. If the design rule is already defined
in library, this variable is used to establish a more constraining design rule in
the resulting timing model.

To determine the current value of this variable, type the following:

printvar extract_model_clock_transition_limit

SEE ALSO
extract_model(2)
extract_model_capacitance_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_num_capacitance_points(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)

extract_model_clock_transition_limit
34
extract_model_data_transition_limit
Defines the maximum bound on the transition time (slew) for ports that transitively
drive the D pins of registers.

TYPE

float

DEFAULT

DESCRIPTION

Defines the maximum bound on the transition time (slew) for ports that transitively
drive the D pins of registers. Extracted timing tables are characterized for a
transition range from zero to the specified bound. Specifying a tight bound for this
variable improves the accuracy of extracted timing tables for a specified transition
time range. The default value for this variable is 5.0.

If a gate in the design whose input pin is connected to an input port does not have
a max_transition design rule in its library definition, the extract_model command
uses the value of the extract_model_data_transition_limit variable when defining a
max_transition design rule for the input port. If the design rule is already defined
in library, then this variable is used to establish a more constraining design rule
in the resulting timing model.

To determine the current value of this variable, type the following:

printvar extract_model_data_transition_limit

SEE ALSO
extract_model(2)
extract_model_capacitance_limit(3)
extract_model_clock_transition_limit(3)
extract_model_min_resolution(3)
extract_model_num_capacitance_points(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)

extract_model_data_transition_limit
35
extract_model_db_naming_compatibility
Determines whether the library name used in the .db format extracted model (ETM)
should maintain the same naming style as in previous releases.

TYPE

string

DEFAULT

true

DESCRIPTION

ETMs generated by PrimeTime can be written in either .lib (Liberty) or .db (Synopsys
database) format. Historically, the naming of the library in these two formats
output can be different. The .lib format uses the string specified for the -output
option; while the library naming of the .db format has been using the design name of
the block being extracted. When this variable is set to its default of true, the
above behavior is unchanged for backward compatibility.

If you set this variable to false, the .db format naming follows the .lib format.
For example, both formats use the value specified for the -output option. This might
improve scripting convenience when both the .lib and .db formats ETM models are
mixed in the flow.

To determine the current value of this variable, type the following:

printvar extract_model_db_naming_compatibility

SEE ALSO
extract_model(2)

extract_model_db_naming_compatibility
36
extract_model_enable_report_delay_calculation
Determines report delay calculation to be performed on the timing arcs contained in
models.

TYPE

string

DEFAULT

true

DESCRIPTION

When you set this variable to false, the models generated by PrimeTime model
extraction do not allow report delay calculation to be performed on the timing arcs
contained in models. The default value is true. This is enforceable only for the
Synopsys database (.db) format output. For Liberty (.lib) format models, you can
always modify the files before compiling them to enable or disable the feature of
the resulting library.

To determine the current value of this variable, type the following:

printvar extract_model_enable_report_delay_calculation

SEE ALSO
extract_model(2)
report_delay_calculation(2)

extract_model_enable_report_delay_calculation
37
extract_model_gating_as_nochange
Controls the conversion from clock_gating setup/hold arcs into nochange arcs in the
extracted model.

TYPE

string

DEFAULT

false

DESCRIPTION

When you set this variable to true, the clock gating setup and hold constraints are
modeled as nochange arcs on the extracted model. When this variable is set to its
default of false, clock gating checks are represented as separate setup and hold
constraints. This variable affects models in all output formats, such as the
Synopsys database (.db) and Liberty (.lib) formats.

For more information and guidelines about using this variable and the method used to
convert clock gating checks to nochange checks, see the PrimeTime Modeling User
Guide.

To determine the current value of this variable, type the following:

printvar extract_model_gating_as_nochange

SEE ALSO
extract_model(2)
extract_model_capacitance_limit(3)
extract_model_min_resolution(3)
extract_model_tolerance(3)

extract_model_gating_as_nochange
38
extract_model_include_ideal_clock_network_latency
Use this variable to control the behavior of accounting user-defined network
latencies for ideal clocks in the extracted timing models (ETM). When this variable
is set to its default of false, ETMs do not account for any network latency for
ideal clock trees, meaning delays to registers clocked by ideal clocks are always
treated as 0.0 in the delay arcs.

TYPE

string

DEFAULT

false

DESCRIPTION

When you set this variable to true, the PrimeTime model extraction uses the the
user-defined network latency for ideal clock paths leading to registers. This
impacts the delay tables created for constraint arcs such as setup, hold from the
ideal clock port to data input ports, as well as sequential rising_edge and
falling_edge delay arcs from ideal clock ports to output ports. It also impacts the
clock insertion delay arcs created in the model if extraction of such arcs are
enabled by the extract_model_with_clock_latency_arcs variable.

When this variable is set to the default of false, the extracted models treat ideal
clock paths as zero delay in creating timing arcs, you are expected to re-apply the
same clock network latency values when the model is used. This has been the same
behavior of model extraction since PrimeTime version V-2004.06 and later releases.

The only modeling command affected by this variable is the extract_model command.
All formats of the extraced models are affected.

To determine the current value of this variable, type the following:

printvar extract_model_include_ideal_clock_network_latency

SEE ALSO
extract_model(2)
extract_model_with_clock_latency_arcs(3)

extract_model_include_ideal_clock_network_latency
39
extract_model_include_upf_data
Determines if the UPF data is extracted or merged in the models.

TYPE

string

DEFAULT

false

DESCRIPTION

When you set this variable to true, the models generated by PrimeTime model
extraction or merging contains UPF data reflecting the UPF data existing in the
original design or models. The default value is false. This is enforceable only for
the Liberty database (.lib) format output.

To determine the current value of this variable, type the following:

printvar extract_model_include_upf_data

SEE ALSO
extract_model(2)
merge_models(2)

extract_model_include_upf_data
40
extract_model_keep_inferred_nochange_arcs
Controls whether to keep PrimeTime inferred nochange relationships as nochange
timing arcs in the extracted model.

TYPE

string

DEFAULT

false

DESCRIPTION

There are two ways for PrimeTime to perform a nochange constraint check between a
data and a clock signal at a cell. The standard mechanism come explicitly from the
library, when the timing arcs are defined as nochange timing types. The second
mechanism is implicit. When interpreting cells based on its library arc types,
PrimeTime can detect that between a data pin and a reference clock pin, there are
pair-wise setup and hold arcs defined relative to the opposite edges of the clock
signal, and the arcs do not form a standard edge-triggered regular flip-flop and
also do not form a level-sensitive latch, PrimeTime may infer nochange relationship
for the arc pair. For example, a setup_clock_rise and hold_clock_fall arc pair
implies a nochange_clock_high check, meaning the data signal should be stable during
the high pulse of the reference clock signal. This can be regarded as PrimeTime
overrides the library defined arc types and treats the pair as forming a nochange
type constraints instead of regular simple setup and hold.

In general, the extracted timing model (ETM) gives precedence to the library-defined
timing types. This means, ETM always extracts those explicitly defined nochange arcs
as nochange arcs in the model. For those implicitly inferred nochange arcs, by
default, ETM extracts them as regular setup and hold arcs.

When you set this variable to true, model extraction aligns with PrimeTime timing
analysis, detect those implicit nochange relationships, and overrides the setup/hold
arc types as nochange the same way as timing analysis does. In certain special path
or arc configuration, this alignment provides better match between timing analysis
with the original netlists and with the extracted model during model validation. The
default value is false.

This variable affects models in all output formats, such as Synopsys database (.db)
and Liberty (.lib) format.

To determine the current value of this variable, type the following:

printvar extract_model_keep_inferred_nochange_arcs

SEE ALSO
extract_model(2)

extract_model_keep_inferred_nochange_arcs
41
extract_model_lib_format_with_check_pins
Determines if PrimeTime model extraction should write the internal check pins
created for Synopsys .db format models explicitly in the .lib format model files.

TYPE

string

DEFAULT

false

DESCRIPTION

When you set this variable to true, the .lib format model files generated by
PrimeTime model extraction has the same set of internal check pins that are created
in the .db format models under certain conditions so that the PrimeTime timing
engine correctly interprets the timing models. The default value is false. This
might mean that the check pins need to be created by the down stream tools that
interpret the .lib model files.

To determine the current value of this variable, type the following:

printvar extract_model_lib_format_with_check_pins

SEE ALSO
extract_model(2)
report_delay_calculation(2)

extract_model_lib_format_with_check_pins
42
extract_model_merge_clock_gating
Indicates whether to merge clock gating setup and hold constraints with only
nonclock gating clock constraints.

TYPE

string

DEFAULT

false

DESCRIPTION

When you set this variable to true, the PrimeTime extract_model command merges clock
gating setup and hold constraints with nonclock gating clock constraints only
keeping the most critical setup and hold constraints for any combination of input
pin and clock edge. Even when the most critical constraint was originated from a
clock gating constraint, the model constraint is not labeled as a clock gating
constraint.

If you intend to use the generated models with a third-party tool that does not
accept multiple setup or hold constraint between the same input pin and clock edge,
set this variable to true. When using models with Synopsys tools, ensure this
variable is set to its default of false.

To determine the current value of this variable, type the following:

printvar extract_model_merge_clock_gating

SEE ALSO
extract_model(2)

extract_model_merge_clock_gating
43
extract_model_noise_iv_index_lower_factor
Controls the scale factor of the minimum index value used to create a steady-state
current table, such as the I-V curve.

TYPE

float

DEFAULT

-1

DESCRIPTION

This variable controls the scale factor of the minimum index value used to create a
steady-state current table (for example, I-V curve). This variable is a scale factor
that is multiplied by Vdd (the power supply voltage). The default value is -1.0. For
example, if Vdd is 1.8, the minimum voltage used is -1.0*1.8 = -1.8.

To determine the current value of this variable, type the following:

printvar extract_model_noise_iv_index_lower_factor

SEE ALSO
extract_model(2)
report_noise(2)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_noise_iv_index_upper_factor(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)
extract_model_num_noise_width_points(3)

extract_model_noise_iv_index_lower_factor
44
extract_model_noise_iv_index_upper_factor
Controls the scale factor of the minimum index value used to create a steady-state
current table, such as the I-V curve.

TYPE

float

DEFAULT

2.0

DESCRIPTION

Controls the scale factor of the maximum index value used to create a steady-state
current table, such as the I-V curve. This variable is a scale factor that is
multiplied by Vdd (the power supply voltage). The default value is 2.0. For example,
if Vdd is 1.8, the maximum voltage used is 2.0*1.8 = 3.6.

To determine the current value of this variable, type the following:

printvar extract_model_noise_iv_index_upper_factor

SEE ALSO
extract_model(2)
report_noise(2)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_noise_iv_index_lower_factor(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)
extract_model_num_noise_width_points(3)

extract_model_noise_iv_index_upper_factor
45
extract_model_noise_width_points
Selects the exact noise width points of extracted noise immunity tables.

TYPE

string

DEFAULT

"" (empty string)

DESCRIPTION

Selects the exact noise width points of extracted noise immunity tables. The default
value for this variable is an empty string. This value is only used if the -noise
option is used with the extract_model command and the library’s noise immunity
tables is selected by PrimeTime SI noise analysis for detecting noise on the input
ports.

The value of this variable is a string of spaced float values. For example,

set extract_model_noise_width_points "0.1 0.2 0.5 1.0"

To determine the current value of this variable, type the following:

printvar extract_model_noise_width_points

SEE ALSO
extract_model(2)
report_noise(2)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)
extract_model_num_noise_width_points(3)

extract_model_noise_width_points
46
extract_model_num_capacitance_points
Controls the size of extracted timing tables by defining the number of capacitance
(load) points in these tables.

TYPE

int

DEFAULT

DESCRIPTION

Controls the size of extracted timing tables by defining the number of capacitance
(load) points in these tables. The default value for this variable is 5.

To determine the current value of this variable, type the following:

printvar extract_model_num_capacitance_points

SEE ALSO
extract_model(2)
extract_model_capacitance_limit(3)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)

extract_model_num_capacitance_points
47
extract_model_num_clock_transition_points
Controls the size of extracted timing tables by defining the number of clock
transition time (slew) points in these tables.

TYPE

int

DEFAULT

DESCRIPTION

Controls the size of extracted timing tables by defining the number of clock
transition time (slew) points in these tables. The default value for this variable
is 5.

To determine the current value of this variable, type the following:

printvar extract_model_num_clock_transition_points

SEE ALSO
extract_model(2)
extract_model_capacitance_limit(3)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_num_data_transition_points(3)
extract_model_num_capacitance_points(3)

extract_model_num_clock_transition_points
48
extract_model_num_data_transition_points
Controls the size of extracted timing tables by defining the number of data
transition time (slew) points in these tables.

TYPE

int

DEFAULT

DESCRIPTION

Controls the size of extracted timing tables by defining the number of data
transition time (slew) points in these tables. The default value for this variable
is 5.

To determine the current value of this variable, type the following:

printvar extract_model_num_data_transition_points

SEE ALSO
extract_model(2)
extract_model_capacitance_limit(3)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_num_clock_transition_points(3)
extract_model_num_capacitance_points(3)

extract_model_num_data_transition_points
49
extract_model_num_noise_iv_points
Controls the size of extracted noise steady-state current tables, for example I-V
curve, by defining the number of index, such as voltage, points in these tables.

TYPE

int

DEFAULT

10

DESCRIPTION

Controls the size of extracted noise steady-state current tables, such as I-V curve,
by defining the number of index (for example, voltage) points in these tables. The
default value for this variable is 10. This value is only used if the -noise option
is used with the extract_model command and if the library’s steady-state current
tables are selected by SI noise analysis for detecting noise on the output and inout
ports.

To determine the current value of this variable, type the following:

printvar extract_model_num_noise_iv_points

SEE ALSO
extract_model(2)
report_noise(2)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_noise_iv_index_lower_factor(3)
extract_model_noise_iv_index_upper_factor(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)
extract_model_num_noise_width_points(3)

extract_model_num_noise_iv_points
50
extract_model_num_noise_width_points
Controls the size of extracted noise immunity tables by defining the number of noise
width points in these tables.

TYPE

int

DEFAULT

DESCRIPTION

Controls the size of extracted noise immunity tables by defining the number of noise
width points in these tables. The default value for this variable is 5. This value
is only used if the -noise option is used with the extract_model command and the
library’s noise immunity tables is selected by PrimeTime SI noise analysis for
detecting noise on the input ports.

To determine the current value of this variable, type the following:

printvar extract_model_num_noise_width_points

SEE ALSO
extract_model(2)
report_noise(2)
extract_model_clock_transition_limit(3)
extract_model_data_transition_limit(3)
extract_model_min_resolution(3)
extract_model_noise_width_points(3)
extract_model_num_clock_transition_points(3)
extract_model_num_data_transition_points(3)

extract_model_num_noise_width_points
51
extract_model_single_pin_cap
This variable is used to provide backward compatability with the introduction of the
mininum, maxium, rise, and fall specific pin capacitances to account for Miller
effect. When the variable is set to its default of true, the models extracted keep
only a single capacitance value for a pin. The capacitance written is the maximum of
all the minimum, maximum, rise, and fall values.

TYPE

string

DEFAULT

true

DESCRIPTION

This variable is needed to deal with libraries accounting for Miller Effect by
having different minimum, maximum, rise, and fall capacitance values for pins of
library cells. The actual timing arcs extracted is not impacted by this variable and
still accounts for the Miller effect if it is available in the library and
applicable in the analysis condition. For minimum and maximum paths and rise and
fall trasitions, the pin capacitances used to calculate the path delay are different
if they are different in the library and the analysis type is not "single" operating
condition.

When you set this variable to false and you are using the .lib and .db file formats,
different minimum, maximum, rise, and fall pin capacitance values are extracted, if
available and applicable. These valuse are written as per the

The only modeling command affected by this variable is the extract_model command.

To determine the current value of this variable, type the following:

printvar extract_model_single_pin_cap

SEE ALSO
extract_model(2)

extract_model_single_pin_cap
52
extract_model_single_pin_cap_max
Provides a method to write only minimum capacitance values in a model that is in
single capacitance mode. If the extract_model_single_pin_cap variable is set to its
default of true, the maximum capacitance is written to the model. If this variable
is set to false, the minimum capacitance is written to the model.

TYPE

string

DEFAULT

true

DESCRIPTION

This variable is needed to deal with libraries accounting for Miller Effect by
having different minimum, maximum, rise, and fall capacitances for pins of library
cells. The actual timing arcs extracted is not impacted by this variable and still
accounts for the Miller effect, if available in the library and applicable in the
analysis condition. For minimum and maximum paths and rise and fall transitions, the
pin capacitances used to calculate the path delay are different if they are
different in the library and the analysis type is not a "single" operating
condition.

This variable only effects the model if the extract_model_single_pin_cap variable is

set to its default of true. If this variable is true and the minimum values if this
variable is set to false, the single capacitance written are the maximum values.

When the variable is false and in .lib and .db formats, different minimum, maximum,
rise, and fall pin capacitance are extracted, if available and applicable. These
values are written as per the .lib and .db syntax.

The only modeling command affected by this variable is the extract_model command.

To determine the current value of this variable, type the following:

printvar extract_model_single_pin_cap_max

SEE ALSO
extract_model(2)
extract_model_single_pin_cap(3)

extract_model_single_pin_cap_max
53
extract_model_split_partial_clock_gating_arcs
Controls whether to split the incomplete clock gating check setup and hold arcs in
the extracted timing model (ETM).

TYPE

string

DEFAULT

false

DESCRIPTION

When the value is set to its default of false, all clock gating checks are merged
together and attached to the same pin.

When you set this variable to true and model extraction detects clock gating setup
and hold constraints that cannot be paired together, a seperate internal check pin
is created to avoid difference in timing analysis with the model in PrimeTime.

This variable affects models in all output formats, such as the Synopsys database
(.db) and Liberty (.lib) formats.

Standard clock gating constraint is essentially a no-change check to ensure that the
active clock pulses are not clipped by the gating control signal. Therefore, setup
and hold arcs need to be paired to check against opposite edges of the active clock
pulse. For example, a setup on clock rise arc needs to be paired with a hold on
clock fall edge to ensure no clipping of the positive clock pulse by the gating
signal. However, there is no explicit syntax support in the Library to define such
arc pairing. Therefore, the pairing must occur automatically by PrimeTime when
lirary cell timing arcs are analyzed. Consequently, this pair-wise relationship
between setup and hold also determines the clock edges/cycles to be used when
performing the checks.

In particular, when setup check present, the hold check is performed on the edge
whose opposit edege has been pre-chosen as the most constraining or setup analysis.
In cases where a proper pairing relationship cannot be established among the arcs,
PrimeTime treats the missing part as not being constrained. If the setup check is
missing, hold is used as the primary constaint in choosing the most constaining
edge.

As a compact timing model, ETM retains the most constraining relationship exists
between an input port and its related clock port. There are many paths and endpoints
that contribute to the constraints between them. ETM must evaluate the worst-case
and lump all the originally separate clock gating checks existed in pair but at
different cells in the netlist into simple setup/hold arcs all between the same
input and clock of the macro library cell. In doing so, the details of the original
arc and path pairing relationship is lost, resulting in potentially different arc
pairing when the ETM is used versus during netlist timing. Consequently, model
validation may show a mismatch dur to differen clock edges are used for the

extract_model_split_partial_clock_gating_arcs
54
orginally mis-pairing check. The difference arises most commonly when:

• The original setup and hold arcs in the library cells in the netlist are not
standard clock-gating checks.For example, they are defined to be the same clock
edge.

• There are non-unate clock paths reaching the same cell, or a mixture of inverting
and non-inverting clock paths reaching different gating check cells.

To retain the original arc relationships without the standard syntax support in
Liberty to define arc pairing, internal pins need to be introduced to force split of
different classes of pairing on to different pins. This arc seperation controls the
automatic pairing process when ETM is used in PrimeTime, thus reproducing the
original timing behavior existed in the netlist.

To determine the current value of this variable, type the following:

printvar extract_model_split_partial_clock_gating_arcs

SEE ALSO
extract_model(2)
extract_model_capacitance_limit(3)

extract_model_split_partial_clock_gating_arcs
55
extract_model_status_level
Controls the message displaying for progress of the model extraction process.

TYPE

string

DEFAULT

none

DESCRIPTION

Controls the number of progress messages displayed during the timing model
extraction process. The allowed values are the default of none, low, medium, and
high.

When set to none, no messages are displayed. When set to low, medium, or high, the
progress of the model extraction is reported.

The number of messages varies based on the value of the variable, as follows:

• When set to low, messages are displayed at the beginning of major phases of the
extract_model command.

• When set to medium, all messages for low are displayed. Additionally, messages are
displayed at the beginning of extraction subphases that may involve significant
processing time.

• When set to high, all messages for medium are displayed. Additionally, percent
complete messages are displayed for the long running subphases.

To determine the current value of this variable, type one of the following:

printvar extract_model_status_level

echo $extract_model_status_level

SEE ALSO
extract_model(2)

extract_model_status_level
56
extract_model_suppress_three_state
Determines report delay calculation to be performed on the timing arcs contained in
models.

TYPE

string

DEFAULT

false

DESCRIPTION

The default value is false. When you set this variable to true, the models generated
by PrimeTime model extraction does not contain the is_three_state pin attribute.

The extract_model command adds the is_three_state pin attribute to the allows for
the extracted models to be used along with other three state drivers. PrimeTime
assumes that only one of the three state drivers is driving at a time.

The is_three_state pin attribute is supported by Library Compiler version W-2004.12-

SP2 and later and PrimeTime version X-2005.06 and later.

To determine the current value of this variable, type the following:

printvar extract_model_suppress_three_state

SEE ALSO
extract_model(2)

extract_model_suppress_three_state
57
extract_model_use_conservative_current_slew
Enables or disables the adjustment with the current context slew if it is more
conservative during the extraction of a timing path. The adjusted models model the
netlist behavior better if the netlist is in the worst_slew propagation mode.

TYPE

string

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, no adjustment is made in the
extraction and the models created is the same as before extracting it. When you set
the variable to true, the extracted tables are adjusted with the current context
slew, if it is more conservative to do so. This results in a model that generally
passes the model validation better if the netlist is also timed in the worst_slew
slew-propagation mode. The adjusted model is generally more pessimistic compare to
the model extracted when the variable is set to its default of false.

This variable is only effective if the value of the timing_slew_propagation_mode

PrimeTime variable is set to the worst_slew value before processing the model
extraction.

The only modeling command affected by this variable is the extract_model command.
All formats of the extraced models are affected.

To determine the current value of this variable, type the following:

printvar extract_model_use_conservative_current_slew

SEE ALSO
extract_model(2)
timing_slew_propagation_mode(3)

extract_model_use_conservative_current_slew
58
extract_model_with_3d_arcs
Enables or disables creating models contain arcs with three-dimentional delay and
transition tables.

TYPE

string

DEFAULT

true

DESCRIPTION

When this variable is set to its default of true, the PrimeTime model-generating
commands attempt to merge certain output-to-output delays, clock-to-output, or both
arcs into three-dimensional arcs with related_output_load as the third variable in
the delay table, transition table, or both tables.

When you set this variable to false, the model keeps all output-to-output, clock-to-
output, or both constraint arcs as they are, which is the default behavior of model
extraction for PrimeTime version T-2002.09 and earlier releases.

The only modeling command affected by this variable is the extract_model command.
All formats of the extraced models are affected.

If your downstream tools do not know how to handle timing arcs with three-
dimensional delay tables, set this variable to false before extracting the timing
model.

To determine the current value of this variable, type the following:

printvar extract_model_with_3d_arcs

SEE ALSO
extract_model(2)

extract_model_with_3d_arcs
59
extract_model_with_clock_latency_arcs
Enables or disables creating clock tree latency, or clock insertion delay arcs in
the extracted timing models (ETM).

TYPE

string

DEFAULT

false

DESCRIPTION

When you set this variable to true, the PrimeTime model-generating commands traverse
all the clock tree paths, compute the insertion delay of the paths, and create clock
latency arcs in the model. Note clock insertion delay is the path delay measured
between clock source and the destination registers, constraints from such as clock-
gating cells are not considered.

When this variable is set to its default of false, the extracted models do not have
clock insertion delay arcs in them. This is the default behavior of model extraction
for PrimeTime version U-2003.03 and earlier releases.

The only modeling commands affected by this variable is the extract_model command.
All formats of the extracted models are affected.

If you extracted models with clock latency arcs in them and the format of the models
is .lib, you are required to use the Library Compiler version V-2003.12 or later to
compile the model.

The clock latency arcs are meant to be used by tools such as Astro and Physical
Compiler to compensate and balance clock tree skews at chip level. Those clock
latency arcs in the models are also respected by the report_clock_timing PrimeTime
command when reporting the clock tree latency and skews. Commands such as the
report_delay_calculation, set_timing_derate, set_annotated_delay, and
get_timing_arcs commands also recognize the new insertion delay arcs.

To determine the current value of this variable, type the following:

printvar extract_model_with_clock_latency_arcs

SEE ALSO
extract_model(2)
report_clock_timing(2)

extract_model_with_clock_latency_arcs
60
extract_model_with_min_max_delay_constraint
Enables or disables creating models contain set_min/max_delay constraints.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default value of false, it indicates that the
PrimeTime model-generating commands ignore all of the set_min_delay and
set_max_delay constraints; you must delete these constraints before extracting the
model to pass the model validation. When you set this variable to true, the
PrimeTime model-generating commands create internal check pins and construct arcs
between ports and internal check pins. PrimeTime also writes the set_min_delay and
set_max_delay constraints into constraint files.

The only modeling commands affected by this variable is the extract_model command.
All formats of the extracted models are also affected.

To determine the current value of this variable, type the following:

printvar extract_model_with_min_max_delay_constraint

SEE ALSO
extract_model(2)
set_max_delay(2)
set_min_delay(2)

extract_model_with_min_max_delay_constraint
61
extract_model_write_case_values_to_constraint_file
Controls whether to write logic values seperately into the extracted timing model
(ETM) constraint file due to the user-defined case analysis value propagation.

TYPE

string

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, all logic constant values
reaching block I/O ports are written into the .lib and .db files as a function
attribute for the pin. This occurs regardless of whether the logic value is due to
propagate circuit intrinsic functional constants or user-defined case analysis
values. This is the behavior of the ETM.

When you set this variable to true and model extraction detects any logic constant
set or propagated to the I/O boundary of the block as a result of user-defined
analysis settings, the logic value is written into the ETM constraint file with the
proper set_case_analysis command.

This variable affects models in all output formats, such as Synopsys database (.db)
and Liberty (.lib) formats.

An ETM generated by PrimeTime, captures I/O timing behavior for the purpose of
static timing analysis. By design, the primary flow intention is to improve the
capacity and performance of downstream consumer tools in their timing driven
implementation, optimization, and analysis steps. By design, the ETM does not retain
any functional information about the original netlist and is essentially a
functional black-box. Lacking functional definition, an ETM by itself might not be
well suited for design steps where the cell function is of primary concern. However,
because logic values and their propagation impact timing of both the block and
higher level netlist where the model becomes instances, ETMs have to keep the logic
values from the block that propagated to the output ports, so that their effects to
timing analysis can be carried consistently to higher level. These logic values can
come from inherent netlist logic constants or from user-defined case analysis
values. PrimeTime represents the logic values of the macro block with the simple
function attribute on pins. This ensures consistency from a timing analysis
perspective. For certain design flows where some tools consuming ETMs in certain
steps need to be able to differentiate logic values resulted from functional
constant versus case analysis propagation. Optionally, it is possible to write logic
values resulting from case analysis to a seperate constraint file, and write only
the functional constant with function attribute.

It is worth noting that the constraint file written along with the .lib, .db model,
or both files should be used together with the ETM to completely reproduce the
timing behavior of the original netlist with the model.

extract_model_write_case_values_to_constraint_file
62
To determine the current value of this variable, type the following:

printvar extract_model_write_case_values_to_constraint_file

SEE ALSO
extract_model(2)
set_case_analysis(2)

extract_model_write_case_values_to_constraint_file
63
extract_model_write_verilog_format_wrapper
Write Verilog format wrapper for wrapper plus core style ETM.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to its default of false, the extract_model command
generates a database format wrapper for wrapper plus core style extracted timing
model (ETM). When you set this variable to true, a Verilog format wrapper is created
instead.

To determine the current value of this variable, type the following:

printvar extract_model_write_verilog_format_wrapper

SEE ALSO
extract_model(2)

extract_model_write_verilog_format_wrapper
64
hier_modeling_version
Specifies the current modeling technique version.

TYPE

float

DEFAULT

1.0

DESCRIPTION

Specifies the current modeling technique version. In the default version of 1.0, the
verification script duplicates constraints in the instance script. There is no good
way to test the instance script. When an ETM is instantiated at the top level, you
must change the names of generated clocks in the constraint file so they match the
names of clocks. For ILM, when a model is instantiated more than once at the top
level, you must also change the constraint file such that the names of clocks are
uniqified.

If you set this variable to 2.0, the -validate option of the create_ilm and
extract_model commands is enabled, and the generated models are automatically
validated after they are created. In addition, all interface logic model (ILM) files
generated are added to the pt_model_dir/ILM/design_name directory, and all extracted
timing model (ETM) files are added to the pt_model_dir/ETM/output directory. These
names are consistent for ILM and ETM.

In version 2.0, a test design is always created for ETM and ILM. This netlist
information of the test design is in the mod_verif.v file. The constraints in the
mod_verif.pt.gz file are those constraints that define the outside context (for
example, the set_input_delay command), and the constraints in the mod_inst.pt.gz
file are those constraints that are brought to the top level by the model. The
mod_verif.pt.gz file sources the mod_inst.pt.gz file directly, and there are no
duplicated constraints in these two files.

In version 2.0, all constraints in the mod_inst.pt.gz file are in a Tcl procedure.
This procedure has two arguments: inst_name and clock_name_prefix. The constraint
file needs to be sourced only once although the model might be instantiated more
than once. The names of clocks whose sources are inside the block and all generated
clocks are uniquified. You do not need to change the constraint script to uniquify
clocks. You do not need to use the current_instance command before sourcing this
constraint file.

In version 2.0, internal nongenerated clocks are created in the mod_inst.pt.gz file
for ETM. The uncertainty information of all generated clocks and internal
nongenerated clocks are also added to the mod_inst.pt.gz file.

To determine the current value of this variable, type one of the following:

printvar hier_modeling_version

hier_modeling_version
65
echo $hier_modeling_version

SEE ALSO
create_ilm(2)
extract_model(2)
pt_model_dir(3)

hier_modeling_version
66
hier_scope_check_defaults
Defines the types of scope checks to be performed by the check_block_scope command
or reported by the report_scope_data command. Note that this variable does not
impact the scope information to be captured by the create_ilm and extract_model
PrimeTime model creation commands.

The allowed value for this variable is one or more of the following: clock_arrival,
clock_transition, data_input_arrival, data_input_transition, clock_uncertainty, and
clock_skew_with_uncertainty.

TYPE

list

DEFAULT

clock_arrival clock_transition clock_skew_with_uncertainty

GROUP

hierarchy_variables

DESCRIPTION

All the applicable scoping information is captured and store in files during the
block-level analysis and model creation time. When integrating at the top-level with
some blocks being replaced by their timing models, it is recommended that you
perform the checks to confirm that the models are indeed instantiated within the
ranges they are originally validated for. Any violations reported by the scope check
for the model can potentially result in timing violations; however, there is no
implication by the scope violation on whether, where, and how much the timing
violations would be.

You can use this variable to customize the types of scope checks to be performed by
the check_block_scope command at top-level and concentrate on the ones that are
important for the flow and each instance.

SEE ALSO
check_block_scope(2)
create_ilm(2)
extract_model(2)
report_scope_data(2)

hier_scope_check_defaults
67
hierarchy_separator
Determines how hierarchical elements of the netlist are delimited in reports and how
they are searched for in selections and other commands.

TYPE

string

DEFAULT

/ (forward slash)

DESCRIPTION

This command determines how hierarchical elements of the netlist are delimited in
reports and how they are searched for in selections and other commands. The choice
of a separator is limited to these characters: bar (|), caret (^), at (@), dot (.),
and the default of a forward slash (/).

Normally, you should accept the default, forward slash (/). However, in some cases
where the hierarchy character is embedded in some names, the search engine might
produce results that are not intended. Using the hierarchy_separator variable is a
convenient method for dealing with this situation. For example, consider a design
that contains a hierarchical cell A, which contains hierarchical cells B and B/C; B/
C contains D; B contains C. Searching for A/B/C/D is ambiguous and might not match
what you intended. However, if you set the hierarchy_separator variable to the
vertical bar |, searching for A | B/C | D is explicit, as is A | B | C | D.

SEE ALSO
selection(2)

hierarchy_separator
68
ilm_ignore_percentage
Specifies a threshold for the percentage of total registers in the transitive fanout
of an input port, beyond which the port is to be ignored when identifying interface
logic.

TYPE

float

DEFAULT

25

DESCRIPTION

Specifies a minimum threshold for the percentage of the total registers in the
transitive fanout of an input port, beyond which the port is to be ignored when
identifying interface logic.

This variable affects the -auto_ignore option of the identify_interface_logic

command. The -auto_ignore option automatically determines those ports (for example,
scan enable and reset ports) that should be ignored when the
identify_interface_logic command places the is_interface_logic_pin attribute on
objects to identify them as part of the interface logic model (ILM) for the design.
Ports are automatically ignored if they fan out to a percentage of total registers
in the design greater than the value specified by this variable.

For more information about creating ILMs and associated commands, see the
identify_interface_logic man page.

To determine the current value of this variable, type following:

printvar ilm_ignore_percentage

SEE ALSO
identify_interface_logic(2)

ilm_ignore_percentage
69
in_gui_session
This read-only variable is true when the graphical user interface (GUI) is active
and false, the default, when the GUI is inactive.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

You can use this variable when writing Tcl code that depends on the presence of the
GUI. If you have invoked the gui_start command and the GUI is active, the read-only
variable is true. Otherwise, the variable is false and the GUI is inactive.

SEE ALSO
gui_start(2)
gui_stop(2)

in_gui_session
70
library_pg_file_pattern
Specifies the file name pattern for the power and ground (PG) Tcl side files for
library PG conversion and update.

TYPE

string

DEFAULT

""

DESCRIPTION

Use this variable to specify the file name pattern for the PG Tcl side files for
library PG conversion and update. By setting the variable to a valid file name
pattern, the tool finds the associated PG Tcl side file for the technology libraries
provided. At library loading time, the tool performs on-the-fly PG updates on the
in-memory databases. With this on-the-fly library PG conversion and update
capability, the tool relaxes the requirement of complete PG pin library for UPF
specifications.

As default, the variable is set to "", which means that there is no PG Tcl side
file, unless specified.

For advanced users, string substitution can be used for finding PG Tcl side file
(limit one occurrence per pattern):

- use pattern "__DIR__" for path to .db dir - use pattern "__FILE__" for leaf file
name for .db

There can be one Tcl for all databases, one Tcl per database, or one Tcl per a group
of databases. For examples,

1. One Tcl for all databases: a. At the current directory

set library_pg_file_pattern "libpg_sidefile.pg"

b. At different location

set library_pg_file_pattern "/my_dir/libpg_sidefile.pg"

2. One Tcl per database: a. At the same location as the original database files

set library_pg_file_pattern "%d/%f.pg"

b. At a directory called "pg_sidefiles" under the same directory as original the

original database

set library_pg_file_pattern "%d/pg_sidefiles/%f.pg"

library_pg_file_pattern
71
c. At a different location called "/my_dir"

set library_pg_file_pattern "/my_dir/%d/%f.pg"

3. One Tcl for a group of databases at the same location as the database files

set library_pg_file_pattern "%d/libpg_sidefile.pg"

Note: You must set this variable before loading the libraries.

This on-the-fly database updates is disabled in the power domain backward

compatibility mode (set power_domains_compatibility TRUE).

To determine the current value of this variable, type one of the following:

printvar library_pg_file_pattern

echo $library_pg_file_pattern

SEE ALSO
power_domains_compatibility(3)

library_pg_file_pattern
72
link_allow_design_mismatch
Controls the behavior of the link design when pin mismatch between instance and
reference occur.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable controls whether the link still succeeds or not when pin mismatches
between instance and reference occur. By default, link fails when there are pin
mismatches between instance and reference. For example, when a pin exists in the
instance but does not exist in the library, link issues an error and fails. When you
set this variable to true, this extra pin is ignored and the link still succeeds.
This allows you to gather as many as possible useful information even when part of a
design is in the early stage.

Common causes of those mismatches include:

1) A pin has different directions in instance and reference.

2) A pin of instance does not exist in reference.
3) A bus has different widths in instance and reference.

When a mismatch occurs, reference always wins. For case 1, the direction of the pin
in the linked design is from reference; for case 2, that pin is ignored and does not
exist in the reference; for case 3, all extra bits in instance are ignored, and the
bus width in the linked design is the same with the bus width from reference.

Note that for bus width mismatch, LSB of instance is mapped to LSB of reference, and
all extra bits of instance are ignored and all extra bits of reference are dangling.

To determine the current value of this variable, type one of the following:

printvar link_allow_design_mismatch

echo $link_allow_design_mismatch

To report mismatches found in link, use report_design_mismatch command.

SEE ALSO
report_design_mismatch(2)

link_allow_design_mismatch
73
link_create_black_boxes
Enables the linker to automatically convert each unresolved reference into a black
box.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When this variable is set to the default of true, the linker automatically converts
each unresolved reference into a black box, which is essentially an empty cell with
no timing arcs. The result is a completely linked design on which analysis can be
performed.

When you set this variable to false, unresolved references remain unresolved and
most analysis commands cannot function.

To determine the current value of this variable, type one of the following:

printvar link_create_black_boxes

echo $link_create_black_boxes

SEE ALSO
link_design(2)
search_path(3)

link_create_black_boxes
74
link_force_case
Controls the case sensitivity behavior of the link design command.

TYPE

string

DEFAULT

check_reference

DESCRIPTION

This variable controls the case-sensitive or insensitive behavior of the link_design

command. Allowed values are the default of check_reference, case_sensitive, or
case_insensitive. The check_reference option means that the case sensitivity of the
link is determined only by the case sensitivity of the input format that created
that reference. For example, a VHDL reference is linked case-insensitively, whereas
a Verilog reference is linked case-sensitively.

Some caveats apply to this variable, as follows:

1. Do not set the link_force_case variable to case_insensitive if you are reading in

source files from case-sensitive formats (for example, Verilog). Doing so could
cause inconsistent, unexpected, and undesirable results. For example, you might have
an instance u1 of design ’inter’, but might have loaded a design ’Inter’. If you do
a case-insensitive link, you get design ’Inter’. The side effect is that the
relationship between u1 and ’inter’ is gone; it has been replaced by a relationship
between u1 and ’Inter’. Changing the link_force_case variable back to
check_reference or case_sensitive does not restore the original relationship. You
would have to remove the top design, reload it, and relink. Note: Design Compiler
has the same restriction.

2. Do not change the value of this variable within a session. Doing so could cause
numerous error and warning messages that can cause confusion.

3. Be aware that setting the link_force_case variable to case_insensitive can

decrease the performance of the link_design command.

To determine the current value of this variable, type one of the following:

printvar link_force_case

echo $link_force_case

For a list of all link-related variables and their current values, use the printvar
link* command.

SEE ALSO
link_design(2)

link_force_case
75
link_create_black_boxes(3)

link_force_case
76
link_library
This is a synonym for the link_path variable.

SEE ALSO
link_path (3)

link_library
77
link_path
Specifies a list of libraries, design files, and library files used during linking.

TYPE

list

DEFAULT

DESCRIPTION

Specifies a list of libraries, design files, and library files used during linking.
The link_design command looks at those files and tries to resolve references in the
order of the specified files.

The link_path variable can contain three different types of elements: *, a library
name, or a file name.

The "*" entry in the value of this variable indicates that the link_design command
should search all the designs loaded in the pt_shell while trying to resolve
references. Designs are searched in the order in which they were read.

For elements other than "*", PrimeTime searches for a library that has already been
loaded. If that search fails, PrimeTime searches for a file name using the
search_path variable.

To determine the current value of this variable, type one of the following:

printvar link_path

echo $link_path

SEE ALSO
link_design(2)
printvar(2)
search_path(3)

link_path
78
link_path_per_instance
Overrides the default link path for selected leaf cell or hierarchical cell
instances.

TYPE

list

DEFAULT

(empty)

DESCRIPTION

This variable, which takes effect only if set prior to linking the current design,
overrides the default link_path variable for selected leaf cell or hierarchical cell
instances. The format is a list of lists. Each sublist consists of a pair of
elements: a set of instances, and a link_path specification that should be used for
and within these instances. For example,

set link_path {* lib1.db}

set link_path_per_instance [list
[list {ucore} {* lib2.db}]
[list {ucore/usubblk} {* lib3.db}]]

Entries are used to link the specified level and below. If a given block matches
multiple entries in the per-instance list, the more specific entry overrides the
more general entry. In the example above:

1. lib3.db would be used to link blocks ’ucore/usubblk’ and below.

2. lib2.db would be used to link ’ucore’ and below (except within ’ucore/subblk’).

3. lib1.db would be used for the remainder of the design (everything except within
’ucore’).

The default value of the link_path_per_instance variable is an empty list, meaning

that the feature is disabled.

To determine the current value of this variable, use one of the following:

set link_path_per_instance

echo $link_path_per_instance

SEE ALSO
link_design(2)
link_path(3)
link_path_per_instance(3)

link_path_per_instance
79
lp_default_ground_pin_name
Specifies the default ground pin name for creating default PG pins for the library
cells in non-PG pin libraries.

TYPE

string

DEFAULT

""

DESCRIPTION

Use this variable to specify the default ground pin name for default PG pin
creation. This variable is also used for ground pin name for database conversion for
legacy rail_connection libraries. One default power and one default ground PG pins
are created for the library cells in non-PG pin libraries, which will be performed
on the in-memory databases by the tool at library loading time. With this
capability, the tool relaxes the requirement of PG pin library for UPF
specifications.

The name is used for pg_pin of library cells and voltage_map defined at library
level. For library cells from PG pin libraries, the variable have no impact. The
default PG pin creation isl only triggered when the PG Tcl side file is not provided
(specified by the library_pg_file_pattern variable). UPF explicit connections (using
the connect_supply_net command) are not allowed on default PG pins created based on
the default PG pin name variables.

The default of this variable is empty "", which means that there is no default PG
pin added unless specified. To enable default PG pin creation, set the
lp_default_power_pin_name variable to a valid name.

Note: You must set this variable before loading libraries.

Database updates are disabled in power domain backward compatibility mode (when you
set the power_domains_compatibility variable to true).

To determine the current value of this variable, type one of the following:

printvar lp_default_ground_pin_name

echo $lp_default_ground_pin_name.

SEE ALSO
connect_supply_net(2)
library_pg_file_pattern(3)
lp_default_power_pin_name(3)
power_domains_compatibility(3)

lp_default_ground_pin_name
80
lp_default_power_pin_name
Specifies the default Power pin name for creating default PG pins for the library
cells in non-PG pin libraries.

TYPE

string

DEFAULT

""

DESCRIPTION

Use this variable to specify the default Power pin name for default PG pin creation.
One default power and one default ground PG pins is created for the library cells in
non-PG pin libraries, which is performed on the in-memory databases by the tool at
the time the library is loaded. With this capability, the tool relaxes the
requirement of PG pin library for UPF specifications.

The name is used for pg_pin of library cells and voltage_map defined at library
level. For library cells from PG pin libraries, the variable have no impact. The
default PG pin creation is triggered only when the PG Tcl side file is not provided
(specified by the library_pg_file_pattern variable). UPF explicit connections (using
the connect_supply_net) is not allowed on default PG pins created based on the
default PG pin name variables.

The default of this variable is empty "", which means that there is no default PG
pin added unless specified. To enable default PG pin creation, you must set the
lp_default_ground_pin_name variable to a valid name.

Note: You must set this variable before loading the library.

The database updates are disabled in power domain backward compatibility mode (Use
the set power_domains_compatibility TRUE command).

To determine the current value of this variable, type one of the following:

printvar lp_default_power_pin_name

echo $lp_default_power_pin_name.

SEE ALSO
connect_supply_net(2)
library_pg_file_pattern(3)
lp_default_ground_pin_name(3)
power_domains_compatibility(3)

lp_default_power_pin_name
81
model_validation_capacitance_tolerance
Specifies the absolute error tolerance for capacitance data.

TYPE

list

DEFAULT

{0.001 0.001}

DESCRIPTION

Specifies the absolute error tolerance for capacitance data. If this is used in
conjunction with the -percent_tolerance option, both tolerances must be exceeded to
cause a FAIL. For information about other absolute tolerances, see the
model_validation_timing_tolerance man page.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_capacitance_tolerance

echo $model_validation_capacitance_tolerance.

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)
model_validation_timing_tolerance(3)

model_validation_capacitance_tolerance
82
model_validation_ignore_pass
Excludes all passing comparisons; therefore, fails are only displayed if this
variable is set to its default of true.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Excludes all passing comparisons; therefore, fails are only displayed if this
variable is set to its default of true.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_ignore_pass

echo $model_validation_ignore_pass

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)

model_validation_ignore_pass
83
model_validation_output_file
The name of the file that stores the model validation results.

TYPE

string

DEFAULT

verif.out

DESCRIPTION

Specifies where the model validation results should be written. If this variable is
empty, the results are printed at the standard output. If no path is given in this
name, this file is created in the model_validation subdirectory under the directory
specified by the pt_model_dir variable.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_output_file

echo $model_validation_output_file

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)
pt_model_dir(3)

model_validation_output_file
84
model_validation_pba_clock_path
Perform path-based analysis on clock portion of mismatched paths.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

By default, path-based analysis in model validation is only performed on the data

portion of mismatched paths. When you set this variable to true, path-based analysis
is performed on the clock portion too. This can help resolving mismatched paths.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_pba_clock_path

echo $model_validation_pba_clock_path

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)

model_validation_pba_clock_path
85
model_validation_percent_tolerance
Specifies the absolute error tolerance for time data during model validation.

TYPE

list

DEFAULT

{0.00 0.00}

DESCRIPTION

This option is similar to the model_validation_timing_tolerance variable except that

it uses the percent relative error instead of an absolute error. The exception is
that slack data ignores this variable and uses only the
model_validation_timing_tolerance variable. If this variable is specified in
conjunction with either the model_validation_timing_tolerance or
model_validation_capacitance_tolerance variable, both tolerances must be exceeded to
cause a FAIL.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_percent_tolerance

echo $model_validation_percent_tolerance

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)
model_validation_timing_tolerance(3)
model_validation_capacitance_tolerance(3)

model_validation_percent_tolerance
86
model_validation_reanalyze_max_paths
Specifies the maximum number of mismatched paths that are analyzed again.

TYPE

int

DEFAULT

1000

DESCRIPTION

During automatic model validation, some mismatched paths after graph-based analysis
are reselected to do path-based analysis. This variable specifies the maximum number
of selected paths. The smaller the number, the faster the validation occurs;
however, more unresolved mismatches might occur.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_reanalyze_max_paths

echo $model_validation_reanalyze_max_paths

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)

model_validation_reanalyze_max_paths
87
model_validation_report_split
Allow line-splitting in report.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Allows line-splitting in a report. This is most useful for performing diffs on

previous scripts or for postprocessing the script.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_report_split

echo $model_validation_report_split

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)

model_validation_report_split
88
model_validation_section
Specifies a list of data sections to be included in the comparison.

TYPE

string

DEFAULT

"" (empty)

DESCRIPTION

Specifies a list of data sections to be included in the validation; only those

sections are validated. By default, all sections are validated. If it is not empty,
defined sections are validated. The following list describes the keywords that are
accepted in the section_list as valid:

• slack — Specifies that only worst-case slacks are to be validated.

• transition_time — Specifies that only actual transition times on ports are to be

validated.

• capacitance — Specifies that only actual capacitances on ports are to be

validated.

• design_rules — Specifies that only design rules on ports are to be validated.

• missing_arcs — Specifies that only arcs in the reference timing file that are
missing from the compare timing file are to be included in the report.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_section

echo $model_validation_section

SEE ALSO
create_ilm(2)
extract_model(2)

model_validation_section
89
hier_modeling_version(3)

model_validation_section
90
model_validation_significant_digits
Specifies the number of digits to the right of the decimal point that are to be
reported in the validation results.

TYPE

int

DEFAULT

DESCRIPTION

Allowed values are 0-13. The default value is 2.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_significant_digits

echo $model_validation_significant_digits

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)

model_validation_significant_digits
91
model_validation_sort_by_worst
Specifies that the output is to be sorted from worst to best.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Specifies that the output is to be sorted from negative to positive, with the worst
failure first. After the FAIL section, all PASS lines are sorted alphabetically
within each path attribute.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_sort_by_worst

echo $model_validation_sort_by_worst

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)

model_validation_sort_by_worst
92
model_validation_timing_tolerance
Specifies the absolute error tolerance for time data during model validation.

TYPE

list

DEFAULT

{0.01 0.01}

DESCRIPTION

Specifies the absolute error tolerance for time data during model validation. Each
tolerance is a list of either one or two floating point numbers. All tolerances are
inclusive, and the sign of the values has no effect. If there is only one number it
serves to specify both the plus and minus tolerances. The plus tolerance is the
absolute value of the number, and the minus tolerance is the inverse of the plus. If
this is used in conjunction with the model_validation_percent_tolerance variable,
both tolerances must be exceeded to cause a FAIL. For other absolute tolerances, see
the model_validation_capacitance_tolerance man page.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

To determine the current value of this variable, type one of the following:

printvar model_validation_timing_tolerance

echo $model_validation_timing_tolerance

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)
model_validation_percent_tolerance(3)

model_validation_timing_tolerance
93
model_validation_verbose
Specifies that detailed debugging of mismatched paths is performed.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Specifies that a detailed debugging of mismatched paths is performed. When this

variable is set to its default of true, a detailed debugging of mismatched paths is
performed, which generates a report that shows why those paths are mismatched. The
name of the report is the name of the output file specified by the
model_validation_output_file variable with the .detail extension.

For ILMs, the tolerance of delay and slews is one-tenth of the tolerance specified
by the model_validation_timing_tolerance variable, and the tolerance of capacitance
is the same with the model_validation_capacitance_tolerance variable. If either of
these tolerances are violated for a stage, the detailed information of this stage is
printed; however, only the first stage violating the tolerances is printed.

For ETMs, since paths from the model are generally simple, the report_etm_arc style
report is printed for each mismatched arc and stage information is not compared.

If it is found that the topologies of paths from the netlist and the model are
different with each other, another detailed debugging is performed: the exactly same
path from the model is selected from the netlist and compared against with the
original path selected from the netlist. This debugging can help you understand why
the create_ilm or extract_model command picks a different critical path.

This variable is effective only in the automatic model validation flow, such as when
the output from either the create_ilm or extract_model command is used with the -
validate option. The output of the compare_interface_timing command is not affected
by this variable.

EXAMPLES

The following examples shows that the mismatch is because an aggressor that is not
screened in the block gets screened when the interface logic model (ILM) is used.

Netlist path:

Startpoint: IN (input port clocked by CLK)

Endpoint: ff1 (rising edge-triggered flip-flop clocked by CLK’)
Path Group: CLK
Path Type: max

model_validation_verbose
94
 Point Fanout Cap Trans Incr Path
-------------------------------------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock network delay (propagated) 0.00 0.00
input external delay 0.20 0.20 f
IN (in) 0.00 0.00 0.20 f
IN (net) 1 1.00
U1/A (ND2) 0.00 0.00 0.20 f
U1/Z (ND2) 0.17 0.67 & 0.87 r
n1 (net) 1 1.23
ff1/D (FD1) 0.18 0.01 & 0.88 r
data arrival time 0.88

clock CLK’ (rise edge) 0.60 0.60

clock source latency 0.00 0.60
CLK (in) 0.00 0.00 0.60 f
CLK (net) 3 3.00
U2/A (IV) 0.00 0.00 0.60 f
U2/Z (IV) 0.14 0.52 1.13 r
n2 (net) 1 1.00
ff1/CP (FD1) 0.14 0.00 1.13 r
library setup time -0.80 0.33
data required time 0.33
-------------------------------------------------------------------------------
data required time 0.33
data arrival time -0.88
-------------------------------------------------------------------------------
slack (VIOLATED) -0.55

The dominant exceptions are:

None

Model path:

Startpoint: IN (input port clocked by CLK)

Endpoint: ff1 (rising edge-triggered flip-flop clocked by CLK’)
Path Group: CLK
Path Type: max
Scenario: model_validation

Point Fanout Cap Trans Incr Path

-------------------------------------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock network delay (propagated) 0.00 0.00
input external delay 0.20 0.20 f
IN (in) 0.00 0.00 0.20 f
IN (net) 1 1.00
U1/A (ND2) 0.00 0.00 0.20 f
U1/Z (ND2) 0.17 0.67 & 0.87 r
n1 (net) 1 1.23
ff1/D (FD1) 0.17 0.00 & 0.87 r
data arrival time 0.87

model_validation_verbose
95
 clock CLK’ (rise edge) 0.60 0.60
clock source latency 0.00 0.60
CLK (in) 0.00 0.00 0.60 f
CLK (net) 3 3.00
U2/A (IV) 0.00 0.00 0.60 f
U2/Z (IV) 0.14 0.52 1.13 r
n2 (net) 1 1.00
ff1/CP (FD1) 0.14 0.00 1.13 r
library setup time -0.80 0.33
data required time 0.33
-------------------------------------------------------------------------------
data required time 0.33
data arrival time -0.87
-------------------------------------------------------------------------------
slack (VIOLATED) -0.54

The dominant exceptions are:

None

Stage 0 with difference :

Point Fanout Cap Trans Incr Path
-----------------------------------------------------------------------------
U1/Z (ND2) 0.17 0.67 & 0.87 r
U1/Z (ND2) 0.17 0.67 & 0.87 r
ff1/D (FD1) 0.18 0.01 & 0.88 r
ff1/D (FD1) 0.17 0.00 & 0.87 r
-----------------------------------------------------------------------------
Path Aggressor Screen Switching Bump
Net (ratio of VDD)
----- ---------------------- ---------------- ---------------
0 n5 active 0.03
1 n5 screened_by_macro_model
0.00
-------------------------------------------------------------------------------

SEE ALSO
create_ilm(2)
extract_model(2)
hier_modeling_version(3)

model_validation_verbose
96
multi_core_allow_overthreading
Controls over-threading with more than one thread per CPU core.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Given a maximum limit on the CPU cores that the current PrimeTime process can use,
the count of simultaneously active threads can exceed that limit. This is determined
differently for different threaded algorithms and commands. The degree of
overthreading is set up with the guarantee that most of the time the cores usage
limit that you set is honored. However, it is possible that for very short
intervals, the usage might exceed that limit. If this is absolutely undesirable,
setting the multi_core_allow_overthreading variable to false guarantees the process
cores utilization never exceeds the user maximum cores limit. This would result in
reduced multicore analysis performance.

It is important to note that modifying this variable only impacts algorithms invoked
within Tcl commands launched subsequent to the variable setting.

To determine the current value of this variable, type the following:

printvar multi_core_ allow_overthreading

SEE ALSO
set_host_options(2)

multi_core_allow_overthreading
97
multi_core_skip_unsupported
Enables or disables skipping of unsupported commands and variables in the
distributed multicore analysis flow.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

This variable controls how unsupported commands and variables are handled by
PrimeTime in the distributed multicore analysis flow.

By default, this variable is set to true and all commands that are unsupported in
multicore analysis are skipped, a warning is issued, and the analysis continues.

Upon exiting the session, PrimeTime produces a summary of commands and variables
that were skipped along with the location of a data file containing further
information. The data file is located in the multicore analysis working directory,
which you specified using the multi_core_working_directory variable.

To execute an unsupported command or use an unsupported variable, set the

multi_core_skip_unsupported variable to false. If the multi_core_skip_unsupported
variable is set to false and an unsupported command or variable is encountered,
PrimeTime displays a warning message and automatically switches out of distributed
multicore. The master completes the timing update and all subsequent analysis is
performed at the master.

You can alter the setting of this variable at any stage in the multicore analysis
flow.

To determine the current value of this variable, type one of the following:

printvar multi_core_skip_unsupported

echo $multi_core_skip_unsupported

UNSUPPORTED COMMANDS AND VARIABLES

The following commands and variables are unsupported in multicore analysis and are
automatically skipped if the multi_core_skip_unsupported variable is set to its
default of true:

• PrimeTime VX commands

multi_core_skip_unsupported
98
• PrimeTime PX commands

• Modeling commands (ETM, ILM, QTM)

• Context commands

• GUI commands

• write_spice_deck related commands

• write_sdf_constraints

• transform_exceptions

• write_parasitics

• timing_crpr_enable_adaptive_engine

The write_sdf command is unsupported in multicore analysis when the advanced on-chip
variation (AOCV) mode is active.

SEE ALSO
echo(2)
remove_host_options(2)
set_host_options(2)
start_hosts(2)
stop_hosts(2)
multi_core_working_directory(3)

multi_core_skip_unsupported
99
multi_core_use_32bit_slaves
Enables or disables automatic launching of 32-Bit slaves.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When this variable is set to its default of true, the master calculates a value at
the start of the update_timing command to predict the maximum slave memory. If the
predicted maximum slave memory is small enough to fit inside a 32-Bit memory space,
the master issues the MC-108 informational message and automatically launches all
slaves with a 32-Bit executable. This leads to a significant drop in the memory used
by the slaves.

To determine the current value of this variable, type the following:

printvar multi_core_use_32bit_slaves

SEE ALSO
remove_host_options(2)
remove_hosts(2)
report_host_options(2)
set_host_options(2)
start_hosts(2)
stop_hosts(2)

multi_core_use_32bit_slaves
100
multi_core_working_directory
Defines the root working directory for all multicore analysis data, including remote
process log files.

TYPE

string

DEFAULT

(current working directory)

DESCRIPTION

In multicore analysis, the working directory can be explicitly specified using the
multi_core_working_directory variable. This defines the root working directory for
all multicore analysis data, including log files. You must have write-accessible and
network accessible for the specified directory and all PrimeTime processes. This
value of this variable cannot be modified once the remote hosts have been launched.
If no value is specified for the multi_core_working_directory variable, the working
directory defaults to the directory from which the analysis was invoked.

To determine the current value of this variable, type one of the following:

printvar multi_core_working_directory

echo $multi_core_working_directory

SEE ALSO
remove_host_options(2)
set_host_options(2)
start_hosts(2)
stop_hosts(2)

multi_core_working_directory
101
multi_scenario_fault_handling
Controls how fatal errors are handled in remote processes.

TYPE

string

DEFAULT

ignore

DESCRIPTION

Controls how fatal errors are handled in remote processes. Allowed values are exit
and ignore (the default).

• When you set this variable to exit, if the master detects fatal errors in the
remote processes, it shuts down the entire analysis after all the executing tasks
have been processed. Before exiting, the master reports which scenarios have caused
a fatal error.

• When this variable is set to its default of ignore, if the master detects fatal
errors in the remote processes, it removes the scenarios that caused a fatal error
from the current session when all the executing tasks have been processed. It then
re-runs the command encountering the fatal error on the remaining scenarios in
command focus. It repeats this process until the command either succeeds or the
command focus is depleted of all scenarios. If there are no scenarios left in
command focus, the command does not run again. If all the scenarios in the session
are removed, the session is removed. If the resources required to sustain a session
are no longer available, the current session is removed. For the resource
requirements needed to sustain a session, see the current_session man page.

To determine the current value of this variable, type the following:

printvar multi_scenario_fault_handling

SEE ALSO
current_scenario(2)
current_session(2)

multi_scenario_fault_handling
102
multi_scenario_merged_error_limit
Defines the maximum number of errors or warnings of a particular type to be
considered for merging in the merged error log on a per task basis.

TYPE

int

DEFAULT

100

DESCRIPTION

In multi-scenario analysis, errors, warnings, and informational messages are

produced by both the master and slave processes. For the data produced by the
slaves, full (compressed) error, warning, and informational messages are stored in
the file specified by the multi_scenario_merged_error_log variable. To avoid
excessive memory usage and network traffic, the number of errors on a per type basis
is limited to the number set using the multi_scenario_merged_error_limit variable.
For example, if the multi_scenario_merged_error_limit variable is set to 10, a
maximum of 10 errors of type CMD-003 is written to the log specified using the
multi_scenario_merged_error_log variable. The default value of the
multi_scenario_merged_error_limit variable is 100.

To determine the current value of this variable, type

printvar multi_scenario_merged_error_limit

SEE ALSO
multi_scenario_merged_error_log(3)

multi_scenario_merged_error_limit
103
multi_scenario_merged_error_log
Use to specify a file location where full (compressed) error, warning, and
informational messages are stored for data produced by the slaves.

TYPE

string

DESCRIPTION

In multi-scenario analysis, errors, warnings, and informational messages are

produced by both the master and slave processes. For the data produced by the
slaves, full (compressed) error, warning, and informational messages are stored in
the file specified by the multi_scenario_merged_error_log variable. All errors,
warnings, and informational messages are displayed as in regular PrimeTime, with the
addition of the name of the scenario where the message occurred. If all scenarios
produce the same message, only one message is stored with all used instead of
listing all scenario names. This describes the term compressed used above. Along
with the multi-scenario merged error log, slave errors are displayed in full at the
master while slave warnings are summarized at the master (slave informational
messages are not displayed at the master). At each slave, the errors and warnings
are written in full to the slave log file.

To determine the current value of this variable, type one of the following:

printvar multi_scenario_merged_error_log

echo $multi_scenario_merged_error_log.

SEE ALSO
multi_scenario_merged_error_limit(3)

multi_scenario_merged_error_log
104
multi_scenario_message_verbosity_level
Define the verbosity level of messages printed at the master during slave
processing.

TYPE

string

DEFAULT

default

DESCRIPTION

During slave processing, the master reports back several different types of
messages. You can use the multi_scenario_message_verbosity_level variable to control
the types of messages reported at the master. The variable can take two values, low
or default. If the variable is set to low, the master prints out the following
messages:

errors, fatal, and task failure

If the variable is the default, the master prints out the following messages:

licensing, errors, warnings, fatal, task status, and task failure

To determine the current value of this variable, type the following:

printvar multi_scenario_message_verbosity_level

SEE ALSO
multi_scenario_merged_error_log(3)

multi_scenario_message_verbosity_level
105
multi_scenario_working_directory
Defines the root working directory for all multi-scenario analysis data, including
log files.

TYPE

string

DEFAULT

(current working directory)

DESCRIPTION

In multi-scenario analysis, the working directory can be explicitly specified using

the multi_scenario_working_directory variable. This defines the root working
directory for all multi-scenario analysis data, including log files. The working
directory must be visible to the master and all the slaves. You must have write
permissions in the specified directory. If no value is specified for the
multi_scenario_working_directory variable, the working directory defaults to the
directory from which the analysis was invoked.

To determine the current value of this variable, type one of the following commands:

printvar multi_scenario_working_directory

echo $multi_scenario_working_directory

SEE ALSO
multi_scenario_working_directory(3)

multi_scenario_working_directory
106
mv_input_enforce_simple_names
Enforces usage of simple names for restricted commands as per the IEEE 1801 (UPF)
standard.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable controls whether or not hierarchical names are accepted when you
specify an argument that requires simple names, as per the IEEE 1801 standard.

The default value of this variable is FALSE. So, by default, the tool accepts
hierarchical names even if the IEEE 1801 (UPF) standard requires them to be simple.

When you set this variable to TRUE, the restricted command causes the tool to error
out, when you use hierarchical names. Note, this variable does not affect command
create_supply_net and create_supply_set, which always require simple names.

SEE ALSO
connect_supply_net(2),
create_power_domain(2),
create_power_switch(2),
create_supply_port(2).

mv_input_enforce_simple_names
107
mw_design_library
This variable stores the name of the design library for the read_milkyway command.

TYPE

string

DEFAULT

"" (empty)

GROUP

milkyway variables

DESCRIPTION

This variable has the name of the design library for the read_milkyway command. If
the read_milkyway command is issued without the design library name on the command
line, the command reads this variable to get the name. If the read_milkyway command
is issued with the design library name, this variable is set to that name.

To determine the current value of this variable, type one of the following:

printvar mw_design_library

echo $mw_design_library.in -0.25in

SEE ALSO
read_milkyway(2)

mw_design_library
108
mw_logic0_net
This variable controls the name of constant zero net for the read_milkyway command.

TYPE

string

DEFAULT

VSS

GROUP

milkyway variables

DESCRIPTION

This variable determines the name of the net is the logic low net for the
read_milkyway command. When the read_milkyway command is reading a design and sees a
net by this name it treats it as if it were tied to logic 0.

To determine the current value of this variable, type one of the following:

printvar mw_logic0_net

echo $mw_logic0_net

SEE ALSO
read_milkyway(2)
mw_logic1_net(3)

mw_logic0_net
109
mw_logic1_net
This variable controls the name of the constant one net for the read_milkyway
command.

TYPE

string

DEFAULT

VDD

GROUP

milkyway variables

DESCRIPTION

This variable determines the name of the net is the logic high net for the
read_milkyway command. When the read_milkyway command is reading a design and sees a
net by this name it treats it as if it were tied to logic 1.

To determine the current value of this variable, type one of the following:

printvar mw_logic1_net

echo $mw_logic1_net

SEE ALSO
read_milkyway(2)
mw_logic0_net(3)

mw_logic1_net
110
parasitic_variation_default_type
Specifies the type of default distribution used for parasitic variation parameters
in PrimeTime VX.

TYPE

string

DEFAULT

normal

DESCRIPTION

Specifies the default distribution of parasitic variation parameters for statistical

static timing analysis of the design. This variable is applicable only when
variation aware parasitics are read using the read_parasitics -keep_variations -
create_default command.

The valid options are normal (the default), uniform, and discrete.

When set to normal, a Gaussian distribution is created for the parasitic variation
parameters. When set to uniform, a uniform distribution from mean-abs(3*sigma) to
mean+abs(3*sigma) is created. When set to discrete, a 2-value distribution for the
parasitic variation parameters is created. The two values used are mean+abs(3*sigma)
and mean-abs(3*sigma), each with equal probability of 0.5. The distribution used for
the parameters can be seen using the report_variation command.

To determine the current value of this variable, type printvar

parasitic_variation_default_type or echo $parasitic_variation_default_type.

SEE ALSO
read_parasitics(2)
report_variation(2)

parasitic_variation_default_type
111
parasitics_cap_warning_threshold
Specifies a capacitance threshold beyond which a warning message is issued during
the reading of a parasitics file.

TYPE

float

DEFAULT

0.0

DESCRIPTION

When this variable is set with a value greater than 0.0, the read_parasitics command
issues a PARA-014 warning if it finds in the parasitics file a capacitance value, in
picofarads, greater than this threshold. The default is 0.0, in which case no
checking is done. Use this variable to detect large, unexpected capacitance values
written to parasitics files by other applications. The capacitor is still used, but
you can quickly find it in the parasitics file.

You can define an analogous resistance threshold by using the

parasitics_res_warning_threshold variable.

To determine the current value of this variable, type one of the following commands:

printvar parasitics_cap_warning_threshold

echo $parasitics_cap_warning_threshold

SEE ALSO
read_parasitics(2)
parasitics_res_warning_threshold(3)
PARA-014(n)

parasitics_cap_warning_threshold
112
parasitics_log_file
Determines where the output of parasitic commands should go when run in the
background process.

TYPE

string

DEFAULT

parasitics_command.log

DESCRIPTION

PrimeTime might launch a side process to perform parasitic operations in parallel

with portions of the main run. This variable determines where the output data of the
side process should go. By default, it goes to a file named parasitics_command.log
in the current working directory. This variable can be used to modify the filename.

To determine the current value of this variable, type printvar parasitics_log_file

SEE ALSO

read_parasitics (2)

parasitics_log_file
113
parasitics_rejection_net_size
Defines a threshold number of nodes in an annotated parasitic network beyond which
the detailed network is automatically replaced by a lumped capacitance.

TYPE

int

DEFAULT

20000

DESCRIPTION

Defines a threshold number of nodes in an annotated parasitic network beyond which

the detailed network is automatically replaced by a lumped capacitance. The default
is 20000.

This variable is one of a pair of variables, parasitics_warning_net_size and

parasitics_rejection_net_size, that help you prevent unacceptable or unexpected run
times caused by large numbers of nodes in an annotated parasitic network. If the
read_parasitics command finds a number of nodes that exceeds the value of the
parasitics_warning_net_size variable (default 10000), you receive a PARA-003 message
warning you that extended run time could occur. If the read_parasitics command finds
a number of nodes that exceeds the value of the parasitics_rejection_net_size
variable (default 20000), the network is rejected and automatically replaced by a
lumped capacitance, and you receive a PARA-004 message warning.

The value of the parasitics_warning_net_size variable is ignored if it is greater

than or equal to the value of the parasitics_rejection_net_size variable.

To determine the current value of this variable, enter the following command:

pt_shell> printvar parasitics_rejection_net_size

SEE ALSO
read_parasitics(2)
parasitics_warning_net_size(3)

parasitics_rejection_net_size
114
parasitics_res_warning_threshold
Specifies a resistance threshold beyond which a warning message is issued during the
reading of a parasitics file.

TYPE

float

DEFAULT

0.0

DESCRIPTION

When this variable is set with a value greater than 0.0, the read_parasitics command
issues a PARA-014 warning if it finds in the parasitics file a resistance value, in
ohms, greater than this threshold. The default is 0.0, in which case no checking is
done. Use this variable to detect large, unexpected resistance values written to
parasitics files by other applications. The resistor is still used, but you can
quickly find it in the parasitics file.

You can define an analogous capacitance threshold by using the

parasitics_cap_warning_threshold variable.

To determine the current value of this variable, type one of the following commands:

printvar parasitics_res_warning_threshold

echo $parasitics_res_warning_threshold.

SEE ALSO
read_parasitics(2)
parasitics_cap_warning_threshold(3)
PARA-014(n)

parasitics_res_warning_threshold
115
parasitics_warning_net_size
Defines a threshold number of nodes in an annotated parasitic network beyond which a
message is issued that warns of a potential extended run time.

TYPE

int

DEFAULT

10000

DESCRIPTION

Defines a threshold number of nodes in an annotated parasitic network beyond which a

message is issued that warns of a potential extended run time. The default is 10000.

This variable is one of a pair of variables, parasitics_warning_net_size and

parasitics_rejection_net_size, that help you prevent unacceptable or unexpected run
times caused by large numbers of nodes in an annotated parasitic network. If the
read_parasitics command finds a number of nodes that exceeds the value of the
parasitics_warning_net_size variable (default 10000), you receive a PARA-003 message
warning you that extended run time could occur. If the read_parasitics command finds
a number of nodes that exceeds the value of the parasitics_rejection_net_size
variable (default 20000), the network is rejected and automatically replaced by a
lumped capacitance. You receive a PARA-004 message warning you of that action.

The value of the parasitics_warning_net_size variable is ignored if it is greater

than or equal to the value of the parasitics_rejection_net_size variable.

To determine the current value of this variable, enter the following command:

pt_shell> printvar parasitics_warning_net_size

SEE ALSO
read_parasitics(2)
parasitics_rejection_net_size(3)

parasitics_warning_net_size
116
pba_aocvm_only_mode
Specifies that only advanced on-chip variation (advanced OCV) is performed during
path-based analysis.

TYPE

Boolean

DEFAULT

false

GROUP

timing_variables

DESCRIPTION

This variable applies to the path-based analysis performed during the

get_timing_paths and report_timing commands when the -pba_mode option is specified.
This option controls whether or not regular path-based analysis (path-specific slew
propagation) effects are performed during a path-based analysis in addition to
advanced OCV path-based analysis.

When the variable is set to its default of false, PrimeTime performs both regular
path-based analysis and advanced OCV path-based analysis during a path-based
analysis. This option removes the maximum amount of pessimism from the design, but
the runtime can be large.

When the variable is set to true, PrimeTime only performs advanced OCV path-based
analysis during a path-based analysis. This option is recommended for fastest
runtime in an advanced OCV flow.

Note that advanced OCV path-based analysis is applied only if user-specified

advanced OCV information exists.

To determine the current value of this variable, enter the following command:

pt_shell> printvar pba_aocvm_only_mode

SEE ALSO
get_timing_paths(2)
read_aocvm(2)
report_timing(2)

pba_aocvm_only_mode
117
pba_derate_list
Specifies path-based derate factors.

TYPE

string

DEFAULT

""

GROUP

timing_variables

DESCRIPTION

This variable specifies a list of set_timing_derate commands. Each set_timing_derate

command specifies a derating factor applicable only during path-based analysis and
does not impact regular graph-based timing analysis during the update_timing
command. During path-based analysis, path-based derate factors have higher
precedence over graph-based derate factors.

The pba_derate_list variable is only effective when the -pba_mode option of the
get_timing_paths or report_timing command is set to path.

Note: The -pba_mode option cannot be specified in an advanced on-chip variation

(OCV) flow.

In the following example the pba_derate_list variable is used to define a late path-
based derate factor for cell ’buf0’. It is important to reset the pba_derate_list
variable after the path-based analysis so that subsequent path reports are not
affected.

pt_shell> set pba_derate_list "set_timing_derate -late 1.12 buf0"

pt_shell> report_timing -pba_mode path $PATH
pt_shell> set pba_derate_list ""

This next example for the get_timing_paths command is quite similar.

pt_shell> set pba_derate_list "set_timing_derate -late 1.12 buf0"

pt_shell> get_timing_paths -pba_mode path -to FF4/D
pt_shell> set pba_derate_list ""

pba_derate_list
118
To determine the current value of this variable, enter the following command:

pt_shell> printvar pba_derate_list

SEE ALSO
get_timing_paths(2)
report_timing(2)
set_timing_derate(2)

pba_derate_list
119
pba_enable_path_based_physical_exclusivity
This variable controls whether a path-based or stage-based physical exclusivity
crosstalk computation is used during path-based analysis of paths involving
physically exclusive clocks.

TYPE

int

DEFAULT

false

DESCRIPTION

When set to false (the default), each delay calculation stage is evaluated
independently of the other stages in the path. For instance, consider two clocks
which are physically exclusive, CLK1 and CLK2. For one stage in the path, an
aggressor clocked by CLK1 might result in the worst delta delay. For the next stage,
an aggressor clocked by CLK2 might result in the worst delta delay. In a stage-based
approach, these deltas are both used for the corresponding stages in the path. This
approach is runtime efficient, but can possibly result in some pessimism.

When set to true, the path is recalculated multiple times to consider each possible
victim and aggressor combination across the physically exclusive clocks. In this
case, aggressors from CLK1 and CLK2 could not simultaneously attack different stages
across the path. This removes the pessimism of the stage-based approach, but at the
cost of additional runtime. The recommendation is to leave the default value of
false for most analysis, but to set it to true for the final signoff run if
additional pessimism removal is desired during path-based analysis.

To determine the current value of this variable, type one of the following commands:

printvar pba_enable_path_based_physical_exclusivity
echo $pba_enable_path_based_physical_exclusivity

SEE ALSO
report_timing(2)
get_timing_paths(2)

pba_enable_path_based_physical_exclusivity
120
pba_enable_xtalk_delay_ocv_pessimism_reduction
During the path-based analysis, reduces the pessimism due to clock on-chip variation
(OCV) on xtalk delay analysis.

TYPE

int

DEFAULT

false

DESCRIPTION

When this is set to true (the default is false), during the path-based crosstalk
delay analysis, PrimeTime SI reduces the pessimism due to the impact of clock on-
chip-variation (OCV) on the victim and aggressor arrivals. This process is
computationally intensive and should be used only when the clock path is long and
the on-chip variation is large. Clock reconvergence pessimism removal (CRPR) must be
enabled (by setting the timing_remove_clock_reconvergence_pessimism command to true)
to use this feature.

To determine the current value of this variable, type one of the following commands:

printvar pba_enable_xtalk_delay_ocv_pessimism_reduction

echo $pba_enable_xtalk_delay_ocv_pessimism_reduction

SEE ALSO
report_timing(2)
get_timing_paths(2)
timing_remove_clock_reconvergence_pessimism(3)

pba_enable_xtalk_delay_ocv_pessimism_reduction
121
pba_exhaustive_endpoint_path_limit
Defines a limit for exhaustive path-based analysis.

TYPE

int (Range: 1 to 2000000)

DEFAULT

25000

GROUP

timing_variables

DESCRIPTION

This variable applies to the exhaustive path-based analysis performed during the
get_timing_paths or report_timing command when the -pba_mode exhaustive option is
specified. This exhaustive analysis is computationally intensive, and it is intended
to be used only when the design is approaching signoff.

In certain badly-behaved designs the exhaustive analysis can run for a long time.
This variable restricts the exhaustive path search so that the number of paths
recalculated at any endpoint is limited. You can adjust this limit; however,
increasing the value to a larger number increases the runtime of the analysis.

When the pba_path_recalculation_limit_compatibility variable is set to false, graph-

based analysis paths are included in the results from exhaustive path-based analysis
mode after the endpoint path limit is reached.

There are several other measures that improve the runtime of the analysis.

• Uniquify path through parallel arcs

• Use conservative values for the -nworst and -max_paths options

• Set a realistic threshold for the -slack_lesser_than option

When an advanced on-chip variation (OCV) analysis is being performed, there are
several additional variable settings that improve the runtime of the analysis.

• Enable CRPR

• Enable graph-based advanced OCV

pba_exhaustive_endpoint_path_limit
122
• Enable path-based advanced OCV only mode

To determine the current value of this variable, enter the following command:

pt_shell> printvar pba_exhaustive_endpoint_path_limit

SEE ALSO
get_timing_paths(2)
report_timing(2)
pba_aocvm_only_mode(3)
timing_aocvm_enable_analysis(3)
timing_remove_clock_reconvergence_pessimism(3)
timing_report_use_worst_parallel_cell_arc(3)

pba_exhaustive_endpoint_path_limit
123
pba_path_recalculation_limit_compatibility
Controls whether graph-based analysis paths are included in results from path-based
analysis recalculation when the path recalculation limit is reached.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When set to its default of true, PrimeTime only returns path-based analysis paths
from the get_timing_paths command when the -pba_mode option is not set to none.
Also, when this variable is true, the report_timing command with the -pba_mode
option set to anything other than none reports only recalculated paths. This
behavior is similar to the behavior in PrimeTime version D-2009.12.

When set to false, PrimeTime can report both recalculated and non-recalculated
paths.

For the -pba_mode exhaustive option, the per-endpoint limit can be controlled using
the pba_exhaustive_endpoint_path_limit variable.

To determine the current value of this variable, type the following command:

printvar pba_path_recalculation_limit_compatibility

SEE ALSO
get_timing_paths(2)
report_timing(2)
pba_exhaustive_endpoint_path_limit(3)

pba_path_recalculation_limit_compatibility
124
pba_recalculate_full_path
Allow regular path-based analysis to recalculate full clock paths and borrowing path
segments.

TYPE

int

DEFAULT

false

DESCRIPTION

When this variable is set to true, PrimeTime allows all path-based analysis commands
(report_timing and get_timing_paths) to recalculate full clock paths and borrowing
paths in addition to the data paths.

When this variable is set to its default of false, PrimeTime blocks recalculation of
clock paths and borrowing path portions and the original timing is retained. This
allows paths obtained with the -path full_clock, -path full_clock_expanded, and -
trace_latch_borrow options to be fully reported, while avoiding recalculation on the
borrowing and clock portions of the path. The reason this may be desirable is that
with certain circuit topologies, a conservative path-based recalculation of the
clock or borrowing path may not be guaranteed. This can happen when there are
multiple clock or borrowing paths which can apply to the path. Only the worst pre-
recalculation clock or borrowing path is included for recalculation. This may not be
the worst path after recalculation.

In advanced on-chip variation (OCV) mode, the depth and distance metrics are always
recomputed by path recalculation regardless of the value of this variable. In
advanced OCV mode, this variable only has an effect when path slew recomputation is
enabled when the pba_aocvm_only_mode variable is set to its default of false. When
this variable is set to true, path-specific delay calculation is performed along the
clock and data paths. When this variable is set to false, path-specific delay
calculation is only performed along the data path.

To determine the current value of this variable, type

printvar pba_recalculate_full_path

SEE ALSO
report_timing(2)
get_timing_paths(2)

pba_recalculate_full_path
125
port_search_in_current_instance
Controls whether the get_ports command can get ports of the current instance.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, the get_ports command gets ports of the current instance; when set
to false (the default), the command gets ports of the current design.

To determine the current value of this variable, type one of the following:

printvar port_search_in_current_instance
echo $port_search_in_current_instance

SEE ALSO
get_ports(2)

port_search_in_current_instance
126
power_analysis_mode
Sets the power analysis mode.

TYPE

string

DEFAULT

averaged

GROUP

power_variables

DESCRIPTION

Explicitly selects the analysis mode for power calculation. PrimeTime PX provides
three different analysis modes: averaged, time_based, and leakage_variation. Set
this variable before the first power command, otherwise, the default mode is
assumed. For a particular analysis mode, you must provide the appropriate activity
information. The allowed values are as follows:

* averaged (the default): PrimeTime PX calculates power based on toggle-rate and

state-probability. Only averaged power results are calculated. In this mode, it can
take the VCD file and SAIF file as activity input files. Use the
set_switching_activity and set_case_analysis commands to set the statistical
switching activity on top of the default switching activity. For more information,
see the update_power man page.

* time_based: PrimeTime PX calculates power based on the events from VCD. Averaged
power results are calculated, along with calculations for peak powers and time_based
power waveforms. You must provide the VCD file in this mode. Both gate-level VCD and
RTL VCD can be specified for this mode. For more information, see the update_power
man page.

* leakage_variation: PrimeTime PX performs leakage variation analysis. For more

information, see the power_enable_leakage_variation_analysis man page.

The power_analysis_options variable can change in one run. However once changed, all
the activity and power data is removed internally. You must provide activity
information before the update_power command.

In addition, you can use the set_power_analysis_options to specify the options for
power analysis.

SEE ALSO
power_enable_analysis(3)
update_power (2)

power_analysis_mode
127
set_power_analysis_options(2)
report_power(2)
read_vcd(2)
read_saif(2)
set_switching_activity(2)
set_case_analysis(2)
power_enable_leakage_variation_analysis(3)
printvar(2)

power_analysis_mode
128
power_calc_use_ceff_for_internal_power
Specifies whether to use effective C for internal power calculation.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

This variable controls whether to use effective capacitance in the sense of timing
as the output net capacitance parameter when looking up internal power tables during
the power calculation stage. If the variable is true, use effective capacitance;
otherwise use the total net capacitance.

To determine the current value of this variable, type one of the following commands:

printvar power_calc_use_ceff_for_internal_power

echo $power_calc_use_ceff_for_internal_power

power_calc_use_ceff_for_internal_power
129
power_check_defaults
Defines the default checks for the check_power command.

TYPE

list

DEFAULT

out_of_table_range missing_table missing_function

DESCRIPTION

Defines the default checks performed when the check_power command is executed
without any options. The same default checks are also performed if the check_power
command is used with the -include or -exclude options. The default check list
defined by this variable can be overridden by either redefining it before the
check_power command is executed or using the -override_defaults option of the
check_power command.

If an undefined check is specified while redefining this variable, a warning is

issued by the next execution of the check_power command.

SEE ALSO
check_power(2)

power_check_defaults
130
power_clock_network_include_clock_gating_network
Indicates that clock gating networks are included in the clock network.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable affects the predefined clock_network and register power groups. When
the variable is set to true, discrete logic structure that functions as clock gating
belongs to the clock_network power group. Only the typical clock gating logic is
considered a qualified clock gating network included in the clock network. The
typical clock gating logic starts from the output of a level-sensitive latch driven
by the specified clock. The clock gating logic possibly goes through some buffers,
and returns to the specified clock network through one of the input pins of an AND
or OR gate. The input pin must be a PrimeTime clock check enabled pin, either
inferred or manually set. Therefore, the results can be affected by clock gating
check related commands or variables. When the clock gating network is included in
the clock network, the latch is regarded as part of the clock_network power group,
but not the register power group.

To determine the current value of this variable, type one of the following commands:

printvar power_clock_network_include_clock_gating_network
echo $power_clock_network_include_clock_gating_network

SEE ALSO
report_power(2)
create_power_group(2)

power_clock_network_include_clock_gating_network
131
power_clock_network_include_register_clock_pin_power
Indicates whether the register clock pin power is included when reporting
clock_network power.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

This variable affects the power report for the predefined clock_network and register
power groups. When set to its default of true, the internal power of registers
caused by the toggling of register clock pin when output pin does not toggle is
included as clock_network power and excluded from register power. When set to false,
the power is included as register power and excluded from clock_network power.

To determine the current value of this variable, type one of the following commands:

printvar power_clock_network_include_register_clock_pin_power

echo $power_clock_network_include_register_clock_pin_power

SEE ALSO
report_power(2)
create_power_group(2)

power_clock_network_include_register_clock_pin_power
132
power_default_static_probability
Specifies the default static probability value.

TYPE

Float

DEFAULT

0.5

DESCRIPTION

The power_default_static_probability variable (along with the

power_default_toggle_rate and power_default_toggle_rate_reference_clock variables)
is used to determine the switching activity of unannotated nets that are driven by
primary inputs or black box cells. The power_default_toggle_rate variable is used to
specify the default toggle rate value and the
power_default_toggle_rate_reference_clock variable is used to specify how the
related clock for default toggle rate is determined.

For other unannotated nets, PrimeTime PX propagates the switching activities of the
driving cell inputs based on the cell functionality to derive the switching activity
required for power calculations. This mechanism cannot be used for primary inputs
and black box outputs. Instead, the following values are used for these type of
nets:

- Annotated values are used.

- In some cases, unannotated switching activity values can still be accurately

derived. For example, if the net drives a buffer cell and the output of this cell is
annotated, your annotated values are used as the default values. Also, if the input
is a clock the clock period and waveform are used to derive the switching activity
values.

- If the static probability is not annotated, the value of the

power_default_static_probability variable is used for the static probability value.

- If the toggle rate is not annotated by you, whether the static probability is set
or not, the following is used for the toggle rate value:

dtr * fclk

where fclk is the frequency of the related clock, and the dtr is the value of the
power_default_toggle_rate variable.

The related clock is determined by the value of the

power_default_toggle_rate_reference_clock variable. Two values (fastest and related)
are allowed for the power_default_toggle_rate_reference_clock variable. If the
fastest value is specified, the related clock is the fastest clock in the design. If
the related value is given, the related clock would depend on which clock domain the

power_default_static_probability
133
net belongs to.

The value of the power_default_static_probability variable should be between 0.0 and

1.0, both inclusive. The value of the power_default_toggle_rate should be greater or
equal to 0.0. Also, if the value of the power_default_static_probability variable is
0.0 or 1.0, the value of the power_default_toggle_rate variable should be 0.0. If
the value of the power_default_toggle_rate variable is 0.0, the value of the
power_default_static_probability should be either 0.0 or 1.0.

The default value of both variables is 0.5.

SEE ALSO
power_default_toggle_rate(3)
power_default_toggle_rate_reference_clock(3)
set_switching_activity(2)

power_default_static_probability
134
power_default_toggle_rate
Specifies the default toggle rate value.

TYPE

Float

DEFAULT

0.1

DESCRIPTION

The power_default_toggle variable and the power_default_toggle_rate_reference_clock

and power_default_static_probability variables are used to determine the switching
activity of non-user annotated nets that are driven by primary inputs or black-box
cells.

For other unannoated nets, PrimeTime PX will propagate the switching activities of
the driving cell inputs based on the cell functionality to derive the switching
activity required for power calculations. This mechanism cannot be used for primary
inputs and black-box outputs. Instead the following values are used for these type
of nets:

- User annotated values are used.

- In some cases, unannotated switching activity values may still be accurately

derived, for example, if the net drives a buffer cell and the output of this cell is
user annotated, then the user annotated values are used as the default values. Also,
if the input is a clock then the clock period and waveform are used to derive the
switching activity values.

- If the static probability is not annotated then the value of the

power_default_static_probability variable is used for the static probability value.

- If the toggle rate is not user annotated, no mater the static probability is set
or not, the following is used for the toggle rate value:

dtr * fclk

where fclk is the frequency of the related clock, and dtr is the value of the
power_default_toggle_rate variable.

The related clock is determined by the value of

power_default_toggle_rate_reference_clock. Two values (fastest, related) are allowed
for the value of power_default_toggle_rate_reference_clock variable. If the value
fastest is specified, the related clock would be simply the fastest clock in the
design. If the value related is given, the related clock would depend on which clock
domain the net belongs to.

The value of power_default_static_probability should be between 0.0 and 1.0, both

power_default_toggle_rate
135
inclusive. The value of power_default_toggle_rate should be greater or equal to 0.0.
Also, if the value of power_default_static_probability is 0.0 or 1.0, then the value
of power_default_toggle_rate should be 0.0. If the value of
power_default_toggle_rate is 0.0, then the value of power_default_static_probability
should be either 0.0 or 1.0.

The default value of power_default_static_probability is 0.5 and the default value

of power_default_toggle_rate is 0.1.

SEE ALSO

power_default_toggle_rate_reference_clock (3), power_default_static_probability (3),

set_switching_activity (2),

power_default_toggle_rate
136
power_default_toggle_rate_reference_clock
Specifies how the related clock for default toggle rate is determined.

TYPE
string power_default_toggle_rate_reference_clock

DEFAULT

related

DESCRIPTION

The power_default_toggle_rate_reference_clock variable and the

power_default_toggle_rate and power_default_static_probability variables are used to
determine the switching activity of non-user annotated nets that are driven by
primary inputs or black-box cells. The power_default_toggle_rate is used to specify
the default toggle rate value and the power_default_toggle_rate_reference_clock
variable is used to specify how the related clock for default toggle rate is
determined.

For other unannotated nets, PrimeTime PX propagates the switching activities of the
driving cell inputs based on the cell functionality to derive the switching activity
required for power calculations. This mechanism cannot be used for primary inputs
and black-box outputs. Instead the following values are used for these type of nets:

- User annotated values are used.

- In some cases, unannotated switching activity values may still be accurately

derived, for example, if the net drives a buffer cell and the output of this cell is
user annotated, then the user annotated values are used as the default values. Also,
if the input is a clock then the clock period and waveform are used to derive the
switching activity values.

- If the static probability is not annotated then the value of the

power_default_static_probability variable is used for the static probability value.

- If the toggle rate is not user annotated, the following is used for the toggle
rate value regardless of whether the static probability is set or not:

dtr * fclk

where fclk is the frequency of the related clock, and the dtr is the value of the
power_default_toggle_rate variable.

The related clock is determined by the value of

power_default_toggle_rate_reference_clock. Two values (fastest, related) are allowed
for the value of power_default_toggle_rate_reference_clock variable. If the value
fastest is specified, the related clock would be simply the fastest clock in the
design. If the value related is given, the related clock would depend on which clock
domain the net belongs to.

power_default_toggle_rate_reference_clock
137
The value of power_default_static_probability should be between 0.0 and 1.0, both
inclusive. The value of power_default_toggle_rate should be greater or equal to 0.0.
Also, if the value of power_default_static_probability is 0.0 or 1.0, then the value
of power_default_toggle_rate should be 0.0. If the value of
power_default_toggle_rate is 0.0, then the value of power_default_static_probability
should be either 0.0 or 1.0.

The default value of both variables is 0.5.

SEE ALSO

power_default_static_probability (3), power_default_toggle_rate (3),

set_switching_activity (2).

power_default_toggle_rate_reference_clock
138
power_domains_compatibility
Indicates whether to revert to power domains mode and disable UPF mode.

TYPE

fIBooleanfP

DEFAULT

false

DESCRIPTION

Indicates whether to revert to power domains mode and disable UPF mode. Power
domains are the previous (PrimeTime version Z-2007.06) method of specifying virtual
power network and power intent. Starting with version A-2007.12, PrimeTime will be
in UPF mode by default and all power domain commands will be unavailable.

When you set this variable to TRUE, - All UPF commands are disabled - Power domain
commands are enabled - All designs and their annotations are removed from memory.

This variable is equivalent to the Design Compiler shell startup option -upf_mode.

To determine the current value of this variable, type printvar

power_domains_compatibility or echo $power_domains_compatibility.

Please note, this variable should not be changed after library loading, or user must
re-load the libraries. The reason is that the tool performs library PG conversion
and update in UPF mode but not in power domains mode. For more information, check
out the man page for variable library_pg_file_pattern.

SEE ALSO

To list commands available in UPF mode, use help upf To list commands available in
power domains mode, use help "power domains"

power_domains_compatibility
139
power_enable_analysis
Enables or disables PrimeTime PX, which provides power analysis.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

When set to true, enables PrimeTime PX, so that you can perform power analysis.
Without this variable set to true, you cannot see power related data. By default,
PrimeTime PX is disabled; this variable is set to false.

If you set this variable to true and enable PrimeTime PX, you must obtain a
PrimeTime PX license. You cannot use PrimeTime PX without a license.

For the current value of this variable, type the following command:

printvar power_enable_analysis

SEE ALSO
printvar(2)

power_enable_analysis
140
power_enable_clock_scaling
Enables or disables clock scaling for power analysis in PrimeTime PX.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

When set to true, this variable enables PrimeTime PX to scale average power number
according to clock frequencies specified in SDC and the set_power_clock_scaling
command.

For the current value of this variable, type the following command:

printvar power_enable_clock_scaling

SEE ALSO
set_power_clock_scaling(2)
printvar(2)

power_enable_clock_scaling
141
power_enable_leakage_variation_analysis
Enables or disables the leakage variation feature in PrimeTime PX.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

When set to true, enables the leakage variation feature in PrimeTime PX. Without
this variable set to true, you cannot compute or report leakage variation
information.

In order to successfully use the leakage variation feature, the following variables
must also be set to true:

power_enable_analysis variation_enable_analysis

In order to successfully use the leakage variation feature, libraries containing

leakage variation information must be used. See the set_variation_library command.

Also, variation commands must be issued to describe the variation of the parameters.
See the create_distribution, set_variation, set_variation_correlation commands for
more information.

To use the leakage variation feature, you must have a PrimeTime PX license, as well
as a PrimeTime VX license. The PrimeTime New Technology license must also be
available in order to use the leakage variation feature.

For the current value of this variable, type the following command:

printvar power_enable_leakage_variation_analysis

SEE ALSO
printvar(2)
set_variation_library(2)
set_variation(2)
power_enable_analysis(3)
variation_enable_analysis(3)

power_enable_leakage_variation_analysis
142
power_enable_multi_rail_analysis
Enables or disables PrimeTime PX concurrent multirail power analysis.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

When this variable is set to true, PrimeTime PX starts concurrent multirail power
analysis power updates. Under concurrent multirail power analysis mode, power data
for each rails or supply nets is maintained and processed individually and
concurrently. Power reports of different combinations of rail and supply net
specifications can be generated without the need to update power again.

The -rails option of the report_power command requires that this variable is set to
true.

For the current value of this variable, type

printvar power_enable_multi_rail_analysis

SEE ALSO
report_power(2)

power_enable_multi_rail_analysis
143
power_estimate_power_for_unmatched_event
Controls to estimate power when no table is found in the library to match a certain
event.

TYPE

Boolean

DEFAULT

true

GROUP

power_variables

DESCRIPTION

Sometimes when an output pin toggles, PrimeTime PX cannot find a matching table in
the library based on the current state of the cell. This variable controls whether
PrimeTime PX should skip this event without power contribution or try to estimate a
power number for it according to all the tables in the library relating to this
output pin.

To determine the current value of this variable, type one of the following commands:

printvar power_estimate_power_for_unmatched_event

echo $power_estimate_power_for_unmatched_event

power_estimate_power_for_unmatched_event
144
power_include_initial_x_transitions
Controls to count x power in the power up initialization stage.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

Initially, if you do not set a logic value to a certain net, PrimeTime PX assumes
the logic value is X. In the later stage, the value becomes 0 or 1. This variable
controls whether PrimeTime PX should count the power caused by the X->0 or X->1
toggle.

To determine the current value of this variable, type one of the following commands:

printvar power_include_initial_x_transitions

echo $power_include_initial_x_transitions

power_include_initial_x_transitions
145
power_limit_extrapolation_range
Specifies if extrapolation is limited to a certain range for internal power
calculation.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

This variable specifies if extrapolation is limited to certain range for internal

power calculation. By default, PrimeTime PX does extrapolation with no limit if the
data point for internal power table lookup is out-of-range. This applies for both
nlpm (non-linear power model) and sppm (scalable polynomial power model) types of
internal power table. If this variable is set to true, PrimeTime PX stops
extrapolation as follows:

for nlpm power table: PrimeTime PX stops extrapolation at one additional index grid.
for sppm power table: PrimeTime PX stops extrapolation at the specified range.

For the current value of this variable, type the following command:

printvar power_limit_extrapolation_range

SEE ALSO
printvar(2)

power_limit_extrapolation_range
146
power_match_state_for_logic_x
Specifies logic x interpretation.

TYPE

char

DEFAULT

GROUP

power_variables

DESCRIPTION

Specifies how PrimeTime PX interprets logic x in the Boolean function of the when
state of a power table. This variable uses the following settings:

0: regards x as zero (0)

1: regards x as one (1)

x/X: regards x as neither 0 nor 1. For example, when there is any x logic, the
Boolean function is evaluated as false.

"SEE ALSO
printvar(2)

power_match_state_for_logic_x
147
power_model_preference
Specifies the power model preference if the library contains both CCS power and NLPM
data.

TYPE

string

DEFAULT

ccs

GROUP

power_variables

DESCRIPTION

A library can contain either CCS power data, NLPM data, or both types of data within
a cell definition. Use this variable to specify the power model preference if the
library contains both CCS power and NLPM data. This variable must be set before
library power data loading, otherwise, it is ignored. Allowed values are:

* ccs (the default): PrimeTime PX uses CCS power data in the library (if present)
and ignores any NLPM data for the cell. CCS power data calculates both static and
dynamic power. If no CCS power data is found, PrimeTime PX uses NLPM data.

* nlpm: If this variable is set to nlpm, PrimeTime PX uses NLPM data. If no NLPM
data is found, PrimeTime PX uses CCS power data.

If neither CCS power or NLPM data is found for a cell in the library, the cell is
not characterized for power analysis.

SEE ALSO
printvar(2)

power_model_preference
148
power_rail_output_file
Specifies the output file name for writing out power information for PrimeRail
users.

TYPE

string

DEFAULT

"" (empty)

GROUP

power_variables

DESCRIPTION

The power_rail_output_file variable is provided for PrimeRail users. If the file

name is provided with this variable, during power calculation relevant power
information is written into the file provided. Note that information is written in a
binary format. This file is then read by PrimeRail.

Starting with the B-2008.12 release, the update_power command can perform both
average and peak power analysis. The power_analysis_mode variable can be used to
specify the power analysis mode to perform. PrimeTime PX can perform different types
of power analysis based on the mode setting. The default power analysis mode is
averaged. For more information, see the power_analysis_mode man page.

The set_power_analysis_options command can be used to specify the options for power
analysis. It must be set before the update_power command to take effect in power
analysis. Issuing the set_power_analysis_options command with no option can reset
all the power analysis options to default. Use the report_power_analysis_options
command to get the current analysis option settings. See the
set_power_analysis_options man page for more information.

PrimeTime PX can consume either time-based (for example, a VCD file) or statistical
switching activity information (for example, a SAIF file) for power calculation. For
a particular analysis mode, appropriate activity information must be provided. For
example, in time-based power analysis mode, a VCD file must be provided. In averaged
power analysis mode, any form of switching activity information is accepted. You can
specify a VCD file by using the read_vcd command. The statistical switching activity
can be specified by using the read_saif or set_switching_activity commands.

For the current value of this variable, type the following command:

printvar power_rail_output_file

power_rail_output_file
149
SEE ALSO
printvar(2)
update_power(2)
power_analysis_mode(3)
set_power_analysis_options(2)
report_power_analysis_options(2)

power_rail_output_file
150
power_rail_static_analysis
Excludes timing data in the PTPX binary report file.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable is used to control whether the PTPX binary report file includes timing
data like timing windows. When this variable sets to be true, the purpose of the
PTPX report file is used only for static rail analysis. In this case, timing data is
not needed, and the PTPX report will exclude the timing data to speed up and also
reduce the file size.

SEE ALSO
update_power(2)

power_rail_static_analysis
151
power_read_activity_ignore_case
Use the power_read_activity_ignore_case variable instead of the
power_read_vcd_ignore_case variable to control ignore case when reading activity
files.

TYPE

fIbooleanfP

DEFAULT

true

GROUP

power_variables

DESCRIPTION

The fipower_read_vcd_ignore_case variable has been replaced with the

power_read_activity_ignore_case variable. For backward compatibility, the
fipower_read_vcd_ignore_case variable is an alias for the
power_read_activity_ignore_case variable.

The power_read_activity_ignore_case variable controls match pin, net and cell names
from VCD or SAIF file and those from the design case sensitively if the value of
this variable is false or design case insensitively if the value is true. This
variable also affects the set_rtl_to_gate_name command.

To determine the current value of the active variable, type printvar

power_read_activity_ignore_case or echo $power_read_activity_ignore_case.

SEE ALSO

printvar(2) set_rtl_to_gate_name(2) read_saif(2) read_vcd(2)

power_read_activity_ignore_case
152
power_report_leakage_breakdowns
Controls to report leakage components.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

Controls whether or not the report_power command prints out leakage power
components. By default, the variable value is false, which means the report_power
command does not report leakage power components. For example, only total leakage is
reported. If the variable is set to true, then intrinsic leakage and gate leakage is
also reported, in addition to the total leakage in the summary report and the cell
based power report.

SEE ALSO
printvar(2)
report_power(2)

power_report_leakage_breakdowns
153
power_reset_negative_extrapolation_value
Resets the negative extrapolated energy value from library to zero.

TYPE

Boolean

DEFAULT

false

GROUP

pwr_variables

DESCRIPTION

The power_reset_negative_extrapolation_value variable is used to reset the negative

extrapolated energy value from library to zero, if the energy value for the boundary
points is positive. If this variable is set to true, the negative extrapolated
energy value is reset to zero.

In some cases, the values of variables (mostly output capacitance and input slew),
which is used for extracting the energy number from library energy tables is out of
range. For example, the values can be greater or smaller than the boundary points.
In this scenario, extrapolation techniques are used for deriving the energy number
from library energy tables. If the variable values are too small or too big, the
derived energy number can come out negative. However, the energy number
corresponding to the boundary points can be positive. Using the negative energy
number given the fact that the energy number corresponding to boundary points is
positive, results in incorrect energy numbers. To resolve this problem, use the
power_reset_negative_extrapolation_value variable, which if set to true, resets the
negative extrapolated energy numbers to zero, if the energy number for boundary
points is positive.

To determine the current value of this variable, type one of the following commands:

printvar power_reset_negative_extrapolation_value

echo $power_reset_negative_extrapolation_value

power_reset_negative_extrapolation_value
154
power_reset_negative_internal_power
Resets the negative internal power to zero.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

Resets the negative internal power to zero. This variable can be used if you are
confident about the accuracy of the power tables. Furthermore, if the values of
capacitance and input slew values are out of range from the range specified in the
power tables, the internal energy number can be negative due to extra/intrapolation.
This variable gives you the choice to reset the negative internal energy numbers to
zero.

To determine the current value of this variable, type the following command:

printvar power_reset_negative_internal_power

SEE ALSO
printvar(2)

power_reset_negative_internal_power
155
power_scale_dynamic_power_at_power_off
Indicates if the dynamic power is scaled according to the static probability of the
corresponding power supply net. When this variable is set to false, only leakage
power is scaled by the power-on probability.

TYPE

Boolean

DEFAULT

false

GROUP

power_variables

DESCRIPTION

The statistical activity information can be input from the SAIF file, the
set_switching_activity and set_case_analysis commands, or from default settings and
propagated through the whole design. PrimeTime PX is built with power management
awareness and can reflect power saving technology used in the design in the
calculated power results. If the power supply net is switched off during simulation,
PrimeTime PX can report the correct dynamic and static (leakage) power based on the
statistical activity information.

If the given statistical activity information does not contain any toggle happened
at the power-off state, only leakage power is scaled by the power-on probability.
This is the default behavior. However, if the input activity information includes
toggles happened at the power-off state, both dynamic and leakage power is scaled.
Under such situation, you need to set the power_scale_dynamic_power_at_power_off
variable to true, so that PrimeTime PX applies the scaling to dynamic power as well.

This variable has no effect if there is no power switch Boolean function defined.
Also it only applies to averaged power analysis mode. It has no effect for time-
based power analysis mode. As in time-based mode, PrimeTime PX monitors the status
of the power supply net and determines the power consumption at event basis.

To determine the current value of this variable, type one of the following commands:

printvar power_scale_dynamic_power_at_power_off

echo $power_scale_dynamic_power_at_power_off

SEE ALSO
power_analysis_mode(3)
read_saif(2)
set_switching_activity(2)

power_scale_dynamic_power_at_power_off
156
set_case_analysis(2)

power_scale_dynamic_power_at_power_off
157
power_table_include_switching_power
Indicates whether power tables in technology library include switch power.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Indicates whether the nonlinear power model (NLPM) in the technology library
includes switch power components. There can be 2 types of NLPM internal power tables
from characterization. One type contains pure internal energy. Another type contains
(total energy - 0.5 * switching energy). PrimeTime PX supports the second format by
default. For average power analysis, the difference of these two types of
characterization does not have significant impact on the results. The effects of
added switching energy canceled out by events of opposite edges. For power waveform
generation, the added 0.5 switching energy makes the difference, especially for
single cell or very small designs. For correlation and characterization verification
purposes, small designs or single cell designs might be used and the differences can
be significant.

When the variable is set to false, it means the power tables in the technology
library are of the first type. For example, the values in the tables are pure
internal energy. When it is set to true, the values in power tables are of the
second type. PrimeTime PX chooses the proper power calculation approach based on
this variable.

When using CCS Power tables, this variable should alway be set to false.

power_table_include_switching_power
158
power_x_transition_derate_factor
Sets the scale factor for X-transition power.

TYPE

float

DEFAULT

0.5

GROUP

power_variables

DESCRIPTION

Controls a scale factor for X-transition power.

SEE ALSO
printvar(2)

power_x_transition_derate_factor
159
pt_ilm_dir
Specifies a directory for PrimeTime to create ILM related files.

TYPE

fIstringfP

DEFAULT

(current directory)

DESCRIPTION

Specifies a directory for PrimeTime to create ILM related files. By default, the
value is ".", the current directory. You can set this variable to any directory,
such as /u/primetime/ilm.

Note that if hier_modeling_version is set to 2.0, the directory to create ILM

related files is specified by pt_model_dir instead of this variable.

To determine the current value of this variable, type printvar pt_ilm_dir or echo
$pt_ilm_dir

SEE ALSO
hier_modeling_version(3)
create_ilm(2)
create_si_context(2)
write_arrival_annotations(2)

pt_ilm_dir
160
pt_model_dir
Specifies a directory for PrimeTime to create model related files.

TYPE

fIstringfP

DEFAULT

(current directory)

DESCRIPTION

Specifies a directory for PrimeTime to create model related files. By default, the
value is ".", the current directory. You can set this variable to any directory,
such as /u/primetime/model.

This variable is only effective when variable hier_modeling_version is 2.0. All the
ILM/ETM related files are in the ilm/etm subdirectory under pt_model_dir.

To determine the current value of this variable, type printvar pt_model_dir or echo
$pt_model_dir

SEE ALSO
create_ilm(2)
extract_model(2)
create_si_context(2)
write_arrival_annotations(2)
pt_model_dir(3)

pt_model_dir
161
pt_shell_mode
Describes the mode of operation of the current shell.

TYPE

string

DESCRIPTION

This read-only variable describes the mode of operation of the current shell. The
mode ’primetime’ indicates that the current PrimeTime shell was launched in non
multi_scenario mode. The mode ’primetime_master’indicates that the current shell was
launched by the user with the -multi_scenario option. The mode ’primetime_slave’
indicates that the current shell was launched by the start_hosts command in multi-
scenario mode. The pt_shell_mode variable is usefull in scripts or setup files which
are to be sourced by both the master and the slave.

To determine the current value of this variable, type printvar pt_shell_mode

pt_shell_mode
162
pt_tmp_dir
Directory that PrimeTime uses for temporary storage.

TYPE

fIstringfP

DEFAULT

/tmp (the local /tmp partition)

DESCRIPTION

Specifies a directory for PrimeTime to use as temporary storage. By default, the

value is "/tmp". You can set this variable to any directory with proper read/write
permissions, such as ".", the current directory.

A very important use of the disk storage specified by pt_tmp_dir is for the high
capacity mode (please refer to set_program_options for more details about high
capacity mode). From a storage point of view, there are temporary files created
during the run of PrimeTime to store some data at runtime, the files stored in
pt_tmp_dir are automatically removed either during the run or at the exit of the
program. In order to help users monitor and identify the sub-directories and files
that are still in active use inside pt_tmp_dir, we write special empty file(s) with
names in the form of LOCK#hostname#pid to indicate the host and pid of the PrimeTime
process that is actively using the files in the directory.

To determine the current value of this variable, type printvar pt_tmp_dir or echo
$pt_tmp_dir

SEE ALSO
set_program_options (2)

pt_tmp_dir
163
ptxr_root
Specifies an alternative installation root path for PrimeTime to look for the
executables required by PrimeTime External Reader (ptxr).

TYPE

string

DEFAULT

By default, this variable is the same as the root path where PrimeTime is installed.

DESCRIPTION

When set to a different path from the default PrimeTime installation root, this
variable contains a path name to the executables specific to PrimeTime external
reader (ptxr). Instead of using the reader programs installed within PrimeTime’s
root path, this provides user with the flexibility of supplying an alternative
program that is equivalent to the natively installed executable to achieve reading
of file formats that are only supported by ptxr.

Because this alternative root path is outside of PrimeTime, the availability and
completeness of that installation is not garanteed by PrimeTime. When the expected
ptxr executables cannot be located within the user specified root path, PrimeTime
will fall back and proceed with the natively installed program.

This variable is intended for use only when the natively installed ptxr programs do
not work with certain files of supported formats. Most often it happens when trying
to read files generated by a newer version of synopsys tool such as DesignCompiler
or PhysicalCompiler.

The following example shows how to use the ptxr_root to specify an alternative ptxr
program.

pt_shell> set ptxr_root /tools/DC2004.12-SP1/snps/synopsys

/tools/DC2004.12-SP1/snps/synopsys
pt_shell> read_ddc new_design.ddc
Information: Using user set ptxr_root ’/tools/DC2004.12-SP1/snps/synopsys’.
Beginning read_ddc...

It also should be noted that when this variable is set, all down stream file reading
which requires ptxr will use the reader from the specified path unless it is
explicitly set back to the default.

SEE ALSO
read_lib(2)
read_vhdl(2)

ptxr_root
164
read_ddc(2)
ptxr_setup_file(3)

ptxr_root
165
ptxr_setup_file
Specifies a setup file to be read by the PrimeTime External Reader (ptxr) instead of
home and local .synopsys_dc.setup files.

TYPE

fIstringfP

DEFAULT

By default, this variable does not exist.

DESCRIPTION

When set, this variable contains a pathname to a setup file specific to the
PrimeTime external reader (ptxr). By default, this variable does not exist until you
set it with a value.

This variable is intended for use only if you are reading a netlist using ptxr, by
executing one of the following:

• read_verilog -hdl_compiler

• read_vhdl

• read_ddc

The ptxr program uses the same reader as that used by Design Compiler. When you
execute one of the above commands, the ptxr program by default reads your
.synopsys_dc.setup files (not .synopsys_pt.setup), including the system, home, and
local setup files, to access needed variables. You cannot disable reading of system
.synopsys.dc.setup files, but you can substitute a ptxr-specific setup file for the
home and local setup files by setting the ptxr_setup_file variable with the pathname
of a ptxr-specific setup file you create.

You write the ptxr_setup_file in Tcl. The file can contain a very limited set of
commands: comments, blank lines, and variable assignments, as in the following
example for a file named my_ptxr.setup:

# My ptxr_setup_file
set bus_naming_style "%s(%d)"
set bus_extraction_style "%s[%d:%d]"

The following example shows how to use the ptxr setup file when reading a Verilog
netlist with ptxr. First, you set the ptxr_setup_file variable with the filename
my_ptxr.setup. Next, you invoke the read_verilog command using the -hdl_compiler
option.

ptxr_setup_file
166
pt_shell> set ptxr_setup_file my_ptxr.setup
my_ptxr.setup
pt_shell> read_verilog -hdl_compiler module1.v

To discontinue using the ptxr setup file, unset the ptxr_setup_file variable, as
follows:

pt_shell> unset ptxr_setup_file

SEE ALSO

read_verilog (2), read_vhdl (2). read_ddc (2).

ptxr_setup_file
167
rc_adjust_rd_when_less_than_rnet
Enables or disables overriding of library-derived drive resistance when it is much
less than the dynamic RC network impedance to ground.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When true (the default), PrimeTime checks the library-derived drive resistance, and
if it is less than the dynamic RC network impedance to ground by an amount equal to
or greater than the threshold value contained in the variable
rc_rd_less_than_rnet_threshold (default 0.45), PrimeTime adjusts the drive
resistance using an empirical formula. To disable the checking and adjustment, set
the rc_adjust_rd_when_less_than_rnet variable to false.

When the library-derived drive resistance is much less than the dynamic RC network
impedance to ground, the behavior of the resistor-based driver model can deviate
from that of transistors. In this case, PrimeTime replaces the drive resistance with
a value obtained by using an empirical formula to improve accuracy, and issues the
RC-009 message. This entire process of checking, detection, replacement, and issuing
of the message is referred to as the "RC-009 condition".

This variable is one of a set of four variables relevant to the RC-009 condition.
The other three are effective only when rc_adjust_rd_when_less_than_rnet is true,
and are as follows:

• rc_degrade_min_slew_when_rd_less_than_rnet determines whether or not slew

degradation is used in min analysis mode when the RC-009 condition occurs. The
default is false. To use slew degradation during the RC-009 condition, set this
variable to true.

• rc_filter_rd_less_than_rnet determines whether the RC-009 message is issued only

when a network delay is greater than the corresponding driver transition time. The
default is true. To receive RC-009 messages every time PrimeTime overrides the drive
resistance, set this variable to false.

• rc_rd_less_than_rnet_threshold specifies the threshold beyond which PrimeTime

overrides the library-derived drive resistance with an empirical formula. The
default is 0.45. If there is a reason why the default is not appropriate in your
situation, you can set this variable to another value.

For more information, see the manual page of the RC-009 warning message.

rc_adjust_rd_when_less_than_rnet
168
To determine the current value of this variable, type printvar
rc_adjust_rd_when_less_than_rnet or echo $rc_adjust_rd_when_less_than_rnet.

SEE ALSO

rc_degrade_min_slew_when_rd_less_than_rnet (3), rc_filter_rd_less_than_rnet (3),

rc_rd_less_than_rnet_threshold (3); RC-009 (n).

rc_adjust_rd_when_less_than_rnet
169
rc_always_use_max_pin_cap
Specifies whether to override the use of pin-capacitances from the min library
during min RC delay-calculation and use the pin-capacitances from the max library
instead. This functionality is provided only to obtain backward compatibility with
older releases of PrimeTime.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

As of the 2002.09 release of PrimeTime, support for min pin-capacitance during min
RC delay-calculation is provided. To achieve backward compatibility with previous
releases of PrimeTime, set the rc_always_use_max_pin_cap variable to true.

To determine the current value of this variable, enter the following command:

pt_shell> printvar rc_always_use_max_pin_cap

SEE ALSO

set_min_library (2).

rc_always_use_max_pin_cap
170
rc_cache_min_max_rise_fall_ceff
Specifies whether to cache min/max rise/fall values of effective capacitance
computed during RC delay calculation.

TYPE

boolean

DEFAULT

false

DESCRIPTION

Specifies whether to cache min/max rise/fall values of effective capacitance

computed during RC delay calculation. These cached values may be queried via
attributes on driver pins and ports with driving cells.

When the rc_cache_min_max_rise_fall_ceff shell variable is set true before a timing

update occurs, the effective-capacitance (also known as C-effective) associated with
propagated driver behavior is cached according to min/max and rise/fall
characteristics.

There are four driver-pin/port attributes that can be queried to obtain the cached
values: cached_ceff_max_rise, cached_ceff_min_rise, cached_ceff_max_fall, and
cached_ceff_min_fall. These cached attributes are useful for obtaining the worst-
case C-effectives for every driver in the design. Note that the other C-effective
attributes (that is, effective_capacitance_min, effective_capacitance_max,
ceff_params_min, and ceff_params_max) are computed at query time and, thus, take
considerably more runtime.

The values of the cached attributes depend on the selected slew-propagation mode.
See the timing_slew_propagation_mode shell variable man page for more information
about slew propagation.

Note that if the rc_cache_min_max_rise_fall_ceff shell variable is false during the

most-recent timing update, the cached values are not created or updated. This means
that the attribute values might be nonexistent or invalid.

The following tcl code show how to use the attribute query results only when the
attributes exist.

set ceff \
[get_attribute -quiet $obj ceff_min_rise]
if {[string length $ceff] != 0} {
...
}

The cached values are removed only when you execute the remove_annotated_parasitics
command or when a netlist-editing command has similar reason to remove annotated
parasitics.

rc_cache_min_max_rise_fall_ceff
171
To determine the current value of this variable, enter the following command:

pt_shell> printvar \
rc_cache_min_max_rise_fall_ceff

SEE ALSO

remove_annotated_parasitics (2), timing_slew_propagation_mode (3).

rc_cache_min_max_rise_fall_ceff
172
rc_ceff_use_delay_reference_at_cpin
Specifies whether to compute C-effective using a driver delay relative to that for
the output pin capacitance. This can improve accuracy for drivers with many internal
stages (e.g. extracted timing models), but it requires library data characterized
all the way to down to the output pin capacitance.

TYPE

boolean

DEFAULT

false

DESCRIPTION

PrimeTime adjusts C-effective to match library and RC-network delays to within a

small percentage. When the library delay is very large, as would be the case for a
driver with many internal stages (e.g. an extracted timing model), this criterion
can be met without a sufficient number of C-effective iterations.

If rc_ceff_use_delay_reference_at_cpin is set true, then PrimeTime will exclude the

portion of the library delay due to output pin capacitance from the C-effective
convergence criterion. This will allow a sufficient number of iterations to occur.

Note that if rc_ceff_use_delay_reference_at_cpin is true, then the library data must

be characterized all the way down to the output pin capacitance.

To determine the current value of this variable, enter the following command:

pt_shell> printvar rc_ceff_use_delay_reference_at_cpin

SEE ALSO

rc_ceff_use_delay_reference_at_cpin
173
rc_degrade_min_slew_when_rd_less_than_rnet
Enables or disables the use of slew degradation in min analysis mode during the RC-
009 condition.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When false (the default), PrimeTime does not use slew degradation through RC
networks in min analysis mode during the RC-009 condition. When true, PrimeTime uses
slew degradation during the RC-009 condition. This variable is effective only if the
rc_adjust_rd_when_less_than_rnet variable is true.

The "RC-009 condition" means a condition in which PrimeTime checks the library-
derived drive resistance, and if it is less than the dynamic RC network impedance to
ground by an amount equal to or greater than the value of the
rc_rd_less_than_rnet_threshold variable, PrimeTime adjusts the drive resistance
using an empirical formula to improve accuracy, and issues the RC-009 message. In
case this improved accuracy is not sufficient, PrimeTime provides extra pessimism by
not using slew degradation in min analysis mode; however, superfluous min delay
violations could occur as a side effect. You can keep slew degradation on in min
analysis mode after you have qualified the RC-009 methodology for your accuracy
requirements, by setting this variable to true.

rc_degrade_min_slew_when_rd_less_than_rnet is one of a set of four variables

relevant to the RC-009 condition. The other three are as follows:

• rc_adjust_rd_when_less_than_rnet enables or disables the RC-009 condition; the

default is true. When this variable is set to false, PrimeTime does not check the
drive resistance, and the values of the other related variables do not matter.

• rc_filter_rd_less_than_rnet determines whether the RC-009 message is issued only

when a network delay is greater than the corresponding driver transition time. The
default is true. To receive RC-009 messages every time PrimeTime overrides the drive
resistance, set this variable to false. This variable has no effect if
rc_adjust_rd_when_less_than_rnet is false.

• rc_rd_less_than_rnet_threshold specifies the threshold beyond which PrimeTime

overrides the library-derived drive resistance with an empirical formula. The
default is 0.45 ohms. You can override this default by setting the variable to
another value. This variable has no effect if rc_adjust_rd_when_less_than_rnet is
false.

rc_degrade_min_slew_when_rd_less_than_rnet
174
Note: If rc_degrade_slew_when_rd_less_than_rnet is false while
rc_filter_rd_less_than_rnet is true, the RC-009 message is not issued.

For more information, see the manual page of the RC-009 warning message.

To determine the current value of this variable, type printvar

rc_degrade_min_slew_when_rd_less_than_rnet or echo
$rc_degrade_min_slew_when_rd_less_than_rnet.

SEE ALSO

rc_ajust_rd_when_less_than_rnet (3), rc_filter_rd_less_than_rnet (3),

rc_rd_less_than_rnet_threshold (3); RC-009 (n).

rc_degrade_min_slew_when_rd_less_than_rnet
175
rc_driver_model_mode
Specifies which driver model type to use for RC delay calculation.

TYPE

string

DEFAULT

advanced

DESCRIPTION

PrimeTime supports two types of driver models for RC delay calculation, basic and
advanced. The basic model is derived from the conventional delay and slew library
schema, while the advanced model is derived from a new schema. The advanced model
has many advantages, one of which is the solution to the problem described by the
RC-009 warning message. The advanced driver model is part of the Synopsys Composite
Current-Source (CCS) model.

When the shell variable rc_driver_model_mode is set to basic, RC delay calculation

will always use driver models derived from the conventional delay and slew schema
present in design libraries. When set to advanced, RC delay calculation will use the
advanced driver model if data for it is present. The report_delay_calculation
command used on a cell arc will show the message "Advanced driver-modeling used" as
appropriate.

When the shell variable rc_driver_model_mode is set to basic, and the variable
rc_receiver_model_mode is set to advanced, PrimeTime will use the advanced voltage-
dependent capacitance models to derive an equivalent single capacitance dependent
only on the rise, fall, min or max arc condition and these equivalent capacitances
will be used in analysis instead of the pin capacitances from the library. Please
check the manpage for variable rc_receiver_model_mode for additional details.

To determine the current value of this variable, enter the following command:

pt_shell> printvar rc_driver_model_mode

SEE ALSO

rc_receiver_model_mode (3), report_delay_calculation (2).

rc_driver_model_mode
176
rc_filter_rd_less_than_rnet
Enables or disables suppressing the display of RC-009 messages when the network
delay is less than the corresponding driver transition time.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When true (the default), PrimeTime displays the RC-009 message only when a network
delay is greater than the corresponding driver transition time. When false,
PrimeTime displays the RC-009 message whenever it overrides the library-derived
drive resistance during the RC-009 condition. This variable is effective only if the
rc_adjust_rd_when_less_than_rnet variable is true.

The "RC-009 condition" means a condition in which PrimeTime checks the library-
derived drive resistance, and if is less than the dynamic RC network impedance to
ground by an amount equal to or greater than the value of the
rc_rd_less_than_rnet_threshold variable, PrimeTime replaces the drive resistance
with a value obtained by using an empirical formula to improve accuracy and issues
the RC-009 message. The filtering provided by rc_filter_rd_less_than_rnet isolates
those timing calculations known to be most sensitive to drive resistance. The
network delay is not compared with the slew itself, but with with the time the
driver reaches its later slew trip point. If you want the RC-009 message to be
displayed whenever PrimeTime drive resistance to improve accuracy, set this variable
to false.

This variable is one of a set of four variables related to the RC-009 condition. The
others are as follows:

• rc_adjust_rd_when_less_than_rnet enables or disables the RC-009 condition; the

default is true. When this variable is set to false, PrimeTime does not check the
drive resistance, and the values of the other related variables do not matter.

• rc_degrade_min_slew_when_rd_less_than_rnet determines whether or not slew

degradation is used in min analysis mode when the RC-009 condition occurs. The
default is false. To use slew degradation, set this variable to true. This variable
has no effect if rc_adjust_rd_when_less_than_rnet is false.

• rc_rd_less_than_rnet_threshold specifies the threshold beyond which PrimeTime

overrides the library-derived drive resistance with an empirical formula. The
default is 0.45 ohms. You can override this default by setting the variable to
another value. This variable has no effect if rc_adjust_rd_when_less_than_rnet is

rc_filter_rd_less_than_rnet
177
false.

For more information, see the manual page of the RC-009 warning message.

To determine the current value of this variable, type printvar

rc_filter_rd_less_than_rnet or echo $rc_filter_rd_less_than_rnet.

SEE ALSO

RC-009 (n).

rc_filter_rd_less_than_rnet
178
rc_rd_less_than_rnet_threshold
Specifies the RC-009 threshold, beyond which PrimeTime overrides the library-derived
drive resistance with an empirical formula, to improve accuracy.

TYPE

double

DEFAULT

0.45

DESCRIPTION

This variable specifies a metric threshold to be used by PrimeTime to determine

whether to adjust the library-derived drive resistance using an empirical formula;
see the RC-009 man page for more information about this condition. This variable is
effective only if the rc_adjust_rd_when_less_than_rnet variable is true. The default
value of this variable is 0.45.

To determine the value appropriate for a given technology, look at PrimeTime

accuracy vs. drive-strength for cells connected to very resistive networks, e.g.
top-level routes, with rc_adjust_rd_when_less_than_rnet set false. At a particular
drive-strength the accuracy will suffer due to the limitation in the delay/slew
schema that RC-009 addresses. Then set rc_adjust_rd_when_less_than_rnet true and use
a value of rc_rd_less_than_rnet_threshold high-enough to be used for all the drivers
(e.g. 1.0). Next, gradually decrease rc_rd_less_than_rnet_threshold until RC-009
switches off at the desired drive-strength.

Customers who have performed this study have so far obtained values very close to
the default value of 0.45. As technology shrinks, so will drive-resistances, causing
an increased occurrance of RC-009; in that case users can decrease the
rc_rd_less_than_rnet_threshold variable or switch to using Composite Current-Source
data for delay calculation.

To determine the current value of this variable, type printvar

rc_less_than_rnet_threshold or echo $rc_less_than_rnet_threshold.

SEE ALSO

rc_degrade_min_slew_when_rd_less_than_rnet (3), rc_filter_rd_less_than_rnet (3),

rc_rd_less_than_rnet_threshold (3); RC-009 (n).

rc_rd_less_than_rnet_threshold
179
rc_receiver_model_mode
Specifies which receiver model type to use for RC delay calculation.

TYPE

string

DEFAULT

advanced

DESCRIPTION

PrimeTime supports two types of receiver models for RC delay calculation, basic and
advanced. The basic model is a single capacitance dependent only on the rise, fall,
min, or max arc condition. The advanced model is a voltage-dependent capacitance
additionally dependent on input-slew and output capacitance. The advanced model has
many advantages, one of which is that the accuracy of both delays and slews is
improved. Another advantage is that nonlinearities such as the Miller effect are
addressed. The advanced receiver model is part of the Synopsys Composite Current-
Source (CCS) model.

When set to advanced, RC delay calculation will use the advanced receiver model if
data for it is present and if the network is driven by the advanced driver model.
The report_delay_calculation command used on a network arc will show the message
"Advanced receiver-modeling used" as appropriate.

When the shell variable rc_receiver_model_mode is set to advanced, and the network
is not driven by the advanced driver model, ( i.e. the variable rc_driver_model_mode
is set to basic or lumped load is used), PrimeTime will use the advanced voltage-
dependent capacitance models to derive an equivalent single capacitance dependent
only on the rise, fall, min or max arc condition. These equivalent capacitances will
be used in analysis instead of the pin capacitances from the library. The
report_delay_calculation command used on a network arc will not show the message
"Advanced receiver-modeling used" for these calculations, since only an equivalent
single capacitance is used.

When the shell variable rc_receiver_model_mode is set to basic, RC delay calculation

will always use the pin capacitances specified in the design libraries.

To determine the current value of this variable, enter the following command:

pt_shell> printvar rc_receiver_model_mode

SEE ALSO

rc_driver_model_mode (3), report_delay_calculation (2).

rc_receiver_model_mode
180
read_parasitics_load_locations
Specifies that read parasitics should load locations information during the reading
of a parasitics file.

TYPE

fIbooleanfP

DEFAULT

false

DESCRIPTION

When this variable is set to true, read_parasitics will load the locations of
various nodes of nets, pins, and ports that are present in the parasitic file. The
default is false, in which case locations infomation will not be loaded into
PrimeTime.

The location data is stored using attributes. The attributes are set to the
coordinate value directly from the parasitics files, and no interpretation or unit
conversion is performed. The following attributes are available on pin and port
objects.

*x_coordinate (float) * y_coordinate (float)

These attributes define a single (x, y) point. The following attributes are
available on cell and net objects.

* x_coordinate_min (float) * x_coordinate_max (float) * y_coordinate_min (float) *

y_coordinate_max (float)

These attributes define a bounding box around the cell or net. For cells, the
bounding box is computed using all pins of the cell. For nets, the bounding box is
computed using all net terminals (port and pins). If the parasitics file includes
coordinates for intermediate modes, these will also be considered for the net’s
bounding box.

If location data has been loaded, it will be included in any parasitics files
written out by PrimeTime. If you remove the parasitics from a net (using the
remove_annotated_parasitics command, for instance), PrimeTime also deletes the
location data.

SEE ALSO

read_parasitics (2).

read_parasitics_load_locations
181
report_capacitance_use_ccs_receiver_model
Specifies if basic or advanced receiver model should be reported in reporting
commands.

TYPE

boolean

DEFAULT

true

DESCRIPTION

When set this variable to be true, advanced receiver model will be reported in
report_net, report_attribute, report_delay_calculation and report_timing.

SEE ALSO

report_timing (2) report_net (2) report_delay_calculation (2).

report_capacitance_use_ccs_receiver_model
182
report_default_significant_digits
The default number of significant digits used to display values in reports.

TYPE

int

DEFAULT

DESCRIPTION

Sets the default number of significant digits for many reports. Allowed values are
0-13; the default is 2. Some report commands (for example, the report_timing
command) have a -significant_digits option that overrides the value of this
variable.

Not all reports respond to this variable. Check the man page of individual reports
to determine whether they support this feature.

To determine the current value of this variable, type one of the following:

printvar report_default_significant_digits

echo report_default_significant_digits

SEE ALSO
report_timing(2)

report_default_significant_digits
183
sdc_save_source_file_information
Enables or disables source file name and line number information of a subset of SDC
commands related to the current design constraints PrimeTime context.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Setting this variable to true enables PrimeTime to preserve source location

information, namely the source file name and line number. The scope of source
location tracking only applies to the following timing exceptions commands:

set_false_path

set_multicycle_path

set_max_delay

set_min_delay

Important Note: The value of this variable is only allowed to be modified as long as
no exceptions have been input. If at least one exception command has already been
successfully input, attempting to set this variable results in the CMD-013 error
message being issued, and the variable value remains unchanged.

Note that source information is not available for any commands that were not input
using source. (Tcl files sourced using the -f command line option are internally
processed through the source command for the purposes of this feature.) Therefore,
commands entered interactively at the shell prompt would not preserve nor print
source location data. Also, commands input inside control structures, such as if-
statements, loops, or procedure calls are not accurately tracked.

This location data per exception command could be viewed using either the
report_exceptions or report_timing -exceptions command.

To determine the current value of this variable, type one of the following:

printvar sdc_save_source_file_information

echo $sdc_save_source_file_information.

EXAMPLES

Here is an example of the timing exceptions report using the report_exceptions

sdc_save_source_file_information
184
command.

pt_shell> report_exceptions

****************************************
Report : exceptions
Design : dma
Version: Z-2007.06
Date : Thu Apr 5 19:42:40 2007
****************************************

Reasons : f invalid start points

t invalid end points
p non-existent paths
o overridden paths

From To Setup Hold

------------------------------------------------------------------------
arbiter/lat_reg/CK { arbiter/state_reg_3_/D arbiter/state_reg_2_/D }
cycles=2 *
[ location = /path/constraints.tcl:197 ]

Here is another example of the timing exceptions report using the report_timing -
exceptions command.

pt_shell> report_timing -exceptions all

****************************************
Report : timing
-path_type full
-delay_type max
-max_paths 1
-exceptions all
Design : dma
Version: Z-2007.06
Date : Thu Apr 5 19:46:44 2007
****************************************

[ Timing report omitted. ]

The dominant exceptions are:

From To Setup Hold
------------------------------------------------------------------------

arbiter/lat_reg/CK
{ arbiter/state_reg_3_/D arbiter/state_reg_2_/D }
cycles=2 *
[ location = /path/constraints.tcl:197 ]

The overridden exceptions are:

None

SEE ALSO
report_exceptions(2)

sdc_save_source_file_information
185
report_timing(2)

sdc_save_source_file_information
186
sdc_version
Use in context of reading a Synopsys Design Constraints (SDC) file. Specifies the
SDC version that was written.

TYPE

string

DEFAULT

latest version

DESCRIPTION

The sdc_version variable is meaningful only within the context of reading an SDC
file. Setting it outside an SDC file has no impact, other than to produce an
informational message.

The write_sdc command writes a command to the SDC file to set the sdc_version
variable to the version that was written. There is no user control over the version
of SDC that is written. The most current version is written. When the read_sdc
command reads the SDC file, it validates the version specified in the file (if
present) with the version requested by the command.

SEE ALSO
read_sdc(2)
write_sdc(2)

sdc_version
187
sdc_write_unambiguous_names
Determines whether or not ambiguous hierarchical names are made unambiguous when
they are written to SDC files.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When this variable is set to its default of true, the application ensures that cell,
net, pin, lib_cell, and lib_pin names written to the Synopsys Design Constraints
(SDC) file are not ambiguous. When hierarchy has been partially flattened, embedded
hierarchy separators can make names ambiguous, so that it is unclear which hierarchy
separator characters are part of the name, and which are real separators. Beginning
with SDC Version 1.2, hierarchical names can be made unambiguous using the
set_hierarchy_separator SDC command and the -hsc option of the following SDC object
access commands:

get_cells
get_lib_cells
get_lib_pins
get_nets
get_pins

By default, PrimeTime and Design Compiler writes an SDC file using these features to
create unambiguous names.

The recommended practice is to accept the default behavior and allow the application
to write SDC files that do not contain ambiguous names. However, if you are using a
third-party application that does not support the unambiguous hierarchical names
feature of SDC (in SDC Versions 1.2 and later), you can suppress this feature by
setting the sdc_write_unambiguous_names variable to false. The write_sdc command
issues a warning if you set this variable to false.

To determine the current value of this variable, type the following:

printvar sdc_write_unambiguous_names

SEE ALSO
write_sdc(2)

sdc_write_unambiguous_names
188
sdf_align_multi_drive_cell_arcs
Boolean variable which specifies whether PrimeTime will unify the small timing
differences in driver cell outputs of a parallel network, when writing out sdf delay
values.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Small timing differences in the timed switching characteristics of the mesh arcs can
cause the simulation to fail. By setting the sdf_align_multi_drive_cell_arcs
variable to true, PrimeTime attempts to align the delays between the driver pins of
the parallel network and the load pins of the network. The cell and net delay arcs
written to the SDF file is adjusted to make this happen. The net arcs are only
altered if you set the sdf_enable_port_construct variable to true. Therefore, to
eliminated the small timing differences, you must set both the
sdf_align_multi_drive_cell_arcs and sdf_enable_port_construct variable to true, and
the following criteria must be true:

1. All cells have to be nonsequential, nonhierarchical cells. 2. All cells

must be single input, single output devices. 3. None of the drivers of the
parallel network are three-state buffers.

To determine the current value of this variable, type the following:

printvar sdf_align_multi_drive_cell_arcs

SEE ALSO
sdf_align_multi_drive_cell_arcs_threshold(3)
sdf_enable_port_construct(3)
sdf_enable_port_construct_threshold(3)

sdf_align_multi_drive_cell_arcs
189
sdf_align_multi_drive_cell_arcs_threshold
Specifies the threshold below which multidrive cell arcs are aligned during the
write_sdf command.

TYPE

float

DEFAULT

DESCRIPTION

Small timing differences in the timed switching characteristics of the mesh arcs can
cause the simulation to fail. When you set the sdf_align_multi_drive_cell_arcs
variable to true, PrimeTime attempts to unify the delays between the driver pins of
the parallel network and the load pins of the network. The cell delay arcs written
to the Standard Delay Format (SDF) file is adjusted to make this happen. The
criteria for this to occur is that the delay values of the parallel cells are within
a threshold of each other, where the threshold is specified by the
sdf_align_multi_drive_cell_arcs_threshold variable. The threshold value is specified
in pico seconds (ps), where the default value is 1 ps.

To determine the current value of this variable, type the following:

sdf_align_multi_drive_cell_arcs_threshold

SEE ALSO
sdf_align_multi_drive_cell_arcs_threshold(3)
sdf_enable_port_construct(3)
sdf_enable_port_construct_threshold(3)

sdf_align_multi_drive_cell_arcs_threshold
190
sdf_annotate_cond_specific_delays
Enables or disables support for out-of-order specific conditional delay annotations.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When you set this variable to true, during the annotating conditional timing arcs,
PrimeTime provides precedence to conditional Standard Delay Format (SDF) delay
information over default delay information. This variable affects the read_sdf and
set_annotated_delay commands.

SEE ALSO
read_sdf(2)

sdf_annotate_cond_specific_delays
191
sdf_enable_cond_start_end
Enables or disables support for the sdf_cond_start and sdf_cond_end attributes.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When you set this variable to true, PrimeTime supports the sdf_cond_start and
sdf_cond_end attributes on timing arcs. These attributes impact the way the read_sdf
and write_sdf commands deal with timing arcs.

SEE ALSO
read_sdf(2)

sdf_enable_cond_start_end
192
sdf_enable_port_construct
Enables or disables support for port construct usage during the write_sdf command.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

For designs with high-fanin, high-fanout mesh clock networks, large Standard Delay
Format (SDF) files are produced. When you set the sdf_enable_port_construct variable
to true, PrimeTmie attempts to reduce the size of the produced SDF file. PrimeTime
uses the port construct instead of the interconnect construct when executing the
write_sdf command.

Using the port construct is restricted by the sdf_enable_port_construct_threshold

variable. Any group of parallel nets in the design that are not driven or driving
three-state buffers and that have a delay value within the threshold as defined by
the sdf_enable_port_construct_threshold variable is written out using a port
construct. Otherwise, the interconnect construct is used. The port construct is not
used on nets outside the clock network. It must be noted that the produced SDF file
can contain both port and interconnect statements for a given load pin. In this
case, the port statement is written out first, followed by interconnect statements.

SEE ALSO
sdf_enable_port_construct_threshold(3)

sdf_enable_port_construct
193
sdf_enable_port_construct_threshold
Sets the threshold value for the parallel net arcs delay variance below which
parallel nets are written out using the port construct during the write_sdf command.

TYPE

float

DEFAULT

DESCRIPTION

For designs with high-fanin, high-fanout mesh clock networks, large Standard Delay
Format (SDF) files are produced. When you set the sdf_enable_port_construct variable
to true, PrimeTime attempts to reduce the size of the produced SDF file. The
sdf_enable_port_construct_threshold variable provides a maximum value for the
parallel net arcs delay variance below which parallel nets are written out using the
port construct.

The threshold value is specified in pico seconds, where the default value is 1 ps.

To determine the current value of this variable, type one of the following:

printvar sdf_enable_port_construct_threshold

echo $sdf_enable_port_construct_threshold

SEE ALSO
sdf_enable_port_construct(3)

sdf_enable_port_construct_threshold
194
search_path
Shows a list of directory names that contain design and library files that are
specified without directory names.

TYPE

list

DEFAULT

"" (empty)

DESCRIPTION

A list of directory names that specifies which directories to search for design and
library files that are specified without directory names. Normally, the search_path
variable is set to a central library directory. The default value of this variable
is the empty string, "". The read_db and link_design commands particularly depend on
the search_path variable.

You can cause the source command to search for scripts using the search_path
variable, by setting the sh_source_uses_search_path variable to true.

To determine the current value of this variable, type one of the following:

printvar search_path

echo $search_path

SEE ALSO
link_design(2)
read_db(2)
source(2)
sh_source_uses_search_path(3)

search_path
195
sh_eco_enabled
Read-only variable that indicates if the engineering change order (ECO) commands are
enabled.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable indicates if the program is in ECO mode or not. In not in ECO mode,
unconnected cells are removed to get better performance and capacity, and the ECO
parasitics (such as the read_parasitics command with the -eco option) cannot be
read.

If you must change the value of this variable, use the set_program_options command.

To determine the current value of this variable, type the following command:

pt_shell> printvar sh_eco_enabled

SEE ALSO
set_program_options(2)

sh_eco_enabled
196
sh_enable_line_editing
Enables the command line editing capabilities in PrimeTime.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

If this variable set to its default of true, advanced UNIX like shell capabilities
are enabled

This variable needs to be set in the .synopsys_pt.setup file to take effect.

Key Bindings

The list_key_bindings command displays current key bindings and the edit mode. To
change the edit mode, the sh_line_editing_mode variable can be set in either the
.synopsys_pt.setup file or directly in the shell.

Command Completion

The editor is able to complete commands, options, variables, and files given a
unique abbreviation. You must type part of a word and hit the tab key to get the
complete command, variable, or file. For command options, type - and hit tab key to
get the options list.

If no match is found, the terminal bell rings. If the word is already complete, a
space is added to the end if it isn’t already there, to speed typing and provide a
visual indicator of successful completion. Completed text pushes the rest of the
line to the right. If there are multiple matches, all the matching commands,
options, files, or variables are autolisted.

Completion works in following context sensitive way:

The first token of a command line : completes commands

Token that begins with "-" after a command : completes command arguments

After a ">", "|" or a "sh" command : completes file names

After a set, unset or printvar command : completes variables

After ’$’ symbol : completes variables

sh_enable_line_editing
197
After the help command : completes command

After the man command : completes commands or variables

Any token which is not the first token and does not match any of the above rules :
completes file names

SEE ALSO
list_key_bindings(2)
sh_line_editing_mode(3)

sh_enable_line_editing
198
sh_fast_analysis_mode_enabled
Read-only variable that indicates if fast analysis mode is enabled.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable indicates if fast analysis mode is enabled. In fast analysis mode,
there is a trade-off between accuracy and better performance.

To change the value of this variable, use the set_program_options command.

To determine the current value of this variable, type the following:

pt_shell> printvar sh_fast_analysis_mode_enabled

SEE ALSO
set_program_options(2)

sh_fast_analysis_mode_enabled
199
sh_high_capacity_effort
Specifies the level of capacity effort for the timing analysis of PrimeTime and
PrimeTime SI. It only provides simple heuristics for trade-off between capacity and
performance of the program. It does not have any impact on the analysis results.

TYPE

string

DEFAULT

default

DESCRIPTION

Specifies the effort level for capacity improved mode of the program. Allowed values
are default, low, medium, and high. The default value corresponds to the medium
setting.

When effort level increases, the peak memory required by the tool is expected to
reduce, with potentially slightly longer run time. It should be clarified that this
variable only provides simple heuristic control on the trade-off between capacity
and performance. And most importantly, regardless of the value, this variable alone
does not change the results of the analysis.

This variable is only effective when the program is running in high capacity mode by
issuing the set_program_options -enable_high_capacity command.

If the program is already in high capacity mode, further change of this variable do
not have any effect until the next time the above command is issued.

To determine the current value of this variable, type the following:

printvar sh_high_capacity_effort

SEE ALSO
set_program_options(2)

sh_high_capacity_effort
200
sh_high_capacity_enabled
A read-only variable for you to query whether high capacity mode is currently
enabled or not. The value of this variable changes upon a successful change of the
state with the set_program_options command.

TYPE

Boolean

DEFAULT

false for small designs, true for large designs

DESCRIPTION

This is a read-only variable. You can query its value for the mode of analysis and
program accordingly. The value of this variable changes after successfully executing
the set_program_options command.

From the D-2010.06 release, this variable and the sh_high_capacity_effort variable
are saved and restored. For more information, see the set_program_options man page.

To determine the current value of this variable, type the following:

printvar sh_high_capacity_enabled

SEE ALSO
set_program_options(2)
sh_high_capacity_effort(3)

sh_high_capacity_enabled
201
sh_launch_dir
Defines the launch directory of the current PrimeTime shell.

TYPE

string

DESCRIPTION

This read-only variable defines the launch directory of the current PrimeTime shell.
In multi-scenario analysis, all slaves are launched from the same directory as the
master. However during the course of analysis, the slave changes its current working
directory multiple times but the /fBsh_launch_dir/fP variable remains constant
across all slaves and the master.

To determine the current value of this variable, type the following:

printvar sh_launch_dir

sh_launch_dir
202
sh_limited_messages
The set of message types that have a limit by default when the read_parasitics,
report_annotated_parasitics with the -check option, read_sdf, or update_timing
command is invoked. This limit is defined by the sh_message_limit command.

TYPE

string

DEFAULT

"DES-002 PARA-004 PARA-006 PARA-007 PARA-040 PARA-041 PARA-043 PARA-044 PARA-045

PARA-046 PARA-047 PARA-050 PARA-051 PARA-053 RC-002 RC-004 RC-005 RC-009 RC-011 RC-
104 PTE-014 PTE-060 PTE-070 SDF-036 UITE-494 LNK-039 LNK-038"

DESCRIPTION

This command defines the set of messages that have a limit by default when the
read_parasitics, report_annotated_parasitics with the -check option, read_sdf, or
update_timing command is executed. This limit has no impact on messages that are
emitted from other commands.

This limit is refreshed per invoking of the read_parasitics,

report_annotated_parasitics with the -check option, read_sdf, or implicit or
explicit update_timing command. Each time one of these commands is invoked the
sh_message_limit command allows a number of messages to show up for each message
type specified with the sh_limited_messages command. If the limit is exceeded for
one type of message, a warning message appears showing the type of message that is
suppressed.

The setting of this variable has lower priority than the set_message_info command.
If the set_message_info command is already used to set the limit for a message type,
this command has no impact for the default limit for that message type.

If it is needed to remove this default limit, either set the sh_limited_messages

variable to "" or set the sh_message_limit variable to 0.

To determine the current value of this variable, type the following command:

pt_shell> printvar sh_limited_messages

SEE ALSO
get_message_info(2)
print_message_info(2)
set_message_info(2)
sh_message_limit(3)

sh_limited_messages
203
sh_line_editing_mode
Enables vi or Emacs editing mode in the PrimeTime shell.

TYPE

string

DEFAULT

emacs

DESCRIPTION

Used to set the command line editor mode to either vi or Emacs. Valid values are the
default of Emacs and vi.

Use the list_key_bindings command to display the current key bindings and edit mode.

This variable can be set in the either the .synopsys_pt.setup file or directly in
the shell. The sh_enable_line_editing variable must be set to its default of true.

SEE ALSO
list_key_bindings(2)
sh_enable_line_editing(3)

sh_line_editing_mode
204
sh_message_limit
Default limit of messages defined in sh_limited_messages during read_parasitics,
report_annotated_parasitics (with -check), read_sdf and update_timing.

TYPE

int

DEFAULT

100

DESCRIPTION

This variable defines the default limit of the messages in the sh_limited_messages
variable when the read_parasitics, report_annotated_parasitics (with -check option),
read_sdf or update_timing command is executed. This limit is not effective for
messages emitted from other commands.

This limit is refreshed when the read_parasitices, report_annotated_parasitics -

check, read_sdf or implicit or explicit update_timing command is invoked. Each time
you invoke one of these commands, the sh_message_limit variable displays the number
of messages that show up for each message type set using the sh_limited_messages
variable. If the limit is exceeded for one type of message, a warning message
appears explaining that this type of message is being suppressed.

The setting of this variable has lower priority than the set_message_info command.
If the set_message_info command is already used to set the limit for a message type,
the default limit on that message type is not effective.

To remove this default limit, either set the sh_limited_messages variable to "" or
set the sh_message_limit variable to 0.

To determine the current value of this variable, type the following command:

pt_shell> printvar sh_message_limit

SEE ALSO
get_message_info(2)
print_message_info(2)
set_message_info(2)
sh_limited_messages(3)

sh_message_limit
205
sh_output_log_file
Specifies the name of the file to which all application output is logged.

TYPE

string

DEFAULT

"" (empty)

DESCRIPTION

Specifies the name of the file to which the application logs all output information
during a session. By default, this variable is set to an empty string, indicating
that the application’s output is not logged.

This variable can be set only in a setup file. After setup files have been read, the
variable becomes read-only.

To determine the current value of this variable, type the following:

printvar sh_output_log_file

SEE ALSO
sh_command_log_file(3)

sh_output_log_file
206
si_analysis_logical_correlation_mode
Enables or disables logical correlation analysis during PrimeTime SI delay or noise
calculation.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When this variable is set to its default of true, PrimeTime SI enables logical
correlation analysis while performing crosstalk delay or crosstalk noise analysis.
In logical correlation analysis, PrimeTime SI considers the logical relationships
between multiple aggressor nets where buffers and inverters are used, so that the
analysis is less pessimistic.

When you set this variable to false, PrimeTime SI assumes that the aggressor nets
switch together in the direction that causes worst-case crosstalk delay or worst-
case crosstalk noise bump on a victim net. When logical correlation analysis is
turned off, PrimeTime SI results are expected to be slightly more pessimistic;
however, the PrimeTime SI runtime is faster.

To determine the current value of this variable, type one of the following:

printvar si_analysis_logical_correlation_mode

SEE ALSO
si_enable_analysis(3)

si_analysis_logical_correlation_mode
207
si_ccs_aggressor_alignment_mode
Specifies aggressor alignment mode used in the CCS-based gate-level simulation
engine.

TYPE

string

DEFAULT

lookahead

DESCRIPTION

Specifies aggressor alignment mode used in the CCS-based gate-level simulation

engine. Valid values include the default of lookahead and also stage. The default
value of lookahead enables the lookahead alignment feature for the CCS-based gate-
level simulation engine so that PrimeTime SI finds the alignment that results to
worst-case path delay. It is noted that such an alignment might not correspond to
worst-case stage delay. The lookahead alignment feature only applies to the CCS-
based gate-level simulation engine. Therefore, the si_ccs_use_gate_level_simulation
variable must be set to its default of true for the lookahead alignment mode to take
effect.

For complete information about the difference between worst-case stage alignment and
worst-case path alignment, see the PrimeTime SI User Guide.

To determine the current value of this variable, type the following:

printvar si_ccs_aggressor_alignment_mode

SEE ALSO
si_ccs_use_gate_level_simulation(3)

si_ccs_aggressor_alignment_mode
208
si_ccs_use_gate_level_simulation
Enables or disables the unified CCS timing and CCS noise engine for delay analysis.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When this variable is set to its default of true, the unified CCS timing and CCS
noise engine to be used in delay analysis is enabled. To use the unified CCS timing
and CCS noise engine, ensure this variable is set to its default of true and also
make sure that your library contains characterized CCS data.

For more information about the unified CCS timing and CCS noise feature, see the
PrimeTime SI User Guide.

To determine the current value of this variable, type the following:

printvar si_ccs_use_gate_level_simulation

SEE ALSO
report_timing(2)
update_timing(2)
si_ccs_aggressor_alignment_mode(3)

si_ccs_use_gate_level_simulation
209
si_enable_analysis
Enables or disables PrimeTime SI, which provides crosstalk analysis.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When true, enables PrimeTime SI, so that the crosstalk-aware timing calculation mode
is used by update_timing and report_timing. By default, PrimeTime SI is disabled;
this variable is set to false.

If you set this variable to true and enable PrimeTime SI, you must also do the
following:

1. Obtain a PrimeTime SI license. You cannot use PrimeTime SI without a license.

2. Use read_parasitics -keep_capacitive_coupling to read in the coupling parasitics

for your design. PrimeTime SI is useful only if the design has coupling parasitics
data.

For complete information about PrimeTime SI, see the PrimeTime SI User Guide.

To determine the current value of this variable, type printvar si_enable_analysis.

SEE ALSO
read_parasitics(2)
report_timing(2)
update_timing(2)

si_enable_analysis
210
si_filter_accum_aggr_noise_peak_ratio
Specifies the threshold for the accumulated voltage bumps introduced by aggressors
at a victim node, divided by VCC, below which aggressor nets can be filtered out
during electrical filtering.

TYPE

float

DEFAULT

0.03

DESCRIPTION

Specifies the threshold for the accumulated voltage bumps introduced by aggressors
at a victim node; the default is 0.03. PrimeTime SI uses the
si_filter_accum_aggr_noise_peak_ratio and si_filter_per_aggr_noise_peak_ratio
variables during the electrical filtering phase to determine whether an aggressor
net can be filtered.

An aggressor net, along with its coupling capacitors, is filtered when either of the
following are true:

1. The peak voltage of the voltage bump induced on the victim net divided by VCC is
less than the value specified with the si_filter_per_aggr_noise_peak_ratio variable.

2. The accumulated peak voltage of voltage bumps induced on the victim by aggressor
to the victim net divided by VCC is less than the value specified with the
si_filter_accum_aggr_noise_peak_ratio variable.

To determine the current value of this variable, type the following:

printvar si_filter_accum_aggr_noise_peak_ratio

SEE ALSO
si_analysis_effort_level(3)
si_enable_analysis(3)
si_filter_per_aggr_noise_peak_ratio(3)
si_xtalk_reselect_delta_delay(3)
si_xtalk_reselect_delta_delay_ratio(3)
si_xtalk_reselect_max_mode_slack(3)
si_xtalk_reselect_min_mode_slack(3)

si_filter_accum_aggr_noise_peak_ratio
211
si_filter_per_aggr_noise_peak_ratio
Specifies the threshold for the voltage bump introduced by an aggressor at a victim
node, divided by VCC, below which the aggressor net can be filtered out during
electrical filtering.

TYPE

float

DEFAULT

0.01

DESCRIPTION

Specifies the threshold for the voltage bump introduced by an aggressor at a victim
node; the default is 0.01. PrimeTime SI uses the si_filter_per_aggr_noise_peak_ratio
and si_filter_accum_aggr_noise_peak_ratio variables during the electrical filtering
phase to determine whether an aggressor net can be filtered.

An aggressor net, along with its coupling capacitors, is filtered when either of the
following are true:

1. The peak voltage of the voltage bump induced on the victim net divided by VCC is
less than the value specified with the si_filter_per_aggr_noise_peak_ratio variable.

2. The accumulated peak voltage of voltage bumps induced on the victim by aggressors
to the victim net divided by VCC is less than the value specified with the
si_filter_accum_aggr_noise_peak_ratio variable.

To determine the current value of this variable, type one of the following:

printvar si_filter_per_aggr_noise_peak_ratio.

SEE ALSO
si_analysis_effort_level(3)
si_enable_analysis(3)
si_filter_accum_aggr_noise_peak_ratio(3)
si_xtalk_reselect_delta_delay(3)
si_xtalk_reselect_delta_delay_ratio(3)
si_xtalk_reselect_max_mode_slack(3)
si_xtalk_reselect_min_mode_slack(3)

si_filter_per_aggr_noise_peak_ratio
212
si_filter_per_aggr_to_average_aggr_xcap_ratio
Specifies the minimum value of the ratio of the total cross-coupled capacitance
between the aggressor net and the victim net to the average cross-coupled
capacitance between the victim net and all of its aggressor nets, below which an
aggressor net can be filtered out during parasitic filtering.

TYPE

float

DEFAULT

0.0

DESCRIPTION

Note : This variable is in the proccess of obsoletion for version B-2008.12.

Specifies the threshold of the ratio of the total cross-coupled capacitance between
the aggressor net and the victim net to the average cross-coupled capacitance
between the victim net and all of its aggressor nets. This variable, along with the
si_filter_per_aggr_xcap and si_filter_per_aggr_xcap_to_gcap_ratio variables, make up
a set of three variables used by PrimeTime SI during the second stage of the
parasitic filtering phase, to determine whether an aggressor net can be filtered for
a particular victim net. If it meets all of the filtering criteria described in the
Filtering Criteria section, a net is filtered as an aggressor net for that
particular victim net. However, the aggressor net can still be considered as an
aggressor net to another victim net. Note that a coupling capacitor can be filtered
at one end and not at the other.

Filtering Criteria

The following text defines the filtering criteria.

Define the ground capacitance of each subnode of a victim V as:

Cg(V)[i]
where i = from 1 to Ng(V).

Then, the total ground capacitance of V is as:

Cg(V) = Cg(V)[1] + Cg(V)[2] + ... + Cg(V)[Ng(V)]

Further, define the coupling capacitors between a subnode of victim V and a subnode
of its aggressor j Aj as:

Cc(V, Aj)[k]
where j = from 1 to Na(V), and k = from 1 to Nc(V, Aj).

si_filter_per_aggr_to_average_aggr_xcap_ratio
213
Then, the total coupling capacitance between V and Aj can be written as:

Cc(V, Aj) = Cc(V, Aj)[1] + Cc(V, Aj)[2] + ... + Cc(V, Aj)[Nc(V, Aj)]

The total coupling capacitance of V to all its aggressors can be written as:

Cc(V) = Cc(V, A1) + Cc(V, A2) + ... + Cc(V, AK)

where K is Na(V).

All coupling capacitors of a given victim V from its aggressor Aj are filtered if
all of the following are true:

(1) Cc(V, Aj) is less than the value of si_filter_per_aggr_xcap.

(2) Cc(V, Aj)/(Cg(V)+Cc(V)) is less than the value of

si_filter_per_aggr_xcap_to_gcap_ratio.

(3) Cc(V, Aj)*Na(V)/Cc(V) is less than the value of

si_filter_per_aggr_to_average_aggr_xcap_ratio.

Note that you can disable this type of filtering by setting the
si_filter_per_aggr_xcap variable to zero. If an aggressor net does not meet the
above criteria, PrimeTime SI applies the next set of criteria to determine if any
remaining cross-coupling capacitors can be filtered. This next set of criteria is
controlled by the si_filter_single_xcap, si_filter_single_xcap_to_gcap_ratio, and
si_filter_single_average_aggr_xcap_ratio variables.

Previous criteria that is checked is controlled by the si_filter_total_aggr_xcap and

si_filter_total_aggr_xcap_to_gcap_ratio variables.

To determine the current value of this variable, type the following

printvar si_filter_per_aggr_to_average_aggr_xcap_ratio

SEE ALSO

si_enable_analysis (3), si_filter_per_aggr_xcap (3),

si_filter_per_aggr_xcap_to_gcap_ratio (3), si_filter_total_aggr_xcap (3),
si_filter_total_aggr_xcap_to_gcap_ratio (3).

si_filter_per_aggr_to_average_aggr_xcap_ratio
214
si_filter_per_aggr_xcap
Specifies the minimum value of the total cross-coupled capacitance between the
aggressor net and the victim net, below which an aggressor net can be filtered out
during parasitic filtering.

TYPE

float

DEFAULT

0.0

DESCRIPTION

Note : This variable is in the proccess of obsoletion in 2008.12.

Specifies the threshold, in library units, of the total cross-coupled capacitance

between the aggressor net and the victim net. This variable, along with
si_filter_per_aggr_xcap_to_gcap_ratio and
si_filter_per_aggr_to_average_aggr_xcap_ratio, makes up a set of three variables
used by PrimeTime-SI during the second stage of the parasitic filtering phase, to
determine whether an aggressor net can be filtered for a particular victim net. If
it meets all of the filtering criteria described in the section labeled "Filtering
Criteria", a net is filtered as an aggressor net for that particular victim net.
However, the aggressor net can still be considered as an aggressor net to another
victim net. Note that a coupling capacitor can be filtered at one end and not at the
other.

Filtering Criteria

The following text defines the filtering criteria.

Define the ground capacitance of each subnode of a victim V as:

Cg(V)[i]

where i = from 1 to Ng(V)

Then, the total ground capacitance of V is as follows:

Cg(V) = Cg(V)[1] + Cg(V)[2] + ..

si_filter_per_aggr_xcap
215
. + Cg(V)[Ng(V)]

Further, define the coupling capacitors between a subnode of victim V and a subnode
of its aggressor j Aj as:

Cc(V, Aj)[k]

where j = from 1 to Na(V), and k

= from 1 to Nc(V, Aj)

Then, the total coupling capacitance between V and Aj can be written as:

Cc(V, Aj) = Cc(V, Aj)[1] + Cc(V,

Aj)[2] + ... + Cc(V, Aj)[Nc(V, Aj)]

The total coupling capacitance of V to all its aggressors can be written as:

Cc(V) = Cc(V, A1) + Cc(V, A2) +

... + Cc(V, AK)

where K is Na(V)

All coupling capacitors of a given victim V from its aggressor Aj are filtered if
all of the following are true:

(1) Cc(V, Aj) is less than the value of the si_filter_per_aggr_xcap variable.

(2) Cc(V, Aj)/(Cg(V)+Cc(V)) is less than the value of the

si_filter_per_aggr_xcap_to_gcap_ratio variable.

(3) Cc(V, Aj)*Na(V)/Cc(V) is less than the value of the

si_filter_per_aggr_to_average_aggr_xcap_ratio variable.

Note that you can disable this type of filtering by setting the
si_filter_per_aggr_xcap variable to zero. If an aggressor net does not meet the
above criteria, PrimeTime-SI applies the next set of criteria to determine if any
remaining cross-coupling capacitors can be filtered.

To determine the current value of this variable, type the following:

si_filter_per_aggr_xcap
216
 printvar si_filter_per_aggr_xcap

SEE ALSO

si_enable_analysis (3), si_filter_per_aggr_to_average_aggr_xcap_ratio (3),

si_filter_per_aggr_xcap_to_gcap_ratio (3), si_filter_total_aggr_xcap (3),
si_filter_total_aggr_xcap_to_gcap_ratio (3).

si_filter_per_aggr_xcap
217
si_filter_per_aggr_xcap_to_gcap_ratio
Specifies the minimum value of the ratio of the total cross-coupled capacitance
between the aggressor net and the victim net to the total ground capacitance of the
victim net, below which an aggressor net can be filtered out during parasitic
filtering.

TYPE

float

DEFAULT

0.0

DESCRIPTION

Note : This variable is in the proccess of being obsoleted in version B-2008.12.

Specifies the threshold, in library units, of the ratio of the total cross-coupled
capacitance between the aggressor net and the victim net to the total ground
capacitance of the victim net. This variable, along with the si_filter_per_aggr_xcap
and si_filter_per_aggr_to_average_aggr_xcap_ratio variables, makes up a set of three
variables used by PrimeTime SI during the second stage of the parasitic filtering
phase, to determine whether an aggressor net can be filtered for a particular victim
net. If it meets all of the filtering criteria described in the section labeled
"Filtering Criteria", a net is filtered as an aggressor net for that particular
victim net. However, the aggressor net can still be considered as an aggressor net
to another victim net. Note that a coupling capacitor can be filtered at one end and
not at the other.

Filtering Criteria

The following text defines the filtering criteria.

Define the ground capacitance of each subnode of a victim V as

Cg(V)[i]

where i = from 1 to Ng(V

).

Then, the total ground capacitance of V is

si_filter_per_aggr_xcap_to_gcap_ratio
218
 Cg(V) = Cg(V)[1] + Cg(V)[2] + ..
. + Cg(V)[Ng(V)]

Further, define the coupling capacitors between a subnode of victim V and a subnode
of its aggressor j Aj as

Cc(V, Aj)[k]

where j = from 1 to Na(V), and k

= from 1 to Nc(V, Aj).

Then, the total coupling capacitance between V and Aj can be written as

Cc(V, Aj) = Cc(V, Aj)[1] + Cc(V,

Aj)[2] + ... + Cc(V, Aj)[Nc(V, Aj)]

The total coupling capacitance of V to all its aggressors can be written as

Cc(V) = Cc(V, A1) + Cc(V, A2) +

... + Cc(V, AK)

where K is Na(V)

All coupling capacitors of a given victim V from its aggressor Aj are filtered if
all of the following are true:

(1) Cc(V, Aj) is less than the value of si_filter_per_aggr_xcap.

(2) Cc(V, Aj)/(Cg(V)+Cc(V)) is less than the value of

si_filter_per_aggr_xcap_to_gcap_ratiofP.

(3) Cc(V, Aj)*Na(V)/Cc(V) is less than the value of si_filter_per_aggr_to_average_ag

gr_xcap_ratio.

Note that you can disable this type of filtering by setting si_filter_per_aggr_xcap
to zero. If an aggressor net does not meet the above criteria, PrimeTime-SI applies
the next set of criteria to determine if any remaining cross-coupling capacitors can
be filtered.

To determine the current value of this variable, type the following:

si_filter_per_aggr_xcap_to_gcap_ratio
219
 printvar si_filter_per_aggr_xcap_to_gcap_ratio

SEE ALSO

si_enable_analysis (3), si_filter_per_aggr_to_average_aggr_xcap_ratio(3),

si_filter_per_aggr_xcap (3), si_filter_total_aggr_xcap (3),
si_filter_total_aggr_xcap_to_gcap_ratio (3).

si_filter_per_aggr_xcap_to_gcap_ratio
220
si_filter_total_aggr_xcap
Specifies the minimum value of the total cross-coupled capacitance between the
victim net and all aggressor nets, below which a victim net can be filtered out
during parasitic filtering.

TYPE

float

DEFAULT

0.0

DESCRIPTION

Note : This variable is in the proccess of being obsoleted in version B-2008.12.

Specifies the threshold, in library units, of the total cross- coupled capacitance
between the victim net and all aggressor nets. This variable, along with
si_filter_total_aggr_xcap_to_gcap_ratio, makes up a pair of variables used by
PrimeTime SI during the first stage of the parasitic filtering phase, to determine
whether a victim net can be filtered. If it meets all of the filtering criteria
described in the section labeled "Filtering Criteria", a victim net is filtered.
However, the victim net can still be considered as an aggressor net. Note that a
coupling capacitor can be filtered at one end and not at the other.

Filtering Criteria

The following text defines the filtering criteria.

Define the ground capacitance of each subnode of a victim V as

Cg(V)[i]
where i = from 1 to Ng(V).

Then, the total ground capacitance of V is

Cg(V) = Cg(V)[1] + Cg(V)[2] + ... + Cg(V)[Ng(V)]

Further, define the coupling capacitors between a subnode of

victim V and a subnode of its aggressor j Aj as

Cc(V, Aj)[k]
where j = from 1 to Na(V), and k = from 1 to Nc(V, Aj).

Then, the total coupling capacitance between V and Aj can be written as

Cc(V, Aj) = Cc(V, Aj)[1] + Cc(V, Aj)[2] + ... + Cc(V, Aj)[Nc(V, Aj)]

si_filter_total_aggr_xcap
221
And, the total coupling capacitance of V to all its aggressors can be written as

Cc(V) = Cc(V, A1) + Cc(V, A2) + ... + Cc(V, AK)

where K = Na(V).

All coupling capacitors of a given victim V are filtered if both of the following
are true:

(1) Cc(V) is less than the value of si_filter_total_aggr_xcap.

(2) Cc(V)/(Cg(V)+Cc(V)) is less than the value of

si_filter_total_aggr_xcap_to_gcap_ratio.

Note that you can disable this type of filtering by setting

si_filter_total_aggr_xcap to zero. If a victim net does not meet the the above
criteria, PrimeTime SI applies the next set of criteria to determine whether any
aggressor nets can be filtered with respect to that victim net. This next set of
criteria is controlled by the variables si_filter_per_aggr_xcap,
si_filter_per_aggr_xcap_to_gcap_ratio, and
si_filter_per_aggr_to_average_aggr_xcap_ratio.

To determine the current value of this variable, type printvar

si_filter_total_aggr_xcap.

SEE ALSO

si_enable_analysis (3), si_filter_per_aggr_to_average_aggr_xcap_ratio (3),

si_filter_per_aggr_xcap (3), si_filter_per_aggr_xcap_to_gcap_ratio (3),
si_filter_total_aggr_xcap_to_gcap_ratio (3).

si_filter_total_aggr_xcap
222
si_filter_total_aggr_xcap_to_gcap_ratio
Specifies the minimum value of the ratio of total cross-coupled capacitance to the
total ground and cross-coupled capacitance, below which a victim net can be filtered
out during parasitic filtering.

TYPE

float

DEFAULT

0.0

DESCRIPTION

Note : This variable is in the proccess of being obsoleted in version B-2008.12.

Specifies the threshold of the ratio of total cross-coupled capacitance to the total
ground and cross-coupled capacitance of a victim net. This variable, along with
si_filter_total_aggr_xcap, makes up a pair of variables used by PrimeTime SI during
the first stage of the parasitic filtering phase, to determine whether a victim net
can be filtered. If it meets all of the filtering criterial described in the section
labeled "Filtering Criteria", a victim net is filtered. However, the victim net can
still be considered as an aggressor net. Note that a coupling capacitor can be
filtered at one end and not at the other.

Filtering Criteria

The following text defines the filtering criteria.

Define the ground capacitance of each subnode of a victim V as

Cg(V)[i]
where i = from 1 to Ng(V).

Then, the total ground capacitance of V is

Cg(V) = Cg(V)[1] + Cg(V)[2] + ... + Cg(V)[Ng(V)]

Further, define the coupling capacitors between a subnode of victim V and a subnode
of its aggressor j Aj as

Cc(V, Aj)[k]
where j = from 1 to Na(V), and k = from 1 to Nc(V, Aj).

Then, the total coupling capacitance between A and Vj can be written as

Cc(V, Aj) = Cc(V, Aj)[1] + Cc(V, Aj)[2] + ... + Cc(V, Aj)[Nc(V, Aj)]

si_filter_total_aggr_xcap_to_gcap_ratio
223
And, the total coupling capacitance of V to all its aggressors can be written as

Cc(V) = Cc(V, A1) + Cc(V, A2) + ... + Cc(V, AK)

where K = Na(V).

All coupling capacitors of a given victim V are filtered if both of the following
are true:

(1) Cc(V) is less than the value of si_filter_total_aggr_xcap.

(2) Cc(V)/(Cg(V)+Cc(V)) is less than the value of

si_filter_total_aggr_xcap_to_gcap_ratio.

Note that you can disable this type of filtering by setting

si_filter_total_aggr_xcap to zero. If a victim net does not meet the the above
criteria, PrimeTime SI applies the next set of criteria to determine whether any
aggressor nets can be filtered with respect to that victim net. This next set of
criteria is controlled by the variables si_filter_per_aggr_xcap,
si_filter_per_aggr_xcap_to_gcap_ratio, and
si_filter_per_aggr_to_average_aggr_xcap_ratio.

To determine the current value of this variable, type printvar

si_filter_total_aggr_xcap_to_gcap_ratio.

SEE ALSO

si_enable_analysis (3), si_filter_per_aggr_to_average_aggr_xcap_ratio (3),

si_filter_per_aggr_xcap (3), si_filter_per_aggr_xcap_to_gcap_ratio (3),
si_filter_total_aggr_xcap (3).

si_filter_total_aggr_xcap_to_gcap_ratio
224
si_ilm_keep_si_user_excluded_aggressors
Specifies whether or not to include user-excluded PrimeTime SI aggressors in the
interface logic model (ILM).

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Specifies whether or not to include the user-excluded PrimeTime SI aggressors in the

ILM. By default, aggressors that you exclude are not included in the ILM. You can
exclude aggressors by setting nets to be constant or by using the
set_si_delay_analysis or set_si_noise_analysis command.

To determine the current value of this variable, type one of the following:

printvar si_ilm_keep_si_user_excluded_aggressors

echo $si_ilm_keep_si_user_excluded_aggressors

SEE ALSO
create_ilm(2)

si_ilm_keep_si_user_excluded_aggressors
225
si_noise_check_show_user_driver
Enables or disables showing user noise driver setting for the check_noise command.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable controls how the check_noise command shows you the noise driver
setting. When this variable is set to its default of false, pins shown in the
"equivalent library pin" are included in other types based on the type of the
equivalent library pins set by the set_noise_lib_pin command, and pins shown in
"user resistance" are included in the "none" type.

If you set this variable to true, the check_noise command shows additional types,
"equivalent library pin" and "user resistance", while it is showing noise driver
type. In the "equivalent library pin" type, the number of pins that are set by the
set_noise_lib_pin command are shown. In the "user resistance" type, the number of
pins that are set by the set_steady_state_resistance command are shown.

If the -verbose option is specified in the check_noise command and you have set this
variable to true, pin names are also shown.

To determine the current value of this variable, type one of the following:

printvar si_noise_check_show_user_driver

echo $si_noise_check_show_user_driver

SEE ALSO
check_noise(2)
set_noise_lib_pin(2)
set_steady_state_resistance(2)

si_noise_check_show_user_driver
226
si_noise_composite_aggr_mode
Specifies the composite aggressor mode for noise analysis.

TYPE

string

DEFAULT

disabled

DESCRIPTION

This variable specifies which composite aggressor mode is used in PrimeTime SI noise
analysis. The following values are allowed for the variable:

• disabled, the default - Turns off the composite aggressor feature.

In disabled composite aggressor mode, PrimeTime SI uses its original flow with
composite aggressor completely off to analyze the noise.

• normal - Causes PrimeTime SI to calculate noise by using the nonstatistical

composite aggressor feature.

In normal composite aggressor mode, PrimeTime SI aggregates the effect of multiple

small aggressors into a single composite aggressor, thereby reducing the
computational complexity and improving the performance. Beginning with release
2012.06, the normal composite aggressor mode will no longer be available.

• statistical - Causes PrimeTime SI to calculate noise by using the statistical

composite aggressor flow.

In statistical composite aggressor mode, PrimeTime SI reduces the pessimism for

noise analysis by reducing the effect of composite aggressor.

To determine the current value of this variable, type the following:

printvar si_noise_composite_aggr_mode

SEE ALSO
report_noise_calculation(2)

si_noise_composite_aggr_mode
227
si_noise_effort_threshold_beyond_rails
Specifies the threshold for the noise bump height introduced by an aggressor at a
quiet victim node beyond power and ground rails, divided by Vcc, above which the
aggressor net will be analyzed by detailed noise calculation engine.

TYPE

float

DEFAULT

0.2

DESCRIPTION

Note : This variable is in the proccess of obsoletion in 2008.12.

Specifies the threshold for the noise bump voltage height introduced by an aggressor
at a quiet victim node beyond power and ground rails; the default is 0.2. This
variable, along with si_noise_effort_theshold_within_rails,
si_noise_total_effort_theshold_within_rails and
si_noise_total_effort_theshold_beyond_rails are the variables used by PrimeTime-SI
during the noise analysis phase, to determine whether an aggressor net should be
analyzed by detailed noise calculation engine.

An aggressor net, along with its coupling capacitors, is analyzed by detailed noise
calculation engine when the peak voltage of voltage bumps induced on the quiet
victim net beyond power and ground rails divided by Vcc is more than the value of
si_noise_effort_threshold_beyond_rails.

To determine the current value of this variable, type printvar

si_noise_effort_threshold_beyond_rails.

SEE ALSO

si_noise_effort_threshold_within_rails (3),
si_noise_total_effort_threshold_within_rails (3),
si_noise_total_effort_threshold_beyond_rails (3), set_noise_parameters (2).

si_noise_effort_threshold_beyond_rails
228
si_noise_effort_threshold_within_rails
Specifies the threshold for the noise bump height introduced by an aggressor at a
quiet victim node within power and ground rails, divided by Vcc, above which the
aggressor net will be analyzed by detailed noise calculation engine.

TYPE

float

DEFAULT

0.2

DESCRIPTION

Note : This variable is in the proccess of obsoletion in 2008.12.

Specifies the threshold for the noise bump voltage height introduced by an aggressor
at a quiet victim node within power and ground rails; the default is 0.2. This
variable, along with si_noise_effort_theshold_beyond_rails,
si_noise_total_effort_theshold_within_rails and
si_noise_total_effort_theshold_beyond_rails are the variables used by PrimeTime-SI
during the noise analysis phase, to determine whether an aggressor net should be
analyzed by detailed noise calculation engine.

An aggressor net, along with its coupling capacitors, is analyzed by detailed noise
calculation engine when the peak voltage of voltage bumps induced on the quiet
victim net within power and ground rails divided by Vcc is more than the value of
si_noise_effort_threshold_within_rails.

To determine the current value of this variable, type printvar

si_noise_effort_threshold_within_rails.

SEE ALSO

si_noise_effort_threshold_beyond_rails (3),
si_noise_total_effort_threshold_within_rails (3),
si_noise_total_effort_threshold_beyond_rails (3), set_noise_parameters (2).

si_noise_effort_threshold_within_rails
229
si_noise_endpoint_height_threshold_ratio
Specifies a value that defines the threshold where noise propagation stops. The
ratio is between 0.0 and 1.0 of VDD.

TYPE

float

DEFAULT

0.75

DESCRIPTION

This variable sets a threshold voltage for an endpoint. When the propagated noise
reaches this threshold voltage, noise propagation stops, and the load pin of the net
is recorded as an endpoint. This variable only impacts the report_at_endpoint
analysis mode of the noise update.

This variable applies only to combinational circuit pins because sequential cell
pins are automatically (noise) endpoints.

Suppose VDD is 1.0 V, and the variable is set to 0.75. In addition, suppose net N1
has a noise bump with the height of 0.8 V. Since the height of the noise bump is
greater than 0.75 V, net N1 is recorded as an endpoint.

Since N1 is an endpoint, there is no propagated noise at the next stage of net N1.

To determine the current value of this variable, type printvar

si_noise_endpoint_height_threshold_ratio or. echo
$si_noise_endpoint_height_threshold_ratio.

SEE ALSO

report_noise (2), report_noise_calculation (2), set_noise_parameters (2).

si_noise_endpoint_height_threshold_ratio
230
si_noise_immunity_default_height_ratio
Specifies a value that defines the noise immunity default height ratio. The ratio is
between 0.0 and 1.0 of VDD.

TYPE

float

DEFAULT

0.4

DESCRIPTION

This variable sets a noise immunity default value if a noise pin is not constrained.
If the noise pin has no data to compute noise immunity value, a default noise
immunity height is calculated by multiplying this variable and VDD of the pin.

If this variable is set to 1.0, the pin is not constrained any more, and no noise
slack will be calculated. The pins with no constraints will be reported as none in
check_noise.

To determine the current value of this variable, type printvar

si_noise_immunity_default_height_ratio or echo
$si_noise_immunity_default_height_ratio.

SEE ALSO

check_noise (2), check_noise (2), report_noise_calculation (2).

si_noise_immunity_default_height_ratio
231
si_noise_limit_propagation_ratio
This variable limits the amount of propagated noise if the noise height passes noise
immunity.

TYPE

float

DEFAULT

0.75

DESCRIPTION

During the noise update, if a noise passes the immunity criteria, then the
propagated height is reduced to a specified ratio of the noise immunity value. This
ratio is set by the variable si_noise_limit_propagation_ratio. This variable only
impacts the report_at_source analysis mode of the noise update. This variable has to
be between 0.0 and 1.0 and the default value is 0.75.

SEE ALSO

update_noise (2), set_noise_parameters (2).

si_noise_limit_propagation_ratio
232
si_noise_slack_skip_disabled_arcs
Controls whether to skip disabled timing arcs for noise slack calculation.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Controls whether to skip disabled timing arcs for noise slack calculation. The
allowed values for this variable are its default of false and true.

When this variable is set to its default of false, disabled timing arcs are ignored
and noise slacks are calculated for all available timing arcs. For example, if an
arc is disabled by the set_case_analysis or set_disable_timing command, no noise
slack is calculated for that arc by default. However, if the variable is set to its
default of false, the disabled timing arc is ignored and noise slack is calculated.

When you set this variable to true, noise slack is not calculated for disabled
timing arcs.

To determine the current value of this variable, type one of the following:

printvar si_noise_slack_skip_disabled_arcs

echo $si_noise_slack_skip_disabled_arcs

SEE ALSO
get_timing_arcs(2)
set_case_analysis(2)

si_noise_slack_skip_disabled_arcs
233
si_noise_total_effort_threshold_beyond_rails
Specifies the threshold for the summation of noise bump height introduced by all
aggressor at a quiet victim node beyond power and ground rails, divided by Vcc,
above which all aggressor nets will be analyzed by detailed noise calculation
engine.

TYPE

float

DEFAULT

10.0

DESCRIPTION

Note : This variable is in the proccess of obsoletion in 2008.12.

Specifies the threshold for the summation of noise bump voltage height introduced by
all aggressor at a quiet victim node beyond power and ground rails; The default is
10.0. This variable, along with si_noise_total_effort_theshold_within_rails,
si_noise_effort_theshold_within_rails and si_noise_effort_theshold_beyond_rails are
the variables used by PrimeTime-SI during the noise analysis phase, to determine
whether the aggressor nets should be analyzed by detailed noise calculation engine.

The aggressor nets, along with their coupling capacitors, are analyzed by detailed
noise calculation engine when the summation of peak voltage of voltage bumps induced
on the quiet victim net beyond power and ground rails divided by Vcc is more than
the value of si_noise_total_effort_threshold_beyond_rails.

To determine the current value of this variable, type printvar

si_noise_total_effort_threshold_beyond_rails.

SEE ALSO

si_noise_total_effort_threshold_within_rails (3),
si_noise_effort_threshold_within_rails (3), si_noise_effort_threshold_beyond_rails
(3), set_noise_parameters (2).

si_noise_total_effort_threshold_beyond_rails
234
si_noise_total_effort_threshold_within_rails
Specifies the threshold for the summation of noise bump height introduced by all
aggressor at a quiet victim node within power and ground rails, divided by Vcc,
above which all aggressor nets will be analyzed by detailed noise calculation
engine.

TYPE

float

DEFAULT

10.0

DESCRIPTION

Note : This variable is in the proccess of obsoletion in 2008.12.

Specifies the threshold for the summation of noise bump voltage height introduced by
all aggressor at a quiet victim node within power and ground rails; The default is
10.0. This variable, along with si_noise_total_effort_theshold_beyond_rails,
si_noise_effort_theshold_within_rails and si_noise_effort_theshold_beyond_rails are
the variables used by PrimeTime-SI during the noise analysis phase, to determine
whether the aggressor nets should be analyzed by detailed noise calculation engine.

The aggressor nets, along with their coupling capacitors, are analyzed by detailed
noise calculation engine when the summation of peak voltage of voltage bumps induced
on the quiet victim net within power and ground rails divided by Vcc is more than
the value of si_noise_total_effort_threshold_within_rails.

To determine the current value of this variable, type printvar

si_noise_total_effort_threshold_within_rails.

SEE ALSO

si_noise_total_effort_threshold_beyond_rails (3),
si_noise_effort_threshold_within_rails (3), si_noise_effort_threshold_beyond_rails
(3), set_noise_parameters (2).

si_noise_total_effort_threshold_within_rails
235
si_noise_update_status_level
Controls the number of progress messages displayed during the update of noise
analysis.

TYPE

string

DEFAULT

none

DESCRIPTION

Controls the number of progress messages displayed during the noise update process.
Allowed values are the default of none, low, or high.

When this variable is set to its default of none, no messages are displayed. When
you set this variable to low or high, the progress of the noise update is reported
for an explicit update (using the update_noise command) or for an implicit update
invoked by another command (for example, the report_noise command) that forces a
noise update.

When the variable is set to the following value, the number of messages displayed
varies:

• none - No messages are displayed.

• low - Messages are displayed only at the beginning and the end of the update.

• high - all messages for low are displayed, and messages for the noise calculation
step show the completion percentage in steps of 10 percents.

To determine the current value of this variable, type one of the following:

printvar si_noise_update_status_level

echo $si_noise_update_status_level

SEE ALSO
report_noise(2)
update_noise(2)

si_noise_update_status_level
236
si_use_driving_cell_derate_for_delta_delay
Allows crosstalk delta delay for one net to be derated using the relevant derate
factor for the cell driving that net.

TYPE

Boolean

DEFAULT

false

GROUP

si_variables

DESCRIPTION

When you set this variable to true, the crosstalk delta delays for each net is
derated using the derate factors from the cell driving that net.

The relevant derate factor to be applied adheres to the same precedence rules as the
driving cell itself. For example, if no instance-specific derate factor was set on
the driving cell then the hierarchical cell, the library cell, and finally the
global derate factors are checked for a relevant derate factor.

To see what derate factors are to be applied to the net in question, first obtain
the driving cell ($driving_cell) and use the following command:

pt_shell> report_timing_derate [get_cells $driving_cell]

If the report_timing command is invoked with the -derate option, the underated
crosstalk delta delay is reported jus as before. In addition the derate column
reports the net derate factor used to derate the delta-free net delay.

To determine the current value of this variable, type one of the following:

pt_shell> printvar si_use_driving_cell_derate_for_delta_delay

pt_shell> echo $si_use_driving_cell_derate_for_delta_delay

SEE ALSO
report_timing_derate(2)
report_timing(2)
set_timing_derate(2)

si_use_driving_cell_derate_for_delta_delay
237
si_xtalk_composite_aggr_mode
Specifies the composite aggressor mode for crosstalk delay.

TYPE

string

DEFAULT

disabled

DESCRIPTION

Specifies which composite aggressor mode is used in PrimeTime SI crosstalk delay

analysis. Allowed values are disabled (the default), which turns off the composite
aggressor feature. The normal value causes PrimeTime SI to calculate crosstalk delay
by using the non-statistical composite aggressor feature. Selecting the statistical
value causes PrimeTime SI to calculate crosstalk by using the statistical composite
aggressor flow.

In disabled composite aggressor mode, PrimeTime SI uses its original flow with
composite aggressor completely off to calculate the crosstalk delay.

In normal composite aggressor mode, PrimeTime SI aggregates the effect of some small
aggressors (including filtered ones) into a single composite aggressor, reducing the
computational complexity and improving the performance. Beginning with release
2012.06, the normal composite aggressor mode will no longer be available.

The statistical composite aggressor mode reduces the pessimism for crosstalk delay
analysis by reducing the effect of composite aggressor.

For the current value of this variable, type the following command:

printvar si_xtalk_composite_aggr_mode

SEE ALSO
printvar(2)
report_delay_calculation(2)
si_xtalk_composite_aggr_noise_peak_ratio(3)
si_xtalk_composite_aggr_quantile_high_pct(3)
remove_si_delay_disable_statistical(2)
set_si_delay_disable_statistical(2)
report_si_delay_analysis(2)

si_xtalk_composite_aggr_mode
238
si_xtalk_composite_aggr_noise_peak_ratio
Controls the composite aggressor selection for crosstalk analysis.

TYPE

float

DEFAULT

0.01

DESCRIPTION

Specifies the threshold value in crosstalk bump to VDD ratio, below which aggressors
are selected into composite aggressor group. The default value is 0.01, which means
all the aggressor nets with crosstalk bump to VDD ratio less than 0.01 is selected
into the composite aggressor group. This variable works together with other
filtering thresholds, si_filter_per_aggr_noise_peak_ratio and
si_filter_accum_aggr_noise_peak_ratio, to determine which aggressors can be selected
into composite aggressor group.

To determine the current value of this variable, type the following command:

printvar si_xtalk_composite_aggr_noise_peak_ratio

SEE ALSO
si_xtalk_composite_aggr_mode(3)
si_filter_per_aggr_noise_peak_ratio(3)
si_filter_accum_aggr_noise_peak_ratio(3)
si_xtalk_composite_aggr_quantile_high_pct(3)
remove_si_delay_disable_statistical(2)
set_si_delay_disable_statistical(2)
report_si_delay_analysis(2)

si_xtalk_composite_aggr_noise_peak_ratio
239
si_xtalk_composite_aggr_quantile_high_pct
Controls the composite aggressor creation for statistical analysis.

TYPE

float

DEFAULT

99.73

DESCRIPTION

Sets the desired probability in percentage format that any given real combined bump
height is less than or equal to the computed composite aggressor bump height. Given
the desired probability, the resulting quantile value for the composite aggressor
bump height is calculated.

The default value of this variable is 99.73, which corresponds to a 3-sigma

probability that the real bump height from any randomly-chosen combination of
aggressors is covered by the composite aggressor bump height.

To determine the current value of this variable, type the following command:

printvar si_xtalk_composite_aggr_quantile_high_pct

SEE ALSO
si_xtalk_composite_aggr_mode(3)
si_xtalk_composite_aggr_noise_peak_ratio(3)
remove_si_delay_disable_statistical(2)
set_si_delay_disable_statistical(2)
report_si_delay_analysis(2)

si_xtalk_composite_aggr_quantile_high_pct
240
si_xtalk_delay_analysis_mode
Specifies the arrival window alignment mode for crosstalk delay.

TYPE

String

DEFAULT

all_paths

DESCRIPTION

This variable specifies how the alignment between victim & aggressors is performed
in crosstalk delay analysis PrimeTime SI. Allowed values are all_paths (the
default), which causes PrimeTime SI to calculate crosstalk for all paths through the
victim net, worst_path, which causes PrimeTime SI to calculate crosstalk for all the
worst paths (the earliest/latest path) through the victim net, and
all_violating_paths, which causes PrimeTime SI to calculate crosstalk for all worst
paths and paths with negative slack.

In the all_paths alignment mode, PrimeTime SI considers the largest possible

crosstalk delta delay for the given victim & aggressor arrival windows. This
gurantees that all paths going through the victim net with different arrival times
are conservative. This is the default and traditional way PTSI calculates delta
delay. The limitation of this approach is that the worst crosstalk delta delay is
applied to all paths, including the worst path, which causes slack of the design to
be pessimistic. When the path based analysis is done on a path using report_timing -
pba_mode, the above pessimism is removed for the specific path. However, it is too
expensive to do path based analysis analysis on all the paths of the design.

In the worst_path alignment mode, PrimeTime SI aligns aggressors for the the
earliest/latest paths on the victim, such that only crosstalk affecting the worst
path is considered. Hence, only the crosstalk effect that makes the slowest
(fastest) path any slower (faster) is calculated. If the worst path is a false path,
the true path is considered. Considering the worst path instead of all paths
typically generates smaller delta delays, and the worst paths and design slack
become less pessimistic. This approach makes sure that design slack & worst path are
conservative.

There is a caveat to the worst_path alignment mode: the crosstalk delay is

applicable to the worst path only, so the sub-critical path delay may be inaccurate.
The side effect of this limitation is that report_timing -nworst N, N>1 could report
paths with optimistic slacks. Also, report_constraint -all_violators -max_delay -
min_delay will report less number of violations than really exist in the design.
Moreover, as violating critical paths are fixed, the optimistic sub-critical paths
will become critical and violating. Bottleneck commands like
report_timing_bottleneck and report_si_bottleneck will also be less effective.

For some design flows the sub-critical path optimism is less of an issue if the
design meets the timing constraints, i.e., all endpoints in the design show positive

si_xtalk_delay_analysis_mode
241
slacks. However, when the design has not met the timing yet, getting conservative
crosstalk deltas for all the violating paths (whose slack is negative) is essential
for the fixing flow. The alignment mode all_violating_paths addresses this by
aligning the aggressors for all the violating and the worst path through any pin in
the design. This means that all paths with negative slacks and all the critical
paths through any pin in the design (even if the slack for that worst path is
positive) are analyzed conservatively. This mode may show more pessimism on worst
paths than the worst_path mode along with a slightly higher runtime than the
worst_path mode.

To reduce pessimism further, in the new modes worst_path and all_violating_paths,

another feature is enabled, where in a separate delay calculation is performed for
each clock in the clock network. This is usefull when multiple clocks in the clock
network are propagated to the clock selection muxes.

When the delay analysis mode is set to all_violating_paths or worst_path,

distributed multi-core analysis results may be slightly different (generally less
conservative) compared to single-core analysis due to the nature of design
partitioning. In these modes, the variable
timing_ideal_clock_zero_default_transition assumes its default value and setting it
to any other value has no effect.

For the current value of this variable, type printvar si_xtalk_delay_analysis_mode.

SEE ALSO

printvar (2), si_enable_analysis (2), report_timing (3),

timing_ideal_clock_zero_default_transition (3).

si_xtalk_delay_analysis_mode
242
si_xtalk_double_switching_mode
Controls the double switching detection during the PrimeTime SI timing analysis.

TYPE

string

DEFAULT

disabled

DESCRIPTION

Double switching detection mode can have one of these three values, disabled,
clock_network, or full_design. When the si_xtalk_double_switching_mode variable is
set to its default of disabled, double switching detection is disabled. When you set
this variable to either clock_network or full_design, during the update_timing,
PrimeTime SI checks whether crosstalk bump on the switching victim could cause the
output to switch twice (and cause a pulse) instead of the desired single signal
propagation.

To detect the potential double switching in the clock network, which could cause the
double clocking (where the clock could switch twice on a the sensitive edge) or
false clocking (where the switching bump on the nonsensitive edge could actually
latch the state), set this value to clock_network.

To detect the potential double switching in the data path as well as clock path set
this variable to full_design. Double switching on a data path is less severe then
double switching on the clock network.

The double switching detection needs CCSN library information on the victim load
cell.

After the update_timing command, you can access this information by using the
report_si_double_switching command or by the net attributes by using the
si_has_double_switching and si_double_switching_slack commands.

For the command details, see the report_si_double_switching man page. The victim net
attribute, si_has_double_switching, is true whenever there is a potential double
switching on any of the load pins.

The victim net attribute, si_double_switching_slack, has the bump slack, reducing
the switching bump by that much amount could remove the double switching. If the
victim net does not cause double switching the si_double_switching_slack attribute
is "POSITIVE". If the victim net load pins does not have CCS noise model
information, the attribute is reported as "INIFINITY".

The victim nets having the double switching is automatically reselected to higher
iteration so that they could be reanalyzed with more accurate analysis.

The double switching happens when, the switching bump and transition time are large

si_xtalk_double_switching_mode
243
and fed into drivers that are strong enough to amplify this. To avoid double
switching, either of them can be reduced.

SEE ALSO
si_enable_analysis(3)
report_si_double_switching(3)

si_xtalk_double_switching_mode
244
si_xtalk_exit_on_max_iteration_count
Specifies a maximum number of incremental timing iterations, after which PrimeTime
SI exits the analysis loop.

TYPE

integer

DEFAULT

DESCRIPTION

Specifies a maximum number of incremental timing iterations. PrimeTime SI exits the

analysis loop after performing this number of iterations.

The default value of this variable is 2, meaning that PrimeTime SI exits the
analysis loop after performing two iterations. You can override this default by
setting the variable to another integer; the minimum allowed value is 1.

You can also manually exit the analysis loop by pressing Ctrl+C to send an interrupt
signal to the PrimeTime process. The interrupt is handled as the above exit
criteria, at the end of the current iteration of the crosstalk analysis. You cannot
interrupt iteration immediately without exiting PrimeTime.

To determine the current value of this variable, type the following command:

printvar si_xtalk_exit_on_max_iteration_count

si_xtalk_exit_on_max_iteration_count
245
si_xtalk_exit_on_max_iteration_count_incr
Specifies a maximum number of timing iterations following what-if change (such as
size_cell) to the design, after which PrimeTime SI exits the analysis loop.

TYPE

integer

DEFAULT

DESCRIPTION

update_timing for signal integrity (SI) is done in an iterative way. The number of
iterations is controlled by the si_xtalk_exit_on_max_iteration_count variable. The
si_xtalk_exit_on_max_iteration_count_incr variable has the same function but is used
when update_timing can be done incrementally. Incremental SI timing is only done
after minor changes, such as size_cell, insert_buffer, set_coupling_separation.
Large number of changes or any other change result in full_update_timing.

This variable will be obsoleted and removed from future releases of PrimeTime
starting with 2012.06.

SEE ALSO
si_xtalk_exit_on_max_iteration_count(3)

si_xtalk_exit_on_max_iteration_count_incr
246
si_xtalk_reselect_clock_network
Determines whether or not PrimeTime SI reselects clock network nets for subsequent
delay calculations.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When set to the default value of true, PrimeTime SI reselects nets in the clock
network for the next iteration of delay calculations. It can be enabled with the
following other reselection variables:

si_xtalk_reselect_delta_delay
si_xtalk_reselect_delta_delay_ratio
si_xtalk_reselect_max_mode_slack
si_xtalk_reselect_min_mode_slack

This variable will be obsoleted and removed from future releases of PrimeTime
starting with 2012.06.

To determine the current value of this variable, type the following command:

printvar si_xtalk_reselect_clock_network

SEE ALSO
si_xtalk_reselect_max_mode_slack(3)
si_xtalk_reselect_min_mode_slack(3)
si_xtalk_reselect_delta_delay(3)
si_xtalk_reselect_delta_delay_ratio(3)

si_xtalk_reselect_clock_network
247
si_xtalk_reselect_delta_delay
Specifies the threshold of net delay change caused by crosstalk analysis, above
which PrimeTime SI reselects the net for subsequent delay calculations.

TYPE

float

DEFAULT

1000000

DESCRIPTION

This variable specifies a reselection threshold in terms of absolute delta delay.

Nets that have at least one net arc with a crosstalk-annotated delta delay above
this threshold are selected for the next iteration of PrimeTime SI delay
calculations. Note that delta delays are annotated on net arcs, but they capture the
change of stage delay (cell plus net) because of crosstalk. Default value for this
variable is set to 1000000 which basically makes the default behavior independent of
library unit. This default setting disables this type of reselection.

This variable is one of a set of four variables that determine net reselection
criteria. The other variables are as follows:

si_xtalk_reselect_delta_delay_ratio
si_xtalk_reselect_max_mode_slack
si_xtalk_reselect_min_mode_slack

To determine the current value of this variable, type the following:

printvar si_xtalk_reselect_delta_delay

SEE ALSO
si_xtalk_reselect_delta_delay_ratio(3)
si_xtalk_reselect_max_mode_slack(3)
si_xtalk_reselect_min_mode_slack(3)

si_xtalk_reselect_delta_delay
248
si_xtalk_reselect_delta_delay_ratio
Specifies the threshold of the ratio of net delay change caused by crosstalk
analysis to the total stage delay, above which PrimeTime SI reselects a net for
subsequent delay calculations.

TYPE

float

DEFAULT

1000000

DESCRIPTION

Specifies a reselection threshold in terms of the delta delay ratio. Nets that have
at least one net arc with a crosstalk-annotated delta delay, where the ratio of the
annotated delta to the stage delay is above this threshold, are selected for the
next iteration of PrimeTime SI delay calculations.

If a net has multiple stage delays (because of a net fanout greater than one or
multiple cell arcs), PrimeTime SI considers the stage delta delay and stage delay
that result in higher delta to stage delay ratio, thus making reselection
conservative.

This variable is one of a set of four variables that determine net reselection
criteria. The other three variables are as follows:

si_xtalk_reselect_delta_delay
si_xtalk_reselect_max_mode_slack
si_xtalk_reselect_min_mode_slack

This variable will be obsoleted and removed from future releases of PrimeTime
starting with 2012.06.

To determine the current value of this variable, type the following command:

printvar si_xtalk_reselect_delta_delay_ratio

SEE ALSO
si_xtalk_reselect_delta_delay(3)
si_xtalk_reselect_max_mode_slack(3)
si_xtalk_reselect_min_mode_slack(3)

si_xtalk_reselect_delta_delay_ratio
249
si_xtalk_reselect_max_mode_slack
Specifies the max mode pin slack threshold, below which PrimeTime SI reselects a net
for subsequent delay calculations.

TYPE

float

DEFAULT

DESCRIPTION

Specifies the pin slack threshold in the maximum mode. Nets that have at least one
pin with a maximum mode slack below this threshold are selected for the next
iteration of PrimeTime SI delay calculations. Maximum mode pin slack is the slack of
the worst maximum mode (setup) path through the pin.

This variable is one of a set of four variables that determine net reselection
criteria. The other variables are:

si_xtalk_reselect_delta_delay
si_xtalk_reselect_delta_delay_ratio
si_xtalk_reselect_min_mode_slack

To determine the current value of this variable, type the following command:

printvar si_xtalk_reselect_max_mode_slack

SEE ALSO
si_xtalk_reselect_delta_delay(3)
si_xtalk_reselect_delta_delay_ratio(3)
si_xtalk_reselect_min_mode_slack(3)

si_xtalk_reselect_max_mode_slack
250
si_xtalk_reselect_min_mode_slack
Specifies the min mode pin slack threshold, below which PrimeTime SI reselects a net
for subsequent delay calculations.

TYPE

float

DEFAULT

DESCRIPTION

Specifies the pin slack threshold in the min mode. Nets that have at least one pin
with a min mode slack below this threshold are selected for the next iteration of
PrimeTime SI delay calculations. Min mode pin slack is the slack of the worst min
mode (hold) path through the pin.

This variable is one of a set of four variables that determine net reselection
criteria. The other three variables are:

si_xtalk_reselect_delta_delay
si_xtalk_reselect_delta_delay_ratio
si_xtalk_reselect_max_mode_slack

To determine the current value of this variable, type the following command:

printvar si_xtalk_reselect_min_mode_slack

SEE ALSO
si_xtalk_reselect_delta_delay(3)
si_xtalk_reselect_delta_delay_ratio(3)
si_xtalk_reselect_max_mode_slack(3)

si_xtalk_reselect_min_mode_slack
251
si_xtalk_reselect_time_borrowing_path
Determines whether or not PrimeTime SI reselects time borrowing path nets for
subsequent delay calculations.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Determines whether or not PrimeTime SI reselects time borrowing path nets for
subsequent delay calculations. When set to true, PrimeTime SI reselects time
borrowing path nets for the next iteration. It can be enabled with slack based
reselection. It reselects only coupled nets that are not filtered, as with other
reselection criteria. This variable is useful for designs that contain level-
sensitive latches.

For slack based reselection, PrimeTime SI reselects all nets that directly or
indirectly borrow time from nets that are reselected based on the
si_xtalk_reselect_max_mode_slack and si_xtalk_reselect_min_mode_slack variables.
This includes level-sensitive latch loops.

When set to false, reselection based on borrowing is disabled.

This variable will be obsoleted and removed from future releases of PrimeTime
starting with 2012.06.

To determine the current value of this variable, type the following command:

printvar si_xtalk_reselect_time_borrowing_path

SEE ALSO
si_xtalk_reselect_delta_delay(3)
si_xtalk_reselect_delta_delay_ratio(3)
si_xtalk_reselect_max_mode_slack(3)
si_xtalk_reselect_min_mode_slack(3)

si_xtalk_reselect_time_borrowing_path
252
svr_enable_vpp
Enables or disables preprocessing of Verilog files by the Verilog preprocessor.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Used only by the native Verilog reader. When set to true, before the Verilog reader
reads a Verilog file, the Verilog preprocessor scans for and expands the Verilog
preprocessor directives ‘define, ‘undef, ‘include, ‘ifdef, ‘else, and ‘endif.
Intermediate files from the preprocessor are created in the directory referenced by
the pt_tmp_dir variable. Also, the ‘include directive uses the search_path variable
to find files.

Very few structural Verilog files use preprocessor directives. Set this variable to
true only if your Verilog file contains directives that require the preprocessor.
Without the preprocessor, the native Verilog reader does not recognize these
directives.
To determine the current value of this variable, type one of the following commands:

printvar svr_enable_vpp

echo $svr_enable_vpp

SEE ALSO
printvar(2)
read_verilog(2)
pt_tmp_dir(3)
search_path(3)

svr_enable_vpp
253
svr_keep_unconnected_nets
Used only by the native Verilog reader to preserve or discard unconnected nets.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

This variable is used only by the native Verilog reader. When set to true (the
default), unconnected nets are preserved. When set to false, unconnected nets are
discarded.

To determine the current value of this variable, type one of the following commands:

printvar svr_keep_unconnected_nets

echo $svr_keep_unconnected_nets

SEE ALSO
printvar(2)
read_verilog(2)

svr_keep_unconnected_nets
254
timing_all_clocks_propagated
Determines whether or not all clocks are created as propagated clocks.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, all clocks subsequently created by the create_clock or

create_generated_clock commands are created as propagated clocks. When set to false
(the default), clocks are created as nonpropagated clocks.

By default, the create_clock and create_generated_clock commands create only

nonpropagated clocks. You can subsequently define some or all clocks to be
propagated clocks using the set_propagated_clock command. However, if you set the
timing_all_clocks_propagated variable to true, the create_clock and
create_generated_clock commands subsequently create only propagated clocks. Setting
this variable to true or false affects only clocks created after the setting is
changed. Clocks created before the setting is changed retain their original
condition (propagated or nonpropagated).

To determine the current value of this variable, type one of the following commands:

printvar timing_all_clocks_propagated

echo $timing_all_clocks_propagated

SEE ALSO
create_clock(2)
create_generated_clock(2)
printvar(2)
set_propagated_clock(2)

timing_all_clocks_propagated
255
timing_allow_short_path_borrowing
Enables time borrowing through level sensitive latches for hold time checks.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Affects time borrowing for short paths (used for hold checks) at a level-sensitive
latch. By default, PrimeTime performs time borrowing only for long paths (used for
setup checks).

The default model is a conservative model for short paths. It is valid even during
power-up transient state.

An aggressive model is to allow borrowing for short paths. It is valid only during
steady state.

Enable borrowing for short paths by setting the timing_allow_short_path_borrowing

variable to true.

To determine the current value of this variable, type the following command:

printvar timing_allow_short_path_borrowing

SEE ALSO
report_timing(2)
set_max_time_borrow(2)

timing_allow_short_path_borrowing
256
timing_aocvm_analysis_mode
Configure an advanced on-chip variation (advanced OCV) analysis.

TYPE

string

DEFAULT

""

GROUP

timing_variables

DESCRIPTION

When this variable is set to "", the default advanced OCV analysis is performed. The
default analysis is defined as follows:

Depth is used to index the random component of variation in an advanced OCV derate
table. Depth is defined as the number of cell (or net) delay timing arcs in a path
from the path common point. Separate depth values are calculated for cells and nets.
Separate depth values are calculated for launch and capture paths. Both clock and
data networks objects are included in the depth computation. Random coefficients
affect the depth computation. For more information, see the set_aocvm_coefficient
man page.

Distance is used to index the systematic component of variation in an advanced OCV

derate table. Distance is defined as the length of the diagonal of the bounding box
enclosing the cell (or net) delay timing arcs in a path from the path common point.
Separate bounding boxes and distance values are calculated for cells and nets. Both
clock and data networks objects are included in the bounding box. The cell at the
path endpoint is included in the cell bounding box. Only nodes and terminals of the
network along the net arc are included in the net bounding box.

The timing_aocvm_analysis_mode variable is used to configure an advanced OCV

analysis. Choose from the following analysis modes, which can all be combined except
for the combined_launch_capture_depth and separate_data_and_clock_metrics modes.
Only one of these two modes can be specified due to their inherently contradictory
flows.

• clock_network_only

• combined_launch_capture_depth

• separate_data_and_clock_metrics

• single_path_metrics

timing_aocvm_analysis_mode
257
To configure an advanced OCV analysis, specify the analysis modes required in the
timing_aocvm_analysis_mode variable. For example,

pt_shell> set timing_aocvm_analysis_mode "clock_network_only"

To determine the current value of this variable, enter the following command:

pt_shell> printvar timing_aocvm_analysis_mode

The effect that of each of the advanced OCV analysis modes has on the default
analysis is described below in detail:

clock_network_only

When this option is not specified (default), advanced OCV derating is applied
throughout the design and constant (OCV) derating is ignored.

When this option is specified, advanced OCV derating is applied to arc delays in the
clock network only. Clock network advanced OCV depth and distance metrics are
calculated based on clock network topology only. The data network receives constant
(OCV) derating, if constant derates have been annotated for data network objects;
otherwise they are not derated.

In the clock_network_only delay timing arcs in the data network are excluded from
depth and distance calculations. The cell at the path endpoint is still included in
the cell bounding box.

combined_launch_capture_depth In this mode, launch and capture depths are not

calculated separately. The launch and capture paths are considered together and a
combined depth is calculated for the entire path. This option cannot be specified
together with the separate_data_and_clock_metrics mode.

separate_data_and_clock_metrics In this mode, separate depths are computed for the

clock and data paths and the appropriate advanced OCV derates based on the separate
depths are used for derating delays. This option cannot be specified together with
the combined_launch_capture_depth mode.

single_path_metrics In this mode, a single set of path metrics is calculated for

both cell and net objects. Separate path metrics are not calculated for cells and
nets in a path. This behavior is backwardly compatible with the legacy Tcl-based
"LOCV" solution.

Distance is measured by computing the diagonal of a bounding box around all of the
cells in a path. Ports in the path and the common point are also included. This
distance is used to lookup the systematic component of variation for both cells and
nets.

Depth is measured considering only the cells in a path. This depth is used to lookup

timing_aocvm_analysis_mode
258
the random component of variation for both cells and nets.

SEE ALSO
set_aocvm_coefficient(2)
read_aocvm(2)
remove_aocvm(2)
report_aocvm(2)
get_timing_paths(2)
report_timing(2)

timing_aocvm_analysis_mode
259
timing_aocvm_enable_analysis
Enable the graph-based advanced on-chip variation (advanced OCV) analysis in
PrimeTime.

TYPE

Boolean

DEFAULT

false

GROUP

timing_variables

DESCRIPTION

When this variable is set to its default of false, the graph-based advanced OCV
timing update is not performed. A path-based advanced OCV analysis can be performed
in this mode using the -pba_mode option of the report_timing and get_timing_paths
commands. In this mode, constant timing derates specified using the
set_timing_derate command are required to pessimistically bound the analysis. You
should specify constant derates that do not clip the range of the path-based
advanced OCV derates to avoid optimism.

When you set this variable to true, the graph-based advanced OCV timing update is
performed as part of the update_timing command. A path-based advanced OCV analysis
can also be performed in this mode. In this mode, constant timing derates are not
required and, in fact, constant derates for static delays are ignored. Graph-based
advanced OCV derates computed during the update_timing command tightly bound the
path-based advanced OCV derates without clipping their range. Note that setting this
variable to true automatically switch the design into on_chip_variation analysis
mode using the set_operating_conditions command.

SEE ALSO
set_operating_conditions(2)
read_aocvm(2)
report_aocvm(2)
get_timing_paths(2)
report_timing(2)

timing_aocvm_enable_analysis
260
timing_aocvm_ocv_precedence_compatibility
Control the fallback to on-chip variation (OCV) derates when advanced OCV is
enabled.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When this variable is set to true (default), the OCV derates are completely ignored
for AOCV analysis. However when this variable is set to false, for a given object
both OCV and AOCV derates are considered and then the one with higher order of
specificity is used. Where the default order of specificity in decreasing priority
order for both path and graph based analysis is:

i. OCV leaf cell derate

ii. AOCV lib-cell derate
iii. OCV lib-cell derate
iv. AOCV hier-cell derate
v. OCV hier-cell derate
vi. AOCV design derate
vii. OCV design derate

This variable controls the derates for both cell delays and net delays. Path based
OCV derate set using pba_derate_list is not supported for AOCV analysis. The AOCV
guardband derate will be used only if the AOCV derate factor is used for an object.
This variable is effective only when timing_aocvm_enable_analysis is set to true.

To determine the current value of this variable, enter the following command:

pt_shell> timing_aocvm_ocv_precedence_compatibility

SEE ALSO
set_timing_derate(2)
timing_aocvm_enable_analysis(3)

timing_aocvm_ocv_precedence_compatibility
261
timing_bidirectional_pin_max_transition_checks
Determines the extent of max transition design rule checks on bidirectional pins.

TYPE

String

DEFAULT

both

DESCRIPTION

Determines the extent of a max transition design rule check for bidirectional pins.
The variable can be one of three values: both (the default), driver, and load. The
both value specifies the driver and load to be checked, while the driver value only
specifies the driver and the load only specifies the load.

To determine the current value of this variable, type the following command:

printvar timing_bidirectional_pin_max_transition_checks

timing_bidirectional_pin_max_transition_checks
262
timing_calculation_across_broken_hierarchy_compatibility
Control whether delay calculation ignores hierarchical pins where clock constraints
are specified when performing detailed RC calculation.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When false, PrimeTime computes the interconnect delay from leaf pin to leaf pin,
ignoring any intervening hierarchical pins where clock constraints are defined. When
true, the calculation engine would revert to attempt to use the hierarchical pin
during calculation.

Previously, PrimeTime would attempt to calculate interconnect delays to hierarchical

pins where clock constraints are specified by individually computing the delays from
and to the segments leading to and from the pin in question. When parasitics are
annotated to the interconnect, the detailed RC engine would fail to find such delays
reverting to a lumped model calculation. The latter behavior could introduce a
significant amount of pessimism into the delay results. So, the tool warns about
such instances recommending the moving of the constraint to a corresponding leaf
pin. However, it is understood that sometimes the latter correction may be difficult
and would cause a discontinuity in the user’s top-level to block-level clock
specifiers. So, a new behavior is implemented to always ignore hierarchies in this
case for delay calculation and backannotate the corresponding interconnect delays
into arcs from and to the hierarchical boundary.

It is important to note that since this behavior change impacts clock skews, it may
cause a significant change in timing results. These results are less pessimistic.

To determine the current value of this variable, type printvar

timing_calculation_across_broken_hierarchy_compatibility.

SEE ALSO

printvar (2), create_generated_clock (2), create_clock (2), report_delay_calculation

(2).

timing_calculation_across_broken_hierarchy_compatibility
263
timing_check_defaults
Defines the default checks for the check_timing command.

TYPE

list

DEFAULT

generated_clocks generic latch_fanout loops no_clock no_input_delay

partial_input_delay unconstrained_endpoints unexpandable_clocks no_driving_cell
pulse_clock_non_pulse_clock_merge pll_configuration

GROUP

timing_variables

DESCRIPTION

Defines the default checks to be performed when the check_timing command is executed
without any options. The same default checks are also performed if the check_timing
command is used with the -include or -exclude option. The default check list defined
by this variable can be overriden by either redefining it before the check_timing
command is executed or using the -override_defaults option of the check_timing
command.

If an undefined check is specified while redefining this variable, a warning is

issued by the next execution of the check_timing command.

SEE ALSO
check_timing(2)

timing_check_defaults
264
timing_clock_gating_check_fanout_compatibility
Controls whether the effects of the set_clock_gating_check command propagates
through logic, or applies only to the specified design object.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable controls the behavior of the set_clock_gating_check command when it is

applied to design netlist objects (ports, pins or cells).

When this variable is set to false, PrimeTime uses the current behavior where the
effects of the set_clock_gating_check command apply only to the specified design
objects, and do not propagate through the transitive fanout. When this behavior is
enabled, specifying the command on a port has no effect. This behavior is consistent
with Design Compiler and IC Compiler.

To apply the clock gating settings to an entire clock domain without enumerating all
gating cells, clock objects can be provided to the set_clock_gating_check command.
When clock objects are provided, the clock gating settings apply to all instances of
clock gating for those clocks.

When this variable is set to true, PrimeTime uses the behavior from older versions
where the set_clock_gating_check command also applies to the transitive fanout of
the specified design objects. There is no way to configure only the specified design
objects without also propagating the clock gating settings to downstream logic.

To determine the current value of this variable, enter the following command:

pt_shell> printvar timing_clock_gating_check_fanout_compatibility

SEE ALSO
set_clock_gating_check(2)

timing_clock_gating_check_fanout_compatibility
265
timing_clock_gating_propagate_enable
Allows the gating enable signal delay to propagate through the gating cell.

TYPE

int

DEFAULT

true

DESCRIPTION

When set to true (the default), PrimeTime allows the delay and slew from the data
line of the gating check to propagate. When set to false, PrimeTime blocks the delay
and slew from the data line of the gating check from propagating. Only the delay and
slew from the clock line is propagated.

If the output goes to a clock pin of a latch, setting this variable to false
produces the most desirable behavior.

If the output goes to a data pin, setting this variable to true produces the most
desirable behavior.

To determine the current value of this variable, type printvar

timing_clock_gating_propagate_enable or echo $timing_clock_gating_propagate_enable.

SEE ALSO

timing_clock_gating_propagate_enable
266
timing_clock_reconvergence_pessimism
Selects signal transition sense matching for computing clock reconvergence pessimism
removal.

TYPE

string

DEFAULT

normal

DESCRIPTION

Determines how the value of the clock reconvergence pessimism removal (CRPR) is
computed with respect to transition sense. Allowed values are normal (the default)
and same_transition.

When set to normal, the CRPR value is computed even if the clock transitions to the
source and destination latches are in different directions on the common clock path.
It is computed separately for rise and fall transitions and the value with smaller
absolute value is used.

When set to same_transition, the CRPR value is computed only when the clock
transition to the source and destination latches have a common path and the
transition is in the same direction on each pin of the common path. If the source
and destination latches are triggered by different edge types, CRPR is computed at
the last common pin at which the launch and capture edges match.

If the variable is set to same_transition,the CRPR for all min pulse width checks is
zero as they are calculated using different clock edges (for example, rise and
fall).

To determine the current value of this variable, type one of the following commands:

printvar timing_clock_reconvergence_pessimism

echo $timing_clock_reconvergence_pessimism

SEE ALSO
report_timing(2)
get_timing_path(2)
timing_remove_clock_reconvergence_pessimism(3)

timing_clock_reconvergence_pessimism
267
timing_crpr_enable_adaptive_engine
Enables or disables the adaptive clock reconvergence pessimism removal (CRPR)
engine.

TYPE

Boolean

DEFAULT

false

GROUP

timing_variables

DESCRIPTION

When you set this variable to true, the adaptive CRPR engine is turned on. The
adaptive CRPR engine can significantly improve the performance and capacity of a
timing update with PrimeTime SI enabled across multiple iterations. To enable
PrimeTime SI, set the si_enable_analysis variable to true.

The performance and capacity gain is achieved by only calculating CRP for the
violating portion of the design thus reducing the complexity of the CRPR analysis.

This variable is only applicable for PrimeTime SI analysis and when the maximum
iteration count using the si_xtalk_exit_on_max_iteration_count variable is set to 2
or greater. If neither of the previous two conditions are true, PrimeTime reverts to
using the standard CRP calculation method. Two PrimeTime SI iterations are required
because adaptive CRPR requires two interations to perform its analysis as opposed to
standard CRPR, which only requires one PrimeTime SI iteration.

Note: You might see differences in PrimeTime SI delta delays and slack values
between adaptive and standard CRPR. This is because PrimeTime SI net reselection is
dependent on slack values, which are dependent on CRPR. Since adaptive only
calculates CRP during the second iteration slack-based net reselection during the
first iteration is not CRPR-aware. The result of this is that more nets are
reselected after the first PrimeTime SI if adaptive CRPR is enabled. Since more nets
are reselected after the first iteration, a more accurate PrimeTime SI analysis
(that is, less pessimistic) can be expected.

If you want to compare standard and adaptive CRPR, the best approach is to ’force’
the reselection of all nets using the set_si_delay_analysis command. You can then
compare slacks between both runs.

To determine the current value of the variable, use the following command:

pt_shell> printvar timing_crpr_enable_adaptive_engine

timing_crpr_enable_adaptive_engine
268
SEE ALSO
set_si_delay_analysis(2)
update_timing(2)
si_enable_analysis(3)
si_xtalk_exit_on_max_iteration_count(3)
timing_crpr_threshold_ps(3)
timing_remove_clock_reconvergence_pessimism(3)

timing_crpr_enable_adaptive_engine
269
timing_crpr_minimize_grouping
Enables or disables the aggressive grouping during CRPR calculations..

TYPE

Boolean

DEFAULT

False

GROUP

timing_variables

DESCRIPTION

When set to TRUE, this variable reduces the amount of grouping performed during CRPR
calculations. This is done to maximize the computed value of clock reconvergence
pessimism. Setting this variable to TRUE can result in significant memory overhead
as PT would not perform some optimizations during CRPR calculations. It should only
be turned ON only if the difference in CRP value reported by report_timing and
report_crpr differs by more than the CRPR threshold.

Use the following command to determine the current value of the variable:

prompt> printvar timing_crpr_minimize_grouping

SEE ALSO
update_timing (2),
timing_crpr_threshold_ps (3),
timing_remove_clock_reconvergence_pessimism (3).

timing_crpr_minimize_grouping
270
timing_crpr_remove_clock_to_data_crp
Allows the removal of Clock Reconvergence Pessimism (CRP) from paths that fan out
directly from clock source to the data pins of sequential devices.

TYPE

boolean

DEFAULT

FALSE

DESCRIPTION

When this variable is set to true then CRP will be removed for all paths that fan
out directly from clock source pins to the data pins of sequential devices.

When this variable is set to false, only the CRP up to the clock source pin which
fans out to the data pin of the sequential device would be removed. This is because
the path up to a clock source pin is considered to be a clock path. Consider the
following example, where GCLK1 as a generated clock with CLK as its master clock. In
this case, the CRP between pins A and B would removed irrespective of the value of
the variable. However, when the variable is set to true, additional CRP between pins
B and C would also be removed.

+-- buff3 (D) --- FF1/D

|
A (CLK) --- buff1 (B GCLK1) --- buff2 (C) --- |-- buff4 (E) --- FF1/CP

It should be noted that when this variable is set to true all

sequential devices that reside in the fanout of clock source pins must
be handled seperately in the subsequent timing update. This may cause
a severe performance degradation to the timing update.

pt_shell> echo $timing_crpr_remove_clock_to_data_crp

or
pt_shell> printvar timing_crpr_remove_clock_to_data_crp

SEE ALSO

timing_remove_clock_reconvergence_pessimism (3).

timing_crpr_remove_clock_to_data_crp
271
timing_crpr_remove_muxed_clock_crp
Allow CRPR to consider common path reconvergence between related clocks.

TYPE

Boolean

DEFAULT

TRUE

GROUP

timing_variables

DESCRIPTION

This variable controls the CRPR in cases where two related clocks reconverge in the
logic. Two clocks are related if one is a generated clock and the other is its
parent, or both are generated clocks of the same parent clock. Although this
variable name refers specifically to multiplexers, the variable applies to any
situation where two related clocks reconverge within combinational logic.

If this variable is set to TRUE then the separate clock paths up to the multiplexer
are treated as reconvergent, and the CRP will include the reconvergence point as
well as any downstream common logic. If this variable is set to FALSE then the
common pin will be the last point where the clocks diverged to become related
clocks.

If the design contains related clocks which switch dynamically (a timing path
launches from one related clock and the clock steering logic switches dynamically so
the path captures on the other related clock), then this variable should be set to
false so the CRP is not removed.

The default value is true, which removes the additional CRP.

To determine the value of this variable use:

prompt> printvar timing_crpr_remove_muxed_clock_crp

SEE ALSO
timing_remove_clock_reconvergence_pessimism (3).

timing_crpr_remove_muxed_clock_crp
272
timing_crpr_threshold_ps
Specifies amount of pessimism that clock reconvergence pessimism removal (CRPR) is
allowed to leave in the report.

TYPE

float

DEFAULT

20

DESCRIPTION

Specifies amount of pessimism that clock reconvergence pessimism removal (CRPR) is

allowed to leave in the report. The unit is in pico seconds (ps), regardless of the
units of the main library.

The threshold is per reported slack: setting the this variable to the TH1 value
means that reported slack is no worse than S - TH1, where S is the reported slack
when timing_crpr_threshold_ps is set close to zero (the minimum allowed value is 5
picosecond).

The variable has no effect if CRPR is not active

(timing_remove_clock_reconvergence_pessimism is false). The larger the value of
timing_crpr_threshold_ps, the faster the runtime when CRPR is active. The
recommended setting is about one half of the stage (gate plus net) delay of a
typical stage in the clock network. It provides a reasonable trade-off between
accuracy and runtime in most cases. You may want to use different settings
throughout the design cycle: larger during the design phase, smaller for sign-off.
You might have to experiment and set a different value when moving to a different
technology.

To determine the current value of this variable, type printvar

timing_crpr_threshold_ps.

SEE ALSO

timing_remove_clock_reconvergence_pessimism (3).

timing_crpr_threshold_ps
273
timing_disable_bus_contention_check
Disables checking for timing violations resulting from transient contention on
design busses.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Applies only to bus designs that have multiple three-state drivers.

When set to false (the default), PrimeTime reports these timing violations. When set
to true, PrimeTime ignores timing setup and hold (max and min) violations that occur
as a result of transient bus contention.

Bus contention occurs when more than one driver is enabled at the same time. By
default, PrimeTime treats the bus as if it is in an unknown state during this region
of contention, and reports a timing violation if the setup and hold regions extend
into the contention region. Note that checking is done only for timing violations
and not for logical and excessive power dissipation violations, which are outside
the scope of static timing analysis tools.

Set this variable to true only if you are certain that transient bus contention
regions never occur. By setting the value to true, you guarantee that on a multi-
driven three-state bus, the drivers in the previous clock cycle are disabled before
the drivers in the current clock cycle are enabled. If you set this variable to
true, you must ensure that the timing_disable_bus_contention_check variable is
false. The timing_disable_bus_contention_check and timing_disable_floating_bus_check
variables cannot both be true at the same time.

During the switching between the high-impedance (Z) state and the high/low state,
the timing behavior (for example, intrinsic delay) of three-state buffers is
captured in the Synopsys library using the three_state_disable and
three_state_enable timing arc types. These timing arcs connect the enable pin to the
output pin of the three-state buffers. For details, see the Library Compiler
Reference Manual.

To determine the current value of this variable, type one of the following commands:

printvar timing_disable_bus_contention_checks

echo $timing_disable_bus_contention_checks

SEE ALSO
timing_disable_floating_bus_check(3)

timing_disable_bus_contention_check
274
timing_disable_clock_gating_checks
Disables checking for setup and hold clock gating violations.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to false (the default), PrimeTime automatically determines clock-gating and
performs clock-gating setup and hold checks. When set to true, PrimeTime disables
clock-gating setup and hold checks.

To determine the current value of this variable, type one of the following commands:

printvar timing_disable_clock_gating_checks

echo $timing_disable_clock_gating_checks

SEE ALSO
report_constraint(2)
set_clock_gating_check(2)

timing_disable_clock_gating_checks
275
timing_disable_cond_default_arcs
Disables the default, nonconditional timing arc between pins that have conditional
arcs.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, disables nonconditional timing arcs between any pair of pins that
have at least one conditional arc. When set to false (the default), these
nonconditional timing arcs are not disabled. This variable is primarily intended to
deal with the situation between two pins that have conditional arcs, where there is
always a default timing arc with no condition.

Set this variable to true when the specified conditions cover all possible state-
dependent delays, so that the default arc is useless. For example, consider a 2-
input XOR gate with inputs as A and B and with output as Z. If the delays between A
and Z are specified with 2 arcs with respective conditions ’B’ and ’B~", the default
arc between A and Z is useless and should be disabled.

To determine the current value of this variable, type one of the following commands:

printvar timing_disable_cond_default_arcs

echo $timing_disable_cond_default_arcs

SEE ALSO
report_disable_timing(2)

timing_disable_cond_default_arcs
276
timing_disable_floating_bus_check
Disables checking for timing violations resulting from transient floating design
buses.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Applies only to bus designs that have multiple three-state drivers. When set to
true, PrimeTime ignores timing setup and hold (max and min) violations that occur as
a result of transient floating buses. When set to false (the default), PrimeTime
reports these timing violations.

Floating bus condition occurs when no driver controls the bus at a given time. By
default, PrimeTime treats the bus as if it is in an unknown state during this region
of contention, and reports a timing violation if the setup and hold regions extend
into the floating region. Note that checking is done only for timing violations, and
not for logical violations, which are outside the scope of static timing analysis
tools.

Set this value to true only if you are certain that transient floating bus regions
never occur. By setting the value to true, you guarantee that on a multi-driven
three-state bus, the drivers in the previous clock cycle are disabled before the new
drivers in the current clock cycle are enabled. If you set this variable to true,
you must ensure that the timing_disable_bus_contention_check variable is false. The
timing_disable_floating_bus_check and timing_disable_bus_contention_check variables
cannot both be true at the same time.

During the switching between the high-impedance (Z) state and the high/low state,
the timing behavior (for example, intrinsic delay) of three-state buffers is
captured in the Synopsys library using the three_state_disable and
three_state_enable timing arc types. These timing arcs connect the enable pin to the
output pin of the three-state buffers. For details, see the Library Compiler
Reference Manual.

To determine the current value of this variable, type one of the following commands:

printvar timing_disable_floating_bus_check

echo $timing_disable_floating_bus_check

SEE ALSO
timing_disable_bus_contention_check(3)

timing_disable_floating_bus_check
277
timing_disable_internal_inout_cell_paths
Enables bidirectional feedback paths within a cell.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When set to true (the default), PrimeTime automatically disables bidirectional

feedback paths in a cell. When set to false, bidirectional feedback paths in cells
are enabled.

This variable has no effect on timing of bidirectional feedback paths that involve
more than one cell (that is, if nets are involved); these feedback paths are
controlled by the timing_disable_internal_inout_net_arcs variable.

To determine the current value of this variable, type one of the following commands:

printvar timing_disable_internal_inout_cell_paths

echo $timing_disable_internal_inout_cell_paths

SEE ALSO
remove_disable_timing(2)
report_timing(2)
set_disable_timing(2)
timing_disable_internal_inout_net_arcs(3)

timing_disable_internal_inout_cell_paths
278
timing_disable_internal_inout_net_arcs
Controls whether bidirectional feedback paths across nets are disabled or not.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

When set to true (the default), PrimeTime automatically disables bidirectional

feedback paths that involve more than one cell; no path segmentation is required.
Note that only the feedback net arc between non-bidirectional driver and load is
disabled. When set to false, these bidirectional feedback paths are enabled.

This variable has no effect on timing of bidirectional feedback paths that are
completely contained in one cell (that is, if nets are not involved); these feedback
paths are controlled by the timing_disable_internal_inout_cell_paths variable.

To determine the current value of this variable, type one of the following commands:

printvar timing_disable_internal_inout_net_arcs

echo $timing_disable_internal_inout_net_arcs

SEE ALSO
remove_disable_timing(2)
report_timing(2)
set_disable_timing(2)
timing_disable_internal_inout_cell_paths(3)

timing_disable_internal_inout_net_arcs
279
timing_disable_recovery_removal_checks
Disables or enables the timing analysis of recovery and removal checks in the
design.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, disables recovery and removal timing analysis. When set to false
(the default), PrimeTime performs recovery and removal checks. For a description of
these checks, see the man page for the report_constraint command.

To determine the current value of this variable, type one of the following commands:

printvar timing_disable_recovery_removal_checks

echo $timing_disable_recovery_removal_checks

SEE ALSO
report_constraint(2)

timing_disable_recovery_removal_checks
280
timing_dynamic_loop_breaking
Enables or disables the dynamic breaking of combinational feedback loops.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, enables dynamic loop breaking. When set to false (the default),
dynamic loop breaking is disabled.

By default, PrimeTime handles loops by identifying the loop and disabling one of the
timing arcs of the loop. In some cases, this approach can result in some real paths
not being reported in PrimeTime because they are broken by the disabled arcs used to
break loops. Enabling dynamic loop breaking guarantees that no timing arc is
disabled to break a loop and that all valid paths of the design are reported.

If the design or the search space for the report_timing command is large, or if the
loops are complex, setting this variable may increase the run time (or memory) for
the report_timing command significantly.

To determine the current value of this variable, type the following command:

printvar timing_dynamic_loop_breaking

SEE ALSO
printvar(2)
report_timing(2)

timing_dynamic_loop_breaking
281
timing_early_launch_at_borrowing_latches
Removes clock latency pessimism from the launch times for paths which begin at the
data pins of transparent latches.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

In the following description we assume that the data paths of interest are setup
paths since we refer specifically to time borrowing scenarios. However, if
timing_allow_short_path_borrowing is enabled then the same discussion applies to
borrowing hold paths too.

When a latch is in its transparent phase, data arriving at the D-pin passes through
the element as though it were combinational. To model this scenario, whenever
PrimeTime determines that time borrowing occurs at such a D-pin, paths which
originate at the D-pin are created.

Sometimes there is a difference between the launching and capturing latch latencies,
due either to reconvergent paths in the clock network or different min and max
delays of cells in the clock network. For setup paths, PrimeTime uses the late value
to launch and the early value to capture. This achieves the tightest constraint and
avoids optimism. However, for paths starting from latch D-pins this is pessimistic
since data simply passes through and thus does not even "see" the clock edge at the
latch.

When this timing variable is set to true (the default), such pessimism is eliminated
by using the early latch latency to launch such paths. Note that only paths which
originate from a latch D-pin are affected. When the variable is set to false, late
clock latency is used to launch all setup paths in the design.

It is recommended that the user avail of this form of pessimism removal since it
does not cause the run-time of the analysis to increase. However, it is also advised
that the user disable it when clock reconvergence pessimism removal (CRPR) is
enabled (i.e. when timing_remove_clock_reconvergence_pessimism is true). CRPR may
not be applied to paths which have been launched using an early latency or the
results may be optimistic. Since CRPR is a more sophisticated and accurate means of
pessimism removal, the user should disable timing_early_launch_at_borrowing_latches
when CRPR is enabled so that CRPR applies to all paths in the design. In this mode,
note that the D-pin launch time is not modified by the open edge CRP - since late
launch latency is used at the path startpoint, to additionally add CRP would be
pessimistic, representing a "double-counting" of early-late differences.

To determine the current value of this variable, type printvar

timing_early_launch_at_borrowing_latches or echo

timing_early_launch_at_borrowing_latches
282
$timing_early_launch_at_borrowing_latches.

SEE ALSO

printvar (2), report_timing (2), timing_remove_clock_reconvergence_pessimism (3),

timing_allow_short_path_borrowing (3).

timing_early_launch_at_borrowing_latches
283
timing_enable_clock_propagation_through_preset_clear
Enables propagation of clock signals through preset and clear pins

TYPE

Boolean

DEFAULT

false

GROUP

Timing variables

DESCRIPTION

When this variable is set to true, clock signals propagates through the preset and
clear pins of a sequential device. Naturally, this only occurs when clock signals
are incident on such pins.

If CRPR is enabled, it considers any sequential devices in the fanout of such pins
for analysis.

To determine the current value of this variable, type the following command:

prompt> printvar timing_enable_clock_propagation_through_preset_clear

SEE ALSO
timing_remove_clock_reconvergence_pessimism(2)

timing_enable_clock_propagation_through_preset_clear
284
timing_enable_clock_propagation_through_three_state_enable_pins
Allows the clocks to propagate through the enable pin of a three-state cell.

TYPE

int

DEFAULT

false

DESCRIPTION

When set to true, PrimeTime allows the clocks to propagate through the enable pins
of tristates. When set to false (the default), PrimeTime does not propagate clocks
between a pair of pins if there is at least one timing arc with a disable sense
between those pins.

To determine the current value of this variable, type one of the following commands:

printvar timing_enable_clock_propagation_through_three_state_enable_pins

echo $timing_enable_clock_propagation_through_three_state_enable_pins

timing_enable_clock_propagation_through_three_state_enable_pins
285
timing_enable_cross_voltage_domain_analysis
Enables reduced-pessimism analysis of timing paths that cross multiple voltage
domains.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Set this variable to true to enable reduced-pessimism analysis of the timing paths
that cross multiple voltage domains. Standard on-chip variation analysis leads to
pessimistic results for cross-domain paths because it can consider the behavior of
different cells operating at both the high voltage and low voltage within a given
domain at the same time. After single-domain path violations are found and fixed
using standard on-chip variation analysis, you can analyze just the cross-domain
paths and reduce the pessimism of the results by setting this variable set to true.

When this variable is set to true, the update_timing command identifies paths that
traverse multiple voltage domains and subsequently limits the reporting to only
those paths. If a path-based analysis is performed by using the -pba_mode path
option of the report_timing command, PrimeTime performs an efficient path-based
recalculation of the cross-domain paths. This analysis finds the worst-case voltage
for each domain crossed by each path, but eliminates the pessimism that occurs in
standard on-chip variation analysis.

If you do not have any reliable characterization information with respect to voltage
variation, you can use derating to analyze the impact of different supply voltages.
The set_cross_voltage_domain_analysis_guardband command sets derating factors that
apply whenever the timing_enable_cross_voltage_domain_analysis variable is set to
true.

SEE ALSO
set_cross_voltage_domain_analysis_guardband(2)
report_timing(2)
update_timing(2)

timing_enable_cross_voltage_domain_analysis
286
timing_enable_max_capacitance_set_case_analysis
Specifies that max capacitance constraint is checked on constant pins.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable determines if max capacitance constraint is checked for constant pins.
The variable can be one of two values: true or false. The default value is false.
The value true specifies that the max capacitance is checked for constant pins.

For the current value of this variable, type the following command:

printvar timing_enable_max_capacitance_set_case_analysis

SEE ALSO
printvar(2)
report_constraint -max_capacitance(2)

timing_enable_max_capacitance_set_case_analysis
287
timing_enable_preset_clear_arcs
Controls whether PrimeTime enables or disables preset and clear arcs.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, this variable permanently enables asynchronous preset and clear
timing arcs, so that you use them to analyze timing paths. When set to false (the
default), PrimeTime disables all preset and clear timing arcs.

Note that if there are any minimum pulse width checks defined on asynchronous preset
and clear pins, they are performed regardless of the value of this variable. Also
note the -true and -justify options of the report_timing command cannot be used
unless this variable is at its default value.

To determine the current value of this variable, type the following command:

printvar timing_enable_preset_clear_arcs

SEE ALSO
printvar(2)
report_timing(2)

timing_enable_preset_clear_arcs
288
timing_enable_pulse_clock_constraints
Enables checking of pulse clock constraints.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

This variable determines if pulse clock constraints are checked or not. The variable
can be one of two values: true or false. The value of true specifies that the pulse
clock constraints set by the set_pulse_clock_min_width, set_pulse_clock_max_width,
set_pulse_clock_min_transition, and set_pulse_clock_max_transition commands are
checked. When this variable is set to true, the min pulse width constraints set by
the set_min_pulse_width command do not apply to pulse clock networks and more
specific pulse clock constraints checked.

For the current value of this variable, type the following command:

printvar timing_enable_pulse_clock_constraints

SEE ALSO
printvar(2)
report_constraint -pulse_clock_min_width(2)
report_constraint -pulse_clock_max_width(2)
report_constraint -pulse_clock_min_transition(2)
report_constraint -pulse_clock_max_transition(2)
set_pulse_clock_min_width(2)
set_pulse_clock_max_width(2)
set_pulse_clock_min_transition(2)
set_pulse_clock_max_transition(2)
report_pulse_clock_min_width(2)
report_pulse_clock_max_width(2)
report_pulse_clock_min_transition(2)
report_pulse_clock_max_transition(2)

timing_enable_pulse_clock_constraints
289
timing_gclock_source_network_num_master_registers
The maximum number of register clock pins clocked by the master clock allowed in
generated clock source latency paths.

TYPE

int

DEFAULT

10000000

DESCRIPTION

This variable allows you to control the maximum number of register clock pins
clocked by the master clock allowed in generated clock source latency paths. The
variable does not effect the number of register traversed in a single path that do
not have a clock assigned or are clocked by another generated clock that has the
same primary master as the generated clock in question.

Register clock pins or transparent-D pins of registers clocked by unrelated clocks

are not traversed in determining generated clock source latency paths. An unrelated
clock is any clock that the primary master clock differs from the generated clock
when source latency paths are being computed.

To determine the current value of this variable, type one of the following commands:

printvar timing_gclock_source_network_num_master_registers

echo $timing_gclock_source_network_num_master_registers

timing_gclock_source_network_num_master_registers
290
timing_ideal_clock_zero_default_transition
Specifies whether or not a zero transition value is assumed for sequential devices
clocked by ideal clocks.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Specifies a transition value to use at clock pins of a flip-flop. If

set_clock_transition command is used and the clock is ideal, the transition value
will be used. This variable has no effect. If the clock transition is not set by
set_clock_transition command, and the clock is ideal, then this variable will have
the following effect. When true (the default), PrimeTime uses a zero transition
value for ideal clocks. When false, PrimeTime uses a propagated transition value.
Note that set_clock_transition will override the effect of this variable, when clock
is ideal.

Note that this behavior differs from previous behavior, where PrimeTime used a
propagated transition value for an ideal clock, but zero delay values at the clock
pins.

In PrimeTime SI, when setting the si_xtalk_delay_analysis_mode to either

all_violating_paths or worst_path, this variable assumes its default value (true)
and setting it to any other value has no effect.

To determine the current value of this variable, type printvar

timing_ideal_clock_zero_default_transition or echo
$timing_ideal_clock_zero_default_transition.

SEE ALSO
report_delay_calculation(2)
set_clock_transition(2)
si_xtalk_delay_analysis_mode(3)

timing_ideal_clock_zero_default_transition
291
timing_include_available_borrow_in_slack
Determines whether or not PrimeTime includes available borrow time in slack.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to false (the default), the slack of a signal arriving before the latch
opening edge is measured relative to the open edge and does not include available
borrow time. A signal arriving during the transparent interval is considered to have
a slack of zero. Violations are measured with respect to the closing latch edge.

When set to true, any path terminating at the data pin of a transparent latch will
have positive or negative slack measured with respect to the closing transition at
the latch. That is, available borrow time is considered a component of slack.
Available borrow time is typically the duration of the active clock region minus the
setup time required. A maximum time borrow set on a latch could decrease this
available borrow time.

To determine the current value of this variable, type one of the following commands:

printvar timing_include_available_borrow_in_slack

echo $timing_include_available_borrow_in_slack

SEE ALSO
printvar(2)
set_max_time_borrow(2)
report_timing(2)

timing_include_available_borrow_in_slack
292
timing_input_port_default_clock
Determines whether a default clock is assumed at input ports for which the user has
not defined a clock with set_input_delay.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This Boolean variable affects the behavior of PrimeTime when you set an input delay
without a clock on an input port. When set to true (the non-default value), the
input delay on the port is set with respect to one imaginary clock so that the
inputs are constrained. This also causes the clocks along the paths driven by these
input ports to become related. Also, the period of this clock is equal to the base
period of all these related clocks. When set to false, no such imaginary clock is
assumed.

To determine the current value of this variable, type the following command:

printvar timing_input_port_default_clock

SEE ALSO
set_input_delay(2)

timing_input_port_default_clock
293
timing_keep_loop_breaking_disabled_arcs
Determines whether to keep .db inherited disabled timing arcs for static loop
breaking.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When true, enables inheriting of .db disabled timing arcs for loop breaking. When
false (the default), do not accept .db disabled timing arcs for loop breaking.

If the .db inheritied disabled timing arcs do not break all of the loops, the
default static loop breaking technique breaks the loops unless the dynamic loop
breaking technique is enabled.

The .db inherited disabled timing arcs may be removed individually without affecting
the other .db inheritied disabled timing arcs.

There is a difference between Design Compiler and PrimeTime where additional

set_case_analysis or set_disable_timing commands do not remove .db inherited
disabled timing arcs.

For this variable to take effect, you must set it before link is performed. If you
set this variable after link, it has no effect.

To remove .db inherited arcs after they are accepted, they may be removed using the
remove_disable_timing command because they are user defined.

A boolean attribute is_db_inherited_disabled has been added to the class

timing_arcs, where true indicates an arc is a db inherited disabled arc.

To remove all .db inherited disable timing arcs for loop breaking, issue command
remove_disable_timing [get_timing_arcs -of [get_cell *] -filter
"is_db_inherited_disabled == true"]

To determine the current value of this variable, type printvar

timing_keep_loop_breaking_disabled_arcs.

SEE ALSO

printvar (2), report_disable_timing (2), remove_disable_timing (2).

timing_keep_loop_breaking_disabled_arcs
294
timing_port_clock_and_data_compatibility
Disable or enable the simultaneous behavior of input port as clock and data port.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, the set_input_delay command has the behavior defined in PrimeTime
version B-2008.12. When set to false (the default), the set_input_delay command has
the behavior defined in PrimeTime version C-2009.06 and subsequent versions.

Previously, the set_input_delay command could also set a clock source latency at a
clock port, if the ports has data sinks; the input delay could also be set only
relative to clocks defined at the port. Beginning with version C-2009.06, the
set_input_delay command can be issued at a clock port, relative to clocks defined at
any other port. Furthermore, the set_input_delay command no longer sets clock source
latency.

To determine the current value of this variable, type the following command:

printvar timing_port_clock_and_data_compatibility

SEE ALSO
printvar(2)
set_input_delay(2)
set_clock_latency(2)

timing_port_clock_and_data_compatibility
295
timing_prelayout_scaling
Enables scaling of delay and transition times in pre-layout flow to approximate
effects of mismatching driver and load signal levels.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

Enables scaling of delay and transition times in pre-layout flow to approximate

effects of mismatching driver and load signal levels. When this variable is set to
true (the default value), then in pre-layout flow (without detailed parasitics)
delay and transition times along net arcs are scaled to describe the same physical
waveform using local trippoints and voltage level on the load cell.

No scaling is done for post-layout flow since PrimeTime measures delays on analog
waveforms.

This variable is intended for obtaining backward compatibility with releases prior
to 2002.09.

To determine the current value of this variable, use printvar

timing_prelayout_scaling.

SEE ALSO

report_delay_calculation (2);

timing_prelayout_scaling
296
timing_propagate_interclock_uncertainty
Enables or disables the propagation of interclock uncertainty through transparent
latches in PrimeTime.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When false (the default), the interclock uncertainty is calculated for each latch-
to-latch path independently, from the clock at the launch latch to the clock at the
capture latch, even when latches operate in transparent mode.

When true, clock uncertainty information is propagated through each latch operating
in transparent mode, as though it were a combinational element. This allows an
entire sequence of latch-to-latch stages to be considered a single path for
interclock uncertainty calculation, provided that time borrowing occurs at the
endpoint of each intermediate stage.

Operating with this variable set to true can lead to more accurate results for
designs containing transparent latches, at the cost of some CPU time and memory
resources. To illustrate, consider a pipeline containing latches A, B, and C,
clocked by clocks 1, 2, and 3, respectively. PrimeTime treats the paths between A
and B and between B and C as distinct. In reality, however, if latch B is in
transparent mode, data passes through it as though it were a combinational element.
Regardless of whether interclock uncertainty has been applied between clocks 1 and
3, the default behavior is to apply the uncertainty between clocks 2 and 3 when
calculating slack at latch C. It is more accurate, however, to apply the uncertainty
between the clock at the path startpoint (clock 1, latch A) and the clock at the
path endpoint (clock 3, latch C), if defined.

With timing_propagate_interclock_uncertainty set to true, the correct interclock

uncertainty is applied, as though the path from latch A to latch C through the
transparent latch B were a single, extended path. That is, the uncertainty is
propagated through the transparent latch. To find out the startpoint of this
extended path, use report_timing -trace_latch_borrow.

To determine the current value of this variable, type printvar

timing_propagate_interclock_uncertainty or echo
$timing_propagate_interclock_uncertainty.

SEE ALSO

printvar (2), set_clock_uncertainty (2), report_timing (2).

timing_propagate_interclock_uncertainty
297
timing_propagate_through_non_latch_d_pin_arcs
Always propagate cell arcs from data pins for edge-triggered devices.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, PrimeTime always allows propagation through the cell arcs from
data pins for edge-triggered devices. By default, under certain conditions PrimeTime
does not allow propagation through the cell arcs from data pins of edge-triggered
devices.

To determine the current value of this variable, type one of the following commands:

printvar timing_propagate_through_non_latch_d_pin_arcs

echo $timing_propagate_through_non_latch_d_pin_arcs

Changing the value of this variable triggers a full update timing subsequently.

SEE ALSO
update_timing(2)

timing_propagate_through_non_latch_d_pin_arcs
298
timing_reduce_multi_drive_net_arcs
Enables or disables the collapsing of parallel timing arcs to improve PrimeTime
performance and memory utilization.

TYPE

fIBooleanfP

DEFAULT

false

DESCRIPTION

Designs with high-fanin, high-fanout mesh clock networks can cause significant
performance degradation and explosion in memory requirements. Evidently, detailed
parasitics would further exaggerate these problems. The suggested flow is to Spice
the clock network and annotate clock latency and transition as ideal clock network
attributes at the clock pins. To improve performance and memory requirements for
clock network analysis, PrimeTime has to reduce the number of timing arcs it must
consider. This is achieved by setting timing_reduce_multi_drive_net_arcs to true.

The reduction operation is performed during link; hence, the variable has to be set
prior to that. Once the design is linked, modifying the value of the
timing_reduce_multi_drive_net_arcs variable does not cause parallel timing arcs to
be collapsed or restored.

Potential instances of parallel drivers are detected at design nets based on the
multiplication product of the size of a net’s fanin and fanout. If this product were
greater than the value of the timing_reduce_multi_drive_net_arcs_threshold variable,
the net would be considered for reduction. In order to reduce the fanin of such
nets, the following criteria must be true:

1. All drivers have to be nonsequential, nonhierarchical cells.

2. All driver cells must be the same type (lib_cell).

3. All driver cells must correspondingly connect to the same nets.

For every successfully reduced net, a PTE-046 message is issued, specifying the
reduced net and the corresponding driver after the reduction. For unsuccessful
attempts, a PTE-047 message is issued to explain the reason the net drivers cannot
be reduced.

Ideal clock network parameters must be set at latch clock pins in the fanout of
reduced parallel buffers by using the set_clock_transition and set_clock_latency
commands. An ideal clock network stipulates that the clock signal is not propagated
through the parallel buffers. The cell delay accuracy of the parallel buffers or net
delay accuracy of the output net of parallel buffers is not preserved. Any
report_timing or report_delay_calculation commands involving these objects might
show incorrect or inconsistent delays that should be overridden by ideal clock

timing_reduce_multi_drive_net_arcs
299
latency and transition at the register clock pins. The check_timing command will
verify that reduced parallel buffers drive only latch clock pins with ideal clocks.

Note that the reduced cells are not physically removed from the netlist, but that no
timing arcs exist to the input pins or from the output pins. Hence, flows using the
write_changes command are not be affected. However, not having the timing arcs in
and out of the collapsed cells implies that the report_timing command through these
cells or the setting of point-to-point exceptions are completely ignored.

Flows using Standard Delay Format (SDF) annotations are accepted if ideal clock
network attributes are used. SDF annotations to or from collapsed cells issue the
PTE-048 informational message noting that a particular delay annotation is ignored.
Note that the remaining cell post-collapse is arbitrarily selected; and, hence, no
assertion can be made as to its annotated delay. The same applies to Reduced
Standard Parasitic Format (RSPF) annotations. Flows using the write_sdf command must
account for the reduced timing arcs.

To determine the current value of the timing_reduce_multi_drive_net_arcs variable,

type the following:

printvar timing_reduce_multi_drive_net_arcs

or

echo $timing_reduce_multi_drive_net_arcs.

SEE ALSO

check_timing (2), printvar (2), report_delay_calculation (2), report_timing (2),

set_annotated_transition (2), set_clock_latency (2), set_clock_transition (2),
write_changes (2), write_sdf (2), timing_reduce_multi_drive_net_arcs_threshold (3).

timing_reduce_multi_drive_net_arcs
300
timing_reduce_multi_drive_net_arcs_threshold
Provides a threshold for the product of some net’s fanin and fanout beyond which a
parallel timing arc in the net’s fanin might be reduced.

TYPE

fIintegerfP

DEFAULT

10000

DESCRIPTION

For a net, the number of timing arcs through the net is equal to the product of the
net’s drivers and loads. For designs with high-fanin, high-fanout mesh clock
networks, significant performance degradation and explosion in memory requirements
can occur. Setting the timing_reduce_multi_drive_net_arcs variable improves parallel
drivers reduction.

The timing_reduce_multi_drive_net_arcs_threshold variable provides a minimum value

for the driver-load product below which the net would not be considered for
reduction.

To determine the current value of this variable, type the following:

printvar timing_reduce_multi_drive_net_arcs_threshold

or

echo $timing_reduce_multi_drive_net_arcs_threshold.

SEE ALSO

printvar (2), timing_reduce_multi_drive_net_arcs (3).

timing_reduce_multi_drive_net_arcs_threshold
301
timing_reduce_parallel_cell_arcs
Enable merging parallel cell arcs to reduce memory footprint.

TYPE

Boolean

DEFAULT

true

GROUP

timing_variables

DESCRIPTION

Multiple parallel cell arcs of the same sense can exist between the same pair of
pins.

When this variable is set to its default of true, delays on these parallel cell arcs
are merged in a bounding manner. This behaviour applies to calculated delays as well
as delays that are annotated from the set_annotated_delay command. This behavior is
turned off for read_sdf flows. When this behavior is on, the write_sdf command also
writes out the same bounding value for all of the parallel cell arcs. When this
behavior is turned on, reporting commands report the worst path through a set of
parallel cell arcs.

This feature is not compatible with the write_spice_deck command. To ensure that the
cell arc sensitized in the spice deck corresponds to the worst cell arc, this
variable should be set to false.

When you set this variable to false, each parallel cell arc might have a different
delay.

This variable setting has no impact for designs without parallel cell arcs.

SEE ALSO
get_timing_paths(2)
report_timing(2)
set_annotated_delay(2)
write_sdf(2)

timing_reduce_parallel_cell_arcs
302
timing_remove_clock_reconvergence_pessimism
Enables or disables clock reconvergence pessimism removal

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to true, PrimeTime removes clock reconvergence pessimism
from slack calculation and minimum pulse width checks. This variable replaces the
following discontinued options:

-report_clock_reconvergence_pessimism
-remove_clock_reconvergence_pessimism

of the report_timing, report_constraint, and get_timing_paths commands.

Clock reconvergence pessimism (CRP) is a difference in delay along the common part
of the launching and capturing clock paths. The most common causes of CRP are
reconvergent paths in the clock network, and different min and max delay of cells in
the clock network.

CRP is independently calculated for rise and fall clock paths. You can use the
variable timing_clock_reconvergence_pessimism to control CRP calculation with
respect to transition sense. In the case of the capturing device being a level-
sensitive latch two CRP values will be caculated:
• crp_open, which is the CRP corresponding to the opening edge of the latch
• crp_close, which is the CRP corresponding to the closing edge of the latch The
required time at the latch will be increased by the value of crp_open and hence
reduce the amount of borrowing (if any) at the latch. Meanwhile, the maximum time
borrow allowed at the latch is affected by shifting the closing edge by crp_close.
For more details, see the PrimeTime User Guide: Fundamentals.

For a more detailed description of a CRP calulation, use the report_crpr command.

CRP is calculated differently for minimum pulse-width checks. It is given as the

minimum of (maximum rise arrival time - minimum rise arrival time) and (maximum fall
arrival time - minimum fall arrival time) at the pin where the check is being made.

If the variable si_enable analysis is set to true delays in the clock network may
also include delta delays resulting from crosstalk interaction. Such delays are
dynamic in nature, that is, they may vary from one clock cycle to the next, causing
different delay variations (either speed-up or slow-down) on the same network, but
during different clock cycles.

Starting with U-2003.03 release PrimeTime only considers SI delta delays as part of

timing_remove_clock_reconvergence_pessimism
303
the CRP calculation if the type of timing check deployed derives its data from the
same clock cycle.

Similarily if dynamic annotations have been set on the design the clock delays
computed using these annotations will only be used to calculate CRP if type of
timing check deployed derives its data from the same clock cycle. Such dynamic
annotations include, dynamic clock latency which may be specified using the
set_clock_latency command or dynamic rail voltage which may be specified using the
set_rail_voltage command.

In transparent-latch based designs, it is recommended that the variable

timing_early_launch_at_borrowing_latches should be set to false when CRP removal
(CRPR) is enabled. In this case, CRPR will apply even to paths whose startpoints are
borrowing, leading to better pessimism reduction overall.

Any effective change in the value of the timing_remove_clock_reconvergence_pessimism

variable causes full update_timing. You cannot perform one report_timing operation
that considers CRP and one that does not without full update_timing in between.

For backward compatibility, the discontinued options will appear for the first few
releases after they are obsoleted. However, if the design is not up to date at the
time they are executed, they will only set
timing_remove_clock_reconvergence_pessimism to true

If the design is up to date, then the command with the discontinued option fails.
Since the discontinued command options only set
timing_remove_clock_reconvergence_pessimism to true, the -
report_clock_reconvergence_pessimism option behavior is not backward compatible. It
causes slack to be removed prior to selecting the worst path. In other words, it
behaves the same as the discontinued -remove_clock_reconvergence_pessimism option of
the report_timing, reyport_constraint, and get_timing_paths commands. As soon as
possible, update your scripts to set the timing_remove_clock_reconvergence_pessimism
variable to true instead of using the discontinued options.

Limitations: CRPR does not support paths that fan out directly from clock source
pins to the data pins of sequential devices. To enable support for such paths the
variable timing_crpr_remove_clock_to_data_crp must be set to TRUE.

To turn CRP removal on:

pt_shell> set timing_remove_clock_reconvergence_pessimism TRUE

TRUE
pt_shell> report_timing

SEE ALSO

get_timing_paths (2), report_analysis_coverage (2), report_bottleneck (2),

report_constraint (2), report_min_pulse_width (2), report_timing (2),
set_clock_latency (2), set_rail_voltage (2), timing_crpr_threshold_ps (3),
timing_clock_reconvergence_pessimism (3), timing_early_launch_at_borrowing_latches
(3), report_crpr(2), timing_crpr_remove_clock_to_data_crp (3), .si_enable_analysis
(2).

timing_remove_clock_reconvergence_pessimism
304
timing_report_always_use_valid_start_end_points
Requires the -from/-rise_from/-fall_from options from_list objects to be valid
timing startpoints and the -to/-rise_to/-fall_to options to_list objects to be valid
timing endpoints.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable affects the way the report_timing, report_bottleneck and

get_timing_path commands interpret -from/-rise_from/-fall_from options from_list
objects and -to/-rise_to/-fall_to options to_list objects.

When set to false (the default), the from_list are interpreted as all pins found by
given objects. When objects are specified with "*" or some cells name, there is a
possibility that many invalid startpoints or endpoints are gotten, such as -from
[get_pins FF/*] includes input, output, and asynchronous pins. The current behavior
for PrimeTime considers these invalid startpoints or endpoints as through points and
continues the path searching. Even though it is convenient to use, it is not
suggested since it usually has a longer run time.

You can set this variable to true to report using only valid startpoints and
endpoints. It is always suggested to use input ports or register clock pins for the
from_list objects and use output ports or register data pins for the to_list
objects.

To determine the current value of this variable, type the following:

printvar timing_report_always_use_valid_start_end_points

SEE ALSO
printvar(2)
report_timing(2)
report_bottleneck(2)
get_timing_path(2)

timing_report_always_use_valid_start_end_points
305
timing_report_fast_mode
Enables the fast report_timing algorithm.

TYPE

Boolean

DEFAULT

true

DESCRIPTION

This variable, when set to true (the default), selects the fast reporting mode for
the report_timing and get_timing_paths commands.

When this variable is set to false, it selects the behavior of earlier releases,
resulting in the following changes:

- The value specified with the -max_paths options applies to each path group rather
than all path groups. Therefore, the worst path in each path group is reported
rather than the worst path among all path groups. More paths are reported because
the -max_paths and -nworst options apply to each path group.

- The paths returned the command are organized by path group rather than by slack.
If you want the paths reported by path group, an alternative to setting this
variable to false is to use the -group option, for example, report_timing -group
[get_groups *].

- Paths with positive slack are reported. By default, in the fast mode, when -
max_paths and -nworst are larger than 1, only paths with negative slack are
reported. If you want paths with positive slack to be reported, an alternative to
setting the timing_report_fast_mode variable to false is to use the -
slack_lesser_than option with a positive value.

To determine the current value of this variable, type printvar

timing_report_fast_mode.

SEE ALSO
get_timing_paths (2),
report_timing (2).

timing_report_fast_mode
306
timing_report_maxpaths_nworst_reached
Controls max_paths and nworst reached messages displayed during the timing report
process.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Controls messages displayed during the timing report when the paths reported for a
group reaches the specified max_paths and the paths reported for an endpoint reaches
the specified nworst. When you set this variable to true, the timing report displays
messages to report whether the specified max_paths for a group and nworst for an
endpoint have been reached or not.

The messages are based on the paths before applying any filtering, such as -
slack_greater_than. An endpoint that has exactly nworst paths is not considered as
nworst reached. Therefore, you do not need to look at these endpoints for more
paths. The message only displays endpoints that have more than nworst paths, so you
need to increase the specified nworst to get all paths for these reported endpoints.

It is suggested that you use this variable with the

timing_report_always_use_valid_start_end_points variable since the messages might be
inaccurate if invalid startpoints and endpoints are presented. You cannot use with -
true options.

For the current value of this variable, type the following:

printvar timing_report_maxpaths_nworst_reached

SEE ALSO
printvar(2)
report_timing(2)
get_timing_path(2)

timing_report_maxpaths_nworst_reached
307
timing_report_recalculation_status
Display progress messages during an exhaustive path-based analysis.

TYPE

string

DEFAULT

low

DESCRIPTION

This variable controls the reporting of information messages during path-based

recalculation for the report_timing and get_timing_paths commands with the -pba_mode
exhaustive option.

The number of messages varies based on the value of the variable, as follows:

• When set to none, PrimeTime will not show any recalculation information messages.

• When set to low, a message is displayed only at the end of the recalculation for
each clock group.

• When set to medium, messages are displayed only at the beginning and end of the
recalculation for each clock group.

• When set to high, all messages for medium are displayed; and, in addition, the
total number of endpoints to search and the completion percentage for searching
these endpoints are displayed.

Sample information messages are shown below when the variable is set to high.

Information(nworst 5, max_paths 20): recalculating group **async_default**...

Information: No paths to recalculate.
Information(nworst 5, max_paths 20): recalculating group **clock_gating_default**...
Information: No paths to recalculate.
Information(nworst 5, max_paths 20): recalculating group **default**...
Information: No paths to recalculate.
Information(nworst 5, max_paths 20): recalculating group clk...
Information: recalculated_paths 10
Information: recalculated_paths 20
Information: recalculated_paths 30
Information: finished_endpoints 3, total_endpoints 5, recalculated_paths 30
Information: finished_endpoints 5, total_endpoints 5, recalculated_paths 30
Information: Recalculated 30 paths and returned 20 paths for group ’clk’. The maxim
um number of paths recalculated at an endpoint was 10.

timing_report_recalculation_status
308
To determine the current value of this variable, type printvar
timing_report_recalculation_status.

SEE ALSO
get_timing_paths (2),
report_timing (2).

timing_report_recalculation_status
309
timing_report_status_level
Controls the number of progress messages displayed during the timing report process.

TYPE

fIstringfP

DEFAULT

none

DESCRIPTION

Controls the number of progress messages displayed during the timing report process.
Valid values are none (the default), low, medium, and high.

When set to none, no messages are displayed. When set to low, medium, or high,
progress is reported when you use the report_timing and report_constraint commands.

The number of messages varies based on the value of the variable, as follows:

• When set to low, messages are displayed only at the beginning and end of the
timing report.

• When set to medium, all messages for low are displayed; and, in addition, messages
are displayed at the beginning of searching for each clock group.

• When set to high, all messages for medium are displayed when you use the
report_timing command; and, in addition, the total number of endpoints to search and
the completion percentage for searching these endpoints are displayed.

The report_constraint command displays status only when the

timing_report_status_level variable is set to high and the -verbose option is used.
The report_constraint command displays only progress status related to timing paths
search.

This variable controls the display only for the timing report. Sometimes, the timing
report might trigger a timing update. If you want to see the progress status for
timing update, you should set the timing_update_status_level variable. To determine
the current value of this variable, type:

printvar timing_report_status_level

or:

echo $timing_report_status_level.

timing_report_status_level
310
SEE ALSO

printvar (2), report_constraint (2), report_timing (2); timing_update_status_level

(3).

timing_report_status_level
311
timing_report_unconstrained_paths
Specifies if PrimeTime searches for unconstrained paths or not when you use the
report_timing or get_timing_paths command.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When this variable is set to false (the default), the report_timing and
get_timing_paths commands search only for constrained paths. It runs much faster if
there are lots of unconstrained paths in the design, but you are not interested in
these unconstrained paths.

For backward compatibility, you can set this variable to true. The report_timing and
get_timing_paths commands continue searching for unconstrained paths when
constrained paths cannot be found. Searching unconstrained paths might have a longer
run time than expected as specified by the UITE-413 warning message.

Note that both the report_timing and get_timing_paths commands only search for
unconstrained paths if there are no constrained paths that satisfy the path search
options.

To determine the current value of this variable, type the following command:

printvar timing_report_unconstrained_paths

SEE ALSO
printvar(2)
report_timing(2)
get_timing_paths(2)

timing_report_unconstrained_paths
312
timing_report_use_worst_parallel_cell_arc
Enables uniquification of paths through parallel cell arcs.

TYPE

Boolean

DEFAULT

false

GROUP

timing_variables

DESCRIPTION

Multiple cell arcs of the same sense can exist between the same pair of pins. In
designs with large numbers of such parallel cell arcs, there can often be an
explosion of seemingly identical paths reported. You can choose whether or not to
report every path through parallel cell arcs.

When this variable is false (the default), all paths through parallel cell arcs can
be reported.

When this variable is true, only the worst path through a set of parallel cell arcs
is reported. PrimeTime chooses the arc with the worst delay to determine the worst
path. This variable setting has no effect in designs that have no parallel cell
arcs.

SEE ALSO
get_timing_paths(2)
report_timing(2)

timing_report_use_worst_parallel_cell_arc
313
timing_save_pin_arrival_and_required
Specifies whether the arrival and required times of all pins are kept in memory.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, the arrival and required times of all pins of the design are kept
in memory. When set to false (the default), arrival and required times are stored on
an as-needed basis for the analysis you are performing.

This variable is very similar in effect to the timing_save_pin_arrival_and_slack

command, enabling the same features (particularly slack and arrival window attribute
query). However, the timing_save_pin_arrival_and_required command maintains
additional information which is more expensive in terms of memory usage.

You should avoid using this variable except in the specific case where the
write_sdf_constraints command forms part of your flow, as it is the only command
which requires additional information be stored at all pins. If the
write_sdf_constraints command is used while this variable is set to false, it is set
to true automatically and an informational message issued.

To determine the current value of this variable, type the following command:

printvar timing_save_pin_arrival_and_required

SEE ALSO
printvar(2)
timing_save_pin_arrival_and_slack(3)

timing_save_pin_arrival_and_required
314
timing_save_pin_arrival_and_slack
Specifies whether the slacks of all pins are kept in memory.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to true, the slacks of all pins of the design are kept in memory. When set
to false (the default), the slacks are preserved only for endpoints of the design.

To query slack attributes or arrival window attributes on pins that are not
endpoints of the design, set this variable to true.

To determine the current value of this variable, type the following command:

printvar timing_save_pin_arrival_and_slack

SEE ALSO
printvar(2)
report_timing(2)

timing_save_pin_arrival_and_slack
315
timing_si_exclude_delta_slew_for_transition_constraint
Specifies that the delta slew be excluded from maximum and minimum transition
constraint checks.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

This variable determines if the delta slew should be excluded from maximum and
minimum transition constraint checks. The variable can be one of two values: true or
false (default). The true value specifies that the delta slew is excluded for
maximum and minimum transition constraint checks.

For the current value of this variable, type the following command:

printvar timing_si_exclude_delta_slew_for_transition_constraint

SEE ALSO
printvar(2)
report_constraint -max_transition(2)
report_constraint -min_transition(2)

timing_si_exclude_delta_slew_for_transition_constraint
316
timing_simultaneous_clock_data_port_compatibility
Disable or enable the simultaneous behavior of input port as a clock and data port.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

PrimeTime allows an input port to behave simultaneously as a clock and data port.
You can use the timing_simultaneous_clock_data_port_compatibility variable to enable
or disable the simultaneous behavior of the input port as a clock and data port.
When this variable is false, the default, simultaneous behavior is enabled and you
can use the set_input_delay command to define the timing requirements for input
ports relative to a clock. In this situation, the following applies:

• If you specify the set_input_delay command relative to a clock defined at the same
port and the port has data sinks, the command is ignored and an error message is
issued. There is only one signal coming to port, and it cannot be at the same time
data relative to a clock and the clock signal itself.

• If you specify the set_input_delay command relative to a clock defined at a

different port and the port has data sinks, the input delay is set and controls data
edges launched from the port relative to the clock.

• Regardless of the location of the data port, if the clock port does not fanout to
data sinks, the input delay on the clock port is ignored and you receive an error
message.

When you set the timing_simultaneous_clock_data_port_compatibility variable to true,

the simultaneous behavior is disabled and the set_input_delay command defines the
arrival time relative to a clock. In this situation, when an input port has a clock
defined on it, PrimeTime considers the port exclusively as a clock port and imposes
restriction on the data edges that are launched. PrimeTime also prevents setting
input delays relative to another clock.

To determine the current value of this variable, type the following:

printvar timing_port_clock_and_data_compatibility

SEE ALSO
printvar(2)
set_input_delay(2)

timing_simultaneous_clock_data_port_compatibility
317
set_clock_latency(2)

timing_simultaneous_clock_data_port_compatibility
318
timing_slew_threshold_scaling_for_max_transition_compatibility
Specifies the compatibility mode for timing slew threshold scaling.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

The scaling of transition time for slew threshold is on by default starting with
version Z-2006.12. You must set this variable to true to revert to the behavior
prior to version Z-2006.12.

SEE ALSO
set_max_transition(2)

timing_slew_threshold_scaling_for_max_transition_compatibility
319
timing_update_effort
Controls the computational effort (in CPU time) and memory usage for the fast timing
update algorithm in PrimeTime.

TYPE

string

DEFAULT

medium

GROUP

timing_variables

DESCRIPTION

Controls the computational effort (in CPU time) and memory usage for the fast timing
update algorithm in PrimeTime. Allowed values are as follows:

* low: The computational effort is low (that is, the report_timing command is fast);
however, the memory usage is not bounded and can increase significantly if the
number of changes is very large.

* medium (the default): The computational effort is low (that is, the report_timing
command is fast); however, the memory usage is bounded by 10% over the memory usage
for initial timing. If this bound is not sufficient to accommodate all of your
changes, PrimeTime issues an informational message and automatically switches to a
less efficient algorithm that is more conservative in the memory usage. In this
case, you might need to change to the low value. However, even with this small 10%
bound, PrimeTime can accommodate a relatively large number of changes. Therefore, it
is unlikely that you need to change this default value.

* high: The computational effort is high (that is, the report_timing command becomes
slow); however, there is no increase in the memory used for the initial timing of
the design.

When a design is timed again after a change, the algorithm reuses a portion of the
computation done for the initial timing. For example, if a design was loaded and
timed using the update_timing or report_timing command, and the capacitance on a
port was changed using the set_load command, the effort spent in the execution of a
subsequently issued the report_timing command is smaller than that for the first
issued the report_timing or update_timing command.

To determine the current value of this variable, type the following command:

printvar timing_update_effort

timing_update_effort
320
SEE ALSO
printvar(2)
report_timing(2)
set_load(2)
update_timing(2)

timing_update_effort
321
timing_update_status_level
Controls the number of progress messages displayed during the timing update process.

TYPE

string

DEFAULT

none

GROUP

timing_variables

DESCRIPTION

Controls the number of progress messages displayed during the timing update process.
Allowed values are none (the default), low, medium, or high.

When set to none, no messages are displayed. When set to low, medium, or high, the
progress of the timing update is reported for an explicit update (using the
update_timing command) or for an implicit update invoked by another command (for
example, report_timing) that forces a timing update. The number of messages varies
based on the value of the variable, as follows:

When set to low, messages are displayed only at the beginning and the end of the
update.

When set to medium, all messages for low are displayed, and in addition, messages
are displayed at the beginning and at the end of the additional intermediate timing
update steps constant propagation, delay calculation, and slack computation.

When set to high, all messages for medium are displayed; in addition, messages for
the delay calculation and arrival calculation steps show the completion percentage
for large designs, and messages for the slack computation step show the groups for
which the computation is made.

To determine the current value of this variable, type one of the following commands:

printvar timing_update_status_level
echo $timing_update_status_level

SEE ALSO
printvar (2)
report_timing(2)
update_timing(2)

timing_update_status_level
322
timing_use_constraint_derates_for_pulse_checks
Enables or disables using timing constraint derates for min_pulse_width and
min_period constraints.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When set to false (the default), there is no behavior change. When set to true,
PrimeTime uses factors defined by the set_timing_derate -cell_check -late command to
derate the min_pulse_width and min_period constraints as follows:

• set_timing_derate -cell_check -late -fall applies to min_pulse_width checks for

low pulses.

• set_timing_derate -cell_check -late -rise applies to min_pulse_width checks for

high pulses.

• Greater of set_timing_derate -cell_check -late -rise and set_timing_derate -

cell_check -late -fall applies to min_period checks.

To determine the current value of this variable, type one of the following commands:

printvar timing_use_constraint_derates_for_pulse_checks

echo $timing_use_constraint_derates_for_pulse_checks

SEE ALSO
set_timing_derate(2)
report_min_pulse_width(2)

timing_use_constraint_derates_for_pulse_checks
323
timing_use_zero_slew_for_annotated_arcs
Allows disabling of the slew calculation to enhance performance in a pure SDF flow.

TYPE

list

DEFAULT

auto

DESCRIPTION

Allows you to sacrifice slew calculation for performance in an SDF flow. The valid
variable values are always, auto, or never.

When set to always, a zero value is used for transition time on the load pins of
fully delay annotated arcs. Fully annotated arcs have values for both rise and fall,
either read from an SDF file, or set with the set_annotated_delay command.

If blocks of arcs that are not annotated exist, delay is estimated using the best
available slew at the inputs. This functionality requires the
timing_slew_propagation_mode command be set to worst_slew, as other modes of slew
propagation are not supported within these blocks.

The default value is auto, which allows the automatic switching to the SDF flow if
more than 95 percent of delay arcs on a design have annotated values.

To avoid usage of the SDF flow, set the timing_use_zero_slew_for_annotated_arcs

command to never.

To determine the the current value of this variable, type the following command:

printvar timing_use_zero_slew_for_annotated_arcs

SEE ALSO
printvar(2)
read_sdf(2)
timing_slew_propagation_mode(3)

timing_use_zero_slew_for_annotated_arcs
324
variation_analysis_mode
Specifies the scope of variations analysis performed during a subsequent timing
update.

TYPE

string

DEFAULT

default

DESCRIPTION

The setting of this variable encodes the scope of the subsequent graph-based static
timing analysis performed during a timing update, provided the
variation_enable_analysis command is set to true. If the latter variable were false,
this variable has no effect.

The valid choices of effort level are default and path_based_only.

To determine the current value of this variable, type the following command:

printvar variation_analysis_mode

SEE ALSO
update_timing(2)
variation_enable_analysis(3)

variation_analysis_mode
325
variation_derived_scalar_attribute_mode
Enables get_attribute command to return statistical timing attributes of timing_path
and timing_point collections in VASTA.

TYPE

String

DEFAULT

quantile

DESCRIPTION

This variable is used to enable or disable statistical timing attributes as the

return values of get_attribute command for timing_path and timing_point collections.
If it is set to mean or quantile, the arrival, slack, required, or transition values
returned from command get_attribute will be replaced with the mean or quantile
values of corresponding variation_arrival, variation_slack, variation_required, or
variation_transition attributes. The default value is quantile in variation-aware
analysis. Setting this variable to none will disable statistical attributes, and
get_attribute will return the corner values. If variation-aware analysis is turned
off, get_attribute will always return the corner values regardless of the value of
this variable.
Commands sort_collection and filter_collection will be affected if this variable is
set to mean or quantile while related timing attributes are used in the sorting or
filtering schemes. This feature allows to create custom timing_path collections that
are sorted/filtered by statistical timing attributes.
The default quantile value can be defined by command set_variation_analysis_mode. To
determine the current value of this variable, type printvar
variation_derived_scalar_attribute_mode or echo
$variation_derived_scalar_attribute_mode.

SH EXAMPLES

The following example replaces the returned arrival value of get_attribute from
corner value to mean of variation_arrival.

pt_shell> set variation_derived_scalar_attribute_mode none

none
pt_shell> get_attribute $path arrival
0.25
pt_shell> set variation_derived_scalar_attribute_mode mean
mean
pt_shell> get_attribute $path arrival
0.22

This example creates a new timing_path collection by sorting an existing collection

by statistical quantile of variation_slack.

variation_derived_scalar_attribute_mode
326
pt_shell> set path [get_timing_path -nworst 10]
_sel22
pt_shell> set variation_derived_scalar_attribute_mode quantile
quantile
pt_shell> set stat_path [sort_collection $path "arrival"]
_sel23

SEE ALSO

variation_enable_analysis (3), set_variation_analysis_mode (2), get_attribute (2),

sort_collection (2), filter_collection (2).

variation_derived_scalar_attribute_mode
327
variation_enable_analysis
Enables statistical variation analysis for PrimeTime.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Used to enable or disable statistical variation analysis. Set this variable to true
to enable statistical variation. Set to false (the default) to disable statistical
variation. When set to true, PrimeTime attempts to get the appropriate license. If
it gets the license, the variable is set to true. If it cannot get the license, the
variable is left at the false default setting.
To determine the current value of this variable, type one of the following commands:

printvar variation_enable_analysis

echo $variation_enable_analysis

SEE ALSO
set_variation_library(2)
create_distribution(2)
set_variation(2)
variation_analysis_mode(3)

variation_enable_analysis
328
variation_pba_use_worst_parasitics
Enables use of worst parasitic corner for statistical path-based analysis.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

Used to enable or disable the use of worst parasitic corner per path for statistical
path-based analysis. Set this variable to true to enable the use of worst
parasitics, and set to false to disable it. When set to true, PrimeTime VX attempts
to calculate the worst parasitic corner (worst slack corner) each time a path-based
analysis command is issued. The parasitic variations are treated as constants at the
computed corner values and statistical analysis with device variations is carried
out. Worst parasitic corner is computed only if the design has variation aware
parasitics read using the read_parasitics -keep_variations command and the auto-
correlation for the parasitic variation parameters is 1. Cross-correlation values of
only +1/-1 between parasitic variation parameters are honored to determine the worst
corner. All other cross-correlations values are ignored (considered to be 0) for
determining the worst corner.
To determine the current value of this variable, type one of the following commands:

printvar variation_pba_use_worst_parasitics
echo $variation_pba_use_worst_parasitics

SEE ALSO
read_parasitics(2)
set_variation_correlation(2)

variation_pba_use_worst_parasitics
329
variation_report_timing_increment_format
Controls the display of report timing increments for variation-aware timing paths.

TYPE

string

DEFAULT

effective_delay

DESCRIPTION

This variable affects the display of paths which have been recalculated within the
context of a variation-aware timing analysis. The transition times, delays, and
arrival times associated with these paths are statistical in nature. This variable
lets you configure the display of the delays appearing in the increment column
(labeled Incr).
Allowed values are effective_delay (the default) and delay_variation. When set to
effective_delay, each increment displayed equals the scalar difference between the
arrival values appearing in the path column. When set to delay_variation, the
quantile value (or mean value) of the statistical increment is displayed instead,
according to the variation_derived_scalar_attribute_mode variable.
The arrival times and transitions are also displayed using scalar representations of
their underlying distributions. These also obey the
variation_derived_scalar_attribute_mode variable.
To determine the current value of this variable, type the following command:

printvar variation_report_timing_increment_format

SEE ALSO
variation_enable_analysis(3)
variation_analysis_mode(3)
variation_derived_scalar_attribute_mode(3)
report_timing(2)

variation_report_timing_increment_format
330
wildcards
Describes supported wildcard characters and ways in which they can be escaped.

DESCRIPTION

The following characters are supported as wildcards:

• Asterisks (*) - Substitute for a string of characters of any length

• Question marks (?) - Substitute for a single character

The following commands support wildcard characters:

get_cells
get_clocks
get_designs
get_lib_cells
get_lib_pins
get_libs
get_nets
get_pins
get_ports
list_libs

In addition to the commands listed, commands that perform an implicit get support
wildcard characters.

Escaping Wildcards

Wildcard characters must be escaped using double backslashes (\\) to remove their
special regular expression meaning. For more information, see the EXAMPLES section.

Escaping Escape Character (\\)

This is similar to the escaping wildcard characters; however, the escaping escape
character needs one escape character each to escape the escape character. For more
information, see the EXAMPLES section.

EXAMPLES

The following examples show how to use wildcard characters.

wildcards
331
Using Wildcards

The following example gets all nets in the current design that are prefixed by /
fIin/fP and followed by any two characters:

pt_shell> get_nets in??

{"in11", "in21"}

The following example gets all cells in the current design that are prefixed by /
fIU/fP and followed by a string of characters of any length:

pt_shell> get_cells U*
{"U1", "U2", "U3", "U4"}

Escaping Wildcards

The following examples show how to use escaping wildcard characters.

The following example gets the test?1 design in the system.

pt_shell> get_designs {test\\?1}

{"test?1"}

The same example can be used in a Tcl-based pt_shell using the list Tcl command. For
example,

pt_shell> get_designs [list {test\?1}]

{"test?1"}

If neither the curly braces nor the list command is used in the Tcl-based pt_shell,
the syntax is as follows:

pt_shell> get_designs test\\\\?1

{"test?1"}

Escaping Escape Character (\\)

The following examples show how to escape an escape character.

wildcards
332
The following example gets teh test\1 design in the system.

pt_shell> get_designs {test\\\\1}

{"test\1"}

The same example as above can be used in the Tcl-based pt_shell by using the list
Tcl command. For example,

pt_shell> get_designs [list {test\\1}]

{"test\1"}

If neither curly braces nor the list command is used in the Tcl-based pt_shell, the
syntax is as follows:

pt_shell> get_designs test\\\\\\\\1

{"test\1"}

wildcards
333
write_script_include_library_constraints
Controls whether constraints set on library objects are written to script output by
the write_script and write_sdc commands.

TYPE

Boolean

DEFAULT

true

GROUP

timing_variables

DESCRIPTION

Controls whether constraints set on library objects are written to script output by
the write_script and write_sdc commands. When set to truetrue (the default), these
constraints are written. The only constraints which are written are those attached
to objects in libraries in use by the current design.
Currently, only constraints created with the set_disable_timing command are written.
To determine the current value of this variable, type one of the following commands:

printvar write_script_include_library_constraints
echo $write_script_include_library_constraints

SEE ALSO
printvar(2)
set_disable_timing(2)
write_script(2)
write_sdc(2)

write_script_include_library_constraints
334
write_script_output_lumped_net_annotation
Determines whether or not the write_script command outputs lumped network
annotations.

TYPE

Boolean

DEFAULT

false

DESCRIPTION

When the write_script_output_lumped_net_annotation variable is set to true, the

write_script command outputs lumped network annotations. When the variable is set to
its default of false, the write_script command does not output lumped network
annotations because they are not valid equivalents of detailed network annotations
made by the read_parasitics command. The lumped network annotations are total
capacitance, set by the set_load command, and total resistance, set by the
set_resistance command. Set this variable to true if you need to include lumped
annotations in the write_script output.

If you want intentional set_resistance and set_load annotations, it is preferred to

include them in a separate Tcl script rather than in a Synopsys Design Constraints
(SDC) file.

To determine the current value of this variable, type the following command:

printvar write_script_output_lumped_net_annotation

SEE ALSO
read_parasitics(2)
set_load(2)
set_resistance(2)
write_script(2)

write_script_output_lumped_net_annotation
335