首页资源分类应用技术消费电子 > prime time

prime time

已有 445110个资源

下载专区

文档信息举报收藏

标    签:primetime

分    享:

文档简介

prime time的基础资料,很实用

文档预览

PrimeTime Commands Version Y-2006.06, June 2006 Comments? Send comments on the documentation by going to http://solvnet.synopsys.com, then clicking “Enter a Call to the Support Center.” Copyright Notice and Proprietary Information Copyright © 2006 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, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CRITIC, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSIM, HSPICE, Hypermodel, iN-Phase, in-Sync, Leda, MAST, Meta, Meta-Software, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill, PrimeTime, RailMill, RapidScript, Saber, SiVL, SNUG, SolvNet, Superlog, System Compiler, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc. Trademarks (™) Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC Expert, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision, DesignerHDL, DesignTime, DFM-Workbench, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI, Dynamic Model Switcher, Dynamic-Macromodeling, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, Galaxy, Gatran, HANEX, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II, Hierarchical plus Optimization Technology, High Performance Option, HotPlace, HSIM , HSPICE-Link, i-Virtual Stepper, iN-Tandem, Integrator, Interactive Waveform Viewer, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Libra-Visa, Library Compiler, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View, Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate, ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael, Raphael-NES, RoadRunner, RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT, Taurus, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice, TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator, VirSim, and VMC 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. All other product or company names may be trademarks of their respective owners. PrimeTime Commands, version Y-2006.06 ii Table of Contents 1 add_distributed_hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 add_to_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 add_variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 all_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 all_connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 all_fanin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 all_fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 all_inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 all_instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 all_outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 all_registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 append_to_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 cell_of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 change_histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 change_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 characterize_context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 check_block_scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 check_level_shifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 check_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 check_timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Collections_and_Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 compare_collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 compare_interface_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 compile_stamp_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 complete_net_parasitics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 connect_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 copy_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 cputime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 create_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 create_configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 create_correlation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 create_distributed_farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 create_distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 create_eco_astro_constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 create_generated_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 create_histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 create_ilm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 create_lcd_operating_condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 create_net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 create_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 create_power_group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 create_power_rail_mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 create_power_waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 create_qtm_constraint_arc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 create_qtm_delay_arc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 create_qtm_drive_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 create_qtm_generated_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 create_qtm_load_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 create_qtm_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 create_qtm_path_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 create_qtm_port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 create_scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 create_si_context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 current_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 current_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 current_power_rail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 current_scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 current_session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 define_design_mode_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 define_qtm_attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 define_scaling_lib_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 define_user_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 iv derive_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 disconnect_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 drive_of. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 estimate_clock_network_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 extract_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 filter_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 find . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 foreach_in_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 get_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 get_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 get_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 get_clock_network_objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 get_clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 get_designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 get_designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 get_distributed_variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 get_distribution_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 get_generated_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 get_generated_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 get_ilm_objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 get_libs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 get_lib_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 get_lib_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 get_lib_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 get_lib_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 get_lib_timing_arcs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 get_libs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 get_license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 get_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 get_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 get_noise_violation_sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 get_object_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 get_path_groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 get_path_groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 get_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 get_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 get_ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 v get_ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 get_power_group_objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 get_qtm_ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 get_random_numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 get_recalculated_timing_paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 get_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 get_si_bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 get_switching_activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 get_timing_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 get_timing_paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 get_variation_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 get_view_type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 group_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 gui_create_menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 gui_create_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 gui_delete_menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 gui_enable_cross_communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 gui_set_timing_analysis_path_options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 gui_start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 gui_stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 identify_interface_logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 index_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 license_users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 link_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 list_attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 list_delcalc_resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 list_designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 list_key_bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 list_libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 list_licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 load_of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 map_design_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 max_variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 mem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 merge_models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 merge_saif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 min_variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 vi read_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 report_annotated_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 report_timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 report_timing_derate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 reset_timing_derate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 set_timing_derate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 write_spice_deck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 query_objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 read_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 read_ddc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 read_edif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 read_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 read_lib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 read_mdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 read_milkyway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 read_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 read_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 read_saif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 read_sdc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 read_sdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 read_vcd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 read_verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 read_vhdl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 remote_execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 remove_annotated_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 remove_annotated_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 remove_annotated_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 remove_annotated_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 remove_annotated_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 remove_buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 remove_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 remove_case_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 remove_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 remove_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 remove_clock_gating_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 remove_clock_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 remove_clock_latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 remove_clock_sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 vii remove_clock_transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 remove_clock_uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 remove_command_buffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 remove_configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 remove_connection_class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 remove_context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 remove_coupling_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 remove_coupling_separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 remove_current_session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 remove_data_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 remove_delcalc_resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 remove_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 remove_design_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 remove_disable_clock_gating_check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 remove_disable_timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 remove_distributed_hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 remove_distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 remove_drive_resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 remove_driving_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 remove_fanout_load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 remove_from_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 remove_generated_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 remove_ideal_latency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 remove_ideal_network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 remove_ideal_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509 remove_input_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511 remove_input_noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 remove_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 remove_license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 remove_max_area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 remove_max_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 remove_max_fanout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 remove_max_time_borrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 remove_max_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 remove_min_capacitance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522 remove_min_pulse_width. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 remove_multi_scenario_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 remove_net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 viii remove_noise_immunity_curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 remove_noise_lib_pin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 remove_noise_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 remove_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 remove_output_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531 remove_parasitic_corner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 remove_path_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534 remove_port_fanout_number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 remove_power_groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 remove_propagated_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 remove_qtm_attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538 remove_rail_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 remove_resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 remove_scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 remove_si_aggressor_exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 remove_si_delay_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 remove_si_delay_disable_statistical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 remove_si_noise_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 remove_si_noise_disable_statistical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 remove_steady_state_resistance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 remove_user_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 remove_user_sensitization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 remove_variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 remove_wire_load_min_block_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559 remove_wire_load_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560 remove_wire_load_selection_group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 rename_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 rename_design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 rename_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 report_analysis_coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 report_annotated_check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 report_annotated_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580 report_annotated_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 report_annotated_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587 report_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 report_bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591 report_bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 report_case_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 ix report_cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 report_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 report_clock_gating_check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 report_clock_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 report_clock_tree_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618 report_command_buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619 report_constraint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 report_context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629 report_crpr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631 report_delay_calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636 report_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 report_disable_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651 report_distributed_hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654 report_driver_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655 report_etm_arc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658 report_exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662 report_hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667 report_ideal_network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668 report_lib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672 report_lib_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678 report_min_pulse_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680 report_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682 report_multi_scenario_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686 report_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689 report_noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692 report_noise_calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695 report_noise_parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 report_noise_violation_sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 report_path_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703 report_port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705 report_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708 report_power_calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 report_power_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723 report_power_rail_mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 report_qtm_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727 report_reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730 report_register_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 report_scale_parasitics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733 x report_scope_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734 report_si_aggressor_exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736 report_si_bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740 report_si_delay_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 report_si_double_switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 report_si_noise_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752 report_switching_activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757 report_timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 report_timing_derate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784 report_transitive_fanin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787 report_transitive_fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789 report_units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 report_user_sensitization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793 report_variation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795 report_wire_load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800 reset_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802 reset_mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803 reset_noise_parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806 reset_path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 reset_scale_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811 reset_switching_activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812 reset_timing_derate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816 restore_session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 save_qtm_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 save_session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822 scale_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 set_active_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826 set_annotated_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828 set_annotated_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 set_annotated_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 set_annotated_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837 set_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 set_case_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842 set_clock_gating_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844 set_clock_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847 set_clock_latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851 set_clock_sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 set_clock_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 xi set_clock_uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858 set_connection_class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862 set_constraint_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864 set_context_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865 set_coupling_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867 set_coupling_separation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870 set_data_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872 set_delcalc_resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875 set_disable_clock_gating_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876 set_disable_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877 set_distributed_parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881 set_distributed_variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 set_dont_touch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885 set_dont_touch_network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887 set_dpcm_rail_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888 set_drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890 set_drive_resistance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 set_driving_cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 set_equal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899 set_false_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901 set_fanout_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 set_ideal_latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 set_ideal_network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909 set_ideal_transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 set_input_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913 set_input_noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 set_input_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 set_lcd_pulse_width_multipliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 set_lib_rail_connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923 set_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924 set_max_area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928 set_max_capacitance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929 set_max_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931 set_max_fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936 set_max_time_borrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938 set_max_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940 set_min_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942 set_min_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944 xii set_min_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949 set_min_pulse_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951 set_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953 set_multi_scenario_license_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 set_multicycle_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958 set_noise_derate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965 set_noise_immunity_curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967 set_noise_lib_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969 set_noise_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970 set_noise_parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972 set_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974 set_opposite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978 set_output_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980 set_parasitic_corner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985 set_port_fanout_number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987 set_program_options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988 set_propagated_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990 set_qtm_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992 set_qtm_global_parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994 set_qtm_port_drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996 set_qtm_port_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998 set_qtm_technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000 set_rail_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002 set_resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004 set_rtl_to_gate_name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006 set_si_aggressor_exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008 set_si_delay_analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010 set_si_delay_disable_statistical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013 set_si_noise_analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014 set_si_noise_disable_statistical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017 set_steady_state_resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018 set_switching_activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020 set_timing_derate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025 set_user_attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030 set_user_sensitization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032 set_variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036 set_variation_analysis_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037 set_variation_correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041 xiii set_variation_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043 set_wire_load_min_block_size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045 set_wire_load_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046 set_wire_load_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047 set_wire_load_selection_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049 sh_list_key_bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051 sizeof_collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056 sort_collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057 start_gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059 stop_gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060 sub_variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061 swap_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062 terminate_distributed_farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065 translate_stamp_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071 update_noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072 update_power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074 update_scope_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076 update_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078 write_arrival_annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079 write_astro_changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081 write_changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083 write_context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086 write_ilm_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089 write_ilm_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091 write_interface_timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097 write_parasitics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100 write_physical_annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102 write_pi_parasitics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105 write_saif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107 write_script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109 write_sdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111 write_sdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115 write_sdf_constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121 write_spice_deck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125 xiv add_distributed_hosts Add one or more distributed hosts for distributed jobs. SYNTAX int add_distributed_hosts [-32bit] -farm lsf | grd | generic | now [-setup_path setup_path] [-num_of_hosts count] [-options string] [work_station_name] ARGUMENTS -32bit Specifies that the architecture of the selected distributed host(s) is 32bit. If not specified the default value is native architecture; i.e. 32bit on 32bit systems, and 64bit on 64bit systems. -farm lsf | grd | generic | now This option is used to specify the type of the farm from which the distributed hosts are to be acquired. -setup_path path This option specifies the path to the submission scripts/executables for farms of type lsf/grd/generic. The path should contain the following scripts/ executables. -farm lsf the setup_path should contain "qsub", "qdel" -farm grd the setup_path should contain "bsub", "bkill" -farm generic the setup_path should contain "gsub", "gdel" The -setup_path option is not valid with -farm now -[options string] This option is used only in conjunction with -farm lsf | grd | generic. It is a list of arguments to be passed off to the submission_script used for job submission to a lsf, grd or generic queue. -[num_of_hosts count] The user can specify the number of hosts to use in an lsf, grd, generic, or now compute environment. The number must be at least 1. If this option is not specified then the number of hosts is 1. workstation_name Specifies a single UNIX machine. This option is used only in conjuction with -farm now. DESCRIPTION The options for add_distributed_hosts depend on whether the user has an on-site load balancing capability and whether they wish to use it or not. add_distributed_hosts 1 If on-site load balanced facilities are available these should be specified using the -farm lsf, -farm grd or -farm generic options, depending on the type of resource available. If no on-site load balancing capabilities are available or there are other compute resources available that are not under load balancing control, these should be specified using the -farm now hostname method. All combinations of resources are concurrently supported by command, however, each separate type must be specified independently with a separate invocation of the add_distributed_hosts command. EXAMPLES In the following example, two hosts are added for a distributed command. The first host, platinum1, is specified to have 2 hosts and the second, platinum2, is specified to have 4 hosts. The processes on platinum1 will be 64 bit where as the processes on platinum2 will be 32 bit. Notice that the actual number of processors in platinum1 and platinum2 is irrelevant but for optimal performance the number or processes allocated should match the processors in each machine i.e. 2 processors in platinum1 and 4 processors in platinum2. pt_shell add_distributed_hosts -farm now -num_of_hosts 2 platinum1 1 pt_shell add_distributed_hosts -farm now -num_of_hosts 4 platinum2 -32bit 1 To use this command where on-site load balancing capabilities (LSF/GRD/GENERIC) are in place, use options -farm grd, -farm lsf, or -farm generic. In the example below, populate the distributed hosts list by defining four 32 bit hosts from a lsf farm, and two 64 bit hosts from a grd farm. pt_shell add_distributed_hosts -farm lsf -setup_path "/bin/lsf/" -options { -R "tmp300" -q} -num_of_hosts slaves 4 -32bit 1 pt_shell add_distributed_hosts -farm grd -setup_path "/bin/grd/" -options {-cwd -V -r y -P bnormal -l} -num_of_hosts slaves 2 1 add_distributed_hosts 2 add_to_collection Adds objects to a collection, resulting in a new collection. The base collection remains unchanged. SYNTAX collection add_to_collection base_collection object_spec [-unique] collectionbase_collection list object_spec ARGUMENTS base_collection Specifies the base collection to which objects are to be added. This collection is copied to the result collection, and objects matching object_spec are added to the result collection. base_collection can be the empty collection (empty string), subject to some constraints, explained in the DESCRIPTION. object_spec Specifies a list of named objects or collections to add. If the base collection is heterogeneous, only collections can be added to it. If the base collection is homogeneous, the object class of each element in this list must be the same as in the base collection. If it is not the same class, it is ignored. From heterogeneous collections in the object_spec, only objects of the same class of the base collection are added. If the name matches an existing collection, the collection is used. Otherwise, the objects are searched for in the database using the object class of the base collection. The object_spec has some special rules when the base collection is empty, as explained in the DESCRIPTION. -unique Indicates that duplicate objects are to be removed from the resulting collection. By default, duplicate objects are not removed. DESCRIPTION The add_to_collection command allows you to add elements to a collection. The result is a new collection representing the objects in the object_spec added to the objects in the base collection. Elements that exist in both the base collection and the object_spec, are duplicated in the resulting collection. Duplicates are not removed unless you use the -unique option. If the object_spec is empty, the result is a copy of the base collection. If the base collection is homogeneous, the command searches in the database for any elements of the object_spec that are not collections, using the object class of the add_to_collection 3 base collection. If the base collection is heterogeneous, all implicit elements of the object_spec are ignored. When the base_collection argument is the empty collection, some special rules apply to the object_spec. If the object_spec is non-empty, there must be at least one homogeneous collection somewhere in the object_spec list (its position in the list does not matter). The first homogeneous collection in the object_spec list becomes the base collection and sets the object class for the function. The examples show the different errors and warnings that can be generated. For background on collections and querying of objects, see the collections man page. EXAMPLES The following example from PrimeTime (using the get_ports command) gets all ports beginning with ’mode’, then adds the "CLOCK" port. pt_shell set xports [get_ports mode*] {"mode[0]", "mode[1]", "mode[2]"} pt_shell add_to_collection $xports [get_ports CLOCK] {"mode[0]", "mode[1]", "mode[2]", "CLOCK"} The following example from PrimeTime adds the cell u1 to a collection containing the SCANOUT port. pt_shell set sp [get_ports SCANOUT] {"SCANOUT"} pt_shell set het [get_cells u1] {"u1"} pt_shell query_objects -verbose [add_to_collection $sp $het] {"port:SCANOUT", "cell:u1"} The following examples show how add_to_collection behaves when the base collection is empty. Adding two empty collections yields the empty collection. Adding an implicit list of only strings or heterogeneous collections to the empty collection generates an error message, because no homogeneous collections are present in the object_spec list. Finally, as long as one homogeneous collection is present in the object_spec list, the command succeeds, even though a warning message is generated. The example uses the variable settings from the previous example. pt_shell sizeof_collection [add_to_collection "" ""] 0 pt_shell set A [add_to_collection "" [list a $het c]] Error: At least one homogeneous collection required for argument ’object_spec’ to add_to_collection when the ’collection’ argument is empty (SEL-014) pt_shell add_to_collection "" [list a $het $sp]] Warning: Ignored all implicit elements in argument ’object_spec’ to add_to_collection because the class of the base collection could not be determined (SEL-015) {"SCANOUT", "u1", "SCANOUT"} add_to_collection 4 SEE ALSO collections(2), query_objects(2), remove_from_collection(2), sizeof_collection(2). add_to_collection 5 add_variation Sums two or more variations. Returns a collection (that corresponds to this sum variation). SYNTAX collection add_variation variation_list collection variation_list ARGUMENTS variation_list List of the variations to be added up. DESCRIPTION Enables the addition of two or more variations. The sum is a variation. The command creates this sum variation and returns it as a collection. EXAMPLES The following example adds two variations $v1 and $v2 (assuming they have already been created) into collection $vsum, which is a new variation collection. pt_shell set col [add_to_collection $v1 $v2] _sel128 pt_shell set vsum [add_variation $col] _sel129 SEE ALSO create_distribution (2), sub_variation (2), max_variation (2), min_variation (2). add_variation 6 all_clocks Creates a collection of all clocks in the current design. You can assign these clocks to a variable or pass them into another command. SYNTAX collection all_clocks ARGUMENTS None. DESCRIPTION The all_clocks command creates a collection of all clocks in the current design. If you do not define any clocks, the empty collection (empty string) is returned. If you want only certain clocks, use get_clocks to create a collection of clocks matching a specific pattern and optionally pass in filter criteria. EXAMPLES The following example applies the set_propagated_clock command to all clocks in the design. pt_shell set_propagated_clock [all_clocks] SEE ALSO collections(2), create_clock(2), derive_clocks(2), get_clocks(2), set_propagated_clock(2). all_clocks 7 all_connected Creates a collection of objects connected to a net, pin, or port object. You can assign this collection to a variable or pass it into another command. SYNTAX collection all_connected object_spec [-leaf] list object_spec ARGUMENTS object_spec Specifies the object whose connections are returned. This is a collection of one element which is a net, pin, or port collection, or the name of a net, pin, or port. -leaf Specifies that the connections of the net that are being returned should be global or leaf pins. When specified, this gives the leaf pins of a hierarchical net. For non-hierarchical nets, there is no difference in output. DESCRIPTION The all_connected command creates a collection of objects connected to a specified net, pin, or port. The object_spec option is either a collection of exactly one net, pin, or port object, or a name of an object. If it is a name, PrimeTime searches for a net, pin, or port, in that order. If the object_spec refers to a net, the -leaf option can be used to get the global leaf pins of the net. The command returns a collection. The collection can contain nets, ports, pins, or a combination of ports and pins. In the latter case, the ports will be first, followed by the pins. When issued from the command prompt, all_connected behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example shows all objects connected to net "CLOCK": pt_shell query_objects -verbose [all_connected [get_nets CLOCK]] {"port:CLOCK", "pin:U1/CP", "pin:U2/CP", "pin:U3/CP", "pin:U4/CP"} all_connected 8 SEE ALSO collections (2), get_nets (2), get_pins (2), query_objects (2). collection_result_display_limit(3). all_connected 9 all_fanin Creates a collection of pins/ports or cells in the fanin of specified sinks. SYNTAX collection all_fanin -to sink_list [-flat] [-only_cells] [-startpoints_only] [-levels level_count] [-pin_levels pin_count] [-step_into_hierarchy] list sink_list int level_count ARGUMENTS -to sink_list Specifies a list of sink pins, ports, or nets in the design. Each object is a named pin, port, or net, or a collection of pins, ports, or nets. The timing fanin of each sink in sink_list becomes part of the resulting collection. If a net is specified, the effect is the same as listing all driver pins on the net. This argument is required. -startpoints_only When this option is specified, only the timing startpoints will be included in the result. -only_cells The result will include only cells in the timing fanin of the sink_list and not pins or ports. -flat There are two major modes in which all_fanin functions: hierarchical (the default) and flat. When in hierarchical mode, only objects within the same hierarchical level as the current sink are included in the result. In flat mode, the only non-leaf objects in the result will be hierarchical sink pins. -levels cell_count The traversal will stop when reaching a depth of search of cell_count hops, where the counting is performed over the layers of cells of same distance from the sink. -pin_levels pin_count The traversal will stop when reaching a depth of search of pin_count hops, where the counting is performed over the layers of pins of same distance from the sink. -step_into_hierarchy This option may only be used in hierarchical mode and only has effect with either -levels or -pin_levels. Without the switch, a hierarchical block at the same level of hierarchy as the current sink is considered to be a cell; all_fanin 10 the input pins are considered a single level away from the related output pins, regardless of what is inside the block. With the switch enabled, the counting is performed as though the design were flat, and although pins inside the hierarchy are not returned, they determine the depth of the related output pins. DESCRIPTION The all_fanin command creates a collection of objects in the timing fanin of specified sink pins/ports or nets in the design. A pin is considered to be in the timing fanin of a sink if there is a timing path through combinational logic from the pin to that sink. The fanin stops at the clock pins of registers (sequential cells). If current instance in the design is not the top level of hierarchy, only objects within the current instance will be returned. EXAMPLES This example shows the timing fanin of a port in the design. The fanin includes a register, reg1. pt_shell query_objects [all_fanin -to out_1] {"out_1", "reg1/Q", "reg1/CP"} This example shows the flat mode of all_fanin. The sink is an input pin of a hierarchical cell, H1, which is connected to an output pin of another hierarchical cell, H2. H2 contains additional hierarchy and eventually, a leaf cell with 2 inputs, each of which has a top level register in its fanin. pt_shell query_objects [all_fanin -to H1/a -flat] {"H1/a", "H2/U1/n1/Z", "H2/U1/n1/A", "H2/U1/n1/B", "reg1/Q", "reg2/Q", "reg1/CP", "reg2/CP"} SEE ALSO all_fanout (2), report_transitive_fanin (2), current_instance (2). all_fanin 11 all_fanout Creates a collection of pins/ports or cells in the fanout of the specified sources. SYNTAX collection all_fanout -from source_list -clock_tree [-flat] [-only_cells] [-endpoints_only] [-levels level_count] [-pin_levels pin_count] [-step_into_hierarchy] list source_list int level_count ARGUMENTS -from source_list Specifies a list of source pins, ports, or nets in the design. Each object is a named pin, port, or net, or a collection of pins, ports, or nets. The timing fanout of each source in source_list becomes part of the resulting collection. If a net is specified, the effect is the same as listing all load pins on the net. This option is exclusive with the -clock_tree option. -clock_tree Indicates that all clock source pins and/or ports in the design are to be used as the list of sources. Clock sources are specified using create_clock. If there are no clocks, or if the clocks have no sources, the result is the empty collection. This option is exclusive with the -from option. -endpoints_only When this option is specified, only the timing endpoints will be included in the result. -only_cells The result will include only cells in the timing fanout of the source_list and not pins or ports. -flat There are two major modes in which all_fanout functions: hierarchical (the default) and flat. When in hierarchical mode, only objects within the same hierarchical level as the current source are included in the result. In flat mode, the only non-leaf objects in the result will be hierarchical source pins. -levels cell_count The traversal will stop when reaching a depth of search of cell_count hops, where the counting is performed over the layers of cells of same distance from the source. -pin_levels pin_count The traversal will stop when reaching a depth of search of pin_count hops, all_fanout 12 where the counting is performed over the layers of pins of same distance from the source. -step_into_hierarchy This option may only be used in hierarchical mode and only has effect with either -levels or -pin_levels. Without the switch, a hierarchical block at the same level of hierarchy as the current sink is considered to be a cell; the output pins are considered a single level away from the related input pins, regardless of what is inside the block. With the switch enabled, the counting is performed as though the design were flat, and although pins inside the hierarchy are not returned, they determine the depth of the related input pins. DESCRIPTION The all_fanout command creates a collection of objects in the timing fanout of specified source pins/ports or nets in the design. A pin is considered to be in the timing fanout of a source if there is a timing path through combinational logic from that source to the pin. The fanout stops at the inputs to registers (sequential cells). The sources are specified using either -clock_tree or -from source_list. If current instance in the design is not the top level of hierarchy, only objects within the current instance will be returned. EXAMPLES This example shows the timing fanout of a port in the design. The fanout includes a register, reg3. pt_shell query_objects [all_fanout -from in1] {"in1", "reg3/D"} This example shows the difference between the hierarhical and flat modes of all_fanout. The source is an output pin of a hierarchical cell, H3/z1, which is connected to an input pin of another hierarchical cell, H4/a. H4 contains contains a leaf cell U1 with input A and output Z. The first command is hierarchical mode, and shows that hierarchical pins are included in the result. The second command is in leaf mode, and leaf pins from the lower level are included. pt_shell query_objects [all_fanout -from H3/z1] {"H3/z1", "H4/a", "H4/z", "reg2/D"} pt_shell query_objects [all_fanout -from H3/z1 -flat] {"H3/z1", "H4/U1/A", "H4/U1/Z", "reg2/D"} all_fanout 13 SEE ALSO all_fanin (2), report_transitive_fanin (2), current_instance (2). all_fanout 14 all_inputs Creates a collection of all input ports in the current design. You can assign these ports to a variable or pass them into another command. SYNTAX collection all_inputs [-level_sensitive] [-edge_triggered] [-clock clock_name] list clock_name ARGUMENTS -level_sensitive Only considers ports with level-sensitive input delay. This is specified by set_input_delay 2 -clock CLK -level_sensitive IN1. -edge_triggered Only considers ports with edge-triggered input delay. This is specified by set_input_delay 2 -clock CLK IN2. -clock clock_name Only considers ports with input delay relative to a specific clock. This can be the name of a clock, or a collection containing a clock. DESCRIPTION The all_inputs command creates a collection of all input or inout ports in the current design. You can limit the contents of the collection by specifying the type of input delay that must be on a port. If you want only certain ports, use get_ports to create a collection of ports matching a specific pattern and optionally passing filter criteria. When issued from the command prompt, all_inputs behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example specifies a driving cell for all input ports. pt_shell set_driving_cell -lib_cell FFD3 -pin Q [all_inputs] all_inputs 15 SEE ALSO collections (2), get_ports (2), report_port (2), query_objects (2), set_driving_cell (2), set_input_delay (2). collection_result_display_limit(3). all_inputs 16 all_instances Creates a collection of all instances of a specific design (or library cell) in the current design, relative to the current instance. You can assign the resulting collection of cells to a variable or pass it into another command. SYNTAX collection all_instances [-hierarchy] object_spec ARGUMENTS -hierarchy Searches for instances in all levels of instance hierarchy below the current instance. By default, only instances from the current level of hierarchy are considered. object_spec Specifies the target design or library cell. This can be a design collection, a lib_cell collection, or a name. DESCRIPTION The all_instances command creates a collection of cells that are instances of a design or library cell. The search for instances is made relative to the current instance within the current design. By default, all_instances considers only instances at the current level of the hierarchy. If you use the -hierarchy option, the search continues throughout the hierarchy. The object_spec can be a simple name. In this case, any instance of a design or lib_cell with that name will match. Alternatively, the object_spec can be a collection of exactly one design or one library cell. Any other collection will result in an error message. Using the collection can help focus the search for instances of specific designs or lib_cells, especically after swap_cell has been used. When issued from the command prompt, all_instances behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example uses all_instances to get the instances of the design ’low’ in the current level of hierarchy. pt_shell all_instances low {"U1", "U3"} all_instances 17 The following example uses -hierarchy to display instances of a design across multiple levels of hierarchy. pt_shell query_objects [all_instances low -hierarchy] {"U1", "U2/U1", "U3"} In the following example, there are two instances of design "inter". One of them is swapped for a new design. The difference between using all_instances with a name and a collection of one design is shown. pt_shell swap_cell i1 inter_2.db:inter 1 pt_shell all_instances inter {"i1", "i2"} pt_shell all_instances [get_designs inter_2.db:inter] {"i1"} SEE ALSO collections (2), current_design (2), current_instance (2), get_designs (2), get_lib_cells (2), get_cells (2), list_designs (2), query_objects (2). collection_result_display_limit(3). all_instances 18 all_outputs Creates a collection of all output ports in the current design. You can assign these ports to a variable or pass them into another command. SYNTAX collection all_outputs [-level_sensitive] [-edge_triggered] [-clock clock_name] list clock_name ARGUMENTS -level_sensitive Only considers ports with level-sensitive output delay. This is specified by set_output_delay 2 -clock CLK -level_sensitive IN1. -edge_triggered Only considers ports with edge-triggered output delay. This is specified by set_output_delay 2 -clock CLK IN2. -clock clock_name Only considers ports with output delay relative to a specific clock. This can be the name of a clock, or a collection containing a clock. DESCRIPTION The all_outputs command creates a collection of all output or inout ports in the current design. You can limit the contents of the collection by specifying the type of output delay that must be on a port. If you want only certain ports, use get_ports to create a collection of ports matching a specific pattern and optionally passing filter criteria. When issued from the command prompt, all_outputs behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example specifies a pin capacitance for all output ports. pt_shell set_load 4.56 [all_outputs] all_outputs 19 The following example shows the names all of the output ports with output delay relative to PHI1. pt_shell all_outputs -clock PHI1 SEE ALSO collections (2), get_ports (2), report_port (2), query_objects (2), set_output_delay (2). collection_result_display_limit(3). all_outputs 20 all_registers Creates a collection of register cells or pins. You can assign the resulting collection to a variable or pass it into another command. SYNTAX collection all_registers [-clock clock_name] [-rise_clock rise_clock_name] [-fall_clock fall_clock_name] [-cells] [-data_pins] [-clock_pins] [-slave_clock_pins] [-async_pins] [-output_pins] [-level_sensitive] [-edge_triggered] [-master_slave] [-no_hierarchy] list clock_name list rise_clock_name list fall_clock_name ARGUMENTS -clock clock_name Considers all registers clocked by clock_name. This is either the name of a clock, or a collection containing a clock. For example, all registers whose clock pins are in the fan out of the specified clock. -rise_clock rise_clock_name Considers all registers clocked by rise_clock_name and having open edge effectively the rising clock edge. This is either the name of a clock, or a collection containing a clock. For example, rising edge triggered flip flops without any inversion on the clock path or falling edge triggered flip flops with inversion on the clock path. -fall_clock fall_clock_name Considers all registers clocked by fall_clock_name and having open edge effectively falling the clock edge. This is either the name of a clock, or a collection containing a clock. For example, rising edge triggered flip flops with inversion on the clock path or falling edge triggered flip flops without any inversion on the clock path. -cells Creates a collection of cells (default). The cells are registers and are further limited by other command options. -data_pins Creates a collection of register data pins. The collection can be limited by other command options. -clock_pins Creates a collection of register clock pins. The collection can be limited by other command options. -slave_clock_pins Creates a collection of register slave clock pins (the slave clock pins of master-slave registers). Specify slave clock pins as clocked_on_also in the library. all_registers 21 -async_pins Creates a collection of async preset or clear pins. -output_pins Creates a collection of register output pins. -level_sensitive Limits search to level-sensitive latches. -edge_triggered Limits search to edge-triggered flip-flops. -master_slave Only considers master or slave register cells. -no_hierarchy Only searches the current instance; does not decend the hierachy. DESCRIPTION The all_registers command creates a collection of pins or cells related to registers. When issued from the command prompt, all_registers behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. For information about collections and the querying of objects, see the collections man page. EXAMPLES This example performs a trace from a port to all register clock pins which are clocked by CLK. pt_shell report_timing -from [get_ports {CLK}] \ -to [all_registers -clock CLK clock_pins] **************************************** Report : timing -path full -delay max -max_paths 1 Design : counter Version: 1997.01-development Date : Thu Jul 25 14:23:48 1996 **************************************** Startpoint: CLK (input port clocked by CLK) Endpoint: ffa/CP (internal pin) Path Group: (none) Path Type: max all_registers 22 Point Incr Path --------------------------------------------------------------- input external delay 0.00 0.00 r CLK (in) 0.00 0.00 r ffa/CP (FD2) 0.00 0.00 r data arrival time 0.00 --------------------------------------------------------------- (Path is unconstrained) The following example performs a trace from all registers clock pins, which are triggered by clock rising edge. pt_shell report_timing -from [all_registers -rise_clock \ CLK -clock_pins] **************************************** Report : timing -path full -delay max -max_paths 1 Design : li_FD3x Version: 2002.03-SI1 Date : Tue Nov 13 11:07:29 2001 **************************************** Startpoint: ff3 (falling edge-triggered flip-flop clocked by clk’) Endpoint: ff4 (falling edge-triggered flip-flop clocked by clk’) Path Group: clk Path Type: max Point Incr Path --------------------------------------------------------------- clock clk’ (fall edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 ff3/CP (FD3x) 0.00 0.00 f ff3/Q (FD3x) 1.44 1.44 f iv2/Z (IVA) 0.31 1.75 r ff4/D (FD3x) 0.00 1.75 r data arrival time 1.75 clock clk’ (fall edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 ff4/CP (FD3x) 10.00 f library setup time -0.90 9.10 data required time 9.10 --------------------------------------------------------------- data required time 9.10 data arrival time -1.75 --------------------------------------------------------------- slack (MET) 7.35 all_registers 23 SEE ALSO collections(2), get_cells(2), get_pins(2). collection_result_display_limit(3). all_registers 24 append_to_collection Add object(s) to a collection. Modifies variable. SYNTAX collection add_to_collection var_name object_spec [-unique] collection var_name list object_spec ARGUMENTS var_name Specifies a variable name. The objects matching object_spec are added into the collection referenced by this variable. object_spec Specifies a list of named objects or collections to add. -unique Indicates that duplicate objects are to be removed from the resulting collection. By default, duplicate objects are not removed. DESCRIPTION The append_to_collection command allows you to add elements to a collection. This command treats the variable name given by var_name as a collection, and appends all of the elements in object_spec to that collection. If the variable does not exist, it is created as a collection with elements from object_spec as its value. If the variable does exist, and it does not contain a collection, it is an error. The result of the command is the collection which was initially referenced by var_name, or the collection created if the variable did not exist. The append_to_collection command is provides the same semantics as a common use of add_to_collection but with significant improvement in performance. An example of replacing add_to_collection with append_to_collection is given below. set var_name [add_to_collection $var_name $objs] Using add_to_collection this becomes: append_to_collection var_name $objs The append_to_collection command can be much more efficient than add_to_collection if you are building up a collection in a loop. The arguments of the command have the same restrictions as the add_to_collection command. Please see the add_to_collection append_to_collection 25 man page for more information about those restrictions. EXAMPLES The following example from PrimeTime shows how a collection can be built up with append_to_collection: pt_shell set xports Error: can’t read "xports": no such variable Use error_info for more info. (CMD-013) pt_shell append_to_collection xports [get_ports in*] {"in0", "in1", "in2"} pt_shell append_to_collection xports CLOCK {"in0", "in1", "in2", "CLOCK"} SEE ALSO add_to_collection (2), foreach_in_collection (2), index_collection (2), remove_from_collection (2), sizeof_collection (2). append_to_collection 26 cell_of Creates a collection of cells of the given pins. The cell_of command is a DC Emulation command provided for compatibility with Design Compiler. SYNTAX string cell_of object_list list object_list ARGUMENTS object_list A list of pins for which to get cells. DESCRIPTION The cell_of command creates a collection of cells owned by a list of pins. The command exists in PrimeTime for compatibility with Design Compiler. Complete information about the cell_of command can be found in the Design Compiler documentation. The supported method for getting pins of cells is to use the get_cells command with the -of_objects option. SEE ALSO get_cells (2). cell_of 27 change_histogram Changes the graph and display attributes of an existing histogram. SYNTAX int change_histogram [-numbins number_of_bins] [-min min_value] [-max max_value] [-greater_than gt_value] [-less_than lt_value] [-midpoint mid_value] [-worst worst_side] [-value_label value_label] [-object_name object_name] [-title title_label] [-xlabel x_axis_label] [-ylabel y_axis_label] -view view_to_use int number_of_bins float min_value float max_value float gt_value float lt_value float mid_value stringworst_side stringvalue_label stringobject_name stringtitle_label stringx_axis_label stringy_axis_label stringview_to_use ARGUMENTS -numbins number_of_bins An integer in the range of 1 to 300, that specifies the number of bins to use when changing the histogram. -min min_value Specifies the minimum value to use in binning objects. Any object whose associated value is less than this value is to be dropped from the histogram with a warning message. -max max_value Specifies the maximum value to use in binning objects. Any object whose associated value is greater than this value is to be dropped from the histogram with a warning message. -greater_than gt_value Specifies the non-inclusive least value limit to use in binning objects. Any change_histogram 28 object whose associated value is less than or equal to this value is to be dropped from the histogram with a warning message. -less_than gt_value Specifies the non-inclusive greatest value limit to use in binning objects. Any object whose associated value is greater than or equal to this value is to be dropped from the histogram with a warning message. -midpoint mid_value Specifies the midpoint value to use in interpreting histogram bins. An x-axis tick mark is placed on the midpoint value and all bins to the worst side of the midpoint are colored red while all bins to the other side of the midpoint are colored green. The worst side is none by default but can be set to left or right using the -worst option. -worst worst_side Specifies whether values less than or greater than the midpoint are to be considered "worst." Allowed values are left, meaning that values less than midpoint are worse; right, meaning that values greater than the midpoint are worse; and none (the default), meaning that neither is worse. -value_label value_label Specifies the label to place at the head of the value column in the list view accompanying the histogram. -object_name object_name Specifies the label to place at the head of the object name column in the list view accompanying the histogram. -title title_label Specifies the label to place at the top of the histogram graph. -xlabel x_axis_label Specifies the label to place along the X axis of the histogram graph. -ylabel y_axis_label Specifies the label to place along the Y axis of the histogram graph. -view name_of_view Specifies the name of the histogram whose graph attributes are to be changed by the command. This argument is required. DESCRIPTION The change_histogram command changes the graph and display attributes of an existing histogram. If the number of bins, minimum, maximum or midpoint values are changed, the objects are rebinned. Other arguments affect only display attributes (for example, labels). The -view argument is required, and specifies the histogram view to which the new graph and display attributes are to be applied. You can use this command only while the GUI is active; type the command into the command line field at the bottom of the GUI console window. Any graph or display attribute that is not changed by one of the arguments to this command remains unchanged. For default values of the attributes, see the manual page change_histogram 29 for the create_histogram command. EXAMPLES The following example shows changing the histogram graph in the view named "histogram_1" so that the objects are rebinned using 4 bins in the value range greater than 0 and less than 10.0. The title changes to read "0.0 to 10.0". pt_shell change_histogram -title "0.0 to 10.0" -numbins 4 \ -greater_than 0.0 -less_than 10.0 -view histogram_1 1 SEE ALSO create_histogram (2). change_histogram 30 change_selection Changes the selection in the GUI. SYNTAX int change_selection [-name slct_bus] [-replace (default) ] [-add ] [-remove ] [toggle ] [-type object_type] [-clock_trees clock_tree_list] [collection] stringslct_bus stringobject_type list clock_tree_list list collection ARGUMENTS -name slct_bus Specifies the selection bus to which the change is made. The default is "global", the default global selection bus. -replace Replace current selection with the objects in the collection. This is the default behavior if no optional parameter is specified. -add Add the objects in the collection to the current selection. -remove Remove the objects that are specified in the collection from current selection. -toggle Toggle the selection state of the objects that are specified in the collection. -type object_type Specifies the type to change. Only those items from the collection that are of the type specified will be used to change the selection. If not specified, the entire collection is used. The object_type can be one of the following: Type design port net cell pin path (timing path) -clock_trees clock_tree_list The list of clock trees to use to change the selection. The type of change that is applied to the current selection with the clock tree list is specified by the optional parameters listed above. change_selection 31 collection The collection of objects to use to change the selection. The type of change that is applied to the current selection with the collection is specified by the optional parameters listed above. DESCRIPTION The change_selection command changes the selection in the GUI. When selections are changed, the GUI will update all the relevant windows to reflect this change. A collection of objects and the type of change are given as inputs to the command. The collection of objects could be returned as the result of another command such as the get_designs command. If the collection is empty and the -replace option is specified (or no option specified), the current selection will be cleared. If the -type option is used, only the type of objects specified will be used to change the current selection. For example, if a -type design is used, only the design objects in the collection are used to change the current selection. If no type option is specified, all the objects in the collection will be used to change the current selection. For example, if the option -add is used with no -type, then all the objects, regardless of type of object, will be added to the current selection. For information about collections, see the collections man page. EXAMPLES The following example replaces the current selection with the collection of design objects, regardless of type. pt_shell change_selection [get_designs] The next example adds cell U5 to the selection. pt_shell change_selection -add [get_cells U5] The next example removes all the objects of type pin from the current selection. pt_shell change_selection -remove -type pin [get_selection] The last example clears all the selection. pt_shell change_selection "" SEE ALSO collections(2), filter(2), filter_collection(2), get_selection(2), query_objects(2) change_selection 32 characterize_context Captures the timing context of a list of instances. SYNTAX string characterize_context [-timing] [-environment] [-design_rules] [-constant_inputs] [-no_boundary_annotations] cell_list list cell_list ARGUMENTS -timing Characterizes timing information; for example, clocks, input and output delays, and timing exceptions. -environment Characterizes environment-related information; for example, operating conditions (process, temperature, and voltage), wire load model, capacitive loads on input and output pins, and driving cell information on input pins. -design_rules Characterizes design rules; for example, max_capacitance, max_transition, and max_fanout. -constant_inputs Characterizes logic constants propagated to input pins of the instance being characterized by the case analysis capability of PrimeTime. -no_boundary_annotations Disables characterization of annotated capacitance on boundary nets as annotated capacitance in the characterized instance. Instead, the port wire capacitance is adjusted to account for any difference between the estimated and annotated values. By default, PrimeTime characterizes annotated capacitance on boundary nets as annotated capacitance in the characterized instance. cell_list Specifies a list of instances to characterize. DESCRIPTION Captures the timing context of instances of subdesigns from the chip-level timing environment. The timing context of an instance is defined as waveforms of the clocks affecting this instance, input arrival times, output required times, timing exceptions, design rules, propagated constants, wire load models, input drives, and capacitive loads. characterize_context 33 The characterize_context command does not capture delays and parasitics annotated on the internal nets of the instance being characterized. To capture this information, use the write_physical_annotations command without the -boundary_nets option. All categories are characterized if no option is specified. To characterize one or more categories of interest, specify the respective option or list of options. EXAMPLES The following command derives only the timing-related context information for instance I1 and I2. pt_shell characterize_context -timing {I1 I2} The following command derives the design rule and the logic constant information from the context of cell I2. pt_shell characterize -constant_inputs -design_rules I2 SEE ALSO remove_context (2), report_context (2), write_context (2), write_physical_annotations (2). characterize_context 34 check_block_scope Checks the scope of hierarchical blocks that were replaced with timing models during the top-level analysis. SYNTAX int check_block_scope -instances instance_list [-scope_scenario scenario_name] [-check_types chk_types] [-significant_digits digits] [-absolute_clock_arrival] [-nosplit] [-verbose] file_name ARGUMENTS -instances instance_list Specifies the list of instances for which scope needs to be verified. The scope information for the blocks corresponding to these instances should be contained in the file specified by the file_name option. -scope_scenario scenario_name Specifies the scenario name for which the scope data needs to be used to verifie the top-level instantiation of the block as timing models. The scope information in the data file should contain data corresponding to the given scenario. If not specified, a fixed default name is used internally. -check_types chk_types Specifies the types of scope checks to be performed. By default, when this option is not specified, the types of checks defined by environment variable hier_scope_check_defaults will be performed. Use this option to overrides the globally defined default scope check types. -significant_digits digits Specifies the number of digits after the decimal point to be displayed for time values in the generated report. Allowed values are 0-13; the default is determined by the report_default_significant_digits variable, whose default value is 2. Use this option if you want to override the default. This option controls only the number of digits displayed, not the precision used internally for analysis. For analysis, PrimeTime uses the full precision of the platform’s fixed-precision, floating-point arithmetic capability. -absolute_clock_arrival Indicates that the clock arrival times reach the block boundary pins are to be checked as aboslute rather than relative latency values against those captured as scope information during original block-level analysis. By default, when this option is not used, the arrival windows for clock signals are checked as relative arrival requirements. See DESCRIPTION below for more information. check_block_scope 35 -nosplit Specifies that the printed report should not split the lines even when they become long and unfit for the line column number settings. By default, the report lines will be split if necessary. DESCRIPTION This command should be used while performing top-level analysis in a bottom-up hierarchical design flow. At the block-level, timing analysis has been performed and a timing model is created via the create_ilm or the extract_model command. In addition, scope data can be generated for the models by specifying appropriate options to these two commands. The check_block_scope command checks the scope of block instances to make sure that the timing model accurately reflects the full block. The checks that are performed are dictated by the variable hier_scope_check_defaults. More information on the relative clock arrival checking. For a given block, when multiple clocks interact with each other and therefore should be maintained synchronous to each other, it indicates that the relative skews among these clocks should be maintained in order to safely move the analysis from block-level to toplevel. It is not necessary to require for each and every clock that the absolute arrival times at the block boundary for all instances of the block remain unchanged. It is sufficient for all these clocks to incur a similar amount of insertion delay when propagate through their top-level clock trees before reaching the block boundary as long as their inter-clock skew relations are maintained. This is also applicable to blocks with only one clock. When the option -absolute_clock_arival is not specified, PrimeTime will automatically derive a best common shift, seperately for each synchronous clocking domain and each instance of the block need to be checked, based on the original arrival windows captured into the scope file and the actual arrival windows obtained at top-level. This global shift is then uniformly applied across all the clocks in that domain such that the number of scope violations reported is minimized. Note that for the same block, different global shift may be derived for different instances. The goal of deriving and applying the global shift is to minimize the scope violations reported and therefore need to be fixed potentially. It may or may not correlate directly to the actual common insertion delay for all the related clocks in that domain of an instance of the block. This flow can be used in both PrimeTime and PrimeTime SI. EXAMPLES This example uses the scope information saved in top/ilm.scope file to verify that the timing models for instances I1 and I2 are within the validated scope of the block. pt_shell check_block_scope -instances {I1 I2} top/ilm.scope check_block_scope 36 SEE ALSO create_ilm (2). extract_model (2). create_scenario (2). hier_scope_check_defaults (3). check_block_scope 37 check_level_shifter SYNTAX int check_level_shifter [-verbose] ARGUMENTS -verbose Prints a detailed report of all possible violations. DESCRIPTION In PrimeTime, the check_level_shifter command is an alias for: check_timing -override_defaults {signal_level} SEE ALSO check_timing (2). check_level_shifter 38 check_power Shows possible power problems for design. SYNTAX string check_power [-verbose] [-significant_digits digits] [-override_defaults check_list] [-include check_list] [-exclude check_list] float delta int digits list check_list ARGUMENTS -verbose Shows detailed information about potential problems. -significant_digits digits Specifies the number of digits of precision to be displayed by warnings that show floating point numbers. Allowed values are 0-13; the default is determined by the report_default_significant_digits variable, whose default value is 2. Use this option if you want to override the default. -override_defaults check_list Overrides the checks in power_check_defaults using check_list. See the man page of power_check_defaults for its default value. -include check_list Adds the checks listed in check_list to the checks in power_check_defaults. -exclude check_list Subtracts the checks listed in check_list from the checks in power_check_defaults. check_list Gives the list of checks to be performed. Each element in this list is one of the following strings: no_arrival_window, no_base_clock, out_of_table_range, missing_table. DESCRIPTION The check_power command checks structure of the design for potential power violations. This command is used to identify possible power calculation problems before updating power or before generating power reports. This command also prints which checks it performs. If a check reveals a violation, then the command also prints a message about the violation. By default, the message contains a summary of the violation. To get more information about violations, use check_power 39 the -verbose option. This command without any options performs the checks defined by the power_check_defaults variable. To change the value of this variable, either redefine it or use the -override_defaults option. If the -override_defaults option is not used, the final list of checks to be performed is the checks in power_check_defaults plus the list of checks given by the -include option minus the list of checks given by the -exclude option. If the -override_defaults option is used with a check_list, the final list of checks to be performed is the checks in the check_list given by the option plus the list of checks given by the -include option minus the list of checks given by the -exclude option. The alphabetically ordered list below shows the meaning of each check: missing_table Checks if library cells have leakage power tables and dynamic power tables. no_arrival_window Checks whether pins have arrival window or not. This check helps to generate accurate cycle-based average waveform, zero delay VCD power analysis, and RTL VCD power analysis. In order to save the arrival windows user should set the variable timing_save_pin_arrival_and_slack to true before update_timing/ update_power. Users seeing this violation will be directed to check if timing is correct by using check_timing command. no_base_clock Checks wheter nets have power base clock or not. During updating power, the fastest clock is used as power base clock for these nets which don’t have power base clock. But this exposes some potential accuracy problem. Users seeing this violation will be directed to check if timing is correct by using check_timing. out_of_table_range Checks if there are out-of-range ramp or load violations when looking up power tables for each cells. The out of range values together with cell name and pin name, and library cell name and its range will be displayed if "-verbose" is used. SEE ALSO power_check_defaults(3). check_timing(2). report_constraint(2). check_power 40 check_timing Shows possible timing problems for design. SYNTAX string check_timing [-verbose] [-significant_digits digits] [-ms_min_separation delta] [-override_defaults check_list] [-include check_list] [-exclude check_list] float delta int digits list check_list ARGUMENTS -verbose Shows detailed information about potential problems. -significant_digits digits Specifies the number of digits of precision to be displayed by warnings that show floating point numbers. Allowed values are 0-13; the default is determined by the report_default_significant_digits variable, whose default value is 2. Use this option if you want to override the default. -ms_min_separation delta Minimum separation value between master and slave clocks. The default minimum separation is 0.0. -override_defaults check_list Overrides the checks in timing_check_defaults using check_list. See the man page of timing_check_defaults for its default value. -include check_list Adds the checks listed in check_list to the checks in timing_check_defaults. -exclude check_list Subtracts the checks listed in check_list from the checks in timing_check_defaults. check_list Gives the list of checks to be performed. Each element in this list is one of the following strings: clock_crossing, data_check_multiple_clock, data_check_no_clock, generated_clocks, generic, latch_fanout, latency_override, loops, ms_separation, multiple_clock, no_clock, no_input_delay, retain, signal_level, unconstrained_endpoints. check_timing 41 DESCRIPTION Checks the assertions and structure of the design for potential timing violations. This command is used to identify possible problems before generating timing or constraint reports. This command also prints which checks it performs. If a check reveals a violation, then the command also prints a message about the violation. By default, the message contains a summary of the violation. To get more information about violations, use the -verbose option. This command without any options performs the checks defined by the timing_check_defaults variable. To change the value of this variable, either redefine it or use the -override_defaults option. If the -override_defaults option is not used, the final list of checks to be performed is the checks in timing_check_defaults plus the list of checks given by the -include option minus the list of checks given by the -exclude option. If the -override_defaults option is used with a check_list, the final list of checks to be performed is the checks in the check_list given by the option plus the list of checks given by the -include option minus the list of checks given by the -exclude option. The alphabetically ordered list below shows the meaning of each check: clock_crossing Checks clock interactions when there are multiple clock domains. If a clock launches one or more paths, which are captured by other clocks, it will have an entry in clock crossing report. If all paths between two clocks are false paths or they are exclusive/asynchronous clocks, the path is marked by *. If only part of paths are set as false paths or exclusive/asynchronous clocks, the path is marked by #. data_check_multiple_clock Warns if multiple clocked signals reach a data check register reference pin. The analysis will be done for each of the clocked domain separately. If timing_enable_multiple_clocks_per_reg is set to FALSE, only the one of the clocked signal will be analyzed. data_check_no_clock Warns if no clocked signal reaches a data check register reference pin. In this case, no setup or hold checks are performed on the constrained pin. generated_clocks Checks generated clock network. The master must be driven by a clock source. There cannot be loops of generated clocks. For example, the source of generated clock CLK1 cannot be used to generate clock CLK2 if CLK2 also is used to generate CLK1. generic Warns about generic (unmapped) cells in the design. The timing of paths through generic cells is inaccurate because generic cells have zero delay. ideal_clocks Shows the clocks that are not defined as propagated using the command / fBset_propagated_clock/fP. Generally, all clocks should be propagated so that the clock network timing is accurately calculated. Especially, in presence check_timing 42 of crosstalk, the delay changes induced by other nets on the clock network will not be reflected in the calculated slacks in the design. latch_fanout Checks fanout of level-sensitive latches. A warning is issued if a levelsensitive latch fans out to itself. An information message also appears for a latch that fans out to a latch of the same clock (PHI1 to PHI1 path). latency_override Warns of clock latency specification conflicts. If clock source latency is defined for both a clock and its port (source pin), the source latency for clock object is ignored. If input_delay is set on clock port, which also has source latency specified, the input_delay is ignored as a source latency. Also warns if more than one clock latency fan out to any latch clock pin. loops Warns of combinational feedback loops. Combinational feedback loops are not analyzed. If the feedback loop is not broken by set_disable_timing, it is automatically broken by disabling one or more timing arcs. ms_separation Checks minimum separation of master and slave clock pulses on master/slave latches. multiple_clock Warns if multiple clocks reach a register clock pin. If more than one clock signal reaches a register clock pin, and timing_enable_multiple_clocks_per_reg is set to FALSE, then it is undefined which one is used for analysis. In this case, use set_case_analysis so only one clock can propagate from its sources to the register clock pin. Using this check and the no_clock check run significantly faster than other checks. Hence, to save time, user may want to issue these checks separately from other checks. no_clock Warns if no clock reaches a register clock pin. In this case, no setup or hold checks are performed on data pins related to that clock pin, and the path starting at the clock pin is not relative to a clock. For performance of this check, see the description in the multiple_clock check. no_driving_cell Warns if a port does not have any driving cell. This warning is issued only when the net connected to the port has parasitics. In such case, the accuracy of delay calculation could be impacted, as a default strong driver is assumed in absence of driving cell definition. Especially, in presence of crosstalk, a port with no driving cell could act as a strong aggressor which could lead to significant amount of pessimism in the analysis. Also, a port with no driving cell could act as a string victim, which could underestimate the crosstalk effect. no_input_delay Warns if no clock related delay specified on an input port, where it propagate to a clocked latch or output port. With -verbose, the port name will be listed. Note that with timing_input_port_default_clock set to ’true’, a default clock will be assumed for the input port, else it will not be clocked, check_timing 43 and the paths are unconstrained. partial_input_delay Warns if any port has partially defined input delay. This happens when set_input_delay -min is applied on a port to set the min input delay with respect to a clock, however no set_input_delay -max is applied to that port to specify the max delay, or vice versa. As a result, some paths starting from the port with partially defined input delay may become unconstrained and some potential violations could be missed. retain Warns if any of the RETAIN values is larger than its corresponding delay value. The RETAIN values should be less than their corresponding delay values so that they be considered for hold violations. Otherwise, they may be considered for setup violations. signal_level Checks that the driver signal level matches the load signal level. The signal levels are determined from the cell specific operating conditions and rail voltages, and from the following library attributes: input_signal_level, output_signal_level, input_voltage, output_voltage. The check is performed on all input pins that have input_voltage defined in the timing library. If the driver pin does not have output_voltage defined in the library then the voltage of the rail powering the driver pin (derived from the output_signal_level) is used as the output signal level. If the load pin does not have input_voltage then only a simple report based on the exact matching of driver and load rail voltages is generated. This simplified report shows the first 100 driver-load pin pairs signal level mismatches. unconstrained_endpoints Warns about unconstrained timing endpoints. This warning identifies timing endpoints (output ports and register data pins) that are not constrained for maximum delay (setup) checks. If the endpoint is a register data pin, it can be constrained by using create_clock for the appropriate clock source. You can constrain output ports using the set_output_delay or set_max_delay commands. unexpandable_clocks Warns if there are pairs of clocks for which periods are not expandable with respect to each other. The checking is only done for the clock domains that interact with each other, i.e. when there is at least one path from one clock domain to the other. This could be because of an incorrectly defined clock period for one or more of the clocks. Another possibility is when asynchronous clocks with unexpandable periods are interacting where they should have been defined in different clock domains. EXAMPLES The following example checks timing of the current design and shows summary information of potential problems. The checks performed are those defined by timing_check_defaults. pt_shell check_timing check_timing 44 Information: Checking ’no_clock’. Warning: There are 4 register clock pins with no clock. Information: Checking ’no_input_delay’. Information: Checking ’unconstrained_endpoints’. Warning: There are 10 endpoints which are not constrained for maximum delay. Information: Checking ’generic’. Information: Checking ’latch_fanout’. Warning: There are 2 level-sensitive latches which fanout to themselves. Information: There are 2 level-sensitive latches which fanout to latches of the same clock. Information: Checking ’loops’. Warning: There are 6 timing loops in the design. Information: Checking ’generated_clocks’. The following example adds the clock_crossing check to the list of checks in timing_check_defaults. pt_shell check_timing -include {clock_crossing} Information: Checking ’no_clock’. Warning: There are 4 register clock pins with no clock. Information: Checking ’no_input_delay’. Information: Checking ’unconstrained_endpoints’. Warning: There are 10 endpoints which are not constrained for maximum delay. Information: Checking ’generic’. Information: Checking ’latch_fanout’. Warning: There are 2 level-sensitive latches which fanout to themselves. Information: There are 2 level-sensitive latches which fanout to latches of the same clock. Information: Checking ’loops’. Warning: There are 6 timing loops in the design. Information: Checking ’generated_clocks’. Information: Checking ’clock_crossing’. The following example adds the clock_crossing check to the list of checks in timing_check_defaults and removes the loops check from the same list. pt_shell check_timing -include {clock_crossing} -exclude {loops} Information: Checking ’no_clock’. check_timing 45 Warning: There are 4 register clock pins with no clock. Information: Checking ’no_input_delay’. Information: Checking ’unconstrained_endpoints’. Warning: There are 10 endpoints which are not constrained for maximum delay. Information: Checking ’generic’. Information: Checking ’latch_fanout’. Warning: There are 2 level-sensitive latches which fanout to themselves. Information: There are 2 level-sensitive latches which fanout to latches of the same clock. Information: Checking ’generated_clocks’. Information: Checking ’clock_crossing’. The following example removes the retain option from the list of checks in timing_check_defaults. Assuming that this check is not included in timing_check_defaults, there is nothing to remove. The output in this example is the same as running the command without the -exclude option. pt_shell check_timing -exclude {retain} Information: Checking ’no_clock’. Warning: There are 4 register clock pins with no clock. Information: Checking ’no_input_delay’. Information: Checking ’unconstrained_endpoints’. Warning: There are 10 endpoints which are not constrained for maximum delay. Information: Checking ’generic’. Information: Checking ’latch_fanout’. Warning: There are 2 level-sensitive latches which fanout to themselves. Information: There are 2 level-sensitive latches which fanout to latches of the same clock. Information: Checking ’loops’. Warning: There are 6 timing loops in the design. Information: Checking ’generated_clocks’. The following example checks only latch fanout and shows detailed information. pt_shell check_timing -verbose -override_defaults {latch_fanout} Warning: There are 2 level-sensitive latches which fanout to themselves. Latch data pin -----------------------------------------------------------l3/D check_timing 46 l4/D Information: There are 2 level-sensitive latches which fanout to latches of the same clock. From Pin To Pin Clock Level -------------------------------------------------------------------------------- l1/G l2/D C1 positive l1/G l3/D C1 positive SEE ALSO create_clock (2), report_constraint (2), report_timing (2), set_clock_groups (2), set_case_analysis (2), set_disable_timing (2), set_false_path (2), set_max_delay (2), set_output_delay (2), timing_check_defaults (3), timing_enable_multiple_clocks_per_reg (3), timing_input_port_default_clock (3), report_default_significant_digits (3). check_timing 47 Collections_and_Querying Describes the methodology for creating collections of objects and querying objects in the database. DESCRIPTION Synopsys applications build an internal database of the netlist and the attributes applied to it. This database consists of several classes of objects, including designs, libraries, ports, cells, nets, pins, and clocks. Most commands operate on these objects. By definition: A collection is a group of objects exported to the Tcl user interface. Collections have an internal representation (the objects) and, sometimes, a string representation. The string representation is generally used only for error messages. A set of commands to create and manipulate collections is provided as an integral part of the user interface. The collection commands encompass two categories: those that create collections of objects for use by another command, and one that queries objects for viewing. The result of a command that creates a collection is a Tcl object that can be passed along to another command. For a query command, although the visible output looks like a list of objects (a list of object names is displayed), the result is an empty string. An empty string "" is equivalent to the empty collection, that is, a collection with zero elements. Homogeneous and Heterogeneous Collections A homogeneous collection contains only one type of object. A heterogeneous collection can contain more than one type of object. Commands that accept collections as arguments can accept either type of collection. Lifetime of a Collection Collections are active only as long as they are referenced. Typically, a collection is referenced when a variable is set to the result of a command that creates it or when it is passed as an argument to a command or a procedure. For example, if in PrimeTime you save a collection of ports: pt_shell set ports [get_ports *] then either of the following two commands deletes the collection referenced by the ports variable: pt_shell unset ports pt_shell set ports "value" Collections can be implicitly deleted when they go out of scope. Collections go out Collections_and_Querying 48 of scope when the parent (or other antecedent) of the objects within the collection is deleted. For example, if our collection of ports is owned by a design, it is implicitly deleted when the design that owns the ports is deleted. When a collection is implicitly deleted, the variable that referenced the collection still holds a string representation of the collection. However, this value is useless because the collection is gone, as illustrated in the following PrimeTime example: pt_shell current_design {"TOP"} pt_shell set ports [get_ports in*] {"in0", "in1"} pt_shell remove_design TOP Removing design ’TOP’... pt_shell query_objects $ports Error: No such collection ’_sel26’ (SEL-001) Iteration To iterate over the objects in a collection, use the foreach_in_collection command. You cannot use the Tcl-supplied foreach iterator to iterate over the objects in a collection, because foreach requires a list; and a collection is not a list. In fact, if you use foreach on a collection, it will destroy the collection. The arguments to foreach_in_collection are similar to those of foreach: an iterator variable, the collections over which to iterate, and the script to apply at each iteration. Note that unlike foreach, the foreach_in_collection command does not accept a list of iterator variables. The following example is an iterative way to perform a query. For details, see the foreach_in_collection man page or the user guide. pt_shell \ foreach_in_collection s1 $collection { echo [get_object_name $s1] } Manipulating Collections A variety of commands are provided to manipulate collections. • add_to_collection - Takes a base collection and a list of element names or collections that you want to add to it. The base collection can be the empty collection. The result is a new collection. In addition, the add_to_collection command allows you to remove duplicate objects from the collection by using the unique option. • remove_from_collection - Takes a base collection and a list of element names or collections that you want to remove from it. For example, in PrimeTime: Collections_and_Querying 49 pt_shell set dports \ [remove_from_collection [all_inputs] CLK] {"in1", "in2", "in3"} • compare_collections - Verifies that two collections contain the same objects (optionally, in the same order). The result is "0" on success. • copy_collection - Creates a new collection containing the same objects (in the same order) as a given collection. Not all collections can be copied. • index_collection - Extracts a single object from a collection and creates a new collection containing that object. Not all collections can be indexed. • sizeof_collection - Returns the number of objects in a collection. Filtering You can filter any collection by using the filter_collection command. It takes a base collection and creates a new collection that includes only those objects that match an expression. Many of the commands that create collections support a -filter option, which allows objects to be filtered out before they are ever included in the collection. Frequently this is more efficient than filtering after the they are included in the collection. The following example from PrimeTime filters out all leaf cells: pt_shell filter_collection \ [get_cells *] "is_hierarchical == true"] {"i1", "i2"} The basic form of a filter expression is a series of relations joined together with AND and OR operators. Parentheses are also supported. The basic relation contrasts an attribute name with a value through a relational operator. In the previous example, is_hierarchical is the attribute, == is the relational operator, and true is the value. The relational operators are == Equal != Not equal Greater than Less than = Greater than or equal to = Less than or equal to =~ Matches pattern !~ Does not match pattern The basic relational rules are Collections_and_Querying 50 • String attributes can be compared with any operator. • Numeric attributes cannot be compared with pattern match operators. • Boolean attributes can be compared only with == and !=. The value can be only true or false. Additionally, existence relations determine if an attribute is defined or not defined, for the object. For example, sense == setup_clk_rise and defined(sdf_cond) The existence operators are defined undefined These operators apply to any attribute as long as it is valid for the object class. See the appropriate man pages for complete details. Sorting Collections You can sort a collection by using the sort_collection command. It takes a base collection and a list of attributes as sort keys. The result is a copy of the base collection sorted by the given keys. Sorting is ascending, by default, or descending when you specify the -descending option. In the following example, the PrimeTime command sorts the ports by direction and then by full name. pt_shell sort_collection [get_ports *] \ {direction full_name} {"in1", "in2", "out1", "out2"} Implicit Query of Collections All commands that create implicitly collections query the collection when the command is used at the command line. The number of objects displayed is controlled by the collection_result_display_limit variable. Consider the following examples from PrimeTime: pt_shell set_input_delay 3.0 [get_ports in*] 1 pt_shell get_ports in* {"in0", "in1", "in2"} pt_shell query_objects -verbose [get_ports in*] {"port:in0", "port:in1", "port:in2"} pt_shell set iports [get_ports in*] {"in0", "in1", "in2"} In the first example, the get_ports command creates a collection of ports that is passed to the set_input_delay command. This collection is not the result of the primary command (set_input_delay), so it is not queried. The second example shows Collections_and_Querying 51 how a command that creates a collection automatically queries the collection when that command is used as a primary command. The third example shows the verbose feature of the query_objects command, which is not available with implicit query. Finally, the fourth example sets the variable iports to the result of the get_ports command. Only in the final example does the collection persist to future commands until iports is overwritten, unset, or goes out of scope. Controlling Deletion Effort When a subset of objects in a design is removed, it is not always clear whether to remove the collection. The PrimeTime collection_deletion_effort variable controls the amount of effort expended to preserve collections. For complete details, see the collection_deletion_effort command man page. Related Commands For your convenience, related commands and variables are listed below by categories: Common Commands: add_to_collection compare_collections copy_collection foreach_in_collection index_collection query_objects remove_from_collection sizeof_collection filter_collection sort_collection PrimeTime Commands all_clocks all_connected all_inputs all_instances all_outputs get_cells get_clocks get_designs get_generated_clocks get_lib_cells get_lib_pins get_libs get_nets get_path_groups get_pins get_ports get_qtm_ports get_timing_paths PrimeTime Variables: Collections_and_Querying 52 collection_deletion_effort collection_result_display_limit SEE ALSO add_to_collection (2), all_clocks (2), all_connected (2), all_inputs (2), all_instances (2), all_outputs (2), compare_collections (2), copy_collection (2), filter_collection (2), foreach_in_collection (2), get_cells (2), get_clocks (2), get_designs (2), get_generated_clocks (2), get_lib_cells (2), get_lib_pins (2), get_libs (2), get_nets (2), get_path_groups (2), get_pins (2), get_ports (2), get_qtm_ports (2), get_timing_paths (2), index_collection (2), query_objects (2), remove_from_collection (2), sizeof_collection (2), sort_collection (2); collection_deletion_effort (3), collection_result_display_limit (3). Collections_and_Querying 53 compare_collections Compares the contents of two collections. If the same objects are in both collections, the result is "0" (like string compare). If they are different, the result is nonzero. The order of the objects can optionally be considered. SYNTAX int compare_collections [-order_dependent] collection1 collection2 collection collection1 collection collection2 ARGUMENTS -order_dependent Indicates that the order of the objects is to be considered; that is, the collections are considered to be different if the objects are ordered differently. collection1 Specifies the base collection for the comparison. The empty string (the empty collection) is a legal value for the collection1 argument. collection2 Specifies the collection with which to compare to collection1. The empty string (the empty collection) is a legal value for the collection2 argument. DESCRIPTION The compare_collections command is used to compare the contents of two collections. By default, the order of the objects does not matter, so that a collection of cells u1 and u2 is the same as a collection of the cells u2 and u1. By using the order_dependent option, the order of the objects is considered. Either or both of the collections can be the empty string (the empty collection). If two empty collections are compared, the comparison succeeds (that is, compare_collections considers them identical), and the result is "0". EXAMPLES The following example shows a variety of comparisons. Note that a result of "0" from compare_collections indicates success. Any other result indicates failure. pt_shell compare_collections [get_cells *] [get_cells *] 0 pt_shell set c1 [get_cells {u1 u2}] {"u1", "u2"} pt_shell set c2 [get_cells {u2 u1}] {"u2", "u1"} pt_shell set c3 [get_cells {u2 u4 u6}] {"u2", "u4", "u6"} pt_shell compare_collections $c1 $c2 0 compare_collections 54 pt_shell compare_collections $c1 $c2 -order_dependent -1 pt_shell compare_collections $c1 $c3 -1 The following example builds on the previous example by showing how empty collections are compared. pt_shell set c4 "" pt_shell compare_collections $c1 $c4 -1 pt_shell compare_collections $c4 $c4 0 SEE ALSO collections (2). compare_collections 55 compare_interface_timing Compares two write_interface_timing reports. SYNTAX int compare_interface_timing ref_timing_file cmp_timing_file [-output file_name] [-absolute_tolerance atol_list] [-percent_tolerance ptol_list] [-capacitance_tolerance ctol_list] [-noise_tolerance ntol_list] [-ignore ign_list] [-include cmp_list] [-quiet] [-nosplit] [-sort_by_worst] [-session session_name] [-significant_digits digits] stringref_timing_file stringcmp_timing_file stringfile_name string session_name list atol_list list ptol_list list ctol_list list ntol_list list ign_list list cmp_list stringsession_name int digits ARGUMENTS ref_timing_file Specifies the name of the timing file to be used as the reference in the comparison. cmp_timing_file Specifies the name of the timing file to be compared to the reference timing file. -output file_name Specifies the name of the output file to which the results of the comparison are to be written. The information written to file_name specifies PASS/FAIL status for every parameter compared by the command. By default, these results are written to the session transcript. All informational, warning, or error messages are still directed to the session transcript even if this option is specified. compare_interface_timing 56 -absolute_tolerance atol_list Specifies the absolute error tolerance for time data. See below for a description of the tolerance format. If this is used in conjunction with percent_tolerance then both tolerances must be exceeded to cause a FAIL. See -capacitance_tolerance and -noise_tolerance for other absolute tolerances. The default is zero. -percent_tolerance ptol_list This option is similar to the -absolute_tolerance option except that it uses the percent relative error instead of an absolute error. The exception is that slack data ignores this option and uses only the absolute tolerance. See below for a description of the tolerance format. If this is specified in conjunction with either -absolute_tolerance, -capacitance_tolerance, or noise_tolerance, then both tolerances must be exceeded to cause a FAIL. The default is zero. -capacitance_tolerance ctol_list Specifies the absolute error tolerance for capacitance data. See below for a description of the tolerance format. If this is used in conjunction with percent_tolerance then both tolerances must be exceeded to cause a FAIL. See -absolute_tolerance and -noise_tolerance for other absolute tolerances. The default is zero. -noise_tolerance ntol_list Specifies the absolute error tolerance for noise slack. See below for a description of the tolerance format. If this is used in conjunction with percent_tolerance then both tolerances must be exceeded to cause a FAIL. See -absolute_tolerance and -capacitance_tolerance for other absolute tolerances. The default is zero. -ignore ign_list Specifies a list of categories of slack or arc data to be excluded from the comparison. The following list describes the valid values: max — Excludes all max_rise and max_fall delay type arcs from the slack and transition_time sections. The capacitance section is not examined because it contains only max information. min — Excludes all min_rise and min_fall delay type arcs from the slack and transition_time sections. unconstrained — Excludes all paths that are unconstrained for both reference and compare data files. pass — Excludes all passing comparisons, so only fails are displayed. async_default — Excludes comparison of paths in the async_default path group. This option is obsolete and is replaced by specifying the recover and removal values of the -include option. clock_gating — Excludes comparison of paths with the clock_gating_default path group. This option is obsolete and is replaced by specifying the clock_gating_setup and clock_gating_hold of the -include option. input_to_register — Excludes comparison of input-to-register paths. This option is obsolete and is replaced by specifying the setup and hold values of the -include option. register_to_output — Excludes comparison of register-to-output path. This option is obsolete and is replaced by specifying the max_seq_delay and min_seq_delay of the -include option. input_to_output — Excludes comparison of combinational paths. This option is obsolete and is replaced by specifying the max_combo_delay and compare_interface_timing 57 min_combo_delay of the -include option. -include cmp_list Specifies a list of data sections from the write_interface_timing command output to be included in the comparison; only those sections are compared. By default, all sections are compared. The following list describes the keywords that are accepted in the cmp_list as valid: slack — Specifies that only worst-case slacks are to be compared. arc — Specifies that only arc values are to be compared. transition_time — Specifies that only actual transition times on ports are to be compared. capacitance — Specifies that only actual capacitances on ports are to be compared. design_rules — Specifies that only design rules on ports are to be compared. 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. max_combo_delay — Specifies that only max_combo_delay arc type paths are to be reported. min_combo_delay — Specifies that only min_combo_delay arc type paths are to be reported. max_seq_delay — Specifies that only max_seq_delay arc type paths are to be reported. min_seq_delay — Specifies that only min_seq_delay arc type paths are to be reported. setup — Specifies that only setup arc type paths are to be reported. hold — Specifies that only setup arc type paths are to be reported. recovery — Specifies that only recovery arc type paths are to be reported. removal — Specifies that only removal arc type paths are to be reported. clock_gating_setup — Specifies that only clock_gating_setup arc type paths are to be reported. clock_gating_hold — Specifies that only clock_gating_hold arc type paths are to be reported. noise — Specifies that the noise section should be included. -quiet Specifies an obsolete option. This option is now obsolete and has been replaced by the -session quiet option. -session session_name Controls the information that is printed to the session transcript. Note that this option affects only the session transcript, not the information written to the output file. The following list describes the keywords that are accepted for session_name: quiet — Prevents information, warning, and error messages from appearing in the session transcript. Use this option when you want to see only the success/ failure return code without any MV messages. The -session option used with this keyword replaces the now-obsolete -quiet option. summary — Prints only the summary pass/fail count to the session transcript. full — Prints the detailed report either to the session transcript or to a file if you specify the -output option. This is the default value. -nosplit The -nosplit option prevents line-splitting. This is most useful for performing diffs on previous scripts or for postprocessing the script. compare_interface_timing 58 -sort_by_worst 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. By default, the output follows the order of the reference write_interface_timing data, which is sorted alphabetically within each path attribute (c paths, i paths including a and g, then o paths). -significant_digits digits Specifies the number of digits to the right of the decimal point that are to be reported following the method used in the report_timing command. Allowed values are 0-13. The default value is 2. Use this option if you want to override the default. See below for a more detailed description of significant digits. DESCRIPTION The compare_interface_timing command compares two interface timing files (called the "reference" and "comparison" files) previously generated by the write_interface timing command. The result is PASS if the timing parameter values in the two files are the same or within a specified tolerance. The result is FAIL if both columns have data and the tolerance is exceeded. If all comparisons in the report are PASS, the return code for the compare_interface_timing command is 0. If one or more comparisons result in FAIL, the return code is 1. Any other return code (or no return code) indicates a command error. If either file format does not conform to the write_interface_timing standard, the command issues a warning message. The compare_interface_timing command lets you specify the input and output files for the comparison, the types of paths and timing parameters to compare or not compare, and the allowed tolerance levels that trigger comparison failures. If the timing_slew_propagation_mode variable was set to worst_arrival when the write_interface_timing command was run on the reports being compared, then this variable is expected to be in the same state when running the compare_interface_timing command. Otherwise, some combinational paths might not be properly compared. If the reference and comparison files were generated using different contexts then the two files may contain different timing arcs along with different slacks. If an arc exists in the comparison file but not in the referece file then compare_interface_timing ignores the extra arcs. If an arc exists in the comparison file but not in the reference file, then compare_interface_timing reports the slack value for the reference file, but either "N.C." or "----" for the comparison file slack. The slack difference is marked as "----", and the status is FAIL. The comparison slack is marked as "----" if the arc is not clock gating or recovery or removal. The slack for a missing arc is mark as "N.C.", meaning not critical, if it exists in the reference but not in the comparison file, and the arc type is clock gating or recovery or removal. These arcs fall into the **clock_gating_default** or **asynchronous_default** clock groups, respectively. Each of these groups can have several clocks in them, and under certain circumstances write_interface_timing will see the path to one clock as critical for the reference view and report that arc and slack, but another clock as critical in the comparison view and report that arc and compare_interface_timing 59 slack. The compare_interface_timing command deals with significant digits in two distinct ways. First, the internal computations are limited to the minimum precision of the two input files. This means that if the ref_timing_file was generated with three digits and the cmp_timing_file with four, then compare_interface_timing will use three digits for all internal computations. It is important to make the tolerances larger than a unit of the computational significant digits, or compare_interface_timing could generate false FAIL and PASS messages. This can happen because of rounding. For example, if the internal significant digits is two, and the absolute tolerance is set to 0.01, then a difference of 0.014 is rounded to 0.01 and reported as a PASS even though it is outside the tolerance. Similiarly, if the absolute tolerance of 0.009 a difference of 0.009 is rounded to 0.01 and reported as FAIL even though it is within tolerance. The user should ensure that the number of digits of accuracy of the input files is greater than the accuracy of the tolerances. A second use of significant digits is in report generation, which is limited to the minimum of the input precision and the significant digits specified by the user. The user specifies the significant digits for the report through the -significant_digits option. For example, if the value for the -significant_digits option is five but the ref_timing_file was generated with four digits, then the report will be limited to four digits. Note that this use of significant digits does not affect the PASS or FAIL status, but a reported difference could look like it should have a different status if the difference is close to a tolerances and the difference rounded when writing the report. 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. For example, atol_list equal to 0.1 indicates that time differences of less than 0.1 and greater than -0.1 are considered to be passing. If there are two numbers then the first specifies the minus bound and the second the plus. The minus tolerance is the inverse of the absolute value of the first number, and the plus tolerance is the absolute value of the second number. Having a pair of numbers allows different tolerances to be applied for negative and positive errors, which can be interpreted as optimism and pessimism depending the the arc type. For example, an atol_list equal to {0.2 -0.3} indicates that data differences of less than 0.3 and greater than -0.2 are considered passing. EXAMPLES The following example shows a variety of comparisons. Each item in parentheses (for example, L1, L2) represents the latch level associated with the slack number directly to the left. These values are included in the report wherever there is an L# attribute in the write_interface_timing output. At the end of the report is a summary of the the total comparisons passed and failed broken down by data section. pt-shell compare_interface_timing demo_net.rpt demo_etm.rpt ? -include arc -percent_tolerance {10 5} compare_interface_timing 60 **************************************** Command: compare_interface_timing demo_net.rpt demo_etm.rpt -include arc -percent_tol 10.0 5.0 Design : top Version: 2002.03-SI1 Date : Mon Nov 26 11:20:01 2001 **************************************** Arc Arc Value From To Type Ref Cmp %Error Status ----------------------------------------------------------------------------- in(r) out(r)max_combo_delay 2.63 2.21 15.97 FAIL in(f) out(r)max_combo_delay 2.28 2.32 -1.75 PASS in(r) out(f)min_combo_delay 0.17 0.30 -76.47 FAIL in(f) out(f)min_combo_delay 0.51 0.51 0.00 PASS in(r) clk(r)setup 2.63 (L1) 2.63 0.00 PASS in(f) clk(r)setup 2.29 (L2) 2.29 0.00 PASS in(r) clk(f)hold 0.17 0.17 0.00 PASS clk(r)out(r)max_seq_delay 17.79 17.79 0.00 PASS clk(r)out(f)max_seq_delay 18.20 18.20 0.00 PASS clk(f)out(r)min_seq_delay 2.21 2.21 0.00 PASS clk(f)out(f)min_seq_delay 1.80 1.80 0.00 PASS Totals Arc Value Transition Time Capacitance Rules --------------------------------------------------------------- Passed 9 9 0 0 - Failed 2 2 0 0 0 Total 12 12 0 0 0 SEE ALSO write_interface_timing (2); timing_slew_propagation_mode (3). compare_interface_timing 61 compile_stamp_model Compiles a STAMP model. SYNTAX string compile_stamp_model -model_file model_file_name -data_file data_files [update] -output output_file_name [-library_cell] [-test_design] [-expand_buses] stringmodel_file_name list data_files stringoutput_file_name ARGUMENTS -model_file model_file_name Specifies the name of the model file to read and compile. -data_file data_files Specifies a list of data files to read. Specify a separate data file for each operating condition. -update Adds the output model to an existing model for another operating condition. -output output_file_name Specifies the root name to use for the generated DB files. Two files are generated: output_file_name.db contains the model design and output_file_name_lib.db contains the library cell containing all the timing arcs. The model design is a regular DB design which instantiates the library cell. The pins of the core cell are connected to the ports of the library design using nets. -library_cell Specifies that the model should be generated as a library cell rather than a design. -test_design Specifies that a test design instantiating the model lib_cell be generated. This option is valid only when used with -library_cell option. -expand_buses Used to expand the bus definitions to scalar bits such that no busses are created or written to the compiled DB libraries or wrapper designs. All the busses are bit blasted. DESCRIPTION This command compiles STAMP files and generates a model in Synopsys DB format. This model can be read into PrimeTime and Design Compiler to perform timing analysis. STAMP is a modeling language developed by Synopsys to describe the static timing models of complex blocks such as RAMs and microprocessor cores. STAMP model description consists of a single model file and multiple data files. The model file compile_stamp_model 62 contains the definition of design ports and timing arcs. The data file contains the arc data (timing numbers) and the port data (capacitance, max_transition, and so on). Both types of data are dependent on the operating condition. To describe timing data for different operating conditions, use separate data files. The -update option can be used to add the data from another operating condition to the existing DB model. The data for the additional operating condition is added to the library file with root name specified in the -output option. If the file already contains data for the specified operating condition, the data is overwritten with the new one. The -library_cell option can be used to write out only the DB file that contains the lib_cell (output_file_name_lib.db) representing the model. The name given to the lib_cell is the design name specified in the model file. To generate a test_design that instantiates this lib_cell, use -test_design option. This generates a design DB (called output_file_name_test.db) which instantiates the model lib_cell. The name given to the test_design is design_name_test. EXAMPLES The following command compiles the STAMP model specified in the sram.mod file and sram.data file and generates two DB files: sram_model.db contains the model design and sram_model_lib.db contains the library cell DB. pt_shell compile_stamp -model_file sram.mod -data_file sram.data -output sram_model The following command compiles a stamp model for two operating conditions: WCCOM and WCMIL. Two DB files are generated: sram_multiple.db which contains the model design and sram_multiple_lib.db which contains the library cell arc data for both operating conditions. pt_shell compile_stamp -model_file sram.mod -data_file {sram_WCCOM.data sram_WCMIL.data} -out sram_multiple The following command adds the delay data for the WCIND operating conditions to the model generated in the previous example. The sram_multiple_lib.db file is augmented with the delay data for the WCIND operating condition. pt_shell compile_stamp -model_file sram.mod -data_file sram_WCIND.data update -out sram_multiple The following command compiles the STAMP model specified in the design.mod file and design.data file and generates a library cell contained in design_model_lib.db. The file design_model_test.db contains the test design that instantiates the model core cell, is also generated although it is not a part of the model. It can be used to obtain timing and model reports in PrimeTime. pt_shell compile_stamp -model_file design.mod -data_file design.data library_cell -test_design -output design_model compile_stamp_model 63 SEE ALSO extract_model (2). compile_stamp_model 64 complete_net_parasitics Completes partial parasitics annotated on all nets of the current design. SYNTAX string complete_net_parasitics [-complete_with completion_type] string completion_type ARGUMENTS -complete_with completion_type Indicates that a net with partially annotated parasitics and missing segments is to be completed by inserting capacitances and resistances according to completion_type. Allowed values are zero (the default), which completes the net by inserting zero capacitances and resistances; and wlm, which completes the net by inserting capacitances and resistances derived from wire load models. This option is equivalent to read_parasitics -complete_with. DESCRIPTION The complete_net_parasitics command completes all nets in the design that have incomplete RC networks annotated from SPEF or SPF files. If lumped parasitics (set using set_load or set_resistance) already exist on any of the nets they will not be overwritten; instead a warning will be issued. Note: complete_net_parasitics and read_parasitics -complete_with complete a net only if all missing segments are between two pins, and only if the nets are partially annotated (nets are not affected if they are fully annotated or have no annotation at all). Also, the net must be hierarchical, so that if the parasitics for the block-level parts of a net are missing, those parasitics could exist in the toplevel net. If any of these conditions are not met, you must correct the SPEF or DSPF file manually. Use the report_annotated_parasitics command to view how the parasitics are completed. After the completion of the nets, there is no direct way to remove only the completed segments. You can remove all parasitics read and annotated with read_parasitics and complete_net_parasitics using remove_annotated_parasitics, then reread the previously annotated parasitics using the read_parasitics command. reset_design removes all attributes from the current design, including annotated parasitics. EXAMPLES The following example completes the partially annotated parasitics from the file speffile.spef, by inserting zero capacitances and resistances. complete_net_parasitics 65 pt_shell read_parasitics speffile.spef pt_shell complete_net_parasitics -complete_with zero SEE ALSO read_parasitics (2), remove_annotated_parasitics (2), report_annotated_parasitics (2), reset_design (2). complete_net_parasitics 66 connect_net Connects a net to specified pins or ports. SYNTAX int connect_net net object_spec stringnet list object_spec ARGUMENTS net Specifies the name of the net to which the pins and ports are to be connected. object_spec Specifies a list of pins or ports to connect to net. DESCRIPTION The connect_net command connects pins and ports to a net in the current design. Like all other netlist editing commands, for connect_net to succeed, all of its arguments must succeed. If any arguments fail, the netlist remains unchanged. connect_net returns a 1 if successful and a 0 if unsuccessful. The net and each pin and port specified in the object_spec must be in scope; that is, at or below the current instance. There are two rules for connect_net: • You cannot connect net to a pin that is already connected. • You cannot connect across a hierarchical boundary. For example, you cannot connect a port to a net at a hierarchical level other than the top of the design. EXAMPLES The following example creates a cell and a net, then connects the new net to the output of the new cell. pt_shell create_net new_net1 Information: Created net ’new_net1’ in design ’top’. (NED-016) 1 pt_shell create_cell u1 class/AN2 Information: Created cell ’u1’ in design ’top’. (NED-014) 1 pt_shell connect_net new_net1 u1/Z Information: Connected ’u1/Z’ to ’new_net1’. (NED-018) 1 connect_net 67 SEE ALSO create_cell (2), create_net (2), disconnect_net (2), size_cell (2), swap_cell (2), write_changes (2). connect_net 68 copy_collection Duplicates the contents of a collection, resulting in a new collection. The base collection remains unchanged. SYNTAX collection copy_collection collection1 collection collection1 ARGUMENTS collection1 Specifies the collection to be copied. If the empty string is used for the collection1 argument, the command returns the empty string (a copy of the empty collection is the empty collection). DESCRIPTION The copy_collection command is an efficient mechanism for creating a duplicate of an existing collection. It is more efficient, and almost always sufficient, to simply have more than one variable referencing the same collection. For example, if you create a collection and save a reference to it in a variable c1, assigning the value of c1 to another variable c2 simply creates a second reference to the same collection: pt_shell set c1 [get_cells "U1*"] {"U1", "U10", "U11", "U12"} pt_shell set c2 $c1 {"U1", "U10", "U11", "U12"} This has not copied the collection. There are now two references to the same collection. If you change the c1 variable, c2 continues to reference the same collection: pt_shell set c1 [get_cells "block1"] {"block1"} pt_shell query_objects $c2 {"U1", "U10", "U11", "U12"} There may be instances when you really do need a copy, and in those cases, copy_collection is used to create a new collection that is a duplicate of the original. copy_collection 69 EXAMPLES The following example shows the result of copying a collection. Functionally, it is not much different that having multiple references to the same collection. pt_shell set c1 [get_cells "U1*"] {"U1", "U10", "U11", "U12"} pt_shell set c2 [copy_collection $c1] {"U1", "U10", "U11", "U12"} pt_shell unset c1 pt_shell query_objects $c2 {"U1", "U10", "U11", "U12"} SEE ALSO collections (2). copy_collection 70 cputime Retrieves the overall user time associated with the current pt_shell process. SYNTAX float cputime [format] string format ARGUMENTS format This argument takes a printf style formatting string for a floating point number. DESCRIPTION The cputime command returns the accumulated user time, in seconds, for the current pt_shell process. If the format string is omitted, an integer number of seconds is returned. If the format string is specified, a floating point number is returned. The number includes fractions of a second elapsed and is formatted in accordance with given specifier. Refer to the Unix man page for printf for a detailed description of how to format a floating point argument. pt_shell cputime "%g" 3.74 SEE ALSO mem(2) cputime 71 NAME create_cell Creates cells in the current design. SYNTAX int create_cell [-libraries lib_spec] [-exact] cell_list lib_cell list cell_list stringlib_cell ARGUMENTS -libraries lib_spec If this option is specified, then PrimeTime resolves lib_cellP from the libraries contained in the lib_spec only. Libraries are searched in the order in which they appear in lib_spec. lib_spec can be a list of library names, or collections of libraries loaded into PrimeTime; the latter can be obtained using the get_libs command. You cannot specify this option if a full library cell name has been specified. -exact Indicates that names are to be used exactly as specified. Use this option if you want to create a cell that contains a hierarchy or wildcard character as part of the cell name. For more information, see the section entitled "NAMING CELLS WITH SPECIAL CHARACTERS". cell_list Specifies a list of cells to be created. lib_cell Specifies the name of the library cell to which the specified cells are to be linked. lib_cell can be a library cell object, or the name of a library cell. The former can be obtained using the get_lib_cells command. The latter can either be the full library cell name, i.e. ’lib_name/lcell_name’, or the just the base name of the library cell, i.e. ’lcell_name’. You cannot specify the -libraries option and explicitly specify the full library cell name. If the user invokes PrimeTime with the -multi_scenario option, then the library cell base name only must be used. For more information, see the section entitled "RESOLVING LIBRARY CELLS". DESCRIPTION The create_cell command creates new cells in the current design. Like all other netlist editing commands, for create_cell to succeed, all of its arguments must succeed. If any arguments fail, the netlist remains unchanged. create_cell returns a 1 if successful and a 0 if unsuccessful. Cells are created in scope; that is, at or below the current instance. Cell names are specified as for other commands, using the full hierarchical name relative to the current instance, as in the following example: 72 create_cell u1/u2/u3 class/AN2 This command attempts to create a cell named u3 in the hierarchical block u1/u2. The name to the right of the last hierarchical separator is the actual cell name, and the remainder is sent to a search engine to find a hierarchical block in which to create the new cell. The operation fails if any of the following are true: • The search engine cannot find "u1/u2". • The search engine finds multiple blocks that match "u1/u2". • The search engine finds a leaf cell matching "u1/u2". Currently, you cannot create new hierarchy; that is, you cannot create a cell that is an instance of a design. The lib_cell must be a leaf library cell. After creating a cell, you can connect nets to its pins with connect_net. You can remove cells with remove_cell. RESOLVING LIBRARY CELLS If the lib_cell has been specified in base name only format, i.e. without a library from which to resolve it from, then PrimeTime resolves the library cell according to the following methodology. If the -libraries option is specified, then PrimeTime searches for library cells in the libraries contained within the lib_spec only. Alternatively, if the above option is not specified, PrimeTime searches for the library cell in the libraries contained within the link_path variable. The first library cell that is found is used. NAMING CELLS WITH SPECIAL CHARACTERS If you want to create a cell whose name contains the current hierarchical separator or wildcard characters used by the search engine, you must do the following: • Use current_instance to change the scope to the block in which you want the new cell created. • Use create_cell -exact to create the cell. For examples, see the EXAMPLES section. 73 EXAMPLES In the following example, cells are created in the current instance, and at a level below the current instance. Currently, u1 is an instance of a design that has multiple instances. Therefore, it is uniquified as part of the editing operation. pt_shell create_cell t1 class/AN2 Information: Created cell ’t1’ in design ’top’. (NED-014) 1 pt_shell create_cell u1/t1 class/AN2 Uniquifying ’u1’ (block1) as ’block1_0’. Information: Created cell ’t1’ in ’top/u1’. (NED-014) 1 The following example creates cell a/b in the hierarchical block u1/u2. The first attempt fails, because the -exact option was omitted. Here, u1/u2 is an instance of a design that has multiple instances; therefore, it is uniquified as part of the editing operation. u1 was already uniquified in the previous example. pt_shell current_instance u1/u2 u1/u2 pt_shell create_cell a/b class/AN2 Error: Could not create cell ’a/b’: a not found. (NED-041) Error: No changes made. (NED-040) 0 pt_shell create_cell a/b class/AN2 -exact Uniquifying ’u1/u2’ (block2) as ’block2_0’. Information: Created cell ’a/b’ in ’top/u1/u2’. (NED-014) 1 In the following example, multiple cells are created using library cells chosen from user specified libraries using the library cell base name only. The ’lib1’ library is searched first as it appears in the lib_spec list first, then ’lib2’ is searched. pt_shell create_cell -libraries {lib1 lib2} {u1 u2 u3} ND2 Information: Created cell ’u1’ in design ’middle’ with ’lib1/ND2’. (NED-014) Information: Created cell ’u2’ in design ’middle’ with ’lib1/ND2’. (NED-014) Information: Created cell ’u3’ in design ’middle’ with ’lib1/ND2’. (NED-014) 1 SEE ALSO connect_net (2), create_net (2), current_instance (2), remove_cell (2), size_cell (2), swap_cell (2), write_changes (2), link_path (3). 74 create_clock Creates a clock object. SYNTAX string create_clock -period period_value [-name clock_name] [-waveform edge_list] [-add] [source_objects] float period_value stringclock_name list edge_list list source_objects ARGUMENTS -period period_value Specifies the clock period in library time units. This is the minimum time over which the clock waveform repeats. The period_value must be greater than or equal to zero. -name clock_name Specifies the name of the clock being created, enclosed in quotation marks. If you do not use this option, the clock gets the same name as the first clock source specified in the sources option. If you did not specify sources, you must use the -name option, which creates a virtual clock not associated with a port or pin. You can use both the -name option and the sources option to give the clock a more descriptive name than the first source pin or port. If you specify the -add option, you must use the -name option and the clocks with the same source must have different names. -waveform edge_list Specifies the rise and fall edge times of the clock waveforms of the clock, in library time units, over an entire clock period. The first time in the edge_list is a rising transition, typically the first rising transition after time zero. There must be an even number of edges, and they are assumed to be alternating rise and fall. The edges must be monotonically increasing, except for a special case with two edges, where fall can be less than rise. The numbers should represent one full clock period. If you do not specify this option, a default waveform is assumed, which has a rise edge of 0.0 and a fall edge of period_value/2. -add Specifies whether to add this clock to the existing clock or to overwrite. Use this option to capture the case where multiple clocks must be specified on the same source for simultaneous analysis with different clock waveforms. When you specify this option, you must also use the -name option. Defining multiple clocks on the same source pin or port causes longer runtime and higher memory usage than a single clock, because PrimeTime must explore create_clock 75 all possible combinations of launch and capture clocks. Use the set_false_path command to disable unwanted clock combinations. source_objects Specifies the objects used as sources of the clock. The sources can be ports, pins or nets in the design. If you do not use this option, you must use the -name option, which creates a virtual clock not associated with a port, pin or net. If you specify a clock on a pin that already has a clock, the new clock replaces the old one unless you use the -add option. When a net is used as the source, the first driver pin of the net is the actual source used in creating the clock. DESCRIPTION Creates a clock object. It is created in the current design and is applied to the specified sources value. If you do not specify a sources value, but give a clock_name value, a virtual clock is created. You can create a virtual clock to represent an off-chip clock for input or output delay specification. For more information about input and output delay, see the set_input_delay and set_output_delay man pages. If one of the sources is already the source of a clock, the source is removed from that clock. This clock is eliminated if it has just one source. The create_clock command also defines the waveform for the clock. The clock can have multiple pulses per period. The create_clock command is used together with the set_clock_latency, set_clock_uncertainty, set_propagated_clock, and set_clock_transition commands to specify properties of clock networks. By default, a new path group is created for the clock. This new path group brings together the endpoints related to this clock for cost function calculation. To remove the clock from its assigned group, use the group_path command to reassign the clock to another group or to the default path group. For more information, see the group_path man page. The new clock has ideal clock latency and transition time; no propagated delay through the clock network is assumed and a transition time of zero is used at the clock source pin. To enable propagated latency for a clock network, use the set_propagated_clock command. To set an estimated latency, use the set_clock_latency command. To show information about clocks in the design, use the report_clock command. To create a collection of clocks matching a pattern and optionally matching filter criteria, use the get_clocks command. To undo create_clock, use the remove_clock command. EXAMPLES The following example creates a clock on a port named PHI1 with a period of 10.0, a rise at 5.0, and a fall at 9.5. pt_shell create_clock PHI1 -period 10 -waveform { 5.0 9.5 } create_clock 76 The following example shows a clock named PHI2 with a falling edge at 5 and a rising edge at 10 with a period of 10. Because the the edges for the-waveform option should be ordered as first rise, then fall, and should increase in value, the fall edge can be given as 15. This places the next falling edge after the first rise edge at 10. pt_shell create_clock PHI2 -period 10 -waveform { 10 15 } The following example creates a virtual clock PHI2 with a period of 10.0, a rise at 0.0, and a fall at 5.0. pt_shell create_clock -name PHI2 -period 10 -waveform {0.0 5.0} The following example creates a clock named clk2 with multiple sources. pt_shell create_clock -name clk2 -period 10 \ -waveform {2.0 4.0} {clkgen1/Z clkgen2/Z clkgen3/Z} The following example creates a clock named CLK on pin u13/Z with a period of 25, a fall at 0.0, a rise at 5.0, a fall at 10.0, a rise at 15.0, and so on. pt_shell create_clock u13/Z -name CLK -period 25 -waveform { 5 10 15 25} SEE ALSO all_clocks (2), get_clocks (2), group_path (2), remove_clock (2), report_clock (2), set_clock_latency (2), set_clock_uncertainty (2), set_input_delay (2), set_output_delay (2). create_clock 77 create_configuration Creates a configuration for multi-scenario analysis. SYNTAX create_configuration -global_data file_list list file_list ARGUMENTS -global_data An order dependent list of files containing everything that is common across the entire analysis. These files must at the very minimum contain the commands needed to read the design netlist. DESCRIPTION For multi-scenario analysis, the create_configuration is used to define the global data that will be common across th entire analysis. The global data is valid PrimeTime commands, expressions and variables. The data contained in the global_data files will be used to generate the single design image. This can not be altered after this point. The netlist is locked. The contents of the global_data files will be evaluated entirely in the slave context. The files may contain arbitrarily complex Tcl procedures. It is not possible to create more than one configuration. Doing so will result in an error being issued. EXAMPLES In the following example, a configuration is created using the data files global_all1.pt and global_all2.pt. pt_shell create_configuration -global_data {global_all1.pt global_all2.pt} 1 SEE ALSO remove_configuration(2), create_scenario (2), report_multi_scenario_design (2), create_configuration 78 create_correlation Creates a new correlation type. SYNTAX int create_correlation -name correlation_name -constant 0 | 1 string correlation_name ARGUMENTS -name correlation_name Defines a name for this correlation. -constant f0 | 1 Supported values are 0 and 1 (no correlation or complete correlation). A constant factor of zero means that the instances of the corresponding variation will be statistically independent. A constant correlation with value one means that all instances of the corresponding variation are equal. The command returns 1 upon success, 0 upon failure. DESCRIPTION Creates a correlation type. EXAMPLES The following example creates a correlation type with constant correlation 1. pt_shell create_correlation -name corr_zero -constant 0 create_correlation 79 create_distributed_farm Create a virtual distributed farm made up of hosts specified using the add_distributed_hosts command. SYNTAX int create_distributed_farm DESCRIPTION The create_distributed_farm command creates a virtual farm by pooling together hosts from various sources (lsf, generic, grd, now). The various sources are specified using the add_distributed_hosts command. EXAMPLES In the following example, a virtual farm (made up of 11 hosts) is created. platinum1: 2x64 bit hosts, platinum2: 4x32 bit hosts, lsf: 5x32 bit hosts. pt_shell add_distributed_hosts -farm now -num_of_hosts 2 platinum1 1 pt_shell add_distributed_hosts -farm now -num_of_hosts 4 platinum2 -32bit 1 pt_shell add_distributed_hosts -farm lsf -submission_script "/bin/ lsf_stub" -options { -R "tmp300" -q} -num_of_hosts 5 1 pt_shell create_distributed_farm 1 SEE ALSO add_distributed_hosts (2) create_distributed_farm 80 create_distribution Creates a new distribution collection. SYNTAX collection create_distribution -name distribution_name -type distribution_type -values values_list [-lower_bound lower_bound] [-upper_bound upper_bound] string distribution_name string distribution_type list values_list float lower_bound float upper_bound ARGUMENTS -name distribution_name Defines a name of this distribution. -type distribution_type Defines the type of this distribution. The supported types are normal, pwl, empirical, constant, uniform, lognormal. -values values_list A list of floating point numbers that are the arguments for the distribution type. -lower_bound lower_bound The lower truncation point for this distribution. -upper_bound upper_bound The upper truncation point for this distribution. DESCRIPTION Creates a distribution and returns a handle to it in a collection. The values for the different distribution types are as follows: normal pwl empirical constant uniform lognormal mean sigma x1 f1 x2 f2 ... x1 x2 ... c ab mean sigma create_distribution 81 EXAMPLES The following example creates a normal distribution with mean = 100 and sigma = 3.34. pt_shell set d [create_distribution -name test_normal -type normal \ -values {100 3.34}] _sel21 This example creates a pwl distribution with the following pdf function: pdf(-1)=0, pdf(0)=1, pdf(1)=0. pt_shell set d [create_distribution -name test_pwl -type pwl \ -values {-1.0 0.0 0.0 1.0 1.0 0.0}] _sel22 The following example creates an empirical distribution from a list of data samples. pt_shell set d [create_distribution -name test_empirical -type empirical \ -values {1.0 2.0 3.0}] _sel23 The following example creates a distribution with a constant value 1.0. pt_shell set d [create_distribution -name test_const -type constant \ -values {1.0}] _sel24 The following example creates a lognormal distribution with mean = 0 and sigma = 0.5. This distribution is truncated from above at 2.0. pt_shell set d [create_distribution -name via -type lognormal \ -values {0.0 0.5} -upper_bound 2.0] _sel25 The following example creates a uniform distribution with a = 5 and b = 15. This distribution is truncated from below at 7.2 and truncated from above at 13.5. pt_shell set d [create_distribution -name len -type uniform \ -values {5.0 15.0} -lower_bound 7.2 -upper_bound 13.5] _sel26 create_distribution 82 SEE ALSO get_distribution_attribute(2), remove_distribution(2), set_variation(2). create_distribution 83 create_eco_astro_constraints Creates ECO Astro constraints to fix crosstalk delay, static timing, or static noise. SYNTAX int create_eco_astro_constraints [-output file_name] [-constraint_type list_of_constraint_types] [-delay_type delay_type] [-effort_level effort_level] [-validate] [-group path_group_name] [-max_constraints number_of_constraints] [-max_iteration number_of_iterations] [-verbose] [object_list net_or_paths] stringfile_name list list_of_constraint_types stringdelay_type stringeffort_level stringpath_group_name int number_of_constraints int number_of_iterations list nets_or_paths ARGUMENTS -output file_name Specifies the name of the output constraint file. If not specified, the default name constraints.dat will be used. -constraint_type list_of_constraint_types Specifies types of constraints to generate. List one or more types of delta_delay, stage_delay, noise and double_switching. The default value is {delta_delay stage_delay}. -delay_type delay_type Specifies the delay type of the constraints. Values are min, max, and min_max. The default value is max. -effort_level effort_level Specifies the effort level to generate timing constraints. If low, PrimeTime SI generates constraints for large delays. If high, PrimeTime SI will try to remove all timing violations by iterative approach. Thus, high effort will reduce the number of violations, but may increase the number of constraints and runtime. The default value is low. create_eco_astro_constraints 84 -validate Specifies whether to validate the constraints in PrimeTimeSI after constraint generation. PrimeTime SI will read back and annotate the constraints to check the new timing with the generated constraints. -group path_group_name Specifies clock groups to generate constraints for. -max_constraints number_of_constraints Specifies the maximum number of constraints to be generated. If not specified, the default value is 1000. -max_iteration number_of_iterations Specifies maximum number of iterations in high effort level. If not specified, the default value is 3. -verbose Turns on verbose mode. object_list net_or_paths Specifies a list of nets or paths to be analyzed. If not specified, PrimeTime SI will find them automatically. DESCRIPTION This command creates ECO constraints for Astro to fix delta delay, stage delay, and noise. Astro will use these constraints to perform ECO fixing. By specifying -constraint_type option, you can control what types of constraints to be generated. If no option is specified, PrimeTime SI will generate constraints to make the slacks of the paths going through SI bottleneck nets positive. By default, PrimeTime SI reduces delta delay first, then reduces stage delay if necessary. It does so by considering delta delay and stage delay at the same time when it generates constraints, and it optimizes the constraints as well as the number of constraints. If you want to fix only delta delay violations, use -constraint_type option with delta_delay specified. This command must be used at the ECO fixing stage before sign off. It means the design is almost clean, but there are a few timing violations or SI issues that you need to fix before sign off. You must not use this command if your design has too many violations. It might result in generating a large number of constraints that Astro cannot accept. You can control the number of constraints by changing -max_constraints options. To fix for the double_switching violations in the design use -constraint_type double_switching. You can check the new timing with the generated constraints if you enable -validate analysis. PrimeTime SI will read the constraints back to itself, and run incremental update timing to see how much improvement has been achieved. This option is create_eco_astro_constraints 85 especially useful when you want to check your ECO fix before place-and-route. Without any effort level specified, PrimeTime SI will use low effort by default and generate constraints to reduce the worst timing violations. However, if you like to generate more complete set of constraints to remove most of timing violations, use high effort level. PrimeTime SI will spend more time for its analysis and iterates until it finds no violations. The option -max_iteration limits the nuber of iterations. EXAMPLES 1) The following is to run this command to fix delta delay only. This will generate constraints to fix delta delay. create_eco_astro_constraints -output my_constraint.dat -constraint_type delta_delay 2) If fixing delta delay is not enough to make slack positive, use stage delay fixing in addition to delta delay fixing as shown below. create_eco_astro_constraints -constraint_type {delta_delay stage_delay} 3) The following is to run the command in high effort level. This setting will try to remove all violations by spending more time on analysis. create_eco_astro_constraints -effort_level high 4) If you like to check timing with the generated constraints, specify -validate option as following. create_eco_astro_constraints -validate 5) You can see verbose messages by specifying -verbose option. create_eco_astro_constraints -verbose 6) The following will fix noise violations. create_eco_astro_constraints -constraint_type {noise} 7) The following will fix delta, stage delay and noise at the same time. create_eco_astro_constraints -constraint_type {delta_delay stage_delay noise} 8) If you want to fix only the worst timing paths, use the following. set paths [get_timing_paths] create_eco_astro_constraints $paths 9) If you want to fix only particular nets, use the following. set nets [get_nets my_nets*] create_eco_astro_constraints $nets create_eco_astro_constraints 86 SEE ALSO update_noise (2), update_timing (2). create_eco_astro_constraints 87 create_generated_clock Creates a generated clock object. SYNTAX string create_generated_clock [-name clock_name] -source master_pin [-divide_by divide_factor | -multiply_by multiply_factor | -edges edge_list | -combinational ] [-duty_cycle percent] [-invert] [-edge_shift edge_shift_list] [-add] [-master_clock clock] source_objects stringclock_name list master_pin int divide_factor int multiply_factor float percent list edge_list list edge_shift_list stringclock list source_objects ARGUMENTS -name clock_name Specifies the name of the generated clock. If you do not use this option, the clock receives the same name as the first clock source specified in the source option. If you specify the -add option, you must use the -name option and the clocks with the same source must have different names. -source master_pin Specifies the master clock source (a clock source pin in the design) from which the clock waveform is to be derived. Note that the actual delays (latency) for the generated clock are computed using its own source pins and not the master_pin. -divide_by divide_factor Specifies the frequency division factor. If the divide_factor value is 2, the generated clock period is twice as long as the master clock period. -multiply_by multiply_factor Specifies the frequency multiplication factor. If the multiply_factor value is 3, the generated clock period is one-third as long as the master clock period. -edges edge_list Specifies a list of integers that represents edges from the source clock that create_generated_clock 88 are to form the edges of the generated clock. The edges are interpreted as alternating rising and falling edges and each edge must be not less than its previous edge. The number of edges must be an odd number and not less than 3 to make one full clock cycle of the generated clock waveform. For example, 1 represents the first source edge, 2 represents the second source edge, and so on. -combinational Specifies a type of divide by one clock. The source latency paths for this type of generated clock only includes the logic where the master clock propagates. The source latency paths will not flow through sequential element clock pins, transparent latch data pins or the source pins of other generated clocks. -duty_cycle percent Specifies the duty cycle, in percentage, if frequency multiplication is used. Duty cycle is the high pulse width. -invert Inverts the generated clock signal (in the case of frequency multiplication and division). -edge_shift edge_shift_list Specifies a list of floating point numbers that represents the amount of shift, in library time units, that the specified edges are to undergo to yield the final generated clock waveform. The number of edge_shifts specified must be equal to the number of edges specified. The values can be positive or negative, positive indicating a shift later in time, negative a shift earlier. For example, 1 indicates that the corresponding edge is to be shifted by one library time unit. -add Specifies whether to add this clock to the existing clock or to overwrite. Use this option to capture the case where multiple generated clocks must be specified on the same source, because multiple clocks fan into the master pin. Ideally, one generated clock must be specified for each clock that fans into the master pin. If you specify this option, you must also use the -name and -master_clock options. Defining multiple clocks on the same source pin or port causes longer runtime and higher memory usage than a single clock, because PrimeTime must explore all possible combinations of launch and capture clocks. Use the set_false_path command to disable unwanted clock combinations. -master_clock clock Specifies the master clock to be used for this generated clock if multiple clocks fan into the master pin. If you specify this option, you must also use the -add option. source_objects Specifies a list of ports, pins or nets defined as generated clock source objects. When a net is used as the source, the first driver pin of the net is the actual source used in creating the generated clock. create_generated_clock 89 DESCRIPTION Creates a generated clock object. It is created in the current design. The command creates it in the current design and defines a list of objects as generated clock sources in the current design. You can specify a pin or a port as a generated clock object. The command also specifies the clock source from which it is generated. The advantage of using this command is that whenever the master clock changes, the generated clock automatically changes. The generated clock can be created as a frequency divided clock (by using the divide_by option), frequency multiplied clock (by using the -multiply_by option), special divide by one (by useing the vB-combinational option), or an edge-derived clock (by using the -edges option). The frequency-divided or frequency-multiplied clock can be inverted by using the -invert option. The shifting of edges of the edge-derived clock is specified by using the -edge_shift option. The -edge_shift option is used for intentional edge shifts and not for clock latency. The number of edges specified by -edges to make one period of the generated clock waveform has to be an odd number larger than or equal to 3. For example, if you specify create_generated_clock -source clk -edges { 1 3 5 } [get_pins flop/Q] edge 1 indicates the first rising of the generated clock, edge 3 indicates the first falling of the gnerated clock, and edge 5 indicates the next rising of the gerated clock. Therefore, it is required at least three elements with the edges option to define the waveform of the gnerated clock. Non-increasing edges as -edges { 1 1 3 } is allowed and usually used with edge_shift to produce a generated clock pulse independent of the duty cycle of the master clock itself. If a generated clock is specified with a divide_factor value that is a power of 2 (1, 2, 4, ...), the rising edges of the master clock are used to determine the edges of the generated clock. If the divide_factor value is not a power of two, the edges are scaled from the master clock edges. Using the create_generated_clock command on an existing generated_clock object overwrites its attributes. The generated_clock objects are expanded to real clocks at the time of analysis. The following commands can reference the generated_clock: set_clock_latency, set_clock_uncertainty, set_propagated_clock, and set_clock_transition. For internally generated clocks, PrimeTime automatically computes the clock source latency if the master clock of the generated clock has propagated latency and no user-specified value for generated clock source latency exists. If the master clock is ideal and has source latency, and there is no user-specified value for the generated clock’s source latency, then zero source latency is assumed. To display information about generated clocks, use the report_clock command. create_generated_clock 90 EXAMPLES The following example creates a frequency divide_by 2 generated clock. pt_shell create_generated_clock -divide_by 2 \ -source [get_pins CLK] [get_pins foo] The following example creates a frequency divide_by 3 generated_clock. If the master clock period is 30, and master waveform is {24 36}, the generated clock period is 90 with waveform {72 108}. pt_shell create_generated_clock -divide_by 3 \ -source [get_pins CLK] [get_pins div3/Q] The following example creates a frequency multiply_by 2 generated_clock with a duty cycle of 60%. pt_shell create_generated_clock -multiply_by 2 -duty_cycle 60 \ -source [get_pins CLK] [get_pins foo1] The following example creates a frequency multiply_by 3 generated_clock with a duty cycle equal to the master clock duty cycle. If the master clock period is 30, and master waveform is {24 36}, the generated clock period will be 10 with waveform {8 12}. pt_shell create_generated_clock -multiply_by 3 \ -source [get_pins CLK] [get_pins div3/Q] The following example creates a generated clock whose edges are edges 1, 3, and 5 of the master clock source. pt_shell create_generated_clock -edges {1 3 5} \ -source [get_pins CLK] [get_pins foo2] The following example shows the generated clock in the previous example with each derived edge shifted by 1 time unit. pt_shell create_generated_clock -edges {1 3 5} -edge_shift {1 1 1} \ -source [get_pins CLK] [get_pins foo2] The following example creates an inverted clock. pt_shell create_generated_clock -divide_by 1 -invert The following example creates a rising edge pulse triggered by the rising edge of its master clock. pt_shell create_generated_clock -edges {1 1 3} -edge_shift {0 5 0} \ -source [get_pins CLK] [get_pins foo2] The following example creates a falling edge pulse triggered by the rising edge of its master clock with a period 10. pt_shell create_generated_clock -edges {1 1 3} -edge_shift {0 5 0} \ -invert -source [get_pins CLK] [get_pins foo2] create_generated_clock 91 The following example creates a frequency doubling pulse. A rising ege pulse triggered by both rising and falling edges of its master clock with a period of 10. pt_shell create_generated_clock -edges {1 1 2 2 3} -edge_shift {0 2.5 0 2.5 0} \ -source [get_pins CLK] [get_pins foo2] SEE ALSO check_timing (2), create_clock (2), get_generated_clocks (2), remove_generated_clock (2), report_clock (2), set_clock_latency (2), set_clock_transition (2), set_clock_uncertainty (2), set_propagated_clock (2). create_generated_clock 92 create_histogram Creates a custom histogram graph. SYNTAX int create_histogram [-numbins number_of_bins] [-min min_value] [-max max_value] [-greater_than gt_value] [-less_than lt_value] [-midpoint mid_value] [-worst worst_side] [-value_label value_label] [-object_name object_name] [-title title_label] [-xlabel x_axis_label] [-ylabel y_axis_label] [-width window_width] [-height window_height] -attribute attribute_name -tcl_cmd tcl_command -collection object_list int number_of_bins float min_value float max_value float gt_value float lt_value float mid_value stringworst_side stringvalue_label stringobject_name stringtitle_label stringx_axis_label stringy_axis_label int window_width int window_height stringattribute_name stringtcl_command string object_list ARGUMENTS -numbins number_of_bins An integer in the range of 1 to 300, that specifies the number of bins to use in creating the histogram. The default is 8. -min min_value Specifies the minimum value to use in binning objects; the default is the smallest value used in binning the objects, or the value of -greater_than, if specified. Any object whose associated value is less than this value is create_histogram 93 to be dropped from the histogram with a warning message. -max max_value Specifies the maximum value to use in binning objects; the default is the largest value used in binning the objects, or the value of -less_than, if specified. Any object whose associated value is greater than this value is to be dropped from the histogram with a warning message. -greater_than gt_value Specifies the non-inclusive least value limit to use in binning objects; by default, there is no filtering of data on the min end of the value range. If -min is specified and -greater_than is not, the value given for -min is used. Any object whose associated value is less than or equal to this value is to be dropped from the histogram with a warning message. -less_than gt_value Specifies the non-inclusive greatest value limit to use in binning objects; by default, there is no filtering of data on the max end of the value range. If -max is specified and -less_than is not, the value given for -max is used. Any object whose associated value is greater than or equal to this value is to be dropped from the histogram with a warning message. -midpoint mid_value Specifies the midpoint value to use in interpreting histogram bins; by default, no midpoint is used. An x-axis tick mark is placed on the midpoint value and all bins to the worst side of the midpoint are colored red while all bins to the other side of the midpoint are colored green. The worst side is none by default but can be set to left or right using the -worst option. -worst worst_side Specifies whether values less than or greater than the midpoint are to be considered "worst." Allowed values are left, meaning that values less than midpoint are worse; right, meaning that values greater than the midpoint are worse; and none (the default), meaning that neither is worse. -value_label value_label Specifies the label to place at the head of the value column in the list view accompanying the histogram. If not specified, the default is the attribute name specified for the -attribute option, or the Tcl command string specified for the -tcl_cmd option, whichever is used. This label may also be used to construct the default title and X axis labels. -object_name object_name Specifies the label to place at the head of the object name column in the list view accompanying the histogram. If not specified, the default is the standard type name for the type of objects found in the object list supplied for the -collection argument. For example, if the list consists of pins, the label "Pin" is placed at the head of the object name column. If the object list consists of multiple types of objects, the label "Object" is used. This label may also be used to construct the default title and Y axis labels. -title title_label Specifies the label to place at the top of the histogram graph. If not specified, a default title is constructed by concatenating the object_name label and the value_label label. create_histogram 94 -xlabel x_axis_label Specifies the label to place along the X axis of the histogram graph. If not specified, the default X axis label is the value_label label. -ylabel y_axis_label Specifies the label to place along the Y axis of the histogram graph. If not specified, the default Y axis label is constructed with the string "Number of object_names" where object_name is replaced with the object_name label. -width window_width Specifies the width of the window in number of pixels. The default is the width of the last histogram window closed when PrimeTime was last run. -height window_height Specifies the height of the window in number of pixels. The default is the height of the last histogram window closed when PrimeTime was last run. -attribute attribute_name Specifies the name of the attribute to use in constructing the histogram. The value of the named attribute is fetched for each object in the object list specified by the -collection argument. These values are then used to bin the objects to construct the histogram. If the attribute value is not defined for any object in the list, a warning message is issued and the object is excluded from the histogram. You must specify either -attribute or -tcl_cmd, but not both. -tcl_cmd tcl_command_string Specifies the Tcl command to use in constructing the histogram. The Tcl command is evaluated for each object in the object list specified by the collection argument. These values are then used to bin the objects to construct the histogram. If the Tcl command evaluation fails for any object in the list, a warning message is issued and the object is excluded from the histogram. You must specify either -attribute or -tcl_cmd, but not both. For a description of how the object in the object list is passed to the Tcl command, see the DESCRIPTION section. object_list Specifies the collection containing the objects that will be used to generate the histogram. DESCRIPTION The create_histogram command constructs a histogram by binning the objects in the given object list using values evaluated with the given attribute name or Tcl command. You can issue create_histogram only while the GUI is active. Type the command into the command line field at the bottom of the GUI console window. The object in the object list is passed to the Tcl command using the following conventions. For each object the following is appended to the supplied Tcl command string: "collection collection_name -index index_of_object" where collection_name is replaced by the name of the list given to the create_histogram command and the index_of_object is replaced with the zero-based index of the current object under create_histogram 95 evalution in that list. If the object is not a timing path, timing arc, or library timing arc, the following is further appended after the -collection and -index arguments: "-object object" where object is replaced with the name of a one-object collection that contains the current object under evaluation from the object list. Note that you cannot use the index_collection command as the -tcl_cmd argument for lists of timing paths, timing arcs, library timing arcs, and timing points. The histogram is graphed in a histogram view accompanied by a two-column table view that displays members of a selected bar. You can select a bar in the histogram by clicking the left mouse button over the bar. When a bar is selected, the accompanying table view displays the objects in the bar. The left column displays the object names, while the right column displays the values associated with the objects used to created the histogram. EXAMPLES These examples show creation of custom histograms using the create_histogram command. All command strings must be entered in the command line field at the bottom of the GUI console window. The following example shows creation of a histogram using the -attribute flag to retrieve an attribute value for each object in a collection. In this example, the fanout_load attribute value is used to bin all pins in the design. The graph is labeled with the title string "Pin Fanout" using the -title option. A new window frame is created for the new histogram by default because no view is given with a view option. The new histogram view is named view1 using the -name option, pt_shell create_histogram -name view1 -attribute fanout_load \ -title "Pin Fanout" -collection [get_pins *] 1 The following example shows creation of another histogram binning cells by area, with the graph reusing the histogram view named view1 created in the previous example. The histogram will have the default title "Cell area", default X axis label "area" and Y axis label "Number of cells". pt_shell create_histogram -view view1 -attribute area \ -collection [get_cells *] 1 The following example shows creation of a histograms using the -tcl_cmd flag to use a user defined-Tcl procedure to retrieve a value for each object in a collection. First, a Tcl script file named "myscript.tcl" containing the following lines is created to define a Tcl procedure named "myproc" that retrieves the fanout_load attribute value for the object that is passed in the procedure arguments: proc myproc {flag1 clct flag2 idx flag3 obj} { set result [get_attribute $obj fanout_load] return $result } create_histogram 96 The disregarded strings flag1, flag2, and flag3 are placeholders for the collection, -index, and -object option flags, respectively, preceding the three arguments. You can identify the object by directly using the object in the third argument as in the myproc procedure above, or by using the collection name and the object index in the first and second arguments, respectively. The following procedure, myproc2, performs the same function as myproc but retrieves its objects using the first and second arguments: proc myproc2 {flag1 clct flag2 idx flag3 obj} { set mypin [index_collection $clct $idx] set result [get_attribute $mypin fanout_load] return $result } You can now source the script file to define the procedures within the PrimeTime Tcl interpreter context: pt_shell source myscript.tcl 1 Once the procedures have been defined, you can reference them from the -tcl_cmd argument in a create_histogram command invocation as in the following example. pt_shell create_histogram -name view1 -tcl_cmd myproc \ -title "Pin Fanout" -collection [get_pins *] 1 In this example, the embedded command [get_pins *] is first interpreted to create a collection of all pins in the design. The Tcl procedure "myproc" is then invoked for each pin object in the collection to retrieve a value per pin to use in creating the histogram. SEE ALSO change_histogram (2), collections (2). create_histogram 97 create_ilm Extracts interface logic model and writes it to a new directory. Also, sets the is_interface_logic_pin attribute on pins of the current design that are part of its interface logic model. SYNTAX int create_ilm [-script_format format] [-instances instance_list] [-ignore_ports port_list] [-auto_ignore] [-verbose] [-ignore_boundary_pins pin_list] [-include incl_list] [-verification_script] [-latch_level levels] [-context_borrow] [-keep_ignored_fanout] [-include_pins pin_list] [-critical_pins] [-traverse_disabled_arcs] [-parasitics_options para_options] [-sdf_options sdf_options] [-block_scope] [-block_scope_only] [-scope_scenario scenario_name] list int list list list list list string port_list level instance_list pin_list incl_list para_options sdf_options scenario_name ARGUMENTS -script_format format Specifies the output format for the script. Allowed values are ptsh (the default) for pt_shell, dcsh for dc_shell, and dctcl for dc_shell-t. -instances instance_list Specifies the list of instances for which ILMs need to be generated. Separate ILMs are generated for each instance and written out to directories named after the instance name. -ignore_ports port_list Specifies a list of input or output ports whose fanout or fanin is to be ignored when placing the is_interface_logic_pin attribute. Substitute the list of ports you want for port_list. Clock ports are automatically ignored; create_ilm 98 you do not have to specify them in this list. You can use this option to exclude the fanout of ports connected to chiplevel nets (for example, scan enable and reset) from impacting the contents of interface logic. If these nets are not explicitly ignored, they cause unnecessary logic (for example, internal registers) to be part of the interface logic on the current design. You can also use this option to selectively generate the interface logic for a subset of the ports on a block; for example, an interface logic model (ILM) can model only the timing behavior on a subset of the ports on a block. By default all nonclock input and all output ports are used in identifying the contents of interface logic. The -ignore_ports, -ignore_boundary_pins and -auto_ignore options are mutually exclusive. -auto_ignore Enables automatic determination of ports whose fanout should be ignored when placing the is_interface_logic_pin attribute. A port is ignored if the percentage of the total registers in the design in the transitive fanout of the port exceeds a specified threshold percentage contained in the ilm_ignore_percentage variable (default 25). You can use this option to help you identify the test enable and reset ports of your design. Before using it, examine the current value of the ilm_ignore_percentage variable and reset it if necessary. Note that the auto_ignore option might potentially ignore ports you do not want to ignore, or fail to ignore ports you want to ignore. Carefully read the messages issued by this command when you use this option to see which ports have been ignored and what percentage of registers to which they fanned out. The -ignore_ports, -ignore_boundary_pins and -auto_ignore options are mutually exclusive. -verbose Indicates that information about the number of cells and nets in the original design and in the ILM netlist is to be written to standard output. -ignore_boundary_pins pin_list Specifies a list of boundary pins whose fanout or fanin is to be ignored when placing the is_interface_logic_pin attribute while extracting an instance ILM. Works similar to -ignore_ports option but works for instance ILMs. This option can only be used along with the -instances option. The -ignore_ports, -ignore_boundary_pins and -auto_ignore options are mutually exclusive. -include incl_list Specifies the additional categories to be included in the ILM. Allowed values are net_pins, boundary_cells, si_delay_pins and si_noise_pins. The net_pins specifies that all pins on non-clock interface logic nets and propagated clock interface logic nets are to be included in the netlist. Use this option if the interface logic model (ILM) will be used in non-SDF flows and delay calculation will be performed using the information contained in the ILM. Preserving all pins on a net maintains correct pin capacitance information for the net. The net_pins does not affect non-propagated clock nets; that is, nets in the clock network that have user-specified source latency. The boundary_cells specifies that the ILM has to include the boundary cells for all input ports. By default, the boundary cells would be present for all inputs except for the ignored ports. This option allows users to include create_ilm 99 boundary cells for the ignored input ports also so that DRC checks can be performed at top level. The si_delay_pins specifies that the ILM has to include additional logic required to perform cross-talk delay analysis at the chip-level. Since the cross-talk flow involves detailed parasitics, the si_delay_pins also turns the net_pins on. The si_noise_pins specifies that the ILM has to include additional logic required to perform noise analysis at the chip-level. Since the noise flow involves detailed parasitics, the si_noise_pins also turns the net_pins on. -verification_script Specifies that a script needs to be generated that can be used for the verification of ILM. By default, create_ilm command generates a script that can be used when the ILM is instantiated at upper level of hierarchy. This option additionally generates a script that can be used to validate the ILM against the original block from which the ILM was generated. -latch_level levels Specifies the number of logic levels over which time borrowing can occur for latch chains that are a part of the interface logic. Substitute the number of levels you want for levels. By default, all latches found in interface logic are assumed to be potential borrowers. Thus, all logic from I/O ports to flip-flops or output ports are identified as belonging to interface logic. When you use this option, note that the value of level must account for the borrowing behavior of latches only on interface timing paths. If n represents a latch level, then n + 1 represents the number of latches maintained in latch chains that originate at input ports. The n + 1th latch functions as an edgetriggered register and decouples I/O paths from internal paths. Use this option only when there are latches in the interface logic for a block. Specifying this option might potentially result in less accurate models, because not all latches are allowed to borrow. The -context_borrow and latch_level options are mutually exclusive. -context_borrow Specifies that latch borrowing at the interface should be established based on the current context defined for the design. So, latches that borrow based on arrival times defined on input ports and clocks defined on the design are traced through, but path tracing stops at nonborrowing latches. The context_borrow and -latch_level options are mutually exclusive. -keep_ignored_fanout Specifies that the fanout from ignored input ports to interface logic is to be maintained in the model. Thus, ignored ports are not used to identify interface logic, but connections between ignored ports and interface logic are preserved. Timing slacks for ignored ports might differ from those reported on the original netlist because connections from ignored ports to internal registers are not preserved in the model. -include_pins pin_list Specifies a list of pins that must be included in the interface logic. Substitute the list of pins you want for pin_list. This option can be used to optionally add internal pins to the interface logic. After the interface logic is determined, this list of pins is added to the interface logic. You can use this option to define additional interface logic pins that will otherwise be removed in the model. There will not be any affect on pins that create_ilm 100 are already in the interface logic. Use this option in conjunction with the all_fanin and all_fanout commands to include a particular cone of logic in the model. -critical_pins Specifies that critical pins interface logic must be identified. This option allows you to extract a model that keeps only the pins in the critical paths of the design. You can use this option to extract a critical pins interface logic. The model generated contains the interface logic pins in the critical paths of the design. The model is compact compared to normal interface logic models, but might not be as accurate outside of the current context. This model can be used only to do critical path analysis. It might take much longer to generate this model than the normal model. The -include {si_delay_pins} option is not currently supported for critical pins ILM. -traverse_disabled_arcs Specifies that the interface logic should not be affected by disabled arcs/ pins on the design. If specified, this option forces the traversal of disabled arcs while determining interface logic. -parasitics_options para_list Specifies that the parasitics need to be generated for ILM. Allowed values for the list are: spef_format, sbpf_format, input_port_nets and constant_nets. The spef_format specifies that the parasitics are to be written in SPEF. The sbpf_format specifies that the parasitics are to be written in SBPF. The input_port_nets indicates that parasitic information is to be written out for nets connected to the input ports on the current design. By default, this information is not written out. The constant_nets indicates that parasitic information is to be written out for constant nets also. By default, this information is not written out. When the -parasitics_options is specified, all the net pins of ILM nets are included. In other words, the -include {net_pins} option is always assumed when -parasitics_options is used. -sdf_options sdf_options Specifies that SDF needs to be generated for ILM. Allowed values for the list are: annotated, no_edge, 2.1_version, 3.0_version, input_port_nets, output_port_nets. The annotated value indicates that the SDF is to include only timing arcs that have been annotated with the read_sdf, set_annotated_delay, or set_annotated_check commands. The no_edge value indicates that the generated SDF is not to include any edges (posedge or negedge) for combinational IOPATHs. The 2.1_version value selects which SDF version of 2.1. This is the default version. The 3.0_version value selects which SDF version of 3.0. The input_port_nets value indicates that the SDF file is to include delays of nets connected to input ports of the current design. By default, these delays are not written to the SDF file because the external connectivity information for ports is not available. The output_port_nets value indicates that the SDF file is to include delays of nets connected to output ports of the current design. By default, these create_ilm 101 delays are not written to the SDF file because the external connectivity information for ports is not available. -block_scope Specifies that the block scope information needs to be captured for the timing model. If specified, this creates a separate file that contains scope information for the block that will be replaced by ILM at the top-level analysis. Note that the scope information that will be captured and stored is not impacted by the variable hier_scope_check_defaults. -block_scope_only Specifies that only the block scope information needs to be captured, and not the ILM. This option is useful for the later runs when an ILM was already generated but the scope of block-level validation has changed. If specified, this creates a separate file that contains scope information for the block that will be replaced by ILM at the top-level analysis. Note that the scope information that will be captured and stored is not impacted by the variable hier_scope_check_defaults. -scope_scenario scenario_name Specifies the name of the scenario for which the scope data needs to be labeled and later checked for. The scope information captured and stored in the scope data file will be marked as corresponding to the given scenario. If not specified, a fixed default name is used internally. DESCRIPTION Extracts an interface timing model (ILM) for the design or given list of instances. The ILM is written to a directory with name of the design, or the hierarchical name of instance with slash (’/’) replaced by underscore (’_’). The location of this potentially new directory is given by the variable pt_ilm_dir variable. The command generates the following files: dir_name/ilm.v (verilog design for the ILM) dir_name/ilm_inst.pt.gz (script to apply the instance constraints) Additionally, the command might generate: dir_name/ilm.{sbpf, spef.gz} (Parasitics if -parasitics_options is given) dir_name/ilm.sdf (SDF file if -sdf_options is given) dir_name/ilm_verif.pt.gz (verification script for the design) dir_name/ ilm.txt (list of aggressor annotation pins if -include {si_delay_pins} is given) dir_name/ilm.scope (scope information for the block being replaced by model) Also, the command sets is_interface_logic_pin attribute on pins of the current design that are part of its interface logic. The interface logic on a block contains all cells whose timing is impacted by, or impacts, the external environment of a block. The following list describes such parts of interface logic: • All cells in timing paths that lead from input ports to registers or output ports that terminate the paths. • All cells in timing paths that lead to output ports from registers or input ports create_ilm 102 that originate the paths. • Clock trees that drive interface registers; including any registers in the clock tree. Clock-gating circuitry is part of interface logic if it is driven by external ports, but not if it is driven by registered outputs on a block. Notice that interface logic does not include internal register-to-register paths and logic on a block associated only with these paths. Additional logic may be included using the -include_pins option. If the -include {si_delay_pins} option is given, additional register-to-register logic may be pulled in that is needed for cross-talk analysis at chip level. This command implicitly performs an update_timing on the design if required. You can review the objects you have identified as interface logic by using the get_ilm_objects command. Also, the command can be used to generated scope information for the block that will be replaced with the ILM at top-level. EXAMPLES The following example extracts ILM and sets the is_interface_logic_pin attribute on all nonclock pins in the current design, except for pins in the fanin/fanout of ports port1, port2, and port3. pt_shell create_ilm -ignore_ports [get_ports {port1 port2 port3}] The following example extracts ILM for instance I1, additionally includes three levels of logic from internal pin I1/ff/Q and also includes internal cross-talk pins needed for top-level cross-talk analysis. pt_shell set ilm_pins [all_fanout -level 3 \ -flat [get_pin I1/ff/Q]] pt_shell create_ilm -instances {I1}\ -include_pins $ilm_pins -include {si_delay_pins} The following example extracts a critical pins interface timing model. pt_shell create_ilm -critical_pins -include {net_pins} The following example extracts ILM by placing the is_interface_logic_pin attribute on all nonclock pins in the current design, except for pins identified by the auto_ignore option. Because the value of the ilm_ignore_percentage variable is currently 35, pins are ignored if the percentage of the total design registers in their transitive fanout is greater than 35. The -latch_level option with a value of 1 states that the first latch encountered in IO paths might potentially borrow, but the second latch can be treated as an edge-triggered device. Thus, two levels of latches are maintained in the interface logic. Also, it creates scope information for the block. pt_shell printvar ilm_ignore_percentage ilm_ignore_percentage = "35" create_ilm 103 pt_shell create_ilm -auto_ignore -latch_level 1 -block_scope SEE ALSO pt_ilm_dir (3) ilm_ignore_percentage (3). check_block_scope (2). hier_scope_check_defaults (3). create_ilm 104 create_lcd_operating_condition Creates a lcd operating condition by using different operating conditions in the library. SYNTAX int create_lcd_operating_condition -op_worst worst_case_operating_condition_name mult_worst worst_case_multiplier -op_nominal nominal_operating_condition_name mult_nominal nominal_multiplier -op_best best_case_operating_condition_name -mult_best best_case_multiplier -library library_name name string worst_case_operating_condition_name float worst_case_operating_condition_multiplier string nominal_operating_condition_name float nominal_operating_condition_multiplier string best_case_operating_condition_name float best_case_operating_condition_multiplier string library_name string name ARGUMENTS -op_worst worst_case_operating_condition_name Specifies the worst case operating conditon name to be used in LCD. -mult_worst worst_case_operating_condition_multiplier Specifies the multiplier to be applied to worst case operating conditon. -op_nominal nominal_operating_condition_name Specifies the nominal operating conditon name to be used in LCD. -mult_nominal nominal_case_operating_condition_multiplier Specifies the multiplier to be applied to nominal operating conditon. -op_best best_case_operating_condition_name Specifies the best case operating conditon name to be used in LCD. -mult_best best_case_operating_condition_multiplier Specifies the multiplier to be applied to best case operating conditon. -library library_name Specifies the name of the library for the lcd operating condition. name Specifies the name for the lcd operating condition. DESCRIPTION Creates an LCD operating condition in the specified library. A technology library contains a fixed set of operating conditions. This command allows you to create an LCD operating condition that adds delay uncertainty to each gate based on LCD derived from the operating conditons already existing in the library or the create_lcd_operating_condition 105 operating conditions you created. You can use these LCD operating conditions to calculate gate delay in min-max mode to analyze timing with statistical effects. LCD for one delay path considers using three operating conditions (worst case, nominal, and best case) with different weights to compute delays per mode (early mode and late mode). When calculating a delay, a given operating condition with the correspondent output loading is used. Currently, the delay rules (DCM) only support worst-case and bestcase pin capacitances. In order to support nominal delay the assumption is made so that the output loading is linear between best-case and worst-case operating conditons. Therefore, the output loading for nominal is the sum of best case and worst case divided by 2. For slew propagating, if the sum of the weights is larger than 1.0, unwanted pessimism is introduced because of the ripple effect of the dependency of output slew on input slew of a gate. To avoid this behavior, the slew at the output of each delay path is divided by the sum of the weights for the given operating conditon that was created out of an LCD. To see the operating conditions defined for a library, use report_lib. To set lcd operating conditions on the current_design, use set_operating_conditions. EXAMPLES The following examples show how to create lcd operating conditons and how to set them to use. pt_shell create_lcd_operating_condition -op_worst wccom -op_nominal nocom op_best bccom -mult_worst 0.7 -mult_nominal 0.2 -mult_best 0.1 -library library_name lcd_late pt_shell create_lcd_operating_condition -op_worst wccom -op_nominal nocom op_best bccom -mult_worst 0.1 -mult_nominal 0.2 -mult_best 0.7 -library library_name lcd_early pt_shell set_operating_conditons -max lcd_late -min lcd_early -analysis_type on_chip_variation SEE ALSO set_operating_conditions (2), report_lib (2). create_lcd_operating_condition 106 create_net Creates nets in the current design. SYNTAX int create_net [-exact] net_list list net_list ARGUMENTS -exact Indicates that names are to be used exactly as specified. Use this option if you want to create a net that contains a hierarchy or wildcard character as part of the net name. For more information, see the section entitled "Naming Nets with Special Characters". net_list Specifies a list of nets to be created. DESCRIPTION The create_net command creates new nets in the current design. Like all other netlist editing commands, for create_net to succeed, all of its arguments must succeed. If any arguments fail, the netlist remains unchanged. create_net returns a 1 if successful and a 0 if unsuccessful. create_net behaves almost identically to create_cell. Nets are created in scope; that is, at or below the current instance. Net names are specified as for other commands, using the full hierarchical name relative to the current instance, as in the following example: create_net u1/u2/new_net class/AN2 This command attempts to create a net named new_net in the hierarchical block u1/u2. The name to the right of the last hierarchical separator is the actual net name, and the remainder is sent to the search engine to find a hierarchical block in which to create the new net. The operation fails if any of the following are true: • The search engine cannot find "u1/u2". • The search engine finds multiple blocks that match "u1/u2". • The search engine finds a leaf cell matching "u1/u2". • The search engine finds a net, port or hierarical pin matching "u1/u2/new_net". create_net 107 Naming Nets With Special Characters If you want to create a net whose name contains the current hierarchical separator or wildcard characters used by the search engine, you must do the following: • Use current_instance to change the scope to the block in which you want the new net created. • Use create_net -exact to create the net. For examples, see the EXAMPLES section. EXAMPLES The following example creates nets in the current instance, and at a level below the current instance. Currently, u1 is an instance of a design that has multiple instances. Therefore, it is uniquified as part of the editing operation. pt_shell create_net new_net1 Information: Created net ’new_net1’ in design ’top’. (NED-016) 1 pt_shell create_net u1/new_net1 Uniquifying ’u1’ (block1) as ’block1_0’. Information: Created net ’new_net1’ in ’top/u1’. (NED-016) 1 The following example creates net a/b in the hierarchical block u1/u2. The first attempt fails, because the -exact option was omitted. Here, u1/u2 is an instance of a design that has multiple instances; therefore, it is uniquified as part of the editing operation. u1 was already uniquified in the previous example. pt_shell current_instance u1/u2 u1/u2 pt_shell create_net a/b Error: Could not create net ’a/b’: a not found. (NED-041) Error: No changes made. (NED-040) 0 pt_shell create_net a/b -exact Uniquifying ’u1/u2’ (block2) as ’block2_0’. Information: Created net ’a/b’ in ’top/u1/u2’. (NED-016) 1 SEE ALSO create_cell (2), remove_net (2), size_cell(2), swap_cell(2), write_changes (2). create_net 108 create_operating_conditions Creates a new set of operating conditions in a library. SYNTAX int create_operating_conditions -name name -library library_name -process process_value -temperature temperature_value -voltage voltage_value [-tree_type tree_type] [-calc_mode calc_mode] [-rail_voltages rail_value_pairs] string name string library_name float process_value float temperature_value float voltage_value string tree_type string calc_mode Tcl list rail_value_pairs ARGUMENTS -name name Specifies the name of the new set of operating conditions. -library library_name Specifies the name of the library for the new operating conditions. -process process_value Specifies the process scaling factor for the operating conditions. Allowed values are 0.0 through 100.0. -temperature temperature_value Specifies the temperature value, in degrees Celsius, for the operating conditions. Allowed values are -300.0 through +500.0. -voltage voltage_value Specifies the voltage value, in volts, for the operating conditions. Allowed values are 0.0 through 1000.0. -tree_type tree_type Specifies the tree type for the operating conditions. Allowed values are best_case_tree, balanced_tree (the default), or worst_case_tree. The tree type is used to estimate interconnect delays by providing a model of the RC tree. -calc_mode calc_mode For use only with DPCM libraries. Specifies the DPCM delay calculator mode for the operating conditions; analogous to the process used in Synopsys libraries. Allowed values are unknown (the default), best_case, nominal, or worst_case. The default behavior (unknown) is to use worst case values during create_operating_conditions 109 analysis similarly to worst_case. If -rail_voltages are specified, the command sets all (worst_case, nominal, and best_case) voltage values. -rail_voltages rail_value_pairs Specifies a list of name-value pairs that defines the voltage for each specified rail. The name is one of the rail names defined in the library; the value is the voltage to be assigned to that rail. By default, rail voltages are as defined in the library; use this option to override the default voltages for specified rails. DESCRIPTION Creates a new set of operating conditions in the specified library. A technology library contains a fixed set of operating conditions; this command allows you to create new, additional operating conditions. To see the operating conditions defined for a library, use report_lib. To set operating conditions on the current design, use set_operating_conditions. EXAMPLES The following example creates a new set of operating conditions called WC_CUSTOM in the library "tech_lib", specifying new values for process, temperature, voltage, and tree type. By default, rail voltages remain as defined in the library. pt_shell create_operating_conditions -name WC_CUSTOM \ -library tech_lib -process 1.2 -temperature 30.0 -voltage 2.8 \ -tree_type worst_case_tree The following example creates a new set of operating conditions called OC3, in the library "IBM_CMOS5S6_SC", specifying new values for process, temperature, voltage, and rail voltages for rails VTT and VDDQ. By default, the tree type balanced_tree is used. pt_shell create_operating_conditions -name OC3 \ -lib IBM_CMOS5S6_SC -proc 1.0 -temp 100.0 -volt 4.0 \ -rail_voltages {VTT 3.5 VDDQ 3.5} SEE ALSO set_operating_conditions (2), report_lib (2). create_operating_conditions 110 create_power_group Creates a power group of cells in the current design. SYNTAX int create_power_group -name name [object_list] [-default] string name list object_list ARGUMENTS -name name Specifies the name for the power group. The name should not conflict with names of existing power groups. object_list Specifies a list of cells to be included in this power group. This option is mutual exclusive with -default. -default Indicates that the specified power group is predefined and the default list of cells are to be included in the power group. This option is mutual exclusive with object_list. DESCRIPTION Group a list of cells of special interests (not necessarily in the same hierarchy) to form a power group. The create_power_waveforms and report_power commands are able to generate power waveform and power report for this power group. The cells contained in power groups are leaf cells. If a hierarchical cell is specified in the object_list, all the leaf cells contained by the hierarchical cell, instead of the hierarchical cell itself, are added to the power group. There are several power groups predefined and automatically created by the tool. But if a predefined power group has been removed, the -default option can be used to regenerate it. The following is a list of the predefined power groups ordered by priority from high to low. Note that the predefined power groups are not supposed to be overlaping with one another. If one cell happens to belong to more than one group, it is put into the group with higher priority. io_pad All I/O PAD cells. create_power_group 111 memory All memory cells. black_box All black boxes. clock_network Cells in the clock network. The contents is consistent with the results from "get_clock_network_objects -type cell". If the variable power_clock_network_include_clock_gating_network is set to true, the contents is consistent with the results from "get_clock_network_objects -type cell -include_clock_gating_network". register The latches, flip-flops driven by the clock network. The contents is consistent with the results from "get_clock_network_objects -type register". If the variable power_clock_network_include_clock_gating_network is set to true, the contents is consistent with the results from "get_clock_network_objects -type register -include_clock_gating_network". sequential All other sequential cells. combinational All other combinational cells. EXAMPLES In the following example, a power group called clock_tree is created to accomodate all the clock tree cells. pp_shell create_power_group -name clock_tree [get_clock_tree_cells] 1 In the following example, the predefined power group clock_network has been removed earlier, now you want to create it again with the default list of cells. pp_shell create_power_group -name clock_network -default 1 SEE ALSO report_power_groups (2), remove_power_groups (2), get_power_group_objects (2), report_power (2), create_power_waveforms (2), power_clock_network_include_clock_gating_network (3). create_power_group 112 create_power_rail_mapping Map the power rails defined in the libraries to the physical power rails existing in the design. SYNTAX create_power_rail_mapping design_rail [-lib_rail_name rail_name] [-cells cell_list] [-off_condition condition] [-default] string fdesign_rail string rail list cell_list string condition ARGUMENTS design_rail Defines the power rail used in the design. -lib_rail_name power_rail_defined_in_library Specifies the power rail defined in the library. It can take the power rail name defined in the library and also take "all". By using -lib_rail_name all, the mapping is applied to all the power rails in each library associated with the library cells. If option -lib_rail_name is not used, the mapping is applied to the default library power rail in each library associated with the library cells. -cells cell_list Specifies the instance names or collections of instances. The instance can be hierarchical or leaf instances. For a instance block, only the top instance needs to be specified. All the instances inside such block will be affected by the mapping. Without this option, the mapping will be created for the whole design. -off_condition condition Specifies the power-off condition for the design power rail. At power-off state, the portion of design that is powered off by the specific design power rail will not contribute any dynamic or static power. The boolean expression takes net names plus operators. The operators supported are: (, ), !, +, *, &, |, ^, ’. When the expression is evaluated to be "1", the design power rail is in power-off state. If the expression is evaluated to be "0" or any unknow state, the design power rail is in power-on state. Please make sure that the states of the nets used in the boolean expression are clearly defined to avoid any unexpected results. If -power_off option is omitted, the design power rail is assumed to be on all the time. When switching activity information is specified by VCD file, the state of the power control signal nets are monitored. The power-off expression is evaluated if there is any state change on these control nets. When a specific create_power_rail_mapping 113 power rail is powered-off, neither dynamic nor static power will be dissipated on the cell (or part of cell) powered by this rail. When switching activity information is specified by statistical toggle rate and state probability, the state probability of the power rail being on is calculated. As default, only leakage power is scaled by the state probability of the associated power rail being on. Set variable pwr_scale_dyn_pwr_at_power_off to true, if dynamic power needs to be scaled too. Dynamic power scaling is only needed if the statistical switching activity includes toggles happened when the rail is being powered off. -default Specifies the design power rail to be the default rail in the design. If not specified, the design power rail defined by the first create_power_rail_mapping command is assigned as the default design rail. DESCRIPTION Use this command to map the power rails defined in the libraries to the physical power rails existing in the design. Such rail mapping is done at cell (instance) level, which gives user the flexibility to connect the same library cell to different physical power rails in a design. The design power rails specified in this command are virtual power rails, which means that the rail connections do not actually exist in the netlist. No voltage level violation will be checked for such virtual rail connections. It is allowed to connect cells with different voltages to the same virtual design power rail. This command enables PrimeTime PX to create collections of instances on different power rails. Thus provides the capability and flexibility to create rail-based power reporting at design level. This command also enables PrimeTime PX to be sensitive to the power-on/off control signals associated with the design power rails. Single-rail or multi-rail cell in PrimeTime PX is based on its cell definition in technology library. A multi-rail cell can have rail specific internal or leakage power tables defined in the library. So that power consumption can be reported for different rails. This command can create the rail mapping for the whole design or for specific instances (hierarchical or leaf-level). Multiple create_power_rail_mapping commands can be issued, the later overwrites the previous settings if overlaps. For single-rail design, if not specified, the default library rail will be mapped to the default design rail internally. Command report_power_rail_mapping can be used to report existing power rail mapping information. EXAMPLES The following example shows how to create rail mapping and generate rail-based power reports for a multi-rail design. There are three instance blocks in this design: block1, block2 and ls_block. Block block1 and block2 are both single-rail instance blocks with all the leaf cells powered by the default library power rail defined in each associated technology library. Block block1 is connected to design power rail VDD1 in the design while block block2 is connected to design power rail VDD2 in the create_power_rail_mapping 114 design. Block ls_block is a dual-rail instance block with rail V1 and V2 defined in its cells’ technology library. Library power rail V1 is connected to design power rail VDD1 and library power rail V2 is connected to design power rail VDD2. Command current_power_rail can select the rail of interest and update_power can generate the power analysis results just for the interested rails. As a result, report Power_VDD1.rpt file will only contain the power consumed on design power rail VDD1 and report Power_VDD2.rpt will only contain the power consumed on design power rail VDD2. Since current_power_rail all will mark all the design power rails to be interested, report Power_all.rpt file will contain the total power consumed for entire design. pt_shell create_power_rail_mapping VDD1 -cells block1 pt_shell create_power_rail_mapping VDD2 -cells block2 pt_shell create_power_rail_mapping VDD1 -lib V1 -cells ls_block pt_shell create_power_rail_mapping VDD2 -lib V2 -cells ls_block pt_shell current_power_rail VDD1 pt_shell update_power pt_shell report_power Power_VDD1 pt_shell current_power_rail VDD2 pt_shell update_power pt_shell report_power Power_VDD2 pt_shell current_power_rail all pt_shell update_power pt_shell report_power Power_all SEE ALSO report_power_rail_mapping (2), current_power_rail (2), update_power (2), report_power (2), read_vcd (2), read_saif (2), set_switching_activity (2), power_scale_dynamic_power_at_power_off (3). create_power_rail_mapping 115 create_power_waveforms Create power waveforms and calculate peak power. SYNTAX int create_power_waveforms [-output file_name] [-format file_format] [-leaf] [-levels level] [-groups group_list] [-clocks clock_list] [object_list] string file_name string file_format int level list clock_list list group_list list object_list ARGUMENTS -output file_name Specify the prefix of the file in which the waveform data is to be written. -format file_format Specify the format of the file in which the waveform data is to be written. The value for this option can be: fsdb, out or none. Default is fsdb. If set to none, waveform data is not to be dumped, but peak power is calculated. Indicates that waveforms for leaf cells are to be created as well. By default, waveforms are not created for leaf cells. -levels level Create power waveforms for hierarchical cells only to the specified level from the top. The default is to create waveforms for all non-leaf cells. -groups group_list Create power waveforms for the specified power groups. -clocks clock_list This option is only used when generating average cycle waveform in the SAIF or Vector Free flow. Specifies the clocks based on which average waveform is to be created. If not specified, all existing clocks are to be considered. object_list Create power waveforms only for the specified cells. DESCRIPTION Create power waveforms for the design and specific hierarchies or cells. At the same create_power_waveforms 116 time, peak power, which is the largest power value in the waveform, for the design and cells are calculated. The created power waveforms are dumped into waveform files. The calculated peak power is saved and can be reported by the report_power command. Before generating power waveforms, the average power information is updated as well. There are two formats for the waveform file: .out and .fsdb. By default, PrimeTime PX output a .fsdb file. If "-format out" is specified, PrimeTime PX outputs a text .out file. Both files can be used as the input of the waveform display in PrimeTime PX. If "-format none" is specified, PrimeTime PX does not output waveform, but only calculates the peak power. For VCD flow, a waveform is a series of event-based power data calculated over time during the processing of the VCD data. For SAIF and Vector Free flow, the waveform is called average cycle waveform, which is based on the average power over one clock cycle or common base period of multiple clocks. The waveform shows where in the cycle the power is consumed, or in other words, how the power is distributed within the cycle or common base period. Timing information is heavily used to generate average cycle waveform. Therefore, make sure timing constraints are complete and timing is correct before creating average cycle waveforms. It is suggested to use the commands check_timing and check_power before using this command for average cycle waveform. For multi-clock designs, the tool generates an average cycle waveform for the common base period of all clocks, by default. However, the tool cannot generate a single average cycle waveform for asynchronous clocks. In this case, specify the -clocks option to instruct PrimeTime PX to generate a cycle waveform only for the synchronous clocks. Another case to use the -clocks option is when the common base period of all clocks is too big, which means the clocks are not synced with each other very well. In this case, use the option to generate cycle waveform for a group of clocks with smaller common base period. By default, the common base period of a group of clocks is called too big when it is greater than 10 times of the period of the slowest clock in the group. To redefine this, use the variable power_average_waveform_limit. Refer the man page of this variable for details. EXAMPLES This example outputs the text file foo.out with waveform information in the .out format. pt_shell create_power_waveforms -output foo -format out SEE ALSO update_power (2), report_power (2), check_power (2), check_timing (2), power_average_waveform_limit (3). create_power_waveforms 117 create_qtm_constraint_arc Creates a constraint arc for a QTM. SYNTAX string create_qtm_constraint_arc [-name arc_name] [-setup] [-hold] -from port_name [-to port_spec] -edge triggering_edge [-path_type name] [-path_factor multiplication_factor] [-value constraint_value] stringarc_name stringport_name list port_spec stringtriggering_edge stringname float multiplication_factor float constraint_value ARGUMENTS -name arc_name Specifies the name of the constraint arc. -setup Creates a setup arc. -hold Creates a hold arc. -from port_name Specifies the constraining port name. Define this port as a clock port. -to port_spec Specifies the constrained port. Define this port as an input/inout port. -edge triggering_edge Specifies the triggerring edge of the clock (rise/fall). -path_type name Specifies the path type you want to use to set the delay. -path_factor multiplication_factor Specifies the multiplication factor for the path type. -value constraint_value Specifies the delay value in terms of the time units you use for the model. create_qtm_constraint_arc 118 DESCRIPTION This command allows you to create a constraint arc in a QTM. The -from port denotes the constraining port, and the -to port denotes the constrained port. The -fromP port must be defined as a clock port and the -to port must be an input/inout port. The -setup and -hold switches are used to specify either a setup arc or a hold arc. You must use one of the switches and cannot use both simultaneously. To specify the triggering edge of the clock, use the -edge option. The option takes rise/fall as valid values. To specify the delay value, use i-path_type. You can specify the delay as a value in terms of the time units used in the design. Use either the -path_type or the -value option; you cannot use both simultaneously. If the constraint arc is a setup arc, the QTM parameter global setup time is added to the value of the specified setup. If the constraint arc is a hold arc, the global hold time is added to the value of hold specified. You must define the global setup time before creating any setup arc and global hold time before creating any hold arc. The command checks to see if these parameters are defined. Global setup and time, and global hold time are defined using the set_qtm_global_parameter command. To see the information about the current QTM model, use report_qtm_model command. For basic description about QTM, please refer to create_qtm_model man page. For a more detailed description about QTM please refer to the PrimeTime User Guide. EXAMPLES The following command creates a setup arc from the positive edge of constraining pin CLK to IN1 (constrained pin) with a delay equivalent to 2 times that of path type path1. pt_shell create_qtm_constraint_arc -setup -edge rise -from CLK -to IN1 path_type path1 -path_factor 2 The following command creates a hold arc from the positive edge of constraining pin CLK to IN1 (constrained pin) with a delay equivalent to 2 times that of path type path1. pt_shell create_qtm_constraint_arc -hold -edge rise -from CLK -to IN1 path_type path1 -path_factor 2 The following command creates a hold arc from the positive edge of constraining pin CLK to IN1 (constrained pin) with a delay of 3 time units. pt_shell create_qtm_constraint_arc -hold -edge rise -from CLK -to IN1 -value 3.0 SEE ALSO create_qtm_delay_arc(2), create_qtm_model(2), create_qtm_path_type(2), save_qtm_model(2), report_qtm_model(2), get_qtm_ports(2). create_qtm_constraint_arc 119 create_qtm_delay_arc Creates a delay arc for a Quick Timing Model (QTM). SYNTAX string create_qtm_delay_arc [-name arc_name] -from port_spec -to port_spec [-edge triggering_edge] [-path_type path_type] [-path_factor multiplication_factor] [-value delay_value] stringarc_name list port_spec list port_spec stringtriggering edge stringpath_type float multiplication_factor float delay_value ARGUMENTS -name arc_name Specifies the name of the delay arc. -from port_spec Specifies the QTM port name or a collection of QTM ports, which is the start point of the delay arc. For an edge trigerring arc this must be a clock. -to port_spec Specifies the QTM port name or a collection of QTM ports. This port must be output/inout type. -edge triggering_edge Specifies the triggering edge (rise or fall) -path_type name Specifies the path type you want to use to set the delay. -path_factor multiplication_factor Specifies the multiplication factor for the path type. -value delay_value Specifies the delay value in terms of the time units you use for the model. DESCRIPTION This command allows you to create a delay arc in a QTM from a QTM port or collection of QTM ports to a port or collection of QTM ports. If you specify a list of ports for the from and to ports, a delay arc is created from each start port to each end port. To create a edge triggering arc, use the -edge option. For an edge trigerring arc, the clk_to_output delay (specified as a global parameter) is added to the delay value specified. create_qtm_delay_arc 120 You can use a -path_type to specify the delay value or you can specify the delay as a value in terms of the time units used in the design. Use either the -path_type or the -value option; you cannot use both options simultaneously. To show the information about the current QTM model, use report_qtm_model command. For a basic description about QTM, please refer to create_qtm_model man page. For a more detailed description about QTM, please refer to the PrimeTime User Guide. EXAMPLES The following command creates a delay arc from input ports {A, B, C} to output port D with a delay value of 2.0 time units. pt_shell create_qtm_delay_arc -from {A, B, C} -to D -value 2.0 The following command creates an arc from clock CLK to output port OUT with a delay equivalent to 3 times that of path type ’path1’. pt_shell create_qtm_delay_arc -from CLK -to OUT -path_type path1 -path_factor 3 The following example uses wildcard to match all ports matching "CL*". pt_shell create_qtm_delay_arc -from CL* -to OUT -path_type path1 -path_factor 3 The following example uses a collection for the QTM port ’CLK’: pt_shell create_qtm_delay_arc -from [get_qtm_ports CLK] -to OUT -path_type path1 -path_factor 3 SEE ALSO create_qtm_constraint_arc(2), create_qtm_model(2), create_qtm_path_type(2), get_qtm_ports(2), report_qtm_model(2), save_qtm_model(2). create_qtm_delay_arc 121 create_qtm_drive_type Creates a drive type in a Quick Timing Model (QTM) description. SYNTAX string create_qtm_drive_type -lib_cell lib_cell_name [-input_pin pin_name] [-output_pin pin_name] [-input_transition_rise rtrans] [-input_transition_fall ftrans] drive_type_name stringlib_cell_name stringinput_pin_name stringoutput_pin_name float rtrans float ftrans stringdrive_type_name ARGUMENTS -lib_cell lib_cell_name Specifies the library cell name in the technology library. -input_pin pin_name Specifies the input pin in the lib_cell is the start point of the arc and ends in the output pin. -output_pin pin_name Specifies the output pin in the lib_cell that specifies the drive. -input_transition_rise rtran Specifies the input rising transition time associated with the -input_pin to compute the delay for the drive arc. If you do not include this option, the delay table for rising input of the drive arc will be loaded from library as is. Use the -input_transition_rise and -input_transition_fall options to capture the transition time associated with the input_pin. This can obtain more accurate information on the transition time and delay time for the defined drive arc. -input_transition_fall ftran Specifies the input falling transition time associated with the input_pin to compute the delay for the drive arc. If you do not include this option, the delay table for falling input of the drive arc will be loaded from library as is. drive_type_name Specifies the name given to the defined drive type. create_qtm_drive_type 122 DESCRIPTION This command can be used to create a drive type. The defined drive type can be used to set the drives on output ports. The drive type is specified by referring to a lib_cell in the technology library. The lib_cell is specified by using the -lib_cell option. This lib_cell must be present in the technology library. The output pin which drives the port is specified by using the -output_pin option. In addition, you can specify the input pin by using the -input_pin option. This option selects an arc that drives the output pin of the lib_cell. If neither the input pin nor the output pin is specified, an arbitrary arc is chosen to define the drive type. If the input pin is specified and output pin is not specified, an arbitrary arc starting from the input pin defines the drive type. If the output pin is specified and input pin is not specified, the arbitrary delay arc coming into the output pin defines the drive type. If both input and output pins are specified, the lib_cell must have an combinational arc from the input pin to the output pin. To use this command you must read in the technology library and then specify it by using the set_qtm_technology command. To show the information about the current QTM model, use report_qtm_model command. For a basic description QTM, see the create_qtm_model man page. For a more detailed description, see Chapter 12 of the PrimeTime User Guide. EXAMPLES In the following examples it is assumed that you have loaded the technology library, and the QTM technology is set. Do this by using the following the sequence of commands as a guide, substituting the name of your technology library. pt_shellread_db my_technology_library.db pt_shellset_qtm_technology -library my_technology_library The following command creates a drive type equivalent to the lib_cell BUF1. pt_shell create_qtm_drive_type -lib_cell BUF1 drive1 The following command creates a drive type drive2 equivalent to lib_cell BUF2 and specifies the output pin to use. pt_shell create_qtm_drive_type -lib_cell BUF2 -output_pin Y drive2 SEE ALSO create_qtm_load_type (2), create_qtm_model (2), create_qtm_path_type (2), report_qtm_model (2), save_qtm_model (2), set_qtm_port_drive (2), set_qtm_technology (2). create_qtm_drive_type 123 create_qtm_generated_clock Creates a QTM generated_clock. SYNTAX string create_qtm_generated_clock -source master_clock_name [-divide_by divide_factor | -multiply_by multiply_factor] [-invert] generated_clock_name stringmaster_clock_name stringgenerated_clock_name int divide_factor int multiply_factor ARGUMENTS generated_clock_name Specifies the name of the generated clock. If the name has been used in defining a port or internal pin, then the generated_clock will be defined on the existing port or internal pin. Otherwise, a new same-named internal pin will be created to be the source of the generated clock. -source master_clock_name Specifies the name of the clock defined as master source of the generated clock. The master source must be defined as a clock, or a generated clock, priort to the generated_clock definition. -divide_by divide_factor Specifies the frequency division factor. If the divide_factor value is 2, the generated clock period is twice as long as the master clock period. -multiply_by multiply_factor Specifies the frequency multiplication factor. If the multiply_factor value is 3, the generated clock period is one-third as long as the master clock period. -invert Inverts the generated clock signal (in the case of frequency multiplication and division). DESCRIPTION This command creates QTM generated clock. A generated clock can be defined on the external port of the QTM, as well as internal pin in the QTM. After definition of the generated clock, the source port/pin can be used in other QTM commands the same way as those port/pins defined by create_qtm_port, i.e. delay arcs from or to the generated clock source pin can be defined with create_qtm_delay_arc; constraint arcs related to the generated clock can be defined with create_qtm_constraint_arc. create_qtm_generated_clock 124 For a basic description about QTM, please refer to create_qtm_model man page. For a more detailed description about QTM, please refer to the PrimeTime User Guide. EXAMPLES The following example creates a divide-by 2 generated clock on an internal pin, assume there is no port defined with name "GCLK_int", with master clock CLK. pt_shell create_qtm_generated_clock GCLK_int -source CLK -multiply_by 2 The following example creates a generated clock on port GCLK, assume GCLK has already been defined as a port with command create_qtm_port. pt_shell create_qtm_generated_clock GCLK -source CLK -divide_by 2 -invert SEE ALSO create_qtm_model(2), report_qtm_model(2), save_qtm_model(2), get_qtm_ports(2), set_qtm_delay_arc(2), set_qtm_constraint_arc(2). create_qtm_generated_clock 125 create_qtm_load_type Creates a load type for a Quick Timing Model (QTM) description. SYNTAX string create_qtm_load_type -lib_cell name [-input_pin pin_name] load_type name stringlib_cell_name stringinput_pin_name stringload_type name ARGUMENTS -lib_cell name Specifies the name of the library cell in the technology library. -input_pin pin_name Specifies the input pin in the lib_cell to specify capacitance. load_type name Specifies the name given to the defined load type. DESCRIPTION This command is used to create a load type. A load type can be used to define the load on a QTM input port. The load type is specified by referring to a lib_cell in the technology library. The lib_cell is specified using the -lib_cell option. lib_cell must be present in the specified technology library. The input pin can be specified by using the -input_pin option. If the input pin is not specified, an arbitrary input pin is chosen to define the load type. To use this command you must first read in the technology library, then specify the technology library by using the set_qtm_technology command. To show the information about the current QTM model, use report_qtm_model command. For a basic description about QTM, please refer to create_qtm_model man page. For a more detailed description about QTM, please refer to Chapter 12 of the PrimeTime User Guide. EXAMPLES In the following examples the technology library is loaded by you and the QTM technology is set. This is done by the following sequence of commands: pt_shellread_db my_technology_library.db pt_shellset_qtm_technology -library my_technology_library The following command creates a load type ’load1’ using cell OR1. Since the input pin name is not specified, QTM selects an arbitrary input pin. create_qtm_load_type 126 pt_shell create_qtm_load_type -lib_cell OR1 load1 The following command creates a load type ’load2’ using cell OR1, input pin A. pt_shell create_qtm_load_type -lib_cell OR1 -input_pin A load2 SEE ALSO create_qtm_drive_type(2), create_qtm_model(2), create_qtm_path_type(2), report_qtm_model(2), save_qtm_model(2), set_qtm_port_load(2). create_qtm_load_type 127 create_qtm_model Begins the definition of a Quick Timing Model (QTM) description. SYNTAX string create_qtm_model model_name stringmodel_name ARGUMENTS model_name Specifies the name of the generated model. DESCRIPTION Specifies the name of a new quick timing model (QTM) to be created by PrimeTime. QTMs are temporary timing models that can be created quickly for a block using PrimeTime commands. The purpose of these commands is to provide timing information without the necessity of writing a detailed timing model. QTMs are intended to be used early in the design cycle to describe rough initial timing of a block. These models will eventually be replaced, either by some other detailed timing model or by the netlist of the block, to obtain more accurate timing. For a more detailed description of QTMs, see the PrimeTime User Guide. A QTM can be saved as a Synopsys DB file, which can be instantiated in a design in the same way library cells or ITS models are instantiated. Both Design Compiler and PrimeTime accept designs with instantiated QTMs. To save a QTM model, use the save_qtm_model command. Other commands in the QTM command set must be placed between a create_qtm_model and save_qtm_model command. Many QTM commands exist for specifying, configuring and examining QTMs. The following is not an exhaustive list, but gives examples of tasks you can perform using QTM commands: • To create a QTM port, use the create_qtm_port command. • To create constraint arcs and delay arcs, use the create_qtm_constraint_arc and the create_qtm_delay_arc commands, respectively. • To set the drive of a QTM output port, use the set_qtm_port_drive command. • To set the load of a QTM input port, use set_qtm_port_load command. • To show the information about the current QTM model, use the report_qtm_model command. create_qtm_model 128 EXAMPLES The following command creates a new QTM model with the name adder. pt_shell create_qtm_model adder SEE ALSO create_qtm_constraint_arc(2), create_qtm_delay_arc(2), create_qtm_drive_type(2), create_qtm_load_type(2), create_qtm_path_type(2), create_qtm_port(2), get_qtm_ports(2), report_qtm_model(2), save_qtm_model(2), set_qtm_global_parameter(2), set_qtm_port_drive(2), set_qtm_port_load(2), set_qtm_technology(2). create_qtm_model 129 create_qtm_path_type Creates a path type in a Quick Timing Model (QTM) description. SYNTAX string create_qtm_path_type -lib_cell name [-input_pin pin_name] [-output_pin pin_name] [-fanout count] path_type name string name string pin_name string pin_name integer-rangecount string path_type name ARGUMENTS -lib_cell name Specifies the name of the library cell in the technology library. -input_pin pin_name Specifies the input pin in the lib_cell, which is the start point of the arc, to define the path type. -output_pin pin_name Specifies the output pin in the lib_cell, which is the end point of the arc, to define the path type. -fanout count Specifies the average fanout (number of pins) to consider while computing the delay of the path type. The fanout count can range from 1 to 1000. By default this is 1. path_type name Specifies the name given to the defined path type. DESCRIPTION This command is used to create a path type. A path type mimics an arc in a library cell. An arc in the QTM model is defined in terms of the delays of the path type. The path type is specified by referring to a lib_cell in the technology library. The lib_cell is specified using the -lib_cell option. This lib_cell must be present in the technology library specified. You can specify the average fanout count the arc fans out to while defining the path type. It is assumed the arc fans out to the first input pin of the same library cell, while calculating the delays. The input pin is specified by using the input_pin option. The output pin is specified by using the -output_pin option. If neither input pin nor the output pin is specified, an arbitrary delay arc in the lib_cell is chosen to define the path type. If the input pin is specified and output pin is not specified, an arbitrary delay create_qtm_path_type 130 arc staring from the input pin defines the path type. If the output pin is specified and input pin is not specified, an arbitrary delay arc coming into the output pin defines the path type. If both input and output pins are specified, the lib_cell must have an arc from the input pin to the output pin. To use this command you must read in the technology library then specify the technology library by using the set_qtm_technology command. To show the information about the current QTM model, use report_qtm_model command. For a basic description about QTM, please refer to create_qtm_model man page. For a more detailed description about QTM, please refer to Chapter 12 of the PrimeTime User Guide. EXAMPLES In the following examples the technology library is loaded by the user and the qtm technology is set. This is done by the following sequence of commands: pt_shellread_db my_technology_library.db pt_shellset_qtm_technology -library my_technology_library The following command creates a path type path1 by using lib_cell AN2, with an average fanout count of 2 (uses default input, output pins). pt_shell create_qtm_path_type -lib_cell AN2 -fanout 2 path1 The following command creates a path type path2 by using cell AN2, with an average fanout count of 2, and using pin ’A’ as the starting point for the path type. pt_shell create_qtm_path_type -lib_cell AN2 -input_pin A -fanout 2 path2 The following command creates a path type path3 by using cell AN2, with an average fanout count of 2, using ’A’ as the start point of the arc, and pin ’Z’ as the end point of the arc. pt_shell create_qtm_path_type -lib_cell AN2 -input_pin A -output_pin Z fanout 2 path3 SEE ALSO create_qtm_constraint_arc(2), create_qtm_delay_arc(2), create_qtm_drive_type(2), create_qtm_load_type(2), create_qtm_model(2), report_qtm_model(2), save_qtm_model(2). create_qtm_path_type 131 create_qtm_port Creates a QTM port. SYNTAX string create_qtm_port -type port_type port_list stringport_type list port_list ARGUMENTS -type port_type Specifies the type of port. The port can be one of the following types: input, output, inout, internal or clock. If you want a port to be a clock, define it as a clock port. port_list Specifies the list of QTM ports you want created. DESCRIPTION This command creates QTM port. You can create a single port or a list of ports with this command. The ports can be input, output, inout, internal or clock. Any port that constrains another port or has a edge triggered launch arc originating from it, has to be defined to be of the type ’clock’. Bused ports are also defined by giving the start and end index (A[0:5]). Bused ports cannot be internal. To show the information about the current QTM model, use report_qtm_model command. For a basic description about QTM, please refer to create_qtm_model man page. For a more detailed description about QTM, please refer to the PrimeTime User Guide. EXAMPLES The following example creates an input bused QTM port A[0:5]. pt_shell create_qtm_port A[0:5] -type input The following example creates a clocked QTM port CLK. pt_shell create_qtm_port CLK -type clock The following example creates QTM output ports A, B, C, and D. pt_shell create_qtm_port {A B C D} -type output The following example creates QTM internal pin D_int. pt_shell create_qtm_port D_int -type internal create_qtm_port 132 SEE ALSO create_qtm_model(2), report_qtm_model(2), save_qtm_model(2), get_qtm_ports(2), set_qtm_port_drive(2), set_qtm_port_load(2). create_qtm_port 133 create_scenario Creates a scenario for multi-scenario analysis. SYNTAX Boolean create_scenario ARGUMENTS -name name [-common_data file_list] [-specific_data file_list] [-common_variables variable_list] [-specific_variables variable_list] [-image image] stringname list ffile_list list fvariable_list string image -name A unique string used to identify and to refer to a single scenario. [-common_data file_list] A list of files that contains commands and data that is common to more than one scenario. These files will be used to create a common image for all scenarios which share the same common data. [-common_variables variable_list] A list of variables that are common to more than one scenario. These variables will be used in conjuction with the common_data files to determine commonality between scenarios. The value of the variable currently at the master will be set on the slave prior to the sourcing of the common data files. [-specific_data file_list] A list of files that contains commands and data that is specific to this scenario. This data will not be used on any other scenario or in the common image generation. This data that is specific to the scenario is sent direclty to the slave and executed once the common design image has been generated. [-specific_variables variable_list] A list of variables that are specific to this scenario. The value of the variable currently at the master will be set on the slave prior to the sourcing of the specific data files. [-image image] This option allows a scenario to be created with a previously saved scenario image. The image can be an image generated within a standard primetime session, an image generated with a save_session call from the DMSA master or a current_image generated during a DMSA session. create_scenario 134 DESCRIPTION The create_scenario command creates a scenario based on the data supplied by the above arguements. A scenario can be created with a set of scripts and variables. When a set of scenarios share the same common_data and common_variables, a common design image will be created which will be shared across the set of scenarios. Alternatively a scenario can be created with a previously saved image. This command does not actually start the analysis. The analysis will be started when the first merged reporting or remote_execute command is issued. EXAMPLES In the following example, a scenario is created named scen1. scen1 is described by the files common_s1, and specific_s1. pt_shell create_scenario -name scen1 -common_data {common_s1.pt} -specific_data {specific_s1.pt} 1 In the following example, an iterative loop creates a set of scenarios. The same script single.tcl is used for all scenarios but the corner variable distinguishes the scenarios foreach corner {bc tc wc} { create_scenario -name ${corner} -common_variables {corner} -common_data "single.tcl" } SEE ALSO remove_scenario(2), get_current_scenario (2), report_multi_scenario_design (2), create_scenario 135 create_si_context Generates an SI context for selected blocks of the design. A top level design and full chip binary parasitics can also be generated. SYNTAX Boolean create_si_context [-include include_list] [-instances instance_list] [-parasitics_options para_options] [-top_inst instance_name] [-no_design_parasitics] list list list includee_list instance_list para_options ARGUMENTS -include include_list If this option is not specified, the context script will be generated for cross-talk. You can use this option to specify Primetime SI to generate the context scripts for cross-talk, noise or both. Allowed values are xtalk and noise. The generated context will be the same, only the script will be different. -instances instance_list Indicates that PrimeTime SI is to extract contexts for the given list of instances or for all the top level instances of the design. -parasitics_options para_options Specifies that a parasitic file has to be generated to be used to annotate the (block + context) design. The allowed values for para_options are spef_format and sbpf_format. -top_inst instance_name Specifies that Primetime should generate a top level design for the given instance. By default, Primetime generates top level design for the given design. This option can be used in conjunction with -instances to generate contexts and top level design for an arbitrary hierarchy. Note that all the instances provided in -instances option must be the child instances of the top level instance provided in this option. -no_design_parasitics By default, this command also generates full chip parasitics in SBPF format. Use this option to indicate Primetime not to generate the SBPF file. This option should be used if your parasitic extraction tool generated SBPF. DESCRIPTION The create_si_context command generates contexts for all top level instances of the create_si_context 136 design or for the list of instances given in the -instances option. This context can be used to perform signal integrity analysis at the block level. The effect of context on the block is the same as that of the top level and other blocks on the block. Hence, context enables accurate signal integrity analysis for block level analysis as if the block is being analyzed in the context of the full chip. The command also generates a top level design and a top level script that can be used to perform chip level analysis after block level analysis is complete and respective ILMs are generated for each block. User can direct Primetime to generate contexts and top level design for an arbitrary level of hierarchy instance using the -top_inst and -instances options. The command creates one directory for each block (for which a context is being extracted) and outputs the context files inside the directory. Each directory contains a verilog context design (named wrapper.v), a TCL script (named wrapper.tcl) that can be used in performing block level analysis, a text file that contains aggressor annotation points (named wrapper.txt) that can be used later for annotating arrivals/slews for accurate block level analysis. The command also generates an infinite arrival script (named wrapper.pt.gz) that can be used to perform conservative block analysis in the context. The command can generate this arrival script for cross-talk, noise or both depending on the -include option. In addition, if the -parasitics_options option is given, a parasitic file (named wrapper.sbpf or wrapper.spef.gz) gets generated. Also at the level of this new directory, a top level verilog file (named design.v), a top level TCL script (named design.tcl) are also generated. In addition, if the -no_design_parasitics is not given, a full chip binary parasitic file (named design.sbpf) gets generated. The create_si_context command is affected by pt_ilm_dir environment variable. The top design files and directories for individual blocks are created at the location given by variable pt_ilm_dir. EXAMPLES The following example generates contexts for all top level designs along with context parasitics in SBPF and a top level design. pt_shell create_si_context -parasitics_options {sbpf_format} The following example generates contexts for instances "blockA" and "blockB" along with context parasitics in SPEF. pt_shell create_si_context -instances {blockA blockB} \ -parasitics_options {spef_format} create_si_context 137 SEE ALSO pt_ilm_dir(3), write_arrival_annotations(2), create_ilm(2). create_si_context 138 current_design Sets or gets the current design in PrimeTime. SYNTAX string current_design [design_name] string design_name ARGUMENTS design_name Specifies the working or focal design for many PrimeTime commands. If design_name is not specified, current_design returns a collection containing the current design. If design_name refers to a design that cannot be found, an error is issued and the working design remains unchanged. DESCRIPTION Sets or gets the working design for many PrimeTime commands. Without arguments, current_design returns a collection containing the current working design. The combination of the current design and current instance defines the context for many PrimeTime commands. To display designs currently available in PrimeTime, use list_designs. EXAMPLES The following example uses current_design to show the current context and to change the context from one design to another. pt_shell current_design {"TOP"} pt_shell list_designs Design Registry: ADDER /designs/dbs/my_design.db:ADDER FULL_ADDER /designs/dbs/my_design.db:FULL_ADDER FULL_SUBTRACTOR /designs/dbs/my_design.db:FULL_SUBTRACTOR HALF_ADDER /designs/dbs/my_design.db:HALF_ADDER HALF_SUBTRACTOR /designs/dbs/my_design.db:HALF_SUBTRACTOR SUBTRACTOR /designs/dbs/my_design.db:SUBTRACTOR * TOP /designs/dbs/my_design.db:TOP pt_shell current_design ADDER {"ADDER"} pt_shell current_design current_design 139 {"ADDER"} The current_design command can be used as a parameter to other pt_shell commands. In the following example, remove_design is used to delete the working design from pt_shell. pt_shell current_design {"TOP"} pt_shell remove_design [current_design] Removing design ’TOP’... 1 pt_shell current_design Error: Current design is not defined. (DES-001) pt_shell SEE ALSO current_instance (2), list_designs (2). current_design 140 current_instance Sets the working instance object in pt_shell and enables other commands to be used relative to a specific instance in the design hierarchy. SYNTAX string current_instance [instance] string instance ARGUMENTS instance Specifies the working instance (cell) in pt_shell. If instance is not specified, the focus returns to the top level of the hierarchy in the current design. If instance is ".", the current instance remains unchanged. If instance is "..", the context is moved up one level in the instance hierarchy. If instance begins with "/", pt_shell sets both the current design and the current instance. More complex examples of instance arguments are described in EXAMPLES. DESCRIPTION The current_instance command sets the working instance in pt_shell. An instance is a cell in the hierarchy of a design. This command differs from current_design, which changes the working design, then sets the current instance to the top level of the new current design. The combination of the current design and current instance defines the context for many pt_shell commands. current_instance traverses the design hierarchy similar to the way the UNIX "cd" command traverses the file hierarchy. current_instance operates with a variety of instance arguments: • If no instance argument is specified, the focus of pt_shell is returned to the top level of the hierarchy. • If instance is ".", the current instance is returned and no change is made. • If instance is "..", the current instance is moved up one level in the design hierarchy. • If instance is a valid cell (or cell name) at the current level of hierarchy, the current instance is moved down to that level of the design hierarchy. • Multiple levels of hierarchy can be traversed in a single call to current_instance by separating multiple cell names with slashes. For example, current_instance U1/U2 current_instance 141 sets the current instance down two levels of hierarchy. • The ".." directive can also be nested in complex instance arguments. For example the command current_instance "../../MY_INST" attempts to move the context up two levels of hierarchy, then down one level to the "MY_INST" cell. EXAMPLES The following example uses current_instance to move up and down the design hierarchy. The all_instances command is also used to list instances of a specific design relative to the current instance. pt_shell current_design TOP {"TOP"} pt_shell current_instance U1 U1 pt_shell current_instance "." U1 pt_shell query_objects [all_instances ADDER] {"U1", "U2", "U3", "U4"} pt_shell current_instance U3 U1/U3 pt_shell current_instance "../U4" U1/U4 pt_shell current_instance Current instance is the top-level of design ’TOP’. In the following example, changing the current_design resets the current_instance to the top level of the new design hierarchy. pt_shell current_design {"TOP"} pt_shell current_instance "U2/U1" U2/U1 pt_shell current_design ADDER {"ADDER"} pt_shell current_instance . Current instance is the top-level of design ’ADDER’. current_instance 142 The following example uses current_instance to go to an instance of another design. The current_design is set by the new design whose name is the name after the first slash of the given instance name. pt_shell current_design {"TOP"} pt_shell current_instance U1 U1 pt_shell current_instance "/TOP/U2" U2 pt_shell current_instance "/ALARM_BLOCK/U6" U6 pt_shell current_design {"ALARM_BLOCK"} SEE ALSO all_instances (2), current_design (2), list_designs (2), query_objects (2). current_instance 143 current_power_rail Sets or gets the power rails in a multi-rail design to be included in power analysis. As default (if not specified), all the power rails in the design are included in power analysis. This command has no effect on single rail design. SYNTAX int current_power_rail [rail_name_list] object_list rail_name_list string rail_name ARGUMENTS rail_name_list Specifies the names of the power rails in the design to be included in power analysis. If rail_name_list is not specified, current_power_rail returns a collection of power rails being included in power analysis. If rail_name refers to a power rail that is defined in the design, an error is issued and the current rail settings remains unchanged. DESCRIPTION Sets or gets the power rails in a multi-rail design to be included in power analysis. Without arguments, current_power_rail returns a collection of power rails being included in power analysis. The current_power_rail command provides the control of calculating power consumption for the rails of interest. Power consumption data can be generated for different combinations of power rails in a multi-rail design. Only the power dissipated on the power rails in the current rail list will be calculated and reported. For cell internal and leakage power, the rail-based power numbers are calculated based on the rail specific power tables in the technology library. For cell switching power, the rail-based power numbers are calculated based on the output pin voltage rail. This command has no effect on single rail design. Before using this command, user has to define the design power rails by using command create_power_rail_mapping. Command report_power_rail_mapping can be used to show the defined design power rails, library power rails and rail mapping information. The following power analysis results will be affected by this command in a multirail design: - average power report generated by report_power - time-based power report generated by create_power_waveform - power related attributes: total_power dynamic_power internal_power switching_power leakage_power current_power_rail 144 x_transition_power glitch_power peak_power Use current_power_rail all to resume the default behavior, which includes all the power rails in the design. EXAMPLES The following example shows generating rail-based power analysis results. The first report_power will generate the power analysis results for the part of design with supply voltage of VDD1 and VDD2. The second report_power will generate the results for the part of design which is supplied by VDD1. pt_shell create_power_rail_mapping VDD1 -cells block1 pt_shell create_power_rail_mapping VDD2 -cells block2 pt_shell current_power_rail {VDD1 VDD2} pt_shell report_power pt_shell current_power_rail VDD1 pt_shelpt_shell report_power SEE ALSO create_power_rail_mapping (2), report_power_rail_mapping (2), update_power (2), report_power (2), report_power_calculation (2). current_power_rail 145 current_scenario Selects a subset of the scenarios in the current session for analysis. SYNTAX int current_scenario [-all] [scenario_list] list scenario_list ARGUMENTS [scenario list] A list of scenarios in the current session to analyze. [-all] Selects all scenarios in the current session for analysis. DESCRIPTION This command is only available if the user invokes pt_shell with the -multi_scenario option. In multi-scenario analysis, after the scenarios have been created, the current_session command is used to focus on a set of scenarios for analysis. The current_scenario command is used to focus the analysis on a specific subset of the scenarios in the current session, only those scenarios selected will receive subsequent commands. To determine which scenarios are in the current session and their focus use the report_multi_scenario_design command with the -session option. EXAMPLES In the following example, three scenarios named scen1, scen2 and scen3 are created. scen1 is created using common_s1.pt and specific_s1.pt scen2 is created using common_s2.pt and specific_s2.pt scen3 is created using common_s3.pt and specific_s3.pt The scenarios scen1, scen2 and scen3 are selected for the current session which is then displayed. Notice that all three scenarios are in command focus. The analysis is focused on only scen2 and scen3 using the current_scenario command and the session is displayed again. Notice that scen1 is now only in session focus but scen2 and scen3 are in command focus. i.e. only scen2 and scen3 will be considered for analysis. current_scenario 146 1 pt_shell create_scenario -name scen1 -common_data {common_s1.pt} -specific_data {specific_s1.pt} 1 pt_shell create_scenario -name scen2 -common_data {common_s2.pt} -specific_data {specific_s2.pt} 1 pt_shell create_scenario -name scen3 -common_data {common_s3.pt} -specific_data {specific_s3.pt} 1 pt_shell current_session {scen1 scen2 scen3} 1 pt_shell freport_multi_scenario_design -session **************************************** Report : multi_scenario_design Version: V-2004.06 Date : Tue Apr 13 05:50:10 2004 **************************************** Session details ----------------------------------------------------- Number of scenarios in current session: 3 Focus Scenario (Image provider) Command Command Command scen1 scen2 scen3 (scen1) (scen2) (scen3) 1 pt_shell current_scenario {scen2 scen3} 1 pt_shell report_multi_scenario_design -session **************************************** Report : multi_scenario_design Version: V-2004.06-Beta2 Date : Tue Apr 13 05:51:53 2004 **************************************** Session details ----------------------------------------------------- Number of scenarios in current session: 3 Focus Scenario (Image provider) Session Command Command scen1 scen2 scen3 (scen1) (scen2) (scen3) current_scenario 147 1 SEE ALSO current_session (2), remove_scenario(2), report_multi_scenario_design (2) current_scenario 148 current_session Selects a set of scenarios for analysis. SYNTAX string current_session [scenario list] [-all] ARGUMENTS [scenario_list] A list of scenarios to be brought into focus for analysis. [-all] All defined scenarios to be brought into focus for analysis. DESCRIPTION This command is only available if the user invokes pt_shell with the -multi_scenario option. In multi-sceanario analysis, after the license limit has been set, the distributed processes added, the scenarios created, the user must select a set of scenarios to analyse using the current_session command. Calling this command with a list of scenarios brings those scenarios into focus for the current session (session focus) and into focus for receiving commands (command focus) from the master. The current session can be set with all or a subset of the created scenarios. The current_session command returns a list of all scenarios in the current_session. EXAMPLES In the following example, a configuration and three scenarios named scen1, scen2 and scen3 are created. The current_session is then set such that scen2 and scen3 are in session and command focus. scen1 is created using common_s1.pt and specific_s1.pt scen2 is created using common_s2.pt and specific_s2.pt scen3 is created using common_s3.pt and specific_s3.pt The scenarios scen2 and scen3 are brought into focus. pt_shell create_scenario -name scen1 -specific_data {specific_s1.pt} 1 pt_shell create_scenario -name scen2 -specific_data {specific_s2.pt} 1 pt_shell create_scenario -name scen3 -specific_data {specific_s3.pt} -common_data {common_s1.pt} -common_data {common_s2.pt} -common_data {common_s3.pt} current_session 149 1 pt_shell current_session {scen2 scen3} scen2 scen3 SEE ALSO current_scenario (2), remove_scenario(2), report_multi_scenario_design (2) current_session 150 define_design_mode_group Defines a design mode group with a set of design modes. SYNTAX string define_design_mode_group [-group_name name] mode_list stringname list mode_list ARGUMENTS -group_name name Specifies the name of the design mode group. By default, if no design mode group is specified, a default design mode group is created and named "default". mode_list Specifies a list of design modes to be created and included in the design mode group. DESCRIPTION The define_design_mode_group command defines a set of design modes to be placed in a design mode group for your design. You select one of the design modes to be the active mode using the set_mode -type design command. There are only two valid states for a design mode group. The default state of all modes enabled or the state of one mode enabled and all others disabled. Setting one of the modes to be active automatically sets the rest of the modes in the group inactive (disabled). You can map cell modes or paths to a design mode using the map_design_mode command. When you select the active design mode with the set_mode -type design command, the modes of the cells specified for that design mode are also active. Any paths mapped to disabled design modes automatically become false paths. Unlike design modes, which are user-specified, cell modes are predefined, and are in the library. You can find out what cell modes are available using the report_mode command. For more information about cell modes, see the manual page for the set_mode command. To see a report of the design modes specified for the current design, use the report_mode -type design command. To remove design modes, use the remove_design_mode command. Removing a design mode also removes any cell mode or path specifications previously mapped to the design mode using map_design_mode. EXAMPLES The following example defines two design modes for the current design: SYSTEM and TEST. define_design_mode_group 151 pt_shell define_design_mode_group {SYSTEM TEST} The following example defines two independent design mode groups. The first command defines a design mode group named RW that contains design modes READ and WRITE. The second command defines a design mode group named LT that contains design modes LATCH and TRANSPARENT. pt_shell define_design_mode_group -group RW {READ WRITE} pt_shell define_design_mode_group -group LT {LATCH TRANSPARENT} The following command enables the design mode READ and disables the design mode WRITE, because READ and WRITE belong to the same design mode group RW. pt_shell set_mode -type design READ SEE ALSO remove_design_mode (2), map_design_mode (2), report_mode (2), reset_mode (2), set_mode (2). define_design_mode_group 152 define_qtm_attribute Defines a new user-defined attribute for a class of QTM objects. SYNTAX string define_qtm_attribute -type data_type -class obj_class attr_name string data_type string obj_class string attr_name ARGUMENTS -type data_type Specifies the data type of the attribute. The supported data types are string, int, float and boolean. -class obj_class Specifies the class of QTM objects the new attribute is defined for. The valid object classes are lib, lib_cell or lib_pin. Attribute for ’lib’ class applies to the library. Attribute for ’lib_cell’ class applies to the QTM cell. Attribute for ’lib_pin’ class applies to the QTM ports/pins. attr_name Specifies the name of the attribute. DESCRIPTION Use define_qtm_attribute command to define a new user-defined attribute that is applicable to QTM objects. A user-defined attribute is any attribute which PrimeTime does not understand by default. Those attributes already understood or reserved by PrimeTime for various classes of objects are considered application attributes and should not be re-defined. If you need to set the application attributes that are applicable to the classes of QTM objects, just use set_qtm_attribute directly. There is no need to define the attribute before setting them. But for user attributes that are not reserved by the application, you have to define them before set them on objects. Note that the list_attributes command will not show any attributes defined for QTM. After save the QTM in proper library, those user-defined QTM attributes can be imported from db files. But you must define those user attributes you want to import with the define_user_attribute command and the -import option before the library with the QTM cell is read. For more details, please see define_user_attribute. define_qtm_attribute 153 EXAMPLES The following example defines QTM attributes of various types. pt_shell define_qtm_attribute my_str_attr \ ? -class lib_pin -type string pt_shell define_qtm_attribute my_int_attr \ ? -class lib_cell -type int pt_shell define_qtm_attribute my_float_attr \ ? -class lib -type float SEE ALSO set_qtm_attribute (2), remove_qtm_attribute (2), define_user_attribute (2). define_qtm_attribute 154 define_scaling_lib_group Defines a group of libraries to support voltage and/or temperature scaling. SYNTAX string define_scaling_lib_group library_list list library_list ARGUMENTS library_list A list of libraries to support voltage and/or temperature scaling. DESCRIPTION The define_scaling_lib_group command defines a group of libraries that PrimeTime will interpolate between for voltage and/or temperature scaling. The command must be issued before the design is linked. Only one of the libraries in the library_list should be in the link_path; the remaining libraries will be read automatically after the design is linked to complete the group. You can have more than one group to cover different portions of a design, but the groups cannot share libraries. Once a group is in effect, any attempt to use set_rail_voltage and/or set_operating_condition outside the range of the applicable group will result in a DEL-012 error. You can see if a group was used for delay calculation by using the report_delay_calculation command. The report shows the results using the link library, then the scaling library group results if applicable and valid. A minimum of two libraries is required for one-dimensional scaling (i.e. voltage or temperature), and a minimum of four libraries is required for two-dimensional scaling (i.e. voltage and temperature). Presently scaling with library groups is only supported for nonlinear delay model (NLDM) constraints and RC delay calculations with Composite Current-Source (CCS) data. The interpolation methods may be controlled via the following shell variables: lib_group_interpolation_for_voltage lib_group_interpolation_for_voltage_setup_and_hold lib_group_interpolation_for_temperature The above variables may be set to largest, smallest, or linear to dictate how the interpolated value is obtained from the bracketing libraries. define_scaling_lib_group 155 lib_group_interpolation_for_voltage_setup_and_hold may be additionally set to nonlinear for increased accuracy. EXAMPLES The following example defines a scaling library group for two voltage domains about the nominal: pt_shell set link_path "* 1.1.db" pt_shell define_scaling_lib_group { 0.9.db 1.1.db 1.3.db } pt_shell link_design SEE ALSO link_design (2), set_rail_voltage (2), set_operating_conditions (2), report_delay_calculation (2), lib_group_interpolation_for_voltage (3), lib_group_interpolation_for_voltage_setup_and_hold (3), lib_group_interpolation_for_temperature (3). define_scaling_lib_group 156 define_user_attribute Defines a new user-defined attribute. SYNTAX string define_user_attribute -type data_type -classes class_list [-range_min min] [-range_max max] [-one_of values] [-import] [-quiet] attr_name string data_type list class_list double min double max list values string attr_name ARGUMENTS -type data_type Specifies the data type of the attribute. The supported data types are string, int, float, double, and boolean. -classes class_list Defines the attribute for one or more of the classes. The valid object classes are design, port, cell, pin, net, lib, lib_cell or lib_pin. -range_min min Specifies min value for numeric ranges. This is only valid when the data_type is int or double. Specifying a minimum constraint without a maximum constraint creates an attribute which accepts a value = min. -range_max max Specifies max value for numeric ranges. This is only valid when the data_type is int or double. Specifying a maximum constraint without a minimum constraint creates an attribute which accepts a value = max. -one_of values Provides a list of allowable strings. This is only valid when the data type is string. -import Import this attribute from a design or library database. -quiet Does not report any messages. attr_name Specifies the name of the attribute. define_user_attribute 157 DESCRIPTION Use the define_user_attribute command to define a new user-defined attribute. A user-defined attribute is any attribute which PrimeTime does not understand by default. The list_attributes command will show all attributes which PrimeTime understands. You can apply attributes to most object classes in PrimeTime. You can use these to mark interesting cells or nets, or store values you computed, and so on. PrimeTime cannot use these attributes, but you can use them in scripts, procedures, and so on. You can list the attributes you defined using the list_attributes command. User-defined attributes can be imported from a design or library database once they have been defined. A design or library database is a db or ddc format file, or a Milkyway database. You must define attributes you want to import with the -import option. Note that imported attributes do not appear on the design objects until the design is linked. Attributes imported from a design or library database will be inherited through the hierarchy. Note that attributes defined for designs will be inherited onto cells, and attributes defined for ports will be inherited onto pins. The define_user_attribute command will set up these relationships for you automatically if you do not do it explicitly. EXAMPLES The following example defines attributes of various types. Note that more than one class can be specified. Also note that attr_i is defined as imported from a design or library database. Finally, attribute design1 is imported from a design or library database, and PrimeTime defines it for cells as well. pt_shell define_user_attribute attr_s \ ? -class {cell net} -type string pt_shell define_user_attribute attr_i \ ? -class cell -type int -import pt_shell define_user_attribute design1 \ ? -class design -type int -import Information: Inferred definition of attribute ’design1’ for class ’cell’ because it is imported for class ’design’ (ATTR-7) In the following example, attr_ir1 is defined as = 0 and = 100, attr_ir2 is defined as = 0 with no maximum, and attr_ir3 is defined as = 100 with no minimum. pt_shell define_user_attribute attr_ir1 \ ? -class cell -type int \ ? -range_min 0 -range_max 100 pt_shell define_user_attribute attr_ir2 \ ? -class cell -type int -range_min 0 pt_shell define_user_attribute attr_ir3 \ ? -class cell -type int -range_max 100 In the following example, define attribute attr_oo for cells. The attribute is a string, but can only be set to A, B, C, or D. define_user_attribute 158 pt_shell define_user_attribute attr_oo \ ? -class cell -type string -one {A B C D} Once these attributes have been defined, you can list the attribute definitions using the list_attribute command. Notice how the ’attr_i’ attribute is marked as importable from db, meaning a design or library database. pt_shell list_attributes **************************************** Report : List of Attribute Definitions Design : **************************************** Properties: A - Application-defined U - User-defined I - Importable from db (for user-defined) Attribute Name Object Type Properties Constraints ---------------------------------------------------------- attr_i cell int U,I attr_ir1 cell int U 0 to 100 attr_ir2 cell int U =0 attr_ir3 cell int U = 100 attr_oo cell string U A, B, C, D attr_s cell string U attr_s net string U design1 design int U,I design1 cell int U SEE ALSO get_attribute (2), list_attributes (2), read_db (2), read_ddc (2), read_milkyway (2), remove_user_attribute (2), report_attribute (2), set_user_attribute (2). define_user_attribute 159 derive_clocks Creates clocks on source pins in design. SYNTAX string derive_clocks -period period_value [-waveform edge_list] float period_value list edge_list ARGUMENTS -period period_value Specifies the clock period of the automatically derived clocks. The clock period has a value greater than or equal to zero (value = 0). -waveform edge_list Specifies the rise and fall edge times of the clock, in library time units, over an entire clock period. It defines the clock edge specification. The first time that is listed is a rising transition; typically the first rising transition after time zero. There must be an even number of increasing times and alternating rise and fall times. If you do not specify an edge_list value, the command assumes a default waveform that has a rise edge of 0.0 and a fall edge of period_value/2. DESCRIPTION Creates clocks on source pins in design. This command finds the clock source ports and pins that must have clocks defined so that every register clock pin has a clock. Then, on each source set, the command creates a clock in the same way as the create_clock command does. The clocks are created with the specified waveform or period. For a description of commands that use clock objects, see the create_clock command man page. EXAMPLES pt_shell derive_clocks -per 20 SEE ALSO create_clock (2), get_clocks (2), group_path (2), remove_clock (2), report_clock (2), set_clock_latency (2), set_clock_uncertainty (2), set_input_delay (2), set_output_delay (2). derive_clocks 160 disconnect_net Disconnects a net from specified pins or ports, or from all pins and ports. SYNTAX int disconnect_net net object_spec | -all stringnet list object_spec ARGUMENTS -all Indicates that all pins and ports are to be disconnected from net. -all and object_spec are mutually exclusive. net Specifies the name of the net to be disconnected. object_spec Specifies a list of pins or ports to be disconnected from net. -all and object_spec are mutually exclusive. DESCRIPTION The disconnect_net command disconnects pins and ports from a net in the current design. Like all other netlist editing commands, for disconnect_net to succeed, all of its arguments must succeed. If any arguments fail, the netlist remains unchanged. disconnect_net returns a 1 if successful and a 0 if unsuccessful. The net and each pin and port specified in the object_spec must be in scope; that is, at or below the current instance. There are three rules for disconnect_net: • You cannot disconnect an unconnected pin or a port. • You cannot disconnect a pin or a port that is not connected to net. • You cannot disconnect a hierachical pin or a port that has the same name as net. EXAMPLES In the following example, the first command attempts to connect port in1 to net new_net1, but in1 is already connected to a net. The second command determines the net to which in1 is connected; the third command disconnects the port from its net. The fourth and final command connects in1 to new_net1. pt_shell connect_net new_net1 [get_ports in1] Error: Could not connect ’in1’ to ’new_net1’ Object is already connected - disconnect it first (NED-042) disconnect_net 161 Error: No changes made. (NED-040) 0 pt_shell set pnet [get_nets -of_objects [get_ports in1]] {"in1"} pt_shell disconnect_net $pnet [get_ports in1] Information: Disconnected ’in1’ from ’net1’. (NED-019) 1 pt_shell connect_net new_net1 [get_ports in1] Information: Connected ’in1’ to ’new_net1’. (NED-018) 1 SEE ALSO connect_net (2), create_cell (2), create_net (2), size_cell (2), swap_cell (2), write_changes (2). disconnect_net 162 drive_of Determines the drive resistance of the specified library cell pin. The drive_of command is a DC Emulation command provided for compatibility with Design Compiler. SYNTAX float drive_of [-rise] [-fall] [-wire_drive] [-piece val] lib_cell_pin stringval stringlib_cell_pin ARGUMENTS -rise Get rise drive value. -fall Get fall drive value. -wire_drive Not supported by PrimeTime. -piece val Not supported by PrimeTime. lib_cell_pin Specifies the name of the library cell pin for which to get the drive resistance, or a collection that contains the library cell pin. DESCRIPTION The drive_of command returns the drive resistance of the given library cell pin. If neither -rise nor -fall is specified, the greater value of rise and fall is returned. The drive_of command exists in PrimeTime for compatibility with Design Compiler. Complete information about the drive_of command can be found in the Design Compiler documentation. The supported method for getting the capacitance of a library cell pin is by using the get_attribute command with either the drive_resistance_rise or drive_resistance_fall attribute. SEE ALSO get_attribute (2). drive_of 163 estimate_clock_network_power Virtually generate a clock tree and estimate its power. SYNTAX string estimate_clock_network_power lib_cell [-max_fanout fanout] [-wire_load_model wire_load_name] [-library lib_name] [-input_transition transition] [-clocks clock_list] [-include_registers] [-ignore_clock_gating] string lib_cell int fanout string wire_load_nam string lib_name float transition list clock_list ARGUMENTS lib_cell Specifies the buffer or inverter to be used to build the clock tree. -max_fanout fanout Specifies the maximum fanout number that the specified buffer can drive. Default number is 32. -wire_load_model wire_load_name Specifies the wire load model to be used to compute the wire capacitance for the nets in the clock tree. Default is the wire load model set to the design. -library lib_name Specifies the library where the specified wire load model is defined. -input_transition transition Specifies the clock input transition. If not specified, use the clock transition annotated to the clock by the set_clock_transition command. If there is no annotation either, default to 0. -clocks clock_list Specifies the clocks to be estimated for clock tree power. Default is all the clocks in the design. -include_registers Indicate the power of registers driven by the clock is also included in the power report. estimate_clock_network_power 164 -ignore_clock_gating Indicate that existing clock tree cells like the clock gating cells are ignored when building the clock tree. DESCRIPTION The estimate_clock_network_power command virtually create a clock tree for each clock and calculate power for the generated clock tree. The clock trees are built on the fly and the original design is not touched or modified. The following describes how the clock tree is built: Find all the nets in the clock network. For each net in the clock network, insert buffers to build a clock tree, so that the fanout of each buffer in the clock tree is no bigger than max fanout. The command tries to build a tree as balanced as possible such that the delays from the root to the leafs do not vary a lot. All the driven registers are to be put at the same and lowest level of the tree. The deviation of buffer fanouts at the same tree level is to be kept as small as possible. The output load of each buffer are calculated using wire load model. The input transition of each buffer will be propagated from the root of the tree. The switching activity for each inserted buffer is equal to clock frequency or from annotation (SAIF or set_switching_activity). If there are clock gating cells in the original clock network, the command will build a separate tree based on the fanout of the clock gating cell using the same rule for the clock tree, and this separate tree will be considered as a branch of the whole clock tree, and will also be balanced with other branches. Then the clock gating effect can be accounted for by the annotated or, if not annotated, propagated switching activity. In order for user to investigate savings from clock gating, the command has an option (-ignore_clock_gating) to estimate the clock tree power by ignoring the clock gating cells and compare with the power that considers the clock gating effect. The power consumed by the registers driven by the clock can also included in the report if the -include_registers option is specified. EXAMPLES In the following example, clock tree power is estimated for clock CLK by building the clock tree using the buffer buf1a1 of library ssc_core_typ and wire load model in the design is used to calculate the wire capacitance. The clock input transition is 0.2. pt_shell create_clock -name CLK -period 10 clk pt_shell set_clock_transition 0.2 CLK pt_shell estimate_clock_network_power ssc_core_typ/buf1a1 SEE ALSO report_power (2), estimate_clock_network_power 165 extract_model Generates a timing model for a design from its gate-level netlist. SYNTAX string extract_model [-context_borrow] [-latch_level levels] -output file_name [-format format_list] [-parasitic_format format_list] [-library_cell] [-remove_internal_arcs] [-ignore_boundary_parasitics] [-test_design] [-arc_types arc_list] [-noise] [-block_scope] [-block_scope_only] [-scope_scenario scenario_name] int levels stringfile_name list format_list list arc_list ARGUMENTS -context_borrow Indicates that PrimeTime is to determine which latches on an interface borrow based on the input port arrival times and clock definitions specified at the time of model extraction. The actual time borrowed by a latch is not used by model extraction; only whether a latch borrows or not. A borrowing latch is traced through during model extraction, while tracing stops at a nonborrowing latch. Use this option if your design contains latches on its interface. The -context_borrow and -latch_level options are mutually exclusive. -latch_level levels Specifies the number of levels of latch borrowing that are to occur at the interface of a design; the default is 0. The extracted model does not preserve all borrowing behavior up to the specified level, but only the specified borrowing behavior. Use this option only after you have verified that all latches at the interface of a design borrow if they are at a certain level. The -context_borrow and -latch_level options are mutually exclusive. -output file_name Specifies the root name to use in deriving the names of the generated output files; the default is the current design name. The root name is appended with an appropriate extension (.db, .data, .mod, or .lib), depending on the value of the -format option. extract_model 166 -format format_list Specifies a list of one or more output formats for the generated model. If the list contains more than one item, they must be enclosed in braces. Allowed values are as follows: • db (the default), which specifies Synopsys DB format; the output file has the extension _lib.db and contains the DB library description of the core cell of the model. • lib, which specifies Synopsys Library Compiler format; the output file has the extension .lib. -parasitic_format format_list Specifies a list of formats for the boundary parasitic file written for the model. The allowed values are spef (the default) for the SPEF format, and sbpf for the SBPF format. -library_cell Indicates that the model is to be generated as a library cell, named current_design name, rather than a design containing a core library cell. This option eliminates boundary nets, and the boundary parasitics become part of the model. You must use this option if you use the -remove_internal_arcs or the -test_design options; -test_design instantiates the library cell into a test design. -remove_internal_arcs Indicates that internal arcs are to be removed; only the pin-to-pin timing is to be preserved. Internal clocks are lost because internal arcs are needed to support them. The generated model contains only timing arcs that start or end at an input port or output port. If you use -remove_internal_arcs, you must also use the -library_cell option. -ignore_boundary_parasitics Indicates that detailed parasitic annotations present on the boundary nets of the design are not to be included in the model. If specified without the -library_cell option, -ignore_boundary_parasitics disables the writing of the SPEF file. If specified with the the -library_cell option, ignore_boundary_parasitics causes the effects of the boundary net parasitics to be excluded from the model. -test_design Indicates that a test design DB instantiating the model library cell is to be generated. The design is named current_design_test and the DB file, current_design_test.db. If you use -test_design, you must also use the library_cell option. -arc_types arc_list Specifies a list of one or more arc types to be included when extracting a model; only the specified types are extracted. By default, all arc types are included. Allowed values are min_seq_delay, max_seq_delay, min_combo_delay, max_combo_delay, setup, hold, recovery, removal, and pulse_width. If the list contains more than one item, they must be enclosed in braces. -noise Specifies that noise features should be added to the model. If the option is extract_model 167 specified and no noise information is available in the cell’s libraries and none has been specified by the user, then only steady-state resistance is written by using an estimation. This option will perform an implicit update_noise if necessary. This option is only support for the lib format. -block_scope Indicates that the block scope information needs to be captured in addition to extracting the timing model. When specified, PrimeTime creates a separate file that stores the scope information based on the current constraint setup of the block for model extraction. -block_scope_only Indicates that only the scope information based on the current setup needs to be captured for the block, no need to actually extract the timing model. This option is useful for the later runs when an ETM was already generated but the scope of block-level validation has changed yet the original ETM is not impacted by the change and no need to be re-geneated. When specified, PrimeTime creates a file contains scope information captured. -scope_scenario scenario_name Specifies the name of the scenario for which the scope data needs to be labeled and later checked for. The scope information captured and stored in the scope data file will be marked as corresponding to the given scenario. If not specified, a fixed default name is used internally. DESCRIPTION The extract_model command generates a static timing model for the current design from its gate-level netlist. The generated model exhibits the same timing characteristics as the original design and therefore is used instead of the gatelevel netlist for purposes of static timing analysis. Noise information can also be included with the use to the -noise option. The model generated by the extract_model command is context-independent. That is, changes in clock waveforms, output capacitive loads, input drives, input delays, and output delays result in different timing exhibited by the model. The only exception occurs when the -context_borrow option is specified. In this case, the timing of the generated model, especially time borrowing information, is valid only for the clock waveforms, input delays and output delays specified when the model is extracted. By default, the generated model is a design containing a single instance of the core cell. All boundary nets in the original design are preserved in the model. The name given to core lib_cell is current_design name_core and the DB model design name is current_design name. The design is written in db format, to the file filename.db, regardless of the values given to the -format option. When scope of the block is captured, it is not impacted by the environment variable hier_scope_check_defaults, instead, all applicable scoping information of the block based on its current constraint setup is captured and stored. Also, the command can be used to generated scope information for the block that will be replaced with the ETM at top-level. extract_model 168 EXAMPLES The following example generates a model in Synopsys DB format for the current design. The model is generated for the operating condition set on the design. In addition, the time borrowed by each level-sensitive latch is locked at its current value in the generated model. Two files are generated: DMA_model.db and DMA_model_lib.db. pt_shell extract_model -context_borrow -output DMA_model The following example generates a model in Synopsys DB format for the current design. The generated model is a library cell contained in model2_lib.db. The file model2_test.db is also generated; this contains the test design that instantiates the model core cell, but it is not a part of the model. model2_test.db can be used to obtain timing and model reports in PrimeTime. Also, it creates scope information for the block. pt_shell extract_model -library_cell \ -test_design -output model2 -format {db} -block_scope SEE ALSO extract_model_capacitance_limit(3) extract_model_clock_transition_limit(3) extract_model_data_transition_limit(3) extract_model_enable_report_delay_calculation(3) extract_model_gating_as_nochange(3) extract_model_lib_format_with_check_pins(3) extract_model_merge_clock_gating(3) extract_model_noise_iv_index_lower_factor(3) extract_model_noise_iv_index_upper_factor(3) extract_model_noise_width_points(3) extract_model_num_capacitance_points(3) extract_model_num_clock_transition_points(3) extract_model_num_data_transition_points(3) extract_model_num_noise_iv_points(3) extract_model_num_noise_width_points(3) extract_model_single_pin_cap(3) extract_model_status_level(3) extract_model_use_conservative_current_slew(3) extract_model_with_3d_arcs(3) extract_model_with_clock_latency_arcs(3) timing_clock_gating_propagate_enable(3), timing_disable_clock_gating_checks(3), timing_enable_preset_clear_arcs(3), hier_scope_check_defaults(3), check_block_scope(2). extract_model 169 filter The filter command, a synonym for the filter_collection command, is a DC Emulation command provided for compatibility with Design Compiler. SEE ALSO filter_collection (2). filter 170 filter_collection Filters an existing collection, resulting in a new collection. The base collection remains unchanged. SYNTAX collection filter_collection base_collection expression [-regexp] [-nocase] collectionbase_collection string expression ARGUMENTS base_collection Specifies the base collection to be filtered. This collection is copied to the result collection. Objects are removed from the result collection if they are evaluated as false by the conditional expression value. Substitute the collection you want for base_collection. expression Specifies an expression with which to filter base_collection. Substitute the string you want for expression. -regexp Specifies that the =~ and !~ filter operators will use real regular expressions. By default, the =~ and !~ filter operators use simple wildcard pattern matching with the * and ? wildcards. -nocase Makes the pattern match case-insensitive. When you specify this option, you must also specify the -regexp option. DESCRIPTION Filters an existing collection, resulting in a new collection. The base collection remains unchanged. In many cases, commands that create collections support a -filter option that filters as part of the collection process, rather than after the collection has been made. This type of filtering is almost always more efficient than using the filter_collection command after a collection has been formed. The filter_collection command is most useful if you plan to filter the same large collection many times using different criteria. The filter_collection command results in either a new collection or an empty string. A resulting new collection contains the subset of the objects in the input base_collection. A resulting empty string (the empty collection) indicates that the expression filtered out all elements of the input base_collection. The basic form of the conditional expression is a series of relations joined filter_collection 171 together with AND and OR operators. Parentheses () are also supported. The basic relation contrasts an attribute name with a value through a relational operator. For example: is_hierarchical == true and area = 6 The relational operators are == Equal != Not equal Greater than Less than = Greater than or equal to = Less than or equal to =~ Matches pattern !~ Does not match pattern The basic relational rules are • String attributes can be compared with any operator. • Numeric attributes cannot be compared with pattern match operators. • Boolean attributes can be compared only with == and !=. The value can be only true or false. Existence relations determine if an attribute is defined or not defined for the object. For example: sense == setup_clk_rise and defined(sdf_cond) The existence operators are defined undefined These operators apply to any attribute as long as it is valid for the object class. For a complete description of conditional expressions, see the PrimeTime Reference Manual. This command matches a regular expression matching in the same way as in the Tcl regexp command. When using the -regexp option, take care in the way you quote the filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can make the regular expression search case-insensitive by using the -nocase option. filter_collection 172 EXAMPLES The following example creates a collection of only hierarchical cells. pt_shell set a [filter_collection [get_cells *] \ "is_hierarchical == true"] {"Adder1", "Adder2"} The following example creates a collection of all nonmoded cell timing_arc objects in the current design. pt_shell set b [filter_collection \ [get_timing_arcs -of_objects [get_cells *]] \ "undefined(mode)"] SEE ALSO collections (2), regexp (2). filter_collection 173 find The find command, used to create a collection of design objects, is a DC Emulation command provided for compatibility with Design Compiler. SYNTAX string find [-hierarchy] [-flat] type [object_list] stringtype list object_list ARGUMENTS -hierarchy Find objects throughout hierarchy. -flat Not supported by PrimeTime. type Object class (Values: design, port, net, cell, pin, clock, library, lib_cell, lib_pin). object_list Patterns to match. DESCRIPTION The find command creates a collection of objects. The command exists in PrimeTime for compatibility with Design Compiler. Complete information about the find command can be found in the Design Compiler documentation. The supported method for creating collections of objects is to use get* commands (for example, get_cells or get_pins). SEE ALSO get_cells (2), get_clocks (2), get_designs (2), get_lib_cells (2), get_lib_pins (2), get_libs (2), get_nets (2), get_pins (2), get_ports (2). find 174 foreach_in_collection Iterates over the elements of a collection. SYNTAX string foreach_in_collection itr_var collections body stringitr_var list collections stringbody ARGUMENTS itr_var Specifies the name of the iterator variable. collections Specifies a list of collections over which to iterate. body Specifies a script to execute per iteration. DESCRIPTION The foreach_in_collection command is used to iterate over each element in a collection. You cannot use the Tcl-supplied foreach command to iterate over collections, because foreach requires a list, and a collection is not a list. Also, using foreach on a collection will cause the collection to be deleted. The arguments to foreach_in_collection parallel those of foreach: an iterator variable, the collections over which to iterate, and the script to apply at each iteration. All arguments are required. Note that foreach_in_collection does not allow a list of iterator variables. During each iteration, itr_var is set to a collection of exactly one object. Any command that accepts collections as an argument accepts itr_var, because they are of the same data type (collection). You can nest the foreach_in_collection command within other control structures, including foreach_in_collection. Note that if the body of the iteration is modifying the netlist, it is possible that all or part of the collection involved in the iteration will be deleted. The foreach_in_collection command is safe for such operations. If a command in the body causes the collection to be removed, at the next iteration, the iteration will end with a message indicating that the iteration ended prematurely. An alternative to collection iteration is to use complex filtering to create a collection that includes only the desired elements, then apply one or more commands to that collection. If the order of operations does not matter, the following are equivalent. The first is an example without iterators. foreach_in_collection 175 set s [get_cells {U1/*}] command1 $s command2 $s unset s The following is the same example using foreach_in_collection. foreach_in_collection itr [get_cells {U1/*}] { command1 $itr command2 $itr } For collections with large numbers of objects, the non-iterator version is more efficient, though both produce the same results if the commands are orderindependent. EXAMPLES The following example removes the wire load model from all hierarchical cells in the current instance. pt_shell foreach_in_collection itr [get_cells *] { ? if {[get_attribute $itr is_hierarchical] == "true"} { ? remove_wire_load_model $itr ? } ? } Removing wire load model from cell ’i1’. Removing wire load model from cell ’i2’. SEE ALSO collections(2), filter_collection(2), query_objects(2). foreach_in_collection 176 NAME get_alternative_lib_cells Creates a collection of library cells that can be used to replace or "size" a specified cell in the current design. SYNTAX string get_alternative_lib_cells [-current_library] [-libraries lib_spec] [-base_names] object string object list lib_spec ARGUMENTS object Specifies a cell or a library cell for which alternative library cells is required. -current_library If this option is specified, then PrimeTime searches for library cells in the cell’s current library or library cell’s current library only. You cannot specify this option with the -libraries option. -libraries lib_spec Specifies a list of libraries from which to select alternative library cells. The default is to select from all libraries in the link path. lib_spec can be a list of library names, or collections of libraries loaded into PrimeTime; the latter can be obtained using the get_libs command. You cannot specify this option with the -current_library option. -base_names Specifies that a list of library cell base names is to be returned. Multiple library cells may have the same base name, however the list is stripped of these duplicate names. This option is enabled by default if the user invokes PrimeTime with the -multi_scenario option. DESCRIPTION The get_alternative_lib_cells command creates a collection of library cells that can be used to replace or "size" a specified cell or library cell. A library cell is included in the collection only if it satisfies the same criteria used by the size_cell command to determine whether a library cell can be used to replace a cell in the current design. If the -current_library option is specified, then PrimeTime searches for library cells in the cell’s current libraries or library cell’s current library only. If the 177 -libraries option is specified, then PrimeTime searches for library cells in the libraries contained within the lib_spec only. Alternatively, if neither of the above options are specified, PrimeTime searches for the library cell in the following sources in this order: 1) The object’s current library 2) The link_path_per_instance variable 3) The link_path variable. If a library is found with a min library relationship (from set_min_library), the min library is automatically included. To see a comparison of the slack and design cost within a set of alternative library cells, use the report_alternative_lib_cells command. EXAMPLES The following example shows how to find alternative library cells for a cell in the design. Here, u_max is an instance of class_max/OR3 and u_min is an instance of class_min/OR3. pt_shell set link_path [list * class_max.db] * class_max.db pt_shell set_min_library class_max.db -min_version class_min.db Loading db file ’/u/libs/class_max.db’ Loading db file ’/u/libs/class_min.db’ Created max/min library relationship: Max: /u/libs/class_max.db:class_max Min: /u/libs/class_min.db:class_min pt_shell get_alternative_lib_cells -libraries class_min u_max {"class_min/OR3", "class_min/OR3P"} pt_shell get_alternative_lib_cells -libraries class_max u_min {"class_max/OR3", "class_max/OR3P"} pt_shell get_alternative_lib_cells u_max {"class_max/OR3P", "class_min/OR3", "class_min/OR3P"} pt_shell get_alternative_lib_cells u_min {"class_max/OR3", "class_max/OR3P", "class_min/OR3P"} pt_shell get_alternative_lib_cells u_min -current_library {"class_min/OR3P"} pt_shell get_alternative_lib_cells -base_names u_min {"OR3", "OR3P"} The following example shows how to find alternative library cells for a lib_cell. pt_shell get_alternative_lib_cells class_max/OR3 {"class_max/OR3P", "class_min/OR3", "class_min/OR3P"} pt_shell get_alternative_lib_cells class_max/OR3 -current_library 178 {"class_max/OR3P"} SEE ALSO get_libs (2), report_alternative_lib_cells (2), set_min_library (2), size_cell (2), link_path_per_instance (3), link_path (3). 179 get_attribute Retrieves the value of an attribute on an object. SYNTAX string get_attribute [-class class_name] [-quiet] object_spec attr_name stringclass_name stringobject_spec or collection object_spec stringattr_name ARGUMENTS -class class_name Specifies the class name of object_spec, if object_spec is a name. Valid values for object_spec are design, port, cell, pin, net, lib, lib_cell, lib_pin, clock, timing_path, and timing_point. You must use this option if object_spec is a name. -quiet Indicates that any error and warning messages are not to be reported. object_spec Specifies a single object from which to get the attribute value. object_spec must be is either a collection of exactly one object, or a name which is combined with the class_name to find the object. If object_spec is a name, you must also use the -class option. attr_name Specifies the name of the attribute whose value is to be retrieved. DESCRIPTION Retrieves the value of an attribute on an object. The object is either a collection of exactly one object, or a name of an object. If it is a name, the -class option is required. The return value is a string. EXAMPLES In the following example, the first command defines an attribute ’X’ for cells. The second command sets the attribute to a value on all cells in this level of the hierarchy. The third command retrieves the value from one cell, combines it with the application attribute full_name, and creates a simple report. pt_shell define_user_attribute -type int -class cell X pt_shell set_user_attribute [get_cells *] X 30 Set attribute ’X’ on ’i1’ Set attribute ’X’ on ’i2’ pt_shell foreach_in_collection sel [get_cells *] { ? echo -n "On ’[get_attribute $sel full_name]’, " ? echo "X = [get_attribute $sel X]" get_attribute 180 ? } On ’i1’, X = 30 On ’i2’, X = 30 SEE ALSO collections (2), define_user_attribute (2), foreach_in_collection (2), list_attributes (2), remove_user_attribute (2), report_attribute (2), set_user_attribute (2). get_attribute 181 get_cells Creates a collection of cells from the current design relative to the current instance. You can assign these cells to a variable or pass them into another command. SYNTAX collection get_cells [-hierarchical] [-quiet] [-regexp] [-nocase] [-exact] [-filter expression] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -hierarchical Searches for cells level-by-level relative to the current instance. The full name of the object at a particular level must match the patterns. The search is similar to the UNIX find command. For example, if there is a cell block1/ adder, a hierarchical search finds it using "adder". -filter expression Filters the collection with expression. For any cells that match patterns (or objects) the expression is evaluated based on the cell’s attributes. If the expression evaluates to true, the cell is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. For use when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of cells connected to the specified objects. In this case, each object is either a named pin, a pin collection, a named net or a net collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. In addition, you cannot use -hierarchical with of_objects. get_cells 182 patterns Matches cell names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type cell. patterns and -of_objects are mutually exclusive; you must specify one, but not both. DESCRIPTION The get_cells command creates a collection of cells in the current design, relative to the current instance, that match certain criteria. The command returns a collection if any cells match the patterns or objects and pass the filter (if specified). If no objects match the criteria, the empty string is returned. If any patterns (or objects) fail to match any objects and the current design is not linked, the design automatically links. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression; use rigid quoting with curly braces around regular expressions. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search by adding ".*" to the beginning or end of the expressions as needed. You can use the get_cells command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_cells result to a variable. When issued from the command prompt, get_cells behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_cells provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_cells as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries the cells that begin with "o" and reference an FD2 library cell. Although the output looks like a list, it is not. The output is just a display. pt_shell get_cells "o*" -filter "ref_name == FD2" {"o_reg1", "o_reg2", "o_reg3", "o_reg4"} The following example shows that, given a collection of pins, you can query the get_cells 183 cells connected to those pins. pt_shell set pinsel [get_pins o*/CP] {"o_reg1/CP", "o_reg2/CP"} pt_shell query_objects [get_cells -of_objects $pinsel] {"o_reg1", "o_reg2"} The following example removes the wire load model from cells i1 and i2. pt_shell remove_wire_load_model [get_cells {i1 i2}] Removing wire load model from cell ’i1’. Removing wire load model from cell ’i2’. 1 SEE ALSO collections(2), filter_collection(2), get_pins(2), link_design(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_cells 184 get_cells Creates a collection of cells from the current design relative to the current instance. You can assign these cells to a variable or pass them into another command. SYNTAX collection get_cells [-hierarchical] [-quiet] [-regexp] [-nocase] [-exact] [-filter expression] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -hierarchical Searches for cells level-by-level relative to the current instance. The full name of the object at a particular level must match the patterns. The search is similar to the UNIX find command. For example, if there is a cell block1/ adder, a hierarchical search finds it using "adder". -filter expression Filters the collection with expression. For any cells that match patterns (or objects) the expression is evaluated based on the cell’s attributes. If the expression evaluates to true, the cell is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. For use when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of cells connected to the specified objects. In this case, each object is either a named pin, a pin collection, a named net or a net collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. In addition, you cannot use -hierarchical with of_objects. get_cells 185 patterns Matches cell names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type cell. patterns and -of_objects are mutually exclusive; you must specify one, but not both. DESCRIPTION The get_cells command creates a collection of cells in the current design, relative to the current instance, that match certain criteria. The command returns a collection if any cells match the patterns or objects and pass the filter (if specified). If no objects match the criteria, the empty string is returned. If any patterns (or objects) fail to match any objects and the current design is not linked, the design automatically links. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression; use rigid quoting with curly braces around regular expressions. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search by adding ".*" to the beginning or end of the expressions as needed. You can use the get_cells command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_cells result to a variable. When issued from the command prompt, get_cells behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_cells provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_cells as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries the cells that begin with "o" and reference an FD2 library cell. Although the output looks like a list, it is not. The output is just a display. pt_shell get_cells "o*" -filter "ref_name == FD2" {"o_reg1", "o_reg2", "o_reg3", "o_reg4"} The following example shows that, given a collection of pins, you can query the get_cells 186 cells connected to those pins. pt_shell set pinsel [get_pins o*/CP] {"o_reg1/CP", "o_reg2/CP"} pt_shell query_objects [get_cells -of_objects $pinsel] {"o_reg1", "o_reg2"} The following example removes the wire load model from cells i1 and i2. pt_shell remove_wire_load_model [get_cells {i1 i2}] Removing wire load model from cell ’i1’. Removing wire load model from cell ’i2’. 1 SEE ALSO collections(2), filter_collection(2), get_pins(2), link_design(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_cells 187 get_clock_network_objects Returns a collection of objects that belong or relate to the direct clock network. SYNTAX collection get_clock_tree_objects -type object_type [clock_list] [-include_clock_gating_network] stringobject_type list clock_list ARGUMENTS -type object_type Specifies the type of the clock network objects to be returned. clock_list Specifies the clock domains of which the clock network objects are returned. By default, the command returns all clock network objcets. -include_clock_gating_network Indicates that clock gating networks are included in the clock network. DESCRIPTION Returns a collection of clock network objects of certain type (specified by object_type) that belong or relate to one or several clock domains (specified by clock_list), or all clock domains (if clock_list is not specified). A clock network is a special logic part of the design that propagates the clocks from the clock sources to the clock pins of latches, flip-flops (which function as anything but propagating clocks) or black-box IPs. The propagation also stops at design output ports, dangling pins or nets, or the sources of other clocks. The get_clock_network_objects command retrieves certain types of objects from the direct clock network (including the latches, flip-flops and black_box IPs driven by the clock network). If the specified clock is a generated clock, the propagation won’t go backward to the clock network of its master clock. If the specified clock is a master clock, the propagation won’t go forward to the clock network of its generated clocks either. The object_type can be one of the following: cell Cells that belong to the clock network, including non-inverting or inverting buffers, combinational cells, library defined clock gating cells, etc. register Latches, flip-flops or black-box IPs (e.g. the memory cells) that are driven by the clock network. get_clock_network_objects 188 net Nets that connect the clock network cells to other clock network cells, to the driven registers, or to the I/O ports of design. pin Pins and ports that are connected with the clock network nets. Note that the clock pins of the driven registers are included. clock_gating_output Output pins of clock gating cells, either defined by the library, inserted by Power Compiler, automatically inferred by PrimeTime, or manually set by the user. The results are consistent with those of / fBreport_clock_gating_checks/fP, and can be affected by other clock gating check related commands or variables. The option -include_clock_gating_network indicates that discrete logic structure functioning as clock gating is taken as belonging to the clock network. Only the typical clock gating logic is considered as qualified clock gating network to be included in the clock network. The typical clock gating logic starts from the output of a level sensitive latch driven by the specified clock, possibly goes through a couple of buffers, and comes back 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 enable pin, either inferred or manually set. Therefore, similarly, the results can be affected by clock gating check related commands or variables. When the clock gating network is included in the clock network, all objects in the clock gating network is considered as clock network objects. The latch is regarded as a clock network cell, but not a clock network register. The clock_gating_output is not affected by this option. EXAMPLES The following command returns a collection of clock network pins of all clock domains in the design, not including pins of the clock gating networks. pt_shell get_clock_network_objects -type pin SEE ALSO create_clock (2), create_generated_clock (2), get_clocks (2), get_generated_clocks (2), remove_clock (2), remove_generated_clock (2), report_clock (2), remove_clock_gating_check (2), remove_disable_clock_gating_check (2), report_clock_gating_check (2), set_clock_gating_check (2), set_disable_clock_gating_check (2), timing_disable_clock_gating_checks (2). get_clock_network_objects 189 get_clocks Creates a collection of clocks from the current design. You can assign these clocks to a variable or pass them into another command. SYNTAX collection get_clocks [-quiet] [-regexp] [-nocase] [-filter expression] patterns stringexpression list patterns ARGUMENTS -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -filter expression Filters the collection with expression. For any clocks that match patterns, the expression is evaluated based on the clock’s attributes. If the expression evaluates to true, the clock is included in the result. patterns Matches clock names against patterns. Patterns can include the wildcard characters "*" and "?". DESCRIPTION The get_clocks command creates a collection of clocks in the current design that match certain criteria. The command returns a collection if any clocks match the patterns and pass the filter (if specified). If no objects match the criteria, the empty string is returned. You can use the get_clocks command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_clocks result to a variable. When issued from the command prompt, get_clocks behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. get_clocks 190 The "implicit query" property of get_clocks provides a fast, simple way to display clocks in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_clocks as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. In addition, see the man page for all_clocks, which also creates a collection of clocks. EXAMPLES The following example applies the set_max_time_borrow command to all clocks in the design matching "PHI*". pt_shell set_max_time_borrow 0 [get_clocks "PHI*"] The following example sets the variable clock_list to a collection of clocks that have period of 15. pt_shell set clock_list [get_clocks * -filter "period==15"] SEE ALSO all_clocks(2), collections(2), create_clock(2), query_objects(2), report_clock(2); collection_result_display_limit(3). get_clocks 191 get_designs Creates a collection of one or more designs loaded into PrimeTime. You can assign these designs to a variable or pass them into another command. SYNTAX collection get_designs [-hierarchical] [-quiet] [-regexp] [-nocase] [-exact] [filter expression] patterns stringexpression list patterns ARGUMENTS -hierarchical Searches for designs inferred by the design hierarchy relative to the current instance. The full name of the object at a particular level must match the patterns. The use of this option does not force an auto link. -filter expression Filters the collection with expression. For any designs that match patterns, the expression is evaluated based on the design’s attributes. If the expression evaluates to true, the design is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. patterns Matches design names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type design. DESCRIPTION The get_designs command creates a collection of designs from those currently loaded into PrimeTime that match certain criteria. The command returns a collection if any get_designs 192 designs match the patterns and pass the filter (if specified). If no objects matched your criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_designs command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_designs result to a variable. When issued from the command prompt, get_designs behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_designs provides a fast, simple way to display designs in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_designs as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries the designs that begin with ’mpu.’ Although the output looks like a list, it is just a display. A complete listing of designs is available using the list_designs command. pt_shell get_designs mpu* {"mpu_0_0", "mpu_0_1", "mpu_1_0", "mpu_1_1"} The following example shows that, given a collection of designs, you can remove those designs. pt_shell remove_design [get_designs mpu*] Removing design mpu_0_0... Removing design mpu_0_1... Removing design mpu_1_0... Removing design mpu_1_1... get_designs 193 SEE ALSO collections(2), filter_collection(2), list_designs(2), query_objects(2), regexp(2). remove_design(2); collection_result_display_limit(3). get_designs 194 get_designs Creates a collection of one or more designs loaded into PrimeTime. You can assign these designs to a variable or pass them into another command. SYNTAX collection get_designs [-hierarchical] [-quiet] [-regexp] [-nocase] [-exact] [filter expression] patterns stringexpression list patterns ARGUMENTS -hierarchical Searches for designs inferred by the design hierarchy relative to the current instance. The full name of the object at a particular level must match the patterns. The use of this option does not force an auto link. -filter expression Filters the collection with expression. For any designs that match patterns, the expression is evaluated based on the design’s attributes. If the expression evaluates to true, the design is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. patterns Matches design names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type design. DESCRIPTION The get_designs command creates a collection of designs from those currently loaded into PrimeTime that match certain criteria. The command returns a collection if any get_designs 195 designs match the patterns and pass the filter (if specified). If no objects matched your criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_designs command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_designs result to a variable. When issued from the command prompt, get_designs behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_designs provides a fast, simple way to display designs in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_designs as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries the designs that begin with ’mpu.’ Although the output looks like a list, it is just a display. A complete listing of designs is available using the list_designs command. pt_shell get_designs mpu* {"mpu_0_0", "mpu_0_1", "mpu_1_0", "mpu_1_1"} The following example shows that, given a collection of designs, you can remove those designs. pt_shell remove_design [get_designs mpu*] Removing design mpu_0_0... Removing design mpu_0_1... Removing design mpu_1_0... Removing design mpu_1_1... get_designs 196 SEE ALSO collections(2), filter_collection(2), list_designs(2), query_objects(2), regexp(2). remove_design(2); collection_result_display_limit(3). get_designs 197 get_distributed_variables Gets tcl variables from slaves and creates an array at the master indexed by scenario name. SYNTAX Boolean get_distributed_variables ARGUMENTS [pre_commands pre_command_string] (string containing pre commands to be executed at slave) [post_commands post_command_string] (string containing post commands to be executed at slave] [-attributes attribute_list] (list of attributes to be retrieved from the slave) variable_list stringpre_command_string stringpost_command_string list attribute_list list variable_list -pre_commands pre_command_string A string of commands to be executed in the slave context before the retrieval of variables. Commands are grouped using the ";" character. The maximum size of a command is 1000 chars. -post_commands post_command_string A string of commands to be executed in the slave context after the retrieval of variables. Commands are grouped using the ";" character. The maximum size of a command is 1000 chars. -attributes attribute_list A list of attributes to be retrieved from a slave collection. If this option is not specified then only the full_name,scenario_name and object_class attributes are retrieved. This option should be used in conjunction with set_distributed_parameter -collection_levels commands to control the amount of data retrieved from the slave. DESCRIPTION The get_distributed_variables command retrieves data from the slaves and makes it available for further processing at the master. The variables included in the variable_list option must be slave variables. Each slave variable may have a different value depending on the scenario context. The command creates an array at the master for each variable. The array will have the same name as the variable. The array will will be indexed by the scenario name. The data in the array for a given scenario index will have the same value as the slave variable in that scenario’s context. The variable types currently supported are TCL Arrays, TCL lists and all types of collections. Users need to be aware that when number of scenarios number of get_distributed_variables 198 processors variables may be destroyed during the save restore process. When number of scenarios number of processors it is advisable to use the pre_commands variable to generate the variables to be transmitted. When retrieving a collection use the attributes option to specify what attributes are to be retrieved from the slaves for the given collection. EXAMPLES In the following examples we assume that number of scenarios number of processors pt_shell remote_execute {set my_paths [get_timing_paths -nworst 10]} pt_shell get_distributed_variables my_paths -atrributes {slack} pt_shell foreach_in_collection path $my_paths(scen1) { echo [get_attribute $path slack] } pt_shell remote_execute {set pslack [get_attribute [get_pins U1/A] slack} pt_shell get_distributed_variables pslack pt_shell echo [array get pslack] {scen1 0.1231 scen2 0.1232} In the following example we access an attribute which is itself a collection pt_shell remote_execute {set my_pins [get_pins *]} pt_shell get_distributed_variable my_pins -attributes {direction clocks} pt_shell foreach_in_collection pin $my_pins(scen1) { echo "direction:[get_attribute $pin direction]" set my_clocks [get_attribute $pin clocks] foreach_in_collection my_clock $my_clocks { echo "full clock name : get_attribute $my_clock full_name" } } In the following examples we assume that number of scenarios number of processors pt_shell get_distributed_variables my_paths pre_commands{set my_paths [get_timing_paths -nworst 10]} -attributes slack SEE ALSO set_distributed_variables set_distributed_parameters get_distributed_variables 199 get_distribution_attribute Returns a collection of one or more values associated with a distribution’s attribute. SYNTAX list get_distribution_attribute distribution attribute value collection distribution string attribute int or float value ARGUMENTS distribution The distribution collection. attribute The attribute of the distribution. Valid attributes are pdf, cdf, quantile, cdf_values, and pdf_values. value The parameterized value associated with the attribute of the distribution. DESCRIPTION Returns the value (or a list of values) associated with the distribution’s attribute, parameterized at value. EXAMPLES This example returns the 0.98-quantile of the distribution $arrival_dist. pt_shell get_distribution_attribute $arrival_dist quantile 0.98 30.000000 This example returns the cdf value at x-value 4.6. pt_shell get_distribution_attribute $arrival_dist cdf 4.6 0.000000 This example returns the pdf value at x-value 1.0. pt_shell get_distribution_attribute $arrival_dist pdf 1.0 0.000000 get_distribution_attribute 200 This example returns a list of 100 x-pdf value pairs in the format of x1 pdf1 x2 pdf2 ... x100 pdf100. pt_shell get_distribution_attribute $arrival_dist pdf_values 100 {-3.500000 0.000873} {-2.722222 0.009812} ... This example returns a list of 100 x-cdf value pairs in the format of x1 cdf1 x2 cdf2 ... x100 cdf100. pt_shell get_distribution_attribute $arrival_dist cdf_values 100 {-3.500000 0.000234} {-2.722222 0.003250} ... SEE ALSO create_distribution(2). get_distribution_attribute 201 get_generated_clocks Creates a collection of generated clocks. SYNTAX collection get_generated_clocks [-quiet] [-regexp] [-nocase] [-filter expression] patterns stringexpression list patterns ARGUMENTS -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -filter expression Filters the collection with expression. For any generated clocks that match patterns, the expression is evaluated based on the generated clock’s attributes. If the expression evaluates to true, the generated clock is included in the result. patterns Matches generated clock names against patterns. Patterns can include the wildcard characters "*" and "?". DESCRIPTION The get_generated_clocks command creates a collection of generated clocks from the current design that match certain criteria. The command returns a collection if any generated clocks match the patterns and pass the filter (if specified). If no objects match the criteria, the empty string is returned. To create a generated clock in the design, use create_generated_clock. To remove a generated clock from the design, use remove_generated_clock. To show information about clocks and generated clocks in the design, use report_clock. You can use the get_generated_clocks command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_generated_clocks result to a variable. get_generated_clocks 202 When issued from the command prompt, get_generated_clocks behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_generated_clocks provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_generated_clocks as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following command applies the set_clock_latency command on all generated clocks in the design matching the "GEN*". pt_shell set_clock_latency 2.0 [get_generated_clocks "GEN*"] The following command removes all the generated clocks in the design matching "GEN1*". pt_shell remove_generated_clock [get_generated_clocks "GEN1*"] SEE ALSO collections (2), create_generated_clock (2), query_objects (2), remove_generated_clock (2), report_clock (2); collection_result_display_limit(3). get_generated_clocks 203 get_generated_clocks Creates a collection of generated clocks. SYNTAX collection get_generated_clocks [-quiet] [-regexp] [-nocase] [-filter expression] patterns stringexpression list patterns ARGUMENTS -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -filter expression Filters the collection with expression. For any generated clocks that match patterns, the expression is evaluated based on the generated clock’s attributes. If the expression evaluates to true, the generated clock is included in the result. patterns Matches generated clock names against patterns. Patterns can include the wildcard characters "*" and "?". DESCRIPTION The get_generated_clocks command creates a collection of generated clocks from the current design that match certain criteria. The command returns a collection if any generated clocks match the patterns and pass the filter (if specified). If no objects match the criteria, the empty string is returned. To create a generated clock in the design, use create_generated_clock. To remove a generated clock from the design, use remove_generated_clock. To show information about clocks and generated clocks in the design, use report_clock. You can use the get_generated_clocks command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_generated_clocks result to a variable. get_generated_clocks 204 When issued from the command prompt, get_generated_clocks behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_generated_clocks provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_generated_clocks as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following command applies the set_clock_latency command on all generated clocks in the design matching the "GEN*". pt_shell set_clock_latency 2.0 [get_generated_clocks "GEN*"] The following command removes all the generated clocks in the design matching "GEN1*". pt_shell remove_generated_clock [get_generated_clocks "GEN1*"] SEE ALSO collections (2), create_generated_clock (2), query_objects (2), remove_generated_clock (2), report_clock (2); collection_result_display_limit(3). get_generated_clocks 205 get_ilm_objects Returns a collection of nets, cells, or pins that are part of the interface logic for the current design. SYNTAX collection get_ilm_objects [-type {net | pin | cell}] ARGUMENTS -type {net | pin | cell} Specifies the type of object to be returned as a collection of objects. Allowed values are net, pin, or cell. A collection is returned of objects of the specified type that belong to the interface logic on the current design. DESCRIPTION Returns a collection of nets, cells, or pins that have been identified as belonging to interface logic by using the identify_interface_logic command. The is_interface_logic_pin attribute identifies pins that are part of the interface logic, The command takes into account the fact that the design corresponding to the interface logic model (ILM) is flattened, hierarchical nets are reduced to a single flattened net, and hierarchical pins and cells on the original design are not contained in the ILM. The objects returned are those that will be referred to in the interface logic netlist, script, and back-annotation files written using the write_ilm_* commands. Use the get_ilm_objects command to review the objects that have been identified as belonging to the interface logic on the current design. For a discussion of ILM creation and the associated commands, see the manual page for the identify_interface_logic command. EXAMPLES The following example returns a collection of all interface logic cells. pt_shell get_ilm_objects -type cell The following command returns a collection of all nets in the flattened ILM netlist. pt_shell get_ilm_objects -type net SEE ALSO identify_interface_logic (2), write_ilm_netlist (2), write_ilm_parasitics (2), write_ilm_script (2), write_ilm_sdf (2); get_ilm_objects 206 get_libs Creates a collection of libraries loaded into PrimeTime. You can assign these libraries to a variable or pass them into another command. SYNTAX collection get_libs [-filter expression] [-quiet] [-regexp] [-nocase] [-exact] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -filter expression Filters the collection with expression. For any libraries that match patterns (or objects), the expression is evaluated based on the library’s attributes. If the expression evaluates to true, the library is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modify the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of libraries that contain the specified objects. In this case, each object is either a named library cell or a library cell collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. patterns Matches library names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type lib. patterns and -of_objects are mutually exclusive; you must specify one, but not both. get_libs 207 DESCRIPTION The get_libs command creates a collection of libraries from those currently loaded into PrimeTime that match certain criteria. The command returns a collection if any libraries match the patterns and pass the filter (if specified). If no objects match the criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_libs command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_libs result to a variable. When issued from the command prompt, get_libs behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_libs provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_libs as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries all loaded libraries. Although the output looks like a list, it is just a display. Note that a complete listing of libraries is available using the list_libraries command. pt_shell get_libs * {"misc_cmos", "misc_cmos_io"} The following example shows that given a library collection, you can remove those libraries. Note that you cannot remove libraries if they are referenced by a design. pt_shell remove_lib [get_libs misc*] Removing library misc_cmos... Removing library misc_cmos_io... get_libs 208 SEE ALSO collections(2), filter_collection(2), list_libraries(2), query_objects(2), regexp(2), remove_lib(2); collection_result_display_limit(3). get_libs 209 get_lib_cells Creates a collection of library cells from libraries loaded into PrimeTime. You can assign these library cells to a variable or pass them into another command. SYNTAX collection get_lib_cells [-filter expression] [-quiet] [-regexp] [-nocase] [-exact] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -filter expression Filters the collection with expression. For any library cells that match patterns (or objects), the expression is evaluated based on the library cell’s attributes. If the expression evaluates to true, the library cell is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of library cells that are referenced by the specified cells or own the specified library pins. In this case, each object is either a named library pin or netlist cell, or a library pin collection or a netlist cell collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. patterns Matches library cell names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type lib_cell. patterns and -of_objects are mutually exclusive; you must specify one, but not both. get_lib_cells 210 DESCRIPTION The get_lib_cells command creates a collection of library cells from libraries currently loaded into PrimeTime that match certain criteria. The command returns a collection if any library cells match the patterns or objects and pass the filter (if specified). If no objects match the criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_lib_cells command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_lib_cells result to a variable. When issued from the command prompt, get_lib_cells behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_lib_cells provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_lib_cells as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries all library cells that are in the misc_cmos library and begin with AN2. Although the output looks like a list, it is just a display. pt_shell get_lib_cells misc_cmos/AN2* {"misc_cmos/AN2", "misc_cmos/AN2P"} The following example shows one way to find out the library cell used by a particular cell. pt_shell get_lib_cells -of_objects [get_cells o_reg1] {"misc_cmos/FD2"} SEE ALSO collections(2), filter_collection(2), get_cells(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_lib_cells 211 get_lib_cells Creates a collection of library cells from libraries loaded into PrimeTime. You can assign these library cells to a variable or pass them into another command. SYNTAX collection get_lib_cells [-filter expression] [-quiet] [-regexp] [-nocase] [-exact] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -filter expression Filters the collection with expression. For any library cells that match patterns (or objects), the expression is evaluated based on the library cell’s attributes. If the expression evaluates to true, the library cell is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of library cells that are referenced by the specified cells or own the specified library pins. In this case, each object is either a named library pin or netlist cell, or a library pin collection or a netlist cell collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. patterns Matches library cell names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type lib_cell. patterns and -of_objects are mutually exclusive; you must specify one, but not both. get_lib_cells 212 DESCRIPTION The get_lib_cells command creates a collection of library cells from libraries currently loaded into PrimeTime that match certain criteria. The command returns a collection if any library cells match the patterns or objects and pass the filter (if specified). If no objects match the criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_lib_cells command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_lib_cells result to a variable. When issued from the command prompt, get_lib_cells behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_lib_cells provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_lib_cells as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries all library cells that are in the misc_cmos library and begin with AN2. Although the output looks like a list, it is just a display. pt_shell get_lib_cells misc_cmos/AN2* {"misc_cmos/AN2", "misc_cmos/AN2P"} The following example shows one way to find out the library cell used by a particular cell. pt_shell get_lib_cells -of_objects [get_cells o_reg1] {"misc_cmos/FD2"} SEE ALSO collections(2), filter_collection(2), get_cells(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_lib_cells 213 get_lib_pins Creates a collection of library cell pins from libraries loaded into PrimeTime. You can assign these library cell pins to a variable or pass them into another command. SYNTAX collection get_lib_pins [-filter expression] [-quiet] [-regexp] [-nocase] [-exact] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -filter expression Filters the collection with expression. For any library cell pins that match patterns (or objects), the expression is evaluated based on the library cell pin’s attributes. If the expression evaluates to true, the lib_pin is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of library cell pins referenced by the specified netlist pins or owned by the specified library cells. In this case, each object is either a named library cell or netlist pin, or a library cell collection or netlist pin collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. patterns Matches library cell pin names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type lib_pin. patterns and -of_objects are mutually exclusive; you must specify one, but not both. get_lib_pins 214 DESCRIPTION The get_lib_pins command creates a collection of library cell pins from libraries currently loaded into PrimeTime that match certain criteria. The command returns a collection if any library cell pins match the patterns or objects and pass the filter (if specified). If no objects matched the criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_lib_pins command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_lib_pins result to a variable. When issued from the command prompt, get_lib_pins behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_lib_pins provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_lib_pins as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries all pins of the AN2 library cell in the misc_cmos library. Although the output looks like a list, it is just a display. pt_shell [get_lib_pins misc_cmos/AN2/* {"misc_cmos/AN2/A", "misc_cmos/AN2/B", "misc_cmos/AN2/Z"} The following example shows one way to find out how the library pin is used by a particular pin in the netlist. pt_shell get_lib_pins -of_objects o_reg1/Q {"misc_cmos/FD2/Q"} get_lib_pins 215 SEE ALSO collections(2), filter_collection(2), get_libs(2), get_lib_cells(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_lib_pins 216 get_lib_pins Creates a collection of library cell pins from libraries loaded into PrimeTime. You can assign these library cell pins to a variable or pass them into another command. SYNTAX collection get_lib_pins [-filter expression] [-quiet] [-regexp] [-nocase] [-exact] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -filter expression Filters the collection with expression. For any library cell pins that match patterns (or objects), the expression is evaluated based on the library cell pin’s attributes. If the expression evaluates to true, the lib_pin is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of library cell pins referenced by the specified netlist pins or owned by the specified library cells. In this case, each object is either a named library cell or netlist pin, or a library cell collection or netlist pin collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. patterns Matches library cell pin names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type lib_pin. patterns and -of_objects are mutually exclusive; you must specify one, but not both. get_lib_pins 217 DESCRIPTION The get_lib_pins command creates a collection of library cell pins from libraries currently loaded into PrimeTime that match certain criteria. The command returns a collection if any library cell pins match the patterns or objects and pass the filter (if specified). If no objects matched the criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_lib_pins command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_lib_pins result to a variable. When issued from the command prompt, get_lib_pins behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_lib_pins provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_lib_pins as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries all pins of the AN2 library cell in the misc_cmos library. Although the output looks like a list, it is just a display. pt_shell [get_lib_pins misc_cmos/AN2/* {"misc_cmos/AN2/A", "misc_cmos/AN2/B", "misc_cmos/AN2/Z"} The following example shows one way to find out how the library pin is used by a particular pin in the netlist. pt_shell get_lib_pins -of_objects o_reg1/Q {"misc_cmos/FD2/Q"} get_lib_pins 218 SEE ALSO collections(2), filter_collection(2), get_libs(2), get_lib_cells(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_lib_pins 219 get_lib_timing_arcs Creates a collection of library arcs for custom reporting and other processing. You can assign these library arcs to a variable and get the desired attribute for further processing. SYNTAX string get_lib_timing_arcs [-to to_list] [-from from_list] [-of_objects object_list] [-filter expression] [-quiet] list to_list list from_list list object_list stringexpression ARGUMENTS -to to_list Specifies the "to" library pins, or ports. All backward library arcs from the specified library pins or ports are considered. -from from_list Specifies the "from" library pins, or ports. All forward library arcs from the specified library pins or ports are considered. -of_objects object_list Specifies library cells or timing arcs. If a library cell is specified, all library cell arcs of that cell are considered. If a timing arc collection is given in the object list, the corresponding library timing arc is considered. -filter expression Specifies the filter expression. A filter expression is a string that comprises a series of logical expressions describing a set of constraints you want to place on the collection of library arcs. Each subexpression of a filter expression is a relation contrasting an attribute name with a value, by means of an operator. -quiet Specifies that all messages are to be suppressed. DESCRIPTION Creates a collection of library arcs for custom reporting and other processing. You can assign these library arcs to a variable and get the desired attribute for further processing. Use the foreach_in_collection command to iterate among the library arcs in the collection. You can use the get_attribute command to obtain information about the paths. You can also use the filter expression to filter the library arcs that satisfy the specified conditions. The following attributes are get_lib_timing_arcs 220 supported on library timing arcs: from_lib_pin is_disabled is_user_disabled mode object_class sdf_cond sense to_lib_pin One attribute of a library timing arc is the from_lib_pin, which is the library pin from which the timing arc begins. In the same way, to_lib_pin is the library pin to which the timing arc ends. To get more information on from_lib_pin and to_lib_pin, use the get_attributes command. The object_class attribute holds the class name of library timing arcs: lib_timing_arc. See the collections and foreach_in_collection man pages for more information. EXAMPLES The following procedure is an example of how the collection returned from an invocation of get_lib_timing_arcs can be utilized to provide useful and readable cell level arc information. proc show_lib_arcs {args} { set lib_arcs [eval [concat get_lib_timing_arcs $args]] echo [format "%15s %-15s %18s" "from_lib_pin" "to_lib_pin" \ "sense"] echo [format "%15s %-15s %18s" "------------" "----------" \ "-----"] foreach_in_collection lib_arc $lib_arcs { set fpin [get_attribute $lib_arc from_lib_pin] set tpin [get_attribute $lib_arc to_lib_pin] set sense [get_attribute $lib_arc sense] set from_lib_pin_name [get_attribute $fpin base_name] set to_lib_pin_name [get_attribute $tpin base_name] echo [format "%15s - %-15s %18s" \ $from_lib_pin_name $to_lib_pin_name \ $sense] } } pt_shell show_lib_arc -of_objects [get_timing_arcs -of_objects ffa] from_lib_pin to_lib_pin ------------ ---------- CP - D CP - D CP - Q CP - QN CD - Q sense ----setup_clk_rise hold_clk_rise rising_edge rising_edge clear_low get_lib_timing_arcs 221 CD - QN preset_low pt_shell show_lib_arc -of_objects mylib/AN2 from_lib_pin to_lib_pin ------------ ---------- A-Z B-Z sense ----positive_unate positive_unate pt_shell show_lib_arc -from mylib/AN2/A from_lib_pin to_lib_pin ------------ ---------- A-Z sense ----positive_unate SEE ALSO collections (2), filter_collection (2), foreach_in_collection (2), get_attribute (2), get_timing_arcs (2). get_lib_timing_arcs 222 get_libs Creates a collection of libraries loaded into PrimeTime. You can assign these libraries to a variable or pass them into another command. SYNTAX collection get_libs [-filter expression] [-quiet] [-regexp] [-nocase] [-exact] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -filter expression Filters the collection with expression. For any libraries that match patterns (or objects), the expression is evaluated based on the library’s attributes. If the expression evaluates to true, the library is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modify the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -of_objects objects Creates a collection of libraries that contain the specified objects. In this case, each object is either a named library cell or a library cell collection. -of_objects and patterns are mutually exclusive; you must specify one, but not both. patterns Matches library names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type lib. patterns and -of_objects are mutually exclusive; you must specify one, but not both. get_libs 223 DESCRIPTION The get_libs command creates a collection of libraries from those currently loaded into PrimeTime that match certain criteria. The command returns a collection if any libraries match the patterns and pass the filter (if specified). If no objects match the criteria, the empty string is returned. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression. Using rigid quoting with curly braces around regular expressions is recommended. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_libs command at the command prompt, or you can nest it as an argument to another command (for example, query_objects). In addition, you can assign the get_libs result to a variable. When issued from the command prompt, get_libs behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_libs provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_libs as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries all loaded libraries. Although the output looks like a list, it is just a display. Note that a complete listing of libraries is available using the list_libraries command. pt_shell get_libs * {"misc_cmos", "misc_cmos_io"} The following example shows that given a library collection, you can remove those libraries. Note that you cannot remove libraries if they are referenced by a design. pt_shell remove_lib [get_libs misc*] Removing library misc_cmos... Removing library misc_cmos_io... get_libs 224 SEE ALSO collections(2), filter_collection(2), list_libraries(2), query_objects(2), regexp(2), remove_lib(2); collection_result_display_limit(3). get_libs 225 get_license Obtains a license for a feature. SYNTAX int get_license feature_list list feature_list ARGUMENTS feature_list A list of features to be obtained. Refer to the Synopsys System Installation and Configuration Guide for a list of features supported by the current release, or determine from the key file all the features licensed at your site. DESCRIPTION Obtains a license for the named features. These features are checked out by the current user until remove_license is used or until the program is exited. get_license is valid only when Network Licensing is enabled. The list_licenses command provides a list of the features that you currently have checked out. For more information on get_license, refer to the Synopsys System Installation and Configuration Guide. EXAMPLES This example obtains the STAMP Compiler feature: pt_shell get_license STAMP-Compiler Checked out license ’STAMP-Compiler’ 1 SEE ALSO license_users (2), list_licenses (2), remove_license (2). get_license 226 get_nets Creates a collection of nets from the netlist. You can assign these nets to a variable or pass them into another command. SYNTAX collection get_nets [-hierarchical] [-filter expression] [-quiet] [-regexp] [nocase] [-exact] [-top_net_of_hierarchical_group] [-segments] [-boundary_type btype] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -hierarchical Searches for nets level-by-level relative to the current instance. The full name of the object at a particular level must match the patterns. The search is similar to the UNIX find command. For example, if there is a net block1/ muxsel, a hierarchical search would find it using "muxsel." You cannot use hierarchical with -of_objects. -filter expression Filters the collection with expression. For any nets that match patterns (or objects), the expression is evaluated based on the cell’s attributes. If the expression evaluates to true, the net is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -top_net_of_hierarchical_group Keep only the top net of a hierarchical group. When more than one hierarchical net of the same group is specified (local nets at various hierarchical levels of the same physical net), only the net closest to the top of the hierarchy is saved with the collection. In the case of multiple nets at the same level, the first net specified is kept. Although this option can be used when there get_nets 227 are multiple nets specified, it is best used in combination with -segments and with a single net. -segments Return all global segments for given nets. This modifies the initial search which matches patterns or objects. It is applied after filtering, but before the -top_net_of_hierarchical_group is determined. For each net, all global segments which are part of that net will be added to the result collection. Global net segments are all those physically connected across all hierarchical boundaries. Although this option can be used with other options and when there are multiple nets specified, it is best used with a single net. When combined with the -top_net_of_hierarchical_group option, you can isolate the highest net segment of a physical net. -boundary_type btype Specifies what to do when getting nets of boundary pins. This option requires the -of_objects option. Allowed values are lower, upper, and both, meaning the net inside the hierarchical block, outside the hierarchical block, or both nets, respectively. The option has no meaning for non-hierarchical pins. Note that The "upper" value is less useful, as getting pins of a hierarchical net will return the pin outside the hierarchical block, and a subsequent get_nets would find the upper hierarchical net. Using upper on a hierarchical pin is the same as omitting the option. -of_objects objects Creates a collection of nets connected to the specified objects. Each object is either a named pin, a pin collection, a named cell or cell collection. of_objects and patterns are mutually exclusive; you must specify one, but not both. In addition, you cannot use -hierarchical with -of_objects. patterns Matches net names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type net. patterns and -of_objects are mutually exclusive; you must specify one, but not both. DESCRIPTION The get_nets command creates a collection of nets in the current design, relative to the current instance that match certain criteria. The command returns a collection if any nets match the patterns or objects and pass the filter (if specified). If no objects matched the criteria, the empty collection is returned. If any patterns (or objects) fail to match any objects and the current design is not linked, the design automatically links. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression; use rigid quoting with curly braces around regular expressions. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_nets command at the command prompt, or you can nest it as an get_nets 228 argument to another command (for example, query_objects). In addition, you can assign the get_nets result to a variable. When issued from the command prompt, get_nets behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_nets provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_nets as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries the nets that begin with ’NET’ in block ’block1’. Although the output looks like a list, it is just a display. pt_shell get_nets block1/NET {"block1/NET1QNX", "block1/NET2QNX"} The following example shows that with a collection of pins, you can query the nets connected to those pins. pt_shell current_instance block1 block1 pt_shell set pinsel [get_pins {o_reg1/QN o_reg2/QN}] {"o_reg1/QN", "o_reg2/QN"} pt_shell query_objects [get_nets -of_objects $pinsel] {"NET1QNX", "NET2QNX"} This example shows how to use the -top_net_of_hierarchical_group and -boundary_type options. Given the following circuit: u1 u2 -----------------+ +------------------- | | u1/Z -- net5 ---+--- topnet ---+--- net7 -- u1/A | | -----------------+ +------------------- there are hierarchical cells u1 and u2 at this level, connected by a net topnet. Within u1 is a pin u1/Z driving net5, and withing u2 is a pin u1/A being driven by net7. These three nets are physically the same net. Assume these are the only nets get_nets 229 in the design. Notice the difference in the results of the following two get_nets commands: pt_shell get_nets * -hierarchical {"topnet", "u1/net5", "u2/net7"} pt_shell get_nets * -hierarchical -top_net_of_hierarchical_group {"topnet"} Assume that at the top level, topnet is connected to pins u2/in and u1/out. Here are some examples of -boundary_type. Notice now in this case, the "upper" type does not add value. pt_shell get_nets -of_objects u2/in {"topnet"} pt_shell get_nets -of_objects u2/in -boundary_type upper {"topnet"} pt_shell get_nets -of_objects u2/in -boundary_type lower {"u2/net7"} pt_shell get_nets -of_objects u2/in -boundary_type both {"u2/net7", "topnet"} pt_shell get_nets -boundary lower -of_objects \ [get_pins -of_objects [get_nets topnet]] {"u1/net5", "u2/net7"} SEE ALSO collections(2), filter_collection(2), get_pins(2), link_design(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_nets 230 get_nets Creates a collection of nets from the netlist. You can assign these nets to a variable or pass them into another command. SYNTAX collection get_nets [-hierarchical] [-filter expression] [-quiet] [-regexp] [nocase] [-exact] [-top_net_of_hierarchical_group] [-segments] [-boundary_type btype] patterns | -of_objects objects stringexpression list objects list patterns ARGUMENTS -hierarchical Searches for nets level-by-level relative to the current instance. The full name of the object at a particular level must match the patterns. The search is similar to the UNIX find command. For example, if there is a net block1/ muxsel, a hierarchical search would find it using "muxsel." You cannot use hierarchical with -of_objects. -filter expression Filters the collection with expression. For any nets that match patterns (or objects), the expression is evaluated based on the cell’s attributes. If the expression evaluates to true, the net is included in the result. -quiet Suppresses warning and error messages if no objects match. Syntax error messages are not suppressed. -regexp Views the patterns argument as real regular expressions rather than simple wildcard patterns. Also, modifies the behavior of the =~ and !~ filter operators to compare with real regular expressions rather than simple wildcard patterns. -regexp and -exact are mutually exclusive. -nocase When combined with -regexp, makes matches case-insensitive. You can use nocase only when you also use -regexp. -exact Disables simple pattern matching. This is used when searching for objects that contain the * and ? wildcard characters. -exact and -regexp are mutually exclusive. -top_net_of_hierarchical_group Keep only the top net of a hierarchical group. When more than one hierarchical net of the same group is specified (local nets at various hierarchical levels of the same physical net), only the net closest to the top of the hierarchy is saved with the collection. In the case of multiple nets at the same level, the first net specified is kept. Although this option can be used when there get_nets 231 are multiple nets specified, it is best used in combination with -segments and with a single net. -segments Return all global segments for given nets. This modifies the initial search which matches patterns or objects. It is applied after filtering, but before the -top_net_of_hierarchical_group is determined. For each net, all global segments which are part of that net will be added to the result collection. Global net segments are all those physically connected across all hierarchical boundaries. Although this option can be used with other options and when there are multiple nets specified, it is best used with a single net. When combined with the -top_net_of_hierarchical_group option, you can isolate the highest net segment of a physical net. -boundary_type btype Specifies what to do when getting nets of boundary pins. This option requires the -of_objects option. Allowed values are lower, upper, and both, meaning the net inside the hierarchical block, outside the hierarchical block, or both nets, respectively. The option has no meaning for non-hierarchical pins. Note that The "upper" value is less useful, as getting pins of a hierarchical net will return the pin outside the hierarchical block, and a subsequent get_nets would find the upper hierarchical net. Using upper on a hierarchical pin is the same as omitting the option. -of_objects objects Creates a collection of nets connected to the specified objects. Each object is either a named pin, a pin collection, a named cell or cell collection. of_objects and patterns are mutually exclusive; you must specify one, but not both. In addition, you cannot use -hierarchical with -of_objects. patterns Matches net names against patterns. Patterns can include the wildcard characters "*" and "?" or regular expressions, based on the -regexp option. Patterns can also include collections of type net. patterns and -of_objects are mutually exclusive; you must specify one, but not both. DESCRIPTION The get_nets command creates a collection of nets in the current design, relative to the current instance that match certain criteria. The command returns a collection if any nets match the patterns or objects and pass the filter (if specified). If no objects matched the criteria, the empty collection is returned. If any patterns (or objects) fail to match any objects and the current design is not linked, the design automatically links. Regular expression matching is the same as in the Tcl regexp command. When using regexp, take care in the way you quote the patterns and filter expression; use rigid quoting with curly braces around regular expressions. Regular expressions are always anchored; that is, the expression is assumed to begin matching at the beginning of an object name and end matching at the end of an object name. You can widen the search simply by adding ".*" to the beginning or end of the expressions as needed. You can use the get_nets command at the command prompt, or you can nest it as an get_nets 232 argument to another command (for example, query_objects). In addition, you can assign the get_nets result to a variable. When issued from the command prompt, get_nets behaves as though query_objects had been called to display the objects in the collection. By default, a maximum of 100 objects is displayed; you can change this maximum using the variable collection_result_display_limit. The "implicit query" property of get_nets provides a fast, simple way to display cells in a collection. However, if you want the flexibility provided by the query_objects options (for example, if you want to display the object class), use get_nets as an argument to query_objects. For information about collections and the querying of objects, see the collections man page. EXAMPLES The following example queries the nets that begin with ’NET’ in block ’block1’. Although the output looks like a list, it is just a display. pt_shell get_nets block1/NET {"block1/NET1QNX", "block1/NET2QNX"} The following example shows that with a collection of pins, you can query the nets connected to those pins. pt_shell current_instance block1 block1 pt_shell set pinsel [get_pins {o_reg1/QN o_reg2/QN}] {"o_reg1/QN", "o_reg2/QN"} pt_shell query_objects [get_nets -of_objects $pinsel] {"NET1QNX", "NET2QNX"} This example shows how to use the -top_net_of_hierarchical_group and -boundary_type options. Given the following circuit: u1 u2 -----------------+ +------------------- | | u1/Z -- net5 ---+--- topnet ---+--- net7 -- u1/A | | -----------------+ +------------------- there are hierarchical cells u1 and u2 at this level, connected by a net topnet. Within u1 is a pin u1/Z driving net5, and withing u2 is a pin u1/A being driven by net7. These three nets are physically the same net. Assume these are the only nets get_nets 233 in the design. Notice the difference in the results of the following two get_nets commands: pt_shell get_nets * -hierarchical {"topnet", "u1/net5", "u2/net7"} pt_shell get_nets * -hierarchical -top_net_of_hierarchical_group {"topnet"} Assume that at the top level, topnet is connected to pins u2/in and u1/out. Here are some examples of -boundary_type. Notice now in this case, the "upper" type does not add value. pt_shell get_nets -of_objects u2/in {"topnet"} pt_shell get_nets -of_objects u2/in -boundary_type upper {"topnet"} pt_shell get_nets -of_objects u2/in -boundary_type lower {"u2/net7"} pt_shell get_nets -of_objects u2/in -boundary_type both {"u2/net7", "topnet"} pt_shell get_nets -boundary lower -of_objects \ [get_pins -of_objects [get_nets topnet]] {"u1/net5", "u2/net7"} SEE ALSO collections(2), filter_collection(2), get_pins(2), link_design(2), query_objects(2), regexp(2); collection_result_display_limit(3). get_nets 234 get_noise_violation_sources Creates a collection of noise violation sources for custom reporting and other processing. You can assign these timing arcs to a variable and get the desired attribute for further processing. SYNTAX int get_noise_violation_sources [-above] [-below] [-low] [-high] [-nworst_endpoints pin_count] [-max_sources_per_endpoint pin_count] [-slack_type slack_type] [-all_violators] [object_list] list object_list ARGUMENTS -above Performs the reporting only above the rails. If this option is combined with -low, it reports for the noise bumps above the low rail. If it is combined with -high, it reports the noise bumps above the high rail. Otherwise, it reports the noise bumps above the high rail and above the low rail. -below Performs the reporting only below the rails. If this option is combined with -low, it reports for the noise bumps below the low rail. If it is combined with -high, it reports the noise bumps below the high rail. Otherwise, it reports the noise bumps below the high rail and below the low rail. -low Performs the reporting only for the low rail. If this option is combined with -above, it reports the noise bumps above the low rail. If it is combined with -below, it reports the noise bumps below the low rail. Otherwise, it reports the noise bumps for both below and above the low rail. -high Performs the reporting only for the high rail. If this option is combined with -above, it reports the noise bumps above the high rail. If it is combined with -below, it reports the noise bumps below the high rail. Otherwise, it reports the noise bumps for both below and above the high rail. -nworst_endpoints pin_count Specifies the number of endpoint pins to be reported. Any number greater than 1 is accepted; the default value is 1. -max_sources_per_endpoint pin_count Specifies the number of violation source pins per endpoint to be reported. get_noise_violation_sources 235 Any number greater than 1 is accepted; the default value is 1. -slack_type slack_type Specifies the type of slack to be used. Valid values are area, height, and area_percent. A slack_type of area reports slack as the voltage margin multiplied by the noise bump width. The voltage margin is defined by the noise bump height and noise immunity curves or DC noise margin. This setting is the default. A slack_type of height reports noise slack as the voltage margin. A slack_type of area_percent reports noise slack as the percentage of the noise constraint area. The noise constraint area is computed by multiplying the noise height constraint by the noise bump width. The default is area. -all_violators Indicates that violating source pins (negative slack) for all violating endpoints are to be shown. object_list Specifies the load pins for which the noise reporting is performed. If no pin is specified, reporting is performed on the entire design. DESCRIPTION Provides a collection of noise violation source pins for failing noise endpoints of the current design. EXAMPLES The following example creates a collection of the worst violation source for theworst endpoint in the current design and assign it to a variable, viol_pins. pt_shell set viol_pins [get_noise_violation_sources] The following example creates a collection of maximum 10 violation sources for the endpoint ffa/Q in the above the low rail. pt_shell get_noise_violation_sources -above -low -max_sources_per_endpoint 10