Encounter™ User Guide Product Version 4.1.5 May 2005 2002–2005 Cadence Design Systems, Inc. All rights reserved. Printed in the United States of America. Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks, contact the corporate legal department at the address shown above or call 800.862.4522. All other trademarks are the property of their respective holders. Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this publication may violate copyright, trademark, and other laws. Except as specified in this permission statement, this publication may not be copied, reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants you permission to print one (1) hard copy of this publication subject to the following conditions: 1. The publication may be used solely for personal, informational, and noncommercial purposes; 2. The publication may not be modified in any way; 3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other proprietary notices and this permission statement; and 4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be discontinued immediately upon written notice from Cadence. Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence’s customer in accordance with, a written agreement between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information. Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor. Encounter User Guide Contents About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How This Manual Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 23 24 25 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Feature Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . First Encounter Ultra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nano Encounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nano Encounter Demand-Based Savings (DBS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . NanoRoute Ultra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SoC Encounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . First Encounter Global Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SOC Encounter Global Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feature License Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prototyping with SoC Encounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 28 29 29 30 30 31 31 32 35 2 Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Generating a Technology File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Technology Information Using LEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Technology Information Using OpenAccess . . . . . . . . . . . . . . . . . . . . . . . . Preparing Physical Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using LEF to Create Physical Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating OpenAccess Physical Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unsupported LEF and DEF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unsupported LEF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unsupported DEF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 3 38 38 38 38 38 39 39 39 39 Product Version 4.1.5 Encounter User Guide Preparing the Design Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating the I/O Assignment File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an I/O Assignment File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Rule-Based I/O Assignment File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I/O Pad and Pin Assignment Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Area I/O Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing Timing Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encrypting Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing Stamp Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supported SDC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraint Reader Supported Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading PKS Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing Capacitance Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing Data for Delay Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing Data for Crosstalk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing Data in the Timing Closure Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 42 42 46 46 49 50 50 51 51 52 59 59 60 60 60 60 61 3 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Installing Encounter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting the Run-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the Encounter Software in 64-bit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the Encounter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out an Encounter License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Multi-Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Super Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encounter Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Name Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command-Line Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 4 64 64 64 64 65 65 66 68 68 69 69 70 70 72 Product Version 4.1.5 Encounter User Guide Initialization Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online Documentation and Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Form Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Text Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 74 74 74 4 Importing and Exporting Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Data before Importing a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Flat Verilog Netlist from a DEF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended DEF Import Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternative DEF Import Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Previously-Existing Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Configurations Files from the Command Line . . . . . . . . . . . . . . . . . . . . . . . Loading Configuration Files from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Assign Nets from a Verilog Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Tile Cell Design Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving and Restoring Design Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restoring an OpenAccess Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving an OpenAccess Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restoring a Design Created with Encounter 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing and Exporting Design Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading a Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Floorplan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Placement File Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading an I/O Assignment File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading an FSDB File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading an OpenAccess Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving a Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving Floorplan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing and Exporting TDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting OpenAccess Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 5 78 78 78 79 79 81 82 82 82 83 85 86 87 87 87 88 88 88 88 89 90 90 90 90 90 91 91 92 Product Version 4.1.5 Encounter User Guide Merging GDSII Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Merging GDS Files Using the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Merging GDS Files Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GDSII Map File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Column Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating Files during an Encounter Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Flip Chip and Area I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flip Chip Flow in Encounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . APD Bump Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bump Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Area IO Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Peripheral IO Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tile Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manually Assigning Signals to Tile Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calculate Core Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reducing Data Size for APD Import (Bypass Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Bumps to I/O Driver Cells (Hierarchical Area I/O Flow) . . . . . . . . . . . . . . . . . . Splitting Wires in Metal Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing the Package Routing Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross Probing Bumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Differentiating Area I/O and Peripheral I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Swapping Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Differential Routing to Signal Bumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples and Report Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IO_FILE Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LEF and CML Example Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Feasibility Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tile Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 93 93 93 94 95 96 6 100 101 101 102 103 108 108 115 117 120 121 127 127 127 128 128 130 131 131 132 134 136 136 137 138 139 Product Version 4.1.5 Encounter User Guide Tile Libraries and LEF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Useful Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 6 Partitioning the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Top-down Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bottom-up Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Partitions and Blackboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Blackboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Multiple Instantiated Partitions and Blackboxes . . . . . . . . . . . . . . . . . . . Changing Partition Clone Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Rectilinear Partitions and Blackboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Core-to-I/O Distance for Partition Cuts . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Hierarchical Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Blackbox Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Partition Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Pins on Rectilinear Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refining Pin Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resolving Pin Overlaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Snapping Pins to the Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations of Pin Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Partition Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inserting Feedthroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inserting Feedthrough Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inserting Routing Feedthroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating the Wire Crossing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading the Wire Crossing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estimating the Routing Channel Width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running the Partition Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restoring the Top-Level Floorplan with Partition Data . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 7 146 147 148 151 155 156 158 160 161 162 163 164 166 166 167 170 170 175 176 176 176 177 178 180 183 186 186 190 192 194 Product Version 4.1.5 Encounter User Guide Concatenating Netlist Files of a Partitioned Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unpartitioning with Routing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 196 197 197 7 Interface Logic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Commands for Generating and Using ILMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating ILMs With Different Pin Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating ILMs With Different Latch Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Top-Level Partitioning by Identifying the Interface Logic . . . . . . . . . . . . . . . Generating ILMs for a Partition Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Timing Analysis Using ILMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 202 203 207 207 211 212 213 8 Floorplanning the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Floorplanning Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module Constraint Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Target Utilization Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effective Utilization Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calculating Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard Row Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grouping Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the Bounding Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pin Snapping on Resized Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moving a Group of Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Swapping Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Pin Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Relative Floorplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Orientation Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 8 216 217 218 220 221 223 224 225 226 227 228 228 228 229 229 235 235 Product Version 4.1.5 Encounter User Guide Instance Place Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving and Restoring Relative Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Module Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving and Loading Floorplan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 237 240 242 254 9 Power Planning and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading, Saving, and Updating Special Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Ring with User Defined Coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Global Net Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connecting Ring Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixing LEF MINIMUMCUT Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixing LEF Minimum Spacing Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Stripes to Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Power Planning (APP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the IP Block Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Design Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instantiating a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Differential Routing to Signal Bumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 257 257 258 258 259 261 261 261 262 264 264 265 266 266 267 10 Multiple Supply Voltages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tools That Do Not Support MSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Model for MSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inserting Voltage Level Shifters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Rectilinear Power Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 9 270 270 270 270 270 282 283 Product Version 4.1.5 Encounter User Guide 11 Placing the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Placement Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Area I/O Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Spare Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Cell Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Placement Blockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running JTAG Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Amoeba Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running ECO Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Window Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Cell Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reordering Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Filler Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Well-Tap Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Fillers and Well-Taps to MSV Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Endcap Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Filler Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Logical Tie-Off Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing-Driven Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Netlist Clustering Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-Placement Congestion Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving and Loading Placement Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 287 288 289 290 291 292 293 294 295 296 296 308 309 309 310 310 311 312 313 314 314 12 Synthesizing Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding CTS Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manual CTS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic CTS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How CTS Calculates Skew Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Improving Postroute Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 10 316 316 317 317 318 322 324 Product Version 4.1.5 Encounter User Guide Specifying Macro Model Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grouping Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing Hierarchical Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module Placement Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Designs with Tight Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Balancing Pins for Macro Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing Model Requirement for Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding Post-CTS Clock Tree Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the ckECO Command for Post-CTS Clock Tree Optimization . . . . . . . . . . . . Support for Local Skew Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Modes for the ckECO Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a SPEF File with the ckECO Command for RC Estimation . . . . . . . . . . . . . . Running Post-CTS Optimization with the ckECO Command . . . . . . . . . . . . . . . . . . Guidelines for Using the ckECO Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Clock Tree Specification File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of a Clock Tree Specification File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing Constraint File Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming Attributes Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NanoRoute Attribute Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Macro Model Data Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Grouping Data Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock-Tree Topology Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Gated CTS Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log File Headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 326 327 329 329 329 329 329 329 330 330 330 331 332 333 333 335 336 337 338 339 339 340 349 13 Editing Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Bindkeys for Wire Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bindkeys Used to Open Forms or Change Modes . . . . . . . . . . . . . . . . . . . . . . . . . . Bindkeys Used in Auto Query Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bindkeys and Shortcuts Used in Add Wire Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . Bindkeys Used in Stretch Wire Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 11 352 353 353 353 353 354 354 355 Product Version 4.1.5 Encounter User Guide Bindkeys Used to Change Vias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moving Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Mouse to Move Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a Wire for a Single Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Wires for Multiple Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Wires that Automatically Extend to a Target . . . . . . . . . . . . . . . . . . . . . . . . . Using Override to Add Wire Groups with Multiple Widths and Spacing . . . . . . . . . . Cutting Shielding Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trimming Antennas on Selected Stripes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Wire Width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixing Maximum Wire Width Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Duplicating Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stretching Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Wire Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Splitting and Merging Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Vias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Vias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reshaping Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Cell Blockage Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Wires with CCAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running CCAR in Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running CCAR in Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Using Trial Route for Congestion and Timing Analysis . . . . . 373 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing A Flat Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing a Partitioned Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading and Saving Route Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing Route Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Congestion Markers in the Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Congestion Distribution Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Improving Route Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 12 355 355 355 356 357 358 359 360 361 362 363 363 364 364 365 365 366 366 367 368 369 369 370 374 374 375 375 378 378 379 381 387 Product Version 4.1.5 Encounter User Guide Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Wire Overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 15 Routing Your Design With NanoRoute . . . . . . . . . . . . . . . . . . . . . . . . 391 NanoRoute Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NanoRoute in the Encounter Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Your LEF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking for Problems with Cells, Pins, and Vias . . . . . . . . . . . . . . . . . . . . . . . . . . Generating Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NanoRoute Use Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running NanoRoute in Native Mode with Encounter Menu Commands and Forms Running NanoRoute in Native Mode with Encounter Text Commands . . . . . . . . . . Running NanoRoute in Batch Mode From Encounter Software . . . . . . . . . . . . . . . . Running NanoRoute in Standalone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using NanoRoute Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Attributes and Options Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accelerating Routing with Multi-Threading and Super-Threading . . . . . . . . . . . . . . . . . When to Accelerate Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Super-Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . License Considerations for Super-Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Super-Threading Log File Excerpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Acceleration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Following a Basic Routing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Encounter Text Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Encounter GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Congestion Analysis Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Congestion Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interpreting the Congestion Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Timing-Driven Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 13 394 394 396 397 397 397 398 398 401 401 401 402 403 404 405 407 407 408 409 411 412 413 413 414 417 417 418 419 422 422 Product Version 4.1.5 Encounter User Guide Using the CTE and Native NanoRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the CTE and Standalone NanoRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the NanoRoute Timing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Another Timing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Attributes for Clock Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing the Clock Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Postroute Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preventing and Repairing Crosstalk Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Crosstalk Prevention Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running ECO Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ECO Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ECO Routing in Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NanoRoute ECO Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluating Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Violations on Upper Metal Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Violations in Timing-Driven Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Violated Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Additional Strategies to Repair Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimizing Vias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Via Optimization Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimizing Vias in Selected Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Shielded Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Shielded Routing Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About the Shielding Statistics Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NanoRoute Shielding Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Wide Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Nondefault Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repairing Process Antenna Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Diodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repairing Violations on Cut Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Making the Calculations More Conservative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NanoRoute Antenna Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 14 422 423 425 426 427 427 428 428 429 431 433 433 434 434 435 439 441 442 442 443 443 444 445 445 447 447 449 450 450 452 452 452 453 453 454 454 Product Version 4.1.5 Encounter User Guide Using a Design Flow that Includes Astro or Apollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 16 Optimizing Metal Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . After You Complete Adding Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Metal Fill Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying the Active Spacing Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Floating Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Parameters for Floating and Tied-off Metal Fill . . . . . . . . . . . . . . . . . . . . Adding Metal Fill Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trimming Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Metal Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 460 460 461 462 463 464 465 469 469 470 470 17 Timing Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deriving Timing Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing Timing Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resolving Multiple Path Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logic Push-Down of Multi-Point False Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Budgeting Clock Latency in Propagated Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calculating Timing Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customizing the Budget Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying The Timing Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading the Budget Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paths With Negative Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paths With Positive Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraints Support in Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 15 472 474 476 476 479 480 483 485 488 490 492 494 498 Product Version 4.1.5 Encounter User Guide 18 RC Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Native RC Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating a Capacitance Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading a Capacitance Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Correlating Native Extraction With Sign-Off Extraction . . . . . . . . . . . . . . . . . . . . . . Sign-Off Extraction Using Fire & Ice QX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inputs for Fire & Ice Sign-Off Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 503 503 504 506 512 513 522 523 19 Calculating Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ECSM Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using IPDB-based ECSM Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delay Calculation Modes and Related Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choosing A Delay Calculation Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Delay Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 526 526 527 527 529 530 530 20 Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531 Timing Analysis Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading Timing Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Different Timing Libraries for Setup And Hold Checks . . . . . . . . . . . . . . Resolving Discrepancies in Timing Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraints Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 16 532 533 535 535 535 536 536 536 540 Product Version 4.1.5 Encounter User Guide Calculating Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining RC Corners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Timing Analysis Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition of Early and Late Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single Timing Analysis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Best-Case Worst-Case (BC-WC) Timing Analysis Mode . . . . . . . . . . . . . . . . . . . . . On-Chip Variation (OCV) Timing Analysis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Reconvergence Pessimism Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing Timing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resolving Buffer-Related Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Blackbox What-If Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing Models Supported for What-If Timing Analysis . . . . . . . . . . . . . . . . . . . . . . Using the What-If Timing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 542 544 544 546 550 561 568 574 575 576 577 577 580 21 Timing Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Pre-CTS Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimizing in Pre-CTS Mode for the First Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rapid Timing Optimization for Design Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . Pre-CTS Timing Optimization Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incremental Pre-CTS Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Default Settings in Pre-CTS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Pre-CTS Optimization from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Post-CTS Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Correcting Violations in Post-CTS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-CTS Timing Optimization Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incremental Post-CTS Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Default Settings in Post-CTS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Post-CTS optDesign from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Post-Route Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Correcting Violations in Post-Route Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 17 584 585 585 586 587 587 588 588 589 590 591 591 592 593 594 595 595 596 Product Version 4.1.5 Encounter User Guide Correcting Signal Integrity Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597 Changing Default Settings in Post-Route Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 Running Post-Route Optimization from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 Performing Post-CTS and Post-Route Optimization with Cadence PKS . . . . . . . . . . . . 599 Running PKS with Text Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 Running PKS from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600 Fine-Tuning Cadence PKS Optimization from the GUI . . . . . . . . . . . . . . . . . . . . . . 600 optDesign Parameter Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 Useful Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 Pre-CTS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 Post-CTS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603 Controlling Useful Skew Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603 Optimizing Timing Using a Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 Performing Timing Optimization When the Constraint File Includes the set_case_analysis Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 Reducing Leakage Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 Troubleshooting Leakage Power Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 Using Cell Footprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 Viewing Added Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 Timing Optimization Mode Defaults For Effort Levels . . . . . . . . . . . . . . . . . . . . . . . . . . 607 Low Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 Medium Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609 High Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611 22 Interactive ECO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Instance Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Buffer Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming Conventions for Interactive ECO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 18 614 614 614 614 616 618 619 620 Product Version 4.1.5 Encounter User Guide Comparing Physical Design Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 23 Analyzing and Repairing Crosstalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Crosstalk Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing Crosstalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repairing Crosstalk Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Incremental Crosstalk Analysis and Repair . . . . . . . . . . . . . . . . . . . . . . . . . Performing Sign-Off Crosstalk Analysis and Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 628 628 628 629 630 631 631 632 24 Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power Analysis Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Macro Current Source Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Power Analysis with Encounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Power Analysis in Simple Estimate Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estimation Parameter File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Power Analysis with VoltageStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VoltageStorm Power Grid Analysis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running VoltageStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Power Pad Location File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Auto Fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Decoupling Capacitor Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the Power Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Power Analysis Results with Debussy Waveform . . . . . . . . . . . . . . . . . . . . . . . Saving Rail Analysis Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power/Rail Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 19 635 635 636 637 638 639 639 641 642 643 643 643 644 646 647 647 648 649 649 Product Version 4.1.5 Encounter User Guide Power Graph Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instance Average Power Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Net Average Power Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instance Power Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instance Voltage File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boundary Voltage File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Display Setting File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calculating EM Values for Wires and Vias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log of Physical Connectivity to Power Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operating Voltage Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Power Consumption for Specified Pins or Ports . . . . . . . . . . . . . . . . . . . . . . 650 651 651 652 652 653 654 655 655 656 656 25 Verifying Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657 Verifying Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Text Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Metal Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Text Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Text Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Process Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Text Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample Process Antenna Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying AC Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Text Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 20 658 658 658 658 659 659 659 659 661 661 661 661 662 662 662 662 663 665 665 665 666 Product Version 4.1.5 Encounter User Guide Viewing Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Violation Browser Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Text Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clearing Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Violation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Text Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667 667 667 668 669 669 669 669 A Creating the ICT File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warnings and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invalid Layer Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample ICT File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B ECO Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pre-Mask ECO Changes from an ECO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pre-Mask ECO Changes from a New Verilog File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pre-Mask ECO Changes from a New DEF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May 2005 672 672 672 672 672 672 672 683 21 696 696 696 698 698 699 699 702 702 702 703 705 705 Product Version 4.1.5 Encounter User Guide Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pre-Mask ECO Changes from New OpenAccess Data . . . . . . . . . . . . . . . . . . . . . . . . . Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-Mask ECO Changes from a New Verilog Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-Mask Gate Array Style ECO from a New Verilog Netlist . . . . . . . . . . . . . . . . . . . . Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706 706 709 709 710 710 713 713 714 714 718 718 720 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723 May 2005 22 Product Version 4.1.5 Encounter User Guide About This Manual The Cadence® Encounter™ family of products provides an integrated solution for an RTL-toGDSII design flow. This manual describes how to install, configure, and use Encounter to implement digital integrated circuits. Audience This manual is written for experienced designers of digital integrated circuits. Such designers must be familiar with design planning, placement and routing, block implementation, chip assembly, and design verification. Designers must also have a solid understanding of UNIX and Tcl/Tk programming. How This Manual Is Organized The chapters in this manual are organized to follow the flow of tasks through the design process. Because of variations in design implementations and methodologies, the order of the chapters will not correspond to any specific design flow. Each chapter focuses on the concepts and tasks related to the particular design phase or topic being discussed. In addition, the following sections provide prerequisite information for using the Encounter software: ■ Chapter 2, “Data Preparation” Describes how to prepare data for import into the Encounter software. ■ Chapter 3, “Getting Started” Describes how to install, set up, and run the Encounter software, and use the online Help system. May 2005 23 Product Version 4.1.5 Encounter User Guide About This Manual Conventions Used in This Manual This section describes the typographic and syntax conventions used in this manual. text Indicates text that you must type exactly as shown. For example: analyze_connectivity -analyze all text Indicates information for which you must substitute a name or value. In the following example, you must substitute the name of a specific file for configfile: wroute -filename configfile text [ ] Indicates the following: ■ Text found in the graphical user interface (GUI), including form names, button labels, and field names ■ Terms that are new to the manual, are the subject of discussion, or need special emphasis ■ Titles of manuals Indicates optional arguments. In the following example, you can specify none, one, or both of the bracketed arguments: command [-arg1] [arg2 value] [ | ] Indicates an optional choice from a mutually exclusive list. In the following example, you can specify any of the arguments or none of the arguments, but you cannot specify more than one: command [arg1 | arg2 | arg3 | arg4] { | } Indicates a required choice from a mutually exclusive list. In the following example, you must specify one, and only one, of the arguments: command {arg1 | arg2 | arg3} May 2005 24 Product Version 4.1.5 Encounter User Guide About This Manual {[ ] [ ]} Indicates a required choice of one or more items in a list. In the following example, you must choose one argument from the list, but you can choose more than one: command {[arg1] [arg2] [arg3]} { } Indicates curly braces that must be entered with the command syntax. In the following example, you must type the curly braces: command arg1 {x y} ... Indicates that you can repeat the previous argument. . . . Indicates an omission in an example of computer output or input. Command – Subcommand Indicates a command sequence, which shows the order in which you choose commands and subcommands from the GUI menu. In the following example, you choose Floorplan from the menu, then Power Planning from the submenu, and then Add Rings from the displayed list: Floorplan – Power Planning – Add Rings This sequence opens the Add Rings form. Related Documents For more information about the Encounter family of products, see the following documents. You can access these and other Cadence documents with the CDSDoc online documentation system. ■ Encounter Menu Reference Manual Provides information specific to the forms and commands available from the Encounter graphical user interface. ■ Encounter Database Access Command Reference Lists all of the Encounter database access commands and provides a brief description of syntax and usage. ■ Encounter Timing Closure Guide May 2005 25 Product Version 4.1.5 Encounter User Guide About This Manual Addresses issues related to timing closure for challenging designs. It presents a recommended task flow and provides tips on how to resolve or avoid common timing closure problems typically found in a design. ■ Encounter Known Problems and Solutions Describes important Product Change Requests (PCRs) for the Encounter family of products, including solutions for working around known problems. ■ Encounter Library Development Guide Describes library development guidelines for the independent tools that make up the Encounter family of products. ■ Encounter Text Command Reference Describes the Encounter text commands, including syntax and examples. ■ What’s New in Encounter Provides information about new and changed features in this release of the Encounter family of products. ■ README file Contains installation, compatibility, and other prerequisite information, including a list of product change requests (PCRs) that were resolved in this release. You can read this file online at downloads.cadence.com. For a complete list of documents provided with this release, see the CDSDoc library. 5/6/05 May 2005 26 Product Version 4.1.5 Encounter User Guide 1 Overview The Cadence® Encounter™ family of products provides a variety of digital solutions for nanometer design. This chapter provides a brief overview of the product features and the physical prototyping design flow using Encounter software. This chapter presents the following topics: ■ Feature Summary on page 28 ❑ First Encounter Ultra on page 28 ❑ Nano Encounter on page 29 ❑ Nano Encounter Demand-Based Savings (DBS) on page 29 ❑ NanoRoute Ultra on page 30 ❑ SoC Encounter on page 30 ❑ First Encounter Global Physical Synthesis on page 31 ❑ SOC Encounter Global Physical Synthesis on page 31 ■ Feature License Matrix on page 32 ■ Prototyping with SoC Encounter on page 35 May 2005 27 Product Version 4.1.5 Encounter User Guide Overview Feature Summary The Encounter family consists of the following products: ■ First Encounter® Ultra silicon virtual prototyping solution ■ Nano Encounter™ implementation system for flat designs ■ Nano Encounter Demand-Based Savings (DBS) system ■ SoC Encounter™ hierarchical RTL-to-GDSII physical implementation solution ■ NanoRoute™ Ultra SoC routing solution ■ First Encounter® Global Physical Synthesis ■ SoC Encounter™ Global Physical Synthesis First Encounter Ultra The First Encounter Ultra product includes the following features: ■ RTL synthesis Creates a gate-level netlist from Register Transfer Language (RTL) input. ■ Virtual prototyping and placement Provides quick feedback on the design performance. With this feature, you first create a block-and-cell placement, then perform trial routing, analyze timing, and refine the design to meet your specifications. ■ Hierarchical partitioning and block placement Lets you create a hierarchical design consisting of a top-level floorplan that contains blocks you implement separately. At the top level you define blocks, analyze congestion and timing, and refine the design as needed. The system automatically creates timing budgets and optimized pin locations to use in physical implementation. ■ Timing optimization Provides in-place optimization, which improves timing by inserting buffers and resizing gates, without changing the design’s logic. Includes a physical synthesis solution to close timing for difficult blocks. May 2005 28 Product Version 4.1.5 Encounter User Guide Overview Nano Encounter The Nano Encounter product includes the following features for flat design flows: ■ Virtual prototyping and placement ■ Physical synthesis optimization Note: You cannot perform RTL synthesis. ■ WRoute router Provides traditional grid-based global and detailed routing of signal and clock nets. ■ Power router Provides the ability to create power rings and stripes, and perform power routing. ■ NanoRoute router Provides high-speed graph-based global and detailed routing for large-capacity designs. ■ Geometry, connectivity, and antenna verification ■ Signal wire editing ■ Block antenna abstract creation ■ GDSII generation An optional Route Accelerator license provides multi-thread capability that lets you run WRoute and NanoRoute on multiple CPUs. Nano Encounter Demand-Based Savings (DBS) The Nano Encounter DBS product is a cost-saving alternative to Nano Encounter with all of the major features of Nano Encounter for smaller designs. Each Nano Encounter DBS license supports designs with up to 300,000 placeable instances (excluding filler cells). If your design grows beyond that limit, Encounter can check out additional Nano Encounter DBS licenses to support the larger design. The Nano Encounter DBS user interface provides access to all of the major Nano Encounter components, including NanoRoute, WRoute, SRoute, PKS, and ClockWise. However, except for WRoute, the interface does not support use of these tools in standalone mode, and it does not support the Coyote field solver. Additionally, support for multi-threading with Nano Encounter DBS requires a separate Route Accelerator license for each additional thread. May 2005 29 Product Version 4.1.5 Encounter User Guide Overview NanoRoute Ultra The NanoRoute Ultra product is a self-contained, block-level and top-level routing solution for system-on-chip (SoC) designs. It has the same features as Nano Encounter, except for virtual prototyping and placement. SoC Encounter The SoC Encounter product is a full hierarchical floorplanning and routing solution. It provides a broad spectrum of features, including the following features contained in First Encounter Ultra and Nano Encounter: ■ RTL synthesis ■ Virtual prototyping and placement ■ Hierarchical partitioning and block placement ■ Timing optimization ■ Virtual prototyping and placement ■ Physical synthesis optimization ■ WRoute router ■ Power router ■ NanoRoute router ■ Geometry, connectivity, and antenna verification ■ Signal wire editing ■ Block antenna abstract creation ■ GDSII generation SoC Encounter also includes the following feature, which is not included in the other Encounter products: ■ Sign-off signal integrity The CeltIC™ crosstalk analyzer for cell-based design prevents, calculates, and repairs crosstalk noise caused by interconnect coupling. This tool can also calculate and repair glitch noise and the delay effects of noise for static timing analysis. May 2005 30 Product Version 4.1.5 Encounter User Guide Overview SoC Encounter provides an easy upgrade path from the Silicon Ensemble® family, with legacy support. First Encounter Global Physical Synthesis First Encounter Global Physical Synthesis consists of all the features of First Encounter Ultra plus the added technology of Global Physical Synthesis to support a design flow from RTL to placed gates. SOC Encounter Global Physical Synthesis SOC Encounter Global Physical Synthesis consists of all the features of SOC Encounter plus the added technology of Global Physical Synthesis to support a design flow from RTL to GDSII. Global Physical Synthesis (GPS) combines silicon virtual prototyping with high-performance global synthesis by leveraging the patented technology of Cadence’s Encounter™ RTL Compiler Ultra. Unlike traditional physical synthesis approaches, which optimize a single path at a time, GPS concurrently optimizes timing for many paths. This reduces the amount of time and effort required to reach design convergence. May 2005 31 Product Version 4.1.5 Encounter User Guide Overview Feature License Matrix The Encounter family of products offers a wide range of features and functionality. The features to which you have access are determined by your product license. The following table displays the availability of various features with the corresponding product licenses. Licenses Features First Encounter Ultra Nano Encounter/ Nano Encounter DBS* Abstract generation (LEF generation with lefOut)** x x Area I/O x Block placer Cadence® Chip Assembly Router interface NanoRoute SoC Ultra Encounter x SoC Encounter GPS First Encounter GPS x x x x x x x x x x x x x x x x x x Chip finishing x x x x Concurrent timing/SI optimization x x x x Delay calculation (SignalStorm® delay calculator) x x x x x x Encounter field solver x x x x x x Engineering change order (ECO) x x x x x x Export DEF x x x x x x Export GDSII x x x x x x Export hierarchical Verilog® x x x x x x Export SDF x x x x x x May 2005 32 Product Version 4.1.5 Encounter User Guide Overview Licenses Features First Encounter Ultra Nano Encounter/ Nano Encounter DBS* Filler cell capability x x Flat CTS x x Floorplanning x x Hierarchical CTS x Global Physical Synthesis (Optimization) x x Import DEF x Import LEF NanoRoute SoC Ultra Encounter x SoC Encounter GPS First Encounter GPS x x x x x x x x x x x x x x x x x x x x x x x x x x x Import .lib x x x x x x Import SDC x x x x x x Import TLF x x x x x x Import Verilog® x x x x x x Metal fill x x x x x x Multiple threshold voltage library support x x x x x x Multi-supply/multivoltage x x x x x x Multi-threading*** x x x x NanoRoute Ultra x x x x Netlist-to-Netlist Optimization OpenAccess support x Partitioning x May 2005 x x 33 x x x x x x x x Product Version 4.1.5 Encounter User Guide Overview Licenses Features First Encounter Ultra Nano Encounter/ Nano Encounter DBS* NanoRoute SoC Ultra Encounter SoC Encounter GPS First Encounter GPS Placement x x x x x Power analysis x x x x x Power planning x x x x x x Power routing x x x x x x RC extraction x x x x x x Report capacitance x x x x x x RTL synthesis, Cadence® DataPath Synthesis Option x x x x x x RTL Compiler Signal integrity x x x x x x x Static timing analysis x x Trial Route x x Verification x x x x x x Wire editing x x x x x x x x x x WRoute x x * Nano Encounter DBS provides all the major features of Nano Encounter for designs with a maximum of 300,000 placeable instances (excluding filler cells). Access to NanoRoute, WRoute, and SRoute is provided through the user interface. Note, however, that you can also access WRoute in standalone mode. ** OpenAccess abstract generator is available from the Virtuoso Chip Editor version 3.3 stream. *** Multi-threading consumes an additional Nano Encounter, NanoRoute Ultra, SoC Encounter, or Route Accelerator license for each additional thread. Nano Encounter DBS requires a separate Route Accelerator license for each additional thread; other Encounter product licenses are ignored. May 2005 34 Product Version 4.1.5 Encounter User Guide Overview Prototyping with SoC Encounter While designers widely use hierarchical methodologies on the logic side, flat methodologies are used more often in physical implementation. The key issue slowing the adoption of hierarchical methodologies is ease of use. In a traditional methodology, designers perform long back-end design iterations before determining that the chip cannot meet timing or other constraints. A single back-end iteration can take several days for a large chip in the traditional approach, because it requires floorplanning, placement, routing, and verification. SoC Encounter provides a full-chip, hierarchical physical prototyping system that lets you immediately validate the physical feasibility of the netlist. You use physical information to partition the design into hierarchical modules, while simultaneously creating timing budgets that are realistic. Physical prototyping includes the following elements: ■ Legal cell placement ■ Trial routing ■ RC extraction ■ Delay calculation ■ Static timing analysis ■ Timing optimization ■ Clock tree synthesis Physical prototyping starts with chip floorplanning, which includes I/O placement, macro placement, and power planning. Inputs are the gate-level netlist generated through initial synthesis stage and the timing constraints. You can reuse designs by including them as macros in the chip design, using a combination of interactive and automatic floorplanning approaches. First, place the major design elements manually, based on your knowledge of the chip architecture. Then, automatically place the remaining elements. After the first floorplanning pass, the software places remaining standard cells using a timingdriven algorithm. Placement includes a trial routing stage that highlights any congestion issues. This approach achieves timing closure without long design iterations because the timing results produced by the physical prototype correlate with those produced by the chip’s final implementation. May 2005 35 Product Version 4.1.5 Encounter User Guide Overview Physical prototyping reduces the time needed to determine the feasibility of a design floorplan from days to a few hours. This allows you to view the chip layout several times a day, without the long delays caused by back-end processes. You can evaluate different implementations of a chip and receive quick feedback on the tradeoffs. Prototyping allows you to create realistic timing budgets for all sections of the chip. The physical information that underlies the creation of timing budgets makes the timing budgets realistic. The result is a final physical implementation that achieves closure without multiple, long implementation iterations. May 2005 36 Product Version 4.1.5 Encounter User Guide 2 Data Preparation This chapter describes how to prepare data for import into the Encounter software. This chapter discusses the following topics: ■ Generating a Technology File on page 38 ■ Preparing Physical Libraries on page 38 ■ Unsupported LEF and DEF Syntax on page 39 ■ Preparing the Design Netlist on page 41 ■ Generating the I/O Assignment File on page 42 ■ Preparing Timing Libraries on page 50 ■ Encrypting Libraries on page 50 ■ Preparing Stamp Models on page 51 ■ Preparing Timing Constraints on page 51 ■ Preparing Capacitance Tables on page 60 ■ Preparing Data for Delay Calculation on page 60 ■ Preparing Data for Crosstalk Analysis on page 60 ■ Checking Designs on page 60 ■ Preparing Data in the Timing Closure Design Flow on page 61 May 2005 37 Product Version 4.1.5 Encounter User Guide Data Preparation Generating a Technology File The technology file provides the software with design rules for placement and routing, and interconnect resistance and capacitance data for generating RC values and wireload models for the design. The technology file also contains process information for the metal interconnect layers, including metal thickness, metal resistance, and line-to-line capacitance values of metal layers, for determining coupling capacitance. Creating Technology Information Using LEF You can use the Library Exchange Format (LEF) to specify technology information. If you do not have LEF technology information, refer to the LEF/DEF Language Reference for details on specifying the information manually. Creating Technology Information Using OpenAccess You can also create technology information equivalent to the information you specify in LEF, but in an OpenAccess database format. This allows you to share technology information easily among tools that support the OpenAccess standard. Preparing Physical Libraries To run the Encounter software, you must create physical libraries (cells and macros). If you have a complete LEF file that contains all cells in the design, and process technology information, then you can import a LEF file. Using LEF to Create Physical Libraries You can use the following methods for creating abstracts for each leaf cell in the design. ■ Use the Abstract Generator. For more information, see the Cadence Abstract Generator User Guide. ■ Create LEF MACROs manually. For more information, see the LEF/DEF Language Reference. May 2005 38 Product Version 4.1.5 Encounter User Guide Data Preparation Creating OpenAccess Physical Libraries You can translate the LEF MACROs to OpenAccess format by using a LEF-to-OpenAccess translator. This allows you to share libraries easily among tools supporting OpenAccess standard. Unsupported LEF and DEF Syntax The Encounter software supports most of the syntax statements in the 5.5 version of LEF and DEF. The software ignores this information, and including it in your files does not cause errors. Unsupported LEF Syntax The Encounter software does not support the following LEF syntax: LEF Statement Unsupported Syntax Macro MACRO macroName [SOURCE {USER | BLOCK} ;] Macro Pin PIN pinName [TAPERRULE ruleName [LEQ pinName ;] PORT LAYER layerName ; [RECT ITERATE pt [PATH ITERATE pt [POLYGON ITERATE Macro Obstruction ;] pt stepPattern ;] ... stepPattern ;] pt pt pt pt ... stepPattern ;] LAYER layerName ; [RECT ITERATE pt pt stepPattern ;] [PATH ITERATE pt ... stepPattern ;] [POLYGON ITERATE pt pt pt pt ... stepPattern ;] Unsupported DEF Syntax The Encounter software parses but ignores the following DEF syntax: ■ BUSBITCHARS statement May 2005 39 Product Version 4.1.5 Encounter User Guide Data Preparation ■ ARRAY statement ■ FLOORPLAN statement ■ HISTORY statement ■ CANPLACE statement ■ CANNOTOCCUPY statement ■ SLOTS section ■ BEGINNEXT section The Encounter software does not support the following DEF syntax. DEF Statement Unsupported Syntax Blockages [+COMPONENT compName] [+SLOTS] Components [+SOURCE TIMING] [+WEIGHT weight] [+FOREIGN foreignCellName pt orient] [ netName | *] [+GENERATE] Groups [+ PROPERTY {propName propVal}] Nets [( {compName pinName | PIN pinName} [+ SYNTHESIZED] )] [+VPIN vpinName [LAYER layerName] pt pt [PLACED pt orient | FIXED pt orient | COVER pt orient] ] [+ SUBNET subnetName [ ( {compName pinName | PIN pinName | VPIN vpinName} ) ] [NONDEFAULRULE ruleName]] [+USE {RESET | SCAN | TIEOFF}] [+PATTERN {STEINER | WIREDLOGIC}] [+ESTCAP wireCapacitance] [+SOURCE {DIST | NETLIST | TEST | USER} [+USE {ANALOG | RESET | SCAN | TIEOFF} May 2005 40 Product Version 4.1.5 Encounter User Guide Data Preparation DEF Statement Pins Unsupported Syntax [+USE {TIEOFF | ANALOG | SCAN | RESET | SIGNAL}] [+DIRECTION FEEDTHRU] [+DIRECTION FEEDTHROUGH] [+COVER] NOTE: +COVER is converted as FIXED. Pin Properties All pin property syntax Regions [+ PROPERTY {propName propVal}] Rows [+ PROPERTY {propName propVal}] Scan chains (BITS numBits) in +FLOATING and +ORDERED attributes Special Nets [+ SYNTHESIZED] ) [+ VOLTAGE volts] [+ SOURCE {DIST | NETLIST | USER} [+ USE {RESET | SCAN | TIEOFF} [+ PATTERN {STEINER | WIREDLOGIC} [+ ESTCAP wireCapacitance [+ WEIGHT weight [+ WIDTH] Preparing the Design Netlist The Encounter software reads a Verilog® design netlist that must be unique to run Clock Tree Synthesis (CTS), Scan Reorder, and In-Placement Optimization (IPO) features. To ensure that the names of all instantiated cell types are unique, use the following command: uniquifyNetlist The command tests all levels of intermediate modules. It does not test leaf cells. For syntax and more information, see uniquifyNetlist in the Encounter Text Command Reference. May 2005 41 Product Version 4.1.5 Encounter User Guide Data Preparation Generating the I/O Assignment File The I/O assignment file defines the rules that determine how the I/O pad cells and pins are organized. The file is rule based to specify exact location, global spacing, individual spacing, skip, offset, keep clear, and corner information. You can specify detailed rules to control the locations, or you can specify minimal or no rules to allow Encounter to determine the locations automatically. Encounter does not require you to create an I/O assignment file to run the software. If you do not specify an I/O assignment file when you import a design, I/Os are assigned randomly. If you do not specify an I/O assignment file, but you want to set I/O pin or pad placement, use a DEF file. Load the DEF file after importing the design, then save the floorplan. You can also save the I/O file to write a sequence file for rule-based work. If you provide an I/O assignment file, you are not required to specify the exact location of all I/O pads. If you do not provide offset values, Encounter spaces the I/O pads evenly along the specified row. The spacing between the corners and adjacent pads is the same as the spacing between the other pads. Area I/Os (flip-chips) are supported by preplacing the bump cells as blocks. This section discusses the following topics: ■ Creating an I/O Assignment File on page 42 ■ Creating a Rule-Based I/O Assignment File on page 46 ■ I/O Pad and Pin Assignment Examples on page 46 ■ Performing Area I/O Placement on page 49 Creating an I/O Assignment File You create an I/O assignment file manually using the following template: Version: 2 Orient: orientation Pin: pinName side [layer width [depth]] Pad: padInstanceName side | corner [cellName] MicronPerUserUnit value Offset: length Skip: length Spacing: length Keepclear: side offset1 offset2 RowMargin: side rowNumber offset Row: rowNumber Indent: length May 2005 42 Product Version 4.1.5 Encounter User Guide Data Preparation The following entries are included in the template: Version: 2 Specifies the beginning of a new I/O format. Orient: orientation Specifies the orientation of the I/O. Pin: pinName Specifies the name of a pin. Specify I/Os as pins for block designs. layer Specifies the layer on which the pin must be placed. width Specifies the width of the pin in µmeters. depth Specifies the length of the pin in µmeters. Pad: padInstanceName Specifies the name of a pad instance. Specify I/Os as pads for chip designs. MicronPerUserUnit: value Specifies the scaling factor for specified length values. cellName Specifies an I/O filler pad that is not in the netlist. corner Assigns a pin to the specified corner of the design. Specify ne, nw, sw, or se. side Assigns a pin to the specified side of the design. Specify n, w, s, or e. layer Specifies the layer number, for example, 7 for layer 7. Offset: length Assigns the absolute pin or pad location, in µmeters, from the left or bottom of the floorplan box. The offset of a pad is the offset of its lower left corner, and the offset of a pin is the offset of its center. Skip: length Specifies the spacing, in µmeters, between the previously defined pad and the pad being defined. Spacing: length Specifies the global spacing, in µmeters, between all pads. This spacing stays in effect until you specify another Spacing: line. Note: When both Skip and Spacing values are specified, the Skip value overrides the Spacing value. Keepclear: side offset1 offset2 May 2005 43 Product Version 4.1.5 Encounter User Guide Data Preparation Specifies an area on a chip where you cannot place pins or pads. side specifies the chip side. offset1 and offset2 specify a range, in µmeters, on the chip side that remains unoccupied. The following commands allow you to create multiple I/O rows: RowMargin: side rowNumber offset Specifies the I/O pad row margin, measuring from the die box inward, rather then from the core box outward. The rowNumber parameter specifies the row number, counting inward from the outer edge of the design. Row: rowNumber Specifies the row number for the following pad or pin, counting inward from the outer edge of the design. Indent: length Indents the next pad or pin by the specified distance from the I/O pad row determined by RowMargin. Note: When creating the I/O assignment file, start comment lines with a pound (#) sign. Specifying Area I/O Information You can also define the following four objects in the I/O assignment file for area I/O placement: ■ Bump Cell A bump cell is the master cell for bump instances. The bump cell specifies the geometry shape, layers, and the technology site of the area I/O instances to which it can connect. Define bump cells using the following format: BumpCell: bumpCell_name {Rect nr_box | Polygon nr_points} [TechSite nr_site] [Layer layer_no] [Port port_name] box | point ... site ... The following example shows a bump cell definition: BumpCell: BUMP Polygon 8 TechSite 2 Layer 6 -34 -80 34 -80 May 2005 44 Product Version 4.1.5 Encounter User Guide Data Preparation 80 -34 80 34 34 80 -34 80 -80 34 -80 -34 areaio_site1 areaio_site2 ■ Bump A bump is a piece of metal that works as a bonding pad to the package. When defining a bump, you must specify its master bump cell and its physical location. You can generate one bump, or an array of bumps of the same bump cell type. ❑ To define an individual signal bump, use the following syntax: Bump: bump_name bumpCell_name x y [io_pin_name [-fixed]] For example, Bump: A3 BUMP 300 100 DI[0] -fixed ❑ To define an individual power bump, use the following syntax: Bump: bump_name reference_bumpcell_name x y power_net_name -power For example, Bump: V5 BUMPP -60 20 VDD -power Bump: G6 BUMPG 40 20 VSS -ground ❑ To define an array of bumps, use the following syntax: Bump: bump_name_prefix bumpCell_name x y H | V step num For example, Bump: myBumpArray myBumpCell 300 100 H 100 5 V 100 10 ■ IORow This section specifies the rows for placing I/O instances. Define I/O rows using the following format: IOROW: iorow_name x y site_name [orient] [ [H | V] step num] For example, IORow: iorow_1 100 100 areaio_site1 R0 H 50 4 ■ IOInst This section specifies the preplaced area I/O instances. Define area I/O instances using the following format: IOInst: inst_name [x y [orient] [-fixed]] For example, May 2005 45 Product Version 4.1.5 Encounter User Guide Data Preparation IOInst: A1/B1/BUF1 200 200 Creating a Rule-Based I/O Assignment File To create a rule-based I/O assignment file, 1. Create an I/O assignment file with I/O pads in the proper sequence. This file can include VDD and VSS filler pads. 2. Import the design. 3. After reviewing the I/O pads, choose Design – Save – IO File. 4. On the Save IO File form, select sequence. 5. Edit the new file for reimporting, or use the loadIoFile command. 6. Save the floorplan to a file. I/O Pad and Pin Assignment Examples The following example shows statements in a sample I/O assignment file for I/O pads as shown in the figure below: I/O Pads Core Area Version: 2 Orient: R0 Offset: 0.0000 Pad: IOPADS_INST/pad1 W Offset: 235.0000 Pad: IOPADS_INST/pad2 W May 2005 46 Product Version 4.1.5 Encounter User Guide Data Preparation Offset: 296.1250 Assigning Pads for Multiple Rows The following example shows statements in a sample I/O assignment file for multiple rows of I/O pads as shown in the figure below: Multiple Row IO Pads Core Area Version: 2 Orient: R0 Offset: 0.0000 Row: 1 Pad: IOPADS_INST/pad1 W Offset: 235.0000 Row: 2 Pad: IOPADS_INST/pad2 W Offset: 296.1250 May 2005 47 Product Version 4.1.5 Encounter User Guide Data Preparation Assigning Module Pins The following example shows an I/O assignment file for module pins as shown in the figure below: Module Pins Module Area Version: 2 Offset: 19.4700 Pin: address[14] N Offset: 39.2700 Pin: address[10] N Assigning Bump Cells The following example shows an I/O assignment file for bumpcell (“Flip Chip”) pads as shown in the figure below: Flip Chip Pads Core Area Version: 2 May 2005 48 Product Version 4.1.5 Encounter User Guide Data Preparation BumpCell: BUMPCELL Rect 1 TechSite 1 Layer 6 0.000 0.000 40.000 40.000 IO1 Bump: A2 BUMPCELL -320.000 -100.000 SM -fixed Bump: A1 BUMPCELL -320.000 -200.000 SI -fixed IOROW: IO_1 -300.000 -117.600 IO1 R0 H 210.000 1 IOROW: IO_0 -300.000 -218.400 IO1 R0 H 210.000 1 IOInst: test_clk/clk/inbuf 100.000 -218.400 R0 -fixed IOInst: test_clk/test/smbuf -300.000 -117.600 R0 -fixed Performing Area I/O Placement Before you begin area I/O placement, you must first specify CLASS PAD AREAIO in a LEF file. To import the LEF files, use the following procedure: 1. Select Design – Design Import. The Design Import form appears. 2. On the Design page, enter the names of the Verilog and ILM files, and choose a top cell assignment option. 3. In the LEF Files field, type the LEF file names to import, and include the file that contains the CLASS PAD AREAIO statement. Instead, you can click on the … icon to the right of the field to select files. 4. Click OK. The Design Import form closes and Encounter imports the data. To load the floorplan and I/O assignment files separately, use the following procedure: 1. Select Floorplan – Load Floorplan – FP or run the loadFPlan text command. 2. Select Design – Load – I/O file or run the loadIoFile text command. As an alternative, you can include the I/O assignment file in the floorplan file, add the following statement to your floorplan file before loading your floorplan. IOFile: iofile_name Note: You can also specify area I/O rows in DEF or PDEF files. May 2005 49 Product Version 4.1.5 Encounter User Guide Data Preparation For more information on the I/O assignment file, see “Creating an I/O Assignment File” on page 42. To save your floorplan and I/O assignment files, use the following procedure: 1. Select Design – Save – Floorplan. Fill out the form and click Save. As an alternative, you can specify the saveFPlan text command. 2. Select Design – Save – I/O File. Fill out the form and click Save. As an alternative, you can specify the saveIoFile text command. To place area I/Os, use either the GUI or command line: ■ To place I/Os, select Place – Place Area I/O. Fill out the form and click OK. ■ Use the placeAIO command to place the area I/Os. Specify the -onlyAIO argument to place only the area I/Os on the area I/O rows. If you do not specify this argument, all standard cell instances and blocks are also placed. Specify the -assignBump argument if you have unassigned bumps for area I/O instance connections. If you specify this argument, area I/O instances are connected to the nearest unassigned bumps. Note: You can also assign bumps after area I/O placement by using the assignBump command. Preparing Timing Libraries Timing library files contain timing information for all of the standard cells, blocks and I/O pad cells in ASCII format. The Encounter software reads timing library format files (.tlf) or Synopsys Technology Library format files (.lib). You do not need to translate timing library files before reading them into the software. Encrypting Libraries To protect proprietary data, you can encrypt the ASCII library files. Use the lib_encrypt utility to perform the encryption. The lib_encrypt utility is installed along with the Encounter software. To encrypt the ASCII library file, use the following command: lib_encrypt [-ogz] [-help] in_file out_file May 2005 50 Product Version 4.1.5 Encounter User Guide Data Preparation Parameters -help Displays the syntax of the lib_encrypt command. in_file Specifies the name of library file to be encrypted. -ogz Creates a gzip file of the encrypted output library file. out_file Specifies the name of the output file. Preparing Stamp Models Stamp models contain timing information for a module, such as an instantiated module, block, or partitioned module. It describes the timing models of large blocks, such as RAM blocks, microprocessor cores, DSP, and others that have not been synthesized into gate-level netlists. A stamp model consists of two files: ■ Model file that describes the ports, timing arcs, and other attributes of the block. ■ Data file that provides technology specific data, including values for timing arcs, port capacitance, and maximum transitions. You do not need to translate these files before reading them into the software. Note: Stamp models supersede timing library models. Preparing Timing Constraints The Encounter software reads Synopsys design constraints written by write_sdc (from Prime Time or Design Compiler), write_script in tcl format (from Prime Time or Design Compiler), or dc_shell format from Design Compiler. You do not need to translate either DC or PT constraints before reading them into the software. Note: When reading in constraints, only read in one format type in a session. This section discussed the following topics: ■ Supported SDC Commands on page 52 ■ Constraint Reader Supported Commands on page 59 May 2005 51 Product Version 4.1.5 Encounter User Guide Data Preparation ■ Reading PKS Constraints on page 59 Supported SDC Commands The following table lists the SDC commands supported by the Encounter software. The second and third columns list the supported and unsupported arguments for each of these commands. Command Supported Arguments add_to_collection collection_of_objects objects_to_add (PTTCL only, non-SDC) Unsupported Arguments -unique all_clocks all_connected object_list (PTTCL only, non-SDC) all_inputs [-clock clock_name] [-edge_triggered] [-level_sensitive] all_outputs [-clock clock_name] [-edge_triggered] [-level_sensitive] create_clock -add -master_clock [-period period_value] [-name clock_name] [-waveform edge_list] [port_pin_list] create_generated_clock -add -master_clock [-name clock_name] -source pin_port [-divide_by freq_div_factor] [-multiply_by freq_mult_factor] [-duty_cycle percent] [-invert] [-edges edge_list] [-edge_shift shift_list] pin_list current_design current_instance May 2005 object_list: ports design_name [hierarchical_instance] 52 Product Version 4.1.5 Encounter User Guide Data Preparation Command Supported Arguments Unsupported Arguments filter pin_object_list “direction == *” [-regexp] [-nocase] object_type [search_pattern] [-hierarchy] [-flat] object_type: cluster, multi-bit, operator, module, implementation, file (PTTCL only, non-SDC) find (PTTCL only, non-SDC) foreach_in_collection (PTTCL only, non-SDC) get_cells (PTTCL only) get_clocks variable collection_of_objects {/* command body */} [-hierarchical | -hierarchy] potential_cell_objects [-quiet] [-regexp] [-exact] [-nocase] [-of_objects objects] [-filter filter_expr] potential_clock_objects [-quiet] [-regexp] [-nocase] [-filter filter_expr] design_objects [-hierarchical] [-quiet] [-regexp] [-nocase] [-exact] [-filter filter_expr] potential_generated_clock_obj ects [-quiet] [-regexp] [-nocase] [-filter filter_expr] lib_cell_objects [-quiet] [-regexp] [-exact] [-nocase] [-of_objects objects] [-filter filter_expr] lib_pin_objects [-filter “direction == *”] [-quiet] [-regexp] [-exact] [-nocase] [-of_objects objects] (PTTCL only) get_designs (PTTCL only, non-SDC) get_generated_clocks (PTTCL only, non-SDC) get_lib_cells (PTTCL only) get_lib_pins (PTTCL only) May 2005 53 Product Version 4.1.5 Encounter User Guide Data Preparation Unsupported Arguments Command Supported Arguments get_nets [-hierarchical] [-hierarchy] potential_net_objects [-quiet] [-regexp] [-exact] [-nocase] [-of_objects objects] [-filter filter_expr] [-hierarchical] [-hierarchy] potential_pin_objects [-filter “direction == *”] [-quiet] [-regexp] [-exact] [-nocase] [-of_objects objects] [-leaf] potential_port_objects [-filter “direction == *”] [-quiet] [-regexp] [-exact] [-nocase] [-of_objects objects] (PTTCL only) get_pins (PTTCL only) get_ports (PTTCL only) get_references get_unix_variable -filter variables (PTTCL only, non-SDC) remove_from_collection (PTTCL only, non-SDC) collection_of_objects objects_to_be_removed set_annotated_check [-setup | -hold | -recovery |-removal] [-rise] [-fall] [-from from_pins] [-to to_pins] [-clock clock_check] set_case_analysis [1|0] port_pin_list set_clock_gating_check [-setup setup_value] [-hold hold_value] [-rise | -fall] [-high | -low] [object_list] May 2005 54 [R | F] Product Version 4.1.5 Encounter User Guide Data Preparation Command Supported Arguments set_clock_latency [-rise] [-fall] [-min] [-max] [-source] [-late] [-early] delay object_list set_clock_skew [-ideal | -propagated] [-delay delay_value] [-rise_delay rise_value] [-fall_delay fall_value] [-uncertainty uncertainty_value] [-minus_uncertainty minus_value] [-plus_uncertainty plus_value] object_list (DC only, non-SDC) set_clock_transition [-min] [-max] [-rise] [-fall] transition_value [clock | register_clock_pin] set_clock_uncertainty [-from from_clock] [-to to_clock] [-rise] [-fall] [-setup] [-hold] uncertainty [clock_object] set_data_check Unsupported Arguments object_list: ports, pins, cells All non-clock objects [-from_edge] [-to_edge] None set_disable_clock_gating_check set_disable_timing obj_list [-from from_pin_name] [-to to_pin_name] [-restore] Note: -from, -to are valid only for cell and lib_cell objects. May 2005 55 Product Version 4.1.5 Encounter User Guide Data Preparation Command Supported Arguments set_dont_touch object_list [true | false] (Non-SDC) set_dont_touch_network Unsupported Arguments Reference objects object_list (Non-SDC) lib_cell_list [true | false] All objects (modules, implementations) other than library cells set_drive drive_strength [-rise] [-fall] [-max] [-min] [-pin_drive] port_list [-wire_drive] set_driving_cell [-min] [-max] [-cell library_cell_name] [-lib_cell library_cell_name] [-pin pin_name] [-from_pin from_pin_name] [-cell_rise library_cell_name_rise] [-pin_rise pin_name_rise] [-from_pin_rise from_pin_name_rise] [-cell_fall library_cell_name_fall] [-pin_fall pin_name_fall] [-from_pin_fall from_pin_name_fall] port_list [-input_transition_rise] [-input_transition_fall] [-rise] [-fall] [-library] [-library_rise] [-library_fall] [-dont_scale] [-multiply_by factor] [-none] [-no_design_rule] set_dont_use (Non-SDC) May 2005 56 Product Version 4.1.5 Encounter User Guide Data Preparation Command Supported Arguments set_false_path [-setup] [-hold] [-from from_list] [-through thru_list] [-to to_list] set_fanout_load fanout_load_value port_list set_input_delay delay_value [-clock_fall] [-clock clock_name] [-rise] [-fall] [-max] [-min] [-add_delay] [-network_latency_included] [-source_latency_included] port_pin_list set_input_transition [-min] [-max] [-rise] [-fall] transition_value port_list set_load load_value port_list [-min] [-max] [-pin_load] [-wire_load] set_logic_dc None set_logic_one port_pin_list set_logic_zero port_pin_list set_max_area None set_max_capacitance capacitance_value object_list May 2005 57 Unsupported Arguments [-reset_path] [-rise | -fall] Non-SDC [-rise_from] [-fall_from] [-rise_to] [-fall_to] [-rise_through] [-fall_through] [-level_sensitive] [-fanout_number] [-subtract_pin_load] object_list: nets Product Version 4.1.5 Encounter User Guide Data Preparation Command Supported Arguments Unsupported Arguments set_max_delay [-from from_list] [-through thru_list] [-to to_list] delay_value [-group_path group_name] [-reset_path] [-rise | -fall] set_max_fanout max_fanout_value port_list set_max_time_borrow delay_value object_list set_max_transition maximum_transition_value object_list set_min_capacitance None set_min_delay [-from from_list] [-through thru_list] [-to to_list] delay_value [-reset_path] [-rise | -fall] set_multicycle_path path_multiplier [-setup] [-hold] [-from from_list] [-start | -end] [-through thru_list] [-to to_list] [-reset_path] [-rise | -fall] set_output_delay delay_value [-clock_fall] [-clock clock_name] [-rise] [-fall] [-max] [-min] [-add_delay] [-network_latency_included] [-source_latency_included] port_pin_list [-group_path group_name] [-level_sensitive] set_port_fanout_number None set_propagated_clock clock_list May 2005 object_type: data pins, clock (enable) pins Non-SDC [-rise_to] [-rise_through] [-rise_from] [-fall_to] [-fall_through] [-fall_from] All non-clock objects 58 Product Version 4.1.5 Encounter User Guide Data Preparation Command Supported Arguments set_resistance [-min] [-max] resistance_val net_list set_wire_load_model None set_wire_load_selectio n_group None source file_names Unsupported Arguments All arguments (PTTCL only, non-SDC) Constraint Reader Supported Commands To import timing constraints, use the write_script or write_sdc command from within design compiler, Prime Time, or physical compiler. These commands eliminate any variable substitution confusion, making them easier for the user and the software to read. Use the write_script command on the design inside dc_shell or pt_shell for the best results, for example write_script -format {ptsh | dcsh | dctcl} -output fileName Or, you can use the following command: write_sdc Reading PKS Constraints Although the Encounter software can read PKS constraints directly, Cadence recommends that you translate PKS constraints into a SDC file to read them into the Encounter software. To translate PKS commands into a SDC file, you must set up the BuildGates Synthesis and Cadence PKS constraint translator using the write_sdc command in the ac_shell or pks_shell environment. For information on setting up the constraint translator and translating PKS constraints, see Chapter 4, “Getting Started with write_sdc,” in the SDC Constraints Support Guide. May 2005 59 Product Version 4.1.5 Encounter User Guide Data Preparation Preparing Capacitance Tables For accurate extraction results, use capacitance tables. You can generate and use separate capacitance tables for different process corners. For more information on preparing capacitance table, see Chapter 18, “RC Extraction.” Preparing Data for Delay Calculation If you want to use the SignalStorm® nanometer delay calculator, see Chapter 19, “Calculating Delay” for information about preparing ECSM libraries. Preparing Data for Crosstalk Analysis For information on preparing data for crosstalk analysis, see Chapter 23, “Analyzing and Repairing Crosstalk.” For more information on preparing cdB noise libraries using the make_cdb utility, see the “make_cdB Noise Characterizer User Guide.” Checking Designs Before importing the design or running Encounter at various stages of the design process, you can check for missing or inconsistent library and design data. To perform these checks, use the following command: checkDesign You can check for the following data: ■ Physical library ■ Timing library ■ Netlist ■ I/Os ■ Tie-high and tie-low pins ■ Power and ground pins Cadence recommends that you check libraries and data as follows: May 2005 60 Product Version 4.1.5 Encounter User Guide Data Preparation ■ Perform I/O checking at any time. I/O problems might not impede any tool, but they might add to design problems. ■ Perform netlist checking at any time after the design has been loaded. ■ Perform physical library checking before floorplanning. ■ Perform power/ground checking before routing and extraction, and verifying geometry and connectivity. ■ Perform timing library checking before any timing-related operation (for example, timing driven placement/routing, timing optimization, clock-tree synthesis, and static timing analysis) ■ Perform tie-high/tie-low checking before routing and extraction. Preparing Data in the Timing Closure Design Flow For information on preparing data for the timing closure design flow, see the Encounter Timing Closure Guide. May 2005 61 Product Version 4.1.5 Encounter User Guide Data Preparation May 2005 62 Product Version 4.1.5 Encounter User Guide 3 Getting Started This chapter describes how to install, configure, and run your Encounter™ software, including how to set preferences and how to use keyboard and mouse shortcuts. This chapter discusses the following topics: ■ ■ ■ ■ Installing Encounter Software on page 64 ❑ Product Information on page 64 ❑ Installation Information on page 64 Setting the Run-Time Environment on page 64 ❑ Starting the Encounter Software in 64-bit Mode on page 65 ❑ Examples on page 65 Starting the Encounter Software on page 66 ❑ Checking Out an Encounter License on page 68 ❑ Running Multi-Threading on page 68 ❑ Running Super Threading on page 69 ❑ Encounter Console on page 69 ❑ Command Name Completion on page 70 ❑ Command-Line Editing on page 70 Setting Preferences on page 72 ❑ ■ Initialization Files on page 73 Online Documentation and Help on page 74 ❑ Using Form Help on page 74 ❑ Using Text Command Help on page 74 May 2005 63 Product Version 4.1.5 Encounter User Guide Getting Started Installing Encounter Software This section provides information on installing the Encounter™ software. Product Information The following table shows the Encounter family of products. All products run on Solaris, HPPA, IBM, and Linux platforms. Product Name Number First Encounter® Ultra silicon virtual prototyping solution FE100 NanoRoute™ Ultra SoC routing solution FE150 SoC Encounter™ hierarchical RTL-to-GDSII physical implementation solution FE200 Nano Encounter™ implementation system for flat designs FE300 Nano Encounter™ Demand Based Savings FE300DBS First Encounter® Global Physical Synthesis FE100GPS SoC Encounter™ Global Physical Synthesis FE200GPS Options Route Accelerator Multi-Thread Route Option RA100 Installation Information Use the Cadence interactive installation utility, SoftLoad, or the SETUP.CSH utility on each CD to install the software. Setting the Run-Time Environment ➤ To set the run-time environment, set the following installation directory in your path: install_dir/tools/bin May 2005 64 Product Version 4.1.5 Encounter User Guide Getting Started Starting the Encounter Software in 64-bit Mode Some Cadence® applications have both 32-bit and 64-bit versions. The 64-bit versions of applications are installed in the same tools hierarchy as the 32-bit versions. A “wrapper” for each application determines which version of the application is run. To run a 64-bit version of Encounter software: 1. Verify that your operating system supports 64-bit applications. 2. Verify that a 64-bit version of the application is installed. The 64-bit version of an application is located in the 64bit directory in the standard installation location of the application. For example, your_install_dir/tools/ bin/64bit. 3. Set the following environment variable: CDS_AUTO_64BIT { ALL | NONE | list } ALL All applications are run as 64-bit. NONE All applications are run as 32-bit. list Only the applications specified are run as 64-bit. Specify list as a list of case-sensitive application names, separated by a colon, comma, or semi-colon. If you use a semi-colon, enclose the list in single quotation marks. For the Encounter family of products, the following executable names are valid entries for list: ■ celtic ■ encounter ■ nanoroute ■ pks_shell ■ wroute Examples The following examples show how to run the Encounter software in various 64-bit modes: setenv CDS_AUTO_64BIT ALL All Encounter products are run in 64-bit mode. May 2005 65 Product Version 4.1.5 Encounter User Guide Getting Started setenv CDS_AUTO_64BIT encounter:celtic or setenv CDS_AUTO_64BIT ‘encounter;celtic’ The Encounter and CeltIC™ products run in 64-bit mode. All other products are run in 32-bit mode. setenv CDS_AUTO_64BIT pks_shell Only pks_shell run in 64-bit mode. All other products run in 32-bit mode. Note: If you do not set this environment variable, the Encounter software automatically starts in 32-bit mode. Starting the Encounter Software To start an Encounter session, type the following at the UNIX prompt: encounter [-soce | -ultra | -nano | -nedbs | -nanor | -fegps | -socegps] [-log logFileName] [-config configFileName] [-init tclFileName] [-accel_any_lic] [-win | -nowin] [-overwrite] [-version] The encounter command has the following parameters: -accel_any_lic Searches for available Encounter licenses use for multithreading. After completion, the software returns the checkedout licenses. If you do not specify this parameter, you must have available Route Accelerator licenses for additional threads. For more information, see “Running Multi-Threading” on page 68. -config configFileName Specifies the design input configuration file. -init tclFileName Specifies the Tcl file to be read in during the start of the Encounter session. When the command finishes executing the Tcl file, type the win command in the Encounter console to display the Encounter main window. -log logFileName Represents the user-specified log filename. May 2005 66 Product Version 4.1.5 Encounter User Guide Getting Started -nowin Starts an Encounter session in a non-GUI environment. If you specify -nowin, you cannot use the win command to display the Encounter main window. -overwrite Overwrites the existing file specified by logFileName. Neither the log nor command files are incremented, and both are overwritten. [-soce | -ultra | -nano | -nedbs | -nanor | -fegps | -socegps] Checks out the specified license: ■ soce is the SoC Encounter license ■ ultra is the First Encounter Ultra license ■ nano is the Nano Encounter license ■ nedbs is the Nano Encounter Demand-Based Savings license ■ nanor is the NanoRoute Ultra license ■ fegps is the First Encounter Global Physical Synthesis license ■ socegps is the SoC Encounter Global Physical Synthesis license License names are case-insensitive. Important If the license you specify is not available, an error message is generated and the Encounter software does not start. -version Displays the version of Encounter software you are running. (When you use this parameter, no Encounter license is checked for, nor does the Encounter software start.) -win Displays the Encounter main window if you have started the Encounter software using the -init parameter. If you do not specify any parameters, the following actions occur: ■ A log file and a command file are created in the form encounter.log# and encounter.cmd#. May 2005 67 Product Version 4.1.5 Encounter User Guide Getting Started ■ The first available license is checked out. ■ The Encounter main window opens. Checking Out an Encounter License When you start the software, the system attempts to check out the most complete license, in the following sequence: 1. SoC Encounter 2. First Encounter Ultra 3. Nano Encounter 4. Nano Encounter DBS 5. NanoRoute Ultra Note: If you specify a license that is not available, the software does not start. Note: You cannot run Encounter software version 4.1 without a license for 4.1 or higher. Running Multi-Threading During multi-threading, the Encounter software uses multiple processors in one workstation to accelerate routing. To enable multi-threading, you need additional Encounter or Route Accelerator licenses for the additional processors. You can only use as many licenses as are available. If you ask for more, the software generates a warning message and runs with the available number of licenses. To search for licenses and specify the number of processors to use, complete the following steps: 1. Accept the default behavior or set -accel_any_lic. ❑ If you accept the default behavior, the software searches only for available Route Accelerator licenses. ❑ If you want to use other available Encounter licenses, specify -accel_any_lic. The software searches for licenses in the following order: Route Accelerator, NanoRoute Ultra, Nano Encounter, SoC Encounter, SoC Encounter GPS. 2. Specify the number of processors to use. May 2005 68 Product Version 4.1.5 Encounter User Guide Getting Started ❑ If you are running NanoRoute, each additional license allows you to use three additional processors. Specify the following parameter: setNanoRouteMode -envNumberProcessor numberProcessors For information on this parameter, see setNanoRouteMode in “Route Commands,” in the Encounter Text Command Reference. ❑ If you are running WRoute, each additional license allows you to use one additional processor. Specify the following parameter: wroute multiCpu numberProcessors For information on this parameter, see wroute in “Route Commands,” in the Encounter Text Command Reference. Running Super Threading NanoRoute further accelerates routing by super threading during detailed routing. In super threading, NanoRoute distributes detailed routing across multiple workstations or servers while running multi-threading. Super threading uses available Encounter licenses. To run super threading, specify the following parameter: setNanoRouteMode -envSuperThreading For information on this parameter, see setNanoRouteMode in “Route Commands,” in the Encounter Text Command Reference. For more information on super threading, “Routing Your Design With NanoRoute” on page 391. Encounter Console The UNIX window (shell tool, xterm, and so on) where you start the Encounter session is called the Encounter console. This is where you enter all Encounter text commands and where the software displays messages. When a session is active, this console displays the following prompt: encounter> If you use this console for other actions—for example, to use the vi editor—the session suspends until you finish the action. May 2005 69 Product Version 4.1.5 Encounter User Guide Getting Started If you suspend the session by typing Control-z, the encounter> prompt is no longer displayed. To return to the Encounter session, type fg, which brings the session to the foreground. Command Name Completion You can use the Tab key within the Encounter console to complete text command names. After you type a partial text command name and press the Tab key, the Encounter software displays either ■ The exact command name that completes or matches the text you typed (if the string is unique to one text command), or ■ All the commands that match the partial text you typed Caution When the Encounter software displays multiple matches for a given string of partial text, the list of matches might include command names that are not formally supported in this release. Only those commands that appear in the Encounter Text Command Reference and in the Encounter console’s command-line help and man pages have been validated and are supported. Suggested message to be displayed by the software when the name completion function returns more than one item: “This list of commands might include commands that are not formally supported in this release. Only those commands that appear in the Encounter console’s command-line help and man pages have been validated and are supported.” Command-Line Editing The Encounter software provides a GNU Emacs–like editing interface. You can edit a line before it is sent to the calling program by typing either control characters or escape sequences. A control character, shown below as a caret followed by a letter, is typed by holding down the Control key when typing the character. Most editing commands can be given a repeat count, n, where n is a number. To enter a repeat count, type the Escape key, the number, and then the command to execute. For example, Escape 4 ^f moves forward four characters. If a command may be given a repeat count then the text [n] is given at the end of its description. May 2005 70 Product Version 4.1.5 Encounter User Guide Getting Started You can type an editing command anywhere on the line, not just at the beginning. You can press Return anywhere on the line, not just at the end. Note: Editing commands are case sensitive: Escape F is not the same as Escape f. Control (^) Characters ^A Move to the beginning of the line ^B Move left (backwards) [n] ^C Exits from editing mode, returning the console to normal Encounter mode ^D Delete character [n] ^E Move to end of line ^F Move right (forwards) [n] ^G Ring the bell ^H Delete character before cursor (backspace key) [n] ^I Complete filename (Tab key); see below ^J Done with line (Return key) ^K Kill to end of line (or column [n]) ^L Redisplay line ^M Done with line (alternate Return key) ^N Get next line from history [n] ^P Get previous line from history [n] ^R Search backward (forward if [n]) through history for text; must start line if text begins with an up arrow ^T Transpose characters ^V Insert next character, even if it is an edit command ^W Wipe to the mark ^X^X Exchange current location and mark ^Y Yank back last killed text ^[ Start an escape sequence (Escape key) ^]c Move forward to next character c May 2005 71 Product Version 4.1.5 Encounter User Guide Getting Started ^? Delete character before cursor (Delete key) [n] Escape Sequences Escape ^H Delete previous word (Backspace key) [n] Escape Delete Delete previous word (Delete key) [n] Escape SP Set the mark (Space bar); see ^X^X and ^Y above Escape . Get the last (or [n]’th) word from previous line Escape < Move to start of history Escape > Move to end of history Escape b Move backward a word [n] Escape d Delete word under cursor [n] Escape f Move forward a word [n] Escape l Make word lowercase [n] Escape u Make word uppercase [n] Escape y Yank back last killed text Escape v Show library version Escape w Make area up to mark yankable Escape nn Set repeat count to the number nn Escape C Read from environment variable _C_, where C is an uppercase letter Setting Preferences You set preferences at the beginning of a new design import. You can assign special characters for the design import parser for Verilog®, DEF, and PDEF files, and control the display of the Floorplan and Physical view windows. You can also change the hierarchical delimiter character in the netlist before importing the design, and change the DEF hierarchical default character and the PDEF bus default delimiter before loading the file. Note: If you change the default values for the DEF delimiter or PDEF bus delimiter, these changes become the default delimiters for the DEF and PDEF writers. May 2005 72 Product Version 4.1.5 Encounter User Guide Getting Started You can also change the control defaults while working in the floorplan. These defaults include the snapping of the module guides, minimum module guides, minimum flight line connection width, and route congestion. For information on setting design preferences, see “Design – Preferences” on page 139. Initialization Files The Encounter software uses the following initialization files for setting preferences: .encrc Used for setting Tcl parameters or adding user-defined Tcl commands. If different versions of this file exist in the installation, home, or work directories, the file in the work directory takes precedence. Note: Usage of this file is no longer recommended, but is allowed for backward compatability. You should use enc.tcl instead. This file is processed before the GUI is created, so it cannot be used to customize the GUI. enc.tcl Used for setting Tcl parameters, customizing the GUI, or adding user-defined Tcl commands or global variables. If different versions of this file exist in the installation, home, or work directories, the file in the work directory takes precedence. Note: The Encounter software does not create or modify this file. You must create the file and then put a copy of the file in the installation directory (encounter_installation_path/ tools/fe/etc), home directory, or work directory. enc.pref.tcl Contains design preferences set using the Preferences form (see “Design – Preferences” on page 139). Note: By default, Encounter saves changes that you make to your preferences to the enc.pref.tcl file in the work directory. The initialization files are read in the following sequence: 1. .encrc in the home directory 2. .encrc in the work directory 3. enc.pref.tcl in the work directory May 2005 73 Product Version 4.1.5 Encounter User Guide Getting Started 4. enc.tcl in the installation/etc directory 5. enc.tcl in the home directory 6. enc.tcl in the work directory Note: If initialization files contain conflicting information, the last file read takes precedence. Online Documentation and Help You can access Encounter documentation by clicking on Help on the upper-right side of the main window. You can also access documentation by typing the following UNIX command at a UNIX prompt: install_dir/tools/bin/cdsdoc & Both actions open the CDSDoc: Library window. From this window you can open, or search for topics in, the Encounter Text Command Reference, the Encounter User Guide, and other relevant Cadence documentation. Important Do not type the cdsdoc UNIX command in the Encounter console. If you enter the command in the console, the session suspends until you exit CDSDoc. Using Form Help To see information about a specific form, click the form’s Help button. This takes you to the form’s information in the Encounter User Guide. Using Text Command Help To see syntax information about an Encounter command, type the following in the Encounter console: help command_name To see the entire list of Encounter commands and their syntax, type the following in the Encounter console: help The information is written to the encounter.log file. May 2005 74 Product Version 4.1.5 Encounter User Guide Getting Started To see the complete set of information about an Encounter command, type the following in the Encounter console: man command_name May 2005 75 Product Version 4.1.5 Encounter User Guide Getting Started May 2005 76 Product Version 4.1.5 Encounter User Guide 4 Importing and Exporting Designs This chapter describes how to import and export files into the Encounter environment, and how to reload Encounter files after you have saved them. This chapter presents the following topics: ■ Overview on page 78 ■ Checking Data before Importing a Design on page 78 ■ Creating a Flat Verilog Netlist from a DEF File on page 78 ■ Importing Designs on page 81 ■ Loading Previously-Existing Configuration Files on page 82 ■ Selecting Files on page 83 ■ Removing Assign Nets from a Verilog Netlist on page 85 ■ Importing Tile Cell Design Data on page 86 ■ Saving and Restoring Design Data on page 87 ■ Importing and Exporting Design Data on page 88 ■ Merging GDSII Files on page 93 ■ GDSII Map File Format on page 94 ■ Updating Files during an Encounter Session on page 96 May 2005 77 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Overview The Encounter™ software provides the following options for saving, restoring, importing, and exporting design data: Importing designs Allows you to specify data for starting a design or load existing configuration files. Restoring designs Allows you to load saved data from a previous design session. Saving designs Allows you to save the work you complete during a design session for access at a later date. Loading (importing) design data Allows you to load design data saved in various stages of the design process, and to bring data from specific formats (for example, DEF, SPEF, SDF) into the Encounter environment. Saving (exporting) design Allows you to save design data in various stages of data the design process, and to export data in specific formats (for example, DEF, SPEF, SDF) from the Encounter environment. Checking Data before Importing a Design To check that Verilog, LEF, and .lib files are available at the beginning of an Encounter session, use the following command: setCheckMode -designImport {on | off} Encounter performs this check by default. To report the current checking mode, use the following command: getCheckMode Creating a Flat Verilog Netlist from a DEF File Cadence requires a Verilog netlist for design import. There is an exception: if you have a DEF file that contains connectivity information, you can import this file. This is not the recommended approach. May 2005 78 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Caution After loading the DEF netlist, you can perform floorplanning, non-timing driven placement and routing, wire editing, and verification. You cannot use the DEF netlist flow for parasitic extraction, delay calculation, and timing-driven placement and routing effectively because the DEF names do not properly match the Verilog names used in timing constraints and timing analysis. Recommended DEF Import Commands To import a DEF file that contains connectivity information, use either of the following commands: ■ defToVerilog defFile verilogFile The defToVerilog command loads the DEF netlist, saves the netlist as a Verilog file, and frees the design, enabling to you continue in the Encounter environment. ■ loadDefFile defFile The loadDefFile command loads a DEF file to build Encounter’s in-memory database. In order to use this command, the library data must be present in memory (use loadLefFile). For more information, see defToVerilog and loadDefFile in the Encounter Text Command Reference. Alternative DEF Import Flow As an alternative to the recommended commands, you can use the following procedures. ■ Creating a Verilog Netlist from a DEF File on page 79 ■ Reconciling the Object Names and Creating New DEF File That Can Be Used With the Normal Encounter Flows on page 80 Creating a Verilog Netlist from a DEF File The following procedure creates a Verilog netlist from a DEF file, which must contain connectivity information. 1. Start Encounter May 2005 79 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs encounter 2. Load the library information. loadLefFile example.lef 3. Load the DEF file that contains connectivity information. loadDefNetlist example.def 4. Write the Verilog file created by loadDefNetlist. saveNetlist output.v Important You cannot continue to use Encounter with the netlist you have created. You must exit at this point, then reconcile the object names. 5. Exit the current session. exit Reconciling the Object Names and Creating New DEF File That Can Be Used With the Normal Encounter Flows The following procedure imports the Verilog file generated by saveNetlist in the previous encounter session, and reconciles names in the DEF and Verilog files. This procedure is required if you want to retrieve more information from the original example.def file. 1. Start Encounter. encounter 2. Use a configuration file containing commands to load the LEF file and the Verilog file generated by saveNetlist from the first session. loadConfig output.conf 3. Import the DEF file. defIn -verilog_from_def_netlist_flow example.def This command reads all DEF constructs, not just connectivity. Note: The -verilog_from_def_netlist_flow parameter is undocumented and is used in this flow only. The the defIn operation uses this parameter to correct special characters so that the names in the output.def file match the names in the new Verilog file. 4. Write the DEF file. defOut [other-options] output.def May 2005 80 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs The output.def file is equivalent to example.def, but with the Verilog names resolved. It can be used in future encounter sessions without the -verilog_from_def_netlist_flow parameter. 5. Exit the current session. exit Now, you can use output.conf, output.v, and output.def in any encounter flow. Importing Designs This section describes how to bring design data into the Encounter environment. Before you begin a design, you must first prepare the data. For more information, see “Data Preparation” in the Encounter User Guide. To begin a design, complete the following steps: 1. Select Design – Design Import. 2. Select the Design tab if it is not already selected. 3. Enter the name of the Verilog netlist to import. 4. Select one of the following options to specify the top cell: ❑ Auto Assign (Default) Automatically extracts the top cell name from the netlist, provided the netlist contains only one design. ❑ By User Specifies the name of the top cell when a netlist contains more than one design (more than one top design name). The top cell name specified is the design the software imports and processes. 5. Specify technology and physical information, either in LEF or in OpenAccess format. You can also supply both. ❑ If you have LEF files, enter the names of the files. You must specify the technology LEF file first, then specify the standard cell LEF and block LEF in any order. The LEF file provides technology information, such as metal layer and via layer information and via generation rules, which is used in the Add Rings and Add Stripes forms. The router also uses the technology information contained in the LEF file. May 2005 81 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs If a cell is defined multiple times, Encounter reads the geometry information only from the first definition. For subsequent definitions, Encounter reads the antenna information only. Note: If the LEF file contains all the physical information for the design, no other files are required for the Technology Information/Physical Libraries panel. ❑ If you have OpenAccess data instead of or in addition to LEF files, specify the following information: ❍ OpenAccess reference libraries ❍ Abstract view names ❍ Layout view names 6. Click Save or OK. ❑ Save saves your settings to a configuration file. The design is not imported. ❑ OK uses the current settings to import the design. The configuration file is not updated. Loading Previously-Existing Configuration Files You can use either the command line or GUI to load previously-saved configuration files. Loading Configurations Files from the Command Line To load a previously-saved configuration file, use the following command: loadConfig fileName [0 | 1] Encounter loads a configuration file. If you use this command in batch mode and specify a filename, the file is loaded and the design is imported. If you specify a filename and the 0 parameter, the software loads the file, but does not import the design. To apply settings specified in the current configuration file and import the design, use the following command: commitConfig Loading Configuration Files from the GUI To load a previously-saved configuration file from the GUI, complete the following steps: May 2005 82 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs 1. Select Design – Design Import. 2. Select the Design tab if it is not already selected. 3. Click Load. The Load Import Configuration form is displayed. 4. Select the directory of the file you want to load. 5. Select Input config file (*.conf*) in the Files of type field. 6. Specify a file name or click on the filename in the window. The filename suffix is .conf. 7. Click Open. The Load Import Configuration form closes. The configuration file is loaded. 8. In the Design Import form, continue to specify data you want to import into the design. 9. Click Save or OK. ❑ Save saves your settings to a configuration file. The design is not imported. ❑ OK saves your settings to a configuration file and starts the design import process. This might take several minutes to complete, depending on the size of your design. When the design is loaded, the Design Import form closes and the design displays in the Encounter main window. Selecting Files Many of the text fields on the Design page contain a browse (...) button that opens a separate form for selecting files. The name of the form corresponds to the specific file you are selecting; for example, Netlist Files, ILM Files, or Timing Files. These forms are provided for easier file management. Using Select Files 1. From the Design page of the Design Import form, click the browse (...) button next to the text field of the file type you are interested in. May 2005 83 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs This opens the Files form for that file type. For example, clicking the browse button next to the Max Timing Libraries field opens the Timing Files form. 2. To type in a specific filename, do the following: a. In the first text field, type one or more filenames, specify wildcards, or select a directory. Use spaces to separate multiple filenames. b. Click Add. The filenames appear in the Files list of this form and in the specific Files field of the Design Import form. c. Click close. 3. To choose a file from a directory, do the following: May 2005 84 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs a. Click the file folder icon. This expands the form and displays a list of directories and files. b. Select one or more files in the Files list. c. Click Add. The filenames appear in the Files list of this form and in the specific Files field of the Design Import form. d. Click close. 4. To delete files, select the file(s) to be deleted in the Files list and click Delete. The files are deleted from the both this form and the Design Import form. Removing Assign Nets from a Verilog Netlist You can use the setDoAssign command to remove assign statements from the Verilog netlist for a design. Encounter has the following approaches to process assign statements, each with its own limitation: 1. Encounter removes assign statements and does not change the netlist. Use the following command: May 2005 85 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs setDoAssign off Note: IPO, ECO, and CTS cannot modify the nets affected by the assign statements. 2. Encounter removes assign statements by merging the nets in Assign statements, changing the netlist. Use the following command: setDoAssign on 3. Encounter replaces Assign statement with buffers during design import. Use the following command: setDoAssign on -buffer buffer_cell The following conditions arise from using the setDoAssign command. 1. Timing constraints applied to hierarchical pins associated with assign statements are lost in some cases. To retain constraints, use the following command: setDoAssign on -buffer buffer_name 2. Encounter cannot remove Assign statements associated with I/O pins.To do this manually, use the following command: setDoAssign on -buffer buffer_name 3. Encounter does not handle Assign statements associated with bussed nets. You must process assign statements using your front-end software. Importing Tile Cell Design Data You can use text commands or the GUI to import a DEF file containing tile cell design data. To import tile cell data by using a script, complete the following steps: 1. Load the configuration file. loadConfig 2. Set the relative path from the working directory. set rda_ciop(tile:rootdir) [file join [pwd] "tile_cell_lib_dir"] 3. Find all LEF files in the specified path. ciopLoadTileLib 4. Read the DEF file. defIn tile_cell_def_file To import the tile cell data by using the GUI, complete the following steps: 1. Provide a valid path to the tile library. May 2005 86 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs FlipChip – Select Tile – Edit 2. Load tiles from the library. FlipChip – Select Tile – Load 3. Read the DEF file. defIn tile_cell_def_file Saving and Restoring Design Data This section contains the following general guidelines for saving and restoring your design data: ■ Saving Design Files on page 87 ■ Restoring an OpenAccess Design on page 87 ■ Saving an OpenAccess Design on page 88 ■ Restoring a Design Created with Encounter 3.1 on page 88 Saving Design Files The design files you save depend on the work completed during an Encounter session. For example, if you did not perform Trial Route on an imported design, the saved design data will not include a route file. You can save a netlist file only if you made a design change during the Encounter session. If you make no changes, Encounter references the original netlist when it saves the design. You must not use the Save Design form to save a partition. Restoring an OpenAccess Design Before you attempt to restore an OpenAccess design for the first time, you must have saved the design using the Design – Save – OA Design command in the previous Encounter session. If you saved data in the previous session using the Design – Save – OA Database command, use Design – Load – OA Database command after design import to restore that data, not Design – Restore OA Design. May 2005 87 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Saving an OpenAccess Design Before you attempt to save an OpenAccess design for the first time, you must set the Reference Libraries and Abstract View values on the Design Import – Misc form. Then, after you run Design – Restore OA Design in a new session, the Encounter software restores the design state to the same as state it was in when you used Design – Save OA Design in the previous session. Restoring a Design Created with Encounter 3.1 If you restore a design in Encounter 4.1 that was created using Encounter 3.1, the software generates the following error message and terminates prematurely: **Info: rda_Input(qxconf_file) = {} **ERROR: Number of design hinsts 25 does not match wire file 27 **ERROR: Aborting restore wires from file "/spc/regtest2/fe/testcases/SOCE_32_training/DATA/FLOORPLAN/ dtmf_chip_restore.enc.dat/dtmf_chip.route.gz" This error occurs because setImportMode -keepEmptyModule is set to 0 by default in Encounter 3.1. This problem does not occur in subsequent releases because import modes are saved in the configuration file when you save the design. To restore a 3.1 design in 4.1, type the following command before restoring the design: setImportMode -keepEmptyModule 0 Importing and Exporting Design Data This section contains some general suggestions for importing design data into the Encounter environment and export data out of the Encounter environment. Loading a Partition Before you load a partition, perform the following tasks: 1. Import the design 2. Load the full chip (flat) floorplan, including partition specifications 3. Commit the partition without pin assignment or a timing budget 4. Place and route each of the partitions May 2005 88 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs When you load a partition design, the Encounter software rebuilds the individual partition and the top level, so that the entire chip can be analyzed. When you load a saved partition, the software loads all the files that are selected in the Load Partition File form. Important The netlist and routing must be consistent when you load a partition that contains routing data. For example, if your netlist was modified after in-place optimization (IPO) or after running NanoRoute, you should make sure that the loaded routing results correctly correspond to the new netlist. Types of Floorplan Data When you load a floorplan, the Encounter software treats the following items as floorplan data: ■ Floorplan dimensions ■ Standard cell rows ■ Floorplan guides ■ Hard blocks (macros) ■ Blackboxes ■ Power structures ■ Density screens ■ Placement blockages ■ Routing blockages ■ Pin blockages ■ Partition pin cuts ■ Feedthrough guides Important Blocks and instances that you load with the Load Floorplan command are set as preplaced. May 2005 89 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Placement File Requirement Before you load the floorplan file that was used to generate the placement file, make sure the placement file is in Encounter format. Loading an I/O Assignment File If you do not read an I/O assignment file into your Encounter session, and if no I/O pad instances are preplaced, the Encounter software randomly places I/O pad instances. Loading an FSDB File Load an FSDB file for detailed power analysis using the Debussy Waveform (nWave) tool. Before You Begin Run a simulation-based power analysis with VCD input. Loading an OpenAccess Database Before you restore an OpenAccess database, you must run the lef2oa command. After you run the lef2oa command, you can use the Restore OA Database form to restore floorplan, placement, and routing information in the OpenAccess format. Saving a Partition You can save import configuration, netlist, floorplan, special route, and vendor-specific files for each partition, including the top level. Note: Regardless of your choice of output file, the Verilog® netlist, configuration file, and floorplan file are always saved. Important You can specify a timing constraint output format for each partition only if you selected Derive Timing Budget when you ran the Partition program. May 2005 90 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Saving Floorplan Data When you save a floorplan, the Encounter software treats the following items as floorplan data: ■ Floorplan dimensions ■ Standard cell rows ■ Floorplan guides ■ Hard blocks (macros) ■ Blackboxes ■ Power structures ■ Density screens ■ Placement blockages ■ Routing blockages ■ Pin blockages ■ Partition pin cuts ■ Feedthrough guides After you save a floorplan, the Encounter software creates the following files: ■ A general floorplanning file with the extension .fp ■ A power route data file with the extension .fp.spr If there is an entry in the IO Cell Libraries field in the Design Import form, a third file with the extension .fp.areaio Importing and Exporting TDF Files Before you can exchange data between the Encounter software and the Astro third-party tool, you must provide information on the layer and contact mapping. Before you can use the tdfIn and tdfOut commands, you must add the following information to your LEF technology file: BEGINEXT "mapName” LAYER layerName LAYEREXTID VIA contactName CONTACTID VIA viaName CONTACTID May 2005 91 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs VIARULE ruleName CONTACTID ENDEXT The following examples shows a layer and contact mapping: BEGINEXT "FE_TF_LAYEREXTID" LAYER MET1 31 LAYER MET2 32 LAYER MET3 33 LAYER MET4 34 LAYER MET5 35 VIA polyCont 1 VIA via1 2 VIA via2 3 VIA via3 4 VIA via4 5 VIARULE via1_array 2 VIARULE via2_array 3 VIARULE via3_array 4 VIARULE via4_array 5 ENDEXT Exporting OpenAccess Data If you have LEF files only and you want to export an OpenAccess design, Encounter creates OpenAccess reference libraries from the LEF files. If you change the LEF, you must remove the generated OpenAccess reference libraries. If you remove the OpenAccess reference libraries before exporting an OpenAccess design, Encounter creates new OpenAccess reference libraries. If you do not remove the generated OpenAccess reference libraries after you change the LEF files, Encounter does not overwrite the OpenAccess libraries. An error occurs if there are inconsistencies between the LEF and OpenAccess libraries when you attempt to import or export an OpenAccess design. You can use either the command line or GUI to export the OpenAccess data. Exporting OpenAccess Data Using the Command Line To export an OpenAccess database using text commands, run the following command: oaOut lib cell view For more information and complete command syntax for oaOut, see “Import and Export Commands” in the Encounter Text Command Reference. Exporting OpenAccess Data Using the GUI To export an OpenAccess database from the GUI, use the following command: May 2005 92 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Design – Save – OA Database For more information about Design – Save – OA Database, see “Design” in the Encounter Menu Reference. Merging GDSII Files Encounter enables you to merge multiple GDSII files into a single GDSII file for hierarchical designs. When you merge GDSII files during stream out (streamOut -merge), and a merge file contains extra cells, Encounter does not merge these cells. For example, if one GDSII merge file contains cells such as A,B,C,D,X,Y,Z. and the design contains only cells A,B,D then Encounter merges only cells A,B and D. In previous releases, all cells were merged, regardless of whether they were used in the design. If you want to merge files with a version numbers greater than 3, Encounter generates a GDSII file with highest version number from merged files. You can merge GDS files by using either the command line or GUI. Merging GDS Files Using the Command Line To use the -merge parameter for a hierarchical design, perform the following steps: 1. Create the block level GDSII files first, using the streamOut -merge option. 2. Create the top level GDS using the block level files as the -merge files. The top-level output issues warning messages because the merge files, including the block GDSII files, contain structures with the same name. The final GDSII file contains the top structure, each of the block structures, and all of the leaf cell structures. Merging GDS Files Using the GUI To use the GUI, perform the following steps: 1. Choose Design – Save – GDS. This opens the GDS Export form. 2. Enter the following information: ❑ May 2005 Output Stream File 93 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Specify the name of the GDSII output file. Use the file folder icon to find the directory and file you want. Note: Add the.gz extension to the filename to enable compression (for example, GDS_file.gds.gz). ❑ Map File Specify the file for layer mapping between the system and GDSII. Use the file folder icon to find the file you want. If you do not specify a file, a default map file is created with the name streamOut.map. For more information, see “GDSII Map File Format” on page 94. ❑ Library Name Specify the library that you want to convert to GDSII format. The default name is DesignLib. ❑ Merge Stream Files Specify a single file or list of files (separated by spaces) to merge with the database. All files must be Stream/GDSII files. Compressed files are acceptable. In case of structure name conflicts, structures from the first file take precedence. The file names in the GDS Files field on the Design – Import – Misc form (Design – Design Import – Misc) form appear in this field. 3. Select the other options you need. 4. Click OK. Encounter enables you create blackboxes only for structures not found in GDS merge libraries, after streamOut merges data. To do this, you must specify both the -merge and -outputMacros parameters. GDSII Map File Format To export GDSII data, you must create a file for layer mapping between the system and GDSII. If a file is not specified, a default map file is created with the name streamOut.map. The map file contains four columns, as shown below. All columns are required. # # 1 #layer/object name t_layerObjName May 2005 COLUMN 2 layer/object type t_layerObjType 3 layer number n_layerNumber 94 4 data type n_dataType Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Column Descriptions t_layerObjName Specifies one of the following keywords: LEF layer name (keyword) Specifies a LEF layer name from the LAYER statement in the LEF technology file section. If column1 contains a layer name, then, column 2 must contain the DEF object type (t_layerObjType). Note: In routing layers, using ALL is the same as using NET, SPNET, VIA, PIN, LEFPIN, FILL, LEFOBS, and VIAFILL. In cut layers, using ALL is the same as using VIA or VIAFILL. COMP (keyword) Specifies component outlines. DIEAREA (keyword) Specifies the chip boundary. NAME (keyword) Specifies a text label for the layer name and associated object type. If column 1 contains COMP, then column 2 should specify ALL. If column 1 contains DIEAREA, then column 2 should specify ALL. If column 1 contains NAME, then column 2 can be either a composite layer name/object type (LEFPIN, PIN, NET, or SPNET), or COMP. For NET, one text is placed on the NET. For SPNET, one text is placed on the SPECIALNET. For PIN, one text is placed on the PIN or IO abstract pad. NAME COMP, creates a name text instance at the location of the placed DEF component. t_layerObjType Specifies one of the following object types: ALL, BLOCKAGE, BLOCKAGEFILL, COMP, FILL, LEFPIN, LEFOBS, NET, PIN, SPNET, VIA, or VIAFILL. n_layerNumber Specifies the GDSII layer number. n_dataType Specifies the GDSII data type. May 2005 95 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Note: Layer names or object types that exist in the database, but are not specified in the map file, will be filtered (not output into the GDSII/Stream file). The following shows an example of a map file. Columns contain the layer object name, layer name and object type, layer number, and data type for each row. # layer/object name METAL1 METAL1 METAL1 METAL1 METAL1 DIEAREA NAME METAL2 METAL2 layer/object type layer number NET 21 SPNET 21 PIN 21 VIA 21 FILL 21 ALL 62 METAL1/NET 21 NET,PIN,VIA,FILL 22 SPNET 22 data type 0 1 0 0 0 0 0 0 1 Updating Files during an Encounter Session The following table below lists the files that can be replaced or updated incrementally during an Encounter session: Type Replace Update ILM N N LEF N Y Encounter Tech File N N Timing Libraries N N Timing Constraints Y Y Stamp Models N N I/O Assignment File Y N loadIoFile Partition File Y N specifyPartition Floorplan File Y N loadFPlan Placement File Y N restorePlace Routing File Y N restoreRoute Special Route File Y Y Use loadSpecialRoute to replace May 2005 How loadLefFile -incremental loadTimingCon -incr 96 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs Type Replace Update How DEF Y Y defIn (use -scanChain option to update scan chains) TDF Y Y tdfIn PDEF Y Y pdefIn * Encounter loads information for display only. You cannot edit it. May 2005 97 Product Version 4.1.5 Encounter User Guide Importing and Exporting Designs May 2005 98 Product Version 4.1.5 Encounter User Guide 5 Flip Chip and Area I/O This chapter presents the following topics: ■ Overview on page 100 ■ Flip Chip Flow in Encounter on page 102 ■ APD Bump Flow on page 108 ■ Tile Flow on page 120 ■ Reducing Data Size for APD Import (Bypass Flow) on page 127 ■ Routing Bumps to I/O Driver Cells (Hierarchical Area I/O Flow) on page 128 ■ Splitting Wires in Metal Layers on page 128 ■ Testing the Package Routing Feasibility on page 130 ■ Cross Probing Bumps on page 131 ■ Differentiating Area I/O and Peripheral I/O on page 131 ■ Swapping Signals on page 132 ■ Creating Differential Routing to Signal Bumps on page 134 ■ Examples and Report Files on page 136 ■ Tile Libraries and LEF Files on page 142 ■ Useful Tasks on page 144 May 2005 99 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Overview Flip chip is a methodology for placing I/O bumps and driver cells over the entire chip area in either a boundary (peripheral I/O) or core (area I/O) configuration. The Encounter flip chip design handles bump arrays, I/O drivers, electrostatic discharge cells (ESDs), and routing information. Power, ground, and signal assignments are made after the bumps are placed. Bump Array Power bump (red) Ground bump (yellow) Signal bump (blue) Note: Flip chip is sometimes referred to as area I/O placement in Encounter documentation. Area I/O placement is a subset of flip chip. Related Packaging Tools Allegro® Package Designer 620 (APD) is a related packaging tool that interfaces with flip chip. You must have a separate license to run APD. The documentation for APD is provided in the Cadence Allegro® Package Designer 620 User Guide. Using this Chapter The flows in this chapter include steps with examples of how to use flip chip. ■ For general flip chip flow information, see “Flip Chip Flow in Encounter” on page 102. ■ For information on a specific type of flow, see one of the following sections: ❑ APD Bump Flow on page 108 ❑ Area IO Flow on page 115 ❑ Peripheral IO Flow on page 117 ❑ Tile Flow on page 120 May 2005 100 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ■ For a list of tasks contained within the flows, see “Useful Tasks” on page 144. Related Flip Chip Information ■ Text commands For information on the flip chip commands, see the “Flip Chip Commands” chapter of the Encounter Text Command Reference. ■ Menu Commands and Forms For information on the FlipChip menu forms, see the “FlipChip Menu” chapter of the Encounter Menu Reference. Before You Begin Before using flip chip, the following information is required: ■ ■ Parameter data for: ❑ Bumps ❑ I/O drivers APD interface files Note: You must have a license for APD. Results Once all parameters have been assigned, a routing feasibility test is performed using the APD interface with Encounter. A report is generated that determines whether the routing package is feasible. For more information, see Testing the Package Routing Feasibility on page 130. May 2005 101 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Flip Chip Flow in Encounter The following figure shows the general Encounter flip chip flow including sub flows. For information on the APD tool, see the Cadence Chip I/O Planner User Guide. Encounter Verilog Netlist APD1 LEF File VCE (Virtuoso) VCE–OA 1 IO_FILE Load Floorplan IO_PLACE Tile (LEF) 2 APD Bump Tile Flow DEF Bump APD Read LEF/DEF Define Bumps 3 Edit Bumps 4 Check Routing Feasibility Assign Bumps/ RDL 5 Add Stripes Route Feasibility 6 Place I/O / Assign Bumps Cross Probing2 7 Connect Power/Ground Verification/ Export Package Design Partition Place Design Block Design Route Design Verify Connectivity RC Extraction APD-based Bypass Flow3 using -nocorecells option of the defOut command Timing Analysis Update Power Output Files 1 License Required 3 2 Typical Encounter Flow See Cross Probing Bumps on Bypasses FlipChip menu (see Reducing Data Size for APD Import (Bypass Flow) on page 127) May 2005 102 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Flow Steps 1. Load the floorplan. Load the floorplan as in a typical Encounter flow. Note: The floorplan information can be passed to APD through the DEF file. The following files are imported during this step: ❑ Verilog netlist A Verilog structural netlist is required for the design connectivity. No bumps are allowed in the netlist since they are physical cells. ❑ LEF File The LEF input files must contain the normal technology information, standard cell macros plus the IO PAD, and bump LEFS. The LEF BUMP MACRO must contain CLASS COVER BUMP. The LEF IO Driver cells must contain CLASS PAD (periphery I/O) or CLASS PAD AREAIO (area I/O). For more information, see Differentiating Area I/O and Peripheral I/O on page 131. Text Command: loadLefFile ❑ OA database via Virtuoso (VCE) The Virtuoso Chip Editor (VCE) can be used through the OpenAccess (OA) 2.0 database. Note: This is a specialized flow. The VCE data should be imported as flat so the routes can be extracted. ❑ IO_FILE, IO_PLACE, or DEF Bump file Import either the IO_FILE, IO_PLACE, or DEF Bump file ❍ The IO_FILE contains bumps, I/O rows (optional), and I/O instances (optional). For an example IO_FILE, see “IO_FILE Example” on page 136. Text Command: loadIoFile ❍ The IO_PLACE file can be used for specific placement of peripheral I/Os or double I/O rows. Text Command: loadIoFile May 2005 103 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ❍ The DEF file can be used to import bumps Text Command: defIn 2. Define the bumps using either the bump flow or the tile flow. ❑ Bump Flow— See “Bump Flow Steps” on page 108. The area I/O flow supports several methods to define the bumps: ❑ ❍ Bump Matrix Generation Use the bump matrix generator. These bumps will be assigned later in step 6. ❍ IO_FILE Generation Generate an IO_FILE that contains the x and y locations of the bumps along with the x and y locations of the I/O rows. The I/O rows are the rows or sites into which the I/O driver cells are placed. These bumps may or may not be assigned to signals at this time. ❍ Define Tiles Define a tile (CLASS COVER BUMP) that contains pins representing bumps. ❍ APD Bump Generation Use APD to generate the bump matrix or other DEF input file, and pass the bumps via a DEF instance. Tile Flow—See “Tile Flow Steps” on page 121. Tiles are defined as a LEF COVER macros. Use the following flip chip forms to modify tiles: ❍ Setup Chip IO ❍ Select Tile 3. Edit the bumps. Use the following flip chip forms and menu commands to edit bumps: ❑ Unassign Bump/Tile Pin ❑ Swap Signals ❑ Change Orientation 4. Check the routing feasibility using APD. The APD packaging tool interfaces to Encounter via LEF/DEF files. Once the bumps are assigned, use either the ChipIO Route Feasibility flip chip form or the chipioRoutability command to send the bump matrix to APD to test the routing May 2005 104 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O feasibility of the bumps to the package. APD will return a report and Encounter will highlight any bumps that cannot be routed to the package. Two APD files are required: ❑ *.cio ❑ *.ldf For more information, see the Cadence Chip I/O Planner User Guide. 5. Add stripes. Generate the power stripes on the chip using the addStripe text command. 6. Place driver cells and assign bumps. Use the placeAIO -assignBump command and option to place the I/O driver cells into the rows/sites closest to the corresponding bumps. If the bumps are not assigned at this time, this command can also be used to assign the bumps and also place all of the standard cells, if requested. 7. Connect the power and ground bumps. Use the fcroute command to connect the power and ground bumps to the stripes, and connect the signal bumps to the IO driver cell specified in the netlist. Note: If you want to view the flight lines before you route the bumps, you must first be in the Floorplan view. Then, use the left mouse button to click on the bump. Note: The remainder of the flow is similar to the typical Encounter flow. 8. Partition the design. Bumps, bump routing, power routing, and I/O driver cells can be pushed down as blockages into the partition. Text Commands: ❑ specifyPartition ❑ handlePtnAreaIo 9. Place the design. Place the design using the placeAIO command. 10. Route the design. NanoRoute (globalDetailRouteBatch command) can be used to connect the regular nets in the design. 11. Verify the connectivity May 2005 105 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Verify the bump (physical cells) connections to the logical cells using the verifyConnectivity command. 12. Run extraction. Extract the RC data using either the runQX command or the extractRC command and then generate a SPEF file. The runQX command input is the DEF output file which contains the bumps that are not present in the original Verilog file. You can create a Verilog output file containing bumps to match the runQX command SPEF. Note: You can also create a defout file and convert the bumps to pins so you do not have to create a physical verilog. Text Commands: ❑ runQX ❑ saveNetlist -phys -includeBumpCell 13. Do a timing analysis. The timing analysis report is the same as in the normal Encounter flow. Text Command: ❑ reportTA 14. Update the power. Update the power. In a flip chip design there will be multiple power sources. Text Commands: ❑ autoFetchDCSources ❑ savePadLocation ❑ updatePower 15. Output the files. Write out the DEF, Verilog, OpenAccess, SPEF, and GDSII files. The defOut command contains the -nocorecells option to reduce the data sent to APD. For more information, see the “Reducing Data Size for APD Import (Bypass Flow)” on page 127. Text Commands: ❑ defOut -nocorecells ❑ saveNetlist ❑ oaOut May 2005 106 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ❑ rcOut -spef ❑ streamOut. May 2005 107 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O APD Bump Flow The following figure shows the bump flow, which is a sub flow of the Flip Chip Flow in Encounter on page 102. Bump Flow Encounter 1 Import Design 2 Bump Setup 3 I/O Driver Row Setup 4 Assign Signals 5 Assign Power/Ground 6 Route Feasibility APD* * License Required *.cio route_feasibility.rpt route_feasibility.cio Yes Problems? No Bump Flow Steps 1. Import the design. Load the Verilog netlist and LEF files into Encounter. For more information about importing a design, see the Design Import form in the Encounter Menu Reference. 2. Set up the bumps. May 2005 108 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Use the Setup Chip IO (Bump Array) flip chip form to set up the bump array. The following figure shows the use of this form and the resulting bump array. 1 3. Set up the I/O driver rows. Use the Setup Chip IO (IO Driver Row) flip chip form to set up the driver rows. Figures 5-1 and 5-2 show the use of this form and the resulting driver rows. The base unit for Number of Sites is determined by the value of Total in the Site to be Created panel. This information comes from the LEF file. Thus, selecting 2 for Number of Sites creates a site twice as large as the base unit. In the figure, the Number of Sites for the lower box is set to 2 while the value for the upper box is set to 1. May 2005 109 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O 1 Number of Sites set to 1 Number of Sites set to 2 4. Assign signals to bumps. Use the Assign Signals flip chip form to assign the signals to the bumps. The following figures shows the use of this form: ❑ “Before Signal Assignment” on page 111 ❑ “After Signal Assignment” on page 112 The selection of the In Select Set allows you to select a particular bump (outlined box) for signal assignment. Bumps with signals assigned to them change to blue-filled squares. Note: You can also select Closest to automatically assign nets to the closest bump. May 2005 110 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Figure 5-1 Before Signal Assignment 1 Before Signal Assignment May 2005 111 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Figure 5-2 After Signal Assignment 1 After Signal Assignment 5. Assign power and ground to bumps. May 2005 112 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Use the Assign Power/Ground Bumps flip chip form to assign power and ground to bumps. Power bumps are red-filled squares. Ground bumps are yellow-filled squares. The following figure shows the use of this form to set ground bumps. 1 6. Do a route feasibility analysis. Use either the CIOP Route Feasibility flip chip form or the chipioRoutability command to test the routability of the bumps. APD creates two files from this analysis: ❑ route_feasibility.rpt An ASCII report file which can be viewed using the View Report File flip chip form. The Encounter GUI highlights the non-routable bumps contained in the report file with yellow squares. See “Route Feasibility Report” on page 138 for an example. ❑ route_feasibility.cio A package binary file created by APD. May 2005 113 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O If there are problems with routing, you can make adjustments to your design and begin this flow again. Otherwise, the routing is feasible, and you can proceed with the design. Note: APD requires a separate license. May 2005 114 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Area IO Flow For Area IO designs, bumps are placed within the core area of the design, and the bonding pads are not built into the bump cells. This means that the bump cells require routing to the pads. To create an Area IO design, complete the following steps: 1. Load the floorplan. Use the Load FPlan File form to load the floorplan file. 2. Define the bumps. Use the Setup Chip IO (Bump Array) form to set up the bump array. 3. Assign signals, power, and ground to the bumps. ❑ Use the Assign Signals form to assign the signals to the bumps. Signal bumps are blue-filled squares. ❑ Use the Assign Power/Ground Bumps form to assign power and ground to bumps. Power bumps are red-filled squares. Ground bumps are yellow-filled squares. 4. Create IO driver rows. Use the Setup Chip IO (IO Driver Row) form to set up the driver rows. 5. Place Area IO pads and standard cells. Use the Place Area I/O form to place I/O driver cells. 6. Check the route feasibility to ensure that the bumps can be routed to the package. Use the CIOP Route Feasibility form to test the routability of the bumps. 7. Create power rings and stripes. ❑ Use the Add iRings form to create rings around the core area and around the power and ground bumps. ❑ Use the Add iStripes form to create stripes that connect to the power and ground bumps. 8. Route I/O cells. Use the Route Flip Chip Signal form to connect I/O cells to the bumps. 9. Route power to the bumps. May 2005 115 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Use the Route Flip Chip Power form to connect the power stripes and rings to the bumps. Note: The remainder of this flow is similar to the typical Encounter flow. 10. Route signal nets. Use the NanoRoute form to route the signal and clock nets in the design. 11. Write DEF. Use the Save DEF form to write out the DEF information. Note: You only need to perform this step if you plan to use runQX to extract parasitics in the next step. 12. Extract parasitics. Use the Extract RC form to extract parasitics. 13. Analyze timing. Use the Timing Analysis form to analyze timing. 14. Perform power analysis. Use the Power Analysis Statistical Mode form to estimate power consumption. 15. Add metal fill. Use the Add Metal Fill form to add metal so that the design meets metal density requirements. 16. Verify the design. ❑ Use the Verify Connectivity form to verify that there are no open nets or loops in the design. ❑ Use the Verify Metal Density form to verify that metal density is within acceptable limits. ❑ Use the Verify Geometry form to verify that the physical layout of the design is within acceptable limits. 17. Write out the design data. You can write the design in one of the following formats: ❑ Use the Save OA Database form to save the data in OpenAccess format. ❑ Use the Save DEF form to save the DEF information to a file. ❑ Use the GDS Export form to create a GDSII Stream file version of the database. May 2005 116 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Peripheral IO Flow For Peripheral IO designs, bumps and IO driver cells are placed at the periphery of the core area of the design. This means that the bump cells require routing to the IO driver cells. To create a Peripheral IO design, complete the following steps: 1. Load the floorplan. Use the Load FPlan File form to load the floorplan file. 2. Define the bumps. Use the Setup Chip IO (Bump Array) form to set up the bump array. 3. Assign signals, power, and ground to the bumps. ❑ Use the Assign Signals form to assign the signals to the bumps. Signal bumps are blue-filled squares. ❑ Use the Assign Power/Ground Bumps form to assign power and ground to bumps. Power bumps are red-filled squares. Ground bumps are yellow-filled squares. 4. Move Peripheral IO pads. Peripheral IO pads are placed randomly along the periphery of the design when it is loaded. Use the Move/Resize/Reshape icon to manually move the Peripheral IO pads to new locations. 5. Check the route feasibility to ensure that the bumps can be routed to the package. You must send the floorplan DEF file to APD for RDL routing and route feasibility. Use the CIOP Route Feasibility form to test the routability of the bumps. The DEF file that is created contains the 45 degree routes. 6. Snap/split route. Use the snapRoute command to snap the 45 degree routes created by APD to the manufacturing grid. Use the splitRoute command to split 45 degree routes that are wider than the maximum width. snapRoute and splitRoute are currently undocumented. 7. Create power rings and stripes. ❑ May 2005 Use the Add Rings form to create rings around the core area and around the power and ground bumps. 117 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ❑ Use the Add Stripes form to create stripes that connect to the power and ground bumps. 8. Route power to the bumps. Use the Route Flip Chip Power form to connect the power stripes and rings to the bumps. Note: The remainder of this flow is similar to the typical Encounter flow. 9. Place standard cells. Use the Place form to run Amoeba placement to complete the placement of the entire design after floorplanning. 10. Route signal nets. Use the NanoRoute form to route the signal and clock nets in the design. 11. Write DEF. Use the Save DEF form to write out the DEF information. Note: You only need to perform this step if you plan to use runQX to extract parasitics in the next step. You must run QX if you are using 45 degree routes. 12. Extract parasitics. ❑ Use the Extract RC form to extract parasitics if you are not using 45 degree routes. ❑ Use Fire &Ice QX to extract parasitics if you are using 45 degree routes. For more information, see the Fire & Ice QX Gate-Level Extraction manual. 13. Read SPEF data into the design. Use the Load Spef File form to read in SPEF information. 14. Perform power analysis. Use the Power Analysis Statistical Mode form to estimate power consumption. 15. Analyze timing. Use the Timing Analysis form to analyze timing. 16. Add metal fill. Use the Add Metal Fill form to add metal so that the design meets metal density requirements. 17. Use the wire editor to finish incomplete routes or to modify routes that have DRC violations. May 2005 118 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O For information on using the wire editor, see Editing Wires. 18. Use Virtuoso Chip Editor to perform chip finishing tasks. For more information, see the Virtuoso Chip Editor User Guide. 19. Verify the design. ❑ Use the Verify Connectivity form to verify that there are no open nets or loops in the design. ❑ Use the Verify Metal Density form to verify that metal density is within acceptable limits. ❑ Use the Verify Geometry form to verify that the physical layout of the design is within acceptable limits. 20. Write out the design data. You can write the design in one of the following formats: ❑ Use the Save OA Database form to save the data in OpenAccess format. ❑ Use the Save DEF form to save the DEF information to a file. ❑ Use the GDS Export form to create a GDSII Stream file version of the database. May 2005 119 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Tile Flow This section describes the tile flow. This flow is a sub flow of the Flip Chip Flow in Encounter on page 102 Note: You must have a tile library in order to use the tile flow. Two tile flows are supported as shown in the following figure. ■ No Netlist Bypasses the netlist and LEF design import step. ■ Netlist Includes steps for importing the netlist/LEF files and assigning signals. The tile flow uses a LEF tile macro, which defines SITEs (PROPERTY DRIVER_SITE) for the I/O driver cells, ESD clamps, and defines BUMPs as LEF PINs. The tiles are flattened after placement and before routing (that is, a BUMP will be created for each PIN in the LEF file). This also requires a LEF BUMP after flattening. Since the tile is a physical instance, it is not included in the Verilog netlist. You assign the tile pin (BUMP) connections by completing the steps shown in the flow. Tile Flow Encounter 1 Import Design** 2 Tile Setup 3 Select Tiles 4 Place Tiles 5 Assign Signals** 1 Flatten Tiles 2 Route Feasibility APD* * License Required ** Netlist Flow only *.cio route_feasibility.rpt route_feasibility.cio Yes Problems? No May 2005 120 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Tile Flow Steps 1. Import the design. Load the Verilog netlist and LEF files into Encounter. If you are using the No Netlist Flow, begin the flow at the next step. For more information about importing a design, see the Design Import form in the “Design: Design Import” chapter. 2. Set up the tiles. Use Setup Chip IO (Tile Based) flip chip form to create the tile placement grid. The following figure shows the use of this form to create the tile grid. Enter information in the Bump Grid and Edge Spacing panels.The grid can be removed after placement is done. The grid will be overwritten if a new grid is created. If you are using the No Netlist Flow, you must enter the following information in the Chip Info panel: May 2005 121 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ❑ Die Width/Height ❑ Core Width/Height ❑ LEF files ❑ Design Name 1 3. Select the tiles. Use the Select Tile flip chip form to select the tiles from the tile library. The library contains prearranged tiles, which are actually just different bump configurations (red, yellow, and blue circles). The following color scheme is used to represent each type of bump: ❑ May 2005 Red: Power 122 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ❑ Yellow: Ground ❑ Blue: Signals 1 4. Place the tiles. In this step, you place selected tiles in the floorplan view. See the following figure for an example of tile placing. Note: You must click the Add Tile icon from Encounter Tools to place tiles. Add Tile icon The following operations are available in this step by using your mouse and keyboard shortcuts: May 2005 123 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ❑ Place a single tile by clicking the tile ❑ Place more than one tile by area ❑ Delete tiles ❑ Delete tile pin (bump in tile) ❑ Move tiles 1 5. Assign signals. Use the Assign Signals flip chip form to select tiles for signal assignment. The following figure shows the use of this form to assign signals to tiles. When a bump is assigned to a signal, it changes from a blue-filled circle to a blue-filled square. May 2005 124 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O See Manually Assigning Signals to Tile Pins on page 127 for information about bypassing the default order of the signals as defined in the LEF file. Signal assigned to bump 1. Flatten the tiles. ■ Use either the Flatten Tiles flip chip form or the flattenTile command to flatten the tile instances. The tile grid is an overlay to help with placement. Once flattened, the tile grid will be removed. The following figure shows flattened tiles. All connected power and ground bumps are preserved. May 2005 125 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Important You must flatten the tiles before doing a route feasibility analysis. 1 2. Do a route feasibility analysis. Two files are created via APD: ❑ route_feasibility.rpt ❑ route_feasibility.cio See “Testing the Package Routing Feasibility” on page 130 for more information on routing feasibility. If there are problems with routing, you can make adjustments to the design and begin this flow again. If the routing is feasible, you can proceed with the design. May 2005 126 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Manually Assigning Signals to Tile Pins In addition to using the Signal Assign form to assign signals to tiles, you can select the signals and then click on the tile pin to make the assignment. This allows you to bypass the default order of the signals as defined in the LEF file. To use this method 1. Click on FlipChip – Assign Signals to display the Signal Assign form. 2. Select some signals from the list to highlight the appropriate tiles in the design window. 3. Click on the tile pin. 4. Click on the Assign button. Calculate Core Area The following procedure allows you to create rectangles that designate regular core space if you are using the non-netlist flow. The software adds up the total area of these rectangles and displays the amount of total core area in the Tile Summary Report. To specify the core area 1. Click on the Add Partial Placement Blockage icon on the left side of the Encounter window. Note: This use of this icon is specific to defining the core area in the non-netlist flow and does not affect it’s usual application in a regular flow. 2. Use the mouse to draw one or more rectangles over the area you want to designate as core area. 3. Press Ctrl-t to view the summary report which displays the total amount of core space. You can use the Edit – Highlight menu items to make the set of rectangles more visible. For an example of the report, see Tile Summary Report on page 139. Reducing Data Size for APD Import (Bypass Flow) You can use the -noCoreCells option of the defOut command to reduce data size for import into APD. The syntax is as follows: May 2005 127 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O defOut -noCoreCells This flow bypasses the tile and bump flows (see Flip Chip Flow in Encounter on page 102). Important You should use the -noCoreCells option whenever you are creating a DEF file for APD. Routing Bumps to I/O Driver Cells (Hierarchical Area I/O Flow) The hierarchical area I/O flow allows you to route the bumps, using the fcroute command, to I/O driver cells and then push down (partition) this data into a lower level. The text command is: handlePtnAreaIo buffer_name This command pushes down data in the partition as follows: ■ Bumps become routing blockages ■ I/O cells become placement and routing blockages ■ An internal pin is created over the I/O cell pin ■ A boundary pin is created ■ A buffer is created between the internal pin and the boundary pin Note: If you want to view the flight lines before you route the bumps, you must first be in the Floorplan view. Then, use the left mouse button to click on the bump. Splitting Wires in Metal Layers If wires that route the bumps are wider than the LEF MAXWIDTH parameter, you can use the editFixWideWires command to split them. For wires splitting in specific metal layers, you can modify a LEF layer with a specific MAXWIDTH parameter as shown in the following example for LAYER M5. LAYER M5 TYPE ROUTING ; DIRECTION VERTICAL ; WIDTH 0.70 ; SPACING 0.70 ; PITCH 1.4 ; CAPACITANCE CPERSQDIST 0.0001000 ; RESISTANCE RPERSQ 0.010000 ; May 2005 128 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O MAXWIDTH 8.0 ; END M5 After running the editFixWideWires command, wires in this layer are split to satisfy the MAXWIDTH value in the LEF file. The following figure shows how a 16.0 micron wire is split using this LEF layer code and the editFixWideWires command. The resulting split wires will be slightly less than 8.0 microns each. There will be a split spacing between the wires such that the total width is 16.0 microns. The split spacing is automatically determined by considering the MINSPACING, PARALLEL RUNLENGTH SPACING, and DENSITY constraints. The split spacing will be greater than or equal to the MINSPACING constraint. There is no manual control for the split spacing parameter. 16.0 micron width wire becomes two < 8.0 micron width wires < 8.0 micron width wire 16.0 microns spacing < 8.0 micron width wire May 2005 129 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Testing the Package Routing Feasibility You can test the package routing feasibility of the design using APD. Note: A separate license is required for APD. Use the CIOP Route Feasibility flip chip form or the chipioRoutability command to test the routing feasibility. Two APD input files are required: ❑ *.cio ❑ *.ldf For more information, see the Cadence Chip I/O Planner User Guide. Two files are created via APD: ■ route_feasibility.rpt This is an ASCII report file which describes non-routable bumps. The report file can be viewed with the View Report File form. For an example report file, see Route Feasibility Report on page 138. ■ route_feasibility.cio This is the routing feasibility file which interfaces with (is loaded into) APD. May 2005 130 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Cross Probing Bumps After running a Route Feasibility Analysis (see “Testing the Package Routing Feasibility” on page 130), there will be an APD database generated from the analysis run. You can invoke APD to read the database which will display the same design at the top level, showing only the IC bumps and package ball map. Use the following guidelines for cross probing bumps: ■ ChipIO should be set to the highlight mode. ■ For Encounter, you can select any bump(s), then choose FlipChip – Cross Probe Bump from the Encounter menu to view the corresponding bump(s) in the APD artwork window. For more information, see the Cross Probe Bump form in the “Flip Chip” chapter of the Encounter Menu Reference. Differentiating Area I/O and Peripheral I/O The LEF IO Driver cells must contain CLASS PAD (for peripheral I/O) or CLASS PAD AREAIO (for area I/O). Note: Depending on your design style, you may need to modify the LEF macro CLASS statement. ■ Area I/O CLASS PAD AREAIO CLASS PAD AREAIO is used by the assignBump and placeAIO commands. ■ Peripheral I/O CLASS PAD CLASS PAD is used by the io_placer to place the pads along the boundary. By default, the CLASS PAD macro is automatically placed along the boundary when the configuration file is read. You can also load a file with the loadIoFile command. LEF MACRO CLASS PAD and PAD AREAIO To support a peripheral I/O-driver with flip-chip bumps flow, PAD AREAIO cells are allowed outside the core box. May 2005 131 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ■ LEF MACRO CLASS PAD has the bonding pad built into the cell. ■ LEF MACRO PAD AREAIO has no bonding pad built-in, so it requires routing to the bump. Swapping Signals Signal swapping allows you to swap signals between bumps. Either one or both of the bumps to be swapped must be assigned. The figures below show signal swapping as follows: ■ Highlight the Bumps on page 133 ■ Signals Swapped on page 134 May 2005 132 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Highlight the Bumps The following figure shows two highlighted bumps with signals to be swapped (bumps A and B). The signals are swapped by selecting FlipChip – Swap Signals. Bump A Bump B Note: If you want to view the flight lines before you swap signals, you must first be in the Floorplan view. Then, use the left mouse button to click on the bump. May 2005 133 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Signals Swapped The following figure shows the signals after swapping. Bump A Bump B Creating Differential Routing to Signal Bumps Differential routing creates wires of the same length or configuration between a set of sources and targets. Use the Route Flip Chip Signal form to specify differential routing parameters. You can create a constraint file to specify differential pair definitions, as well as shield net definitions and differential group definitions. The following example shows how to set up a constraint file: May 2005 134 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ###### Differential pair definition ###balanced routing with shielding out[10] PAIR out[11] SHIELDNET VDD ###balanced routing without shielding out[8] PAIR out[9] ###### Shield net defintition out[5] SHIELDNET VDD out[3] SHIELDNET VSS ###### Differential group definition out[15] GROUP out[16] out[17] out[18] resetn clk GROUP out[12] out[13] May 2005 135 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Examples and Report Files IO_FILE Example The following sample is an IO_FILE file showing bumps, I/O rows, and I/O instances. Format definitions follow the sample. BumpCell: BUMPCELL Rect 1 Layer 6 0.000 0.000 80.000 80.000 Bump: bumpAry_16_3_3 BUMPCELL 697.440 696.800 DI[1] Bump: bumpAry_15_2_3 BUMPCELL 497.440 696.800 DO[1] Bump: bumpAry_14_1_3 BUMPCELL 297.440 696.800 DO[0] Bump: bumpAry_13_0_3 BUMPCELL 97.440 696.800 SO Bump: bumpAry_12_3_2 BUMPCELL 697.440 496.800 Bump: bumpAry_11_2_2 BUMPCELL 497.440 496.800 Bump: bumpAry_10_1_2 BUMPCELL 297.440 496.800 Bump: bumpAry_9_0_2 BUMPCELL 97.440 496.800 Bump: bumpAry_8_3_1 BUMPCELL 697.440 296.800 DI[0] Bump: bumpAry_7_2_1 BUMPCELL 497.440 296.800 Bump: bumpAry_6_1_1 BUMPCELL 297.440 296.800 SI Bump: bumpAry_5_0_1 BUMPCELL 97.440 296.800 Bump: bumpAry_4_3_0 BUMPCELL 697.440 96.800 CLK Bump: bumpAry_3_2_0 BUMPCELL 497.440 96.800 Bump: bumpAry_2_1_0 BUMPCELL 297.440 96.800 SM Bump: bumpAry_1_0_0 BUMPCELL 97.440 96.800 IORow: IORow: IORow: IORow: IOInst: IOInst: IOInst: IOInst: IOInst: IOInst: IOInst: IOInst: IOROW_1 IOROW_2 IOROW_3 IOROW_4 520.100 520.100 119.700 119.700 596.400 126.000 596.400 126.000 IO1 IO1 IO1 IO1 R0 R0 R0 R0 V V V V 100.800 100.800 100.800 100.800 2 2 2 2 test_clk/clk/inbuf 520.100 126.000 R0 -fixed test_clk/test/smbuf 119.700 126.000 R0 -fixed test_clk/test/sibuf 119.700 226.800 R0 -fixed test_clk/test/sobuf 119.700 697.200 R0 -fixed ioall/io_A/inbuf_0/inbuf 520.100 226.800 R0 -fixed ioall/io_A/inbuf_1/inbuf 520.100 596.400 R0 -fixed ioall/io_B/outbuf_0/outbuf 119.700 596.400 R0 -fixed ioall/io_B/outbuf_1/outbuf 520.100 697.200 R0 -fixed Format Definitions ■ I/O Rows: IOROW: iorow_name x y site_name [orient] [ [H | V] step num] iorow_name Specifies the row name. x y Specifies the x and y coordinates, in microns, of the origin. site_name Specifies the site name. This must be defined in the LEF file. May 2005 136 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O orient Specifies the row orientation. H | V Specifies either a Horizontal or a Vertical row. step Specifies the site width or height (depending on orientation), in microns, of the row. num Specifies the number of sites in the row (multiply by step for row length). ■ I/O instances: IOInst: inst_name [x y [orient] [-fixed]] inst_name Specifies the instance name. x y Specifies the x and y coordinates, in microns, of the origin. orient Specifies the instance orientation. -fixed Sets the placement status to fixed. For more information, see the addAIORow command in the “Flip Chip Commands” chapter of the Encounter Text Command Reference. LEF and CML Example Files The following file examples are for the CIOP Route Feasibility flip chip form and the chipioRoutability command, which are used to test routing feasibility. LEF File Example This file points to the LEF file locations. DEFINE abccdr LEFFILE ../lef/atechfile.lef LEFFILE ../lef/abumpfile.lef LEFFILE ../lef/xyzcdr.lef CML File Example The CML file is required for APD. It contains information similar to that found in the LEF file. VERSION 5.20 NAMESCASESENSITIVE OFF May 2005 137 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O MACRO BUMPP MACROCLASSNAME COVER BUMP EXTENTS (102.00,102.00) DEFINESDRIVER PIN PAD UNSPEC PAD ORIGIN(51.00,51.00) DIM(102.00,102.00) END BUMPP MACRO BUMPG MACROCLASSNAME COVER BUMP EXTENTS (102.00,102.00) DEFINESDRIVER PIN PAD UNSPEC PAD ORIGIN(51.00,51.00) DIM(102.00,102.00) END BUMPG MACRO BUMPCELL MACROCLASSNAME COVER BUMP EXTENTS (102.00,102.00) DEFINESDRIVER PIN PAD UNSPEC PAD ORIGIN(51.00,51.00) DIM(102.00,102.00) END BUMPCELL Route Feasibility Report The route_feasibility.rpt file is an ASCII text file which is created with the CIOP Route Feasibility flip chip form. You can view this file by using the View Report File flip chip form. The following sample is a partial report file showing routing errors. A graphical view of this report is shown in the following figure. In the figure, non-routable bumps have yellow squares surrounding them which correspond to the report file. ################# # Route Results # ################# 20 ABC1CK "Fail: Net ABC1CK not scheduled due tounresolvable cross near x 14605. y -6238." SPARE3 "Fail: Net SPARE3 not scheduled due tounresolvable cross near x 13335. y -4464.889" QRATE_R "Fail: Net QRATE_R not scheduled due to overloaded channel near x 4416.804 y -1258.1" XYZOUT_X "Fail: Net XYZOUT_X not scheduled due to overloaded channel near x 3192.657 y -3900." XYZOUT_Y "Fail: Net XYZOUT_Y not scheduled due to overloaded channel near x 2540.726 y -3900." LD_4 "Fail: Net LD_4 not scheduled due to overloaded channel near x 132.931 y -3900." LD_5 "Fail: Net LD_5 not scheduled due to overloaded channel near x -851.278 y -3900." CNTRTP "Fail: Net CNTRTP not scheduled due to overloaded channel near x -4400. y -3498.382" ETOGGLE_R "Fail: Net ETOGGLE_R not scheduled due to overloaded channel near x -4400. y 1401.133" FIX10 "Fail: Net FIX10 not scheduled due to overloaded channel near x -4400. y 1812.881" FORCE_1 "Fail: Net FORCE_1 not scheduled due to overloaded channel near x -4400. y 2208.791" HDIN_XN "Fail: Net HDIN_XN not scheduled due to overloaded channel near x -2533.542 y 3700." HDIN_VN1 "Fail: Net HDIN_VN1 not scheduled due to overloaded channel near x -2282.605 y 3700." HDOUT_VN2 "Fail: Net HDOUT_VN2 not scheduled due to overloaded channel near x 1961.415 y 3700." HDOUT_VN3 "Fail: Net HDOUT_VN3 not scheduled due to overloaded channel near x 2319.069 y 3700." HDOUT_VN4 "Fail: Net HDOUT_VN4 not scheduled due to overloaded channel near x 3034.379 y 3700." MRESET_R "Fail: Net MRESET_R not scheduled due to overloaded channel near x 4434.049 y 1453.288" TSTLVDS_VN "Fail: Net TSTLVDS_VN not scheduled due to overloaded channel near x -359.91 y -3900." TSTMUX_UX1 "Fail: Net TSTMUX_UX1 not scheduled due to overloaded channel near x -4400. y -1850.419" TSTMUX_VX "Fail: Net TSTMUX_VX not scheduled due to overloaded channel near x -4400. y -1377.986" TSTPECL_RN "Fail: Net TSTPECL_RN not scheduled due to overloaded channel near x -4400. y -330.36" SYSCLK_RP "Fail: Net SYSCLK_Z not scheduled due to overloaded channel near x -1676.35 y 3700." May 2005 138 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Non-routable bumps (yellow squares) Tile Summary Report When you select Tile Summary Report from the FlipChip menu, the Encounter console shows a report showing the ■ Amount of core area The core area is the amount of space occupied by the standard cells in the design. In a regular flow based on an imported netlist, the core area reflects the actual amount of space used in the design. In the non-netlist flow, the amount of core area reflects the total amount of space designated by rectangles that you draw using the Partial Placement Boundary icon. See Calculate Core Area on page 127 for more information. ■ Number of signals (Tile Signal Count) assigned to each tile May 2005 139 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O ■ Number of signals connected to each driver (Driver Signal/Cell Count Summary) Note: You can also view the report with the bindkey t or with the text command, ciopReportTilePinStatus command. The following example shows a summary report for a design in which the tiles are grouped into eight families used with 211 pins: Current Core Area Is ================= lvdsiv33v12 :L= bpubv33v12 :L= pecliv33v12 :L= peclov33v12 :L= vddc :L= vdd12vss :L= vssc :L= lvdsov33v12 :L= total :L= ================= 31785600.0 Square Microns Tile Signal Count ================== 0 D= 0 R= 0 U= 29 M= 0 0 D= 28 R= 52 U= 28 M= 0 16 D= 8 R= 0 U= 0 M= 0 8 D= 14 R= 0 U= 0 M= 0 0 D= 0 R= 0 U= 0 M= 0 0 D= 0 R= 0 U= 0 M= 0 0 D= 0 R= 0 U= 0 M= 0 28 D= 0 R= 0 U= 0 M= 0 52 D= 50 R= 52 U= 57 M= 0 End Signal Count ================== Total= Total= Total= Total= Total= Total= Total= Total= Total= 29 108 24 22 0 0 0 28 211 ===================== Driver Signal/Cell Count Summary========================== Driver Cell | Left | Down | Right | Up | Cell Total -------------------------------------------------------------------------------LVDSIFLV33S3T12F: 0/0 | 0/0 | 0/0 | 13/26 | 13 LVCTAPLV33S3T12F: 0/0 | 0/0 | 0/0 | 3/3 | 3 BPUB1P1BV33S3T12F: 0/0 | 28/28 | 52/52 | 28/28 | 108 PECLIDBV33S3T12F: 8/16 | 4/8 | 0/0 | 0/0 | 12 PECLODBV33S3T12F: 4/8 | 7/14 | 0/0 | 0/0 | 11 LVDSODLV33S3T12F: 12/24 | 0/0 | 0/0 | 0/0 | 12 LVDSRDLV33S3T12F: 1/4 | 0/0 | 0/0 | 0/0 | 1 -------------------------------------------------------------------------------Signal Total: | 52 | 50 | 52 | 57 | 160/211 May 2005 140 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O The Tile Signal Count section of the report contains the tile name, followed by the number of signal pins in the tile that are in each of the following quadrants: U L R D L: number of signal pins in the left quadrant D: number of signal pins in the down (lower) quadrant U: number of signal pins in the upper quadrant R: number of signal pins in the right quadrant M: (unused field) Total: the total number of signal pins in the tile Note: The last line of the report contains the total number of signal pins in each quadrant. May 2005 141 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Tile Libraries and LEF Files This section contains the following information: ■ Tile Library Loading Guidelines on page 142 ■ Tile Description File Format on page 143 Tile Library Loading Guidelines The following information provides general guidelines for determining how the tile library information in the LEF files is loaded into Encounter. Set environment variable TILE_PATH setenv TILE_PATH /usr1/john/tile_lib1:/usr1/john/tile_lib2:/cad/ tilelib3 Note: Use a : (colon) as the path separator. Set Tcl variable rda_ciop set rda_ciop(tile:rootdir) "/usr1/john/tile_lib1:/usr1/john/tile_lib2:/ cad/tilelib3" Note: Environment variable will overwrite Tcl variable. If neither of the above is specified, the default is a Tiles directory in the Encounter run directory. set rda_ciop(tile:rootdir) [file join [pwd] "Tiles"] In directories set with the rda_ciop variable, there can be one more level in the bump pitch name for filtering. For example, if there are subdirectories such as 200, 230, 250 under directory /usr1/john/tile_lib1 and the bump pitch is 200, then only tiles in /usr1/ john/tile_lib1/200 will be loaded. Directories should have a structure similar to the following example directories. May 2005 142 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O /usr1/john/tile_lib1/200/tile_family/tile_lib.lef /usr1/john/tile_lib1/200/tile_family/tile_info.txt /cad/tilelib3/fmily1/tile_lib.lef /cad/tilelib3/fmily2/tile_lib.lef Note: tile_info.txt is optional. It contains tile information for display only in the Select Tile form. Tile Description File Format The following example shows the tile description file format. # # TILE DESCRIPTION FILE FORMAT # # # keywords: LIBRARY, TILE, END TILE, END LIBRARY # # LIBRARY lib_name: where lib_name is the name of the library (or family) # # LIBRARY lib_name # Library description text starts here and ends at first TILE keyword. # # Begin a tile description TILE tile_name # Tile description starts here and ends at END TILE # end of tile description END TILE # Another tile TILE tile_name2 ... END TILE ... END LIBRARY May 2005 143 Product Version 4.1.5 Encounter User Guide Flip Chip and Area I/O Useful Tasks The following list of tasks provides links to procedures embedded in the flows which are described in this chapter: ■ Assign signals. on page 124 ■ Assign signals to bumps. on page 110 ■ Assign power and ground to bumps. on page 112 ■ Connect the power and ground bumps. on page 105 ■ Do a route feasibility analysis. on page 113 (Bump flow) ■ Do a route feasibility analysis. on page 126 (Tile flow) ■ Edit the bumps. on page 104 ■ Flatten the tiles. on page 125 ■ Import the design. on page 121 ■ Place driver cells and assign bumps. on page 105 ■ Place the tiles. on page 123 ■ Swapping Signals on page 132 ■ Set up the I/O driver rows. on page 109 May 2005 144 Product Version 4.1.5 Encounter User Guide 6 Partitioning the Design This chapter describes how to use the Partition menu forms to create and work with partitioned designs, including using the blackbox feature. This chapter presents the following topics: ■ Overview on page 146 ■ Flow Methodologies on page 147 ■ Specifying Partitions and Blackboxes on page 155 ■ Assigning Pins on page 166 ■ Inserting Feedthroughs on page 178 ■ Generating the Wire Crossing Report on page 186 ■ Estimating the Routing Channel Width on page 190 ■ Running the Partition Program on page 192 ■ Restoring the Top-Level Floorplan with Partition Data on page 194 ■ Concatenating Netlist Files of a Partitioned Design on page 195 ■ Saving Partitions on page 196 ■ Loading Partitions on page 197 May 2005 145 Product Version 4.1.5 Encounter User Guide Partitioning the Design Overview Most of the system-on-a-chip devices are designed in a traditional flat flow that avoids the effort to set up a design hierarchy. However, in multi-million gate designs, this could result in memory limitations and long runtime. Designs teams can develop and adopt a hierarchical flow to shorten the turnaround time on large designs. Designs can be divided into manageable partitions; each partition can be independently assigned to different design groups to be developed in parallel. May 2005 146 Product Version 4.1.5 Encounter User Guide Partitioning the Design Flow Methodologies Hierarchical design can be divided into three general stages: chip planning, implementation, and chip assembly. ■ Chip Planning Breaks down a design into block-level designs to be implemented separately. ■ Implementation This stage consists of two sub-stages: block implementation for a block-level design, and top-level implementation for a design based on block-level design abstracts and timing models. ■ Chip Assembly Connects all block-level designs into the final chip. This chapter covers the following methodologies in the partitioning area: ■ Top-down Methodology on page 148 ■ Bottom-up Methodology on page 151 May 2005 147 Product Version 4.1.5 Encounter User Guide Partitioning the Design Top-down Methodology The top-down methodology usually consists of top-down planning, implementation, and chip assembly stages. Use this methodologyto create a top-level or hierarchical floorplan from a flat floorplan based on fenced modules. In this approach the die size, shape, and I/O pads locations will drive block and partition placement. Block-level design size and pins will be generated based on the top-level floorplan. Chip Planning The following steps describe the most common flow for chip planning, which includes specifying partitions and blackboxes: 1. Import the entire design to be partitioned. Import the design into the Encounter environment. You can also include blackboxes. 2. (Optional) Define the blackboxes. If your design has blackboxes that are not specified in step 1, you can define them after reading in the netlist. You can also adjust the size of the blackboxes. For more information, see Defining Blackboxes on page 158. 3. Lay out the floorplan. Manually pre-place all modules that will become partitions or blackboxes. You can also generate an initial floorplan by running Amoeba placement, and bring all modules inside the core by generating the floorplan guide (using the Floorplan – Generate FP Guide menu command or the generateGuide text command). 4. Run power planning. 5. Specify the modules and blackboxes that will become partitions. You can further adjust blackbox size, if necessary. For more information, see Specifying Partitions and Blackboxes on page 155. 6. Run Amoeba placement. 7. (Optional) If your design has blackboxes, assign blackbox pins. If you run route-based blackbox pin assignment, trialRoute runs automatically before pin assignment. May 2005 148 Product Version 4.1.5 Encounter User Guide Partitioning the Design 8. (Optional) Insert feedthrough buffers. Insert feedthrough buffers into partitions to avoid routing nets over partition areas. This step is necessary for channelless or mixed designs. For more information, see Inserting Feedthroughs on page 178. Run Trial Route before this step if you want to run route-based feedthrough insertion. You must also run Trial Route if you want to display and generate a list of all nets that cross over the top of each partition (using the Show Wire Crossing menu command or the showPtnWireX text command). 9. Run Trial Route Depending on what stage of the design is in, such as prototyping, intermediate, tapeout, use the appropriate trialRoute option. For example the -floorplanMode option should be used for prototyping, or -highEffort should be used for tapeout mode. Use -handlePartition or -handlePartitionComplex only for channel-based, instead of channelless design. The results give the first order location of aligning the partition pins. 10. Partition the design. This generates pins for each partition and converts the partition modules to blocks. This step consists of three sub-steps: a. Assign partition pins. b. Budget timing for partition blocks. c. Push down power structure into partition blocks. If your design has multiple instantiated partitions, you should run the alignPtnClone text command before this step to make sure that all partition clones are well aligned with the master partition on a power mesh so you will not have any future problems when flattening the partitions. For more information, see Specifying Multiple Instantiated Partitions and Blackboxes on page 160. 11. Save the partition. This creates a directory for each block, and saves its netlist, floorplan, and budgeted constraints to this directory. For top-level designs, this also creates a directory containing the top-level netlist, floorplan, simple timing model, and physical abstract for each partition block or blackbox. Subsequent work should be done in these block-level and top-level directories for implementing the block-level and top-level designs, respectively. May 2005 149 Product Version 4.1.5 Encounter User Guide Partitioning the Design Tip You should do all design work in each saved partition directory, including the toplevel directory. Implementation and Chip Assembly After the chip planning is complete, the next stage is to implement the individual blocks. The detail of each block is implemented using the constraints for timing, size, and pin assignment determined during the planning stage. Block implementation should be done at a block directory that was generated by the savePartition step. At the completion of this step, block abstracts, timing models, DEF file, GDSII file should be generated for using in top-level implementation and chip-assembly. The next step is to implement the top-level designs with block model data, such as LEF, timing model, power model, and noise model. Finally, chip assembly is the last stage is that consists of bringing the detailed information for the top-level and all of the blocks together for full chip extraction, power, timing, and cross-talk analysis. The following is the generic flow to bring in all the top-level and block-level netlists and routing information: 1. Import the design. Import the design with all the updated top-level and block-level netlists. 2. Load the top-level floorplan used to partition the design in the top-down planning stage. 3. Commit partitions without pin assignment (using the commitPartition -noPinAssign text command). 4. Read in the top-level routing (using the defIn text command). 5. Read in the block-level routing information for each partition. Before reading in a block-level DEF file, you should change the partition view (using the Partition – Change Partition View menu command or the setTopCell text command). Repeat this step to bring in routing information for all partitions. 6. Change the view back to the top-level design. 7. (Optional) Flatten the partition (using the Partition – Unpartition menu command or the flattenPartition text command). May 2005 150 Product Version 4.1.5 Encounter User Guide Partitioning the Design Bottom-up Methodology The bottom-up methodology consists of implementation and assembly stages. In the bottomup methodology, the size, shape, and pin position of block-level designs will drive the top-level floorplanning. Implementation Each block in the design must be fully implemented. This includes place and route as well as clock, power, and I/O. This section covers the following topics: ■ Block Implementation on page 151 ■ Top-level Implementation on page 153 Block Implementation The size of a block-level design can be derived or adjusted using the Floorplan – Specify Floorplan menu command or the floorPlan text command. The Encounter software can support a rectilinear block level design. You can use the same procedure to create a rectilinear partition to create a rectilinear block-level design using the following steps: 1. Click on the Cut Rectilinear widget from the Tools area. 2. Move the mouse to an edge or corner of the module. 3. Left click and drag over the area. 4. Left click again to complete the cut. May 2005 151 Product Version 4.1.5 Encounter User Guide Partitioning the Design At a block level design the rectilinear information will be stored in a floorplan file as a CellPtnCutList syntax, for example: CellPtnCutList: execute_i 2 0.0000 142.5100 37.1200 181.4400 156.3800 154.9350 180.1800 181.4400 You can run the assignIoPins text command to assign I/O pins based on placement information. You can specify initial I/O pin placement in an I/O constraint file. For more information, see to the Generating the I/O assignment File section in the “Data Preparation” chapter of the Encounter User Guide. You can read in the I/O constraint file into the Encounter environment during the design import step, or use the loadIoFile text command after reading in the netlist. The I/O constraint file format currently does not support rectilinear block-level designs. If an I/O constraint file does not exist, an initial I/O pin placement can be derived from cell placement. After placing macros and standard cells, the Amoeba placer can internally call the assignIoPins text command to place I/O pins based on current cell placement. By default, pins are placed under power areas on different layers. Use the -pinOffStripes or -noPinBelowStripe option of the assignIoPins command to disable the default behavior. Note: Use the -noassignIoPins option to disable I/O pin assignment during Amoeba placement. After I/O pins had been assigned, you can further refine the current I/O pin assignment by doing either of the following: May 2005 152 Product Version 4.1.5 Encounter User Guide Partitioning the Design ■ Adjust pins (using the Pin Editor or the preassignPin text command). You can also use direct pin manipulation to manually move selected pins to different locations. Note: Direct pin manipulation does not currently support rectilinear partitions. ■ Run incremental pin assignment by running the assignIoPins text command. This command honors fixed pins and re-assigns only the ones that have a placed or unplaced status. Note: The loadIoFile text command automatically sets the I/O pin placement status to fixed. For the pins that need to be re-assigned, you must change their pin placement status. You can use the resolvePinOverlap text command to resolve pin overlaps or pins off-grid. Currently, this command does not support rectilinear block-level designs. Top-level Implementation After block implementation, an abstract should be developed for each block-level design that will be used in the top-level implementation. For the bottom-up approach, create a top-level floorplan where block-level abstracts would be referenced in the top-level design. Chip Assembly For the bottom-up approach, fllow the similar procedures of the top-down approach to bring in all the top-level and block-level netlists and routing information: 1. Import the design. 2. Manually create a top-level floorplan file similar to the one that is used to partition the design in the chip planning stage of the top-down approach. Each block-level design must be specified as partition in this floorplan file. For multiple instantiated partitions, a master partition could have a non-R0 orientation. However, master and clone partitions can only be rotated if design only has regular square vias, or flipped if regular vias used in the design are symmetry in the flip directions. 3. Load the floorplan file created in the previous step. For master and clones partitions, the Encounter software automatically snaps the clone partitions such that clones will have the same row structure and pattern as their master. To disable this snapping capability, use the -noEqualizePtnHinst option of the loadFPlan command. 4. Commit partitions without pin assignment using the commitPartition -noPinAssign text command. May 2005 153 Product Version 4.1.5 Encounter User Guide Partitioning the Design 5. Read in the top-level routing information using the defIn text command. 6. Read in the block-level routing information for each partition. 7. Before reading in a block-level DEF file, change partition view (using the Partition – Change Partition View menu command or the setTopCell text command). Repeat this step to bring in routing information for all partitions. 8. Change the view back to the top-level design. 9. (Optional) Flatten the partition (using the Partition – Unpartition menu command or the flattenPartition text command). May 2005 154 Product Version 4.1.5 Encounter User Guide Partitioning the Design Specifying Partitions and Blackboxes This section covers the following topics: ■ Defining Partitions on page 156 ■ Defining Blackboxes on page 158 ■ Specifying Multiple Instantiated Partitions and Blackboxes on page 160 ■ Changing Partition Clone Orientation on page 161 ■ Specifying Rectilinear Partitions and Blackboxes on page 162 ■ Specifying Core-to-I/O Distance for Partition Cuts on page 163 ■ Specifying Hierarchical Partitions on page 164 May 2005 155 Product Version 4.1.5 Encounter User Guide Partitioning the Design Defining Partitions To designate partitions, use the definePartition and specifyPartition text commands and the Specify Partition form. The following figure shows an example of how some of the fields in the Specify Partition form relate to the partition. For a description of all the fields, see Specify Partition in the Encounter Menu Reference. Partition Pins Partition Core Std Cell Row Min Pin spacing is every other metal track To specify a module as a partition, complete the following steps: 1. Move the the module inside the core area. You can manually move a module, or use the setFPlanObjBox text command, to define a new module boundary with its coordinates in the core area. Note: A blackbox is a special partition where this restriction does not apply. 2. Specify the name of the partition. May 2005 156 Product Version 4.1.5 Encounter User Guide Partitioning the Design 3. Specify the instance name of a module that is to become a partition. Note: A partition cannot have another partition as its ancestor or descendant. For the case where more than one module is instantiated with the same cell type, see Specifying Multiple Instantiated Partitions and Blackboxes on page 160. 4. Specify the space, in micrometers, between the module boundary and core design area of the partition module. 5. (Optional) If the partition row height is different than specified in the Core Spec page of the Design Import form, specify the row height, in micrometers. 6. (Optional) To account for wide wires at the top-level design, specify the extra spacing, in micrometers, around the partition. At the top-level design, this information is saved as part of the partition section in a floorplan file. This information is also saved in a partition floorplan file when saving partitions. By default, this value is 0; the top-level router uses minimum wire spacing. 7. Specify the selected metal layers that are used for routing in the partition and generating partition pins. A normal six-metal layer selection process is M1, M2, M3, M4 and M5 selected, and M6 unselected. When saving the partition, the LEF generated for this partition will have routing blockages on their layers so that the top-level router is aware of which metal layers are being used in the partition. The selected metal layers generate a file which is saved in the top-level design directory. This file notifies the top-level which metal layers are being used in the partition. In addition, the floorplan file generated by saving partition will include the routing blockage for the partition. To customize routing interconnects over a partition, use the Add Partition Feedthrough widget. 8. (Optional) Specify the pin pitch dimension for the partition sides. 9. (Optional) Select or deselect the metal layers from the defaults. Deselecting all metal layers for a side of a partition prevents pins from being created for the entire side of that partition. The selection of partition pin metal layers works in conjunction with the Partition Pin Guide floorplan object. The partition pin guide object specifies exactly where the pins are to be created. When partition pin guide objects are not used, the partition pins are created where the top-level routing connects with the partition. 10. Add the partition information to the Partition List field and save the partition specification file. May 2005 157 Product Version 4.1.5 Encounter User Guide Partitioning the Design Defining Blackboxes Normally a blackbox is a module with content that is not well defined. However, a well-defined module can also be defined as a blackbox. A blackbox is similar to a hard block, but like a fence, a blackbox can be resized, reshaped, and have pins assigned. After a blackbox has its pins assigned, it behaves like a hard block. The blackbox feature can be used only with a partitioned design. After the netlist has been loaded, you can further specify which modules or cells will be regarded as blackboxes, or modify the existing blackbox sizes. A blackbox size can be specified in terms of an estimated area (an actual value or an area value in terms of gate count), or a fixed block width and height. You can define a blackbox in the following ways: ■ Specify a module or hard macro as blackbox after the design import step, using the specifyBlackBox command or the Partition – Specify Black Box menu command. ■ Use the setImportMode -treatUndefinedCellAsBbox 1 command before importing a design to automatically convert all undefined modules or cells into blackboxes. For this method, the initial blackbox size is zero. After reading a netlist into the Encounter software, use the specifyBlackBox text command to change a blackbox size. ■ Define LEF abstracts for blackboxes. You can specify a blackbox library in the LEF Files field of the Design Import form. If a blackbox LEF abstract is specified in the LEF Files field, the LEF abstract should have CLASS type as BLOCK BLACKBOX to indicate it is a blackbox. The following is an example of a blackbox LEF abstract: MACRO amba_dsp CLASS BLOCK BLACKBOX ; ORIGIN 0 0 ; SIZE 4411.8600 BY 5697.3600 ; END amba_dsp After defining a blackbox with any above method, you can further modify an existing blackbox size with the specifyBlackBox text command. May 2005 158 Product Version 4.1.5 Encounter User Guide Partitioning the Design Caution If you convert a hard macro into a blackbox or define a blackbox with LEF abstract that has obstructions, the obstructions size will not be updated with a new blackbox size. Due to this limitation, obstructions may be intruded outside of the new blackbox boundary. Blackbox Flow The following flow specifies blackboxes with an original netlist that has modules with content that is not well-defined: 1. Import the design. You do not need a cdump or LEF file for blackboxes; however, you do have the option of specifying a cdump or LEF file. Note: By default, the Encounter software treats empty modules and undefined cells as special standard cells. To convert these undefined cells into blackboxes, issue the following command before loading a configuration file: setImportMode -treatUndefinedCellAsBbox 1 2. Specify the blackboxes or load a floorplan file with blackbox information. 3. Floorplan the design. 4. Save the design, which saves the blackbox information. The following flow converts blackboxes to fences or partitions with an updated netlist, where the contents of blackboxes are now defined: 1. Restore the design with its updated netlist. The saved floorplan (with blackbox information) from the previous flow is loaded during this step. 2. Run the unspecifyBlackBox command to unspecify all blackboxes. If the original blackbox is a module with content, it should be converted to a module. This module will be unplaced. If you want the blackbox to be converted to a fence, the blackbox must already be placed inside the core, using the unspecifyBlackBox keepPtn text command. If the original blackbox is defined as a macro in the technology library, it should be converted into a macro. 3. Save the floorplan file, which contains the fence or partition information instead of blackboxes. May 2005 159 Product Version 4.1.5 Encounter User Guide Partitioning the Design Saving Blackboxes To save blackbox information, use the saveDesign command or the Design – Save Design menu command. Deleting Blackboxes If a blackbox is an empty module in the netlist, or a cell without a physical macro definition, you must modify the netlist before you can delete it. Tip You should not delete a blackbox that was originally defined as a macro in the technology file; otherwise, you might have problems with loosely integrated applications because these application interfaces automatically generate only macro definitions for blackboxes. You should only use the delete capability to try out different floorplan. When you are ready to run a loosely integrated application, complete the following steps: 1. Run the saveBlackBox command to make sure that you have updated the size and pin information. 2. Exit the Encounter software, or use the freeDesign text command. 3. Rerun the Encounter software with the updated macro information. To delete all the blackboxes in the design, use the unspecifyBlackBox -all command. Specifying Multiple Instantiated Partitions and Blackboxes When a module with multiple instantiations (also known as repeated partitions) of the same cell type is assigned to become a partition, you can specify either one of the multiple instantiated hierarchical instances to be partitions. The name of a hierarchical instance used for partition specification becomes the master partition, and the other instantiations are clones of this master partition. Note: All the master and clone hierarchical instances should be placed inside the core before you specify the partition. This restriction does not apply to blackboxes. When working with repeated partitions, you should be aware of the following: ■ You can only specify one instance as a master partition. The Encounter software will treat the other instances are partition clones. May 2005 160 Product Version 4.1.5 Encounter User Guide Partitioning the Design ■ For the top-down hierarchical flow, where the top-level design is implemented first, the instance must have a R0 orientation; otherwise, you will run into problems with the pin assignment, feedthrough buffer insertion, and commit partition steps. ■ For the bottom-up hierarchical flow, where the block is implemented first, the partition master can have a non-R0 orientation. Make sure all the non-uniquified instances are placed inside the core before you specify the partition. ■ For non-uniquified blackboxes, the Encounter software automatically converts all hierarchical instances of a same module as repeated blackboxes. The hierarchical instance that is first instantiated in the netlist is treated as the master blackbox. ■ Partition and blackbox clones can be rotated and flipped if the design only has regular square vias, and flipped if regular vias used in the design are symmetry in the flip directions. ■ Partition clones share the same pin assignment and pushed-down data as their partition master, you must run the alignPtnClone command before the commit partition step to make sure all the partition clones are well aligned with the master on power mesh so you do not run into problems when flattening the partitions. ■ You cannot use inserted partition feedthrough buffers for partitions that have clones. The Encounter software does not support this capability. ■ For master and clones partitions, the Encounter software automatically snaps the clone partitions such that clones will have the same row structure and pattern as their master. To disable this snapping capability, use the -noEqualizePtnHInst option of the loadFPlan command. Changing Partition Clone Orientation After specifying the partition, you can change the partition clones’ orientation by using the Attribute Editor during floorplanning. For routing purposes, the Encounter software automatically stitches regular wires and rotates vias correctly for non R0 orientations, such as MX, MY, R90, R180, and R270. For example, there is a case where some of the clones follow the orientation of the master instance (R0), and some are placed with R180 orientation. After chip assembly, the Encounter software flips and places the clone instances’ standard cells to match the R180 clone orientation, and repositions the routing according to the R180 orientation. Because R90 and R270 orientation clones have vertical rows, all the cell placement, routing, and IPO should be done at the top-level before flattening step. After flattening the design, you should only run full chip flat timing analysis. May 2005 161 Product Version 4.1.5 Encounter User Guide Partitioning the Design The following example shows a design that has R90, R180, and R270 orientation clones: Master Partition R0 R90 R270 R180 Physical View after Unpartitioning (does not show the top-level connection) Floorplan View Note: The illustration above only shows the wire information inside the partition, and does not include the top-level connection. Specifying Rectilinear Partitions and Blackboxes You can specify a rectilinear (non-rectangular) partition shape by adding a cut area. The partition’s cut area will have no cell placement and no routing. Pins are assigned to the rectilinear partition edges, as shown in the following figure: pins Cut Area pins Partition Area The rectilinear pin assignment recognizes the rectilinear edges when assigning pins, and supports any rectilinear shape. See Assigning Pins on Rectilinear Edges on page 170 for more information. May 2005 162 Product Version 4.1.5 Encounter User Guide Partitioning the Design To add a cut area to the partition or blackbox, complete the following steps: 1. Click on the Cut Rectilinear widget from the Tools area. 2. Move the mouse to an edge or corner of the partition or blackbox. 3. Left click and drag over the area. 4. Left click again to complete the cut. A macro definition file (LEF/cdump) will be created with blockage on the overlap layer covering the cut area. For the top-level partition, the cut area allows block or cell placements. The equivalent text command is setFPlanObjBoxList with the Module object type. For backward compatibility, you can also use the createPtnCut text command. You should specify a module as a partition before using createPtnCut. For repeated partitions or blackboxes, when you create a cut on one instance—either master or clone—the cut is applied to the other instances as well. Note: Blackbox pin locations are saved in a blackbox LEF file, not a floorplan file. If you want to save blackbox pin locations, save the design (using the Design – Save Design menu command or the saveDesign text command) instead of saving the floorplan (using the Design – Save – Floorplan menu command or the saveFPlan text command). You can restore the design that has blackboxes (using the Design – Restore Design menu command or the restoreDesign text command). If you prefer not to use restoreDesign command, you can use the following commands to restore the blackbox pin locations: loadConfig fileName loadLefFile fileName Specifying Core-to-I/O Distance for Partition Cuts Core-to-I/O distance is specified in the Specify Partition form. If the partition has a partition cut, core-to-I/O distance is honored where the cut is specified. The specified top, bottom, left, and right core-to-I/O distances is automatically assigned for the cutting edges that face the north, south, west, and east side, respectively. May 2005 163 Product Version 4.1.5 Encounter User Guide Partitioning the Design For example, if you specify a core-to-I/O distance of 5 µm for the top and bottom, and 2 µm for left and right sides: 5 µm A 2 µm 5 µm B 2 µm The core to I/O distance for the edge A (facing east) should be 2 µm. The core to I/O distance for the edge B (faced to north) should be 5 µm, same as the top side. Specifying Hierarchical Partitions The Encounter software does not support a partition or blackbox that is nested inside another partition. For nested partitions, you can work around this limitation by specifying the second level partition at the partition-level design. For nested blackboxes, you can work around this by converting it into a hard macro after assigning blackbox pins. For example, in the case where module mult_32 is nested inside module tdsp_core, where mult_32 is specified as a blackbox and tdsp_core is defined as a partition, you would complete the following steps: 1. Import the design. 2. Specify blackbox mult_32 and partition tdsp_core. 3. Assign blackbox pins for mult_32. 4. Save the design. The Encounter software automatically creates a LEF abstract for mult_32. 5. Restore the design. 6. Unspecify blackbox mult_32 using the unspecifyBlackBox text command. mult_32 is converted back to a hard macro. May 2005 164 Product Version 4.1.5 Encounter User Guide Partitioning the Design 7. Continue with the normal flow prior to committing the partition. 8. Commit the partition. 9. Switch to partition tdsp_core (using the Partition – Change Partition View menu command or the setTopCell text command). 10. Re-specify mult_32 as a blackbox. 11. Switch back to the top-level design. 12. Save the partition. tdsp_core block level design will contain the blackbox mult_32. May 2005 165 Product Version 4.1.5 Encounter User Guide Partitioning the Design Assigning Pins You can optimize partition and blackbox pins in the Encounter environment based on routing or placement information. You can assign the pins or ports to a location on a partition, and block an area from creating pins on specific metal layers. Cadence recommends that you run the Check Pin Assignment menu command (Partition – Check Pin Assignment) or the checkPinAssignment text command after pin assignment to make sure that all pins are assigned, are placed on routing grids, and are not overlapping. Important You cannot assign blackbox or partition pins when design is unplaced and unrouted. Make sure you place the design before partitioning; otherwise, all pins will be unplaced. This section covers the following topics: ■ Assigning Blackbox Pins on page 166 ■ Assigning Partition Pins on page 167 ■ Assigning Pins on Rectilinear Edges on page 170 ■ Setting Pin Constraints on page 170 ■ Refining Pin Assignment on page 175 ■ Resolving Pin Overlaps on page 176 ■ Snapping Pins to the Grid on page 176 ■ Limitations of Pin Assignment on page 176 Assigning Blackbox Pins To assign blackbox pins, complete the following steps: 1. Import the design. 2. Floorplan the design. 3. Run Placement. 4. Generate the physical pins for the blackbox. Use the blackBoxPinAssign text command or the Partition – Assign Black Box Pins menu command. May 2005 166 Product Version 4.1.5 Encounter User Guide Partitioning the Design Tip At this point, save the floorplan file or save the design for later use should you want to want to assign pins incrementally. 5. Partition the design. 6. Save the partition. After assigning blackbox pins, saving the partition saves the top-level cell and each specified blackbox into a subdirectory. Incremental Blackbox Pin Assignment To assign blackbox pins incrementally, complete the following steps: 1. Start a new Encounter session. Alternatively, you can use the freeDesign command to remove a design instead of starting a new Encounter session. 2. Import the new design netlist. 3. Load the floorplan file or design. 4. If applicable, run placement or restore the placement information. 5. Preassign the locations of the existing locations of the existing blackbox pins. Use the loadPtnPin command. 6. Assign locations for the new added blackbox pins while honoring the pre-assigned partition pins. Use the blackBoxPinAssign text command or the Partition – Assign Black Box Pins menu command. Assigning Partition Pins To assign partition pins, complete the following steps: 1. Import the design with its original netlist. 2. Specify the partition. 3. Floorplan the design. May 2005 167 Product Version 4.1.5 Encounter User Guide Partitioning the Design 4. Run Placement. 5. Run Trial Route. Tip Cadence recommends that at this point you save the floorplan file, or save the design for later use should you want to want to assign partition pins incrementally. 6. Partition the design. 7. Save the partition. Important During pin assignment of a partition, internal macro blockages might move after replacement inside the partition. Add pin blockages where you do not want pin assignment. Incremental Partition Pin Assignment You can assign partition pins incrementally to preserve most of the existing partition pin locations and allow the Encounter software to assign the newly added pins. To run the incremental pin assignment, complete the following steps: 1. Start a new Encounter session. Alternatively, you can use the freeDesign command to remove a design instead of starting a new FE session. 2. Import the new or modified netlist. 3. Load the floorplan file or design that was saved in the step 6. 4. Run Placement. 5. Pre-assign the locations of the existing partition pins by running the loadPtnPin command. 6. Run Trial Route, or restore the routing information, if applicable. 7. Run Partition to assign locations for the new added pins while honoring the pre-assigned partition pins. May 2005 168 Product Version 4.1.5 Encounter User Guide Partitioning the Design Tip It is good practice to run the checkPinAssignment command after pin assignment to make sure that all pins are assigned, are placed on routing grids, and are not overlapped. May 2005 169 Product Version 4.1.5 Encounter User Guide Partitioning the Design Assigning Pins on Rectilinear Edges Rectilinear pin assignment can recognize rectilinear edges when assigning pins. It can support any rectilinear shape (such as L, T, and U shapes). For rectilinear boundaries created with partition cuts, the edges are identified by starting at the lower-left-most corner, moving clockwise to mark each edge with a direction flow, as shown in the following figure: Top Right Top Top Left Left Right Start Point Bottom All the edges with the same direction flow are considered to be on the same side and have the same user-specified pin constraints. Setting Pin Constraints The Encounter software provides a number of constraints to control or guide partition or blackbox pin assignment. Pin Width and Height Use the setPtnPinWidth and setPtnPinWidth text commands to specify default pin width, and depth of a routing layer for a specific partition. When this constraint is defined, the pin assignment engine uses these values for creating a default pin size instead of using the minimum layer width. Note: These commands cannot be used for I/O pins. Pin Spacing Set minimum pin spacing in terms of track number using the Specify Partition form (Partition – Specify Partition menu command). The default pin spacing is 2, which places the pin for every two metal tracks. May 2005 170 Product Version 4.1.5 Encounter User Guide Partitioning the Design For more information on pin spacing, see Defining Partitions on page 156. Pin Layers Specify pin layers that will be used for placing pins on a specific partition side using the Specify Partition form (Partition – Specify Partition menu command). Bus Pins or Group of Pins You can create a group of nets or a group of pins and constrain them to be placed on the same block side, next to each other. Net Group A net group can be created using the createNetGroup text command. After defining a net group, you can add nets to this created net group using the addNetToNetGroup text command. To be honored by a pin assignment engine, net groups must be used in conjunction with a partition pin guide. The following is an example of creating a net group, NETGROUP, that has two nets, NET1 and NET2: createNetGroup NETGROUP addNetToNetGroup NETGROUP NET1 addNetToNetGroup NETGROUP NET2 Cell Pin Group A cell pin group can be created using the createCellPinGroup text command. You can add pins to a cell pin group using the addPinToCellPinGroup text command. Cell pin groups do not have to be associated with a partition pin guide because it is not a constraint to any partition edge. In this case, pin assignment can freely place this group of pins on any edge of the partition. However, pins that belong to this pin group still are placed together in adjacent locations. For blackbox pin assignment, to honor cell pin groups that are not associated with any pin guide, specify the -pinGroup option of the blackBoxPinAssign text command. For partition pin assignment, the Encounter software automatically honors all defined cell pin groups. The Encounter software also provides the capability to optimize order of pins within a cell pin group to improve wire length (using the -optimizeOrder option of the May 2005 171 Product Version 4.1.5 Encounter User Guide Partitioning the Design createCellPinGroup text command). If this option is not specified, the pin order is exactly as specified in the pin group. The following is an example of creating a cell pin group GROUP1 that consists of 3 bus bit pins of the module ALU. These pins can be optimized within this pin group. createCellPinGroup ALU GROUP1 -optimizeOrder addPinToCellPinGroup ALU GROUP1 INT[0] addPinToCellPinGroup ALU GROUP1 INT[2] addPinToCellPinGroup ALU GROUP1 INT[3] Partition Pin Guides You can use partition pin guides to guide where the pins of a particular bus, net, or net group will be assigned or placed. This preserves the pin order within the pin guide. The pin is located where the partition pin guide overlaps with the edge of the module guide (fence). After you have determined a pin guide location in the design display area, you can create a partition port for a net or bus name and add a partition pin guide. To add a partition pin guide, complete the following steps: 1. Click the Add Partition Pin Guides widget from the Tools area. 2. Click and drag over a partition fence overlap. For the vertical edges, the first pin generated starts from the bottom intersect point. For the horizontal edges, the first pin generated starts from the left intersect point, as shown in the following figure: Partition Pin Guide 1 Partition Pin Guide 2 Creates ports at the top side, starting left-to-right Creates ports at the right side, starting bottom-to-top Partition The default pin spacing is 2, which places one pin for every 2 metal tracks. You can change the pin spacing with the Minimum Pin Pitch field in the Specify Partition form, or the Min Space field in the partition pin guide’s Attribute Editor . You can use the Move/Resize/Reshape tool to modify the pin guide location. Note: For a partition that has a rectangular cut, the partition pin guide must be placed May 2005 172 Product Version 4.1.5 Encounter User Guide Partitioning the Design on the cut edge. 3. Change the partition pin guide object name to the net, bus, or net group name. Use the Attribute Editor, or the createNetGroup command to create a net group name. Use the addNetToNetGroup command to assign nets to the net group. If the partition pin guide was assigned the net group name, and all nets and buses added to this net group name will have partition pins generated for the partition. Pins are generated in the order the net or bus was entered by the addNetToNetGroup command. Pins for unconnected nets and buses are randomly assigned. You can also use the partition pin guide to assign floating pins. As an alternative to the steps, you can use the createPtnPinGuide or createRouteBox text command. The advantage of using createRouteBox is you can specify a pin layer and pin pitch without using the Specify Partition form. You can define more than one pin area (route box) for a particular pin guide. For example, the following commands create a partition pin guide for the net group NETGROUP that has two defined pin areas. The first pin area is on M2 and the other one is on M3. Minimum pin spacing for pins that belong to this pin guide is 2 (pin is placed on every 2 tracks): createRouteBox 1829.81 1377.12 1959.08 1962.86 NETGROUP M2 2 createRouteBox 1744.98 1781.08 2019.67 1861.87 NETGROUP M3 2 Optimization within Pin Guides You can specify a range where the partition pins should be assigned, and allow the pin optimizer to optimize the pin order or spacing within the pin guide bounding box to provide better pin assignment. After creating a partition pin guide, double-click on the partition pin guide or route box in the design display area to open the Attribute Editor, then click on the Optimize Pin button. Alternatively, you can use the -optimize parameter with either the createPtnPinGuide and createRouteBox text commands. For example, the following command creates a partition pin guide for the cell pin group GROUP1 of module ALU, and optimizes pins within this pin guide: createPtnPinGuide 678.52 371.25 978.53 787.33 -name GROUP1 -cell ALU -optimize May 2005 173 Product Version 4.1.5 Encounter User Guide Partitioning the Design If a cell pin group is assigned to a partition pin guide, the -optimize parameter of the partition pin guide will have higher precedence, as shown in the following table: -optimizeOrder of pin group -optimize of pin guide Behavior OFF OFF Pin order is exactly as specified in pin group OFF ON Pin order is optimized to improve QOR ON OFF Pin order is exactly as specified in pin group ON ON Pin order is optimize If you enable the -optimize parameter, the pin optimizer uses the minimum pin spacing defined at the partition level using the Specify Partition form (Partition – Specify Partition menu command), although a pin pitch value can be defined at the pin guide level. If you do not enable the -optimize parameter, pins are placed in the same order as specified in partition pin guide. If a pin guide has more than one defined pin area, the first defined route box or pin area is used. If it does not have enough space to place all pin guide pins, the next defined pin area is used. Conversely, if the first defined pin area can accommodate all pins, then the other defined areas will not be used. Partition Pin Blockage After determining the partition pin blockage point, you can block that area from assigning pins on specific metal layers. Pin assignment engines also honor regular routing blockages if they are intersected with partition edges. Note: Trial Route does not honor the partition pin blockage. To create the partition pin blockage, complete the following steps: 1. Click the Add Partition Pin Blockage widget from the Tools area or use the createPtnPinBlk text command. 2. Left click and drag over a partition fence overlap. 3. Use the Attribute Editor to specify which metal layers to block. Pin Pre-Assignment You can pre-assign a pin before pin assignment using the Pin Editor or the preassignPin text command. These pre-assigned pins will have fixed placement status so pin optimizers May 2005 174 Product Version 4.1.5 Encounter User Guide Partitioning the Design will honor them. For more details, see the Pin Editor section in the “Tools” chapter of the Encounter Menu Reference. Pin Layer or Pin Size Constraint Settings You can use a combination of the preassignPin and setPtnPinStatus text commands to specify pin size or pin layer constraints for a specific pin. For example, to assign a layer M2 constraint to pin A of the partition ptnALU before running pin assignment, the following commands first assigns pin A on A layer at location (400.0 636.5), then unplaces the pin: preassignPin ptnALU A -loc 400.00 636.5 -layer 2 setPtnPinStatus ptnALU A unplaced Note: The unpreassignPin text command must be used to remove any pin constraints. Refining Pin Assignment After assigning partition or blackbox pins, you can further refine the current pin assignment using one or more of the following methods: ■ Adjust pins using the Pin Editor or the preassignPin text command. You can also use direct pin manipulation to manually move selected pins to different locations. Note: Direct pin manipulation does not currently support rectilinear partitions. ■ Align partition pins with other block pins (using the Pin Editor or the pinAlignment text command). ■ Run incremental/ECO pin assignment using loadPtnPin text command. ❑ For blackboxes, see Incremental Blackbox Pin Assignment on page 167. ❑ For partition pins, see Incremental Partition Pin Assignment on page 168. Note: Currently, the loadPtnPin text command only loads back the partition pin locations, but not pin sizes. ■ Re-run pin assignment. For partition pins, you should first flatten the partitions using the Partition – Unpartition menu command or the flattenPartition text command. For blackbox pins, unassign blackbox pins using the unassignBlackBoxPins text command before re-running the blackBoxPinAssign text command. May 2005 175 Product Version 4.1.5 Encounter User Guide Partitioning the Design Resolving Pin Overlaps After pin assignment or pin refinement, if you still have pins that are overlapping or off-grid, you can use the resolvePinOverlap text command to fix these problems. Note: resolvePinOverlap does not support rectilinear partition or blackbox. Snapping Pins to the Grid To snap center of pins to nearest intersecting routing grid, where the horizontal and vertical routing tracks cross, use the snapPtnPinsToTracks text command. For example, the following command snaps center of partition ptn_xy pins to the nearest intersecting routing grid: snapPtnPinsToTracks ptn_yz ptn_yz before snapPtnPinsToTracks ptn_yz after snapPtnPinsToTracks Limitations of Pin Assignment The following are the limitations of pin assignment: ■ ■ For multiple instantiated partitions and blackboxes: ❑ Pins can only be assigned for master partitions/blackboxes. Clones share the same pin assignment with their master. Furthermore, you can only manually manipulate master partition pins instead of clone partition pins. ❑ Masters must have R0 orientation; otherwise, the Encounter software might crash, or pins will be assigned to an outside block boundary. For mixed designs, the pin assignment engine might assign pins of multiple pins nets (three or more pins nets) to abutted edges that cause routing violations because a toplevel router is not able to route to these pins. May 2005 176 Product Version 4.1.5 Encounter User Guide Partitioning the Design ■ Pin optimizers will not optimize power or ground pins. Power or ground pins are created based on power stripes information. If you assign a power or ground net to a partition pin guide, the pin optimizer will not honor it. Editing Partition Pins This section provides supplemental information to some of the text command examples in the “Partition Commands” chapter of the Encounter Text Command Reference. Note: If you edit pins after partitioning the design, before saving the partition, you should run the recreatePtnCellBlockage text command after editing pins (using the Pin Editor to edit the pin, or using the preassignPin text command to move pins in the partition). The recreatePtnCellBlockage command will re-cut cell blockage reflect the pin moving. Some routers, such as WRoute, do not need cut-blockage around pin. The following examples illustrate how you can use these to edit the partition pin information: Pin Alignment Using pinAlignment, the following command aligns A0 and A1 pins of blockB to the reference pins of blockA: pinAlignment -block blockB -refBlock blockA {A0 A1} Target Block Target Block A[0] Reference Block Reference Block A[1] A[0] A[0] A[0] A[1] A[1] A[1] Before Pin Alignment May 2005 After Pin Alignment 177 Product Version 4.1.5 Encounter User Guide Partitioning the Design Inserting Feedthroughs There are two types of feedthroughs you can use for partitions: feedthrough buffers and routing feedthroughs. Both types offer different approaches for inserting feedthroughs. Inserting feedthrough buffers allows a netlist change, whereas inserting routing feedthroughs does not. Important Before inserting feedthroughs, you should determine what stage the design is in, such as prototyping, intermediate, tapeout, and set the appropriate global options by running the setMode commands, such as setPlaceMode and setTrialRouteMode. For example, when inserting feedthroughs during prototyping, you could set modes with the following commands: setPlaceMode -fp setTrialRouteMode -floorplanMode setExtractMode -default You can use the insertPtnFeedthrough command (or the Insert Feedthrough Buffer form) to insert feedthrough buffers into the partitions, and the createPtnFeedthrough command (or the Create Physical Feedthrough form) to create a partition routing feedthrough object. The differences between how these two commands affect the design are as follows: ■ insertPtnFeedthrough The insertPtnFeedthrough text command inserts feedthrough buffers into the partitions to change the partition netlists, and avoids routing nets over partition areas. This command affects the design in the following areas: ❑ Changes both the top-level and partition-level netlists. ❑ After inserting buffers, it automatically calls ecoPlace to place these buffers close to the partition boundary. However, insertPtnFeedthrough does not place the feedthrough pins, which should be assigned during Partitioning. ❑ Inserted buffers will be part of the partition netlists and pushed down to the partition level during Partitioning. ❑ Wherever a net enters and exits a partition, two ports and a buffer (or two buffers with the -doubleBuffer option) are added to the partition netlist. ❑ For nets that enter or exit a partition several times, such as a “T” shaped connection, three ports will be created. For a cross shaped connection, four ports will be created. May 2005 178 Product Version 4.1.5 Encounter User Guide Partitioning the Design ■ ❑ Use the Design Browser to view the newly added buffer instance and net names for each partition. The new port names have a FE_FEEDX_.....net_name prefix. ❑ For pure channelless designs, use the -chanLess option to insert feedthrough buffers for all nets that connect to partitions, except nets that can be connected directly between two adjacent partitions. ❑ For mixed designs, not all nets should become feedthrough nets. To exclude certain nets, such as clock nets or high fanout nets, use the -excludeNet option. This option is based on the topology of the partition neighborhood relationship, so trial routing is not required before inserting feedthrough buffers, although it could help improve the quality of results. ❑ To specify a file that contains net names for which to insert feedthrough buffers, use the -selectNet option. You can create this file manually, create a list of nets via a script, or use showPtnWireX. ❑ Whether you use the -chanLess or -selectNet options, the Encounter software does not necessarily insert a feedthrough. ❑ Feedthrough insertion is driven by connectivity when Trial Route is not run before insertPtnFeedthrough. createPtnFeedthrough The createPtnFeedthrough text command inserts routing feedthroughs into the partitions without changing the design netlist. This command affects the design in the following areas: ❑ Manages only the physical aspect of a partition, not the logical aspect. ❑ No new ports are added to a partition and no buffers are added to the partition netlist. ❑ For channel feedthroughs, this creates channels for over-the-block routing on specified layers at the top-level design. These channels are pushed down as routing blockages on the correct routing layers at the partition level during Partitioning. ❑ For placement island feedthroughs, the Encounter software reserves these areas for inserting buffers at the top-level design after running the insertRepeater command. These island feedthroughs will be pushed down as placement blockages and routing blockages on all routing layers at the partition level during partitioning. May 2005 179 Product Version 4.1.5 Encounter User Guide Partitioning the Design Inserting Feedthrough Buffers Partition feedthrough insertion manages partitioned designs that have nets that need to be pushed down to become a component of each partition design. That is, each feedthrough buffer must be added to the partitioned design, which changes the partition’s netlist. This approach is typically used in channelless designs and in designs with limited channel resources. A pure channelless design has no channel routing resource—connections among partitions are always done by means of module abutment and pin alignment. A mixed or partially channelless design has limited routing resource in the channels; therefore, abutment and pin alignment is only performed on selected nets. The following example shows how nets are selected for feedthrough buffers: net1 I/O pin IN net 2 IN OUT Partition A Partition B Partition C Feedthrough Candidates Inserting Feedback Buffers You can insert a feedthrough buffer to a net that loops back to an original partition to avoid the net routing over a partition area using the insertPtnFeedBackBuffer text command, which you should run after the feedthrough insertion step. The following example shows a situation where net LoopBack connects to output pin O and input pin I of Partition A, and input I2 of Partition C. Partition A Partition B Partition C LoopBack O I2 I May 2005 180 Product Version 4.1.5 Encounter User Guide Partitioning the Design By inserting a feedthrough buffer (BUF1) with the insertPtnFeedthrough text command, and inserting a feedback buffer (BUF2) with the insertPtnFeedBackBuffer text command, LoopBack now connects to the input pins of BUF1 and BUF2, as shown in the following figure: Partition A Partition C Partition B O I2 BUF1 I BUF2 Limitations The feedthrough buffer insertion procedure has the following limitations: ■ Each partition must be intact. A non-child instance cannot be preplaced in another partition. This would present a top-level net connection problem. ■ Partition pin guides cannot be used during feedthrough insertion. ■ A partition design that has repeated partition modules is not supported. Exclude all nets that connect into a repeated partition module. ■ The Unpartition program cannot remove the inserted buffers for the feedthrough nets. ■ Does not handle blackboxes. ■ It might not handle clock nets efficiently because the insertPtnFeedthrough text command does not take timing into account. ■ It cannot handle nets that are connected to two or more glue logic standard cells. This type of net should be excluded from feedthrough insertion. ■ It might not provide good quality of results for high fanout nets. You should exclude high fanout nets and clock nets from feedthrough insertion to avoid timing and routing problems. May 2005 181 Product Version 4.1.5 Encounter User Guide Partitioning the Design Procedure To insert feedthrough buffers in a partition design, complete the following steps: 1. Design the top-level floorplan for the partition design. 2. Run Amoeba Placement. 3. (Optional) Run Trial Route. Important Up to step 3, the flow is similar to a partition design flow. To control which nets get buffers inserted, complete step 4. If all nets require buffering, skip step 4 and use the insertPtnFeedthrough text command’s -chanLess option. 4. Create a file to identify which nets get buffers. You can manually edit the file, create a script, or generate a wire crossing file (see Generating the Wire Crossing Report on page 186). 5. Generate the feedthrough buffers and nets. Use the insetPtnFeedthrough -chanLess command, or insetPtnFeedthrough -selectNet with the created net file. Note: Step 6 returns to the normal partition design flow. 6. Run Trial Route to completely connect the design, including the inserted feedthrough buffers. 7. Run Partition to generate the partition pins and change the partition module status to hard block. 8. Run Save Partition. This saves the design and generates a top-level directory and partition directories. Abbreviating Lengthy Feedthrough Net Names You can abbreviate inserted feedthrough net names so that the net names will not extend too long if you run the insertPtnFeedthrough or insertPtnFeedBackBuffer commands multiple times. With the -useShortName option, you can eliminate the use of the old net name and partition names, and instead use a running count for the new net names. May 2005 182 Product Version 4.1.5 Encounter User Guide Partitioning the Design For example, if a feedthrough net reset connects two partitions tt_chiplet and video_chiplet, the feedthrough net name is: FE_FEEDX_NET_C__tt_chiplet_video_chiplet_reset The net name abbreviation convention for feedthrough buffer insertion when using the insertPtnFeedthrough -useShortName command are: Net Names FE_FTN_n, where n is an integer Buffer Names FE_FTB_n, where n is an integer The net name abbreviation convention for feedback buffer insertion when using the insertPtnFeedBackBuffer -useShortName command are: Net Names FE_FB_NET_n, where n is an integer Buffer Names FE_FB_BUF_n, where n is an integer Inserting Routing Feedthroughs Routing feedthroughs and hole punch buffers reserve a portion of the partition area for toplevel use. Because the partition’s netlist does not change, no new ports are created for the partition. Buffers are inserted in top-level netlist but occupy space within the partition’s fence. Partition feedthroughs are used to indicate the top-level partition’s concession within the partition fence. Partition feedthroughs should be defined before running the Partition program, which automatically generates appropriate placement and routing blockages within the partition and in top-level view to reflect the real estate ownership scheme. For example, a routing feedthrough with Metal6 will generate a Metal6 routing blockage for the partition, and an opening in the Metal6 blockage in the top level. Note: The partition feedthrough discussed in this section is a floorplan object. It affects a partition only physically (not logically) and does not affect partition feedthrough buffer cells. May 2005 183 Product Version 4.1.5 Encounter User Guide Partitioning the Design A routing feedthrough (slot) within the partition’s fence is used by the top-level partition’s routing, and an island within the partition’s fence can be used by the top-level partition’s placement, and shown in the following figure: Routing Feedthroughs (slots) Islands Note: Routing feedthroughs can be used without placement islands. To create a channel-type feedthrough, use the Partition Feedthrough tool widget. After adding a partition feedthrough to the design, you can use the Attribute Editor to change its layers. The specified routing layers are reserved for top-level use, and the partition uses the other layers. You can create an island type partition feedthrough in a similar way, but all layers are deselected. To insert routing feedthroughs and hole punch buffers, complete the following steps: 1. Create routing feedthroughs using one of the following methods: Method 1: Use the Add Partition Feedthrough widget to create the feedthrough buffer on the partition. Select the buffer and open the Attribute Editor form, specify the metal layer, and click OK. This creates the channel for the routing on the specified layers at the top level, and pushes down appropriate routing blockages at the block level. Method 2: If you want to specify narrow feedthroughs or several of them on a given partition, choose Partition – Create Feedthroughs to open the Create Feedthrough form. To specify which partition you want, click on the partition in the design display area, then click get selected. Complete the form and click OK. 2. (Optional) if you have hole punch buffers, create an island to specify where the holes are to be punched in the partition. To do this, use the Add Partition Feedthrough widget to create the feedthrough buffer on the partition, then deselect all layers after double-clicking on the island. This creates the island for buffer placement at the top level, and pushes down the appropriate routing and placement blockage at the block level. 3. Run Partition. May 2005 184 Product Version 4.1.5 Encounter User Guide Partitioning the Design This automatically creates routing blockages for the channel feedthroughs, and placement blockages for the placement island, as shown in the following figure: Channel Feedthrough (layer M6) Channel Feedthrough (layer M5) Routing Obstruction (layer M6) Routing Obstruction (layer M5) Placement Obstruction Placement Island Partition with Partition Feedthroughs May 2005 Committed Partition 185 Product Version 4.1.5 Encounter User Guide Partitioning the Design Generating the Wire Crossing Report You can display and write a file of wires that physically cross over partitions using the showPtnWireX text command or the Partition – Show Wire Crossing menu command. The results are saved to a designName.wirecrossing file that reports nets that cross each partition in a design. For any net that crosses more than one partition, you can use it as a starting point for generating a list of nets for feedthrough insertion. Tip Edit the designName.wirecrossing file to exclude high fanout nets, clock nets, and nets that are connected to two or more glue logic standard cells to avoid timing and routing problems on these nets. You can use the resulting file with the insertPtnFeedthrough text command’s -selectNet option. Note that the Encounter software determines the buffer tree topology, so not all specified nets will receive inserted feedthroughs. For example, nets that connect directly between adjacent partitions are not candidates for feedthrough insertion. Reading the Wire Crossing Report The wire crossing report section lists the nets, their wire lengths, in micrometers, and the shape of the wire in relation to the partition. For example, the following report segment is for a partition module named ptn01: ######################################################### # Nets that cross partition module ptn01 # Box (335 335) (833 567) # Format: Net <netName> <wireLength> <shape> ######################################################### Net Net Net Net ... A B C D 65 I 80 L 1050 T 132 X The first net in the report, A, has a wire length of 65 micrometers in an ‘I’ shape, which indicates that the net crosses the partition on opposite sides, as follows: May 2005 186 Product Version 4.1.5 Encounter User Guide Partitioning the Design Net A 65 I The second net in the report, B, has a wire length of 80 micrometers in an ‘L’ shape, which indicates that the net crosses the partition on opposite sides, as follows: Net B 80 L The third net in the report, C, has a wire length of 105 micrometers in an ‘T’ shape, which indicates that the net crosses the partition on three sides, as follows: Net C 105 T May 2005 187 Product Version 4.1.5 Encounter User Guide Partitioning the Design The fourth net in the report, D, has a wire length of 132.30 micrometers in an ‘X’ shape, which indicates that the net crosses the partition on all four sides, as follows: Net D 132 X In the report, you can also include the total length of the wire crossing the block in the horizontal X direction and total length of the wire crossing the block in the vertical Y direction using the -delta option of the showPtnWireX command. For example, the following report segment is for the same partition module named ptn01 using the -delta option: ################################################################## # Nets that cross partition module ptn01 # Box (335 335) (833 567) # Format: Net <netName> <wireLength> <shape> <deltaX> <deltaY> ################################################################## Net A 65 I 0 65 Net B 80 L 38 47 ... The first net in the report, A, has a wire length of 65 micrometers in an ‘I’ shape, with a total of 0 length in the horizontal X direction, and 65 in the vertical Y direction: Net A 65 I 0 65 May 2005 188 Product Version 4.1.5 Encounter User Guide Partitioning the Design The second net in the report, B, has a wire length of 80 micrometers in an ‘L’ shape, with a total of 38 length in the horizontal X direction, and 47 in the vertical Y direction: Net B 80 L 38 47 Net B X1 Y1 X2 Y2 X3 Y3 Horizontal segment net length X1 = 15 X2 = 5 X3 = 18 Vertical segment net length Y1 = 10 Y2 = 12 Y3 = 25 In the above example, the 38 length in the X direction is calculated for the X direction net segments (X1 + X2 + X3), and the 47 in the Y direction is calculated for the Y direction net segments (Y1 + Y2 + Y3). May 2005 189 Product Version 4.1.5 Encounter User Guide Partitioning the Design Estimating the Routing Channel Width For committed partitions and blackboxes with assigned pins, channel width estimation uses the current pin assignment. If partition pins are not assigned, they are placed at the lower-left corner. In this case, the Encounter software issues a warning message because the estimator cannot produce a good result. For uncommitted partitions, channel width estimation runs the Partition program, assigns pins, estimates the channel widths, and runs the Unpartition program. For blackboxes without assigned pins, it assigns pins and estimates the channel widths. Channel width estimation also considers topology constraints to drive block placement. These constraints are block-to-block boundary, block-to-block distance, block order and alignment, block aspect ratio, net weight (from global trialRoute), and block halo. The channel width estimator also respects these constraints so that their top-level block floorplans are not dramatically changed. If there is conflict between a specified constraint and the minimum required channel spacing, the Encounter software honors the minimum required channel spacing. This feature produces a report containing the following information: ■ Estimated required spacing, in micrometers, between partitions, blackboxes, and hard macros. ■ Estimated required spacing surrounding each partition based on its pins (the relative distance between partition blocks required for top-level routing). ■ Estimated distance between blocks and core boundaries (top, bottom, left, right). May 2005 190 Product Version 4.1.5 Encounter User Guide Partitioning the Design The following figure shows an example of how the channel estimation report relates to the design: HB1 BB1 INST3 INST3 INST2 INST1 Partition May 2005 HB2 Hard Macro Block1 Block2 Current Required bot-boundary bot-boundary bot-boundary lft-boundary lft-boundary lft-boundary INST1 INST1 HB1 HB1 INST4 INST4 ... ... INST1 INST2 HB2 INST1 INST3 HB1 INST3 INST2 top-boundary BB1 top-boundary rht-boundary ... ... 24.6 54.3 25.0 38.2 43.2 46.8 64.8 72.1 57.2 44.5 59.5 53.0 ... ... 28.8 46.9 31.2 45.5 37.8 33.5 39.4 55.7 10.9 69.1 51.7 50.5 ... ... Blackbox 191 Product Version 4.1.5 Encounter User Guide Partitioning the Design Running the Partition Program The Partition program creates the partitions in the top-level design. This changes the module’s status from a fence to a block and generates pins if routing data exists from running Trial Route. When the Partition program is run, the Trial Route data is deleted because the current placement and route data are not suitable for further work at the top level. The partition pin guide (floorplan) object can be used to determine the location of the pins, and nets or buses will be assigned to the partition pin guide objects. If the partitions are changed, then the placement and Trial Route programs must be rerun. To change the status of the partition from being a hard block, you must run Unpartition to flatten the partition. Important After you run the Partition program and save the partition data, you should exit the session and start a new session for the top-level design and for each partition in their newly created UNIX directories. Note: Running the Partition program creates a blockage on an OVERLAP layer even though the OVERLAP layer is not defined in the technology section of the LEF file. As a result, the partition LEF file cannot be loaded into either the Encounter software or any standalone tools. If your design has rectilinear partitions or feedthroughs, the OVERLAP layer must be defined in the technology section of the LEF file. Important If a partitioned design is unpartitioned and then partitioned again, it will lose the original routing and timing information. The routing and timing information are not preserved during the unpartition-partition process. To restore the timing information, Save your routing data before partitioning. If you unpartition later, run the restoreRoute text command to get the routing information, then run extractRC, and then buildTimingGraph, to restore timing information. Top-Level Partition To create a routable, top-level partition, complete the following steps: 1. Run the Partition program. 2. Run Trial Route on the top-level partition. 3. Check for routing congestion. May 2005 192 Product Version 4.1.5 Encounter User Guide Partitioning the Design If there is no congestion, you are done. If there is congestion, continue to step 4. 4. Run the Unpartition program and add more routing resources to the congested area. 5. Rerun the Partition program. Repeat steps 1 – 5 until there is no routing congestion. Block-Level Partition To create a block-level partition, complete the following steps: 1. Run the Partition program. 2. Check to see if each partition size is suitable. If it is, you are done. If it is not, continue to step 3: 3. Run the Unpartition program. 4. Increase the size of the block. 5. Rerun the Partition program. Continue with the steps above until you have reached suitable partition sizes. May 2005 193 Product Version 4.1.5 Encounter User Guide Partitioning the Design Restoring the Top-Level Floorplan with Partition Data To restore the top-level floorplan with partition data, complete the following steps: 1. Import the entire design from the top-level directory that was created or updated when you saved the partition. If any portion of the design (top level or any partition) was changed by running scan optimization, CTS, or IPO, the changed netlist of the entire design is imported, not the original netlist. This changed netlist is usually created by concatenating each of the partition netlists to the top-level netlist. To do this, use a text editor to manually edit it, or use the Design Import form to create a single Verilog netlist of the entire design (see “Concatenating Netlist Files of a Partitioned Design” on page 195). Important If a tool changes the partition netlist, you must update the full chip netlist. Some routers, such as NanoRoute, might modify the partition netlist. The Encounter software requires that the full chip netlist, loaded during Design Import, be consistent with the routed partition netlist. 2. Load the top-level floorplan used to partition the entire design. 3. Set the Partition forms with Perform Pin Assignment deselected and partition the design. 4. Load the top-level placement data from the top-level directory. 5. Choose Design – Load – Partition. This opens the Load Partition form. 6. In the Load Partition form, enter the directory name where the partition data was saved. 7. Click OK. Tip In place of steps 5, 6, and 7, you can use the setTopCell command to restore the partition and top-level data for the entire design. This is especially useful for restoring placement data from a DEF or TDF file. Note: To perform a full chip analysis or a timing budget refinement analysis, use the Unpartition form to flatten the design. May 2005 194 Product Version 4.1.5 Encounter User Guide Partitioning the Design Concatenating Netlist Files of a Partitioned Design To create a single Verilog netlist of the entire design, top level plus all the partitions, complete the following steps: 1. Start a new Encounter session. 2. Choose Design – Design Import to open the Design Import form, and click the Design tab if it is not selected. 3. In the Verilog Files field, enter each netlist filename in the order from top-level netlist followed by the partition netlist files. Note: The partition netlist are read from each of the partition’s work directories. 4. Click OK. 5. Choose Design – Save – Netlist to open the Save Netlist form. 6. Enter a Verilog file netlist name in the Netlist File field. 7. Click OK. 8. Use the saved Verilog file to restore the top-level floorplan with partition data (see “Restoring the Top-Level Floorplan with Partition Data” on page 194). May 2005 195 Product Version 4.1.5 Encounter User Guide Partitioning the Design Saving Partitions You can save partition results, including the top-level partition, to their own subdirectories so that each partition can be worked on concurrently. Each partition directory contains all files necessary to run the Encounter software. Files necessary to run back-end tools in DEF, PDEF, and TDF formats can be selected when saving partitions. To save a partition, use the Save Partition form or the savePartition text command. Caution Do not use the Save Design form to save a partition. May 2005 196 Product Version 4.1.5 Encounter User Guide Partitioning the Design Loading Partitions After completing the design work for each partition and the top level, you can restore a partitioned design to the top level, which includes loading all the partition design directories and its data. To restore a saved partition design, use the Load Partition form. Unpartitioning with Routing Data When loading a partition, it is important that the loaded routing results correctly correspond to the new netlist. To ensure that the netlist and routing file are consistent, you need to unpartition with the routing data using the following steps: 1. Load the original flat design. This is the original design before running the partition steps. 2. Specify the partition and save to a file (to be loaded later in step 7). 3. Run partitioning with pin assignment. 4. Save the partitions and the top level. 5. For each partition and the top-level, run the block-level implementation with the following commands: ❑ encounter ❑ restoreDesign (for the block or top level) ❑ trialRoute or nanoroute or wroute ❑ saveRoute 6. Load the original design (the same design loaded in step 1). If the netlist has been modified after step 1 (for example, in the case where a netlist is modified after in-place optimization or running NanoRoute) use the updated netlist instead. To specify the updated netlist, you must first specify top-level netlist, then the block-level netlists in the Verilog Files field of the Design Import form’s Design page. For example, top.v block1.v block2.v ... May 2005 197 Product Version 4.1.5 Encounter User Guide Partitioning the Design Important The netlist and routing must be consistent when loading a partition with routing data, be sure you load the design with floorplanning, placement, and routing data that is consistent with the data saved in step 4. 7. Load the partition file (specified in step 2). 8. Run partitioning without pin assignment. 9. Load the partition data. For each partition, select the partition, then change the partition view (using the Partition – Change Partition View menu command) and load all the data for the viewed partition. You can use either the DEF file, or the .fp, .place and .route files. 10. Reset the view back to the top level (using the Partition – Change Partition View menu command). 11. Load the top-level data. You can read in the top-level physical information by either using the DEF file or the placement (.place) and routing (.route) file. You must not read in the floorplan (.fp) file again because the floorplan information was already read in at the very beginning. Note: Top-level physical information can only be loaded using DEF. 12. Unpartition the design (flattenPartition). May 2005 198 Product Version 4.1.5 Encounter User Guide 7 Interface Logic Models This chapter describes how to generate and use Interface Logic Models (ILMs). The chapter presents the following topics: ■ Overview on page 200 ■ Text Commands for Generating and Using ILMs on page 202 ■ Generating ILMs With Different Pin Data on page 203 ■ Generating ILMs With Different Latch Levels on page 207 ■ Performing Top-Level Partitioning by Identifying the Interface Logic on page 211 ■ Generating ILMs for a Partition Block ■ Performing Timing Analysis Using ILMs on page 213 May 2005 199 Product Version 4.1.5 Encounter User Guide Interface Logic Models Overview Models are compact and accurate representations of timing characteristics of a block. Using models instead of gate-level netlists for blocks reduces runtime and memory requirements. Interface Logic Models (ILMs) are a structural representation of a model. ILMs are not abstracted timing models. To create an ILM, you use the netlist of a block. After creating ILMs, the resulting netlist contains the circuitry leading from the I/O ports to interface registers (edge-triggered registers), and from interface registers to I/O ports. The clock tree leading to the interface registers is preserved. ILMs do not contain any information about the internal register-to-register paths, or any logic between the interface registers. If the logic between the I/O ports is pure combinational, it is preserved in an ILM. A transparent latch is treated as combinational device and path tracing continues through the latch. When identifying interface logic you can specify a list of input ports that can be ignored. For example, you can specify the SET, RESET connectivity to be ignored when generating ILMs. Note: Do not use ILMs for timing optimization. Also, clock tree synthesis does not support ILMs. The following figure shows the ILM generation flow. Load gate-level netlist Load constraints for the netlist Place, Route, and Optimize the Block Generate ILMs using deriveInterfaceLogic Save ILMs using saveInterfaceLogic Verilog and SPEF files for ILMs The advantages of creating ILMs are as follows: May 2005 200 Product Version 4.1.5 Encounter User Guide Interface Logic Models ■ An ILM contains information that is required for modeling boundary timing, so the accuracy is maintained. The accuracy is typically within a few Pico seconds. ■ The time to perform timing analysis at the top improves because the entire design is not loaded in the memory. ■ The design requires less memory. ■ Debugging is easier. The disadvantage of creating ILMs are as follows: ■ Implementation details are not hidden from other users. ■ If the block is purely logical, the generated ILM contains all of the original circuitry. Therefore there is no reduction in size. May 2005 201 Product Version 4.1.5 Encounter User Guide Interface Logic Models Text Commands for Generating and Using ILMs To create an ILM for a module after detailed implementation, use the following commands: ■ deriveInterfaceLogic Derives the interface logic of the module by eliminating all internal registers to register logic that do not have a direct path to the I/Os. ■ saveInterfaceLogic Saves the previously derived interface logic models to the dirName directory. If you do not specify a directory, the logic is saved to the current working directory. A .v file and, optionally, a .spef file are created in a subdirectory that has the same name as the module. For example, if the module is named abc, then you would find abc.v and abc.spef under the subdirectory abc. By default, the command saves the hierarchical ILM netlist. ■ commitInterfaceLogic Marks ILM model in the top-level design. To stitch the top-level spef (after top level routing) with each module's spef, use the -ilm argument in the spefIn command. After the buildTimingGraph command, the timing view down to the interface logic of each ILM is exposed. May 2005 202 Product Version 4.1.5 Encounter User Guide Interface Logic Models Generating ILMs With Different Pin Data Before generating an ILM, you must load a gate-level netlist and constraints for this netlist. 1. Start the process of generating ILMs by identifying the ports that propagate to a large number of flip-flops and to identify false paths. To do this, use the -trial parameter of the deriveInterfaceLogic command. This process is useful for large designs. 2. Run the following command to identify the pins you want to exclude from ILM generation: deriveInterfaceLogic -trial [-maxFaninInst value] [-maxFanoutInst value] [-maxFaninReg value] [-maxFanoutReg value] 3. Use the -ignore parameter to exclude the identified pins in an ILM. Run the following command to exclude particular pins in an ILM: deriveInterfaceLogic -ignore <pins you want excluded> Netlist and Constraints Example for ILM Generation Consider a netlist with 18 leaf-level cells. Ten of the cells are combinational cells, and eight are flip-flops. The the design has 24 nets. a3 i1 i2 D D Q F1 Q a4 a8 D a2 F2 CK D Q F3 CK F4 CK CK x33 a5 a7 a6 D i3 i4 i5 May 2005 CK a1 x4 D Q F5 o1 Q x31 Q F6 x40 a9 o2 CK x41 x44 a10 D Q F7 CK D Q F8 x42 CK 203 Product Version 4.1.5 Encounter User Guide Interface Logic Models The gate-level netlist is as follows: module top (i1, i2, i3, i4, i5, o1, o2); input i1, i2, i3, i4, i5; output o1, o2; DFFHQX1 F1(.Q(x11), .CK(i2), .D(i1)); DFFHQX1 F2(.Q(x21), .CK(x11), .D(x22)); AND2X1 a2 (.Y(x23), .A(x21), .B(x35)); BUFX4 a3 (.Y(x22), .A(x23)); BUFX4 a4 (.Y(x32), .A(x23)); DFFHQX1 F5(.Q(x31), .CK(i3), .D(x22)); BUFX4 a5 (.Y(x35), .A(x31)); BUFX4 a6 (.Y(x33), .A(x31)); BUFX4 a7 (.Y(x39), .A(x33)); DFFHQX1 F3(.Q(x36), .CK(x35), .D(x32)); BUFX4 a8 (.Y(x38), .A(x36)); DFFHQX1 F4(.Q(o1), .CK(x33), .D(x38)); BUFX4 a1 (.Y(x4), .A(i4)); DFFHQX1 F7(.Q(x44), .CK(i5), .D(x4)); BUFX4 a10 (.Y(x41, .A(x44))) DFFHQX1 F6(.Q(x40), .CK(x41), .D(x39)); DFFX1 F8(.QN(x43), .Q(x42), .CK(x41), .D(x43)); AND2X1 a9 (.Y(o2), .A(x40), .B(x42)); endmodule The design uses the following constraints: create_clock -name CLK1 -period 2 [get_ports "i2 i3 i5"] create_clock -name internal -period 2 [get_pins “F7/Q”] set_input_delay -clock CLK1 -source_latency_included 0.5 [get_ports "i1 i4"] set_output_delay -clock CLK1 1 [all_outputs] set_propagated_clock [all_clocks] The netlist has the following components: ■ Data ports i1, i4 ■ Clock ports i2, i3, i5 All non-clock input and output ports are used to identify interface registers. ■ Interface registers F1, F4, F6, F7, and F8 These are identified as interface registers because of their connectivity to I/O ports. This data is preserved in an ILM. ■ Registers F5, F2, and F3 These registers do not contribute to the timing of the interface registers so are not preserved in an ILM. ■ Combinational logic a1 and a9 on the fan-out/fan-in cones of the interface registers and IO ports. This logic is preserved in an ILM. May 2005 204 Product Version 4.1.5 Encounter User Guide Interface Logic Models Combinational logic between F2, F3, and F5, and fan-out/fan-in connections to these registers. ■ This logic is not preserved in an ILM. Feedback path from F8/QN to F8/D. ■ This data is not preserved in an ILM. Fan-in of a6, and fan-out of a7. ■ This data is not preserved because they do not add to the timing of the ILM. Default ILM Generation To generate ILMs, specify the following command: deriveInterfaceLogic The following figure shows the result of the deriveInterfaceLogic command. The combinational logic connecting to clock-pins of interface registers are preserved up to one clock level. i1 i2 D D Q F1 o1 Q F4 CK CK x33 x31 a6 D F5 i3 i4 i5 CK a1 x4 x40 D Q Q F6 a9 o2 CK x41 x44 a10 D Q F7 CK D Q F8 x42 CK In the generated ILMs, the combinational logic net pins a6, and a10 connected to the clock pin of interface registers are preserved and written to the netlist. The ILM netlist has ten leaflevel cells: six flip-flops, and four combinational cells. The resulting ILM is as follows: module top ( i1, i2, i3, i4, i5, o1, o2 ); input i1, i2, i3, i4, i5; output o1, o2; May 2005 205 Product Version 4.1.5 Encounter User Guide Interface Logic Models wire x44, x42, x41, x40, x4, x33, x31; DFFHQX1 F1 ( .D(i1), .CK(i2) ); DFFHQX1 F4 ( .CK(x33), .Q(o1) ); DFFHQX1 F5( .CK(i3), .Q(x31) ); DFFHQX1 F6 ( .CK(x41), .Q(x40) ); DFFHQX1 F7 ( .D(x4), .CK(i5), .Q(x44) ); DFFX1 F8 ( .CK(x41), .Q(x42) ); BUFX4 a1 ( .A(i4), .Y(x4) ); BUFX4 a10 (.A(x44), .Y(x41)) BUFX4 a6 ( .A(x31), .Y(x33)); AND2X1 a9 ( .A(x40), .B(x42), .Y(o2) ); endmodule Net x33 is connected to F4/CK, a6/Y. Net x31 is connected to a6/A and f5/Q. The net pins are included in the netlist. May 2005 206 Product Version 4.1.5 Encounter User Guide Interface Logic Models Generating ILMs With Different Latch Levels The Encounter software enable you to generate ILMs by specifying the level of the latch to trace through the netlist. You use the -latchLevel parameter of the deriveInterfaceLogic command to specify the level of latch that the software traces for generating ILMs. This feature enables you to treat latches as transparent during ILM generation. Examples The following examples show the different scenarios in which you can use the -latchLevel parameter to trace through the netlist for generating ILMs, and their expected results. ■ “Netlist with Five Latch Levels” on page 207 ■ “Netlist With One Flip-Flop And Different Latch Levels” on page 208 ■ “Netlist With Two Flip-Flops And Different Latch Levels” on page 209 Netlist with Five Latch Levels In this example, the ILM is generated for gate-level netlist for a block using different latch levels. The netlist consists of five latch levels. The ILM is generated by defining different levels of latch using the -latchLevel parameter. The value of parameter varies from -1 to 3. lat2 lat1 in D Q G D lat3 Q G D lat4 D Q G lat5 Q G D Q out G CK The gate-level netlist is as follows: module test_latch1 (ck, in, out); input ck, in; output out: TLATX1 lat1 (.D(in), .Q(n1), .G(ck)); TLATX1 lat2 (.D(n1), .Q(n2), .G(ck)); TLATX1 lat3 (.D(n2), .Q(n3), .G(ck)); TLATX1 lat4 (.D(n3), .Q(n4), .G(ck)); TLATX1 lat5 (.D(n4), .Q(out), .G(ck)); endmodule May 2005 207 Product Version 4.1.5 Encounter User Guide Interface Logic Models To generate ILM while preserving different levels of latch information, specify the following command: deriveInterfaceLogic -latchLevel level Where, level = -1, 0, 1, 2, 3 Depending on the value of level that you specify, the software preserves the latch information in the resulting netlist. The following table shows the result of the command above. level lat1 lat2 lat3 lat4 lat5 -1 Preserved Preserved Preserved Preserved Preserved 0 Preserved Ignored Ignored Ignored Preserved 1 Preserved Preserved Ignored Preserved Preserved 2 Preserved Preserved Preserved Preserved Preserved 3 Preserved Preserved Preserved Preserved Preserved In this table the first column represents the latch level that you specify using the latchLevel parameter. The next columns represent the latches that are preserved or ignored depending on the level that you specify. For example, when you specify the following command: deriveInterfaceLogic -latchLevel 0 Latches 1 and 5 are preserved, and latches 2, 3, and 4 are ignored in the resulting ILM netlist. Netlist With One Flip-Flop And Different Latch Levels The netlist consists of one flip-flop with two latches on either side. The ILM is generated by defining different levels of latch using the -latchLevel parameter. The value of the parameter varies from -1 to 3. lat2 lat1 in D Q G D ff3 Q G D lat4 D Q CK lat5 Q G D Q out G CK May 2005 208 Product Version 4.1.5 Encounter User Guide Interface Logic Models The gate-level netlist is as follows: module test_latch2 (ck, in, out); input ck, in; output out: TLATX1 lat1 (.D(in), .Q(n1), .G(ck)); TLATX1 lat2 (.D(n1), .Q(n2), .G(ck)); DFFX1 ff3 (.D(n2), .Q(n3), .CK(ck)); TLATX1 lat4 (.D(n3), .Q(n4), .G(ck)); TLATX1 lat5 (.D(n4), .Q(out), .G(ck)); endmodule Depending on the value of level that you specify using the deriveInterfaceLogic latchLevel level command, the software preserves the latch information in the resulting netlist. The following table shows the result of the deriveInterfaceLogic command. level lat1 lat2 ff3 lat4 lat5 -1 Preserved Preserved Preserved Preserved Preserved 0 Preserved Ignored Ignored Ignored Preserved 1 Preserved Preserved Ignored Preserved Preserved 2 Preserved Preserved Preserved Preserved Preserved 3 Preserved Preserved Preserved Preserved Preserved In this case, when you specify the following command: deriveInterfaceLogic -latchLevel 1 Latches 1, 2, 4, and 5 are preserved, and flip-flop 3 is ignored in the resulting ILM netlist. Netlist With Two Flip-Flops And Different Latch Levels The netlist consists of one flip-flop with two latches on either side. The ILM is generated by defining different levels of latch using the -latchLevel parameter. The value of the parameter varies from -1 to 3. D Q G D CK ff4 lat3 ff2 lat1 in Q D D Q CK G lat5 Q D Q out G CK May 2005 209 Product Version 4.1.5 Encounter User Guide Interface Logic Models The gate-level netlist is as follows: module test_latch3 (ck, in, out); input ck, in; output out: TLATX1 lat1 (.D(in), .Q(n1), .G(ck)); DFFX1 ff2 (.D(n1), .Q(n2), .CK(ck)); TLATX1 lat3 (.D(n2), .Q(n3), .G(ck)); DFFX1 ff4 (.D(n3), .Q(n4), .CK(ck)); TLATX1 lat5 (.D(n4), .Q(out), .G(ck)); endmodule Depending on the value of level that you specify using the deriveInterfaceLogic latchLevel level command, the software preserves the latch information in the resulting netlist. The following table shows the result of the deriveInterfaceLogic command. level lat1 ff2 lat3 ff4 lat5 -1 Preserved Preserved Ignored Preserved Preserved 0 Preserved Ignored Ignored Ignored Preserved 1 Preserved Preserved Ignored Preserved Preserved 2 Preserved Preserved Ignored Preserved Preserved 3 Preserved Preserved Ignored Preserved Preserved In this case, when you specify the following command: deriveInterfaceLogic -latchLevel 2 Latches 1, 2, 4, and 5 are preserved, and latch 3 is ignored in the resulting ILM netlist. May 2005 210 Product Version 4.1.5 Encounter User Guide Interface Logic Models Performing Top-Level Partitioning by Identifying the Interface Logic The Encounter software provides a top-level interface timing analysis flow to perform partitioning and budgeting on a trimmed-down version of the timing graph. This flow saves memory usage and provides faster run time on large designs. the results of the flow are comparable to results of partitioning and budgeting with full timing graph. To perform partitioning and budgeting using top-level timing analysis, complete the following steps: 1. Load the hierarchical design in the database. Specify the partition information in the database. source init.enc 2. Run placement. amoebaPlace -fp -timingDriven -ignoreScan 3. Run trialRoute. trialRoute -noDetour -floorplanMode 4. Identify interface logic for all the partitions. deriveInterfaceLogic -partition -keepClock 5. Mark the interface logic in all the partitions in the top-level design. When you build the timing graph after using this command, the software ignores the core logic of the partitions. commitInterfaceLogic 6. Build the trimmed-down version of the timing graph. The software builds the timing graph ignoring the core logic of the partitions. buildTimingGraph 7. Commit partition. commitPartition -timingShell -boundryTrialIPO 8. Save the partitions. savePartition May 2005 211 Product Version 4.1.5 Encounter User Guide Interface Logic Models Generating ILMs for a Partition Block To prepare a design for generating ILMs, complete the following steps: 1. Start an Encounter session, and load the configuration file partitionName.conf. 2. Load the DEF file or perform steps 3 and 4. 3. Run timing-driven placement using medium placement effort level. 4. Run NanoRoute. 5. Run RC extraction in detail mode. 6. Use the deriveInterfaceLogic command with -ignore pinList option to derive the ILM netlist. Generating ILMs removes all flip-flops in a design except the interface flipflops. 7. Use the saveInterfaceLogic command to save the derived ILM netlist and SPEF files for modules. May 2005 212 Product Version 4.1.5 Encounter User Guide Interface Logic Models Performing Timing Analysis Using ILMs The Encounter software provides a bottom-up flow to perform timing analysis using ILMs. To perform timing analysis using ILMs, complete the following steps: 1. Start an Encounter session from the top level module directory that is in the directory where partitions are saved. 2. Load the top-level configuration file toplevel.conf. Include the ILM files in the configuration file. For example, the following ILM information is included in the configuration file: set rda_Input (ui_ilmlist) “../tdsp_core/ilmnew/tdsp_core/tdsp_core.v” 3. Load the top-level floorplan. 4. Load the top-level placement. 5. Load the routing database or run NanoRoute. 6. Run RC extraction in the detail mode or load the top-level SPEF using the spefIn command. 7. Load the ILM SPEF files using the spefIn -ilm command. 8. Run timing analysis and generate reports using the timeDesign designStage -ilm command. This command flattens the ILMs so that the internal logic of the block is visible at the top, and generates the timing reports. This way the entire design can be analyzed. May 2005 213 Product Version 4.1.5 Encounter User Guide Interface Logic Models May 2005 214 Product Version 4.1.5 Encounter User Guide 8 Floorplanning the Design This chapter describes how to use the Floorplan menu forms to specify and modify a floorplan. This chapter presents the following topics: ■ Overview on page 216 ■ Common Floorplanning Sequence on page 217 ■ Viewing the Floorplan on page 218 ■ Module Constraint Types on page 220 ■ Editing Pins on page 228 ■ Running Relative Floorplanning on page 235 ■ Running Module Placement on page 242 ■ Saving and Loading Floorplan Data on page 254 May 2005 215 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Overview The effort required for floorplanning depends on the prototyping level of the design. For example, floorplanning is very important when preparing the design for timing closure and detailed routing. Floorplanning, in conjunction with placement and trial routing, can be an iterative design process. Floorplanning usually starts by preplacing blocks, modules, and submodules according to the prepared floorplan. All other modules or blocks not in the prepared floorplan are left outside the chip area. The Encounter software includes several keyboard shortcuts for use with the floorplanning feature. Make sure you type the bindkey while the main Encounter window is active and the cursor is in the design display area. The Binding Key form contains a complete list of bindkeys. To display this form, select Design – Preferences from the Encounter menu, then click the Binding Key button on the Preferences form, or use the default b binding key. May 2005 216 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Common Floorplanning Sequence The following steps describe the most common sequence for floorplanning: 1. Import the design. 2. Study the design’s connectivity. 3. Perform the minimum amount of floorplanning based on the chip design floorplan, or do no floorplanning at all. In some cases, no floorplanning is required. For example, a front-end designer might want to predict the quality of the design’s netlist by initially placing the entire design without any floorplanning. This iteration provides a good indication of the how the blocks should be located and arranged together with the larger modules. After a few iterations, it should be clear how to position the blocks and modules in the floorplan. 4. Run Amoeba placement and Trial Route to view placement and routing congestion. In this case, floorplanning is done to detail the pre-placement of all blocks, most likely done by a back-end designer to gauge the feasibility of a prepared floorplan. The placer places all remaining modules and blocks that were not preplaced in the floorplan, and also recognizes the floorplan object, such as power and ground routes. Tip If you are at the design’s top-level in the display area and want to generate a guide for a submodule, ungroup the top module until you have reached the submodule. 5. Use the full chip placement to refine block (hard macro and blackbox) locations. View the placements of blocks to determine if you need to change the alignment or orientations. 6. Look for congestion in modules and change heavily congested modules’ placement density to a lower percentage (using the createDensityArea text command). 7. (Optional) If you made any changes in step 5, or especially step 6, rerun Amoeba placement. Important The placer completes the placement of the entire design of all modules and blocks that were not preplaced during floorplanning. May 2005 217 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Viewing the Floorplan In the design display area, the objects to the left of the core area are the top-level modules, which can be moved and reshaped. The objects to the right of the chip area are the blocks, which can be moved but not reshaped. Modules Core Area Blocks The Floorplan view displays the hierarchical module and block guides, connection flight lines, and floorplan objects, including block placement, and power/ground nets. Use the G key (ungroup), or click the Hierarchy Down icon, to display the submodules for a selected module guide. Each time you use the G key, you move further down the hierarchy. Use the g key (group), or click the Hierarchy Up icon, to move up the hierarchy. May 2005 218 Product Version 4.1.5 Encounter User Guide Floorplanning the Design In Floorplan view, you can view the block pins and connection flight lines by clicking on a block or module. Flight lines show the connections and number of connections between the selected module or block to any other modules and blocks. Number of Connections The pins for blocks are displayed where the flight lines terminate to help you orient the blocks so that the block pins face in the direction that best reduces routing congestion. You can change the die or core size; the margins between the core box and I/O pad instances; and the individual die (head), I/O, or core box sizes. These boxes are shown in the following figure. Core Box (Chip Area) IO Box Die (Head) Box May 2005 219 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Module Constraint Types The entire design size is initially calculated during design import, and each module size is calculated. The size of the modules are determined by either the core utilization or the core width and height specifications. The imported design modules can have one of the following constraint types: ■ None—The module is not pre-placed in the core design area. The Amoeba placement program places the contents of the module without any constraints. ■ Guide—The module is preplaced in the core design area. A module guide represents the logical module structure of the netlist. The purpose of a module guide is to guide Amoeba placement to place the cells of the module in the vicinity of the guide’s location. The preplaced guide is a soft constraint, which is discussed later in this section. After the design is imported, but before floorplanning, you can locate module guides on the left side of the core area, which appear as pink objects (by default) in the Floorplan view. When a module is preplaced in the core design area, it snaps to a standard cell row in the vertical direction and to a metal 2 pitch in the horizontal direction (the default). This default can be changed to snap to the manufacture grid (in the Preferences form’s Floorplan page). To create a guide for a module, or a group that contains hierarchical instances, instances (leaf instance), or other groups, use the createGuide command or select Guide from the Attribute Editor’s Constraint Type pulldown menu. ■ Fence—The module is a hard constraint in the core design area. After specifying a hierarchical instance as a partition, the constraint type status of a module guide is automatically changed to a fence. The physical outline of a fence module is rigid, and the design for the module is selfcontained within the rigid outline. Only child instances must be contained within the partition physical outline; non-child blocks or modules that do not belong to the partition are excluded, and should not be pre-placed within another partition. This restriction is a hard restriction for third party back-end tools where the placement file for a partition does not match the partition netlist. To create a fence for a module, or a group that contains hierarchical instances, instances (leaf instance), or other groups, use the createFence command or select Fence from the Attribute Editor’s Constraint Type pulldown menu. Note: Fence groups can potentially cause overlaps that cannot be corrected because the Encounter software cannot move the cells out of the group. May 2005 220 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ Region—This constraint is the same as a fence constraint except that instances from other modules can be placed within its physical outline by Amoeba placement. A module guide is changed to a status of Region when preplaced in the core design area. To create a region for a module, or a group that contains hierarchical instances, instances (leaf instance), or other groups, use the createRegion command or select Region from the Attribute Editor’s Constraint Type pulldown menu. Note: Region groups can potentially cause overlaps that cannot be corrected because the Encounter software cannot move the cells out of the group. ■ Soft Guide—This constraint is similar to a guide constraint except there are no fixed locations. This provides stronger grouping for the instances under the same soft guide. The soft guide constraint is not as restrictive as a fence or a region constraint, so some instances might be placed further away if they have connections to other modules. To create a soft guide for a module, or a group that contains hierarchical instances, instances (leaf instance), or other groups, select SoftGuide from the Attribute Editor’s Constraint Type pulldown menu. Target Utilization Display Module constraints display a target utilization (TU=%) value to represent their physical design size. This is an estimation of module utilization for the given size of the module where only standard cell and hard macro areas are considered; floorplan constraints, such as placement blockages, are not considered. This value is calculated by the standard cells area plus the hard macros area, divided by the module area. The initial TU values are calculated during design import. The TU percentage helps judge the physical size of a module guide to customize the shape of the module in the floorplan. For example, modules SH19 and SH7 have a TU values of May 2005 221 Product Version 4.1.5 Encounter User Guide Floorplanning the Design 77.2%. If the modules are reshaped with the same area, they retain their TU values, as shown in the following figure: TU=77.2% reshape TU=77.2% SH19 SH19 TU=77.2% reshape TU=77.2% SH7 SH7 You can place them in the core area so they are preplaced close to one another, as shown in the following figure: Block Block SH19 SH7 The position of the module guide is a constraint to the Amoeba placement program, and the final definition of the module is determined by several factors. The most important factor—the May 2005 222 Product Version 4.1.5 Encounter User Guide Floorplanning the Design highest priority of constraint—is the connectivity between itself and other modules. Other floorplan constraints, such as neighboring preplaced module guides, preplaced blocks, placement blockages, and routing blockages, are also considered, but at a lower priority than connectivity. Note: You can use a stronger constraint for keeping modules SH19 and SH7 close together using the Group Instances form, and even a stronger constraint by saving the regrouped netlist. Unlike module guides, the position of fences and regions is a hard constraint to the Amoeba placement program, and are not moved by the same factors. Effective Utilization Display For fences and regions, you can display the effective utilization (EU=%) value. The EU value takes into account the actual cells and hard macros in the fence or region, placement or routing blockages, partition cuts, and other floorplan constraints. It is a good practice to update the EU value before running Amoeba placement. Click the Display/Calculate Effective Utilization toolbar widget (the % button above the design display area) to display the EU value for each fence and region, as shown in the following figure. TU=77.2% EU=84.7% SH19 Note: The displayed EU values are not automatically updated. You must click the Display/ Calculate Effective Utilization toolbar widget each time you want to display the updated EU value. This calculation could be time consuming, especially for larger designs. Note: If the EU value is at or exceeds 100% for a fence or region, the Amoeba placement program changes the fence or region to a guide. To avoid this, before you run Amoeba placement, make sure to check and update the EU value, if necessary. May 2005 223 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Calculating Density When specifying the floorplan, you can determine the core and module sizes by total density or standard cell density using the Core Utilization or Std. Utilization options, respectively, in the Specify Floorplan form. Core Utilization determines the initial size of the core area and the initial size of the pink module guides off to the left of the die area. The total density is calculated as follows: Core Size = (standard cell area/core utilization) + (macro area + halo) In determining the size of the core area and module guides, standard cells and hard macros are treated the same. However, you can determine how densely objects can be packed by weighing the standard cell density separately from the hard macro density. The standard cell density is calculated as follows: Core Size = (standard cell area /standard cell utilization) + (macro area + halo) The size of the core is smaller once you specified your floorplan by using Std. Utilization. May 2005 224 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Standard Row Spacing To configure the rows, use the setFPlanRowSpacingAndType command, or the options from the Standard Cells Rows panel of the Specify Floorplan form. The following row configurations are supported: Bottom R0 and flip/abut Bottom MX and flip/abut Bottom R0 and flip Bottom MX and flip May 2005 Bottom R0 and abut Bottom R0 225 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Grouping Instances The hierarchy of the new instance group is formed at the common point of the modules and submodules. The following example shows how the hierarchy is changed from the common point if submodules B and F are added to a new group called group_A. Top group_A Top A A D D B B C E F C F E To delete an instance from an instance group, complete the following steps: 1. Choose Tools – Design Browser. 2. In the Design Browser, click on and highlight the module or submodule guide(s) to be deleted from the instance group. 3. Click the Delete Group/Group Member icon. To add an instance to an existing group name, complete the following steps: 1. Click on and highlight the module or submodule guide(s) to be added to an instance group. 2. Choose the Floorplan – Create Physical Hierarchy submenu to select the group name. To save the instance group back to the netlist, use the Generate Regrouped Netlist form (Floorplan – Generate Regrouped Netlist). May 2005 226 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Defining the Bounding Box During floorplanning, you can use the setObjFPlanBox command to define a bounding box of a specified object, and the setObjFPlanBoxList command to define rectilinear shape of an object, which is comprised of two or more boxes. This section provides graphical information to illustrate some of the command examples in the Floorplan Commands chapter of the Encounter Text Command Reference. setObjFPlanBox The following command specifies a bounding box for Module abc at a lower left x coordinate of 100.0, a lower left y coordinate of 100.0, and upper right x coordinate of 400.0, and an upper right y coordinate of 545.0: setObjFPlanBox Module abc 100.0 100.0 400.0 545.0 400.0, 545.0 Module abc 100.0, 100.0 setObjFPlanBoxList The following command defines a rectilinear boundary for Module xyz. The rectilinear boundary is made up of two bounding boxes: (371.46, 537.60) (696.96, 754.35), and (412.5, 754.32) (696.96, 920.64): setObjFPlanBoxList Module xyz 371.46 537.60 696.96 754.35 412.5 754.35 696.96 920.64 696.96, 920.64 412.5, 754.35 696.96, 754.35 Module abc Module xyz 371.46, 537.60 May 2005 227 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Editing Pins This section describes how you can move and manipulate pins in your design. For information on blackbox and partition pins, see Assigning Pins on page 166. Pin Snapping on Resized Boundaries As the boundary size increases, the pins maintain their exact horizontal and vertical coordinates, depending on the modified edge. As the boundary size decreases, the pin snap retains its relative position on the modified edge. This following figure illustrates this capability. For the size decreasing example, pins A1 and A2 are both snapped to the upper right corner. A1 A2 Size Increase Size Decrease Note: This feature is limited to rectangular edges. Moving a Group of Pins To move a group pins, all the pins should be at same block and same side of block. By default, all the pins will move together relatively and the layer will be changed to the appropriate layer if the side was changed. For example, layer M2 is changed to M1 when moving pins from top to left. Moving pins from top to bottom does not change the layer. To move a selected group of pins in the design display area from one edge to another edge (including rectilinear edges) on a module, preserving the relative position between pins, complete the following steps: 1. Click the Move/Resize/Reshape widget. 2. Select (highlight) the pins in the design display area while pressing the Shift key. May 2005 228 Product Version 4.1.5 Encounter User Guide Floorplanning the Design 3. Left click on the pins and move them to the new location. Tip To zoom out on the design display area while dragging the pins, press the ShiftZ key combination. During the group pin move, or when the selected pins are in move mode (selecting pins in the design display area with the Move/Resize/Reshape tool widget), you can press the F3 key to open the Group Pin(s) Move form to change the pin layer, the pin size, pin status, and resolve pin overlap. You can use the moveGroupPins to perform the same actions as the form, with the addition of moving the group of pins to the new location. Swapping Pins You can swap pins using the swapPins command or the Swap Pins option in the design display area by completing the following steps. 1. Select two pins of the same block. 2. With the cursor over one of the selected pins, click and hold the middle mouse button to bring up the context pop-up menu. 3. Select Swap Pins. Using the Pin Editor You can use the Pin Editor to display and edit pin and pin groups. To open the Pin Editor, choose Tools – Pin Editor. For information in the fields and options, see Pin Editor in the Tools Menu chapter of the Encounter Menu Reference. The following sections describes some of the features that you can use with the Pin Editor. Using the Pin-Spreading Feature The Pin Editor includes a utility to spread pins along the edges of a block. There are four different methods of spreading pins: ■ Use a pin as the starting point (anchor) and provide a pin spacing distance. ■ Use the center of a block edge as the starting point and provide a pin spacing distance. May 2005 229 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ Space the pins evenly along the block edge, using the ends of the block edge as the starting and ending points. The Pin Editor calculates the pin spacing distance. ■ Space the pins evenly using explicit starting and ending points on the block edge. The Pin Editor calculates the pin spacing distance. Basic Concepts for Pin Spreading Two basic concepts underlie the pin-spreading functionality of the Pin Editor: ■ Pin ordering affects the starting point for pin spreading. Use the Pin Editor’s Group Bus, Reverse Order, or Reorder Pin List functions to specify the first pin in a group. The coordinates of the first pin in a group provide the starting point from which to spread pins. ■ Pin spacing distances can be expressed in either positive or negative values: Positive spacing values spread pins to the right along a horizontal block edge, or up along a vertical block edge. Negative spacing values spread pins to the left along a horizontal block edge, or down along a vertical block edge. Note: You cannot specify pin spacing distances with spacing methods that rely on the Pin Editor to determine the spacing. The following sections provide details on the four pin-spreading methods supported by the Pin Editor. Using a Pin as the Starting Point for Spreading Pins For this method, you select a group of pins and sort them in the desired order. The first pin in the list serves as the starting point (anchor) for spreading the other pins in the group. You must also provide the pin spacing distance. Assume that your design contains four pins (A1, A2, A3, and A4) that are currently spaced 2.0 µm apart. You want to spread the pins to the right with 3.0 µm spacing, using A1 as the starting point. To do this you must 1. Sort the pins so that A1 is the first pin in the list. The coordinates of A1 appear in Starting X/Y. 2. Select Spread – From Starting Point. May 2005 230 Product Version 4.1.5 Encounter User Guide Floorplanning the Design 3. Specify a positive spacing value: 3.0. The following figure illustrates this situation: Original spacing: 2.0 µm A1 Desired spacing: 3.0 µm, with A1 as starting point and the pins spreading to right A1 A2 A3 A2 A4 A3 A4 Now assume that you want to spread the pins to the left with 4.0 µm spacing, using A4 as the starting point. To do this you must 1. Sort the pins so that A4 is the first pin in the list. The coordinates of A4 appear in Starting. 2. Specify a negative spacing value: -4.0. The following figure illustrates this situation: Original spacing: 2.0 µm A1 A2 A3 A4 Desired spacing: 4.0 µm, with A4 as starting point and the pins spreading to the left A1 A2 A3 A4 Using the Center of a Block Edge as the Starting Point for Spreading Pins For this method, you select a group of pins and sort them in the desired order. You must also provide the pin spacing distance. Assume that your design contains four pins (A1, A2, A3, and A4). You want to define new spacing and then group the pins so that the group is centered on the midpoint of the block edge. To do this you must 1. Sort the pins in the desired order (optional). 2. Select Spread – From Center. May 2005 231 Product Version 4.1.5 Encounter User Guide Floorplanning the Design 3. Specify a positive spacing value: 3.0. The following figure illustrates this situation: Original pin spacing A1 A2 A3 A4 New spacing, with the pin group centered on the midpoint of the block edge A1 A2 A3 A4 Edge midpoint Spacing Pins Evenly Using the Block Edge Ends as Limits For this method, you select a group of pins and sort them in the desired order. You do not specify a pin spacing distance because the Pin Editor calculates the appropriate distance, based on the length of the block edge, and spaces the pins evenly along the block edge. Note: Spread – Along Entire Edge honors the distance from the edge corner to the pin constraint by using the variable dbgPinAssignNrCornerMask. Assume that one edge of your design contains four pins (A1, A2, A3, and A4). You want to spread the pins evenly along the block edge. To do this you must 1. Sort the pins in the desired order (optional). May 2005 232 Product Version 4.1.5 Encounter User Guide Floorplanning the Design 2. Select Spread – Along Entire Edge. The following figure illustrates this situation: Original pin spacing A1 A2 A3 A4 New spacing, with pins spread evenly between the ends of the block edge A1 A2 A3 A4 Spacing Pins Evenly Using Explicit Starting and Ending Points For this method, you select a group of pins and sort them in the desired order. You do not specify a pin spacing distance because the Pin Editor calculates the appropriate distance, based on the specified starting and ending points, and spaces the pins evenly along the block edge. Assume that one edge of your design contains four pins (A1, A2, A3, and A4). You want to spread the pins evenly along the block edge between two sets of coordinates. To do this you must 1. Sort the pins in the desired order (optional). 2. Select Spread – Between Points. May 2005 233 Product Version 4.1.5 Encounter User Guide Floorplanning the Design 3. Revise the starting and ending coordinates as desired. The following figure illustrates this situation: Original pin spacing A1 New spacing, with pins spread evenly between the two sets of coordinates 85.0, 0.0 and 130.0, 0.0 May 2005 A2 A1 A2 85.0, 0.0 100.0, 0.0 A3 A3 234 115.0, 0.0 A4 A4 130.0, 0.0 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Running Relative Floorplanning This section describes how to use the Floorplan menu’s Relative Floorplan form to capture and define the placement relationship of floorplan objects independently from the actual coordinates in a floorplan. The Relative Floorplan program provides a more flexible way to place objects, such as modules, blocks, groups, blockages, and power domains. You can capture and define the placement relationship of floorplan objects independently from the actual coordinates in a floorplan. You can also resize a module or blackbox based on other floorplan objects. Before you can use the Relative Floorplan form, design must be loaded into the current Encounter session. After using the Relative Floorplan form in conjunction with the other Floorplan menu forms, you will have an initial floorplan for your design. Orientation Key The following is a key to the orientation of placed objects: Value Definition R0 No rotation MX Mirror through X axis MY Mirror through Y axis R180 Rotate counter-clockwise 180 degrees MX90 Mirror through X axis and rotate counter-clockwise 90 degrees R90 Rotate counter-clockwise 90 degrees R270 Rotate counter-clockwise 270 degrees MY90 Mirror through Y axis and rotate counter-clockwise 90 degrees May 2005 235 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Orientation terminology differs between tools. The following table maps the orientation terminology and definitions used in the Encounter software to that used in LEF and DEF files. LEF/DEF Encounter N (North) R0 S (South) R180 W (West) R90 E (East) R270 FN (Flipped North) MY FS (Flipped South) MX FW (Flipped West) MX90 FE (Flipped East) MY90 Instance Place Example The following figure shows an example of instance placement. May 2005 instB instA Place instA inside instB with Right relation and align to Bottom side by 0 micrometer. instB instA Place instA inside instB with Above relation and align to Left side by 0 micrometer. 236 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Use Undo to undo the previous relative floorplan action. Use Redo to redo the previous undo. Both support multiple levels of undo and redo. To save all the Relative Floorplan commands that were executed during a session, click Save. This saves a script that can be used later for updating or adjusting an existing floorplan based on the new blocks’ size and position. Command Examples The following examples illustrate the relative floorplanning options, including placing floorplan objects relative to quadrant center points. Relative Floorplan – Place Examples The following command places inst1 in the bottom-left (BL) quadrant, and 350 µm in both X and Y directions from the quadrant center point. The quadrant center point is at the upperright corner of the core boundary (1250 2020): relativeFPlan –-place inst1 BL 1250 2020 350 350 350 TL TR 350 BL North Orientation BR The following command places uvideo_s in the bottom-left (BL) quadrant, and 0 µm in both X and Y directions from the quadrant center point. The quadrant center point is at the upperleft corner of refInst: May 2005 237 Product Version 4.1.5 Encounter User Guide Floorplanning the Design relativeFPlan –-relativePlace uvideo_s BL refInst TL 0 0 TL 0 spacing in both x and y between blocks TR uvideo_s is a North Orientation refInst The following command places inst1 in the top-right (TR) quadrant, and 5 µm in both X and Y directions from the quadrant center point. The quadrant center point is at the bottom-left corner of HinstA: relativeFPlan –-updateMacro inst1 TR HinstA BL 5 5 TR HinstA TL inst1 BL BR Relative Floorplan – Reshape Examples The following command reshapes instA height to 20 µm with upper-left corner fixed: May 2005 238 Product Version 4.1.5 Encounter User Guide Floorplanning the Design relativeFPlan –-reshape instA TL Height 20 0 20µm instA The following command constrains the height of instA by the height of refInst plus 10 µm offset. instA is reshaped with lower-left corner fixed: relativeFPlan –-relativeReshape instA BL Height refInst 10 Before reshape After reshape 10 mm offset refInst instA The following command reshapes block1 with the width dimension value that leaves 5 µm channel width between block1 and refObj2. block1 is reshaped with upper left corner fixed: May 2005 239 Product Version 4.1.5 Encounter User Guide Floorplanning the Design relativeFPlan –-reshapeBetween block1 TL Width refObj1 refObj2 5 Before reshape refObj1 After reshape refObj2 block1 5 µm The following command reshapes block1 so that its new height is the same as the sum of refObj1 and refObj2 height, and the spacing between the two objects. block1 is reshaped with the bottom-left corner fixed: relativeFPlan –-reshapeCover block1 BL Height refObj1 refObj2 refObj2 block1 refObj1 Bottom-left is fixed Saving and Restoring Relative Floorplan The Encounter software automatically saves all the executed menu and text commands for the relative floorplanning actions in the encounter.cmd file. May 2005 240 Product Version 4.1.5 Encounter User Guide Floorplanning the Design To restore the relative floorplan information to the design display area, use the restoreRelativeFPlan text command. For more information, see “Floorplan Commands” in the Encounter Text Command Reference. May 2005 241 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Running Module Placement With the module placement feature, you can place modules, blocks (blackboxes and partitions), and hard macros at the top-level design to create an initial floorplan or improve an existing one. You should use module placement primarily for pure block-based designs where the current-level design is dominated by blocks, modules, or partitions, and has a very small number of standard cells (fewer than 10,000). Use Model 1. Import the design. 2. (Optional) Define an optimal fixed die/core size by reading in an existing DEF file or by using the modulePlace -fixedDie command. Note: This step is required only if you run block placement with a fixed core size. 3. (Optional) Set block constraints such as preplaced blocks, net weight, individual block aspect ratio, block halo, topology constraints, and group and region constraints, or specify a user-defined grid that snaps all module corners. 4. (Optional) Ungroup the logical hierarchy using the Hierachy Down toolbar widget or the u key. By default, module placement places all modules, blackboxes, or hard macros that belong to the same level hierarchy. If you want to place all modules, blackboxes, or hard macros flat, without taking the logical hierarchy into account, you must ungroup the logical hierarchy before running module placement. Note: Module placement also works at one hierarchy level if the Place hard macros inside modules option in the Place Blocks form is set. 5. Run block placement to place modules, blackboxes, or hard macros: ❑ Manually resolve hard macro overlaps if running automatic floorplan with the Place hard macros inside modules option. ❑ (Optional) Adjust the block placement results using the move and resize commands. ❑ (Optional) Change module guides to fences (you can also do this before block placement). ❑ (Optional) Set the placement status of the blocks to preplaced if you do not want Amoeba placement to move the blocks using the setBlockPlacementStatus command. Note: To refine the floorplan, you can also run modulePlace incrementally by adding May 2005 242 Product Version 4.1.5 Encounter User Guide Floorplanning the Design different constraints for each run. 6. Run Amoeba placement. 7. Continue with the normal Encounter flow. Best Practices The following five tips can help increase the chances of a good placement without manual intervention: ■ Increase the Effort level. Setting the effort to high (modulePlace -effort h) can significantly improve the quality of the placement results. ■ Increase the number of solutions. Running with 10 solutions (modulePlace -solutionCount 10), rather than the default (modulePlace, where the default number of placement solutions is 3) is often practical and gives far better results. ■ For hierarchical designs, first run modulePlace with many solutions, then fix the relevant modules and run modulePlace with the -placeBlocksInModule parameter. If necessary, apply aspect ratio constraints to modules to ensure they can accommodate the blocks inside them. ■ Run improve-only mode (modulePlace -noInitFP). Running improve can iteratively improve the design. ■ If the core utilization is high, decrease it by shrinking module guides at the current level (modulePlace -scaleModuleGuide pctScale). User-Defined Grid Block placement snaps the lower-left corners of blocks to the user-defined grid for module guides, regions, fences, and blackboxes. You can set the user-defined grid in the Preferences form’s Floorplan page. There are two ways to verify whether blocks or modules have been snapped correctly to the user-defined grid by the block placer: ■ Display the user-defined grid in the design display area and visually check if the blocks have been snapped to the correct grid. May 2005 243 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ View the module placement log information in the Encounter log file to check that the following lines have been correctly set: Info: Info: Info: Info: Info: Info: Info: Info: Info: Info: placement grid hard block / start = step = soft block start = step = resize soft block / blackbox step = (0.000, 0.000) um (20.000, 20.000) um (0.000, 0.000) um (20.000, 20.000) um (20.000, 20.000) um Net Weight Net weight can be used as one of the constraints to drive the module placer. You can specify the net weight with the specifyNetWeight command. The module placer interprets the specified net weight as follows: ■ If the specified net weight is less than 2, the net weight marked by the block placer is 0, which means it is ignored for connectivity weighting. ■ If the specified net weight is 2 or greater than 2, the module placer net weight is equal to the specified net weight minus 1. The default net weight is 1. The contribution made to a net length by a weighted net is equal to: module placer net weight x a net length x the square root of the total number of nets If a net has specified net weight of 0 or 1, the net makes no contribution to wire length in the module placement. The effect of the net weight is proportional to the weight. A net with a weight of 20 is twenty times more costly than a net with weight 1. Thus, it is treated as 20 times more important than a standard net. Instance Groups The module placer supports instance group guides and region constraints. You can define instance groups with the createInstGroup and addInstToInstGroup commands. For more information about group creation, see Grouping Instances on page 226. Note: Module placement does not place an instance group inside the core area. It only places hard blocks and blackboxes that belong to an instance group. If a module is assigned to an instance group, it is not placed because it is not a visible floorplan object. May 2005 244 Product Version 4.1.5 Encounter User Guide Floorplanning the Design The module placer places all instances that belonged to the same instance group close together. To get better results, you should run module placement in high effort mode with multiple generated solutions. For example: createInstGroup group –guide 0 0 1000 1000 addInstToInstGroup group inst_pll addinsttoinstgroup group inst_pll1 addinsttoinstgroup group inst_pll2 Run moduleplace As result, modulePlace places inst_pll, inst_pll1, and inst_pll2 close together in the design. Note: Module placement does not place instance groups inside the core area. Only instances that belonged to this group are placed. Module placement places all instances that belonged to the same instance group region in the area specified during region or fence creation. For example: createInstGroup groupA -region 0 0 1000 1000 addInstToInstGroup groupA inst_pll addInsttoinstGroup groupA inst_pll1 addInstToInstGroup groupA inst_pll2 createRegion groupA 20 20 1020 1020 Run modulePlace As a result, modulePlace places inst_pll, inst_pll1, and inst_pll2 (which belonged to the group groupA) into the area defined by the region that is located inside the core boundary at 20, 20, 1000, 1000. The module placer also supports group and region constraints that are specified in a DEF file. Blocks specified in a DEF group are placed close together. Blocks specified in a DEF region are placed in the core area specified by that region. Setting Instance-Based Block Halos You can set block halos for specific instance blocks (hard macros, blackboxes, and committed partitions). Block halo values are specified based on the current block orientation. For example, if the current block orientation is R0, and you assign a block halo value of 10 µm for the top edge, and 20 µm for the left, right and bottom, then take the same value for a block with an R180 orientation, the block halo value for the bottom edge will be10 µm, while the top, left and right will be 20 µm. Note: The halo values are defined by the instance boundary; however, if there is an overlap layer specified in the LEF or cdump block definition, the halo value will be defined from the overlapping layer. If a block has instance-based block halo information, the block placer uses this information instead of the global block halo value. May 2005 245 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Block halo information is saved with the floorplan file. Its values are stored as block properties and can be viewed in the Attribute Editor form. You can control the block halo display by selecting or deselecting Block Halo in the Color Preferences form. Module Placement Limitations and Workarounds The module placement feature has the following limitations: ■ Module placement does not take standard cell connectivity into account unless the standard cells are preplaced; therefore, module placement might not produce good block placement results if the current-level design has several standard cells or blocks that are directly connected to standard cells. You might want to group standard cells into “pseudo” modules and allow the block placer to place these modules. ■ The Place hard macros inside modules option might not generate good hard macro placement results. Hard macros might be overlapped or placed outside the module boundaries. You need to manually resolve the overlaps. Alternatively, first run modulePlace on the top level of the design (modulePlace), correct the top-level modules, then incrementally place hard macros inside the top-level modules (modulePlace -placeBlocksInModule). ■ With the Place hard macros inside modules option, for lower-level modules (nested inside the top-level modules) that contain hard macros as group constraints, all hard macros inside these modules are placed close together. The block placer ignores the lower-level modules that contain only standard cells. ■ The Fixed core size option might not produce good results if block placement does not start from a good initial fixed core size. The module placement algorithm works best when it has at least ten percent of free space at the top level (core utilization is less than or equal to 90 percent). When you initialize a floorplan, the specified utilization becomes the module utilization. For example, with a 70 percent core utilization, the Encounter software resizes the modules in the design in which 70 percent of the module’s area is occupied by the total cells and blocks area, and 30 percent of area is reserved for routing. Therefore, there is not much room left for the block placer to operate. To work around this, decrease the core utilization by shrinking module guides at the current level (modulePlace –scaleModuleGuide pctScale). ■ To achieve better results when using several topology constraints or group constraints, you must run block placement in a high effort level (modulePlace -effort h) with three or more generated solutions. May 2005 246 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ modulePlace cannot align two instances with the same master if the alignment requires reshaping (using setBlockOrderAlignment). To work around this, uniquify the netlist before running modulePlace. Command Examples This section provides supplemental information to some of the text command examples in the “Module Placement Commands” chapter of the Encounter Text Command Reference. setBlockDistance ■ The following command sets a maximum distance of 20 µm between block TDSP_INST and PLL_INST: setBlockDistance -maxDistance 20 TDSP_INST PLL_INST TDSP_INST PLL_INST Maximum distance 20 µm ■ The following command sets a minimum distance of 20 µm between block TDSP_INST and PLL_INST: setBlockDistance -minDistance 20 TDSP_INST PLL_INST TDSP_INST Distance 80 µm PLL_INST Minimum distance 20 µm May 2005 247 Product Version 4.1.5 Encounter User Guide Floorplanning the Design setBlockToBoundary ■ The following command sets the placement of the block PLL_INST at the top side of the chip with a maximum distance of 20 µm compared to the top boundary chip: setBlockToBoundary -side top -maxDistance 20 -block PLL_INST Maximum distance 20 PLL_INST Chip boundary ■ The following command sets the placement of block PLL_INST at the top side of the chip with a minimum distance of 20 µm compared to the top boundary chip: setBlockToBoundary -side top -minDistance 20 -block PLL_INST Minimum distance 20 Distance 250 µm PLL_INST Chip boundary May 2005 248 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ The following command sets the placement of block PLL_INST at the top left corner of the chip with a maximum distance of 20 µm: setBlockToBoundary -corner TL -maxDistance 20 -block PLL_INST Top left I/O corner pads Distance 15 PLL_INST Chip boundary ■ The following command sets the placement of block PLL_INST at the top left corner of the chip with a minimum distance of 20 µm: setBlockToBoundary -corner TL -minDistance 20 -block PLL_INST Top left I/O corner pads Distance 100 µm PLL_INST Chip boundary May 2005 249 Product Version 4.1.5 Encounter User Guide Floorplanning the Design setBlockOrderAlignment ■ The following command aligns the top edges of these two blocks, and places block PLL_INST on the right side of block TDSP_INST: setBlockOrderAlignment -alignment top -blocks TDSP_INST PLL_INST TDSP_INST ■ PLL_INST The following command places block PLL_INST on the left side of block TDSP_INST: setBlockOrderAlignment -order rightToLeft -blocks TDSP_INST PLL_INST PLL_INST ■ TDSP_INST The following command aligns the bottom edges of blocks TDSP_INST and PLL_INST, and places PLL_INST on the right side of TDSP_INST: setBlockOrderAlignment -order leftToRight -alignment bottom -blocks TDSP_INST PLL_INST TDSP_INST PLL_INST ■ The following command aligns the bottom edges of the blocks ALU_INST, TDSP_INST, and PLL_INST, and places these blocks from right to left, where TDSP_INST is on the left side of ALU_INST, and PLL_INST is on the left side of TDSP_INST: setBlockOrderAlignment -order rightToLeft -alignment bottom -blocks ALU_INST TDSP_INST PLL_INST PLL_INST May 2005 TDSP_INST ALU_INST 250 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ The following command aligns the top and bottom edges of blocks TDSP_INST and PLL_INST, and places PLL_INST on the right side of TDSP_INST. In this example, PLL_INST is a module that will be reshaped to meet the alignment constraint. setBlockOrderAlignment -order leftToRight -alignment topAndBottom -blocks TDSP_INST PLL_INST TDSP_INST ■ PLL_INST The following command aligns the top and bottom edges of blocks TDSP and PLL_INST, and places PLL_INST on the left side of TDSP. In this example, TDSP is a module: setBlockOrderAlignment -order rightToLeft -alignment topAndBottom -blocks TDSP PLL_INST PLL_INST ■ TDSP The following command aligns the right edges of blocks PLL and TDSP_INST, and places PLL at the bottom of TDSP_INST: setBlockOrderAlignment -order topToBottom -alignment right -blocks TDSP_INST PLL TDSP_INST PLL May 2005 251 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ The following command aligns the right edges of blocks PLL and TDSP_INST, and sets the order of PLL at the top of TDSP_INST: setBlockOrderAlignment -order bottomToTop -alignment right -blocks TDSP_INST PLL PLL TDSP_INST ■ The following command aligns the left edges of blocks TDSP_INST, PLL, and ALU_INST, and places these blocks from top to bottom, where PLL is at the bottom side of TDSP_INST, and ALU_INST is on the bottom side of PLL: setBlockOrderAlignment -order topToBottom -alignment left -blocks TDSP_INST PLL ALU_INST TDSP_INST PLL ALU_INST ■ The following command aligns the left and right edges of blocks TDSP_INST and PLL, and places PLL at the bottom of TDSP_INST. In this example, PLL is a module: setBlockOrderAlignment -order topToBottom -alignment leftAndRight -blocks TDSP_INST PLL TDSP_INST PLL May 2005 252 Product Version 4.1.5 Encounter User Guide Floorplanning the Design ■ The following command aligns the left and right edges of blocks TDSP_INST and PLL, and places PLL at the top of TDSP_INST. In this example, PLL is a module: setBlockOrderAlignment -order bottomToTop -alignment leftAndRight -blocks TDSP_INST PLL PLL TDSP_INST May 2005 253 Product Version 4.1.5 Encounter User Guide Floorplanning the Design Saving and Loading Floorplan Data You can save and load floorplan data at any time during a session. ➤ To save the floorplan information to a file, use the Save FPlan File form or the saveFPlan text command. ➤ To load the floorplan information from a file, use the Load FPlan File form or the loadFPlan text command. May 2005 254 Product Version 4.1.5 Encounter User Guide 9 Power Planning and Routing This chapter describes how to add power rings and power stripes, then connect blocks and cells to the power structures. This chapter discusses the following topics: ■ Overview on page 256 ■ Before You Begin on page 257 ■ Results on page 257 ■ Loading, Saving, and Updating Special Route on page 258 ■ Creating a Ring with User Defined Coordinates on page 258 ■ Global Net Connections on page 259 ■ Connecting Ring Pins on page 261 ■ Fixing LEF MINIMUMCUT Violations on page 261 ■ Fixing LEF Minimum Spacing Violations on page 261 ■ Adding Stripes to Power Domains on page 262 ■ Automatic Power Planning (APP) on page 264 ■ Creating a Template on page 264 ■ Instantiating a Template on page 266 ■ Creating Differential Routing to Signal Bumps on page 267 May 2005 255 Product Version 4.1.5 Encounter User Guide Power Planning and Routing Overview Power planning and routing is composed of the following components: ■ Adding a core ring ■ Adding block rings ■ Adding stripes to the core area ■ Adding stripes over blocks within the design ■ Adding ring pins ■ Creating a pad ring ■ Connecting pad pins ■ Routing standard cell pins ■ Connecting block pins ■ Connecting unconnected stripe ■ Routing to power bumps Use the Encounter power planning features to create power structures such as rings, stripes, and ring pins for the design. To create power structures, complete the following steps: 1. Load a LEF file that contains technology information before you add power rings and power stripes. If the LEF file is not loaded, you will not be able to select metal layers on the power planning forms. 2. Specify the floorplan. 3. Establish logical power connectivity. You can issue the globalNetConnect command or use the Global Net Connections form, which is accessed from the Floorplan menu. 4. Cut standard cell rows around macros. Whenever a floorplan change is made, the rows must be cut. Issue the cutCoreRow command to cut the rows based on placement blockages. ❑ To highlight the cut rows, issue the displayCutRow command. ❑ To remove the display of cut rows, issue the clearCutRow command. 5. Add power rings around the core of the design, and block rings around blocks, row clusters, and power domains. May 2005 256 Product Version 4.1.5 Encounter User Guide Power Planning and Routing 6. Add power stripes within the overall design, within a specific area, or over specified blocks or power domains. 7. Connect ring pins. 8. Save special route data. After your design is placed, you can use the Encounter power routing features to make the final power connections. The SRoute software creates pad rings and routes power and ground nets to the following power structures: ■ Block pins ■ Pad pins ■ Standard cell pins ■ Unconnected stripes Use the SRoute form to specify routing to any or all of these structures. In addition, you can specify whether or not the software should make the connections by changing layers or allowing jogs. Before You Begin Before you can begin power planning, the following conditions must be met: ■ The design must be loaded into the current Encounter session. The following input file is required: ■ The design file Before you can begin power routing, the following conditions must be met: ■ The design must have power rings and stripes. The following input file is required: ■ A LEF file that contains technology and macro information. Results After using the power planning software, your design has preliminary power structures that provide the foundation for hooking up each cell to a power source. May 2005 257 Product Version 4.1.5 Encounter User Guide Power Planning and Routing After using the power routing software, your design has power connections between pins of specified nets on the blocks and pads to nearby rings or stripes. Your design is ready for combined power and rail analysis to determine whether power structures and connections provide sufficient power to the design. Loading, Saving, and Updating Special Route To load special route data into a design, use the Load Special Route form. When loading the floorplan, the .fp and .fp.spr. files are included. The filename extension entered in the Load FPlan form is .fp, not .fp.spr. When creating special routes, use the Save Special Route form or the Save Design form to save the special route data plus vias. Floorplan files are saved with the following extensions: ■ .fp — Contains the general floorplan information. ■ .fp.spr — Contains the special route data. You can also use the Save DEF form to save special route information in the DEF file. Creating a Ring with User Defined Coordinates To create a block ring or a core ring in a specific location, complete the following steps: 1. Choose Floorplan – Power Planning – Add Rings. This opens the Basic page of the Add Rings form. 2. Specify the net names for power rings to be created. 3. Select User defined coordinates. 4. Select either Core ring or Block ring. If you select Core ring, the shape of the wires is ring. If you select Block ring, the shape of the wires is blockring. 5. Specify a set of coordinates. You must specify at least four pairs of coordinates. Specify the x coordinate followed by the y coordinate for each corner of the ring. Separate each coordinate with a space. May 2005 258 Product Version 4.1.5 Encounter User Guide Power Planning and Routing For example, to define a 100 x 100 square ring at the bottom left corner of the design, specify the coordinates as follows: 0 0 0 100 100 100 100 0 You can create a rectilinear ring by specifying an even number of coordinate pairs. For example, specify the following set of coordinates to create an L-shaped ring: 0 0 0 100 50 100 50 50 100 50 100 0 You must specify the coordinates in a linear sequence. For example, if you specify the coordinates in the following sequence, the ring is not created because the sequence of the coordinates defines the bottom left, top right, top left, and top right corners: 0 0 100 100 0 100 100 0 You must also specify coordinates that create perpendicular wires. For example, if you specify the following coordinates, the ring is not created because the coordinates define an edge that slants: 0 0 0 100 100 100 50 0 6. Click Apply or OK. The ring is created in the exact location specified by the coordinates. Global Net Connections Global net connections connect terminals and nets to the appropriate power and ground nets so that power planning, power routing, detail routing, and power analysis functions operate correctly for the entire design. Some of these terminals and nets are contained in the Verilog® netlist, and others are contained in the LEF file. From the Verilog netlist, you can connect the following type of nets to power and ground nets: ■ Power and ground nets Connect between the power and ground nets to the appropriate power and ground nets. These power and ground nets are wire keywords in the Verilog netlist. ■ Tie-hi and tie-lo nets Connect between the tie-hi and tie-lo nets to the appropriate power and ground nets. These are keywords in the Verilog netlist, such as 1’b0, 1’b1, supply0, and supply1. ■ Local nets Connect between the local nets to the global nets. These local nets are wire keywords in the Verilog netlist. May 2005 259 Product Version 4.1.5 Encounter User Guide Power Planning and Routing From the LEF file, you can connect the following type of terminals and nets to power and ground nets: ■ Power and ground terminals Connect between the power pins to the appropriate power and ground nets. vdd! and gnd! are examples of these power and ground pin and net names in the LEF file. ■ Filler cell nets Connect between the power pins to the appropriate power and ground nets. You can specify these connections before or after adding filler cells. To assign pins or nets to a global net, use the Global Net Connections form (Floorplan – Global Net Connections). For more information, see Global Net Connections in the “Floorplan Menu” chapter of the Encounter Menu Reference. Important The order of global net connections are important, especially when the Apply All or the Override prior connection options are selected in the Global Net Connections form. Apply All connects all pins or nets in the design to the specified global net. Override prior connection first disconnects pins and local nets that are already connected to a global net, then reconnects them to the specified global net specified in the form. You can also use the globalNetConnect text command to assign global net connections. For more information, see “Floorplan (Power Planning) Commands” in the Encounter Text Command Reference. May 2005 260 Product Version 4.1.5 Encounter User Guide Power Planning and Routing Connecting Ring Pins You can use either the Connect Ring Pins form or the SRoute form to connect ring pins to pad rings and to targets outside the block. The Connect Ring Pins form is primarily designed to route straight from ring pins to the first target outside the block (stripe/ring/design boundary) when the ring pin has many obstructions. Using Connect Ring Pins finishes stripe connections without the jogging that SRoute might add. Using the Connect Ring Pin form is the preferred method for routing from ring pins to the pad ring. SRoute can do this only if you use an extra configuration file. Using the Connect Ring Pin form is also the preferred method for routing from the pin of one block to pin of another block if there are no rows in between the blocks. SRoute can do this only if you use an extra configuration file. Fixing LEF MINIMUMCUT Violations If your design contains violations to the LEF MINIMUMCUT rule, use the fixMinCutVia command as a post-processing step. This command replaces power vias flagged by a violation marker because of a violation of the LEF MINIMUMCUT rule. The via is replaced with a via that contains the minimum number of cuts based on the LEF rule, and the violation marker is removed. If the via cannot be replaced, the violation marker is not removed. See the “Power Route Commands” in the Encounter Text Command Reference for more information. Fixing LEF Minimum Spacing Violations If your design contains violations of the LEF minimum spacing rule, use the fillNotch command as a post-processing step. The command fill gaps, which removes same net violations between generated vias and wires or pins where these violations are flagged by the Verify Geometry software. Using this command, you do not have to sacrifice via size by trimming vias in order to fix same net spacing violations. See “Verify Commands” in the Encounter Text Command Reference for more information. May 2005 261 Product Version 4.1.5 Encounter User Guide Power Planning and Routing Adding Stripes to Power Domains When you use the Each selected block/domain/fence option on the Basic page of the Add Stripes form, stripes are placed according to the location of the power domain ring. Sometimes the location of the power domain ring was not specified at the time the power domain was created. In this case, you must indicate the location of power domain rings to the power planning software by issuing the following command: modifyPowerDomainAttr -rsExts top bottom left right The top, bottom, left, and right values specify a distance from the edge of the power domain boundary. Rings between the power domain boundary and the specified distance are considered power domain rings. ■ Specify negative values if the power domain ring is inside the power domain boundary. The power planning software considers any ring from the power domain boundary to the specified distance inside the boundary to be a power domain ring. When you add stripes, the software trims the stripes at the ring. The stripe also correctly recognizes block rings within the power domain and breaks at those rings if you specify the Omit stripes inside block rings option on the Advanced page of the Add Stripes form. The following illustration shows how the stripe is created when you specify negative values. Stripe Power Domain Boundary Block Ring for Power Domain Block Ring ■ Specify positive values if the power domain ring is outside the power domain boundary. The power planning software considers any ring from the power domain boundary to the specified distance outside the boundary to be a power domain ring, and extends the stripes to that ring. The stripe also correctly recognizes block rings within the power domain and breaks at those rings if you specify the Omit stripes inside block rings May 2005 262 Product Version 4.1.5 Encounter User Guide Power Planning and Routing option on the Advanced page of the Add Stripes form. The following illustration shows how the stripe is created when you specify positive values. Stripe Power Domain Boundary Block Ring around Power Domain Block Ring If the location of the power domain ring is not specified, the stripe begins and ends at the power domain boundary. If the power domain ring is inside the power domain, the stripe recognizes it as a block ring. This can cause the stripe to break in the wrong locations if you specify the Omit stripes inside block rings option on the Advanced page of the Add Stripes form, and can create antennas, as shown in the following illustration. Stripe Power Domain Boundary Block Ring for Power Domain Block Ring Antennas May 2005 263 Product Version 4.1.5 Encounter User Guide Power Planning and Routing Automatic Power Planning (APP) With traditional power planning software, you must add core rings, pad rings, block rings, horizontal stripes, and vertical stripes separately. You could obtain this type of power plan by either issuing separate text commands or by filling out the Add Ring, Add Stripe, and SRoute forms multiple times. Using the APP software, you can create a power plan template that includes all of these features. The template can be applied to specific designs, providing a simpler method for creating a cohesive power plan. You can also use the same template when the floorplan is modified to easily regenerate power structures. Once you have created a template, you can instantiate it with design-specific information, such as the width and pitch of stripes. The Instantiation form also provides you with tools that help you determine the power needs of the design so that you can use these templates within a design to come close to a prototype power plan. To access the APP software, select one of the following forms from Floorplan – Power Planning submenu: ■ Edit Template Opens the Edit Power Plan Template form. ■ Synthesize Power Plan Opens the Template Power Planner form. Creating a Template The Edit Power Plan Template form allows you to set up a generic power plan for any design, as well as specific power plans for IP blocks within a particular design. Tip If you are using this form for the first time, you can click the Wizard On button at the bottom of the Edit Power Plan Template form. The Wizard displays a series of steps that take you through the recommended flow for creating a template. To create a template, complete the following steps. ➤ Choose Floorplan - Power Planning – Edit Template. This opens the Design page of the Edit Power Plan Template form. May 2005 264 Product Version 4.1.5 Encounter User Guide Power Planning and Routing Using the IP Block Page 1. Click the IP Block tab. This opens the IP Block page of the Edit Power Plan Template form. This page contains options that specify ring and stripe properties for each IP block. This page is divided into four quadrants: ❑ The upper-left quadrant contains a list of all IP blocks in the design. This list is obtained from the LEF file. ❑ The upper-right quadrant shows a preview of how the selected block or blocks will look in the design. ❑ The lower-right quadrant contains a list of IP Library templates, and allows you to create, load, save, or delete templates. ❑ The lower-left quadrant contains options for specifying rings around blocks and stripes over blocks. It also contains buttons that let you set or unset the options for the blocks selected in the upper right quadrant. This quadrant has two subtabs: ❍ Use the Block Ring tab to specify whether a block ring is required for a particular IP block whether a block ring is to be created, and if so, whether the block ring can be shared by other blocks. ❍ Use the Stripe tab to specify whether stripes should be created over a particular block, and if so, which layer, width, and pitch values are to be used. 2. Select one or more IP blocks from the list in the upper left quadrant. 3. Click the Block Ring tab in the lower left quadrant, then specify block ring options for the selected IP blocks. 4. (Optional) Click the Stripes tab in the lower left quadrant, then select Stripe over the block. 5. Select the R0 option, then specify stripe configuration options for the selected IP blocks when they are not rotated from their original positions. 6. Select the R90 option, then specify stripe configuration options for the selected IP blocks when they are rotated 90 degrees from their original positions. 7. When the display in the upper right quadrant looks correct, click the Set button. 8. Repeat steps 3-7 for additional IP blocks. May 2005 265 Product Version 4.1.5 Encounter User Guide Power Planning and Routing 9. When all blocks that require block rings or stripes have been set, specify a name in the IP Template Library Name field in the lower right quadrant, then click Save. Using the Design Page 1. Click the Design tab. This returns you to the Design page of the Edit Power Plan Template form. This page contains ring and stripe configuration options for the core area of the design. This page is divided into four quadrants: ❑ The upper left quadrant displays the name(s) of regions and IP blocks in the design. ❑ The upper right quadrant shows a preview of how the rings and stripes will be created in the actual design. ❑ The lower right quadrant contains an list representing each template available for instantiation into the design, and also allows you to create, load, save, or delete templates. This quadrant also contains a button to instantiate existing templates into the design. ❑ The lower left quadrant allows you to define ring and stripe characteristics for a region in the design, and allows you to add or modify regions in the design. 2. Select region names in the upper left quadrant and observe the display in the upper right quadrant. 3. When the display in the upper right quadrant looks correct, select the IP Library Template from the dropdown menu in the lower left quadrant of the form. 4. Specify a name in the Design Template Library Name field in the lower right quadrant of the form, then click Save. The new template is displayed in the list in the lower right quadrant of the form. Instantiating a Template Click the Instantiation button on the Design page of the Edit Power Plan Template form to display the Template Instantiation form, which allows you to add specific information for the chip-level power structures, such as the width, offset, and stripe count or pitch for each layer. The configuration of the top portion of this form depends on which power structures you selected in the Design tab. The bottom half of the form is always the same. The top and bottom halves of the form each have two separate tabs that can be used independently. The Design Template tab in the top half of the form contains a set of default values based on May 2005 266 Product Version 4.1.5 Encounter User Guide Power Planning and Routing physical data. You can update these values manually or click the Update Template Configuration button to update them. The bottom half of the form contains options for using power analysis data to provide better estimates for the width, offset, and count/pitch values in the top portion of the form. The Performance tab and EM Limits tab are also available on this form and can be selected independently. The Design and Template windows of this form allow you to display power structures for the design and to associate Region Library templates with power structures. Click Ok or Apply to create power structures within the design that have the topology (rings and stripes) specified in the template and the geometry (width, spacing, and pitch) specified in the Instantiation form. Creating Differential Routing to Signal Bumps Differential routing creates wires of the same length or configuration between a set of sources and targets. Use the Route Flip Chip Signal form to specify differential routing parameters. You can create a constraint file to specify differential pair definitions, as well as shield net definitions and differential group definitions. The following example shows how to set up a constraint file: ###### Differential pair definition ###balanced routing with shielding out[10] PAIR out[11] SHIELDNET VDD ###balanced routing without shielding out[8] PAIR out[9] ###### Shield net defintition out[5] SHIELDNET VDD out[3] SHIELDNET VSS ###### Differential group definition out[15] GROUP out[16] out[17] out[18] resetn clk GROUP out[12] out[13] May 2005 267 Product Version 4.1.5 Encounter User Guide Power Planning and Routing May 2005 268 Product Version 4.1.5 Encounter User Guide 10 Multiple Supply Voltages This chapter describes how to use the power domain feature to create designs using multiple supply voltages. This chapter discusses the following topics: ■ Overview on page 270 ■ Before You Begin on page 270 ■ Results on page 270 ■ Use Model for MSV on page 270 ■ Inserting Voltage Level Shifters on page 282 ■ Creating a Rectilinear Power Domain on page 283 May 2005 269 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages Overview The Encounter™ software provides a solution for using multiple supply voltages (MSV) in a single design by using power domains. A power domain is a collection of floorplan objects (such as cells, soft blocks, and hard blocks) that share the same power supplies. In floorplanning, a power domain boundary is treated as a fence that contains only the objects that reside within the power domain. Floorplan objects that are not included in a power domain are explicitly excluded, and are not placed within the boundary of a power domain. Tools That Do Not Support MSV The following Encounter tools do not support power domains: ■ PKS ■ CTS ■ Automatic Floorplan (Block Placer) ■ Channel Estimation Before You Begin You must import the design before you create power domains. Results After creating power domains, all cells, macros, and modules in the design are assigned to a power domain. After verifying power domains, error and warning messages for the options you select on the Verify Power Domain form are written to the Encounter console. In addition, error messages are issued if any power domains overlap. Use Model for MSV One method for reducing the total power consumption of the design is to segregate the power supply for specific components. This segregation into power domains provides a means to shut off power to components that do not need continuous power, while ensuring a steady May 2005 270 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages power supply to critical components. With power domains, you can also operate at lower voltages during times when clock frequency can be decreased. Shutting down or reducing voltage to non-critical components reduces both leakage power and switching power, resulting in a more efficient use of the power supply. The following illustration shows how the power domains might be distributed in a design. The following use model indicates changes that apply to designs that have multiple supply voltages: 1. Prepare separate timing libraries for each power domain you plan to create, then import them using the Design Import form. For example, select fast_1_0.lib and fast_0_8.lib in the Min Timing Libraries field and slow_1_0.lib and slow_0_8.lib in the MaxTiming Libraries field of the Design Import form. 2. Import the design (no changes for MSV). May 2005 271 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages 3. Create power domains and assign modules, pads, and shifters to them. ❑ The following example shows how to add a module to a power domain: modifyPowerDomainMember PD2 -instances DTMF_ INST/ RESULTS_ CONV_ INST -power (VDD2: VDD) -ground (VSS2: VSS) ❑ The following example shows how to add IO to a power domain: modifyPowerDomainMember PD2 -instance {IOPADS_ INST/ Pvdd1} -power (VDD2: VDD) - move modifyPowerDomainMember PD2 -instance {IOPADS_ INST/ Pvss1} -ground (VSS2: VSS) - move ❑ The following example shows how to add voltage level shifters to a power domain: modifyPowerDomainMember PD2 -instances TRANSV1V2 -power {( VDD2: VDD1) (VDD3: VDD2)} -ground (VSS: GND) May 2005 272 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages Note: power {( VDD2: VDD1) (VDD3: VDD2)} -ground (VSS2: GND) meansthat the VDD2 net is connected to the VDD1 pin. The VDD3 net is connected to the VDD2 pin for power. Ground pin - GND is connected to the VSS net. After importing the netlist, you can ungroup module instances to the level where the modules to be assigned to power domains are visible. You assign one or more modules to a power domain by specifying the module names, the power pins, the ground pins, the power net, the ground net, and the timing libraries. Note: CTS requires that the logical hierarchy matches the physical hierarchy, since it cannot understand an instance group of cells from different logical hierarchies. For each power domain, the software creates a rectangular fence, connects the power and ground pins of the cells inside the module(s) to the power and ground nets, and binds the cells to the timing libraries. May 2005 273 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages All of the remaining modules that are not yet assigned to a particular power domain must be assigned to a power domain before you can proceed to the next step. You can do this using the Set For Special Power Domain option on the Create Power Domain form. For more information, see the Encounter Menu Reference. 4. Floorplan the design. ❑ Place I/Os. ❑ Move (manually) the power domains into the core area. ❑ Optionally, change the shape of a power domain to a rectilinear shape by adding power domain cuts. The Cut Rectilinear icon allows you to interactively create power domain cuts that define rectilinear power domains. The power domain cuts May 2005 274 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages mask out portions of the power domain to enable you to see the shape of the power domain. The equivalent text command is createPowerDomainCut. May 2005 275 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages ❑ Optionally, preplace hard macros. ❑ Save the floorplan file (.fp). This file has been enhanced to save and restore power domain information. May 2005 276 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages 5. Create core rings (no changes for MSV). 6. Create block rings for power domains and hard macros. Use the Selected power domain/fences option on the Basic tab of the Add Rings form to create a ring around a selected power domain boundary. For more information, see “Floorplan Menu” in the Encounter Menu Reference. May 2005 277 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages The equivalent option for the addRing text command is -around power_domain. Note: If the specified power and ground nets for the ring do not match the power domain power and ground nets, a warning message displays. 7. Create block rings for hard macros (no changes for MSV). 8. Create stripes for a selected power domain or for all power domains: ❑ Select a power domain, then use the Selected power domain/fence option on the Basic tab of the Add Stripes form to create power stripes for a selected power domain. The equivalent text command is addStripe with the parameter -over_power_domain 1. May 2005 278 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages ❑ Use the All domains option on the Basic tab of the Add Stripes form to create power stripes for all power domains. The equivalent text command is addStripe with the parameter -all_domains 1. Note: To create a mesh, you must issue the addStripe command twice: once for vertical stripes and once for horizontal stripes. Note: If the power and ground nets for the stripes do not match the power domain power and ground nets, a warning message displays. 9. Create stripes to connect power domain rings with core rings. May 2005 279 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages 10. Route pad pins (no changes for MSV). 11. (Optional) Route block pins if your design uses block pins (no changes for MSV). 12. Identify the voltage level shifters. Use the loadShifter command to identify voltage level shifters. The file you create must have the following syntax: cellname inputVoltage outputVoltage Note: If the shifters do not exist in the Verilog file, you must issue the addShifterForNetXPowerDomain command before proceeding to the next step. For more information, see “Inserting Voltage Level Shifters” on page 282. May 2005 280 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages 13. Use amoebaplace to place standard cells and hard macros that have not already been placed. All standard cells and hard macros are placed within the boundary of the power domain to which they are assigned. In addition, voltage level shifters are placed around the power domain boundary. Macros that belong to a power domain are placed inside the power domain boundary, if possible. If macros do not fit inside the power domain, you must resize or reshape the power domain. Voltage level shifters are placed along the inside edge of the power domain boundary, on the row ends. For top and bottom rows, multiple shifter cells are placed at row ends, if needed. Note: You must already have associated each level shifter with a power domain during step 3. 14. Route standard cell pins and voltage level shifter pins. The power routing software has been enhanced so that standard cell rows are automatically cut for power domains. ❑ If you select the Standard cell pins option on the Basic tab of the SRoute form, SRoute connects power and ground nets from end to end, terminating at the power rings. Standard cell pins automatically recognize voltage level shifters and connect the standard cells to the correct power nets. For more information, see Sroute – Basic in the “Route Menu” chapter of the Encounter Menu Reference. ❑ If you select the Level shifter pins option, SRoute connects voltage level shifter pins to the closest segment of the ring around the power domain. 15. Add clock trees Use the following command to set the default routing attributes that CTS uses: setCTSMode -fence -MSMV 16. Run Trial Route or NanoRoute (no changes for MSV). 17. Extract RC (no changes for MSV). 18. Analyze timing. Each power domain has a set of associated timing libraries. Instance cells that belong to different power domains are bound to a corresponding timing library. This allows you to perform timing analysis with no further changes for MSV. May 2005 281 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages 19. Perform timing optimization. Inserted cells are assigned to the appropriate power domain, and power and ground pins are connected to the correct power and ground nets. 20. Add spare cells (no changes for MSV). 21. Add filler cells. The addFiller command has been enhanced to do the correct supply connectivity and fill-area determination for filler cells being added to MSV designs. However, filler cells must be added to each power domain separately using the new -powerDomain option, specifying the name of the power domain as the argument. For MSV designs, if no power domain name is provided, the addFiller command fills only the core area that is not part of any power domain. 22. Perform power analysis. Power analysis software recognizes power domains and calculates power values accordingly. To perform power analysis for a design with MSV, you must use the Edit Pad Location form to create a power pad location file for each net. For more information, see Edit Pad Location in the “Power Menu” chapter of the Encounter Menu Reference. The power analysis software can use an instance power file to calculate instance IR drop instead of a global net voltage. You can specify that power analysis reports be organized by net. If you specify a report name, the report for all nets is placed in that one file. If you do not specify a report name, a separate file contains each report. For example, if the net names are VDD1 and VDD2, the report names are VDD1.report and VDD2. report. For more information about how power analysis supports MSV, see “Running Power Analysis with Encounter” on page 639. The remaining stages of the design process are unchanged for MSV. Inserting Voltage Level Shifters To insert voltage level shifters for signals that go from one power domain to another, complete the following steps. 1. Type the loadShifter command. This identifies the voltage level shifters to be added. Make sure that you specify a file that contains the following syntax: May 2005 282 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages cell_name input_voltage output_voltage 2. Type the addShifterForNetXPowerDomain command. Note: You only need to perform this step if the level shifters are not already in the netlist. During the process of inserting level shifters, the software performs the following actions: ■ Identifies all the interface signals (and their direction) between power domains. ■ For each signal that goes from a power domain with input_voltage (driving domain) to another power domain with output_voltage (receiving domain) that is defined in the shifter_file_name above, the corresponding cell_name is inserted in the driving power domain. Voltage level shifters are not inserted for interface signals that go between power domains whose voltages are not defined in the shifter_file_name. ■ Updates the connectivity in the database to include instances of inserted shifters. For example: For signal A, a voltage level shifter named SHIFTER_X is inserted in PD1.5v. No voltage level shifter is inserted for signal B since 3.5v to 3v is not defined in the shifter_file_name. Creating a Rectilinear Power Domain Power domains are rectangular when they are first created. To update a power domain so that its shape is rectilinear, complete the following steps: May 2005 283 Product Version 4.1.5 Encounter User Guide Multiple Supply Voltages 1. Select the power domain. 2. Click the Move/Resize/Reshape icon from the Tool Widgets area. 3. Move the cursor to the edge of the power domain that is to be reshaped. The cursor changes to a new shape, indicating readiness for the reshape action. 4. Click and release the mouse button, then drag the cursor over the area in which you want to expand or contract the power domain. A ghost image of the reshaped power domain displays as you move the cursor. When you click the mouse button a second time, the power domain has the rectilinear shape indicated. Any areas that are no longer contained within the power domain are now available for other power domains. May 2005 284 Product Version 4.1.5 Encounter User Guide 11 Placing the Design This chapter describes how to use the Place menu forms to place standard cells and blocks to create a placement that is routable and meets the performance constraints. This chapter presents the following topics: ■ Overview on page 286 ■ Area I/O Placement on page 288 ■ Specifying Spare Cells on page 289 ■ Specifying Cell Padding on page 290 ■ Setting Placement Blockage on page 291 ■ Running JTAG Placement on page 292 ■ Running Amoeba Placement on page 293 ■ Running ECO Placement on page 294 ■ Running Window Placement on page 295 ■ Scan Cell Functionality on page 296 ■ Reordering Scan Chains on page 296 ■ Adding Filler Cells on page 308 ■ Adding Logical Tie-Off Cells on page 311 ■ Timing-Driven Placement on page 312 ■ Netlist Clustering Mode on page 313 ■ Post-Placement Congestion Optimization on page 314 ■ Saving and Loading Placement Data on page 314 May 2005 285 Product Version 4.1.5 Encounter User Guide Placing the Design Overview After importing the design and floorplanning, you can run Amoeba placement to place the standard cells and blocks that were not pre-placed during the floorplanning session. Amoeba placement considers the modules that were placed (guided) during floorplanning, and takes into account the design’s hierarchy and connectivity. May 2005 286 Product Version 4.1.5 Encounter User Guide Placing the Design General Placement Sequence The following steps detail the most common steps for placing a design: 1. Import the design. 2. Study the design’s connectivity. 3. Do the minimum amount of floorplanning based on the chip design floorplan, or do no floorplanning at all. 4. (Optional) Do the power planning. Note: Be sure to allow sufficient space between cells and power rails. Otherwise, the placement might create a short when the design is routed using NanoRoute. 5. (Optional) Specify spare cells and scan cells, if necessary. 6. (Optional) Create placement blockages, if necessary. 7. (Optional) Load the scan chain information. 8. Run Amoeba Placement. 9. (Optional) Reorder the scan chain(s). 10. Run Trial Route to view placement and routing congestion. May 2005 287 Product Version 4.1.5 Encounter User Guide Placing the Design Area I/O Placement To perform area I/O placement in a design, complete the following steps: 1. Import your area I/O library. a. Choose Design – Design Import, then select the Design tab. b. Enter the LEF filename that contains the area I/O cell in the LEF Files field. c. Click OK. 2. Load your floorplan file and I/O assignment file. You can load the floorplan and I/O assignment files separately, or include the I/O assignment file in the floorplan file. ❑ To load the files separately, use the Load FPlan File (Design – Load – Floorplan) and Load IO File (Design – Load – IO File) forms. ❑ To include the I/O assignment file in the floorplan file, add the following statement to your floorplan file before loading your floorplan. IOFile: iofile_name Note: You can also specify area I/O rows in DEF or PDEF files, or use the addAIORow text command to create area I/O rows. 3. Save your floorplan and I/O assignment files. 4. Place the area I/O cells. 5. You can use the placeAIO text command, or the Place Area I/O form (Place – Place Area I/O). There are different procedures for handling I/O pads inside the core design area. If the I/O pads are inside the core area, the physical library for these I/O pad cells should be located in the Blocks Cell Libraries file or directory entry, and not the I/O Cell Libraries entry in the Design Import form. Blocks cell libraries are the translated physical library cells of the I/O pads in LEF or cdump format. When you preplace the I/O pad instances in the core design area, they become preplaced blocks. These block locations are fixed; the placement program will not move them. I/O pad instances in the I/O assignment file require no entries. For more information about the rule-based I/O assignment file, see Generating the I/O Assignment File on page 42. May 2005 288 Product Version 4.1.5 Encounter User Guide Placing the Design Specifying Spare Cells If spare cell instances are included in the gate-level netlist, you have the option to specify them during the floorplanning session and before running the Placement program. Placement Constraints The more specific an area where the spare cells are contained, the more specific the placement area constraints are defined. The following options determine the placement constraint area: ■ If spare cells are included in a design that has not been floorplanned, the Placement program determines that the design core box is the placement constraint area. ■ If spare cells are contained in floorplanned modules or submodules, the general area of modules or submodules will be the placement constraint area. ■ If spare cells are contained in fences or a regions, the area of the fences or regions determines the bounding box of the placement constraint area. Distribution Depending on how the spare cells are connected, there are three ways they will be distributed: ■ If spare cells are floating (with no connection), or are connected to power or ground, they are evenly distributed in the placement constraint area. ■ If the spare cells have connections to other spare cells, they are treated as a spare cell group and are placed close to one another in the placement constraint area. ■ If the spare cells, or a group of spare cells, have a connection to a non-spare cell instance, they are placed close to that instance. Note: Connections can be disregarded using the Ignore Spare Cell Connection option in the Place form, or amoebaPlace -ignoreSpare command, so that the spare cells will be evenly distributed in the placement constraint area. May 2005 289 Product Version 4.1.5 Encounter User Guide Placing the Design Specifying Cell Padding Specify cell padding to reserve placement space for inserting clock buffers when running Clock Tree Synthesis (CTS) on a highly localized clock. The placement clearance is on the right side of the placed instance at a default metal2 pitch dimension. Tip Use cell padding with a design that has its clock concentrated in a very tight area. Most clock designs are spread uniformly over a large area. Run CTS and set the placement utilization at 5-7 percent less than the targeted final utilization. May 2005 290 Product Version 4.1.5 Encounter User Guide Placing the Design Setting Placement Blockage Amoeba placement treats preroutes exactly the same as routing blockages. It places every instance at a legal location where there should never be any DRC violations against preroutes or routing blockages. Normally, you would use preroutes for special nets that are floorplanned (pre-designed) before placement, such as power, ground, and clock mesh nets, where you do not want any standard cells placed underneath. Instances placed next to power and ground stripes honor the design spacing rule. Instances placed next to routing blockage objects are set adjoined. When you deselect the metal layers, you can place instances under the stripes and routing blockage objects. By default, the Encounter software blocks the placement of standard cells on metal2 for a three-metal layer process. For a four-metal layer process or greater, the software blocks metal2 and metal3. Placement Blockage Types When querying a placement blockage, you can select from three blockage types from the Attribute Editor: Full The area cannot be used to place blocks at any time during the session. Soft The area cannot be used to place blocks during Amoeba placement, but can be used during in-place optimization, clock tree synthesis, or ECO Placement. Partial A specified percentage of the area that is unavailable for placement. For example, a partial blockage of 70 percent means that only up to 30 percent of placement density is allowed in the area. May 2005 291 Product Version 4.1.5 Encounter User Guide Placing the Design Running JTAG Placement The JTAG groups in the design can be placed close to the outer core area by first specifying the JTAG cells, then running the JTAG placement, which outputs a placement file in DEF or TDF format containing the placement information for the JTAG instances. You can then run Amoeba placement in the remaining design. Tip If you do not want to place any regular instances in the JTAG outer core area after running JTAG placement, you must specify a placement blockage prior to running Amoeba placement. May 2005 292 Product Version 4.1.5 Encounter User Guide Placing the Design Running Amoeba Placement Amoeba placement is unified with floorplanning and takes advantage of the design’s hierarchy, which leads to physical locality and implicit timing control. These control the optimizing of wire length, timing performance, chip die size, and routability. When running Amoeba placement during the prototype phase, the completeness and accuracy of the timing constraint file is important, but not necessary. As the design work progresses toward timing closure, the timing constraint file must be complete and accurate, and Amoeba placement should be run with the timing driven option (amoebaPlace timingdriven). Note: Amoeba placement supports partition cuts in modules by treating them as placement blockages for partitions. It places instances only within the rectilinear area. The Amoeba view is a unique way of representing and displaying the layout. It is a flexibly contoured envelope enclosing all sub modules as a cluster. The clusters are used hierarchically from top to bottom, matching the logical hierarchy. To display the Amoeba view, select the Amoeba view widget from the Views panel at the middle-left side of the design display area. May 2005 293 Product Version 4.1.5 Encounter User Guide Placing the Design Running ECO Placement ECO placement updates the placement from a prior Encounter session to reflect the netlist changes, merging the new netlist changes into the prior netlist’s placement. The modified netlist can then be imported into an Encounter session so that the result is a new placement that reflects the changes made in the modified netlist. You can run either an incremental timing or logic change to the design. You can run ECO after running placement, although ECO is usually run after analyzing speed or RC data. To update the placement with the ECO netlist, complete the following steps: 1. Save the pre-ECO netlist placement data. 2. Start a new Encounter session. Alternatively, you can use the freeDesign command. 3. Import the (ECO) design. 4. Load the floorplan. 5. Run ECO Placement. This references the pre-ECO netlist placement data. The changes reflected in the new netlist are ECO’d into the pre-ECO placement. All designs are placed in the resulting placement. After running ECO successfully, you can run Trial Route to view the routing congestion and analyze the design for timing. May 2005 294 Product Version 4.1.5 Encounter User Guide Placing the Design Running Window Placement After running Amoeba placement, if your design contains areas of severe congestion, you can specify a window around the congestion and perform Amoeba placement on the area to improve routability, as shown in the following figure. User-specified window around congestion area Alternatively, you can specify a window by typing values for the lower left (llx) and upper right (urx) boundaries in the x-direction, and the lower left (lly) and upper right (ury) boundaries in the y-direction, as shown in the following figure. urx, ury window around congestion area llx, lly Window placement works best when the congestion is primarily horizontal or vertical, in which case the placer only needs to spread out in one direction. Placement and routing files are saved prior to each window placement so that the original placement can be restored, in case there is no improvement after window placement. May 2005 295 Product Version 4.1.5 Encounter User Guide Placing the Design Scan Cell Functionality Scan cells are usually identified and read automatically from the timing library during design import. You can also use the specifyScanCell text command to define scan cells that are not listed in the timing library. You can specify scan chains (scan groups) in a design by defining them in a DEF or TDF file, or by using the specifyScanChain text command. However, if you define scan chains in a DEF or TDF file, native scanTrace mode is disabled, and the Encounter software runs in scanDEF mode. In this mode, the software issues the following message if you try to run the scanTrace command: scanTrace not supported in DEF-In mode. Reordering Scan Chains If you do not need to retain the scan chain order in your design, you can change the order of how the scan flip-flops are connected along the scan chain for any or all scan groups. This eases connection constraints on the scan cells, but does not constrain the placement of the scan cells. To facilitate reordering of the scan nets, uniquify the incoming netlist, and make sure that it does not contain Verilog assignment statements involving scan nets. A scan net is a net that resides along the scan data path—that is, a net that connects the scan flip-flops in a scan chain. If the netlist is uniquified, but it contains Verilog assignment statements involving scan nets, you can use the following commands to insert a temporary buffer into the netlist to enable reordering of these nets: setDoAssign on [-buffer bufferName] Then load the design in the Encounter software with the loadConfig command. When the Encounter software reads the netlist, it outputs the following messages: Reading netlist ... Reading verilog netlist ".fileName" Inserting temporary buffers to remove assignment statements. If buffers were added using the setDoAssign on -buffer option, these buffers will remain in the final netlist and replace the Verilog assignment statements. Note: If the netlist was generated using BuildGates Synthesis or Cadence PKS, you can remove the assignment statements prior to saving the netlist by running the following command: May 2005 296 Product Version 4.1.5 Encounter User Guide Placing the Design do_xform_fix_multiport_nets There are two approaches to performing scan chain reordering in the Encounter software: native and scanDEF-based reordering. Use the native approach to reorder the following: ■ A single-clock domain, single-edge chains ■ Multiple clock domain chain segments separated by data lockup elements ■ Shared functional output signal chains Use the scanDEF approach to reorder the following: ■ All simple scan chain architectures (handled by the native approach) ■ Implied domain transition scan chains (without data lockup elements) ■ Scan chains with ordered segments ■ Scan chains generated by LogicVision software Tip After the scan groups are reordered, save a netlist of the design using the Save Netlist form (Design – Save – Netlist), or using the saveNetlist command. Native Scan Reordering Approach Use the native approach to scan chain reordering when you do not have a scanDEF file. This approach requires that you use the specifyScanChain command to identify the START and STOP signals of the top-level chains, or chain segments, in the netlist. Using this information, the software identifies the scan flip-flops along the scan chain when running the scanTrace command to analyze the scan flip-flop connections. You can also auto-detect data lockup latch elements using the scanTrace -lockup command. If the scan cells are not listed in the timing library, you must specify them before tracing the scan chains. You can identify scan cells with the specifyScanCell command. After scanTrace has identified the elements along the chain, do the following: 1. Run the Amoeba placement program and (optionally) ignore the scan connections while placing the scan groups: amoebaPlace [–ignoreScan] 2. Reorder the scan chains: May 2005 297 Product Version 4.1.5 Encounter User Guide Placing the Design scanReorder [-noSkip | -skipBuffer | -skipTwoPinCell] The recommended flow for scan chains that have data lockup latches is as follows: 1. Specify a scan chain in the design: specifyScanChain 2. Trace the scan chain connection with the automatic detection lockup latch elements: scanTrace -lockup [-verbose] 3. Run the Amoeba placement program and (optionally) ignore the scan connections while placing the scan groups: amoebaPlace [-ignoreScan] 4. Reorder the scan chains: scanReorder [-noSkip | -skipBuffer | -skipTwoPinCell] The recommended flow for scan chains that have data lockup flip-flops is as follows 1. Specify a scan chain in the design: specifyScanChain ... 2. Specify a cell or instance as a lockup flip-flop element: specifyLockupElement ... 3. Trace the scan chain connection: scanTrace [-verbose] 4. Run the Amoeba placement program and (optionally) ignore the scan connections while placing the scan groups: amoebaPlace [-ignoreScan] 5. Reorder the scan chains: scanReorder [-noSkip | -skipBuffer | -skipTwoPinCell] Note: The scanReorder command automatically calls scanTrace internally if you have not previously run scanTrace. By default, this internal scanTrace run specifies that the tracing will not detect lockup elements (-noLockup); therefore, if you have lockup latches, Cadence recommends using the scanTrace -lockup command before scanReorder, or specifyLockupElement prior to running scanReorder. Valid design types. The native approach to scan chain reordering can be used on designs comprising a simple scan chain architecture with the following characteristics: ■ Single-clock domain, single-edge chains May 2005 298 Product Version 4.1.5 Encounter User Guide Placing the Design In the following figure, all foo_reg scan flip-flops are triggered by the same clock domain and phase. SI SI Q SI foo_reg_1 SI Q foo_reg_2 SO Q foo_reg_3 clk foo_reg_1, foo_reg_2, and foo_reg_2 scan flip-flops are triggered by clk1 (positive edge). ❑ specifyScanChain chain1 -start SI -stop SO scanTrace [-verbose] ■ Multiple clock domain chain segments separated by data lockup elements In the following figure, all domain or edge transitions are separated by a data lockup element. SI SI Q SI D Q Q SI Q SI Q SO EN foo_reg_1 LU foo_reg_2 foo_reg_3 foo_reg_4 clk1 clk2 ❑ foo_reg_1 and foo_reg_2 scan flip-flops are triggered by clk1 (positive edge). ❑ foo_reg_3 and foo_reg_4 scan flip-flops are triggered by clk2 (positive edge). ❑ LU represents a data lockup element of type latch. specifyScanChain chain1 -start SI –stop SO scanTrace -lockup [-verbose] All elements along the scan chain are assumed reorderable from the specified START and STOP signals unless there is a data lockup element in the scan data path. The presence of a data lockup element works as a boundary so that the chain segments on either side of the lockup element are individually reordered. For this example, the toplevel chain is reordered as two individual scan chain segments: ❑ reorderable segment 1: SI > LU/D ❑ reorderable segment 2: LU/Q > SO May 2005 299 Product Version 4.1.5 Encounter User Guide Placing the Design ■ Shared functional output signal chains If the STOP signal of the scan chain is also a shared functional output, the endpoint of the scan chain must be specified to the scan input (SI) pin of the last register in the scan chain, or to the data input pin of the multiplexer (MUX), which drives the shared functional output signal. This is necessary because scanTrace does not perform the forward trace from the last flip-flop in the scan chain through the MUX instance. The following figure is an example of shared functional output: B in[0] SI Q SI Q D SI Q Q EN clk1 foo_reg_1 foo_reg_2 foo_reg_3 LU SI Q Scan data connection Functional connection foo_reg_4 1 out[0] 0 A shift_enable clk2 The following command sequence performs the forward trace from the last flip-flop in the scan chain to the MUX instance: specifyScanChain chain1 -start in[0] -stop MUX/B scanTrace -lockup [-verbose] The following command sequence does not perform the forward trace from the last flipflop through the MUX instance; scanTrace will not succeed: specifyScanChain chain1 -start in[0] –stop out[0] scanTrace -lockup [-verbose] Scan chains with two-pin logic cells. Scan chains often contain two-pin logic cells, usually buffers. The scan tracing algorithm always recognizes and traces through two-pin cells. The scanReorder command parameters control whether two-pin cells remain in the scan chain after scan reordering. May 2005 300 Product Version 4.1.5 Encounter User Guide Placing the Design In the following scan chain example, buffer A is in the scan chain, but not part of the functional logic of the design, and therefore can be deleted. Buffer B is part of the functional logic, and must not be deleted. To other functional logic SI Q SI Q SI Buffer A To other functional logic Q SI Q Buffer B The scanReorder -noSkip command retains all two-pin cells in the scan chain, and reordering changes only the connections to the two-pin cells’ outputs. The nets connected to the two-pin cells’ inputs will not be modified. In the preceding example, both buffers A and B would be retained, and scan reordering would be performed by rearranging the scan input pin connected to their output nets. The scanReorder -skipBuffer command reconnects the scan chain so that buffers (as defined by setBufFootPrint) are skipped. Buffers that are not part of the functional logic are deleted. This disconnects scan inputs and reconnects them directly to a scan output pin, skipping all buffers. Any two-pin cells that are not buffers are retained in the scan chain in the same manner as -noSkip. In the preceding example, buffer A would be deleted and functional buffer B would be retained in the netlist. Scan reordering would disconnect the scan input pin from the output of buffer B, and reconnect some other scan input pin to the input net of buffer B, so buffer B would no longer be in the scan chain. The scanReorder -skipTwoPinCell command works the same as scanReorder -skipBuffer, except that it is not limited to buffers. Any two-pin cell will be treated as -skipBuffer would treat a buffer. Important Because scanReorder -skipTwoPinCell does not consider the functionality of cells that it removes from the scan chain, it can change the scan chain in unpredictable ways. For example, if buffer A in the preceding example was an inverter, it would be removed, and the test pattern would have to be changed to account for the loss of inversion. May 2005 301 Product Version 4.1.5 Encounter User Guide Placing the Design scanDEF Scan Reordering Approach If you have a scanDEF file that describes the set of reorderable scan chains in the design, Cadence recommend using the scanDEF approach. To reorder scan chains with the scanDEF approach, do the following steps: 1. Read in the scanDEF file: defIn –scanChain Note: In the case where a DEF file contains a SCANCHAIN section, the defIn command automatically reads in the scanDEF file, so the -scanChain parameter is not necessary. 2. Place the design: amoebaPlace [–ignoreScan] 3. Reorder the scanDEF chains: scanReorder Using the scanReorder command. When running the scanReorder command, the Encounter software uses the begin and endpoints from the scanDEF chains to trace the connectivity of the scan chains in the netlist. This check verifies if the elements in the netlist scan chains are represented as elements in their respective scanDEF chains. As a result of this check, an internal representation of each scanDEF chain is created in the Encounter database. When a netlist-to-scanDEF file mismatch occurs, for each instance mismatched, scanReorder will issue the following WARNING message: WARNING (SOCSC-5003): The scan chain was found to pass through instance <inst> in the netlist, but this instance does not appear in the DEF scan chain. Mismatches of combinational components (buffers or inverters) in the scan data path can be expected if the netlist has undergone pre-placement optimization, or if the scanDEF file is not properly formatted, as described in Netlist-to-scanDEF mismatch section. Sequential mismatches are tolerated if the mismatch occurs for a scan flop from the FLOATING section only of the scanDEF chain. However, sequential mismatches are not expected and indicate a discrepancy between the scan chains in the netlist, and the scanDEF chains. You should investigate the source of the discrepancy before proceeding with reordering. If necessary, revise the scanDEF description of the scan chains. Using the internal representation of the scanDEF chains, Encounter will issue the following message prior to reordering the chains in the netlist: INFO: Scan reorder based on traced netlist chains. INFO: Medium effort Scan reorder INFO: Reordering scan chain <chainName> May 2005 302 Product Version 4.1.5 Encounter User Guide Placing the Design Netlist-to-scanDEF mismatch. Netlist-to-scanDEF mismatches can occur if a driving scan flip-flop is buffered (or inverted) to the SI pin of the next scan flip-flop in the scan chain. In this situation, the driving scan flop and buffer (or inverter) should be captured to the scanDEF file as an ORDERED segment, rather than capturing the driving scan flip-flop as a freely reorderable element in the FLOATING section of the scanDEF chain. The correct syntax for the FLOATING and ORDERED sections of the scanDEF file is as follows: - chain X + START PIN + FLOATING .... next_scan_flop_reg ( IN SI ) ( OUT SO ) + ORDERED driving_scan_flop_reg ( IN SI ) ( OUT SO ) buf_instance ( IN A ) ( OUT Y ) + STOP In previous releases of Encounter, when a scanDEF to netlist mismatch occurred, scan reorder would abort. If the mismatches were due to combinational components (buffers or inverters) in the scan data path, you could still proceed with scan reordering by issuing scanReorder with the following options: scanReorder -defInForce -deleteDanglingBuforInv For backward compatibility, these options are maintained in this release of the tool. However, in order to leverage the new netlist-to-scanDEF tracing feature, you should remove these options from the scanReorder command The -defInForce parameter forces reordering to use the scanDEF file. The -deleteDanglingBuf parameter removes all buffers or inverters along the scan data path whose output pins are now unconnected as a result of reordering. This is expected because these elements were not originally listed in the scanDEF file. The deleted elements are listed in the _scan_deleted_elements file. May 2005 303 Product Version 4.1.5 Encounter User Guide Placing the Design scanDEF file format. The scanDEF file follows a pin-based format that describes the set of scan chains or chain segments which are reorderable in the design. The syntax is as follows: SCANCHAINS numScanChains ; [- chainName [+ COMMONSCANPINS [( IN pin )][( OUT pin )] ] [+ START {fixedInComp | PIN} [outPin] ] {+ FLOATING {floatingComp [( IN pin )] [( OUT pin )]}...} [+ ORDERED {fixedComp [( IN pin )] [( OUT pin )] fixedComp [( IN pin )] [( OUT pin )]} [fixedComp [( IN pin )] [( OUT pin ) ] ]...] [+ STOP {fixedOutComp | PIN} [inPin] ] ;]... END SCANCHAINS Note: The Encounter software reads and parses DEF 5.5 syntax. However, scan reordering does not utilize the scan reorder DEF 5.5 syntax, such as: [+ PARTITION partitionName [MAXBITS maxBits] ] The logic synthesis tool writes the input scanDEF file after the top-level scan chains are created in the design. Each top-level scan chain can be segmented into multiple scanDEF chains because the elements along each scanDEF chain must belong to the same clock domain, and be triggered by the same active edge of clock. Scan flip-flops that are freely reorderable along the scan chain are captured to the FLOATING section. Fixed segments (a set of connected elements), which are reordered as a fixed entity along the scan chain, are captured to the ORDERED section. Each scan chain must also have a START and STOP signal that defines the reordering start and end points of the scan chain. Note: You can use the following BuildGates/PKS command to create a scanDEF file: write_def –scan_only fileName.scan.def or you can use the following RTL Compiler command: write_scandef > fileName Valid design types. You can use the scanDEF approach to reorder top-level scan chains. This section provides a reordering example for implied domain transition scan chains, and an example of scan chains with fixed-ordered segments. You can also use this approach with all simple scan chain architectures that can use the native approach, as well as scan chains generated by LogicVision software. ■ Implied domain transition scan chains The scan flip-flops are triggered by alternate active edges of the same clock domain. The negative (positive) edge triggered segment precedes the positive (negative) edge May 2005 304 Product Version 4.1.5 Encounter User Guide Placing the Design triggered segments, respectively. In the following example, the implied domain transition occurs at neg2_reg to pos1_reg: Domain transition occurs in SI Q neg1_reg clk1 SI Q neg2_reg SI Q pos1_reg B SI Q pos2_reg SI Q pos3_reg SI Q Scan data connection Functional connection pos4_reg 1 out 0 A shift_enable In this example, the two scan chain segments are as follows: ❑ clk1 (negative edge) consisting of elements neg1_reg and neg2_reg ❑ clk1 (positive edge) consisting of elements pos1_reg, pos2_reg, pos3_reg, and pos4_reg Because the domain transition is done implicitly (without a data lockup element), the scan chain must be segmented to be properly reordered. In the scanDEF format, the toplevel chain becomes two scanDEF chains, segmented by clock domain and clock edge; the pos1_reg scan flip-flop is sacrificed to anchor the domain transition. This register becomes an internal end and internal being point of scan DEF chains (chain1 and chain2 respectively): SCANCHAINS 2 ; - chain1 + START pin in + FLOATING neg1_reg ( IN SI neg2_reg ( IN SI + STOP pos1_reg SI ; - chain2 + START pos1_reg Q + FLOATING pos2_reg ( IN SI pos3_reg ( IN SI + STOP pos4_reg SI ; END SCANCHAINS ) ( OUT Q ) ) ( OUT Q ) ) ( OUT Q ) ) ( OUT Q ) Note: The shared functional output signal (out) is not the STOP signal of the second scan chain segment. Instead, the scan chain is terminated to the IN pin of the last scan flop in the positive-edge triggered segment (BuildGates/PKS), or terminated to the data input pin of the MUX (other third-party tools). May 2005 305 Product Version 4.1.5 Encounter User Guide Placing the Design ■ Scan chains with ORDERED segments An order segment is a set of connected elements that can be reconnected along the scan chain based on its placement. Reconnection to the fixed segment occurs using the IN pin of the first element and the OUT pin of the last element of the ordered segment. The connections of the other elements in the ordered segment are presumed connected and remain as intact connections. When an ORDERED segment is reconnected in the scan chain, the location of the ORDERED segment appears as a comment in the FLOATING section and again in the ORDERED section in order to correlate the segment to its location in the FLOATING section. The notation is as follows: # ORDERED segment integer; The integer corresponds to as many ORDERED segments as defined in the original scan chain. For example, a scanDEF chain with one ORDERED segment is as follows: SCANCHAINS 1 ; - chain0 + START PIN scan_in + FLOATING out_reg_0 ( IN SI ) ( OUT out_reg_1 ( IN SI ) ( OUT out_reg_2 ( IN SI ) ( OUT out_reg_3 ( IN SI ) ( OUT + ORDERED out_reg_4 ( IN SI ) ( OUT u_buf ( IN A ) ( OUT Y ) + STOP PIN scan_out ; END SCANCHAINS Q Q Q Q ) ) ) ) Q ) After reordering the output, the scanDEF file is as follows: SCANCHAINS 1 ; - chain0 + START PIN scan_in + FLOATING out_reg_2 ( IN SI ) ( OUT out_reg_1 ( IN SI ) ( OUT # ORDERED segment 1 out_reg_3 ( IN SI ) ( OUT out_reg_0 ( IN SI ) ( OUT + ORDERED # ORDERED segment 1 out_reg_4 ( IN SI ) ( OUT u_buf ( IN A ) ( OUT Y ) + STOP PIN scan_out ; END SCANCHAINS May 2005 306 Q ) Q ) Q ) Q ) Q ) Product Version 4.1.5 Encounter User Guide Placing the Design Therefore, the connectivity of the elements along the reordered scan chain is as follows: ORDERED segment 1 scan_in A SI Q SI Q Y SI Q SI Q SI Q out_reg_3 out_reg_2 scan_out u_buf clk1 out_reg_2 out_reg_1 out_reg_4 Saving Scan Files After scan reorder is run, save a DEF or TDF file using the following text command: defOutBySection -noNets -noComps -scanChains -fixedScanChain With this command, you can view the new order of elements along the scan chain. However, you should use the scanDEF output file for viewing purposes only, not a subsequent reordering pass. To save scan files, use the Save Scan File form or the defOut or tdfOut text commands. Loading Scan Files To load scan files in either DEF or TDF formats, use the Load Scan File form. For DEF, use the defIn text command. For TDF, you can also use the tdfIn text command. May 2005 307 Product Version 4.1.5 Encounter User Guide Placing the Design Adding Filler Cells You can add filler cells at the end of the design cycle to fill all the gaps between standard cell instances. Filler cells can also provide decoupling capacitance to complete the power connections in the standard cell rows and extend N-well and P-well regions. After routing, the command automatically checks for DRC violations on filler cells being added. This is to ensure that no new DRC violations are created due to filler cells. To add filler cells, use the Add Filler form or the addFiller text command. For more information on the forms listed in this section, see the Encounter Menu Reference. For more information on the commands listed in this section, see the Encounter Text Command Reference. Tip Provide a list of filler cells so that at least one filler can be used to fill the space without causing DRC violations. Filler cells can be added before or after routing the design. If filler are added after routing, the software checks for DRC violations between regular nets and the filler cells that are to be inserted in an effort to add only filler cells with no DRC violations. If filler are added before routing, they will provide decoupling capacitance. You can also add other types of filler cells, such as well-taps for special power and ground connections, and endcaps to cap off the ends of the site rows. Use the Add Filler program at the end of your design cycle because adding filler cells fills all the empty space between standard cell instances, leaving no possibility of running in-place optimization. The Add Filler program recognizes if any filler cell has implant layer geometries and attempts to add fillers to honor the implant layers’ width and spacing rules. By judicious selection of filler cells, the Add Filler can fix implant layers' minimum spacing errors present in the design by putting in same voltage threshold implant layer fillers in spaces between two same implant layer cells. Add Filler also avoids creating any new implant layer minimum width errors by abutting fillers of same implant layer as the adjacent cells, thus extending the implant layer width. For syntax information, see “Layer (Implant)” in the LEF/DEF Language Reference. May 2005 308 Product Version 4.1.5 Encounter User Guide Placing the Design Important The Add Filler program expects to be provided with cells of all types of implant layers to be able to completely fill the design's core area with fillers. For example, if only a low-voltage implant layer filler is provided, and the abutting logical cell has a highvoltage implant layer, then the Add Filler program will place the provided low-voltage implant filler only if its width satisfies the minimum width rule for that implant layer. Adding Well-Tap Cells Well taps are physical-only filler cells that are required by some technology libraries, to limit resistance between power or ground connections to wells of the substrate. Well-tap cells are placed in a preplaced status, so future placement commands will not move them. The following diagram shows an example of well-tap cell placement, which are staggered in the site rows. Well taps Site Rows Add well taps before placing standard cells, but after the floorplan has been fixed and hard macros have been placed. To add well-tap cells, use the Add Well Tap Instances form or the addWellTap text command Adding Fillers and Well-Taps to MSV Designs In cases where there are different voltages in the same design, also known as a multi-voltage (MSV) design, you might need to specify the power domain in which the fillers are to be inserted using the -powerDomain option of the addFiller command. If this option is not specified for MSV designs, the command only inserts default power domain fillers. Any region that does not belong to a specific power domain is assigned to the default power domain. May 2005 309 Product Version 4.1.5 Encounter User Guide Placing the Design Adding Endcap Cells Endcap cells are preplaced physical-only cells that are required to meet certain design rules. They are placed at the ends of the site rows, and are used in some technology for power distribution. Endcap cells are placed in a preplaced status, so future placement commands will not move them. You should add endcaps to the design before any other standard cell is placed, but after hard macros have been placed in the floorplan. The following diagram shows an example of endcap cell placement, which are placed at the ends of each site row. Site Rows Endcaps Endcaps To add endcap cells, use the Add End Cap Instances form or the addEndCap text command Deleting Filler Cells To remove added physical-only cell instances, such as filler cells, well-tap cells, and endcap cells, use the Delete Instances form or the deleteFiller text command. If you specify an area, the deleteFiller command deletes physical instances that are completely contained within the area; it will not delete instances that cross the area boundary. May 2005 310 Product Version 4.1.5 Encounter User Guide Placing the Design Adding Logical Tie-Off Cells The tie-off cell instances provide connectivity between the tie-hi and tie-lo logical input pins of the netlist instances to power and ground. This connectivity does not cross the hierarchy module boundaries. The number of tie-off instances added can be controlled by setting the distance and fanout constraints using the setTieHiLoMode text command. To add logical tie-off cells to the design after placing the netlist, you can use the Add TieHiLo form or the addTieHiLo text command. To remove added logical tie-off cell instances, you can use the Delete TieHiLo form or the deleteTieHiLo text command. For more information on these forms, see the “Place Menu” chapter in the Encounter User Guide. For more information on these commands, see the “Placement Commands” chapter in the Encounter Text Command Reference. May 2005 311 Product Version 4.1.5 Encounter User Guide Placing the Design Timing-Driven Placement You can specify timing-driven placement by using the amoebaPlace command as follows: amoebaPlace -timingdriven During timing-driven placement, the Placement program balances the importance of meeting setup timing constraints with routability. It identifies the most critical nets in the design and runs Placement to meet the constraints. For less critical nets, Placement gives less attention to meeting timing constraints and more attention to enhancing routability. To use this option, you must load a timing constraint file. Important Be aware of the following conditions: ■ A complete constraints file is essential for running timing-driven placement. Make sure the timing constraints file is complete for the entire design before running timing-driven placement. ■ You can perform limited in-place optimization by upsizing and downsizing instances using amoebaPlace -timingdriven -ipo. When specifying the -ipo option, you should save the netlist to a file along with the placement file, because this option changes the design. For more information on the amoebaPlace and trialRoute commands, see the Encounter Text Command Reference. May 2005 312 Product Version 4.1.5 Encounter User Guide Placing the Design Netlist Clustering Mode Netlist clustering is used for fast full chip prototyping of large designs. A cluster is a set of standard cells with strong connectivity that belong to the same intermediate module in the hierarchical netlist. Running placement in clustering mode is a quick way of doing placement evaluation on the netlist to give a quick assessment on floorplan congestion. The floorplan generated by clustering mode placement can also be used in a partitioned design. With netlist clustering, you can create a smaller clustered netlist than the original netlist with the same logic hierarchy. For example, a netlist with 2 million instances can be reduced to 500,000 instances if the average cluster size is set to 4. This reduction results in increased system capacity. Important When running clustering mode placement, be aware of the following: ❑ Congestion and wirelength reported will be worse than normal flat placement. ❑ There is no guarantee that the placement will be free of overlaps. ❑ It is not intended to be used as final placement. ❑ Do not generate a final placement by running refinePlace directly on the placement obtained from clustering mode placement. When utilizing these netlist clustering commands, you must use the following command order: 1. designImport 2. loadFPlan 3. netlistClustering, or restoreClustering 4. amoebaPlace, or restorePlace if you previously ran netlist clustering and saved the placement data. Note: As an alternative to steps 3 and 4, you can use the clusteringPlace command. This bundles the netlistClustering and amoebaPlace commands as one. 5. trialRoute 6. netlistUnclustering 7. savePlace flat.place May 2005 313 Product Version 4.1.5 Encounter User Guide Placing the Design For more information on the netlist clustering commands, and the commands listed in this flow, see the Encounter Text Command Reference. Post-Placement Congestion Optimization Post-placement congestion optimization reduces congestion after placement. This automatically applies to the whole chip or block, and can be applied after global placement, timing optimization, or clock tree synthesis, when routability becomes the ultimate goal. Timing is not considered; therefore, the preservation of timing is not guaranteed, although it usually results in better timing due to the improvement in congestion and the reduction in wire length. Before running post-placement congestion optimization, the design must be legally placed; otherwise, this first places cell instances on legal locations, and then reduces the congestion from that point. As a result, the final design will be a legal one with better routability than the original (legal) one. To run post-placement congestion optimization, use the congOpt command. Saving and Loading Placement Data You can save placement data in the Encounter (place) format, or in DEF, PDEF, and TDF placement data formats. This can be done at any time after running the Placement program. To save placement data, use the Save Placement form or the savePlace text command. To load placement data, use the Load Placement form or the restorePlace text command. May 2005 314 Product Version 4.1.5 Encounter User Guide 12 Synthesizing Clock Trees CTS analyzes all clocks in a design (or specific clocks that you define) and inserts buffers (or inverters) to reduce or eliminate clock skew. This chapter describes how to use the Clock menu’s clock tree synthesis (CTS) forms to build a buffer tree and balance insertion delays from the clock source to all flip-flops. This chapter discusses the following topics: ■ Before You Begin on page 316 ■ Results on page 316 ■ Understanding CTS Operation Modes on page 317 ■ How CTS Calculates Skew Values on page 322 ■ Improving Postroute Correlation on page 324 ■ Specifying Macro Model Delays on page 325 ■ Grouping Clocks on page 326 ■ Analyzing Hierarchical Clock Trees on page 327 ■ Module Placement Utilization on page 329 ■ Clock Designs with Tight Area on page 329 ■ Balancing Pins for Macro Models on page 329 ■ Timing Model Requirement for Cells on page 329 ■ Understanding Post-CTS Clock Tree Optimization on page 329 ■ Creating a Clock Tree Specification File on page 333 May 2005 315 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Before You Begin Before you run CTS on your design, make sure the following files are available: ■ Clock tree specification file ■ Verilog netlist ■ GDSII or LEF physical library ■ Proper RC model from LEF, Encounter™ technology file, or Encounter capacitance table For information on RC extraction in Encounter, see RC Extraction on page 501 of the Encounter User Guide. ■ Timing constraints file (optional) ■ Synopsys .lib file or TLF file with timing models for standard cells and cell footprint names ■ Placement information, such as a DEF file or an Encounter placement file Results After a CTS run, CTS creates reports on the results of the run in ASCII text or HTML format. CTS also creates routing guide files (for clock tree preroutes to be used during trial routing) and macro model files (for partitions or modules). May 2005 316 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Understanding CTS Operation Modes There are two modes for running CTS: manual and automatic. ■ Manual CTS mode allows you to control the number of levels and the number of buffers, and specify the types of buffers at each level. ■ In automatic CTS mode, CTS automatically determines the number of levels and buffers based on the timing constraints in the clock tree specification file, such as the maximum delay and maximum skew. Manual CTS Mode You can run manual CTS on a clock net and specify the levels of clock buffers. CTS builds the clock buffer tree according to the clock tree specification file, generates the clock tree topology, and balances the clock phase delay with inserted clock buffers. However, CTS does not trace the clock net. MCK_GE 2 2 CLKBUF40 20 CLKBUF20 CTS Added by CTS May 2005 317 To FlipFlops MCK_GE Level 2, 20 CLKBUF20 MCK_GE Level 1, 2 CLKBUF40 ClockNetName LevelNumber LevelSpec 1 LevelSpec 2 PostOpt YES End To FlipFlops The following is an example of clock-tree specification file syntax and a graphic representation of that syntax: Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Automatic CTS Mode You can run automatic CTS to synthesize the clock design on a clock net or on a gated clock design. However, CTS does not trace the clock net. Automatic CTS on Nets For automatic CTS on a net, CTS builds the clock buffer tree according to the clock tree specification file, generates the clock tree topology, and balances the clock phase delay with appropriately sized, inserted clock buffers. May 2005 318 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees The following is an example of clock tree specification file syntax for automatic CTS on a net and a graphic representation of the syntax: MacroModel pin mem_core/clk 20ps 18ps 20ps 18ps 28ff AutoCTSRootPin SH1/I23/Z NoGating rising Buffer INV14 CLKBUF12 CLKBUF40 CLKBUF20 DEL4 MaxDelay 5ns MinDelay 0ns MaxSkew 500ps End Phase Delay 1 CTS buffer2 CTS delay1 Buffer Input Transition Time AutoCTSRootPin SH1/I23/Z CTS delay2 CTS buffer3 Phase Delay 2 F/Fs Skew Sink Input Transition Time F/Fs CTS buffer4 MacroModel Pin mem_core/clk Phase Delay 3 Added by CTS CTS buffer5 CTS does not trace through gates, because NoGating rising is specified, but the skew is balanced. Phase Delay 4 Automatic CTS for Gated Clocks For automatic-gated CTS, CTS traces the clock tree starting from a root pin. The tracing begins at the root pin, then continues through the buffers, inverters, multi-output cells, and gated instances to establish the clock tree. The tracing stops at ■ A clock pin ■ An asynchronous set/reset pin May 2005 319 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees ■ An input pin without any timing arc to an output pin ■ A user-specified leaf pin or excluded pin After the tracing, CTS builds the clock buffer tree topology to balance the clock phase delay with inserted clock buffers. Note: Cadence recommends using the ckSynthesis -check command to check the gated clock tree of your design before running automatic gated CTS mode. After running the command, review the trace report file, topCellName.cts_trace. If tracing fails, the -forceReconvergent parameter of the ckSynthesis command could resolve tracing failures. May 2005 320 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees The following is an example of clock tree specification file syntax for automatic CTS on a gated clock and a graphic representation of the syntax: AutoCTSRootPin SH1/I23/Z MaxDelay 5ns MinDelay 0ns MaxSkew 500ps MaxDepth 20 NoGating NO RouteType CK1 LeafPin + FPU/CORE/A rising ExcludedPin + XPU/CAM/C PreservePin + pinA + pinB MaxCap + buf1 20ff + buf2 50ff Buffer buf1 buf2 inv1 inv2 del1 End AutoCTSRootPin Phase Delay 1 SH1/I23/Z MacroModel Pin mem_core/clk CTS buffer2 F/Fs Max Skew Sink Input Transition Time CTS buffer1 Phase Delay 2 FPU/CORE or can be a std cell CTS buffer4 Buffer Input Transition Time CTS buffer3 Pin FPU/CORE/A XPU/CAM No clock skew balance performed Pin XPU/CAM/C Added by CTS May 2005 321 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees How CTS Calculates Skew Values CTS calculates skew at the edge of the clock root in the following fashion: ■ Rise skew and fall skew are calculated relative to the edge of the clock root—for example, rise skew is calculated based on the rising edge at the clock root. Note: The edge polarity at the leaf pins can be rising or falling, regardless of whether CTS is reporting on rise skew or fall skew. ■ Rise skew is the maximum difference of all the arrival times of the clock signal at the leaf inputs, as measured from a rising edge at the clock root. ■ Fall skew is the maximum difference of all the arrival times of the clock signal at the leaf inputs, as measured from a falling edge at the clock root. ■ Trigger-edge skew is based on all the arrival times of the active clock signal at the leaf inputs. The calculation considers the trigger-edge polarity of the receiving leaf inputs, and represents the worst-case trigger-edge-to-trigger-edge skew in the design. See the accompanying figure. Note: Trigger-edge skew can be greater or smaller than rise skew or fall skew. The following example illustrates how CTS calculates various skew values: Assume that a design has two flip-flops, FF1 and FF2: FF1 rise: 3.0 ns; fall: 3.6 ns FF2 rise: 3.4 ns; fall: 4.0 ns Rise skew is 0.4 ns; fall skew is 0.4 ns. Assume that FF1 is a falling-edge-triggered flip-flop, and that FF2 is a rising-edge-triggered flip-flop. The trigger-edge skew is 3.6 ns - 3.4 ns = 0.2 ns. Assume that FF1 is a rising-edge-triggered flip-flop, and that FF2 is a falling-edge-triggered flip-flop. The trigger-edge skew is 4.0 ns - 3.0 ns = 1.0 ns. May 2005 322 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees The following figure illustrates how trigger-edge skew can be smaller than either rise skew or fall skew: A 100 ps B 300 ps T C 500 ps T D 800 ps Rise skew (C - A): 500 ps - 100 ps = 400 ps Fall skew (D - B): 800 ps - 300 ps = 500 ps Trigger-edge skew (C - B): 500 ps - 300 ps = 200 ps T = Trigger edge May 2005 323 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Improving Postroute Correlation You can create a routing guide file that CTS automatically uses to direct the global detailed routing of clock nets. This process helps achieve tighter correlation between preroute (Steiner tree) and postroute topologies. There are two methods of improving postroute correlation with a routing guide file. The difference between the two methods is this: With Method 2, CTS reports on the clock tree before you complete the detailed routing on the design. Method 1 1. In the Encounter console, type setCTSMode -useCTSRouteGuide. 2. In the clock tree specification file, include RouteClkNet YES, or use the text command createClockTreeSpec -routeClkNet. 3. In the Encounter console, type ckSynthesis. 4. Check your run directory for the clock tree timing report (top_level_cell.ctsrpt). Method 2 1. In the clock tree specification file, include RouteClkNet NO. 2. In the Encounter console, type ckSynthesis. 3. In the Encounter console, type routeClockNetWithGuide [-clk clock_root_pin_name] 4. Check your run directory for the clock tree timing report (top_level_cell.ctsrpt). May 2005 324 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Specifying Macro Model Delays You use the MacroModel statement to specify pin delays. A macro model is a block with synthesized clock trees, and thus has delays that have been identified. There are three ways to define the macro model: ■ Cell or port delay specification—All instantiations of cells have the same pin delay. MacroModel port cellName/portName maxRiseDelay minRiseDelay maxFallDelay minFallDelay inputCap where cellName is the cell type name and the portName is the port name. For example: MacroModel port ram256x64/clk 10ns 80ns 110ns 7ns 22pf ■ Pin instance delay specification—This specification can supersede a cell delay or port delay specification. MacroModel pin leafPinName maxRiseDelay minRiseDelay maxFallDelay minFallDelay inputCap where the leafPinName is the leaf pin instance name. For example: MacroModel pin mem_pin/clk 20ps 18ps 20ps 18ps 28ff Delay units for MacroModel statements must be specified in nanoseconds (ns) or picoseconds (ps), for example, 200ps, 1ns. Capacitance units for MacroModel statements must be specified in picofarads (pF) or femtofarads (fF), for example, 0.2pf, 130ff. ■ INSERTION_DELAY statement in the TLF file. INSERTION_DELAY(CLK FAST 01 01 DELAY(InsDelay0) SLEW(InsSlew1)) INSERTION_DELAY(CLK SLOW 01 01 DELAY(InsDelay0) SLEW(InsSlew1)) For information on TLF, see the Timing Library Format Reference. For illustrations of MacroModel behavior, see Automatic CTS on Nets on page 318 and Automatic CTS for Gated Clocks on page 319. May 2005 325 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Grouping Clocks Clock grouping is available in automatic CTS mode. All clock root pin names entered into a clock group that will have their sinks meet the maximum skew as specified in the clock tree specification file. CTS balances the clock tree roots as if they were one tree. The sinks of all clock root pins listed in a ClkGroup statement will meet the maximum skew value set in the clock tree specification file. Clock grouping inserts delays to balance the clocks, and attempts to meet clock skew for all clocks. Note: You can define more than one clock group in the clock tree specification file. The following is an example of clock group syntax and its graphical representation: ClkGroup + SH1/I23/Z1 + SH22/I6/Z2 SH1/I23/Z1 CTS optimizes skew between tree 1 and tree 2 CTS tree 1 SH22/I63/Z2 CTS tree 2 Note: All ClkGroup statements must be specified in lines following macro model line(s), and before any clock specification. May 2005 326 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Analyzing Hierarchical Clock Trees Encounter designs clock trees in a two-step, bottom-up fashion. Within Encounter, the designing of the clock tree is done bottom-up in two steps. After partitioning the design, you can run CTS on each partition individually. Once the partitions are synthesized, the top-level partition runs CTS hierarchically. So CTS runs at the top-level partition, and the partitions’ clock tree results are treated as macro model instances. To generate the partition macro models, use the Synthesize Clock Tree form (Clock – Synthesize Clock Tree) or the following command when running CTS for the partition: ckSynthesis -macromodel fileName The rise time, fall time, and input capacitance for the clock pins are characterized, and the fileName output model file is used when creating the top-level partition’s clock tree specification file. Running CTS for the top-level partition balances the clock phase delay between the top-level and the partitions. Important The macro model specifications for each partition are at the top of the clock tree specification file. For example, in a design with three partitions (blockA, blockB and blockC), you should first synthesize the partitions individually. To run CTS on the partition’s blocks, you should add the AddDriverCell statement in the clock tree specification file. Use the AddDriverCell driver_cell_name statement for block-level CTS to place a driver cell name at the closest possible location to the clock port location. For example: AutoCTSRootPin blockA/clk .... ... AddDriverCell CLKBUF8 End May 2005 327 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees CTS adds buffer CLKBUF8 after the input pin, as shown in the following figure: blockA/CLK blockB CLKBUF8 blockA blockC Clock Tree After running CTS on the blocks, run CTS on the top level of the design. To run top-level CTS, you must include all the macro models from block-level CTS in the clock tree specification file. Important If your top-level design has a large amount of blockage and is limited in routing resources, you should add the Obstruction Yes statement in the clock-tree specification file. That statement instructs CTS to run the detail maze router to detect the obstruction (which increases CTS runtime). Use this statement only when routing resources are extremely limited, such as in top-level CTS. The following example shows the Obstruction Yes command in the clock specification file: MacroModel port blockA/clk 900ps 800ps 900ps 800ps 17ff MacroModel port blockB/clk 1100ps 1000ps 1100ps 1000ps 18ff MacroModel port blockC/clk 500ps 400ps 500ps 400ps 19ff AutoCTSRootPin clk .... ... Obstruction Yes End May 2005 328 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Module Placement Utilization Make sure the modules’ placement utilization, which contains the clock nets is set to 5–7 percent less than the desired final chip utilization (placement density). This provides placement resources for adding clock buffers during CTS. Clock Designs with Tight Area For a clock design that is limited to a tight area, use the Specify Cell Padding form (Place – Specify – Cell Padding) to create placement resources near clocked flip-flop cell types. Balancing Pins for Macro Models CTS can balance a pin of a macro model. These macro models are user specified. CTS balances the phase delay of all leaf pins in the clock tree, including leaf pins of macro models. The timing models for macro models are defined in the clock tree specification file MacroModel statement. Timing Model Requirement for Cells Make sure that all cells have a timing model. If a cell does not have a timing model, CTS will not trace through the gate, and may set the gate’s input pin as a leaf pin. Understanding Post-CTS Clock Tree Optimization Using the ckECO Command for Post-CTS Clock Tree Optimization Use the ckECO command for post-CTS optimization of clock tree(s) in the same Encounter session as the ckSynthesis command was run, or in a new session. The sole aim of the ckECO command is to improve skew. The ckECO command does not attempt to correct any design rule violations. However, in trying to improve skew, the ckECO command does not significantly worsen maximum transition or maximum capacitance violations. May 2005 329 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees The ckECO command performs resizing and buffer insertion or dummy buffer insertion to improve skew. In addition, the ckECO command might move gating cells when the ckECO command runs refinePlace. Support for Local Skew Optimization The ckECO command also supports local skew optimization (with the -localSkew parameter). Local skew optimization considers the skew between adjacent flip-flops that have data path connection (from a Q-pin of one flip-flop to the D-pin of another flip-flop). Load the timing constraints into the Encounter session (design import stage) when you want to perform local skew optimization. At a minimum, the ckECO command needs to have the clock roots defined in the SDC file so CTS can identify the adjacent register pairs. Command Modes for the ckECO Command The ckECO command can be run in three modes: ■ ckECO -preRoute ■ ckECO -clkRouteOnly ■ ckECO -postRoute It is important to choose the correct mode, based on the state of the design. Otherwise CTS might use the wrong RC model, which can lead to quality-of-result (QOR) and correlation problems. Using a SPEF File with the ckECO Command for RC Estimation As an alternative to using CTS estimation for RCs it is possible to load a SPEF file. If you use an external SPEF file (spefIn) you just use the ckECO -postRoute command, and CTS does not create a clock tree report after the ckECO -postRoute process is done. You will need to re-extract the RC values for all the wires. After you create a new SPEF file, load this new file into the Encounter session. Then run reportClockTree -postRoute. CTS then creates the clock report. If clock nets are in a routed state you run the ckECO command, any wires that are disturbed by the ckECO command will automatically be rerouted using NanoRoute in an ECO mode. May 2005 330 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Running Post-CTS Optimization with the ckECO Command You must load the clock tree specification file to run the ckECO command. (The clock tree specification file defines the clocks which you want to optimize.) Whether the ckECO command performs resizing or ECO routing depends on these clock tree specification file or setCTSMode settings: ■ RouteClkNet YES | NO ■ setCTSMode -routeClkNet | -noRouteClkNet ■ PostOpt YES | NO ■ setCTSMode -postOpt | -noPostOpt The following examples show the usage of the ckECO command for two general design states. Example 1 If your design has the following characteristics— ■ Clock tree is already inserted ■ Clocks are routed ■ Signal nets are not routed —use this command sequence: specifyClockTree ckECO -clkRouteOnly Example 2 If your design has the following characteristics— ■ Clock tree is already inserted ■ Clock nets are not routed ■ Signal nets are not routed —use this command sequence: specifyClockTree ckECO May 2005 331 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Note: When you specify the ckECO command without a parameter, you instruct CTS to use the default mode for the command, which is -preRoute. Guidelines for Using the ckECO Command ■ In previous releases, the ckECO command was unable to run if the command detected any trial-routed nets in the design (the command would issue an error message and stop). Now the ckECO command removes any trial-routed nets. When the ckECO command process ends, the command calls Trial Route to replace those trial-routed nets. Note: The trial routes are not guaranteed to be identical to those before you ran the ckECO command. ■ By default, the ckECO command inserts a maximum of 50 buffers. The number of buffers is controlled by the OptAddBufferLimit statement in the clock tree specification file. ■ Often it is possible to make incremental improvements to skew by running the ckECO command multiple times. For details on the ckECO command and its parameters, see “Clock Tree Synthesis Commands” in the Encounter Text Command Reference. May 2005 332 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Creating a Clock Tree Specification File Before you can run CTS, you must create a clock tree specification file by: ■ Using the Create Clock Tree Spec form ■ Using the createClockTreeSpec command ■ Using the specifyClockTree command with the -template parameter The specifyClockTree command creates the basic clock tree specification file template file template.ctstch in the directory in which you are running the Encounter software. Edit the template file with any text editor. This file contains the following information on the clock or clocks you want to analyze with CTS: ■ Timing constraint file (optional) ■ Naming attributes (optional) ■ Macro model data (optional) ■ Clock grouping data (optional) ■ Attributes used by NanoRoute™ Ultra SoC routing solution (optional) ■ Requirements for manual CTS or automatic, gated CTS You can create a clock tree specification file for all the clocks in your design, for a subset of clocks in your design, or for a single clock. Important The general sections of the clock tree specification files must appear in the order given above. However, the individual statements within each section can appear in any order. Example of a Clock Tree Specification File The following example illustrates the content of a clock tree specification file: TimingConstraintFile dtmf_cts.tc UseSingleDelim YES NameDelimiter | MacroModel pin freg/mod004048/CLK 20ps 18ps 20ps 18ps 30ff May 2005 333 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees ClkGroup + CGEN_1 + CGEN_2 UseCTSRouteGuide NO #Start RouteTypeName section RouteTypeName CK1 NonDefaultRule rule1 PreferredExtraSpace 1 TopPreferredLayer 5 BottomPreferredLayer 4 #End RouteTypeName section Shielding VSS End #Example of manual CTS specification information ClockNetName CK LevelNumber 2 LevelSpec 1 1 BUFX2 LevelSpec 2 2 BUFX2 PostOpt YES OptAddBuffer YES End AutoCTSRootPin cgen/i_5/Y MaxDelay 5.0ns MinDelay 0ns MaxFanout 2 MaxSkew 250ps SinkMaxTran 550ps BufMaxTran 550ps NoGating NO DetailReport YES Obstruction YES RouteType CK1 RouteClkNet YES # Turns on NanoRoute. The default value is NO PostOpt YES # Turns on optimization. The default value is YES OptAddBuffer YES OptAddBufferLimit 100 Buffer BUFX2 BUFX4 BUFX8 BUFX12 INVX1 MaxCap + BUFX2 1pf May 2005 334 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees + BUFX4 1pf + BUFX8 1pf + BUFX12 1pf ForceMaxCap NO ThroughPin + df/mod000446/CK ThroughPort + df/mod002300/ax2 LeafPin + PCLK66_gate_i/A rising LeafPort + ssfd2s/D rising PreservePin + cgen/mod000043/A ExcludedPin + freg/mod004048/CLK ExcludedPort + DFF_B/CLK GatingGrpInstances + cg1/an cg1/i_0 + cg2/an cg2/i_0 + cg1/an cg3/i_0 + cg4/an cg4/i_0 GatingGrpModule + grp_module1 + grp_a* End Timing Constraint File Specification You can optionally define a timing constraint file for use during CTS. ➤ To specify a timing constraint file, the TimingConstraintFile fileName statement must be the first statement in the clock tree specification file. May 2005 335 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Naming Attributes Section The following table describes the entries for the naming attributes section: NameDelimiter delimiter Allows you to customize the name delimiter that CTS uses when inserting buffers and updating clock root and net names. There are no restrictions on the characters you can use for name delimiters. For example: NameDelimiter # creates names with the format clk##L3#I2, rather than the default format, clk__L3_I2. Insert the NameDelimiter statement after MacroModel and ClkGroup statements but before an AutoCTSRootPin statement. Note: If you have multiple NameDelimiter statements in the clock tree specification file, CTS uses only the last NameDelimiter statement in the file. Note: The NameDelimiter and UseSingleDelim statements are independent of each other. UseSingleDelim YES | NO Instructs CTS whether to use single name delimiters after the first element in clock root and net names. For example: UseSingleDelim YES creates clock and net names with the format clk_L3_I2, rather than the default format, clk__L3_I2. By default, CTS always inserts double (or, in some cases, multiple) name delimiters after the first element of clock root or net names. The UseSingleDelim YES statement overrides this behavior by instructing CTS to use only a single delimiter after the first element of the name: Insert the UseSingleDelim statement after MacroModel and ClkGroup statements but before an AutoCTSRootPin statement. Note: The UseSingleDelim and NameDelimiter statements are independent of each other. May 2005 336 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees NanoRoute Attribute Section The following table describes the entries for the section of the clock tree specification file that deals with attributes that CTS passes to NanoRoute Ultra. UseCTSRouteGuide YES | NO Specifies whether NanoRoute Ultra should route clock nets with the routing guide file generated by CTS. NanoRoute Ultra will produce better pre- and postroute correlations, though at the expense of longer run time. If you specify UseCTSRouteGuide YES and RouteClkNet YES, clock nets will be routed based on the route guide file created by CTS. If you specify UseCTSRouteGuide YES and RouteClkNet NO, CTS creates a route guide file. But because you instructed CTS not to route the clock nets, this guide file is not used. If the you subsequently use the command routeClockNetWithGuide, CTS generates a new routing guide file and automatically routes the clocks based on that guide file. RouteTypeName name Specifies the routing type for which you are defining routing attributes. Note: RouteTypeName statements must appear in the clock tree specification file before their corresponding RouteType statements. NonDefaultRule ruleName Specifies the LEF NONDEFAULTRULE statement that the router should use. Default: If you do not use this statement, the router uses the default routing rule. PreferredExtraSpace [0-3] Specifies the spacing attribute, with which to add space around clock wires. Default: If you do not use this statement, CTS uses a preferred extra space value of 1. TopPreferredLayer number May 2005 337 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Specifies the top-most preferred routing layer. Default: If you do not use this statement, CTS uses layer 4 as the top-most preferred routing layer. BottomPreferredLayer number Specifies the bottom-most preferred routing layer. Default: If you do not use this statement, CTS uses layer 3 as the bottom-most preferred routing layer. Shielding GNetName Defines the ground net name. End Marks the end of the NanoRoute Ultraattribute section. Important In all clock tree specification file sections that contain delay values or capacitance values, you must include the appropriate unit with the values you specify. The unit designations are case-insensitive. For example, pf, pF, Pf, and PF are all valid unit designations for picofarads. Macro Model Data Section The following table describes the entries for the macro model port data section: MacroModel port cellName_or_portName delay_and_capacitance_values Specifies the name of the macro model cell or port. maxRiseDelay{ns|ps} Specifies the maximum rise delay in nanoseconds or picoseconds. minRiseDelay{ns|ps} Specifies the minimum rise delay in nanoseconds or picoseconds. maxFallDelay{ns|ps} Specifies the maximum fall delay in nanoseconds or picoseconds. minFallDelay{ns|ps} Specifies the minimum fall delay in nanoseconds or picoseconds. inputCap{pf|ff} Specifies the input capacitance in picofarads or femtofarads. May 2005 338 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees The following table describes the entries for the macro model pin data section: MacroModel pin pinName delay_and_capacitance_values Specifies the name of the macro model pin. maxRiseDelay{ns|ps} Specifies the maximum rise delay in nanoseconds or picoseconds. minRiseDelay{ns|ps} Specifies the minimum rise delay in nanoseconds or picoseconds. maxFallDelay{ns|ps} Specifies the maximum fall delay in nanoseconds or picoseconds. minFallDelay{ns|ps} Specifies the minimum fall delay in nanoseconds or picoseconds. inputCap{pf|ff} Specifies the input capacitance in picofarads or femtofarads. Clock Grouping Data Section The following table describes the entries for the clock grouping data section: Specifies two or more clock domains for which you want CTS to balance the skew. ClkGroup + clockRootPinName + clockRootPinName … Clock-Tree Topology Section The clock-tree topology section provides a method for you to manually define buffers at particular levels. The following table describes the entries for the clock-tree topology section: ClockNetName netName Specifies the name of the clock net. LevelNumber totalNumberOfClockTreeLevels Specifies the total number of clock tree levels. LevelSpec levelNumber numberOfBuffers bufferType May 2005 339 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Provides the specifications for an individual clock level. Specify all the following information: levelNumber Sets the level number in the clock tree. numberOfBuffers Specifies the total number of buffers CTS should allow on the specified level of the clock tree. bufferType End Specifies the buffer type (based upon the LEF file). Marks the end of a clock tree topology section. Automatic Gated CTS Section The following table describes the entries for the automatic gated CTS section: AutoCTSRootPin clockRootPinName Specifies the name of the clock root pin name from which to start tracing. MaxDelay number{ns|ps} Specifies the maximum phase delay constraint. Default: If you do not use this statement, CTS uses a maximum phase delay constraint of 10 ns. MinDelay number{ns|ps} Specifies the minimum phase delay constraint. Default: If you do not use this statement, CTS uses a minimum phase delay constraint of 0.0 ns. SinkMaxTran number{ns|ps} Specifies the maximum input transition time constraint for sinks (clock pins). CTS does not allow you to specify a value greater than 10,000 ns. Default: If you do not use this statement, CTS uses a maximum sink transition time constraint of 400 ps. BufMaxTran number{ns|ps} Specifies the maximum input transition time constraint for buffers. CTS does not allow you to specify a value greater than 10,000 ns. Default: If you do not use this statement, CTS uses a maximum buffer transition time constraint of 400 ps. May 2005 340 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees MaxSkew number{ns|ps} Specifies the maximum skew between sinks (clock pins). Default: If you do not use this statement, CTS uses a maximum skew constraint of 300 ps. MaxFanout integer Limits the number of clock buffer fanouts to the number you specify. Use this statement if you have not already specified a timing library. If you use the MaxFanout statement and the setCTSMode -useLibMaxFanout command, CTS uses the smaller maximum fanout constraint. NoGating {rising | falling | NO} Sets the criteria for tracing through logic gates. Choose only one of the following: rising Stops tracing through a gate (including buffers and inverters) and treats the gate as a rising-edge-triggered flip-flop clock pin. falling Stops tracing through a gate (including buffers and inverters) and treats the gate as a falling-edge-triggered flip-flop clock pin. NO Allows CTS to trace through clock gating logic. Default: This is the default behavior for gated-clock designs. (If you omit the NoGating statement, CTS traces through clock gating logic. AddDriverCell driver_cell_name Places a driver cell name at the closest possible location to the clock port location for block-level CTS. MaxDepth number Sets the maximum depth of clock tree tracing. Default: If you do not use this statement, CTS limits the number of levels of clock tree tracing to 1024. May 2005 341 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees RouteType routeTypeName Specifies the name of the clock for which you are defining routing attributes. Note: CTS uses the RouteType statement only if you specify RouteClkNet YES. Note: If you use a RouteType statement, you must also use a corresponding RouteTypeName statement. DetailReport YES | NO Determines whether CTS provides a detailed report. The detailed report includes timing information for every component in the design. The non-detailed report contains only summary information for the design. Default: If you do not use this statement, CTS does not provide a detailed report. Obstruction YES | NO Specifies whether CTS should take design obstructions into account during flip-flop clustering. RouteClkNet YES | NO Specifies whether CTS routes clock nets. Default: If you do not use this statement, CTS does not route clock nets. In other words, the default behavior is as if you had specified RouteClkNet NO. PostOpt YES | NO Specifies whether CTS resizes buffers or inverters, refines placement, and corrects routing for signal and clock wires. Default: If you do not use this statement, CTS performs resizing, refined placement, and routing correction. In other words, the default behavior is as if you had specified PostOpt YES. When used together, the PostOpt and OptAddBuffer statements try to meet the trigger edge skew constraints as defined in the clock tree specification file. However, phase delay, buffer transition time, and sink transition times are not necessarily improved by using these two statements. Note: If you specify PostOpt NO, CTS does not resize gating components. If you specify PostOpt YES, CTS attempts to resize gating components, though it may not do so. May 2005 342 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees OptAddBuffer {YES | NO} Controls whether CTS adds buffers during optimization. Important The OptAddBuffer statement is effective only if you specify PostOpt YES. When used together, the PostOpt and OptAddBuffer statements try to meet the trigger edge skew constraints as defined in the clock tree specification file. However, phase delay, buffer transition time, and sink transition times are not necessarily improved by using these two statements. OptAddBufferLimit positive_integer Specifies the maximum number of buffers that CTS can add to a clock tree during optimization. The number you specify can be no smaller than 1. However, the higher the number you specify, the longer the runtime. Default: If you do not use this statement, CTS inserts no more than 50 buffers. PadBufAfterGate YES | FIRST | NO Controls whether CTS moves padding cells within a chain of gating cells. Padding cells are buffers (with a fanout of 1) that CTS has inserted before a gating cell in the clock tree. A chain of padding cells can contain one or more buffers that CTS has inserted. Gating cells are buffers that exist in a clock tree before you run CTS. A chain of gating cells can contain one or more preexisting buffers (each with a fanout of 1). The PadBufAfterGate statement helps CTS reduce the power used in a gated clock tree. Default: If you do not include this statement in the clock tree specification file, CTS behaves as if you had specified PadBufAfterGate NO. May 2005 343 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Instructs CTS to move padding cells from the input of the first gating cell in a chain to the output of the last gating cell in the chain. YES Padding cell chain and gating cell chain A B C Following PadBufAfterGate YES A B C Instructs CTS to move padding cells from the input of the first gating cell in a chain to the output of the first gating cell in a chain. FIRST Padding cell chain and gating cell chain A B C Following PadBufAfterGate FIRST A B C CTS does not move any cells to reduce power in a gated clock tree. NO AddSpareFF cellName number Specifies the maximum number of flip-flops to add to the lowest level of the clock tree. The inputs of the flip-flops are tied off and the outputs are left floating. Adding extra flip-flops during CTS ensures that if a spare flipflop needs to be connected at some later time (for example, by a metal-only ECO change), the existing clock network will not be disturbed. cellName May 2005 344 Represents the name of the flip-flop(s) to be inserted in the clock root. Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees number Represents the maximum number of flipflops to insert. You can specify 1 or more flipflops. Buffer cell1 cell2 cell3 … Specifies the names of buffer cells to use during automatic, gated CTS. Note: To turn on the buffer insertion mechanism during the optimization process, you must have these statements in your clock tree specification file: ■ PostOpt YES ■ OptAddBuffer YES DummyBuffer cell1 cell2 cell3 … Specifies the names of dummy buffer cells to use during the optimization process. Use this statement if you want CTS to use buffers other than those specified in the Buffer statement. (Buffers defined in the Buffer statement might be too large, or have an input capacitance value that is too small.) Note: To turn on the buffer insertion mechanism during the optimization process, you must have these statements in your clock tree specification file: ■ PostOpt YES ■ OptAddBuffer YES LeafPin + pinName rising | falling + … Marks the pin as a “leaf” pin for non-clock-type instances, stops tracing, and balances clock skew. Note: Use the LeafPin statement only with input pins. CTS ignores LeafPin statements that are associated with output pins. Choose one of the following: rising May 2005 345 CTS treats the pin as a rising-edge-triggered flip-flop clock pin. Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees falling CTS treats the pin as a falling-edgetriggered flip-flop clock pin. LeafPort + portName rising | falling + … Marks the port as a “leaf” port for non-clock-type instances, stops tracing, and balances clock skew. Choose one of the following: rising CTS treats the pin as a rising-edge-triggered flip-flop clock pin. falling CTS treats the pin as a falling-edgetriggered flip-flop clock pin. ExcludedPin + pinName + … Treats the pin as a non-leaf pin, and prevents tracing and skew analysis of the pin. ExcludedPort + portName + … Treats the port as a non-leaf port, and prevents tracing and skew analysis of the pin. ThroughPin + pinName + … Traces through the pin, even if the pin is a clock pin. ThroughPort + portName +… Traces through the port, even if the pin is a clock pin. PreservePin + inputPinName + … Preserves the netlist for the pin and pins below the pin in the clock tree. However, CTS considers any synchronized pins after the pin when computing skew. When you use this statement, CTS applies the ThroughPort statement to all ports with the same footprint as portName. CTS does so because it may resize the gates associated with these ports. MaxCap + bufferName1 capValue1{pf|ff} + bufferName2 capValue2{pf|ff} + … May 2005 346 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Specifies that a buffer should be inserted if the given capacitance value is exceeded. Default: If you do not specify maximum capacitance values in the clock tree specification file, CTS uses the maximum capacitance values in the timing library. bufferName Specifies the name of the buffer for which you specify a maximum capacitance value. capValue Specifies the maximum capacitance for the buffer, in picofarads (pF) or femtofarads (fF). ForceReconvergent YES | NO Controls whether CTS allows or prevents reconvergence conditions for individual clocks. ■ YES indicates that you want CTS to allow reconvergence on a particular clock. CTS synthesizes such clocks. ■ NO indicates that you do not want CTS to allow reconvergence on a particular clock. When CTS synthesizes such a clock, the software stops and issues a warning if a reconvergence condition is found for the clock. The following example illustrates how to specify different reconvergence conditions on clocks clk and clk2: AutoCTSRootPin clk … ForceReconvergent YES … END AutoCTSRootPin clk2 … ForceReconvergent NO … END Note: You can override any ForceReconvegent statement by specifying ckSynthesis -forceReconvergent. In this case, CTS always synthesizes clocks that have reconvergence conditions. Default: If you omit this statement from the clock tree specification file, CTS behaves as if you had specified ForceReconvergent NO. May 2005 347 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees ForceMaxCap YES | NO Increases the number of buffers to assure that the clock net has no maximum capacitance violations. GatingGrpInstances + instanceName instanceName … + instanceName instanceName … + … Instructs CTS to group instances. CTS will not insert buffers between the instances you specify. GatingGrpModule + moduleName + moduleName + … End May 2005 ■ Each line that begins with a + represents a group of instances. ■ Instances that you specify on the same line are in the same group. ■ Each instance list must include at least one gate and one latch. ■ You can specify no more than five instance on each line. ■ Each latch and gate you specify must be connected together. Instructs CTS to treat all the instances within a specified module as if you had included the module’s instances individually in a GatingGrpInstances statement. ■ Each line that begins with a + represents a module and its instances. ■ You can specify only one module on each line. ■ You can use the wildcards * and ?. Marks the end of an automated gated CTS section. 348 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees Log File Headings Given particular settings for the RouteClkNet and PostOpt statements, and for the reportClockTree command, the encounter.log file reports results in the following sections of the log file: Clock tree specification file statements Example clock tree text command sequences RouteClkNet NO ckSynthesis globalDetailRoute reportClkTree -clk clock Encounter log file section heading: Clock clockName plus— Pre-Route Timing Analysis RouteClkNet YES ckSynthesis Clk-Route-Only Timing Analysis globalDetailRoute reportClkTree -clk clock -clkRouteOnly RouteClkNet YES ckSynthesis globalDetailRoute PostOpt YES reportClkTree -clk Post-Route Timing Analysis clock -postRoute May 2005 349 Product Version 4.1.5 Encounter User Guide Synthesizing Clock Trees May 2005 350 Product Version 4.1.5 Encounter User Guide 13 Editing Wires ■ Overview on page 352 ■ Before You Begin on page 353 ■ Results on page 353 ■ Using Bindkeys for Wire Editing on page 353 ■ Moving Wires on page 355 ■ Adding Wires on page 356 ■ Cutting Shielding Wires on page 361 ■ Trimming Antennas on Selected Stripes on page 362 ■ Changing Wire Width on page 363 ■ Fixing Maximum Wire Width Violations on page 363 ■ Duplicating Wires on page 364 ■ Stretching Wires on page 364 ■ Changing Wire Layers on page 365 ■ Splitting and Merging Wires on page 365 ■ Adding Vias on page 366 ■ Changing Vias on page 366 ■ Reshaping Routes on page 367 ■ Controlling Cell Blockage Visibility on page 368 ■ Editing Wires with CCAR on page 369 ■ Running CCAR in Batch Mode on page 369 ■ Running CCAR in Interactive Mode on page 370 May 2005 351 Product Version 4.1.5 Encounter User Guide Editing Wires Overview You can customize the signal and power wires in your design interactively using the Edit Route form, the wire editing commands, and a combination of bindkeys and tool widgets. You can also change vias in the design. For signal wires you can perform the following actions: ■ Add wires ■ Cut wires ■ Move wires ■ Change the wire to another layer ■ Delete wires ■ Merge selected wires ■ Force wires to use specified widths ■ Add vias For power wires, you can perform all of the actions available for signal wires, as well as the following additional actions: ■ Trim selected wires ■ Split selected wires ■ Duplicate selected wires ■ Change wire width ■ Fix wires wider than the maximum width ■ Force wires associated with special nets to be created as signal wires ■ Change vias May 2005 352 Product Version 4.1.5 Encounter User Guide Editing Wires Before You Begin Before you can use the wire editing features, you must load the design into the current Encounter session. Results After you use the wire editing features and save the design, new and modified wires are updated in the database. Using Bindkeys for Wire Editing The Encounter software includes keyboard shortcuts (bindkeys) for use with the wire editing features. You type the bindkeys while the main Encounter window is active and the cursor is in the design display area. Some of these bindkeys provide additional functionality that is not available through the Edit Route form or the wire editing commands. Note: The Binding Key form contains a complete list of bindkeys. To display this form, select Design – Preferences from the Encounter menu, then click the Binding Key button on the Preferences form. Bindkeys Used to Open Forms or Change Modes e—Opens the Edit Route form or closes it if it is already open d—Opens the Select/Delete Route form or closes it if it is already open Note: Before you can use the e or d bindkey to close a form, you must click in the design display area. A—Enters add wire mode (equivalent to Add Wires icon) o—Enters the add via mode (equivalent to Add Via icon) m—Enters move wire mode (equivalent to Move Wires icon) X—Enters cut wire mode (equivalent to Cut Wires icon) s—Enters stretch wire mode (equivalent to Stretch Wires icon) a—Enters select mode (equivalent to Select icon) May 2005 353 Product Version 4.1.5 Encounter User Guide Editing Wires R—Enters non-connectivity-based move mode (equivalent to Move/Resize/Reshape icon) Bindkeys Used in Auto Query Mode Before using the following bindkeys, the Encounter software must be in Auto Query mode. Note: These bindkeys do not work while you are drawing a wire. n—Toggles to next object under cursor p—Toggles to previous object under cursor S—Populates the Edit Route form with net name, width, layers, and shape of highlighted (queried) wire or pin. The Nets field of the Select/Delete Routes form is also populated. Note: If the queried object is a pin, the layer and width information is set for both horizontal and vertical directions. If the queried object is a wire, the width information is set for both horizontal and vertical directions, but only one of the layers is set. That is, only the horizontal layer is set for a horizontal wire and only the vertical layer is set for vertical wires. The s bindkey does not populate the form with spacing information. Control-w—Deletes the queried segment or via. Bindkeys and Shortcuts Used in Add Wire Mode d—Changes the added wire to the layer below the current layer. u—Changes the added wire to the layer above the current layer. Control-w—Deletes the last segment created in the design area. This allows you to remove one segment of the route at a time. Esc—Removes the entire route. Number keys—Changes the added wire to a specific layer number. If you want the wire to be added to metal layer 1, use the 1 bindkey, use the 2 bindkey for metal layer 2, and so forth. Single-click—Ends the segment, allowing you to continue the route in either the same direction or the orthogonal direction. Double-click—Ends the route. May 2005 354 Product Version 4.1.5 Encounter User Guide Editing Wires Bindkeys Used in Stretch Wire Mode 1—Specifies that horizontal wires are stretched or reduced from the left and vertical wires are stretched or reduced from the bottom. 2—Specifies that horizontal wires are stretched or reduced from the right and vertical wires are stretched or reduced from the top. Bindkeys Used to Change Vias N—Changes the selected via to the next available via. P—Changes the selected via to the previous available via. For more information about using these bindkeys, see “Changing Vias” on page 366. Moving Wires You can use the mouse or the keyboard arrow keys (in conjunction with the Shift key) to move signal or power wires in the orthogonal direction. Using the Mouse to Move Wires To move a wire using the mouse, complete the following steps: 1. Click the Move Wires icon in the Tool Widgets area of the Encounter main window. The equivalent bindkey is m. 2. Click the wire to be moved. The selected wire is highlighted. 3. Move the cursor slightly within the selected wire. The cursor changes to a circle shape. 4. Click and release the mouse. The wire moves with the cursor in the orthogonal direction (up or down for a horizontal wire, left or right for a vertical wire). Wires connected to the moved wires stretch to maintain connectivity. 5. Click the mouse again to place the wire in the new location. May 2005 355 Product Version 4.1.5 Encounter User Guide Editing Wires Note: To cancel the move before you click the mouse, press the Esc key. The wire returns to its original location. Note: If you select the Snap to Track option, the wire automatically snaps to the appropriate routing track. Using Arrow Keys to Move Wires To move a wire using the arrow keys, complete the following steps: 1. Choose Route - Edit Route from the menu. The Edit Route form opens. The equivalent bindkey is e. 2. Click the Route tab. 3. Specify a value, in microns, in the Arrow increment field. This value defines the distance that the wire is to move each time you press an arrow key while holding the Shift key. You can specify either a positive or negative number. 4. Click the Move Wire icon in the Tool Widgets area of the Encounter main window. The equivalent bindkey is m. 5. Click the wire to be moved. The selected wire is highlighted. 6. Hold the Shift key, then press the up or down arrow key for a horizontal wire, or the left or right key for a vertical wire. The selected wire moves in the direction of the arrow. Adding Wires You can add one or more wires interactively to single or multiple nets. By default, the routing status for newly added signal wires is fixed. A fixed routing status means that the automated routing tools do not rip up and reroute preroutes. Signal wires that are edited using move, cut, and other editing commands maintain the routing status that was set prior to the operation. May 2005 356 Product Version 4.1.5 Encounter User Guide Editing Wires Adding a Wire for a Single Net To add a wire to a single net, complete the following steps: 1. Click the Add Wires icon. This places the Encounter software in add wire mode and the mouse icon changes to a pencil. In addition, Encounter is automatically placed in Auto Query mode, even if the Q icon below the design display area is not enabled. The equivalent bindkey is A. 2. If pins are not visible, use the Layers tab of the Color Preferences form to make pins visible. 3. Place the cursor over the pin or wire at the starting point for the wire to be drawn, and then type S while the cursor is in the design display window. This populates the Edit Route form with the net name, layer, and width information that is used in creating new wires. Note: If multiple objects exist at a particular point, use the n or p bindkey to cycle through the objects. 4. (Optional) Choose Route – Edit Route from the menu or use the e bindkey. The Edit Route form opens, and has been automatically populated with the net name, layers, and widths. The form is not populated with spacing information, which only applies while editing multiple nets. 5. (Optional) Click the Route tab on the Edit Route form and adjust the values in the Layer and Width fields. 6. (Optional) Click the Misc tab and select a shape from the pulldown menu. Note: Shapes are only defined for power wires. This value is ignored for signal wires. 7. Click the start point for the wire you want to add, then move the mouse to a new point. The wire is drawn interactively as you move the mouse. 8. (Optional) Click a new location to change the direction of the wire or continue in the same direction with a different segment. Note: If there is a layer change, a via is automatically created. 9. (Optional) Press a number key to change the layer of the wire being added. When the software is in add wire mode, number keys can be used as bindkeys, with the number indicating the layer number of the wire being drawn. For example, if you press May 2005 357 Product Version 4.1.5 Encounter User Guide Editing Wires the number 2, the segment is added to metal layer 2. Alternatively, you can use the u or d bindkeys to change the layer of the segment. The u bindkey changes the segment to the next higher layer and the d bindkey changes the segment to the next lower layer. 10. (Optional) Press the Backspace key to erase the most recently drawn segment. You can do this for as many segments as needed. 11. Double-click the mouse. The wire ends at the location of the cursor. Note: After double-clicking, you cannot use the Backspace key to erase segments that you drew. Instead, click the undo icon to remove the entire route, or use the Edit Delete form. Adding Wires for Multiple Nets To add parallel wires to multiple nets at the same time, complete the following steps: 1. Click the Add Wires icon. This places the Encounter software in add wire mode and the mouse icon changes to a pencil. 2. Choose Route – Edit Route from the menu. The Edit Route form opens. 3. Click the Nets tab on the Edit Route form and enter the net names into the Nets field. Note: You can also specify a file that contains a list of nets. See “Adding Wires that Automatically Extend to a Target” on page 359 for more information. 4. (Optional) Click the Route tab, then select horizontal and vertical layer names and specify width and spacing values. Note: To use different width or spacing values for different nets, use the Override tab. See “Using Override to Add Wire Groups with Multiple Widths and Spacing” on page 360 for more information. 5. (Optional) Specify a value in the Drawing wire field. This specifies which of the nets (specified in the Nets field) corresponds to the mouse pointer location. By default this value is 1, meaning the mouse position corresponds to the position of the left-most or bottom-most net of the group. May 2005 358 Product Version 4.1.5 Encounter User Guide Editing Wires For example, if the Nets field contains VSS VDD VDDA VSSA, the VSS net is the bottommost net for horizontal segments, and the left-most net for vertical segments. If the value in the Drawing wire field is set to 1, the mouse location corresponds to wires on the VSS net. 6. (Optional) Click the Misc tab and select a shape from the pulldown menu. Note: Shapes are only defined for power wires. This value is ignored for signal wires. 7. Click the start point for the wires you want to add, then move the mouse to a new point. The wires are drawn interactively as you move the mouse. 8. (Optional) Click a new location to change the direction of the wires or to continue in the same direction with a different segment. Note: If there is a layer change, a via is automatically created. 9. (Optional) Press the Backspace key to erase the most recently drawn set of segments. You can do this for as many sets of segments as needed. 10. Double-click the mouse. The wires end at the location of the cursor. Note: After double-clicking, you cannot use the Backspace key to erase segments that you drew. Instead, click the undo icon to remove the entire route, or use the Edit Delete form. Adding Wires that Automatically Extend to a Target To add wire groups to multiple nets that automatically extend to targets, complete the following steps: 1. Click the Add Wires icon. This places the Encounter software in add wire mode and the mouse icon changes to a pencil. 2. Choose Route – Edit Route from the menu. The Edit Route form opens. 3. Create a text file that contains the names of multiple nets. Make sure that each line in the file contains the name of one net, and that the nets are listed in the order in which you want to create the wire group. May 2005 359 Product Version 4.1.5 Encounter User Guide Editing Wires 4. Click the Nets tab on the Edit Route form. 5. Click the Read button. This opens the Select A File form. 6. Select the file you created in step 3, then click OK. The Nets field now contains the net names in the file. 7. Click the Route tab, then select horizontal and vertical layer names and specify width and spacing values. Note: To use different widths or spacing values for different nets, use the Override tab. See “Using Override to Add Wire Groups with Multiple Widths and Spacing” on page 360 for more information. 8. Click the Misc tab, and select the Extend Start Wires and Extend End Wires options. These options extend both ends of the wires until they connect to a target. 9. Click the point in the design display area where the left-most or bottom-most wire should start. Note: The start point does not have to be at a target. 10. Move the mouse horizontally or vertically. The wires are drawn interactively. 11. Double-click the mouse. The start and end points of the wire extend until they connected to a target. If no target is present, the wire does not extend. Using Override to Add Wire Groups with Multiple Widths and Spacing To add pairs of power and ground wires, where wires have different widths and spacing, complete the following steps: 1. Click the Add Wires icon. This places the Encounter software in add wire mode and the mouse icon changes to a pencil. 2. Choose Route – Edit Route from the menu. The Edit Route form opens. May 2005 360 Product Version 4.1.5 Encounter User Guide Editing Wires 3. Click the Nets tab on the Edit Route form and enter the net names into the Nets field. Note: You can also specify a file that contains a list of nets. See “Adding Wires that Automatically Extend to a Target” on page 359 for more information. 4. Click the Route tab, then select horizontal and vertical layer names and specify width and spacing values. 5. Click the Override tab and enter a set of width and spacing values for the nets that do not have default width and spacing values. For example, if you want wires for the third and fourth nets to have a wider width and larger spacing, specify the following values 3 6 4 4 6 The first line indicates the third net (3) has a width of 6 microns and that the spacing value between the third and fourth net is 4 microns. The second line indicates that the fourth net (4) has a width of 6 microns. Note: To specify a value of less than 1, you must include a 0 before the decimal point. For example, a value of .6 is not valid, and must be expressed as 0.6. 6. Click the point in the design display area where the left most stripe should start. Note: The start point does not have to be at a target. 7. Double-click the mouse. The wires end at the location of the cursor. Cutting Shielding Wires To cut shielding wires, complete the following steps: 1. Click the Cut Wires icon. The cursor changes to the shape of a scissors, indicating that the Encounter software is in cut wire mode. 2. Click the location at which you want to start cutting the shields. 3. Move the mouse so that the drawn line is touching or overlaps the wire orthogonally. 4. Click to complete the cut. 5. Use the w bindkey to enter select mode. May 2005 361 Product Version 4.1.5 Encounter User Guide Editing Wires The cursor changes to an arrow shape. 6. Click the piece of wire to be deleted. The selected piece of wire is highlighted. Note: If multiple objects exist at the location of the cursor, press the spacebar to toggle the selection between them. To select multiple objects, press the Shift key while clicking. 7. Use the D bindkey to delete the selected objects. Note: Wires can only be cut in the orthogonal direction. If you cut multiple wires, including wires in the same direction as the cut, the cut only affects wires in the orthogonal direction to the cut. Once cut, signal wire pieces maintain a 1/2 wire width extension, but power wires are not extended. Trimming Antennas on Selected Stripes If your completed power structure contains stripes in a mesh configuration, physical antennas might remain on some stripes. To trim antennas on selected stripes, complete the following steps: 1. Use the d bindkey to display the Select/Delete Routes form. 2. Choose Select from the Action pulldown menu. 3. (Optional) Click Nets, then specify one or more nets for the wires to be trimmed. 4. (Optional) Click Direction, then click H if only horizontal wires are to be trimmed, or click V if only vertical wires are to be trimmed. 5. Click Shapes, then select STRIPE. 6. Click Apply. The selected wires are highlighted in the design display area. 7. Use the T bindkey to trim the selected wires. The selected power wires are trimmed back to the last connection point and deselected. Note: Signal wires cannot be trimmed. May 2005 362 Product Version 4.1.5 Encounter User Guide Editing Wires Changing Wire Width After running power analysis, you might need to increase the width of some power stripes to alleviate any IR drop or EM issues. To increase the width of selected stripes, complete the following steps: 1. Make sure the software is in select mode (you can use the w bindkey), then click the wire segment to be widened. 2. Use the e bindkey. This displays the Edit Route form without placing the software in add wire mode. 3. Click the Route tab on the Edit Route form, and enter values in the Width fields. Specify a width value in the Horizontal section for horizontal wires and a width value in the Vertical section for vertical wires. 4. Use the W bindkey. This changes the width of the selected wire. Any via connected to that the wire is also updated based upon the new width. Note: Widths for signal wires depend on the applicable LEF rule, no matter what value is populated in the GUI. To specify a wire width that is different from the default wire width value, select both Force Special or a value other than DEFAULT from the Rule pulldown menu. Fixing Maximum Wire Width Violations Violations occur if you specify wires widths greater than the maximum width defined by the maxWidth rule in the LEF file. To fix these violations, complete the following steps: 1. Use the e bindkey. This displays the Edit Route form without placing the software in add wire mode. 2. Click the icon Fix wires wider than max width. This executes the editFixWideWires command, which finds any wires violating the maxWidth rule, and splits up both the wires and the associated vias as minimally as possible while maintaining the same footprint. May 2005 363 Product Version 4.1.5 Encounter User Guide Editing Wires Duplicating Wires After running power analysis, you might need to add some power stripes to alleviate any IR drop or EM issues. Instead of creating new wires interactively, you can duplicate existing wires. 1. Make sure the software is in select mode (you can use the a bindkey), then click the wire segment to duplicate. 2. Use the e bindkey. This displays the Edit Route form without placing the software in add wire mode. 3. Click the Route tab on the Edit Route form and specify the vertical and horizontal layers for the duplicated wires. Note: The widths of the duplicated wires are always the same as the original wires, but the layers are the ones specified in the form. 4. Click the icon Duplicate selected wires or use the c bindkey. The duplicated wires are automatically selected and placed directly on top of the original wires. 5. Use the m bindkey. This places the software in move mode, allowing you to use the mouse or the arrow keys (while holding down the Shift key) to move the newly created wires to the desired location. Stretching Wires To stretch a wire, complete the following steps: 1. Click the Select icon in the Tool Widgets area of the Encounter main window. The cursor shape is an arrow, indicating that Encounter software is in select mode. The equivalent bindkey is w. 2. Click the wire to be stretched. The selected wire is highlighted. 3. Click the Stretch Wire icon in the Tool Widgets area of the Encounter main window. The equivalent bindkey is t. May 2005 364 Product Version 4.1.5 Encounter User Guide Editing Wires 4. Move the cursor to the end point of the wire to be stretched. The cursor changes to a T shape. 5. Click the end point, then release the mouse button and move the cursor to a new location and click again. The wire stretches to the new location. Alternatively, you can use the Shift key in conjunction with the arrow keys to stretch or shrink the wire. When the software is in Stretch Wire mode, you can use 1 and 2 as bindkeys to set the edge of the wire to be stretched. By default, the wire is stretched from the top or the right. To stretch the wire from the bottom or the left, use the 1 bindkey. The Stretch Wires icon reverses so that the outer arrow points to the left. To return to stretching wires from the top or right, use the 2 bindkey. The arrows on the Stretch Wires icon change so that the outer arrow points to the right. Changing Wire Layers You may need to change sections of wires to different layers in order to relieve congestion on a specific layer or to fix process antenna violations. To change a wire to another layer, complete the following steps: 1. Make sure the software is in select mode (you can use the w bindkey), then click the wire segment to be updated. 2. Use the e bindkey. This displays the Edit Route form without placing the software in add wire mode. 3. Click the Route tab on the Edit Route form, and enter values in the Layer fields. Specify a layer value in the Horizontal section for horizontal wires and a layer value in the Vertical section for vertical wires. 4. Use the L bindkey. This changes the layer of the selected wire. Any via connected to that wire is also updated based on the new layer. Splitting and Merging Wires Stripes that spread over the entire die may need to be altered in specific locations. In this case, a stripe that is represented as a single piece of wire must be split into multiple segments. You can use the split command to automatically cut stripes at each crossover: May 2005 365 Product Version 4.1.5 Encounter User Guide Editing Wires 1. Make sure the software is in select mode (you can use the w bindkey), then click the wire segment to be split. 2. Use the Control-s bindkey. This automatically splits the single wire segment into multiple segments at points connected to other wires. After splitting a wire, you can merge those wire segments that align back into a single segment. To merge aligned wire segments, complete the following steps: 1. Select a single segment. 2. Use the M bindkey. This merges the wire segments into a single segment. Adding Vias You can add a via of any configuration to the design. To add a via, complete the following steps: 1. Select the Add Via icon. The equivalent bindkey is o. 2. Press the F3 key. This displays the Edit Via form. 3. Select Geometry in the Create Via by field. 4. Fill all of the fields in the form. For more information, see Edit Via in the Encounter Menu Reference. 5. Move the cursor to the location to which the via is to be added, then click the mouse. A via with the exact configuration specified in the Edit Via form is added at that location. Changing Vias To replace a selected via with another via in the design that has the same LEF rule, complete the following steps: 1. Make sure that Encounter is in Auto Query mode and that the main window is active. 2. Place the cursor above the via to be changed May 2005 366 Product Version 4.1.5 Encounter User Guide Editing Wires 3. Press the n or p bindkey to select the correct via if multiple vias exist in the same location on different layers. 4. Without moving the mouse, press the N (next) or P (previous) bindkey to display a via that has the same LEF rule as the selected via. ❑ If a via is available, the display is updated with the new via when you press the bindkey. ❑ If another via is not available, you will hear a warning beep when you press the bindkey. This can occur when only one via is defined in the LEF file, when the currently queried object is not a via, or when no object is currently queried. Limitations ■ The Edit Route form does not provide access to this feature. ■ You can only change one via at a time using the bindkeys. To change multiple vias at the same time, use the editChangeVia text command. ■ You can edit vias for power wires using the Edit Power Vias form. For more information, see Edit Power Vias in the Encounter Menu Reference. Reshaping Routes You can specify that wires at the corner of a route are to be trimmed after adding wires within an area that makes the existing corner wires obsolete. In addition, if you add a wire that circumvents an existing path, the existing route is trimmed after the new wires are added. To reshape the route, complete the following steps: 1. Click the Add Wires icon. This places the Encounter software in add wire mode and the mouse icon changes to a pencil. In addition, Encounter is automatically placed in Auto Query mode. The equivalent bindkey is A. 2. Select the Edit Route form from the Route menu and click the Misc tab. The equivalent bindkey is e. 3. Select the Reshape option on the form. 4. Add wires to the design, as described in “Adding Wires” on page 356. May 2005 367 Product Version 4.1.5 Encounter User Guide Editing Wires The following illustrations show the results of using this option: Existing wires Unwanted corner segments Corner segments removed Newly added wires Existing wires Unwanted corner segments Corner segments removed Newly added wires Existing wire Unwanted segment Unwanted segment removed Newly added wires Controlling Cell Blockage Visibility If you see a spacing violation when adding or editing a via or wire, it might be caused by a cell blockage that is not currently visible. May 2005 368 Product Version 4.1.5 Encounter User Guide Editing Wires To see any cell blockages, select the Cell Blkg option on the Routing color control display (click the slidebar to display this option). Alternatively, you can click the All Colors button to display the Color Preferences form, then select the Cell Blockage visibility option. By default, this option is deselected. In addition, depending on whether the blockage is outside or inside a cell, you must do one of the following: ■ Cell blockages outside a cell are visible by default. To control the visibility of these blockages for particular layers, click the Wire Layers tab of the Color Preferences form. Use the buttons in the fifth column, Blkg, to deselect the visibility of blockages for particular layers. By default, all layers are selected. ■ Cell blockages within a cell are not visible by default. To see these cell blockages, click the Wire Layers tab of the Color Preferences form, then use the buttons in the sixth column, V Blkg, to select the visibility of blockages for each cut layer that you want to see. By default, all layers are deselected. Editing Wires with CCAR You can use the Cadence Chip Assembly Router (CCAR) environment to route specified nets of a design created in Encounter. You can also reroute nets to fix violations. CCAR Interface can be used at any stage in the design process after placement. Trial route data is ignored in the CCAR environment. Power routing should be done before you edit using CCAR. For more information about the CCAR environment, see the IC Shape-Based Technology Chip Assembly User Guide. Before you can use the CCAR Interface form, the UNIX path variable must have access to both Encounter and CCAR executables. After using the CCAR Interface software, your design contains all routes that were present before using CCAR as well as the new and updated routes that were added within the CCAR environment. You can use CCAR either in batch or interactive mode. Running CCAR in Batch Mode When you run CCAR in batch mode, the software automatically performs the actions specified in the .do file. To run CCAR in batch mode, complete the following steps: 1. Select CCAR Interface from the Route menu. This opens the CCAR Interface form. 2. Specify the nets to be routed. May 2005 369 Product Version 4.1.5 Encounter User Guide Editing Wires 3. Specify a CCAR .do file. Note: If you do not specify a .do file, the software automatically generates a default .do file. The following statements are in the default .do file: set rotate_via off groute 4 route 25 protect all wires save_oa export quit If you create your own .do file, you should include the following statements: set rotate_via off protect all wires 4. Select Batch as the Operation Mode. 5. Specify all additional options on the CCAR Interface form. 6. Click OK or Apply. The CCAR GUI does not display, but the design within Encounter contains the changes to the nets that were specified in the .do file. Running CCAR in Interactive Mode When you run CCAR in interactive mode, your design is transferred from the Encounter environment into the CCAR environment, where you can use the CCAR editing features. This mode is asynchronous, and does not wait for CCAR to complete. To run CCAR in interactive mode, complete the following steps: 1. Select Route – CCAR Interface from the menu. This opens the CCAR Interface form. 2. Specify the nets to be routed in CCAR. 3. (Optional) Select Specify Route Area, then click the Mouse icon. 4. Select Interactive as the Operation Mode. 5. Specify all additional options on the CCAR Interface form. 6. Click OK or Apply. The CCAR GUI displays the design that you transferred from the Encounter environment. May 2005 370 Product Version 4.1.5 Encounter User Guide Editing Wires 7. After you use the CCAR editing features, choose File – Save or File – Save As from the CCAR menu. 8. Choose Design – Load – OA Database from the Encounter menu. This opens the Load OA Database form, which you can use to import the design as an Open Access design. The equivalent text command is oaIn. The updated design is displayed in the Encounter environment. May 2005 371 Product Version 4.1.5 Encounter User Guide Editing Wires May 2005 372 Product Version 4.1.5 Encounter User Guide 14 Using Trial Route for Congestion and Timing Analysis This chapter describes how to use Trial Route to perform quick routing for congestion analysis and parasitics estimation. This chapter presents the following topics: ■ Overview on page 374 ■ Data Preparation on page 374 ■ Routing A Flat Design on page 375 ■ Routing a Partitioned Design on page 375 ■ Loading and Saving Route Data on page 378 ■ Analyzing Route Data on page 378 ■ Improving Route Congestion on page 387 ■ Additional Information on page 388 May 2005 373 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis Overview Trial Route performs quick global and detailed routing for estimating routing-related congestion and capacitance values. It also incorporates any changes made during placement, such as scan reorder. If you specify a routing guide file, Trial Route divides the design into routing regions and routes within these regions. You can use Trial Route results to estimate and view routing congestion, and to estimate parasitic values for optimization and timing analysis. When used during prototyping, Trial Route creates actual wires, so you can get a good representation of RC and coupling for timing optimization at an early stage in the flow. Trial Route also produces a congestion map you can view to get early feedback on whether the design is routable. Trial Route results can also be used for pin assignment when you commit partitions. Note: Trial Route does not guarantee DRC-clean routing results. Do not perform signal integrity analysis on a design that has been routed using Trial Route, because the routes are only used to estimate parasitic values for timing analysis. Route designs with NanoRoute or WRoute, if you want to perform signal integrity analysis. You can use Trial Route during virtual prototyping, hierarchical floorplanning, block implementation, and top-level implementation. Data Preparation Before you can use Trial Route, the following conditions must be met: ■ The design must be successfully placed. Important If you make any changes after running Trial Route that affect the placement data— for example, floorplan changes—you must run placement before rerunning Trial Route. ■ The design must be loaded into the current Encounter session. The following optional input files are only required as necessary: ■ DEF file ■ Top Design Format (TDF) file containing routing data ■ Routing guide file May 2005 374 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis Routing A Flat Design ■ Initial Design Routing Run Trial Route for the first time to gauge the routability of the design. You can then examine the congestion map and congestion distribution report to identify congested areas that might cause routing problems later in the design session. a. Choose Route – Trial Route. This opens the Trial Route Form. b. Select the Prototyping effort level and click OK. You can also issue the following command: trialRoute -floorplan The prototyping (-floorplan) mode runs Trial Route quickly, which is important when prototyping large designs. However, note that components in your design might not be routed at legal locations. ■ Post Clock Tree Synthesis Routing Run Trial Route after clock-tree synthesis to recheck the routing congestion and to estimate parasitic values for timing analysis. a. Choose Route – Trial Route. b. Select the Medium Effort (default) or High Effort effort level on the Trial Route form. c. (Optional) Select the Use Routing Guide option, and specify the name of a guide file in the corresponding field. Trial Route follows the routing regions defined in the guide file and honors the specified pre-routed nets. d. Click OK. Alternatively, you can issue the following command: trialRoute -highEffort -guide my_chip.rguide Routing a Partitioned Design In a flat design, Trial Route can route through guides, regions, and fences, as long as there are no routing blockages or hard blocks. However, fences are often defined as partitions, which become blocks after the design becomes hierarchical. Once partitions become blocks, May 2005 375 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis the routes are no longer allowed, unless they use a proper feedthrough mechanism, such as inserted buffers or routing feedthroughs. In channel-based routing designs, all top-level routing use channels to route around partitions. In a partitioned design in which the partitions have not been committed, you can use the Trial Route -handlePartition and -handlePartitionComplex parameters to force the routing into channels, simulating a channel-based design. ➤ Issue one of the following commands: trialRoute -highEffort -handlePartition or tiralRoute -highEffort -handlePartitionComplex Use the -handlePartition parameter to route nets that are only connected within partitions. Use the -handlePartitionComplex to route nets that belong to more than one partition, so that the routing does not violate partition boundaries. When the -handlePartition or -handlePartitionComplex parameter is specified, Trial Route works in three phases: ■ Phase 1 – Routes the top-level connections ■ Phase 2 – Routes net connections within partitions ■ Phase 3 – Routes net connections between partitions May 2005 376 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis Figure 14-1 P1 Phase 1 – Route top-level connections Phase 2 – Route net connections within partitions P2 Phase 3 – Route net connections between partitions P3 P4 For example, the design in Figure 14-1 on page 377 has five metal layers, a top-level partition and four flattened partitions: P1, P2, P3, and P4. P1 reserves the metal1, metal2, and metal3 layers for partitions, and P2, P3, and P4 reserve layers metal1 through metal5 for partitions. If you specify -handlePartition or -handlePartitionComplex, Trial Route performs the following tasks to route the net connections: 1. Trial Route applies all of the metal blockages defined for each partition. The layers metal1, metal2, and metal3 are blocked for P1, and metal1 through metal5 are blocked for the other partitions. 2. Trial Route then routes nets connecting only at the top level. No connections to partitions or cells within the partitions are made. 3. Trial Route blocks all areas outside of the defined partitions on all routing layers. For P1, Trial Route applies a routing blockage for layers metal4 and metal5. 4. Trial Route routes all nets within P1, P2, P3, and P4 on the available routing layers. This means that even a cell at the lower-left corner of P2 that connects to a cell at the upperright corner of P2 is routed within P2, regardless of any congestion. May 2005 377 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis 5. Trial Route removes the routing blockages and routes the net connections between partitions. If an I/O at the top level connects to P2: ❑ If you specify -handlePartition, Trial Route uses all metal layers to route through P1. ❑ If you specify -handlePartitionComplex, Trial Route uses only layers metal4 and metal5 to route through P1. Loading and Saving Route Data After initially running the Trial Route program, you can load or save Trial Route data at any time during an Encounter session. ➤ To load route data using the Load Route File form, choose Design – Load – Route. ➤ To save route data using the Save Route File form, choose Design – Save – Route. Note: You can also save route data by selecting the Save Routing to option on the Trial Route form and specifying a filename. Analyzing Route Data After running Trial Route, you can analyze the results to check if your design is routable for back-end detailed routing tools. 1. Visually check the route congestion markers. The red diamond-shaped congestion markers should not be very dense in a local area. These markers contain an overflow value to identify the number of tracks required for that grid, and the actual number of tracks available. See “Congestion Markers in the Display” on page 379 for more information. 2. In the log file, inspect the Trial Route contents in the congestion distribution table. Ensure the last routing overflow percent values do not exceed 1.0 percent for both horizontal (H) and vertical (V) tracks. For a design that uses five or more layers of metal interconnect, the 1.0 percent limit is optimal. For a design that uses three layers of metal interconnect, a 0.5 percent limit is optimal. See “Congestion Distribution Report” on page 381 for more information. May 2005 378 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis When these two tests are satisfactory, the design is routable by a detail router. Congestion Markers in the Display You can visually check the Trial Route congestion statistics in the design display area of the main Encounter window to identify the tight clusters of congestion markers. Check the design display area to make sure there are no markers grouped closely together. These usually occur around blocks or between large blocks. The indicators are diamond shaped and red by default. Zoom into the area to display the vertical and horizontal congestion overflow value, as shown in the following figure. Zoom in V=35/20 H=26/26 Congestion Marker Horizontal (H) and Vertical (V) Congestion Overflow Value BLOCK Congestion markers contain a vertical and horizontal overflow value to identify the number of tracks required for that grid, and the actual number of tracks available. For example, in the above illustration, the vertical (V) overflow is 35/20, which indicates that of the 35 tracks that are required for the vertical tracks, only 20 are available. Congestion marker values are based on a unit of 10 adjacent gcells. That is, for each gcell row, 10 gcells are grouped together as a “super gcell.” The vertical and horizontal overflow values shown in congestion markers are calculated differently. For vertical overflow, the required track value is calculated by totalling the number of required tracks in the super gcell. That is, the value is the sum of the number of required tracks in all 10 of the adjacent gcells that form the super gcell. The vertical available track value is calculated by totalling the number of available tracks in the super gcell. This form of calculation typically results in large vertical values. For horizontal overflow, the required track value is calculated by averaging the number of required tracks in the super gcell. That is, the value is the average of the total number of required tracks in the 10 adjacent gcells that form the super gcell. The horizontal available May 2005 379 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis track value is calculated by averaging the number of available tracks in the super gcell. This form of calculation can result in non-integer horizontal values. Note: Congestion markers can display different congestion information than that contained in the congestion distribution report. The information in the congestion distribution report is based on the congestion of each gcell instead of the super gcells. To change the size of super gcells, define the following variable: set rdaSuperGcellSize n The value you specify for n must be greater than or equal to 0 and less than or equal to 10. If you specify a value of 1, a super gcell becomes a regular gcell, and the displayed congestion marker information matches the congestion information provided in the report. If you specify a value of 0, the super gcells become square. Congestion Marker Color Boxes By specifying the HCongest and or VCongest colors in the Color panel, you can also add a color box to the congestion marker that indicates the severity of the overflow level (that is, the number of overflow tracks in a one-unit area). Usually, a one-unit area contains 10 global cells (gcells) horizontally. If there are 50 vertical tracks available in that area, and Trial Route requires 51 vertical tracks, the congestion marker color box is blue (by default), indicating a one-track overflow. If Trial Route requires 52 vertical tracks, the congestion marker color box is green (by default), indicating a two-track overflow. An example of this is shown in the following figure. V=51/50 H=26/26 V=52/50 H=26/26 The following table shows the default congestion marker colors and their corresponding overflow values: Level Color Overflow Value level 1 Blue 1 (One more track required) level 2 Green 2 (Two more tracks required) level 3 Yellow 3 (Three more tracks required) May 2005 380 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis Level Color Overflow Value level 4 Red 4 (Four more tracks required) level 5 Magenta 5 (Five more tracks required) level 6 and higher Grey to white 6 or greater (Six or more tracks required) For more information, see “Multicolor Layers.” Congestion Distribution Report After Trial Route completes, a congestion distribution report is created in the Encounter log file. The congestion distribution report provides usage and routing overflow percent values, as well as gcell overflow information (that is, the internal supply and demand for each gcell). There are two types of congestion distribution reports that can be generated: a default congestion distribution report; and a detailed congestion distribution report. Note: The congestion information contained in the congestion distribution report can differ from the congestion information displayed in congestion markers in the Encounter window. For more information, see “Congestion Markers in the Display” on page 379. Default Congestion Distribution Report By default, Trial Route generates a congestion distribution report that summarizes congestion information for the entire chip. Usage and Routing Overflow The following example illustrates the section of the congestion distribution report that summarizes the usage and routing overflow percent values: Phase 1f route (0:00:02.0 105.9M): Usage: (24.2%H 35.8%V) = (8.695e+06um 1.314e+07um) = (1734514 486668) OvInObst: 21 = 21/5777 (0.4% H) + 0/1587 (0.00% V) Overflow: 192 = 1 (0.0% H) + 191 (0.07% V) The Usage statement summarizes horizontal and vertical tracks used in gcells. In the above example, there are 1,734,514 horizontal tracks used in all gcells, and 486,668 vertical tracks used. Of the available horizontal tracks, 24.2 percent were used for horizontal routing (that is, wires), and 35.8 percent were used for vertical routing. The total horizontal wire length used equals 8.65e+06 µm, and the total vertical wire length used equals 1.314e+07 µm. May 2005 381 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis The OvInObst statement summarizes obstructed gcell information. In the example, there are 5,777 horizontally obstructed gcells (where there are no available tracks). The approximate number of wires over horizontally obstructed gcells equals 21/5,777. The Overflow statement summarizes all overflowed gcells. In the example, there is one horizontally overflowed gcell, and 191 vertically overflowed gcells. Gcell Overflow The following example illustrates the section of the congestion distribution report that summarizes gcell overflow information. A gcell has overflow if its demand exceeds its supply. Supply is the available routing resource, and demand is the amount of routing resource assigned to the gcell. Typically, the supply is the number of unobstructed tracks crossing the gcell, and the demand is the number of wires assigned to it. Remain cntH cntV ---------------------------------------------6: 0 0.00% 1 0.00% -5: 2 0.00% 0 0.00% -3: 10 0.00% 26 0.00% -2: 510 0.03% 830 0.05% -1: 8100 0.47% 17618 1.05% ---------------------------------------------0: 78504 4.59% 178501 10.63% 1: 102934 6.02% 214588 12.78% 2: 76165 4.46% 185168 11.03% 3: 72832 4.26% 179080 10.67% 4: 81555 4.77% 180443 10.75% 5: 92704 5.42% 158498 9.44% 6: 106167 6.21% 137707 8.20% May 2005 382 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis The following table defines the columns in the congestion report: Column Definition Remain The track supply minus the track demand. cntH When Remain is positive, the number and percentage of gcells where the horizontal track supply exceeds the horizontal track demand. When Remain is negative, the number and percentage of gcells where the horizontal track demand exceeds the horizontal track supply. When Remain is 0 (zero), the number and percentage of gcells where the horizontal track demand is equal to the horizontal track supply. cntV When Remain is positive, the number and percentage of gcells where the vertical track supply exceeds the vertical track demand. When Remain is negative, the number and percentage of gcells where the vertical track demand exceeds the vertical track supply. When Remain is 0 (zero), the number and percentage of gcells where the vertical track demand is equal to the vertical track supply. The following line from the example shows that there are 8,100 gcells (.47 percent of the total number of gcells) where the demand exceeds the supply by one track in the horizontal direction, and 17,618 gcells (1.05 percent of the total number of gcells) where the demand exceeds the supply by one track in the vertical direction: -1: 8100 0.47% 17618 1.05% The following line shows that there are 78,504 gcells where the track supply is equal to the track demand in the horizontal direction, and 178,501 gcells where the track supply is equal to the track demand in the vertical direction: 0: 78504 4.59% 178501 10.63% Detailed Congestion Distribution Report You can create a detailed congestion distribution report that writes out information about sections of the chip. These sections can be either fixed quadrants defined by the middle horizontal and vertical lines, or user-defined sections specified by rows and columns. To create a report for quadrants, specify the -printSections parameter with the trialRoute or setTrialRouteMode commands. The report formats the information section-by-section, with each section containing congestion information for each layer in the section. May 2005 383 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis To create a report for user-defined sections, define the following two variables before running the trialRoute or setTrialRouteMode commands with the -printSections parameter: set trgNrSecRows number set trgNrSecCols number These variables define the number of equal-size sections into which to divide the chip when reporting the congestion information. For example, the following two variable definitions divide the chip area into 3 x 2 sections of equal size: set trgNrSecRows 2 set trgNrSecCols 3 The detailed congestion distribution report is divided into six categories of information for each section of the chip: ■ Virtual (global) wire length ■ Range of tracks in a gcell ■ Number of gcells with remaining tracks, including blocked gcells ■ Number of gcells with remaining tracks, excluding blocked gcells ■ Track usage in gcells ■ Real wire length These categories are described below. Virtual (global) wire length This section summarizes the number of tracks used, the estimated wire length, the percentage of overflow, and the percentage of blocked gcells for each layer. The following example illustrates this section of the congestion distribution report: ***Virtual M2: tracks overflow M3: tracks overflow M4: tracks overflow May 2005 wire length: used = 17.8% = 7754505/43513490 est wire length = 1.707e+07um = 0.0% (0.0%) = 369/13471232 blk = 65.5% used = 19.1% = 4452746/23334471 est wire length = 1.959e+07um = 0.0% (0.0%) = 515/13471232 blk = 65.1 used = 13.1 % =14991505/114837671 est wire length = 3.298e+07um = 0.0% (0.0%) = 237/13471232 blk = 0.4% 384 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis Range of tracks in a gcell This section summarizes the range of the number of tracks used in a gcell on each layer, and the average number of tracks used per gcell on the layer. The following example illustrates this section of the congestion distribution report: Range Range Range Range of of of of number number number number of of of of tracks tracks tracks tracks in in in in a a a a Gcell Gcell Gcell Gcell in in in in layer layer layer layer M2: M3: M4: M5: [5:10], avg: 3.2 [1:29], avg: 1.7 [1:29], avg: 8.5 [3:6], avg: 5.0 The first line of this example shows that there are between 5 and 10 tracks used in a gcell on layer metal2, and that the average number of tracks used in a gcell is 3.2. Number of gcells with remaining tracks, including blocked gcells This section summarizes the number of gcells, including blocked gcells, with remaining tracks (or the internal supply and demand for gcells) for each layer. A gcell has overflow if its demand exceeds its supply. Supply is the available routing resource, and demand is the amount of routing resource assigned to the gcell. Typically, the supply is the number of unobstructed tracks crossing the gcell, and the demand is the number of wires assigned to it. The following example illustrates this section of the congestion distribution report: Table for number of Gcells with remain tracks (includes blocked Gcells): Remain M2 M3 M4 M5 ... --------------------------------------------------------------------------6: 0 0.00% 0 0.00% 0 0.00% 0 0.00% -5: 0 0.00% 0 0.00% 0 0.00% 3 0.00% -4: 0 0.00% 0 0.00% 0 0.00% 5 0.00% -3: 0 0.00% 0 0.00% 0 0.00% 37 0.00% -2: 10 0.00% 28 0.00% 6 0.00% 264 0.00% -1: 355 0.00% 476 0.00% 229 0.00% 1254 0.01% --------------------------------------------------------------------------0: 8855290 65.73% 8858305 65.76% 70715 0.52% 127176 0.94% 1: 91903 0.68% 269941 2.00% 124321 0.92% 460099 3.42% 2: 166878 1.24% 441388 3.28% 192300 1.43% 1052688 7.81% 3: 250040 1.86% 559047 4.15% 347255 2.58% 1109275 8.23% 4: 319497 2.37% 734307 5.45% 738688 5.48% 2369132 17.59% The Remain column is the track supply minus the track demand. When this value is a positive number, it is the number and percentage of gcells where the track supply exceeds the track demand on each layer. When it is a negative number, it is the number and percentage of gcells where the track demand exceeds the track supply on each layer. When it is 0 (zero), it May 2005 385 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis is the number and percentage of gcells where the track demand is equal to the track supply on each layer. The following line from the example shows that there are 8,855,290 gcells (65.73 percent of the total number of gcells) where the track supply is equal to the track demand on layer metal2, and 8,858,305 gcells (65.76 percent of the total number of gcells) where the track supply is equal to the track demand on layer metal3. Remain M2 M3 M4 ... --------------------------------------------------------0: 8855290 65.73% 8858305 65.76% 70715 0.52% The following line from the example shows that there are 91,903 gcells (.68 percent of the total number of gcells) where the track supply exceeds the track demand on layer metal2, and 269,941 gcells where the track supply exceeds the track demand on layer metal3. Remain M2 M3 M4 ... --------------------------------------------------------1: 91903 0.68% 269941 2.00% 124321 0.92% Number of gcells with remaining tracks, excluding blocked gcells This section summarizes the number of gcells, excluding blocked gcells, with remaining tracks for each layer, and follows the same format as the table that reports the number of gcells with remaining tracks, including blocked gcells. The following example illustrates this section of the congestion distribution report: Table for number of Gcells with remain tracks (excludes blocked Gcells): Remain M2 M3 M4 M5 ... --------------------------------------------------------------------------6: 0 0.00% 0 0.00% 0 0.00% 0 0.00% -5: 0 0.00% 0 0.00% 0 0.00% 3 0.00% -4: 0 0.00% 0 0.00% 0 0.00% 5 0.00% -3: 0 0.00% 0 0.00% 0 0.00% 37 0.00% -2: 10 0.00% 28 0.00% 6 0.00% 264 0.00% -1: 355 0.00% 476 0.00% 229 0.00% 1214 0.01% --------------------------------------------------------------------------0: 34536 0.74% 83715 1.78% 18240 0.14% 101470 0.75% 1: 91903 1.98% 269941 5.75% 124321 0.93% 460099 3.42% 2: 166878 3.59% 441388 9.40% 192300 1.43% 1052688 7.83% 3: 250040 5.38% 559047 11.90% 347255 2.59% 1109275 8.25% May 2005 386 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis Track usage in gcells This section summarizes the percentage of tracks used for routing per gcell for each layer. It also reports the average number of tracks used in a gcell on each layer. The following example illustrates this section of the congestion distribution report: Table for track usage in Gcells Usage(%) All M M2 M3 M4 M5 ... #Gcells avg trks: 3.2 1.7 8.5 5.0 --------------------------------------------------------------------0%-50% 97.31% 30.20% 29.25% 93.68% 88.09% 13108628 4068834 3940947 1260035 11866924 50%-60% 1.64% 0.33% 3.00% 1.81% 7.37% 221249 44376 404372 243607 9933345 60%-70% 0.78% 1.81% 0.08% 2.08% 0.16% 104771 243711 10795 279931 22125 70%-80% 0.24% 1.24% 1.85% 1.20% 3.34% 32323 166753 249401 161193 450375 80%-90% 0.03% 0.68% 0.05% 0.71% 0.07% 3796 91903 6908 95516 9724 The fourth line from this example shows that 70 percent to 80 percent of the tracks in 1.24 percent of the gcells (out of a total of 166753 gcells) on layer metal2 are used. Real wire length This section summarizes the total real wire length used and number of vias for each layer in the section. The following example illustrates this section of the congestion distribution report: ***Real Wire Length: Total: 1.396e+08um, total number of M1(V): 9.076e+04um M2(H): 1.490e+07um, number of M1/M2 M3(V): 1.652e+07um, number of M2/M3 M4(H): 3.241e+07um, number of M3/M4 M5(V): 4.233e+07um, number of M4/M5 M6(H): 2.492e+07um, number of M5/M6 M7(V): 5.399e+06um, number of M6/M7 M8(H): 3.013e+06um, number of M7/M8 vias: 3547270 vias: vias: vias: vias: vias: vias: vias: 1560437 1273925 360881 242047 75288 26668 8034 Improving Route Congestion For a module or submodule that has route congestion, complete one of the following actions to improve congestion, depending on the type and severity of the violation: May 2005 387 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis 1. Change the block pin orientation. Route congestion usually occurs around blocks that have their pins facing incorrectly. You can identify these blocks by clicking on them in the design display area to see where the flight lines terminate. When the block pins are visible, you can rotate or flip the block(s) to alleviate the congestion. For information on changing block orientation, see “Flip/Rotate Instances.” 2. Add density screens. You can use density screens to control standard cell placement density in certain areas where there is high routing congestion. Use the Add Density Screens tool to create a screen over the highly congested area. Congestion is more severe if it spans between two blocked areas, as illustrated in the following figure. Congestion Area Block 1 Block 2 This figure represents a vertically congested area between two blocks that are placed close to one another. This routing bottleneck is more severe than local congestion. Assigning a density screen alleviates this congested area. For information on adding density screens, see Add Partial Placement Blockage under in the Floorplan Widgets section of “Tool Widgets.” Additional Information Wire Overlap In certain situations, wire overlap can occur when using Trial Route. A wire can overlap a routing blockage boundary if the blockage only partially covers the gcell. The covered tracks are counted as blocked tracks that are not available during global routing. However, Trial Route does not record the exact track location, which can result in wires being placed on a track which is already occupied by a routing blockage. May 2005 388 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis When using nondefault rules, wire width and space are considered during the global routing phase for congestion calculation, before track assignment. Because they are not considered during track assignment, overlapping nondefault wires can occur. However, because spacing was considered during congestion calculation, the routing congestion information is correct. May 2005 389 Product Version 4.1.5 Encounter User Guide Using Trial Route for Congestion and Timing Analysis May 2005 390 Product Version 4.1.5 Encounter User Guide 15 Routing Your Design With NanoRoute ■ NanoRoute Technology on page 394 ❑ Routing Phases on page 394 ■ NanoRoute in the Encounter Flow on page 396 ■ Before You Begin on page 397 ❑ Checking Your LEF File on page 397 ❑ Checking for Problems with Cells, Pins, and Vias on page 397 ❑ Generating Tracks on page 398 ■ Results on page 398 ■ NanoRoute Use Models on page 401 ■ ❑ Running NanoRoute in Native Mode with Encounter Menu Commands and Forms on page 401 ❑ Running NanoRoute in Native Mode with Encounter Text Commands on page 401 ❑ Running NanoRoute in Batch Mode From Encounter Software on page 402 ❑ Running NanoRoute in Standalone Mode on page 403 Using NanoRoute Parameters on page 404 ❑ ■ Using Attributes and Options Together on page 405 Accelerating Routing with Multi-Threading and Super-Threading on page 407 ❑ When to Accelerate Routing on page 407 ❑ Running Super-Threading on page 408 ❑ License Considerations for Super-Threading on page 409 ❑ Super-Threading Log File Excerpts on page 411 May 2005 391 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ❑ ■ ■ Following a Basic Routing Strategy on page 413 ❑ Using the Encounter Text Commands on page 413 ❑ Using the Encounter GUI on page 414 Checking Congestion on page 417 ❑ ■ ■ ■ ■ Interpreting the Congestion Map on page 419 Running Timing-Driven Routing on page 422 ❑ Input Files on page 422 ❑ Using the CTE and Native NanoRoute on page 422 ❑ Using the CTE and Standalone NanoRoute on page 423 ❑ Using the NanoRoute Timing Engine on page 425 ❑ Using Another Timing Engine on page 426 Routing Clocks on page 427 ❑ Setting Attributes for Clock Nets on page 427 ❑ Routing the Clock Nets on page 428 ❑ Running Postroute Optimization on page 428 Preventing and Repairing Crosstalk Problems on page 429 ❑ ■ Route Acceleration Options on page 412 Crosstalk Prevention Options on page 431 Running ECO Routing on page 433 ❑ ECO Limitations on page 433 ❑ ECO Routing in Batch Mode on page 434 ❑ NanoRoute ECO Flow on page 434 Evaluating Violations on page 435 ❑ Violations on Upper Metal Layers on page 439 ❑ Violations in Timing-Driven Routing on page 441 ❑ Deleting Violated Nets on page 442 ❑ Using Additional Strategies to Repair Violations on page 442 May 2005 392 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ Optimizing Vias on page 443 ❑ ■ ■ Performing Shielded Routing on page 445 ❑ Performing Shielded Routing Using the GUI on page 445 ❑ Text Command Examples on page 447 ❑ About the Shielding Statistics Report on page 447 ❑ NanoRoute Shielding Option on page 449 Routing Wide Wires on page 450 ❑ ■ Via Optimization Options on page 443 Using Nondefault Rules on page 450 Repairing Process Antenna Violations on page 452 ❑ Changing Layers on page 452 ❑ Using Diodes on page 452 ❑ NanoRoute Antenna Options on page 454 ❑ Examples on page 454 ■ Using a Design Flow that Includes Astro or Apollo on page 456 ■ Troubleshooting on page 458 May 2005 393 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute NanoRoute Technology NanoRoute™ performs concurrent signal integrity, timing-driven, and manufacturing aware routing (SMART routing) of cell, block, or mixed cell and block level designs. NanoRoute is optimized for routing designs with the following features: ■ More than 300K instances or nets and at least five routing layers ■ 180 nanometer or smaller process technology ■ Signal integrity critical ■ Timing critical ■ Detailed-model (full-model) abstracts Note: WRoute is also included in the Encounter™ software. Your routing results might be better with WRoute when the technology is 180 nm or larger, and you have fewer than five routing layers and 300K instances. For information on using WRoute, see the Ultra Router Reference. Routing Phases Full routing consists of global and detailed routing. ECO routing consists of incremental global and detailed routing passes on a routed design. Global Routing During this phase, NanoRoute breaks the routing portion of the design into rectangles called global routing cells (gcells) and assigns the signal nets to the gcells. The global router attempts to find the shortest path through the gcells, but it does not make actual connections or assign nets to specific tracks within the gcells. It tries to avoid assigning more nets to a gcell than the gcell has tracks to accommodate. The detailed router uses the global routing paths as a routing plan. May 2005 394 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute The following figure represents a portion of a floorplanned design broken into nine gcells that are each 15 tracks wide by 15 tracks high. The shaded area represents a path chosen by the global router. gcell boundary track NanoRoute can generate a map of the gcells, called a congestion map, you can read to see the approximate number of nets assigned to the gcells. The congestion map uses colors to indicate whether there are too few, too many, or the correct number of nets assigned to the gcells. If NanoRoute assigns too many nets to a gcell, it marks the gcell as over-congested. You can also read the Congestion Analysis Table in the Encounter log file to learn the distribution and severity of the congestion after global routing. ■ For more information on gcells, see “GCell Grid” in the “DEF Syntax” chapter of the LEF/ DEF Language Reference. ■ For more information on the congestion map and table, see “Checking Congestion” on page 417. Detailed Routing During this phase, NanoRoute follows the global routing plan and lays down actual wires that connect the pins to their corresponding nets. The detailed router is less conservative than the global router—it creates shorts or spacing violations rather than leave unconnected nets. NanoRoute runs search-and-repair routing during detailed routing. During search and repair, it locates shorts and spacing violations and reroutes the areas to eliminate as many violations and shorts as possible. The primary goal of detailed routing is to complete all of the required interconnect without leaving shorts or spacing violations. During detailed routing, NanoRoute divides the routing portion of the design into areas called switch boxes (SBoxes), which align with the gcell boundaries. The SBoxes can be expressed May 2005 395 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute in terms of gcells; for example, a 5x5 SBox is an SBox that encompasses 25 gcells. The SBoxes overlap with each other, and their size and amount of overlap might vary during search-and-repair iterations. NanoRoute also runs postroute optimization as part of detailed routing. During postroute optimization, it runs more rigorous search and repair steps. Detailed routing stops automatically if it cannot make further progress on routing the design. The routed data is saved as part of the Encounter database. ECO Routing NanoRoute runs both global and detailed routing during ECO routing. NanoRoute makes minimal changes to the topology of fully routed nets during ECO routing. For more information, see “Running ECO Routing” on page 433. NanoRoute in the Encounter Flow NanoRoute is part of the block implementation and the top-level implementation stages of the Encounter flow. Cadence® recommends you run a global and detailed route with NanoRoute after each of the major routing steps in the design flow, check for localized and global congestion, and resolve any problems before going to the next step. Which major design steps? Run NanoRoute early in the design flow to identify and fix routability problems or avoid them altogether. You can run NanoRoute in non-timing-driven mode after the default parasitic extraction step to establish a baseline for future steps. If the design is congested or unroutable, stop and resolve problems before continuing. When do you run it first? What do you do after all problems are fixed? For information on the major routing steps, see “Following a Basic Routing Strategy” on page 413. May 2005 396 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Before You Begin NanoRoute reads designs directly from Encounter. Before running NanoRoute, ensure your design meeting the following conditions: ■ It is fully placed. ■ Power is routed. Checking Your LEF File You can avoid violations and save time if you ensure your LEF file is optimized for routing with NanoRoute. Check the following statements in your LEF file and edit the file with a text editor if necessary: ■ UNITS NanoRoute does not support a value of 100 for DATABASE MICRONS in the UNITS statement. If the LEF file specifies DATABASE MICRONS 100, issue the following command before you import the design: setImportMode -minDBUPerMicron 1000 For information on this command, see “ Import Commands” in the Encounter Text Command Reference. ■ MANUFACTURINGGRID NanoRoute requires that you define the manufacturing grid. ■ MACRO To improve pin access, ensure the following: ❑ All standard cell macros are defined as CLASS CORE. ❑ Other macros are defined as CLASS BLOCK or RING. For information on LEF, see the LEF/DEF Language Reference. Checking for Problems with Cells, Pins, and Vias In addition, check for the following problems: ■ Overlapping cells May 2005 397 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Cells that overlap make pins short each other and create violations on metal1. Check for overlaps using one of the following commands: ❑ verifyGeometry -wireOverlap For more information, see verifyGeometry in the Encounter Text Command Reference. ❑ checkPlace For more information, see checkPlace in the Encounter Text Command Reference. ■ Pins underneath power routes Pins that are underneath power routes are inaccessible and cause violations on metal1 and metal2. Check for pins underneath power routes using the Auto Query feature. For more information, see “Auto Query” in the Encounter Menu Reference. ■ Lack of rotated vias Rotated vias help reduce design rule violations by making pins accessible. NanoRoute does not rotate vias automatically and creates violations on metal1 when it cannot access the pins. Define rotated vias in the LEF file. See the Encounter Library Development Guide for information on defining rotated vias for NanoRoute. Generating Tracks In the Encounter environment, NanoRoute generates tracks automatically, based on the routing pitch, layer width and spacing, and minimum via widths. If you import a DEF file, run the generateTracks command prior to global routing to correct faulty track definitions and tune the tracks to routing. ■ For more information see generateTracks in the Encounter Text Command Reference. ■ For information on importing DEF files, see “Import and Export Commands” in the Encounter Text Command Reference. Results NanoRoute outputs can include the following (depending on the run-time options you set): May 2005 398 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ A section in the Encounter log file ■ A routed DEF file ■ A GDSII file ■ An SDF or SPEF file For information on outputting GDSII and DEF files, see “Importing and Exporting Designs” on page 77. For information on outputting an SDF or SPEF file, see “Timing Analysis” on page 531. ■ The following reports: ❑ Routing statistics For information, see the reportRoute command in “Route Commands” in the Encounter Text Command Reference. ❑ Routing connectivity For information, see the checkRoute command in “Route Commands” in the Encounter Text Command Reference. ❑ Wire statistics, including wirelength For information, see the reportWire command in “Route Commands” in the Encounter Text Command Reference. ❑ Shielding statistics For information, see “About the Shielding Statistics Report” on page 447. ❑ Timing analysis For information, see “Timing Analysis” on page 531. ❑ Capacitance For information, see “RC Extraction” on page 501. ❑ Design rule checking (DRC) and layout versus schematic (LVS) ❑ Process antenna violations For information on DRC and LVS checks and process antenna reports, see “Verifying Violations” on page 657. ❑ May 2005 Signal integrity 399 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute For information on signal integrity reports, see “Analyzing and Repairing Crosstalk” on page 625 May 2005 400 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute NanoRoute Use Models You can run NanoRoute within the Encounter environment or in standalone mode. In the Encounter software, you can run NanoRoute in native mode (using Encounter software commands and forms) or in batch mode. Running NanoRoute in Native Mode with Encounter Menu Commands and Forms NanoRoute can perform all basic functions using Encounter forms. The forms are accessed from the Encounter Route menu. They are: ■ NanoRoute/Attributes Use this form to set attributes for nets. ■ NanoRoute Use this form to set run-time options for NanoRoute. You access the Edit Super Threading Clients form from the NanoRoute form. For more information on using the NanoRoute forms, see “Route Menu” in the Encounter Menu Command Reference. Running NanoRoute in Native Mode with Encounter Text Commands Within the Encounter products, the following commands set NanoRoute attributes and options, and run global and detailed routing with NanoRoute: ■ generateTracks Generates optimized tracks for NanoRoute (only necessary if you import a non-native DEF) file. ■ generateLef Generates an optimized LEF file (only necessary if you import a non-native or noncurrent LEF file). ■ getAttribute setAttribute Display and set the current net attributes. May 2005 401 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ getNanoRouteMode setNanoRouteMode Display and set the current run-time options. ■ globalRoute detailRoute globalDetailRoute globalDetailRouteBatch Route the design. The text commands include some options that are not included on the forms. For more information on the commands and options, see “Route Commands” in the Encounter Text Command Reference. Running NanoRoute in Batch Mode From Encounter Software You can run NanoRoute as a separate process by selecting the Batch option on the NanoRoute form or by running the globalDetailRouteBatch command. In batch mode, NanoRoute starts a separate process that runs standalone NanoRoute. Encounter and NanoRoute communicate through LEF and DEF files, plus files that contain timing-related information. The NanoRoute routing engine used in standalone mode and in Encounter is the same. Note: An Encounter command script that uses the globalDetailRoute command should also work if you substitute the globalDetailRouteBatch command, except that globalDetailRouteBatch does not use the -select argument or the area (x1 y1 x2 y2) specification. The flow for running NanoRoute in batch mode is 1. Encounter outputs the following information to standalone NanoRoute: ❑ Routed DEF file ❑ Current option and attribute settings ❑ Set of selected nets 2. Standalone NanoRoute reads the DEF file and routes the design. Encounter is blocked from running while NanoRoute routes the design. 3. Standalone NanoRoute outputs the routed DEF file to Encounter. May 2005 402 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute 4. Encounter reads back the DEF file that was routed by standalone NanoRoute. For more information on Batch, see “Route Menu” in the Encounter Menu Reference. For more information on globalDetailRouteBatch, see “Route Commands” in the Encounter Text Command Reference. Important For information on the implications of using Batch or globalDetailRouteBatch and running ECO routing, see “ECO Routing in Batch Mode” on page 434. Running NanoRoute in Standalone Mode The commands and options for running NanoRoute standalone are not described in this document. Standalone NanoRoute has its own GUI and command syntax. For more information, see the NanoRoute Technology Reference. May 2005 403 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Using NanoRoute Parameters NanoRoute has two kinds of parameters: attributes and options. ■ Attributes assign characteristics to nets. For example, use attributes to specify nets that have the following attributes: they are routed first (or last), they are routed on certain layers, they are protected by extra spacing, they are shielded (or act as shields), signal integrity violations that affect them are repaired after routing. ■ Options determine run-time operations. For example, use options to perform the following run-time operations: run global or detailed routing; route selected nets only; repair antenna or design-rule violations; run timing driven or signal integrity driven routing; specify the number of processors to use. The following table lists attribute and option characteristics: Characteristic Attributes Options Application Apply locally to a net object Apply globally to a process or command Specification ■ NanoRoute/Attributes form ■ NanoRoute form ■ setAttribute command ■ ■ Some attributes can only be specified by setAttribute. ■ setNanoRouteMode command Persistence May 2005 Saved with the database. When you set an attribute and save the database and exit, the attribute setting is saved. If you reload the database, the object retains the attribute setting. 404 Some options can only be specified by setNanoRouteMode. Saved with the database. When you set an option, save the database and exit, the option setting is saved. If you reload the database, NanoRoute retains the option value. Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Characteristic Attributes Options Format -attribute_name -optionName ■ Example: -avoid_detour ■ Case sensitive (all lower case) ■ Case sensitive (all mixed case) ■ Mandatory underscores separate words ■ No underscores. Each word starts with an upper-case letter ■ Native and standalone NanoRoute formats are the same ■ Native and standalone NanoRoute formats are different (standalone options are all lower case; words are separated by underscores; options do not start with a leading hyphen ■ Example: -drouteAutoStop See settings for this run … Use the getAttribute command Use the getNanoRouteMode command More information available at … setAttribute in the Encounter Text Command Reference setNanoRouteMode in the Encounter Text Command Reference Using Attributes and Options Together You can use attributes and options together. For example, to run global and detailed routing and repair signal integrity violations on a specified net during postroute optimization, set the -si_post_route_fix attribute for the net and route the design with the -routeWithSiPostRouteFix option set to true. Using text commands, issue the following commands: setAttribute -net net1 -si_post_route_fix true setNanoRouteMode -routeWithSiPostRouteFix true globalDetailRoute Using the GUI, make the following selections: ■ On NanoRoute/Attributes form, May 2005 405 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute a. Type the name of the net in the NetName(s) text box. b. Select SI Post Route Fix True. ■ On the NanoRoute form, a. Select both Global Route and Detail Route. b. Select Post Route SI. May 2005 406 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Accelerating Routing with Multi-Threading and Super-Threading Encounter products accelerate routing by using more than one processor in the same machine and by distributing routing to multiple machines. Both signal routers, NanoRoute and WRoute, can use more than one processor in the same machine. This is called multi-threading. For more information, see “Running Multi-Threading” on page 68. NanoRoute accelerates routing even more by distributing detailed routing across the network to multiple machines. This capability combines multi-threading with distributed processing, and is called super-threading. When used with a Gigabit Ethernet connection, superthreading makes data communication time negligible. Super-threading has the following features: ■ It uses available Encounter licenses. No special licenses are necessary. ■ It is platform independent. ■ ❑ Different operating systems—including Solaris, Linux, and HP-UX—can be used in the same job. ❑ Different hardware—including Sun, IBM, and HP—can be used in the same job. ❑ 64-bit and 32-bit NanoRoute can be used in the same job. For example, you can start a large job on a 64-bit server and run the job on smaller 32-bit clients. It can run using the rsh command, and with LSF, SSH, or Sun Grid configurations. ❑ The RSH method ties multi-threaded jobs together. ❑ The LSF, SSH, and Sun Grid methods tie single jobs together. When to Accelerate Routing Not all designs or network topologies can take advantage of accelerated routing. Consider the following issues, and use single threading, multi-threading, or super-threading when appropriate: ■ Small (10k), simple designs or designs that do not have a lot of violations Small jobs or designs that are easily routed probably do not not need multiple CPUs or machines. May 2005 407 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ Slow networks The speed (10Mb, 100Mb, or 1,000Mb) and type (LAN or WAN) of the network affect super-threading speed. ■ Loaded networks Sharing CPU cycles with other processes increases super-threading run time. ■ Full or pending LSF queues or queues configured for one job A queue that is set up to run only one job decreases efficiency. Running Super-Threading To run super-threading, do the following before running any global or detailed routing commands: ■ On the text command line: ❑ Set setNanoRouteMode -envSuperThreading. This option specifies the clients, number of CPUs, and search path for superthreading. During detailed routing, the value of this option overwrites the value of the multi-threading option. ❑ Optionally, set setNanoRouteMode -envDontUseLicsForThreadings. This option limits the license search for multi-threading and super threading. For more information, see “Controlling the Licenses to Use” on page 410. To runs super-threading using rsh on 2 processors on my_linux_machine and 4 processors on my_sun_machine, type the following: setNanoRouteMode -envSuperThreading "RSH {my_linux machine 2 /home/bin/linux/nanoroute} {my_sun_machine 4 /home/bin/solaris/nanoroute} " For more information on syntax and options, and additional text command examples, see “Route Commands” in the Encounter Text Command Reference. ■ In the Encounter GUI: ❑ Select Super Threading on the NanoRoute form. For information on filling in the Encounter forms for super-threading see, “Route Menu” in the Encounter Menu Reference. May 2005 408 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Usage Notes ■ If you use the rsh command for super-threading, you must be able to run the remote shell from the server machine to the client machines without a password prompt. ■ The NanoRoute software must be accessible to the server and client machines. ■ Client machines must be able to access the same version of the NanoRoute software. ■ If you run native NanoRoute, it will be the server program and standalone NanoRoute will be the client program. ■ Start your routing job on the fastest multi-threaded machine available. ■ Include the host machine as a client, otherwise it will be a server only and will not perform any routing jobs. ■ If any CPUs crash, your job will not complete. If there is a crash, most likely it will happen during the client routing stage, and the server will continue to run. The database on the server will be maintained in the state it had prior to the crash. Check the messages in the log file to determine the problem and zoom into the area of the crash to see a graphical representation of the cause of the failure. After you fix the problem, you can continue routing from the crash point. ■ If your job includes both Sun and Linux clients, include a different path to each executable in the command script or configuration file. ■ You can run a job that uses both a Sun queue and a Linux queue. ■ To stop routing in super-threading mode, enter the following command: setNanoRouteMode -envSuperThreading default When would you want to do this? Do you have to reset to default at any point (e.g. after routing), or can you just keep working without resetting it? License Considerations for Super-Threading Licenses for the following Encounter products enable super-threading: ■ NanoRoute™ Ultra SoC routing solution ■ Nano Encounter™ implementation system for flat designs ■ SoC Encounter™ hierarchical RTL-to-GDSII physical implementation solution May 2005 409 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ SoC Encounter Global Physical Synthesis A license for Nano Encounter Demand-Based Savings (DBS) system can be used for the first CPU only. Licenses for Route Accelerator are not used for super-threading. License checking for super-threading takes place on the server machine. The first license that is checked out enables one CPU, and each additional license enables three CPUs. For example, one license enables one CPU (no multi-threading or superthreading), two licenses enable four CPUs, three licenses enable seven CPUs, and so on. To avoid using or holding extra licenses, specify the super-threading configuration at the beginning of your Tcl file, or before running any global routing commands, and avoid changing the configuration during the Encounter session. Controlling the Licenses to Use The software checks out licenses in the following order: ■ NanoRoute Ultra ■ Nano Encounter ■ SoC Encounter ■ SoC Encounter GPS You can control the license search by setting the -envDontUseLicsForThreadings option. Specifying -envDontUseLicsForThreadings is optional. This option limits the license search by excluding licenses. For example, to use a license for Nano Encounter, even though a license for NanoRoute Ultra is available, type the following command: setNanoRouteMode -envDontUseLicsForThreadings "nano" To use a license for SoC Encounter, even though licenses for NanoRoute Ultra and Nano Encounter are available, type the following command: setNanoRouteMode -envDontUseLicsForThreadings "nanor nano" For more information, see setNanoRouteMode in the Encounter Text Command Reference. May 2005 410 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Super-Threading Log File Excerpts The following excerpts from a log file show progress during super-threading. The software uses the following definitions to calculate the time: ■ client CPU time is the CPU time on clients only. ■ cpu time is the server CPU time plus the client CPU time ■ elapsed time is the complete run time (the time elapsed on a clock on the wall). The first file fragment shows that the job is running with RSH, with two threads on the same host. NanoRoute pauses as the data on the server is synchronized. #server my_machine is up on port 123456 waiting for connection ..... # client 2thread 1 from host machine_1 # client 2thread 2 from host host_machine_1 # Sync client 2 data ... # cpu time = 00:00:03, elapsed time = 00:04:18, memory = 561.87 (Mb) The second fragment shows that only 86% of the client CPU time is being used. Another process (in addition to the route job) is using CPU resources. # client 3thread 1 from host machine_2 # client 3thread 2 from host machine_2 # Sync client 3 data ... # cpu time = 00:00:03, elapsed time = 00:04:31, memory = 561.87 (Mb) # #Start Detail Routing. #Start initial detail routing ... # completing 10% with 0 violations ... # completing 90% with 14 violations # elapsed time = 00:12:29, memory = 606.02 (Mb) # completing 100% with 10 violations # elapsed time = 00:12:53, memory = 567.24 (Mb) # number of violations = 0 # client cpu time = 00:03:12, memory 562.70 (Mb), util = 86% #cpu time = 00:01:21, elapsed time = 00:123:54, memory = 566.24 (Mb) . ... The third fragment shows that the job took less elapsed time than cpu time. The elapsed time is less than the cpu time because two clients are being used to route one job. #Total number of violations on LAYER M8 = 4 #Total number of violations on LAYER M9 = 1 #Total number of violations on LAYER M10 = 0 #Client cpu time = 17:38:54 #Client peak memory = 795.22 (Mb) #Cpu time = 19:18:40 #Elapsed time = 10:15:51 The final fragment shows the time the job completed. May 2005 411 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute #Increased memory = 92.98 (Mb) #Total memory = 628.17 (Mb) #Peak memory = 1019.30 (Mb) #Complete global_detail_route on Fri Apr 16 10:14:33 2004 Route Acceleration Options Use the following NanoRoute options to control route acceleration using multi-threading and super-threading: ■ -envDontUseLicsForThreadings ■ -envNumberProcessor ■ -envSuperThreading For more information on these options, see setNanoRouteMode in “Route Commands” in the Encounter Text Command Reference. May 2005 412 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Following a Basic Routing Strategy In general, the first time you route a design, you should be able to accept the default values on the NanoRoute form. You can look at the Encounter log file to see the processes that NanoRoute runs, and the problems it encounters. Then you can adjust the net attributes or run-time options to improve your results. The strategy presented in this section shows how you can break the routing processes into steps, so you can analyze and solve problems easily. After each step, check for data problems and congestion and make repairs. Repeat the step and repair remaining violations. Continue this process until the design is free of violations before going to the next step. Using the Encounter Text Commands The following commands show the basic routing strategy using the Encounter text commands. 1. NanoRoute globally routes the design: globalRoute 2. NanoRoute does the initial detailed routing (iteration 0 does not include a search-andrepair step), and saves the design as droute0: setNanoRouteMode -drouteStartIteration 0 setNanoRouteMode -drouteEndIteration 0 detailRoute saveDesign droute0 3. NanoRoute does the first search-and-repair iteration and saves the design for analysis: setNanoRouteMode -drouteStartIteration 1 setNanoRouteMode -drouteEndIteration 1 detailRoute saveDesign droute1 4. NanoRoute does the second to nineteenth search-and-repair iterations and saves the design for analysis. The switch box grows larger as the iteration number increases. setNanoRouteMode -drouteStartIteration 2 setNanoRouteMode -drouteEndIteration 19 detailRoute saveDesign droute19 5. NanoRoute runs postroute optimization (drouteEndIteration default) and additional search-and-repair operations and saves the design as droute: setNanoRouteMode -drouteStartIteration 20 setNanoRouteMode -drouteEndIteration default detailRoute saveDesign droute May 2005 413 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Using the Encounter GUI The following section describes the basic routing strategy using the GUI. Run Global Routing 1. Choose Route – NanoRoute. 2. Select Global Route. 3. Click OK. 4. Save as groute. 5. Check the congestion map. If you see congested areas after global routing, your design is unroutable. Run Detailed Routing To run initial detailed routing, complete the following steps: 1. Choose Route – NanoRoute. 2. Set the following options on the NanoRoute form: ❑ Detail Route ❑ Start Iteration 0 ❑ End Iteration 0 NanoRoute builds the initial detailed routing database, but does not do any search and repair during this step. 3. Click OK. 4. Save the design as droute0. 5. Check the violations in the log file. If you have many violations on metal1 and metal2, you probably have pin-access problems, incorrect track settings, or overlapped cells. Check your LEF file and correct any problems. See “Evaluating Violations” on page 435 for an excerpt of a log file from a design with many violations on metal1 and metal2. May 2005 414 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute For information on the LEF file, see the LEF/DEF Language Reference or the Encounter Library Development Guide. Run Search and Repair Break search and repair into two phases. Check congestion after each phase and repair violations. To run the first phase of search and repair, complete the following steps: 1. Choose Route – NanoRoute. 2. Set the following options on the NanoRoute form: ❑ Detail Route ❑ Start Iteration 1 ❑ End Iteration 1 During this phase, NanoRoute makes local changes to the database. It does not do detailed or global routing. 3. Click OK. 4. Save the design as droute1. 5. Check the violations in the log file and graphically. To run the second search-and-repair phase, complete the following steps: 1. Choose Route – NanoRoute. 2. Set the following options on the NanoRoute form: ❑ Detail Route ❑ Start Iteration 2 ❑ End Iteration 19 In this phase, NanoRoute makes additional search-and-repair passes. It reroutes nets with violations within a local area (a switch box). In each successive pass, the size of the switch box size increases, so NanoRoute can make the repairs over larger areas. 3. Click OK. 4. Save the design as droute19. May 2005 415 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute 5. Check congestion. If you still have many violations (more than 1,000) or an unbalanced distribution of violations, you might still have a problem with the data or a congested design. For help resolving the violations, see “Evaluating Violations” on page 435. Run Postroute Optimization Ensure your data and library are violation-free before you run postroute optimization, or NanoRoute might spend a lot of time trying to repair violations that it cannot repair. Postroute optimization takes longer than any of the other steps because NanoRoute does more rigorous search and repair during postroute optimization than previous steps. To run postroute optimization, complete the following steps: 1. Choose Route – NanoRoute. 2. Set the following options on the NanoRoute form: ❑ Detail Route ❑ Start Iteration 20 ❑ End Iteration default Note: In general, do not set Start Iteration or End Iteration higher than 20 because it does not increase the quality of results. 3. Click OK. 4. Save the design as droute. During postroute optimization, NanoRoute runs both global and detailed routing and makes global changes to repair violations. May 2005 416 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Checking Congestion Check congestion in your design after global routing by using the congestion analysis table in the Encounter log file and the congestion map in the Encounter main window. Using the Congestion Analysis Table The congestion analysis table shows the distribution and severity of congestion in global routing cells (gcells) on each routing layer. Note: For information on global routing and on gcells, see “Global Routing” on page 394. Following is an example of a congestion analysis table: Congestion Analysis: OverCon OverCon OverCon OverCon #Gcell #Gcell #Gcell #Gcell %Gcell Layer (1-2) (3-4) (5-6) (7-12) OverCon --------------------------------------------------------------------------Metal 1 22(0.01%) 10(0.00%) 0(0.00%) 0(0.00%) (0.01%) Metal 2 5531(2.39%) 1680(0.73%) 370(0.16%) 123(0.05%) (3.33%) Metal 3 4114(1.78%) 19(0.01%) 0(0.00%) 0(0.00%) (1.79%) Metal 4 1333(0.58%) 137(0.06%) 0(0.00%) 0(0.00%) (0.64%) Metal 5 5852(2.53%) 4(0.00%) 0(0.00%) 0(0.00%) (2.53%) Metal 6 27(0.01%) 0(0.00%) 0(0.00%) 0(0.00%) (0.01%) --------------------------------------------------------------------------Total 16879(1.22%) 1850(0.13%) 370(0.03%) 123(0.01%) (1.39%) ■ The first column, Layer, lists the metal layers that have over-congested gcells. NanoRoute marks a gcells as over-congested if the global router has assigned more nets to the gcell than the gcell has available tracks. ■ The second through fifth columns, labelled OverCon #Gcell, list the number and percentage of gcells on each layer that are over-congested. ■ The numbers in parentheses after OverCon #Gcell indicate how many additional tracks within the gcell are needed to accommodate the gobal routing assignments. For example, OverCon #Gcell (1-2) means that one or two additional tracks are needed to accommodate all the nets that the global router has assigned the gcells listed in the column. As you move from left to right in the table, congestion increases because the difference between the number of nets assigned to the gcell by the global router and number of available tracks within the gcell increases. ■ The number of columns in the table is determined by the number of additional tracks needed by the gcells with the worst congestion. For example, if the most over-congested gcells need only four additional tracks, the table would include columns for 1-2 and 3-4 tracks, but not for 5-6 or more tracks. May 2005 417 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ NanoRoute creates only one column for gcells that need seven or more additional tracks. In the example, all gcells that need seven to 12 additional tracks are listed in the column labelled OverCon #Gcell (7-12). ■ NanoRoute displays the maximum number of tracks needed in the last OverCon #Gcell column. In the example, the maximum number of tracks needed is 12. If some gcells needed 14 more tracks, the column would be labelled OverCon #Gcell (714). If the maximum number of tracks needed were only eight, the column would be labelled OverCon #Gcell (7-8). Within each column, the table does not indicate exactly how many additional tracks are needed. For example, in the column labelled OverCon #Gcell (7-12), NanoRoute does not distinguish between gcells that need seven, eight, nine, ten, 11, or 12 additional tracks. ■ The last column, %Gcell OverCon, lists the percentage of all gcells on the layer that are over-congested. In the example, on layer Metal 1, only 0.01% of the gcells are overcongested. ■ The last row of the table, Total, lists the total number and percentage of over-congested gcells in each column. In the example, 1,850 gcells in the design, or 0.13% of all gcells, need three or four more tracks. ■ The last row of the last column displays the overall percentage of over-congested gcells in the design. In the example, 1.39% of all cells are over-congested. Interpreting the Table ■ Read the table horizontally to see the distribution and percentage of gcells on each layer that have a greater demand for tracks than they have supply of tracks. ■ Read the table vertically to see which layers have the most over-congested gcells and how severe the congestion is. ■ The table does not show how closely the over-congested gcells are clustered. Look at the congestion map in the GUI to see clusters of congestion and their exact location. ■ There is no “magic number” that determines whether the design is routable. In general, the more columns, and the more the percentages increase toward the right side of the table, the worse the congestion. Using the Congestion Map Check obstructions and congestion in your design graphically by analyzing a congestion map. The information in the map is directly extracted from NanoRoute after you run global routing. May 2005 418 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute You choose the layer to display on the map. The Encounter software displays the congestion map in the main window when you complete the following steps: 1. Globally route the design. 2. Select Physical view in the Views area of the Encounter main window. 3. Move the slider under All Colors to the left. This displays General color control. 4. Make Congestion viewable. 5. Click the All Colors button. 6. Select both Horizontal Congest and Vertical Congest. 7. Click Update Display. For more information on selecting the objects and colors, see “The Main Window” in the Encounter Menu Reference. Interpreting the Congestion Map In the map, blue or black indicate an acceptable level of congestion; white indicates an unacceptable level. However, this depends on your design. For example, a design that is mostly uncongested might have small areas (often called hot spots) that are highly congested. You must look at the overall congestion graphically to assess routability. The following table explains the meaning of the colors in the congestion map: Color Explanation Black No congestion: You have at least two tracks that are under-used. Blue No congestion: You probably have one track that is under-used. Green No congestion: All the tracks are used. Yellow Low congestion: You probably have one track that is over-used. Red Some congestion: You probably have two tracks that are over-used. Magenta Moderate congestion: You probably have three tracks that are overused. White High congestion: You probably have at least four tracks that are overused. May 2005 419 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute In the congestion map shown below, there is a congested area (a hot spot) in the lower left quadrant. Blue means no congestion and one under-used track Green means no congestion and all tracks are used Black means no congestion and several under-used tracks Red and yellow mean congestion May 2005 420 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute In the congestion map shown below, the design is not congested. May 2005 421 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Running Timing-Driven Routing You can choose the timing engine to use for timing-driven routing. In the Encounter environment, timing-driven NanoRoute uses the Common Timing Engine (CTE) by default, but you can specify another timing engine, such as the internal NanoRoute timing engine or PrimeTime. When you use the CTE, all the related tasks (route estimation for the timing graph, capacitance extraction, timing analysis, timing graph generation) are executed within the Encounter environment. Timing-driven routing might cause longer run time and more violations than nontiming-driven routing. For information, see “Violations in Timing-Driven Routing” on page 441. Input Files To run timing-driven routing you need the following files: ■ Physical libraries in LEF ■ Timing library in .lib format ■ Timing constraints in .sdc format or a timing graph For information on the timing constraints that are compatible with the Encounter CTE, see Appendix A, “Data Preparation” on page 37. For information on the timing constraints that are compatible with the internal NanoRoute timing engine, see Appendix A, “Timing Constraint Compatibility” in the NanoRoute Technical Reference. ■ Extended capacitance table generated by the Encounter software ■ Netlist in DEF or Verilog format ■ Placed design in DEF Using the CTE and Native NanoRoute Figure 15-1 on page 423 shows the design flow for native NanoRoute using the CTE. Native NanoRoute uses the CTE as its default timing engine. In native NanoRoute, the following commands use the CTE: setNanoRouteMode -routeWithTimingDriven true globalDetailRoute May 2005 422 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Figure 15-1 Native NanoRoute-CTE timing-driven routing flow Verilog, .lib, .sdc, .lef, .def and capacitance table files Create floorplan, place design, run CTS, run IPO Run timing-driven routing with NanoRoute Extract RC, run static timing analysis with CTE Routed database Using the CTE and Standalone NanoRoute Figure 15-2 on page 425 shows the design flow for standalone NanoRoute using the CTE. Standalone NanoRoute is loosely integrated with the CTE. In standalone NanoRoute, the following commands use the CTE: ■ From the Encounter environment: setNanoRouteMode -timingEngine external_timing_graph setNanoRouteMode -routeWithTimingDriven true globalDetailRouteBatch ■ Outside of the Encounter environment pdi set_option timing_engine external_timing_graph pdi set_option route_with_timing_driven true pdi global_detail_route The flow is shown in three main steps: 1. Generating a timing graph May 2005 423 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute To generate a timing graph based on the CTE, load your design into the Encounter software and use the Encounter writeDesignTiming and setCteReport commands. setCteReport writeDesignTiming design.tif For more information, see “Timing Commands” in the Encounter Text Command Reference. 2. Routing When you route the design, type the following commands: pdi set_option timingEngine design.tif 3. Extracting capacitance and analyzing timing May 2005 424 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Figure 15-2 Standalone NanoRoute-CTE timing-driven routing flow Verilog, .lib, .sdc, .lef, .def, and capacitance table files Create floorplan, place design, run CTS, run IPO Run Trial Route, extract RC, run static timing analysis with CTE Timing graph Timing graph, .lib, .lef, .def and capacitance table files Run NanoRoute timing-driven routing with external timing graph Routed .def file Routed .def, .lef, .lib, sdc, capacitance table files Extract RC, run static timing analysis with CTE Using the NanoRoute Timing Engine To use the NanoRoute timing engine instead of the CTE, do one of the following: ■ Issue the following commands: setNanoRouteMode -timingEngine Nano setNanoRouteMode -routeWithTimingDriven true globalDetailRoute ■ Select Batch on the NanoRoute form. May 2005 425 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Using Another Timing Engine To use another timing engine, such as PrimeTime, issue the following commands: ■ From the Encounter environment: setNanoRouteMode -timingEngine external_timing_graph setNanoRouteMode -routeWithTimingDriven true globalDetailRouteBatch ■ Outside of the Encounter environment pdi set_option timing_engine external_timing_graph pdi set_option route_with_timing_driven true pdi global_detail_route What do you need to do to generate the timing graph? what is the design flow--same as standalone NR with CTE? May 2005 426 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Routing Clocks Route clock nets before routing the rest of the signal nets. By default, NanoRoute does not move clock nets during postroute optimization. This section gives information on routing clocks manually. For information on routing clocks automatically with the Encounter software, see “Synthesizing Clock Trees” on page 315. Layer assignments for clock nets might not correlate in global and detailed routing. For tight control over clock timing, run global and detailed routing on clock nets before routing other nets. Fix the locations of the nets during detailed routing and unfix them during postroute optimization. Use net weights to ensure priority during search and repair. Setting Attributes for Clock Nets If clock nets are marked USE CLOCK in the DEF file or you have defined a clock net in the Encounter database, NanoRoute automatically sets the following values. You can change the values by setting attributes on the NanoRoute Attributes form. If the clock nets are not defined, type the name of a clock net in the Net Name(s) text box to set attributes for the net. ■ Weight The default net weight for clock nets is 10, to give clock nets priority during global routing (the default net weight for other nets is 2). During global routing, NanoRoute goes from global routing cell to global routing cell within each switch box, and routes the nets with the highest weight first. ■ Bottom Layer The default bottom layer for routing clock nets is 3, to ensure that NanoRoute has access to metal1 pins during routing. This attribute sets a soft limit, and NanoRoute might route some nets on lower layers, if necessary to complete the routing. ■ Top Layer The default top layer for routing clock nets is 4. This attribute sets a soft limit, and NanoRoute might route some nets on lower layers, if necessary to complete the routing. ■ Avoid Detour Avoid Detour is True for clock nets, so they are routed as straight as possible. Set the following attribute in the Encounter console, using the setAttribute command ■ -preferred_extra_space 1 May 2005 427 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute -preferred_extra_space adds spacing around the clock nets, which improves coupling capacitance. It is not included on the NanoRoute/Attributes form. For information on setAttribute -preferred_extra_space, see “Route Commands” in the Encounter Text Command Reference. Tip Select SI Prevention True to set Weight, Avoid Detour and -preferred_extra_space all at once. SI Prevention True sets Weight to 10, Avoid Detour to True, and -preferred_extra_space to 1 for clock nets. Routing the Clock Nets ➤ Specify the following options on the NanoRoute form: ■ Selected Nets Specify Selected Nets to route the clock nets first. Unlike the Weight attribute, which gives priority to routing nets within a switch box, Selected Nets is a global option that routes whole nets. ■ Global Route ■ Detail Route Specify End Iteration 19 to stop routing before the postroute optimization step. Running Postroute Optimization To prevent rip-up and rerouting of clock nets during postroute optimization, specify the following: ■ On the NanoRoute/Attributes form, keep the attributes you have already set, and specify Skip Routing True. ■ On the NanoRoute form, specify Start Iteration 20 and End Iteration default. May 2005 428 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Preventing and Repairing Crosstalk Problems During SMART routing, NanoRoute automatically prevents crosstalk problems by wire spacing, net ordering, minimizing the use of long parallel wires, and selecting routing layers for noise-sensitive nets. NanoRoute performs these operations concurrently with other operations. In addition to the operations it performs automatically, NanoRoute also performs shielded routing to protect critical wires from crosstalk. During postroute signal integrity repair, NanoRoute performs these same operations. The following sections describe the crosstalk prevention and repair operations NanoRoute performs, and whether you can set net attributes to control them. ■ Wire spacing NanoRoute automatically adds extra space between critical nets. You can also use the -preferred_extra_space attribute to add space. For information on this attribute, see setAttribute in the Encounter Text Command Reference. ■ Net ordering NanoRoute automatically routes critical nets first and avoids detours on those nets so they are as short as possible. ❑ May 2005 You can also use the -weight attribute to give priority to critical nets within a switch box, so they are routed first. 429 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ❑ ■ You can use the -avoid_detour attribute to ensure that critical nets are routed as short as possible. Minimizing the use of long parallel wires NanoRoute automatically minimizes the use of long parallel wires, based on an internal algorithm. You cannot set an attribute to control this feature. ■ Selecting routing layers NanoRoute automatically restricts routing layers for critical nets to reduce both coupling and resistance. It routes clocks on layers 3 and 4. ❑ May 2005 You can set the -bottom_preferred_routing_layer and -top_preferred_routing_layer attributes to specify preferred layers for critical nets. 430 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ❑ ■ You can specify how strictly to enforce these attributes by specifying the -preferred_routing_layer_effort attribute. Shielding NanoRoute can shield critical nets with power or ground wires to protect them from coupling. Shielding is not an automatic operation—you control it with the -shield_net attribute. For more information on shielded routing see “Performing Shielded Routing” on page 445. Crosstalk Prevention Options To minimize problems caused by crosstalk, set the following NanoRoute options: setNanoRouteMode -routeWithTimingDriven true setNanoRouteMode -routeWithSiDriven true These options specify timing-driven and signal integrity-driven routing. Optionally, you can also set the following options: setNanoRouteMode -routeTdrEffort setNanoRouteMode -routeSiEffort These options fine tune the priorities NanoRoute assigns to timing, signal integrity, and congestion. Use these options together to minimize crosstalk. After meeting the timing requirements of your design, adjust the values and rerun routing, following these guidelines: ■ If your design is congested, use a low timing-driven effort. ■ If your design is not congested, use a high timing-driven effort. May 2005 431 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Tip Because designs with severe signal-integrity problems are usually not congested, use a high timing-driven effort for those designs. ■ If increasing the timing-driven effort creates a jump in the number of timing violations, decrease the timing-driven effort. For more information on these options, see setNanoRouteMode in the Encounter Text Command Reference. For more information, see “Analyzing and Repairing Crosstalk” on page 625 May 2005 432 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Running ECO Routing NanoRoute performs ECO routing by completing partial routes with added logic, while maintaining the existing wire segments as much as possible. ECO routing is useful in cases such as the following: ■ After the chip is initially routed, the customer or chip owner gives you a new netlist with minor changes. ■ After the chip is initially routed, buffers were added to repair setup or hold violations or DRVs during physical optimization. ■ Buffers were added or gates were resized during hand editing of a routed design. ■ Antenna diodes were added interactively after routing to repair process antenna violations. ■ After metal fill is added to the design. During ECO routing, NanoRoute does the following: ■ Reroutes partial routes and nets without routing. You can use wire editing commands to partially preroute wires to guide global ECO routing. NanoRoute does not globally reroute nets that are automatically prerouted, such as clock nets, but it might make minor routing changes to preroutes to increase routability of the design. Examples of minor routing changes include the following: ❑ Completely moving a preroute ❑ Changing the routing topology within the current routing switch box. ■ Retains fully prerouted nets and pin-to-pin paths. ■ Might use dangling paths in order to complete routes, but removes dangling wires left after global routing. ■ Keeps connectivity within the bounding box, but does not constrain layers or positions. Would be good to add pictures of what NR does. Plus discussion of + ROuTED and + FIXED. ECO Limitations ■ Do not use the globalRoute command in ECO mode. To route in ECO mode, run the globalDetailRoute or globalDetailRouteBatch command. May 2005 433 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ If more than 10 percent of the nets are new or partially routed, run full global and detailed routing instead of ECO routing. ECO Routing in Batch Mode Selecting Batch on the NanoRoute form or running globalDetailRouteBatch when you route the design has implications for ECO routing in Encounter. Because Batch and globalDetailRouteBatch run standalone NanoRoute, they cannot access a saved Encounter database. In this flow, standalone NanoRoute gets routing information only from the DEF file that is output by Encounter. This means that, during an ECO routing step, after the routed database is read back into Encounter, Encounter does not know that the design was previously routed by NanoRoute. It converts the routed DEF file to a database that NanoRoute can read, extracts the wire information and runs the initial verification step on the entire design. Then it routes the entire design. This process is more time consuming than it would be if the database was routed by NanoRoute without selecting Batch or using globalDetailRouteBatch. If you do not select Batch on the NanoRoute form or use globalDetailRouteBatch to route the design, NanoRoute can access the Encounter database directly. It knows that the design was routed by NanoRoute and what was changed since the last time the design was routed. This means that, during an ECO routing step, NanoRoute does not have to extract wire information or run verification on the entire design. It routes only the nets that have been changed since the last time the design was routed. NanoRoute ECO Flow To perform ECO routing, specify the following commands and options: setNanoRouteMode -routeWithEco true globalDetailRoute NanoRoute automatically identifies the nets that need changes during ECO routing. Alternatively, if want to route only a few nets, and you want to skip routing on all the other nets, you can specify the following commands: setAttribute -net @PREROUTED -skip_routing true setAttribute -net eco_net_name1 -skip_routing false setAttribute -net eco_net_name2 -skip_routing false For more information on using Encounter ECO commands and flows, see “Interactive ECO” on page 613. May 2005 434 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Evaluating Violations After you run several search-and-repair iterations, look at the number and distribution of violations remaining, and determine whether they are problems with congestion, or are design or library problems. If you see many violations (more than 1,000) or the number of violations does not decrease with each iteration, stop search and repair and check congestion graphically. Important If you import a routed design from standalone NanoRoute, the Encounter software imports the violation markers as well. To delete the violations, rerun detailed routing. The software deletes the violations during search and repair. Standalone NanoRoute places via violation markers on the lower layer of the via even when the violation is on the upper layer. If you import a routed design with via violations, NanoRoute corrects the violations during search and repair. The following excerpt is from a log file from a design after the nineteenth iteration of search and repair. There are many violations, mostly on layers metal1, metal2, and metal6. #Total #Total #Total #Total #Total #Total #Total #Total number number number number number number number number of of of of of of of of DRC violations = 1426 violations on LAYER Metal1= violations on LAYER Metal2= violations on LAYER Metal3= violations on LAYER Metal4= violations on LAYER Metal5= violations on LAYER Metal6= violations on LAYER Metal7= 876 275 84 38 18 135 0 Figure 15-3 on page 436 illustrates this stage in the design. Violations on different layers are shown by different-colored markers. May 2005 435 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Figure 15-3 Designs with violations like those in the preceding illustration often have library or design problems, such as overlapping pins, improperly defined tracks, or an insufficient number of rotated vias. May 2005 436 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Use the guidelines in the following table to help evaluate violations: Violations/Warnings Check for ... Many violations on metal1 ■ Improper setup of routing tracks ■ Overlapping cells ■ Insufficient via rotation, causing inaccessible pins For information on fixing these problems, see the Encounter Library Development Guide. Many violations on metal1 and metal2 ■ Offgrid pins ■ Overlapping tracks ■ Overlapping cells ■ Improper X offset, causing offgrid standard cell pins ■ Pins buried under power routing For information on fixing these problems, see the Encounter Library Development Guide. Bad net messages ■ NanoRoute might display bad net messages during global routing. A bad net is one that ■ NanoRoute cannot route because it cannot connect to a pin. The message tells you ■ which pin NanoRoute cannot connect to. ■ May 2005 437 Minimum-width pins that are placed off the manufacturing grid Pins that are less than the minimum width Missing power and ground special net routing, for example, missing special routes for stripes or followpins (causing vdd or vss bad net) Pins underneath power stripes on the same metal layer. Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Violations/Warnings Check for ... Violations not decreasing after first iteration of detailed routing ■ Offgrid pins ■ Overlapping tracks ■ Overlapping cells ■ Improper X offset, causing offgrid standard cell pins ■ Pins buried under power routing For information on fixing these problems, see the Encounter Library Development Guide. Violations on upper layers, such as via-towire violations or shorts ■ For information, see “Violations on Upper Metal Layers” on page 439. For more information on correcting the routing pitch, see the Encounter Library Development Guide. Localized congestion (also called hot spots) ■ —areas in the congestion map that are red, magenta, or white. The congestion might be caused by one of the following: ■ Limited pin access to a block ■ Congestion around the corner of a block and in the middle of the standard cells False violations Improper routing pitch (not line-to-via) ■ Improper placement or floorplanning For information on placement see “Placing the Design” on page 285. For information on floorplanning, see “Floorplanning the Design” on page 215 Violation markers on the lower metal layer of a via, even though the actual violation is on the upper layer. When it flags a via violation, NanoRoute places the violation marker on the lower metal layer of the via, whether the actual violation is due to a problem on the lower layer or the upper layer. To repair the violation, rerun detailed routing. NanoRoute finds and repairs the violation, even when the marker was reported on on the incorrect layer. May 2005 438 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Violations on Upper Metal Layers Upper layers are typically used to route on top of macros where only a few routing layers are allowed. These upper layers typically have larger vias than lower layers. When the routing pitch is not set at line-to-via distance, two types of violations are likely to occur: ■ Via-to-wire violations ■ Shorts Figure 15-4 on page 439, Figure 15-5 on page 440, and the LEF and DEF file excerpts that follow show a design with many violations on metal6. Figure 15-4 Area expanded below to show violations May 2005 439 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Figure 15-5 via-to-wire violation metal6 short The relevant LEF file excerpt is: LAYER Metal6 TYPE ROUTING ; PITCH 0.46 ; WIDTH 0.2 ; SPACING 0.21 ‘ DIRECTION VERTICAL ; END Metal6 LAYER Metal7 TYPE ROUTING ; PITCH 0.82 ; WIDTH 0.4 SPACING 42 ; DIRECTION HORIZONTAL ; END Metal7 VIA via6 DEFAULT LAYER Metal6 ; RECT -0.19 -0.23 0.19 0.23 ; LAYER Via6 ; RECT -0.18 -0.18 0.18 0.18 ; LAYER Metal7 ; RECT 0.29 -0.2 0.29 0.2 ; RESISTANCE 0.68 END via6 The relevant DEF file excerpt is: TRACKS X -4749270 D0 6324 STEP 460 LAYER Metal6 To repair the shorts and via-to-wire violations, align the tracks as much as possible without sacrificing them. Change the TRACKS statement in the DEF file to have at least line-to-via STEP (pitch). The line-to-via calculation for metal6 is: Line to via metal6 = 1/2 Width + Spacing + 1/2 Via = 0.1 + 0.21 + 0.19 = 0.5 May 2005 440 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Violations in Timing-Driven Routing Run time and the number of violations often increase during timing-driven routing because NanoRoute restricts the routing of timing-critical nets. During non-timing-driven routing, NanoRoute might detour some nets in order to avoid creating violations. In timing-driven mode, however, NanoRoute does not detour timingcritical nets. Instead, it forces them to be routed as short as possible, which can create congestion in the channels. Later, when design-rule checking takes precedence, NanoRoute detours timing-critical nets in overly congested channels. For information on the timing-driven routing flow, see “Running Timing-Driven Routing” on page 422. Figure 15-6 on page 441 and Figure 15-7 on page 442 illustrate non-timing-driven and timing-driven routing results for the same design. Figure 15-6 Non-timing-driven routing detours some critical paths/nets around the block to avoid DRVs Routing channel May 2005 441 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Figure 15-7 Timing-driven routing forces the same critical paths/nets into the channel Deleting Violated Nets To delete violated nets, use the editDeleteViolations command. After deleting the nets, use area routing or ECO routing to re-route the design. For information, see “Route Commands” in the Encounter Text Command Reference. Using Additional Strategies to Repair Violations Use the following additional strategies to route the design successfully: ■ ■ Repair process antenna violations with antenna repair options or the wire editing commands. ❑ For information on verifying process antenna violations, see “Verifying Process Antenna” on page 662. ❑ For information on NanoRoute process antenna options, see Repairing Process Antenna Violations. ❑ For information on wire editing, see “Editing Wires” on page 351. Ensure that blocks are placed in corners and near boundaries to help ease core congestion. May 2005 442 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Optimizing Vias When the design is free of DRC violations, NanoRoute can optimize vias by replacing singlecut vias with multiple-cut vias or with fat vias (single or multi-cut vias with an extended metal overhang). NanoRoute does not replace double-cut or quad-cut vias during via optimization. NanoRoute replaces vias by substituting vias in the following order: 1. Fat double-cut vias 2. Normal double-cut vias 3. Fat single-cut vias Ensure the following before replacing the vias: ■ Double-cut vias and fat vias are automatically generated or defined in the LEF file. ■ The design is completely global and detailed routed. If you delete any wires after routing, reroute the design before replacing the vias. ■ The design is free of all DRC violations. Note: Via replacement is one way: NanoRoute does not have a parameter to replace doublecut vias with single-cut vias. Via Optimization Options Use the following options during via optimization: ■ -drouteOptimizeUseMultiCutVia ■ -drouteUseBiggerOverhangFirst ■ -drouteUseViaOfCut ■ -routeMinimizeViaCount To replace the vias, select DFM on the NanoRoute form or issue the following commands: setNanoRouteMode -drouteOptimizeUseMultiCutVia true detailRoute To ensure that NanoRoute chooses vias with the largest overhang first, specify the following option: setNanoRouteMode -drouteUseBiggerOverhangViaFirst true May 2005 443 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute To replace single-cut vias with quad-cut vias, specify the following option: setNanoRouteMode -drouteUseViaOfCut 4 To minimize the number of vias, specify the following options: setNanoRouteMode -routeMinimizeViaCount true setNanoRouteMode -drouteEndIteration default For more information on these options, see “Route Commands” in the Encounter Text Command Reference. Optimizing Vias in Selected Nets To optimize vias in selected nets, set the -skip_routing attribute to true for all nets, then set the attribute to false for nets with vias you want to optimize. setAttribute -net * -skip_routing true setAttribute -net ... -skip_routing false globalDetailRoute May 2005 444 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Performing Shielded Routing NanoRoute can protect noise-sensitive nets, such as a clock nets, from crosstalk by shielding them with power or ground wires. You typically route shielded nets before routing other nets. At the end of routing, NanoRoute deletes shielding wires that are not connected to power or ground wires. NanoRoute automatically generates a shielding statistics report after routing. For information on the report, see “About the Shielding Statistics Report” on page 447. Figure 15-8 on page 445 shows a section of a design with a shielded net. In the figure, ■ The signal net is shielded by a power on net one side and ground net on the other side. ■ Multiple vias can be dropped where a stripe crosses the shielding net at a right angle, if the stripe is wide enough to accommodate them. ■ A segment of the signal net is not shielded. ■ There are some floating shielding net segments. What is the definitionof a “floating net segment?” Figure 15-8 Stripes Floating shielding net segment Shielding net No shield Shielded net Shielding net Floating shielding net segment Performing Shielded Routing Using the GUI To shield nets and route the shielded nets using the GUI, complete the following steps: May 2005 445 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute 1. From the main menu, choose Route – NanoRoute/Attribute. This opens the NanoRoute/Attributes form. 2. On the NanoRoute/Attributes form, enter the name of the net to shield (this is the shielded net in the figure) in the Net Name(s) field. 3. Enter the name of the power ground net (or both) in the Shield Net(s) field. These are the shielding nets in the figure. ❑ To shield both sides with ground wires, enter the name of the ground net. ❑ To shield one side with a ground wire and one side with a power wire, enter both the ground and the power net names. 4. Click OK or Apply. 5. Use the Encounter selectNet command to specify the net to shield. It must be the same as the net you specified on the NanoRoute/Attributes form. 6. From the main menu, choose Route – NanoRoute. This opens the NanoRoute form. 7. On the NanoRoute form, select the following: ❑ In the Job Control area, select Selected Nets. ❑ In the Mode area select both Global Route and Detail Route. 8. Click OK or Apply. To route the remaining nets, complete the following steps: 1. On the NanoRoute/Attributes form, set the Skip Routing True for the shielded nets. Tip You can also skip routing on prerouted nets by issuing the following command: setAttribute -net @PREROUTED skip_routing true @PREROUTED applies to a net that has any wiring, including partial wiring. 2. On the NanoRoute form, deselect Selected Nets Only. 3. Click OK or Apply to reroute the design. May 2005 446 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Text Command Examples ■ The following commands shield net1 with both power and ground wires, and shield net2 with a ground wire: setAttribute -net net1 -shield_net vdd \ -shield_net vss setAttribute -net2 -shield_net vss globalDetailRoute ■ The following commands show how to shield two nets (do not shield more than one net with the same command): setAttribute -net net1 -shield_net abc_gnd setAttribute -net net2 -shield_net abc_gnd About the Shielding Statistics Report NanoRoute automatically generates a shielding statistics report named design_name.shield.rpt in the current directory when there are shielded nets in the design. The Encounter log file contains a summary of the statistics from the report. Following is a shielding statistics report for a design: Name Length Noshield Floating Shield ratio : : : : : : Shielded net name Shielded net length Total length of shielded net segments denoted by NOSHIELD in DEF Total length of floating shielding wire Total length of shielding wire not floating Average shielding ratio Floating shielding wire removed ---------------------------------------------------------------------------Name Length Noshield Floating Shield (ratio) ---------------------------------------------------------------------------my_net_1: 185.5 75.8 181.8 34.6 0.095 my_net_2: 214.9 54.6 241.7 79.1 0.184 my_net_3: 241.7 47.3 245.6 175.6 0.335 my_net_4: 270.0 66.5 229.0 195.2 0.347 my_net_5: 285.7 66.0 245.1 204.5 0.350 my_net_6: 310.7 43.2 228.7 330.6 0.509 my_net_7: 277.7 47.6 108.9 362.4 0.637 average: 255.2 57.3 211.5 197.4 0.374 Figure 15-9 on page 448 shows a section of the design in the report. May 2005 447 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Figure 15-9 s f n l s f In the figure, f Represents floating shielding wire. For my_net_1, the length of f is 181.8. l Represents a shielded net. For my_net_1, the length of l is 185.5. n Represents the portion of the shielded net that is not shielded. For my_net_1, the length of n is 75.8. s Represents the portion of the shielding net that is not floating. For my_net_1, the length of s is 34.6. Note that two wire segments, one on either side of net l, are needed to make up s and f. The ratio in the report is calculated using the following formula: ratio = W × ( 1 – F ) May 2005 448 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute where l–n W = ---------l f F = -----------s+ f The calculations for the ratio for my_net_1 in the report are 185.5 – 75.8 W = ------------------------------ = 0.59 185.5 181.8 F = ------------------------------ = 0.84 34.6 + 181.8 ratio = 0.59 × ( 1 – 0.84 ) = 0.095 NanoRoute Shielding Option Use the following NanoRoute option to control shielding: ■ setNanoRouteMode -routeMinShieldViaSpan This option controls the distance between vias and special nets that are used as shield wires. May 2005 449 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Routing Wide Wires NanoRoute automatically tapers wide wires when connecting to pins. The tapered portion of a wire uses the minimum-width wire (the default width). Using Nondefault Rules By default, NanoRoute treats nondefault rule spacing as a soft option; that is, when routing resources are available, it honors the nondefault rule. If the area is too congested, and resources are not available, NanoRoute might not honor the rule. If you enable signal-integrity driven routing, NanoRoute attempts to minimize overall coupling capacitance in the design. If you enable timing-driven routing, NanoRoute also favors critical nets when choosing spacing. You can use up to 254 nondefault rules with NanoRoute. Nondefault rules do not necessarily decrease the routing speed. Routing speed does decrease, however, due to the following factors: ■ The ratio of nondefault rule wires to default rule wires increases. ■ The amount of space between wires increases. ■ The number of additional nondefault vias increases, due to the nondefault rules. In congested areas, NanoRoute might violate nondefault spacing rules in order to avoid design-rule violations and complete the routing. Its flexibility with regard to nondefault spacing decreases the overall wirelength and benefits timing and signal integrity because it allows some shorter nets to be more easily tolerated near adjacent nets without causing violations. Note: You can force NanoRoute to honor the nondefault rules by specifying setNanoRouteMode -strictlyHonorNonDefaultRule true. Figure 15-10 on page 451 illustrates nondefault spacing (“soft spacing”) routing in NanoRoute. May 2005 450 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Figure 15-10 With soft spacing, NanoRoute does not need to detour around these nets. With soft spacing some of the shorter nets that are close to other nets are tolerated. May 2005 451 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Repairing Process Antenna Violations NanoRoute repairs violations caused by the process antenna effect (PAE) in the postroute optimization phase. By default, NanoRoute repairs antenna violations by changing layers (also called antenna stapling or layer hopping), but it can also repair antenna violations by inserting diode cells as close as possible to input gates to discharge current. Note: After routing, run the globalNetConnect command to ensure connectivity to power and ground pins in antenna cells added during process antenna repair. For information, see globalNetConnect in the Encounter Text Command Reference. When NanoRoute calculates the PAE, it includes only the metal area of the gates and routes, not the metal area of the vias. You can adjust the calculations with -drouteAntennaFactor. The default value of this option is less than 1.0, which makes NanoRoute work harder to satisfy the process antenna requirements set in the LEF file. NanoRoute supports hierarchical process antenna calculations and repair. For information on PAE calculations, and the LEF and DEF antenna parameters, see “Calculating and Fixing Process Antenna Violations” in the LEF/DEF Language Reference. Changing Layers When it repairs process antenna violations, NanoRoute automatically shortens wires whose area exceeds the gate/wire area ratio set in the LEF file. This process might not guarantee that it can resolve all antenna violations—if the routing area is congested, process antenna violations can still occur, just as shorts and spacing violations can occur. Using Diodes NanoRoute can also repair process antenna violations by inserting antenna diode cells or using preplaced diode cells. NanoRoute can swap filler cells with antenna diode cells, and fill the gap automatically if an antenna diode cell is not the same size as the filler cell it replaced. A subsequent pass of NanoRoute will not remove any previously placed diodes. The antenna diode cells must have the same LEF SITE definition as the standard cells. You specify the diode cell name using the Diode Cell Name option on the NanoRoute form or the -routeAntennaCellName option on the text command line. May 2005 452 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Repairing Violations on Cut Layers NanoRoute detects antenna violations on cut layers and repairs them by inserting diodes. To repair these violations, you must specify a value in your LEF file for the ANTENNADIFFAREARATIO (or ANTENNACUMDIFFAREARATIO) for the cut layers. For each cut layer, the value for ANTENNADIFFAREARATIO (or ANTENNACUMDIFFAREARATIO) must be larger than the value for ANTENNAAREARATIO (or ANTENNACUMAREARATIO). If you do not use diodes to repair PAE violations, NanoRoute cannot repair the violations on cut layers. Tip To highlight the diodes that NanoRoute inserts, use the choose Edit – Select by Name. To highlight the diodes, type *_antenna_*. For information on the Select by Name form, see “Edit Menu” in the Encounter Menu Reference. ■ To specify the diode cells, use -routeAntennaCellName. ■ To specify the filler cells to remove, use -routeReplaceFillerCellList. ■ To specify the filler cells to fill in the gaps, use -routeReInsertFillerCellList. ■ To use preplaced antenna diode cells, use -routeUseExistingAntennaCells. Tip To force NanoRoute to do more layer changing, and skip diode insertion, specify the following option: setNanoRouteMode -routeInsertAntennaDiode false After NanoRoute repairs as many violations as possible by layer changing, reset this option to true and repeat process antenna repair. Making the Calculations More Conservative NanoRoute does not include the metal area of vias during process antenna calculations. To adjust the calculations, use the following option: setNanoRouteMode -drouteAntennaFactor. The default value for this option is 0.99. To make the calculations more conservative, reduce the value for this option. May 2005 453 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute NanoRoute Antenna Options Use the following NanoRoute options to repair violations caused by process antennas: ■ ■ setNanoRouteMode options: ❑ -drouteAntennaFactor ❑ -drouteFixAntenna ❑ -routeAntennaCellName ❑ -routeAntennaPinLimit ❑ -routeDeleteAntennaReroute ❑ -routeFixTopLayerAntenna ❑ -routeIgnoreAntennaTopCellPin ❑ -routeInsertAntennaDiode ❑ -routeInsertDiodeForClockNets ❑ -routeReInsertFillerCellList ❑ -routeReplaceFillerCellList ❑ -routeUseExistingAntennaCell setAttribute -nets netName -skip_antenna_fix Examples ■ The following commands shows the basic strategy for repairing process antenna violations using NanoRoute: setNanoRouteMode -drouteFixAntenna true setNanoRouteMode -routeAntennaCellName "ANTENNA" setNanoRouteMode -routeInsertAntennaDiode true globalDetailRoute globalNetConnect NanoRoute runs global and detailed routing. After repairing DRC violations, it repairs as many process antenna violations as it can by layer hopping during postroute optimization. If any process antenna violations remain, NanoRoute repairs them by inserting antenna diode cells named ANTENNA. May 2005 454 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute ■ The following commands repair process antenna violations by inserting diodes and filler cells. The filler cells are specified by the my_fillers.txt file. They fill any gaps that is left when a diode replaces large filler cell. setNanoRouteMode -routeInsertAntennaDiode true setNanoRouteMode -routeAntennaCellName "cell_A" setNanoRouteMode -routeReInsertFillerCellList my_fillers.txt globalDetailRoute globalNetConnect May 2005 455 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Using a Design Flow that Includes Astro or Apollo NanoRoute uses the information in the Astro technology file to automatically map vias and layers in the design to Astro scheme format. NanoRoute maps only the routing data, so it does not map DEF vias or special routing. To use Astro or Apollo in your design flow, you must have a LEF technology file that contains layer and via descriptions that match one-to-one with the descriptions in the Astro technology file. Caution Check with the foundry before making any changes to the original files. You can create a rule file to map layers or vias that are not mapped automatically. In native NanoRoute, the following commands are used in this flow: ■ generateLef Converts Astro technology file descriptions, Milkyway CLF files, customized LEF technology files from customers, and other older syntax and non-optimal LEF files to a LEF file with target rules and automatically generated vias. Issue this command before doing any routing with NanoRoute. ■ loadATFile Contains the path to the technology file required by Astro. Issue this command after loading the LEF file. You need to issue this command only once, since the mapping results are persistent. ■ tdfOut Outputs a routed database based on the mapping results. Issue this command after routing. If you are running NanoRoute in batch or standalone mode, issue the following command: ■ pdi export_design -aef -rule Finds the technology file and automatically maps the layers and vias from the LEF file to a format that Astro can read. Optionally, includes user-created rules for additional mapping. Issue this command after routing. The following command outputs a file named MyOutputFile, using a rule file named tfo.map: May 2005 456 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute pdi export_design -aef -rule tfo.map MyOutputFile If you do not need any additional mapping, the only line in tfo.map is techfile apollo.tf May 2005 457 Product Version 4.1.5 Encounter User Guide Routing Your Design With NanoRoute Troubleshooting If you have problems with your design, try the following troubleshooting tips: 1. Check the log file for errors and warnings. Correct the problems and continue routing or reroute, as appropriate. For example, NanoRoute might stop routing automatically if it finds too many violations. If NanoRoute stops unexpectedly, check the log file for a message that NanoRoute has reached the maximum number of violations and the -drouteAutoStop parameter should be set to false to continue routing. For more information on -drouteAutoStop, see the Encounter Text Command Reference. 2. Verify connectivity and geometry before and after routing and compare results. You can also use the checkRoute command to verify the connectivity. It is faster than verifyConnectivity, but does not output a report. 3. Save the database after routing and restore it in a new session in the Encounter software. Saving and restoring the database clears temporary data structures in memory. 4. If you routed the design with globalDetailRoute, reroute the design with globalDetailRouteBatch. The globalDetailRouteBatch command uses the routing information in the DEF file and the set of selected nets, and routes the design in standalone mode. 5. Issue the defOut command, then DefIn, and reroute. The defOut command saves all routing information in DEF and restores a clean database for routing. This step is similar to step 4. May 2005 458 Product Version 4.1.5 Encounter User Guide 16 Optimizing Metal Density This chapter describes how to add metal fill to your design to achieve optimum metal density. ■ Overview on page 460 ■ Before You Begin on page 460 ■ After You Complete Adding Metal Fill on page 460 ■ Specifying Metal Fill Parameters on page 461 ■ ❑ General Recommendations on page 462 ❑ Specifying the Active Spacing Value on page 463 ❑ Example on page 464 Using Floating Metal Fill on page 465 ❑ Specifying Parameters for Floating and Tied-off Metal Fill on page 469 ■ Adding Metal Fill Using the GUI on page 469 ■ Trimming Metal Fill ■ Verifying Metal Density on page 470 May 2005 459 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density Overview The dielectric layers in today’s complex chip designs often vary in thickness due to the different patterns of metal on successive metal layers. These variations can reduce yield and have an impact on chip performance. To minimize them, you can add inactive metal segments, called metal fill, to open areas of the design on a per-layer basis. The metal fill increases the density of metal on the metal layers, which makes the topology of all the metal layers more uniform, therefore reducing the thickness variations of the dielectric layers. The additional metal increases the capacitance, however, so it is important to balance the decrease in thickness variations with the increase in capacitance. The chip manufacturer usually specifies a target metal density percentage for the metal layers and a range of acceptable minimum and maximum metal density. Use the Encounter metal fill commands to add metal fill to a placed and routed design to achieve metal density within the acceptable range. The Encounter software uses parameters specified in the LEF file or the metal fill commands to analyze the metal density and determine the size and position of the metal fill. It divides the design into windows and adds metal to open areas in each window until the metal density is within the acceptable range. You can add metal fill to one or more routing layers at both the chip and block level. If you perform additional routing after inserting metal fill, you can trim away metal fill that causes DRC violations. Important Some chip manufacturers add fill to both metal and non-metal layers. This process is commonly called adding dummy fill. The Encounter software supports adding fill to metal layers only. Before You Begin Before adding metal fill, complete detailed routing on the design. After You Complete Adding Metal Fill After adding metal fill, extract parasitics and run timing and signal-integrity analysis. May 2005 460 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density Specifying Metal Fill Parameters Some of the metal fill parameters can be specified in the Layer (Routing) section of the LEF file. All of the parameters can be specified by the Encounter metal fill commands or forms. The parameters that can be specified in the LEF file are listed in the table below. If a parameter is specified in the LEF file, use the specified value. If a parameter is not specified, check the chip manufacturer’s DRC manual for the correct metal fill (or dummy fill) values and specify them manually with the command or form. Caution Do not override the values in the LEF file or the DRC manual—if not specified properly, metal fill can cause DRC violations and increase capacitance unnecessarily. If a parameter is specified in the LEF file and also specified manually, the manual specification overrides the LEF specification. The following table lists the metal fill parameters that can be specified in the LEF file and corresponding Encounter metal fill parameters: Description LEF Statements setMetalFill Parameter Setup Metal Fill Parameter Minimum distance between a segment of metal fill and another type of object in the design, such as a signal wire FILLACTIVESPACING -activeSpacing Active Spacing Minimum density allowed in the design MINIMUMDENSITY -minDensity Metal Density % Min Maximum density allowed in the design MAXIMUMDENSITY -maxDensity Metal Density % Max Area the Encounter software uses to examine metal density DENSITYCHECKWINDOW -windowSize Step Size X Step Size Y Distance the window moves for each metal fill iteration DENSITYCHECKSTEP -windowStep Window Size X Window Size Y May 2005 461 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density The Encounter software maintains the values specified for these parameters until you reset them or you restart the software. For more information on LEF, see the LEF/DEF Language Reference. General Recommendations Follow these recommendations for metal fill parameters that specify the preferred density, metal fill shape, the space between the metal fill segments, and whether to use metal fill that is connected to special wiring. These parameters are not specified in the LEF file. ■ Specify a preferred metal density between 25 percent and 40 percent. Metal density within this range minimizes the density variation in design windows as well as the impact on added capacitance. The reduced variation improves correlation with early RC estimates, that is, it gives you faster timing convergence, and increases yield. Determining the appropriate metal density is a process of balancing the decrease in density variation with the increase in capacitance: A density of 35 percent minimizes variation and increases the capacitance a moderate amount, a density of 25 percent adds less capacitance but does not decrease the variation quite as much. ■ Insert rectangular metal fill segments rather than square metal fill segments. You can achieve the preferred metal density with fewer pieces of rectangular metal fill than with square metal fill. Adding rectangular segments reduces the number of flashes on the reticle, minimizes the density variation across the design windows, and approaches the preferred metal density in more windows. The following dimensions for rectangular metal fill segments work with most 90 nm and 130 nm process rules: ❑ Length: 1 µm to 10 µm ❑ Width: Use the width specified in the chip manufacturer’s DRC manual for the minimum value. Use two to three times that value for the maximum width. For example, you can specify the following dimensions: ❍ 0.4 µm to 1.0 µm for thin layers ❍ 0.8 µm to 2.0 µm for thick layers Alternatively, for lower capacitance at the expense of more density variation, reduce the maximum width to the same value as the minimum width. May 2005 462 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density ■ Follow the chip manufacturer’s DRC manual for the spacing between metal fill shapes. This is called the gap spacing. The gap spacing is generally one to three times the minimum metal fill width. The following dimensions for gap spacing work with most 90 nm and 130 nm process rules: ❑ 0.4 µm for thin layers ❑ 0.8 µm for thick layers Alternatively, for lower capacitance at the expense of more density variation, use values like 0.8 µm for thin layers and 1.6 µm for thick layers. ■ Add metal fill to all metal layers or run the verifyMetalDensity command to determine where metal fill is needed. ■ Use metal fill that is not connected to special wiring. Unconnected (floating) metal fill adds less capacitance to the design and is easier for postroute and postmask changes to handle than connected (tied-off) metal fill. Alternatively, you can use tied-off metal fill whenever possible and floating metal fill when tied-off metal fill cannot be created. Either method is more likely to meet the preferredmetal density requirements than using tied-off metal fill throughout the design. For more information, see “Using Floating Metal Fill” on page 465. Specifying the Active Spacing Value The space between metal fill and nonmetal-fill geometries is called the active spacing, as shown in the following figure. signal wire active spacing metal fill active spacing signal wire The Encounter software uses the FILLACTIVESPACING value in the LEF file for the active spacing. If FILLACTIVESPACING is not specified, you can set it manually by using one of the following methods: May 2005 463 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density ■ Specifying a value for setMetalFill -activeSpacing on the text command line ■ Specifying a value for Active Spacing on the Setup Metal Fill form If no value is specified in the LEF file, and you do not specify one manually, the software uses two times the LEF minimum spacing value as the default active spacing value. The default active spacing value is usually large enough that you can avoid using Optimal Pattern Correction (OPC) for the metal fill shapes. In addition, the default active spacing minimizes the increase in cross-coupling capacitance caused by the metal fill, which in turn reduces the additional timing delay. As you increase the active spacing value, you reduce the space available for metal fill. A large increase—for example, 2 µm to 3 µm for a 90 nm or 130 nm process—might prevent you from meeting the minimum density rule for some windows. Example The following example specifies conservative values for a 90 nm or 130 nm eight-layer design where metal layers 1 through 6 are thin metal and metal layers 7 and 8 are thick metal. The following command sets values for the active spacing, window size, window step, minimum density, and maximum density for all eight layers: setMetalFill -layer "1 2 3 4 5 6 7 8" -activeSpacing 0.6 \ -windowSize 100 -windowStep 100 \ -minDensity 20 -maxDensity 70 The following command sets values for the gap spacing, preferred density, minimum and maximum width, and minimum and maximum length for the thin-metal layers: setMetalFill -layer "1 2 3 4 5 6" -preferredDensity 35 -gapSpacing 0.4 \ -minWidth 0.4 -maxWidth 1.0 \ -minLength 1.0 -maxLength 10.0 The following command sets values for the gap spacing, preferred density, minimum and maximum width, and minimum and maximum length for the thick-metal layers: setMetalFill -layer "7 8" -preferredDensity 35 -gapSpacing 0.8 \ -minWidth 0.8 -maxWidth 2.0 -minLength 1.0 -maxLength 10.0 The following command adds metal fill to all eight layers: addMetalFill -layer "1 2 3 4 5 6 7 8" May 2005 464 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density Using Floating Metal Fill The following figures show a section of a design with metal fill. In the first figure, all the metal fill is floating. In the second figure, some of the metal mill is floating and some is tied off. In the third figure, all of the metal fill is tied off. May 2005 465 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density Floating metal fill Floating and tied-off metal fill Tied-off metal fill M4 Vdd May 2005 M4 Vss M5 Fill 466 M4 Fill M4M5 Via Product Version 4.1.5 Encounter User Guide Optimizing Metal Density The following figures show the same design after an ECO, in which routing was added on metal3 and metal4. These figures show what happens when you use floating metal fill. The first figure shows the design with the added routing. The second figure shows the design after the metal fill is trimmed. The dotted lines show where the metal fill was trimmed. New routing on metal3 and metal4 M4 Vdd May 2005 M4 Vss M5 Fill 467 M4 Fill M4M5 Via Product Version 4.1.5 Encounter User Guide Optimizing Metal Density These figures show what happens when you use tied-off metal fill. The first figure shows the design with the added routing. The second figure shows the design after the metal fill is trimmed. The dotted lines show where the metal fill was trimmed. New routing on metal3 and metal4 M4 Vdd M4 Vss M5 Fill M4 Fill M4M5 Via When the metal fill is tied off, the vias cause problems during trimming. ■ If the vias are not deleted, they cause shorts to the new wires. ■ If the vias are deleted, the following problems might occur: ❑ An isolated piece of previously tied-off metal fill might be left after trimming. ❑ If the new routing was added during an ECO in which some layers were frozen, the change might affect a layer that should have been left frozen. May 2005 468 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density Specifying Parameters for Floating and Tied-off Metal Fill If you include tied-off metal fill in the design, use one of the following methods to control floating metal fill. Allowing Rectangular Floating Metal Fill This method allows rectangular metal fill, which can be either floating or tied-off. It also allows floating square-shaped metal fill. This is the default behavior, so you do not need to specify additional parameters on the text command line. In the GUI, make the following selections on the Basic page of the Metal Fill form: ■ Select Shape: Rectangle. ■ Select Keep unconnected metal fill(s). ■ Deselect Square shape. Preventing Floating Metal Fill This method allows only rectangular metal fill that is tied-off. On the text command line, include the following parameters: -removeFloatingFill -nets netNameList In the GUI, set the following options on the Basic page of the Metal Fill form. ■ Select Shape: Rectangle ■ Select Tie High/Low to net(s) and specify at least one net name in the text entry field. ■ Deselect Keep unconnected metal fill(s). Adding Metal Fill Using the GUI 1. Determine the minimum and maximum size for metal fill shapes for each layer, then set these values on the Size & Spacing page of the Setup Metal Fill form. ❑ May 2005 If you are using rectangular metal fill, use the Rectangle Length and Metal Fill Width values. 469 Product Version 4.1.5 Encounter User Guide Optimizing Metal Density ❑ If you are using square metal fill, use the Metal Fill Width and Square Decrement values. 2. Determine the spacing around metal fill shapes for each layer, then set the value on the Size & Spacing page of the Setup Metal Fill form. You must set two types of spacing values: ❑ Spacing between a metal fill shape and an active metal shape. An active metal shape can be a signal wire, a power wire, a cell, a pin, or any other structure that is not classified as a fillwire. ❑ Spacing between a metal fill shape and another metal fill shape. 3. Determine the minimum, maximum, and preferred metal density for each layer, then set these values on the Window & Density page of the Setup Metal Fill form. 4. Use the Verify Metal Density form to create a Verify Density report. 5. Locate an area in the design for which metal density is too low, then select that area on the Add Metal Fill form. 6. Determine whether you want metal fill to be square or rectangular, then choose the appropriate value on the Add Metal Fill form. 7. Click OK or Apply on the Add Metal Fill form to add metal fill shapes to the area that you specified. Trimming Metal Fill Some Encounter components do not recognize metal fill in the design. These components can create routes that cause shorts with existing metal fill. To remove these shorts, issue the trimMetalFill command. After issuing this command, verify that the metal density is within the acceptable range. Verifying Metal Density After adding or trimming metal fill, use the Verify Metal Density and Verify Geometry features to verify that the metal fill has been added correctly. For more information, see Chapter 25, “Verifying Violations.” May 2005 470 Product Version 4.1.5 Encounter User Guide 17 Timing Budgeting SoC Encounter™ provides timing budgeting based on the timing results of floorplanning, placement and trial route. This chapter presents the following topics: ■ Overview on page 472 ■ Deriving Timing Budgets on page 474 ■ Analyzing Timing Budgets on page 476 ■ Calculating Timing Budgets on page 483 ■ Customizing the Budget Generation on page 485 ■ Verifying The Timing Budgets on page 488 ■ Reading the Budget Report on page 490 ■ Constraints Support in Budgeting on page 498 May 2005 471 Product Version 4.1.5 Encounter User Guide Timing Budgeting Overview In hierarchical design flows, chip-level timing constraints must be mapped correctly into corresponding block-level constraints. The Encounter software does this automatically to produce predictable timing convergence. The Encounter software apportions budgets to blocks using path-based method, which might not have a direct relationship to the size of the blocks themselves. Encounter supports three ways to do timing budgeting in hierarchical designs: ■ Without Trial IPO Timing optimization is not run before generating budgets at the port boundaries. ■ With Boundary Trial lPO (the default) Timing optimization fixes are done for the top-level nets between partitions before generating budgets, Trial IPO fixes are not inserted in the design, and real timing optimization operations are done at a later time. ■ With Full Trial IPO Timing optimization fixes are done for the entire design before generating budgets, Trial IPO fixes are not inserted in the design, and real timing optimization operations are done at a later time. May 2005 472 Product Version 4.1.5 Encounter User Guide Timing Budgeting The following figure shows how timing budgeting is performed within the overall design flow. Read Timing constraints Complete floorplanning Perform Top-Level Placement Run Trial Route Perform Partitioning Derive Timing Budgets Save Timing Budgets Verify Timing Budgets Budgeted Constraints May 2005 473 Product Version 4.1.5 Encounter User Guide Timing Budgeting Deriving Timing Budgets You can generate timing budget constraint files for each top-level partition using either the Partition graphical user interface (GUI) or the various text commands. To generate the constraints files using the GUI, complete the following steps: 1. Read in the timing constraint file during design import. 2. Complete the floorplan for the design being partitioned. The more complete the floorplanning, the better the timing budgeting results. 3. Run top-level Placement and Trial Route, choosing Medium Effort for both. 4. On the Partition form, choose the Perform Pin Assignment and Derive Timing Budget options. 5. Use the Save Partition form (Design – Save – Partition) to save the partitions to their directories. The directories are called topCellName for the top-level and partitionName for the partitions. For each partition, this procedure creates the timing constraint files named partitionName.constr for dc_shell and partitionName.constr.pt for PrimeTime format. These files are located in each partition directory. The library model files, partitionName.lib, are created in the top-level directory. The constraints file top_level.top.constr is created for the top level. To generate the constraints files using the text commands, complete the following steps: 1. Read in the timing constraint file during design import. 2. Complete the floorplan for the design being partitioned. The more complete the floorplanning, the better the timing budgeting results. 3. Run top-level placement and trial route. 4. Perform partitioning. 5. Derive the timing budgets using the deriveTimingBudget command with -ptn parameter. 6. Save the derived budgets using the saveTimingBudget command with -ptn parameter. 7. Verify the generated budgets using the justifyBudget command. May 2005 474 Product Version 4.1.5 Encounter User Guide Timing Budgeting Note: You can use the deriveTimingBudget command with -inst parameter to derive timing budgets without generating partitions before running the command. However, in this case you will not be able to use justifyBudget command to verify the results. May 2005 475 Product Version 4.1.5 Encounter User Guide Timing Budgeting Analyzing Timing Budgets To analyze timing budgets, you must first identify all the boundary pins of the partitions. For each partition pin, the Encounter software generates timing constraints in the form of timing set_input_delay or set_output_delay if the pin is an input or output pin, respectively. The software divides the total available budget among all partitions involved, where their boundary pins constitute part of the path. A pin might have multiple paths going through it. The multiple paths through a single point might result in conflicts. Therefore the software uses the path that you specify using the various parameters of the deriveTimingBudget command as resolution for the conflict and designates it as a candidate for the budget allotment. Resolving Multiple Path Conflicts In complex designs, that is when multiple paths go through a single point, path exceptions can be resolved by timing budgeting. To do this, you use the following parameters of the deriveTimingBudget command: ■ –min Uses minimum cycle time when there are multiple paths constraints. For the partition port that has multi-cycle paths, this parameter first selects all the paths with least number of cycles, usually paths with only one cycle to do the budgeting. Then, selects the worst slack path from these paths and performs proportioning using this path. This gives the value of budgets. ■ -max Uses the maximum cycle time when multiple paths of different constraints go through a port of an instance. If one path through a port is constrained by the set_max_delay constraint and the other path through the same port by a single-cycle or a multi-cycle, the set_max_delay constraint takes precedence. For the partition port that has multicycle paths, this parameter first selects all the paths with most number of cycles to do the budgeting. Then, selects the best slack path from these paths and performs proportioning using this path. ■ -critical Uses the path with the worst slack value regardless of the number of cycles. ■ -multiClock Generates multiple input and output delay constraints for partition ports based on the clock and clock edge. Using the –multiClock parameter, Encounter combines May 2005 476 Product Version 4.1.5 Encounter User Guide Timing Budgeting constraints propagated through partition port based on the controlling clock and clock edge, and produces one set_input_delay and set_output_delay statement per clock and clock edge. ■ –combined Generates a set_input_delay and set_output_delay statement for each constraint propagated through the partition port. This parameter considers all the paths going through the port, and separates them into groups depending on the launching clock, capturing clock and number of cycles. The maximum delay paths result in more number of groups.The parameter then selects the path with worst slack from each group, and creates an input and output delay. The software generates a virtual clock for each group for input and output. The input and output delays reference to these virtual clocks. Consider the following figure. Figure 17-1 Multiple Path Exceptions Resolution My_partition A partitionB OUT In0 FF0 FF1 CLK FF There is a set_multicycle_path 2 -from My_partition/FF0/CK -to PartitionB/FF1/D. There are multiple constraints going through port In0; a single-cycle path from FF0 to FF and a multi-cycle path of 2 from FF0 to FF1. Budgets for Partition B are different depending on -min, -max, -critical and -combined parameters. Depending on the parameter set, the set_input_delay In has different values. Using the -min parameter, budgeting uses a budget of one cycle. When you use the -max parameter, the max cycle time is two cycles for the design in the figure above. May 2005 477 Product Version 4.1.5 Encounter User Guide Timing Budgeting When you use the -critical parameter for the design in the figure above, either path from My_Partition/FF0 to PartitionB/FF1 or path from My_Partition/FF0 to PartitionB/FF2 are considered depending on the criticality of the path. The following example shows how the usage of -combined parameter affects the budgeted constraints. Figure 17-2 Multiple Path exceptions resolution; -combined My_partition TOP OUT1 FF1 IN IN2 I OUT2 0.5ns FF2 Clk Clk In this example, the constraints set at top-level are: create_clock -name Clk -period 4 [get_ports {Clk}] set_input_delay 1 -clock [get_clocks {Clk}] [get_ports {IN}] set_input_delay 1 -clock [get_clocks {Clk}] [get_ports {IN2}] set_multicycle_path 2 -from [get_ports {IN}] -to [get_pins {My_partition/FF1/D}] In performing timing budgeting on My_partition from Top, Encounter defines a new virtual clock at port I to capture the multicycle path from IN to My_partition/FF1/D. Virtual clock is a clock that is not associated with an actual port of the design. Input delay is defined to capture the multicycle path. The add_delay constraint is used to capture information about multiple paths leading to an input port that are relative to different clocks or clock edges. Because there are no paths between the virtual clocks and clk, false paths are generated. Budgeted constraints for My_partition are: create_clock -name {CLK} -period 4.000 -waveform { 0.000 2.000 } \ [list [get_ports {CK}] ] -add create_clock -name {clk_virtual_1} -period 4.000 -waveform { 0.000 2.000 } create_clock -name {clk_virtual_0} -period 4.000 -waveform { 0.000 2.000 } May 2005 478 Product Version 4.1.5 Encounter User Guide Timing Budgeting set_input_delay 1.5 -clock [get_clocks {clk_virtual_0}] [get_ports {I}] -add_delay set_input_delay 3.5 -clock [get_clocks {clk_virtual_1}] [get_ports {I}] -add_delay set_multicycle_path 2 -from [get_clock {clk_virtual_1}] -to [get_pins {FF1/D}] set_false_path -from [get_clocks {clk_virtual_1} ] -through [get_ports{I} ] \ -to [get_pins {FF2/D} ] set_false_path -from [get_clocks{clk_virtual_0}] -through [get_ports{I} ] \ -to [get_pins {FF1/D}] The commitPartition –max parameter is the default since the intention is to fix the multi-cycle paths first. The other parameters can be applied through successive budget refinement, and eventually lead to fast timing closure. Logic Push-Down of Multi-Point False Paths The Encounter software provides the functionality to derive budgets for single point and multipoint false paths. The software supports all single-point false paths (applied at the top-level or into the block) as well as false paths that lie outside of the partition. The software pushes down the false paths that are completely enclosed in the partition into the partition. For example, in the following figure, false path through A to FF1/D is enclosed in partition. Therefore the path is pushed down into the partition and the software generates the budgeting constraints accordingly. Figure 17-3 Single Point False Path A FF1 Figure 1-4 shows multi-point false paths that lie outside the partition. May 2005 479 Product Version 4.1.5 Encounter User Guide Timing Budgeting Figure 17-4 Multi-Point False paths My_partition FF1 CLK1 A A1 D FF3 B FF2 CLK2 FF4 CLK3 You can set the following false path in this case: set_false_path -through A1/A –to My_partition/FF3 The software creates a virtual clock for the start point of the false path. The output constraints are generated based on the virtual clock. In case of fig. 1-4, the virtual clock, V1, is created on the clock pin of FF1. The software generates the following constraints: set_input_delay with CLK2 set_input_delay with V1 set_false_path -from V1 -to FF3 To set the false path, you use the -falsePath parameter of the deriveTimingBudget command. Budgeting Clock Latency in Propagated Mode The Encounter software includes clock latency in the constraints generated for clocks in propagated mode. The clock latency is included in the set_input_delay and set_output_delay constraints. The clock latency is added to set_input_delay and subtracted from the set_output_delay. This feature is useful when clock tree is present in your design. For multiple paths (-min, -max, -critical, -combined), both source and propagated clock latency is included in the set_input_delay and set_output_delay constraints. The software adds -source_latency_included and -network_latency_included May 2005 480 Product Version 4.1.5 Encounter User Guide Timing Budgeting in the set_input_delay and set_output_delay constraints for all inputs and outputs related to clocks in propagated mode. Consider the following figure. Sub Out1 In1 A FF0 FF1 comb CLK FF2 Subclk The deriveTimingBudget -min | -max | -critical or commitPartition -min | -max | -critical commands result in the following constraints for the Sub partition: create_clock -clock subclk -waveform... set_clock_latency -source (top_source + 0.2 + 0.2 + 0.2) subclk set_input_delay -clock subclk (Input delay + top_source + 0.2) -source_latency_included -network_latency_included In1 set_output_delay -clock subclk (output_delay -top_source -0.2) -source_latency_included -network_latency_included Out1 Where, top_source = source latency of the clock at the top level 0.2 = delay through each buffer in the clock network For -combined, for path originating from primary input and output and path originating from register, all clock latency is included in the port constraint. In this case, the source latency is May 2005 481 Product Version 4.1.5 Encounter User Guide Timing Budgeting written out as source_latency constraint for the generated clock controlling set_input_delay and set_output_delay. Consider the following figure. Sub In0 Out1 In1 FF1 comb CLK FF2 Subclk For the figure above, the FF2 has multicycle path paths. Using deriveTimingBudget -combined or commitPartition -combined, the following constraints are generated: create_clock -name virtual_0 -period x set_input_delay -clock virtual_0 (ID at In0 + budget delay + top_source) -source_latency_included -network_latency_included -add_delay Where, top_source is the source latency of the clock with respect to which the input delay is set. May 2005 482 Product Version 4.1.5 Encounter User Guide Timing Budgeting Calculating Timing Budgets Encounter proportions timing budget for partitions based on the path segment length, with a slight difference in calculation when the slack on a path is positive or negative. For paths with negative slack, the proportioning formula for a setup check (max budgeting) is: SD/TD * AT = BB(neg) For paths with negative slack, the proportioning formula for a hold check (min budgeting) is: SD/TD * (AT + HT)= BB(neg) Note: If AT + HT is less then zero, the software does not use the proportioned value. The software uses the timing analysis values for input or output delays. For paths with positive slack, the proportioning formula for a setup check (max budgeting) is: SD + SD/TD * PS = BB (pos) For paths with positive slack, the proportioning formula for a hold check (min budgeting) is: SD - SD/TD * PS = BB (pos) where: ■ SD is the delay through a path segment. ■ TD is the total delay of the path. ■ AT is the total available time. This could be the number of clock periods for multicycle paths, or the clock period minus the fixed delays. ■ HT is the hold time. ■ BB is the baseline budget ■ PS is the positive slack Example 17-1 Negatively Slacked Path In this example, block A is connected to block B via top-level net C. The budget of the toplevel net is not fixed. When placed and routed, path segment through block A needs 3ns, path May 2005 483 Product Version 4.1.5 Encounter User Guide Timing Budgeting segment through block B needs 2ns, and net C requires 1ns. The available time to be budgeted is 5ns. A=3 B=2 C=1 The software calculates the following values: Budget for block A = 3/6 * 5 = 2.5ns Budget for block B = 2/6 * 5 = 1.67 Budget for net C = 0.83 Output delay at A = Budget for block B + Budget for net C Input delay at B = Budgets for blocks A + Budget for net C Example 17-2 Positively Slacked Path In this example, path segment through block A, B, and net C require 1ns each. The total delay is 3 ns. The total available budget is 5ns. Therefore positive slack is 2ns. A=1 B=1 C=1 The software calculates the following budget values: Budget for A, B, and C = 1 + 1/3 * 2 = 1.66ns May 2005 484 Product Version 4.1.5 Encounter User Guide Timing Budgeting Customizing the Budget Generation You can customize budget generation according to the design stage and timing requirements. To customize budget generation, you can use the following commands in Encounter: ■ The -freezeTopLevel parameter of the deriveTimingBudget or commitPartition command fixes the top-level timing budget and proportions the timing budget for the partitions. The commands consider blocks that are not being budgeted as fixed. If the top-level design has no buffers or glue logic, using the -freezeTopLevel parameter might not make much difference in the generated budgets. ■ The commitPartition [-ignoreDontTouch | -noIgnoreDontTouch] command is used to consider don’t_touch blocks. The -noIgnoreDontTouch parameter considers don’t_touch as fixed delay. The -ignoreDontTouch parameter does not consider don’t_touch as fixed delay. The budgeting results change based on whether fixed delay is considered during trial IPO. ■ At the top-level, you can set the set_input_delay and set_output_delay constraints on the hierarchical ports (or partition ports). The Encounter software generates budgets for the hierarchical ports based on the set constraints. ■ For negative slack paths use the –snapBudget parameter of the saveTimingBudget or savePartition command. This parameter reserves a certain percentage of available budget for the top level or partitions. The remainder of the available budget is proportioned to the partitions based on path segment length. This prevents underbudgeting of the top level or partitions. Before using the –snapBudget parameter, run the setThresholdBudgetRatio command with no parameters to set the threshold budget ratio as the percentage of the overall available budget. The software uses this percentage to reserve budgets for the partitions when you use the -snapBudget parameter. To use the -snapBudget parameter, complete the following steps: a. setThresholdBudgetRatio 0.05 b. deriveTimingBudget SH17 SH25 c. saveTimingBudget -snapBudget -dir ptn -pt May 2005 485 Product Version 4.1.5 Encounter User Guide Timing Budgeting Example 17-3 Using the savePartition Command In the following example, path segment through block A requires 6ns, path segment through block B requires 0.1ns, and net C requires 2ns. The available time to be budgeted is 5ns. A=6 B = 0.1 C=2 The software saves the following budgets when you use the saveTimingBudget command without the -snapBudget parameter: Budget for block B = 0.1/8.1 * 5 = 0.06 Budget for block A = 6/8.1 * 5 = 3.70 Budget for net C = 1.24 The software saves the following budgets when you use the setThresholdBudgetRatio command with a ratio of 0.05, and the saveTimingBudget command with the -snapBudget parameter. Budget for block B = snapped to 5% of 5 ns = 0.25ns The remaining allowed time = 5 – 0.25 = 4.75 ns Budget for block A = 6/8 * 4.75 = 3.56 Budget for net C = 2/8 * 4.75 = 1.19 ■ For positive slack paths, use the setThresholdBudgetRatio -nonFailing command which changes the budgets when non failing paths exist in the design. The nonFailing parameter specifies the ratio at which the residual budget (positive slack) is proportionally reallocated after the specified percentage is reserved for the top-level. The default value for the -nonFailing parameter is 0.2. May 2005 486 Product Version 4.1.5 Encounter User Guide Timing Budgeting Example 17-4 Using the -nonFailing Parameter In the following example, the delay through partitions A, B, and C is 5ns, 2ns, and 1ns respectively. The available time to be budgeted is 10ns. A=5 B=2 C=1 The setThresholdBudgetRatio –nonFailing 0.2 command reserves 20% of the clock positive slack for top-level. The software then proportions the rest of the positive slack. Therefore, positive slack = 10 – 8 = 2ns Time reserved for the partitions = 2 – (0.2 x 2) = 1.6 ns The input delay at the input port at partition B increases. Similarly the output delay at the output port of Partition A also increases. set_input_delay at block B = 6/8 * 1.6 + 6 = 7.2 ns set_output_delay at block A = 3/8 * 1.6 + 3 = 3.6 ns ■ The setThresholdBudgetRatio –topLevel command specifies the minimum percentage of available allowed time to be set aside for the top. For example, if the clock period is 10ns and this minimum value is set to 0.1, then 10 percent of the clock period is set aside for top-level. The remaining 9ns will be proportioned between the partitions. May 2005 487 Product Version 4.1.5 Encounter User Guide Timing Budgeting Verifying The Timing Budgets The Encounter software provides feedback on how the budgets are generated. The feedback is provided in a budget report file. You can verify the timing budgets by analyzing the results in the report file. To verify timing budget values, generate the report file by completing the following steps: 1. Derive budgets for partitions. In the command tool (console) window, type the following: deriveTimingBudget -ptn partitionName The deriveTimingBudget command generates the timing models and stores them in the partition directories. By default, the command generates budgets for setup mode only even if you use the setAnalysisMode command to set the mode as hold. To generate budgets for both setup and hold mode, use the -setupHold parameter. deriveTimingBudget -ptn partitionName -setupHold Note: To derive budgets for instances, use the -inst parameter in the deriveTimingBudget command. 2. Verify the generated budget for any partition pin by typing the following: justifyBudget -pins pinList -outfile fileName partitionName The justifyBudget command generates the debug data to justify timing budget for the given pin. The command creates a budget report containing the timing budget value for each pin and partition. By default, the justifyBudget command generates debug data for setup mode only. To analyze both setup and hold budgets, you must use the -setupHold parameter in the deriveTimingBudget command and set the setAnalysisMode command to -setup or -hold. You can analyze either setup or hold budgets at a time. To verify budgets in the hold mode, complete the following steps: deriveTimingBudget -ptn partitionName -setupHold setAnalysisMode -hold justifyBudget -pins In1 SUB1 Note: To verify the budgets for instances, use the instanceName parameter in the justifyBudget command. 3. Save the generated budgets by typing the following: saveTimingBudget -ptn partitionName The saveTimingBudget command saves time budget files of specified hierarchical instances to a specified directory. If you specify the -setupHold parameter in the May 2005 488 Product Version 4.1.5 Encounter User Guide Timing Budgeting deriveTimingBudget command, the saveTimingBudget command saves both setup and hold budgets. May 2005 489 Product Version 4.1.5 Encounter User Guide Timing Budgeting Reading the Budget Report You use the justifyBudget command to generate the debug data to justify the timing budget for a pin. For a negatively slacked path, the software distributes the total available time (in a simple clock period case) proportionally between ports of instances along the path. For a positively slacked path, the software usually adds some buffer delays to the generated delay values (built in positive slack). The report generated by the justifyBudget command contains the following fields: ■ Adjustment for budget available time This number is derived as follows: Path Fixed Delay + Fixed Delay For Feedthrough Blocks - Clock Skew + Value of Constraint for the Receiving Register (holdConstrValue) Where, Fixed Delay For Feedthrough Blocks is the two buffer delay distributed between all feedthrough blocks. ■ Adjustment by fixed delay This number specifies the delay that cannot be modified. The fixed delay are values set by set_input_delay and set_output_delay at the primary inputs and outputs. In addition if you use –freezeTopLevel parameter during budgeting, the delay through top-level components and the don’t_touch blocks are displayed in this field. ■ Adjustment by virtual clock This number specifies a special adjustment to map the virtual clock into clocks pertaining to partitions. This number is generated when you use the saveTimingBudget noVirtualClock command. ■ Adjustment by net delay This number specifies the delay through the net between partition port and pin of the gate on the path. For input ports it is the delay between partition port and an input of the first gate on the path. For output pins, it is the delay between output of the last gate on the path and an output port. ■ Adjustment by RC This number specifies the input delays. During timing analysis the input delays are adjusted by the delay due to input port drive cell that was added by budgeting as a set_drive command in the generated constraint file. The Adjustment by RC number is subtracted from the delay value in budgeting so that this effect is not counted twice in the budget. May 2005 490 Product Version 4.1.5 Encounter User Guide Timing Budgeting ■ Adjustment by clock latency This number specifies the clock latency of the driving object. ■ Total Delay This number specifies the total path delay. ■ Initial Slack Initial Slack = (Data Required Time - fixed delay) – (Path segment number1 delay + Path segment number 2 delay). ■ Virtual Buffering Adjustment This number specifies the total extra delays added to the positive slacked path. This number is usually three extra buffer delays. In case of abutted designs, the number is two extra buffer delays. Note: In case of feedthru paths, three buffer delay is distributed through all segments of the path. ■ Buffering Adjusted Slack The Encounter software takes out three buffer worth of delay from positive slack to safeguard minimum partition budget. This adjustment is used only for positive slacks. ■ External Buffering Adjustment This number specifies the extra delay that is external to partition port. This is usually equivalent to two buffer delays. This is part of the virtual buffering adjustment. This delay is added to the input delay of the port. ■ Budget Budget = Adjustment for budget available time * Delay for path outside the partition / Absolute total delay + Adjustment by fixed delay + Adjustment by virtual clock + Adjustment by clock latency - Adjustment by RC + External Buffering Adjustment May 2005 491 Product Version 4.1.5 Encounter User Guide Timing Budgeting Example 17-5 Negative and Positive Slack Reports Using justifyBudget The following design is used for this example. Figure 17-5 Design Example sub1 sub1_in1 in1 D Q FF1 W2 buf1_1 D Q FF1 W8 buf1_2 out1 clk1 clk1 clk1 sub1_out1 sub1_w1 sub1_w2 sub1_clk1 sub1_out2 D Q FF1_1 buf1_3 D Q FF1 W7 out2 clk1 The following reports are generated for paths with positive and negative slacks with the justifyBudget command: ■ “Paths With Negative Slack” on page 492 ■ “Paths With Positive Slack” on page 494 Paths With Negative Slack To validate the budgets for design example in Figure 17-5 with negative slack, specify the following command: Encounter > justifyBudget -pins sub1_in1 inst1 The following report is generated: Partition: inst1 Port: sub1_in1 Constraint: set_input_delay(setup rise) One buffer delay for adjustment: 1.000 Adjustment for budget available time= (pathFixedDelay+fixedDelayForFeedThroughBlocks-clockSkew) Adjustment for budget available time= -(0.000+0.000--4.000)=-4.000 Adjustment by fixed delay: 0.000 Adjustment by virtual clock: 0.000 Adjustment by net delay: 0.000 Adjustment by clock latency: 0.000 May 2005 492 Product Version 4.1.5 Encounter User Guide Timing Budgeting Total delay: 1.000 + 2.006 = 3.006 Absolute total delay: 3.006 Budget = 2.000 * 1.000 / 3.006 + 0.000 + 0.000 + 0.000 = 0.665 Rise delay from startpoint: 1.000 -------------------------------------------------------------------------------Path #: 1 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: inst1/ff1_1/D (Setup time: 1.000, clocked by CLK2 R) Data required time: 2.000 (skew: -4.000 adjusted 1 cycle) Data arrival time: 3.006 Slack: -1.006 (SETUP VIOLATION) Object name Delta r/f (ns)Sum r/f (ns) Slew (ns) Load (pf) Cell Location (um) ------------------------------------------------------------------------------ff1 CK->Q (ssfd1) 1.000r/1.000f 1.000r/1.000f 0.120r/0.120f 0.170 (514.50, 517.40) w2 0.000r/0.000f 1.000r/1.000f ------------------------------------------------------------------------------Rise delay to endpoint: 2.006 -------------------------------------------------------------------------------Path #: 2 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: inst1/ff1_1/D (Setup time: 1.000, clocked by CLK2 R) Data required time: 2.000 (skew: -4.000 adjusted 1 cycle) Data arrival time: 3.006 Slack: -1.006 (SETUP VIOLATION) Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load Cell Location (pf) (um) --------------------------------------------------------------------------------inst1/buf1_1 A->Y (ssiv) 1.000f/-r inst1/sub1_w1 1.000f/-r1.000r/1.000f0.215(487.50, 504.40) 0.007f/0.007r1.006f/-r inst1/ff1_1 CK^^D (ssfd1)1.000f/1.000r2.006f/-r1.000f/1.000r (483.00, 530.40) --------------------------------------------------------------------------------Partition: inst1 Port: sub1_in1 Constraint: set_input_delay(setup fall) One buffer delay for adjustment: 1.000 Adjustment for budget available time= -(pathFixedDelay+fixedDelayForFeedThroughBlocks-clockSkew) Adjustment for budget available time= -(0.000+0.000--4.000)=-4.000 Adjustment by fixed delay: 0.000 Adjustment by virtual clock: 0.000 Adjustment by net delay: 0.000 Adjustment by clock latency: 0.000 Total delay: 1.000 + 2.006 = 3.006 May 2005 493 Product Version 4.1.5 Encounter User Guide Timing Budgeting Absolute total delay: 3.006 Budget = 2.000 * 1.000 / 3.006 + 0.000 + 0.000 + 0.000 = 0.665 Fall delay from startpoint: 1.000 --------------------------------------------------------------------------------Path #: 1 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: inst1/ff1_1/D (Setup time: 1.000, clocked by CLK2 R) Data required time: 2.000 (skew: -4.000 adjusted 1 cycle) Data arrival time: 3.006 Slack: -1.006 (SETUP VIOLATION) Object name Delta r/f (ns)Sum r/f (ns) Slew (ns) Load (pf) Cell Location (um) ------------------------------------------------------------------------------ff1 CK->Q (ssfd1) 1.000f/1.000r 1.000f/1.000r 0.120f/0.120r 0.170 (514.50, 517.40) w2 0.000f/0.000r 1.000f/1.000r ------------------------------------------------------------------------------Fall delay to endpoint: 2.006 --------------------------------------------------------------------------------Path #: 2 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: inst1/ff1_1/D (Setup time: 1.000, clocked by CLK2 R) Data required time: 2.000 (skew: -4.000 adjusted 1 cycle) Data arrival time: 3.006 Slack: -1.006 (SETUP VIOLATION) Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load Cell Location (pf) (um) --------------------------------------------------------------------------------inst1/buf1_1 A->Y (ssiv) 1.000r/-f inst1/sub1_w1 1.000r/-f1.000f/1.000r0.215(487.50, 504.40) 0.007r/0.007f1.006r/-f inst1/ff1_1 CK^^D (ssfd1)1.000r/1.000f2.006r/-f1.000r/1.000f (483.00, 530.40) --------------------------------------------------------------------------------- Paths With Positive Slack To validate the budgets for design example in Figure 17-5 on page 492 with positive slack, specify the following command: Encounter> justifyBudget -pins sub1_in1 inst1 The following report is generated: Partition: inst1 Port: sub1_in1 Constraint: set_input_delay(hold rise) May 2005 494 Product Version 4.1.5 Encounter User Guide Timing Budgeting One buffer delay for adjustment: 1.000 Adjustment for budget available time= -(pathFixedDelay+fixedDelayForFeedThroughBlocks-clockSkew+holdConstrValue) Adjustment for budget available time= -(0.000+2.000-0.000+-1.000)=-1.000 Adjustment by fixed delay: 0.000 Adjustment by virtual clock: 0.000 Adjustment by net delay: 0.000 Adjustment by clock latency: 0.000 Total delay: 1.000 + 2.013 = 3.013 Absolute total delay: 3.013 Initial Slack: 3.013 - -1.000 = 4.013 External Buffering Adjustment: 0.000 Budget = 1.000 - 0.000 + 0.000 + 0.000 + 0.000 = 1.000 Rise delay from startpoint: 1.000 Path #: 1 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: ff4/D (Hold time: 1.000, clocked by CLK1 R, latency: 4.000) Data required time: 0.000 (1 cycle) Data arrival time: 2.013 Slack: 2.013 Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load Cell Location (pf) (um) --------------------------------------------------------------------------------ff1 CK->Q (ssfd1) 1.000r/1.000f1.000r/1.000f w2 0.120r/0.120f0.170(514.50, 517.40) 0.000r/0.000f1.000r/1.000f --------------------------------------------------------------------------------Rise delay to endpoint: 1.013 -------------------------------------------------------------------------------Path #: 2 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: ff4/D (Hold time: 1.000, clocked by CLK1 R, latency: 4.000) Data required time: 0.000 (1 cycle) Data arrival time: 2.013 Slack: 2.013 Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load Cell Location (pf) (um) --------------------------------------------------------------------------------inst1/buf1_1 A->Y(ssiv)1.000f/-r 1.000f/-r1.000r/1.000f0.215(487.50, 504.40) inst1/sub1_w1 1.013f/-r 0.013f/0.013r inst1/buf1_2 A->Y(ssiv)1.000r/1.000f 2.013r/-f1.000f/1.000r0.035(510.00, 530.40) w8 0.000r/0.000f 2.013r/-f ff4 CK^^D(ssfd1) -1.000r/-1.000f1.013r/-f1.000r/1.000f (520.50, 504.40) --------------------------------------------------------------------------------- May 2005 495 Product Version 4.1.5 Encounter User Guide Timing Budgeting Partition: inst1 Port: sub1_in1 Constraint: set_input_delay(hold fall) One buffer delay for adjustment: 1.000 Adjustment for budget available time= -(pathFixedDelay+fixedDelayForFeedThroughBlocks-clockSkew+holdConstrValue) Adjustment for budget available time= -(0.000+2.000-0.000+-1.000)=-1.000 Adjustment by fixed delay: 0.000 Adjustment by virtual clock: 0.000 Adjustment by net delay: 0.000 Adjustment by clock latency: 0.000 Total delay: 1.000 + 2.013 = 3.013 Absolute total delay: 3.013 Initial Slack: 3.013 - -1.000 = 4.013 External Buffering Adjustment: 0.000 Budget = 1.000 - 0.000 + 0.000 + 0.000 + 0.000 = 1.000 Fall delay from startpoint: 1.000 --------------------------------------------------------------------------------Path #: 1 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: ff4/D (Hold time: 1.000, clocked by CLK1 R, latency: 4.000) Data required time: 0.000 (1 cycle) Data arrival time: 2.013 Slack: 2.013 Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load Cell Location (pf) (um) --------------------------------------------------------------------------------ff1 CK->Q (ssfd1) 1.000f/1.000r1.000f/1.000r w2 0.120f/0.120r0.170(514.50, 517.40) 0.000f/0.000r1.000f/1.000r --------------------------------------------------------------------------------Fall delay to endpoint: 1.013 --------------------------------------------------------------------------------Path #: 2 Startpoint: ff1/Q (clocked by CLK1 R, latency: 4.000) Endpoint: ff4/D (Hold time: 1.000, clocked by CLK1 R, latency: 4.000) Data required time: 0.000 (1 cycle) Data arrival time: 2.013 Slack: 2.013 Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load Cell Location (pf) (um) --------------------------------------------------------------------------------inst1/buf1_1 A->Y(ssiv)1.000r/-f 1.000r/-f1.000f/1.000r0.215(487.50, 504.40) inst1/sub1_w1 1.013r/-f 0.013r/0.013f inst1/buf1_2 A->Y(ssiv)1.000f/1.000r 2.013f/-r1.000r/1.000f0.035(510.00, 530.40) w8 2.013f/-r May 2005 0.000f/0.000r 496 Product Version 4.1.5 Encounter User Guide Timing Budgeting ff4 CK^^D(ssfd1) -1.000f/-1.000r1.013f/-r1.000f/1.000r (520.50, 504.40) --------------------------------------------------------------------------------- May 2005 497 Product Version 4.1.5 Encounter User Guide Timing Budgeting Constraints Support in Budgeting The following constraints are generated during timing budgeting: ■ create_clock If a top-level clock CK is inverted, then while generating the budgets for a partition a new negative clock CK_B%ENC is created for the partitions connected to the negative clock. For example, if CK is defined as: Create_clock -name CK -period 7.500 -waveform { 0.000 3.750 } \ [list [get_ports {clk}] ] The negative clock is: create_clock -name CK_B%ENC -period 7.500 -waveform { 3.750 7.500 } \ [list [get_ports {losdclko_rp}] ] Where, losdclk0_rp is the clock port of the partition. ■ create_generated_clock ■ set_clock_latency The set_clock_latency constraint is generated when you set the setAnalysisMode –skew. The clock latency is not budgeted between the partitions. The setAnalysisMode –clockTree along with set_clock_propagation constraint do not cause the network delay through the clocktree to be budgeted for the partitions. The same clock latency is assigned to all the partitions if specified in the toplevel clock constraints. ■ set_clock_uncertainty ■ set_input_delay ■ set_output_delay ■ set_input_transition ■ set_load ■ set_drive ■ set_driving_cell ■ set_max_transition ■ set_max_capacitance ■ set_max_delay ■ set_multicycle_path May 2005 498 Product Version 4.1.5 Encounter User Guide Timing Budgeting ■ set_false_path SoC Encounter timing analysis requires that constraints set_false_path and set_multicycle_path have valid start and end points for -from and -to options. This corresponds to the requirement of PrimeTime. Valid start points are: ❑ Input ports ❑ Input part of bidirectional ports ❑ Clock pins of sequential cells ❑ Pins associated with set_input_delay ❑ Pins associated with set_path_delay -from Valid end points are: ❑ Output ports ❑ Output part of bidirectional ports ❑ Data pins of sequential cells ❑ Pins associated with set_output_delay ❑ Pins associated with set_max_delay -to During budgeting, the Encounter software generates valid budgets for partitions based on invalid constraints at the top. For example, if set_multicycle_path 2 –from SUB/IN1 is set at the top-level, it is ignored during timing analysis because a hierarchical pin is not a valid start point for set_multicycle_path constraint. However budgeting generates set_multicycle_path –from IN1 for partition which is valid when the constraints are sourced for the partition because IN1 is a top-level port for partition and a valid start point. ■ set_case_analysis ■ set_max_delay ■ set_min_delay ■ set_logic_zero ■ set_logic_one Partition ports could be left unconstrained. This means that there are some ports missing set_input_delay or set_output_delay constraints in the constraint file. Several factors can cause a partition I/O being unconstrained. For instance, set_false_path, May 2005 499 Product Version 4.1.5 Encounter User Guide Timing Budgeting set_case_analysis, set_disable_timing in input constraint file can effectively cut paths through a port. The Set_input_delay constraint at top-level, without a reference clock is another possibility to cause some partition ports being unconstrained. Missing timing arcs in cell timing model can also cut timing paths. If a constant signal (1'b0, 1'b1) is assigned to net leading to a partition port in verilog, it can also cause that port to be left unconstrained. ■ Min and -hold May 2005 500 Product Version 4.1.5 Encounter User Guide 18 RC Extraction This chapter describes how to use the RC extraction features to generate resistance and capacitance data. ■ Overview on page 502 ■ Before You Begin on page 503 ■ Native RC Extraction on page 504 ■ ❑ Generating a Capacitance Table on page 506 ❑ Reading a Capacitance Table on page 512 ❑ Correlating Native Extraction With Sign-Off Extraction on page 513 Sign-Off Extraction Using Fire & Ice QX on page 522 ❑ May 2005 Inputs for Fire & Ice Sign-Off Extraction on page 523 501 Product Version 4.1.5 Encounter User Guide RC Extraction Overview You can perform two types of extraction in Encounter: ■ Native RC Extraction Used to provide quick parasitic extraction (default mode) for design prototyping, or to generate more accurate parasitics (detailed mode) for cross-coupling and signal integrity analysis. For more information, see “Native RC Extraction” on page 504. ■ Sign-Off RC Extraction using Fire & Ice® QX Used to obtain the most accurate detailed parasitic extraction. Fire & Ice can also be used with native extraction to generate RC scaling factors. For more information, see “Sign-Off Extraction Using Fire & Ice QX” on page 522. The following table summarizes the type of extraction used during the design process. Extraction Type When Native (Default) Used during optimization both before and after clock tree synthesis. Native (Detailed) Used during post-route optimization. Sign-Off (Fire & Ice) Used during chip assembly and timing sign-off processes. May 2005 502 Product Version 4.1.5 Encounter User Guide RC Extraction Before You Begin Before running extraction, you enter the RC scaling factor values in the Timing Defaults page of the Design Import form. Scaling values are used to multiply the extracted resistance and capacitance. For example, a capacitance scaling factor of 1.1 increases the extracted values by ten percent. The following requirements are needed for both detailed and sign-off extraction: ■ ■ ■ Capacitance table—2-D or 3-D field solver ❑ The 2-D field solver produces a basic capacitance table. ❑ The 3-D field solver produces an extended capacitance table. Interconnect technology (ICT) input file ❑ Typical Case ❑ Worst Case ❑ Best Case RC scaling factors ❑ R (resistance) ❑ CL (total lumped capacitance). This is required for default extraction as well. ❑ Cx (Cross-coupling capacitance) Results ■ Native (detailed) extraction—Creates Resistance Capacitance Database (RCDB) then generates an equivalent SPEF file. ■ Fire & Ice QX Extraction—Creates Standard Parasitics Extraction File (SPEF). May 2005 503 Product Version 4.1.5 Encounter User Guide RC Extraction Native RC Extraction There are two modes of native RC extraction: ■ Default In default mode, the total capacitance for each net is calculated based on the net geometry and the local wire density. The Encounter software does not calculate separate coupling capacitance in this mode. Note: Default mode is only used for static timing analysis (STA). ■ Detailed In detailed mode, the RC values are generated that can be used for both STA (including cross-coupling) and signal integrity analysis to generate more accurate results for a particular process technology. In detailed mode, the software calculates the coupling capacitance component for each segment by considering the actual geometries of neighboring nets on the same metal layer, and the adjacent metal layer when a full capacitance table is provided during design import. The following figure shows the native extraction flow. Read ICT Technology File(s) (best, typical, worst corners) Generate Capacitance Table(s) (best, typical, worst corners) Read Capacitance Table generateCapTbl command readCapTbl command Route* Extract RC extractRC command * Trial Route, WRoute, NanoRoute To perform native extraction, complete the following steps: 1. Create an IceCaps technology (ICT) file for each process corner—You can either create an ICT file manually or generate it by using IceCaps, a built-in functionality of Fire & Ice. For most technologies you can get this file from the technology vendors such as TSMC May 2005 504 Product Version 4.1.5 Encounter User Guide RC Extraction and UMC. For technologies that are not available through the technology vendors, you enter the fabrication process information into an ASCII-format interconnect technology (ICT) input file. For more information on creating the ICT files, see Appendix A “Creating the ICT File”, in the Encounter User Guide. Note: The minWidth and minSpacing values should be the same in all three ICT files. 2. Generate a capacitance table using ICT files for each process corner. For more information, see “Generating a Capacitance Table” on page 506. 3. Read in the capacitance table values. For more information, see “Reading a Capacitance Table” on page 512. 4. Use the setExtractRCMode and extractRC command to perform extraction. You can also use the Specify RC Extraction Mode and Extract RC GUI forms to perform the extraction. 5. To correlate native extraction results with sign-off extraction, you compare SPEF files from basic and sign-off extraction to generate the new scaling factors for total capacitance, cross-coupling capacitance, and resistance. Using these scaling factors, the native extraction results are closer to the sign-off extraction results, while only taking a fraction of the run time required for sign-off extraction. For more information, see “Correlating Native Extraction With Sign-Off Extraction” on page 513. May 2005 505 Product Version 4.1.5 Encounter User Guide RC Extraction Generating a Capacitance Table A capacitance table enables more accurate extraction results. A capacitance table contains capacitance and resistance values. The capacitance values in the capacitance table are calculated using 2-D and 3-D field solvers. The resistance values are defined in the process technology file. Each technology requires one capacitance table. To consider process corner variations, you must generate three capacitance tables, one for each process corner. Important The capacitance table must be generated before running extraction. If the capacitance table is not defined before extraction, Encounter generates a basic capacitance table using default process parameters and using heuristic equations for calculation. When capacitance tables are present in the technology file, Encounter will not use the dielectric and thickness values. Inputs for Generating a Capacitance Table To generate a capacitance table, you specify the fabrication process information in an ICT file. Fabrication process information in the ICT file can consists of the following: ■ The minimum spacing and minimum width of the conductors as specified in the design rules for the conductor layers. ■ The thicknesses of the conductor layers. ■ The heights of the conductor layers above the substrate (measuring height from the field) or as a delta from a previously defined lower-level conductor layer. ■ The resistivities of the conductor layers. The ICT file can contain either a constant sheet resistivity value or value-width pairs as a piecewise linear function. When you generate a capacitance table with width-based sheet resistance, the resistance values are generated for each layer. ■ The interlayer planar dielectric constant, its height above the substrate (measuring height above the field), and its thickness. ■ The names of the top conductor layer of a via, the bottom conductor or diffusion layer of the via, and the contact resistance of the via. ■ The names of the wells. For more information on the syntax of the ICT file, see Appendix A “Creating the ICT File”. May 2005 506 Product Version 4.1.5 Encounter User Guide RC Extraction Capacitance Table Generation Flow The following figure shows the flow for generating the three process corner capacitance tables. Best Process Corner ICT File Typical Process Corner ICT File Worst Process Corner ICT File Generate Capacitance Table Generate Capacitance Table Generate Capacitance Table Best Case Capacitance Table Typical Case Capacitance Table Worst Case Capacitance Table Read Capacitance Table Note: The best, typical, and worst corner designations are simply naming conventions used to differentiate the three separate corners (capacitance tables). It is up to you to define the contents of the ICT files for your design. To generate a capacitance table, perform the following steps: 1. Generate an ICT file for each process corner. For an example ICT file, see Appendix A “Creating the ICT File”, in the Encounter User Guide. 2. Generate three separate capacitance tables using the three ICT files. Use the generateCapTbl command or the generateCapTbl standalone executable (recommended) for each of the ICT file to generate a capacitance table and replace the rough estimate of the parasitic parameters in the technology file with accurate data from a 2-D and a 3-D field solver. Important Generating a capacitance table is CPU-intensive and can take a full day to run for newer technologies. Use the generateCapTbl standalone executable which can be found in the bin directory of your Encounter hierarchy. The standalone executable runs independent of Encounter; it has the same syntax as the generateCapTbl command. May 2005 507 Product Version 4.1.5 Encounter User Guide RC Extraction Output of Generating a Capacitance Table You can generate two types of capacitance tables: ■ Basic Creates a basic capacitance table for internal extraction in the Encounter software. You can generate a basic capacitance table using the 2-D field solver provided in the Encounter software. This field solver is based on the differential form of Gauss’s law. The field solver partitions the metal areas into small divisions using a grid, and for each grid, applies Gauss’s law then derives the capacitance values. The basic capacitance table is used for both detailed and default extraction. ■ Extended Creates an extended capacitance table for extraction. The extended capacitance table is created using information in the LEF file. The 3-D tables are generated using either the Cadence field solver (Coyote) or QuickCap. QuickCap is not a Cadence product. It requires a separate license from Random Logic Corporation. Note: Use the extended capacitance table to generate more accurate parasitics. Basic Capacitance Table Example The basic capacitance table uses a 2-D field solver as described in the previous section. A basic capacitance table sample is shown below. BASIC_CAP_TABLE ... M1 width(um) space(um) Ctot(fF/um) Cc(fF/um) Carea(fF/um) Cfrg(fF/um) 0.16 0.162 0.25602 1.07e-01 0.01966 0.01118 0.16 0.18 0.23596 9.62e-02 0.01966 0.01195 0.16 0.28 0.17086 5.95e-02 0.01966 0.0161 0.16 0.38 0.14056 4.07e-02 0.01966 0.01975 0.525 0.132 0.13336 2.02e-02 0.01966 0.01225 0.525 0.122 0.14056 4.07e-02 0.01966 0.02925 ... ... M2 .. May 2005 508 Product Version 4.1.5 Encounter User Guide RC Extraction BASIC_CAP_TABLE ... M1 width(um) space(um) Ctot(fF/um) Cc(fF/um) Carea(fF/um) Cfrg(fF/um) M3 . M<number> : metal layer i.e. M1 , M2, M3 The contents of the capacitance table are described below. width Minimum width of the wires. space Distance between the parallel wires. Ctot Total capacitance of the middle wire in a group of three parallel wires. Cc Line-to-line coupling capacitance. Carea Area capacitance of the middle wire to upper-adjacent and lower-adjacent metal plates. Cfrg Fringe capacitance per side of middle wire to upper-adjacent and lower-adjacent metal plates. Extended Capacitance Table Examples The extended capacitance table is based on a 3-D field solver which is used by native extraction and NanoRoute. The native extractor produces more accurate RC components with the extended capacitance table compared to the basic capacitance table. The extended capacitance table is generated by either the Cadence field solver (Coyote) or QuickCap. QuickCap requires a separate license from Random Logic Corporation. The following sample files show portions of extended capacitance tables for Coyote and QuickCap. The capacitance tables are for different. Extended Capacitance Table Example PROCESS_VARIATION ... # THREE_PROCESS_CORNERS LAYER M1 MinWidth 0.12000 # MinSpace 0.12000 # Height 0.91500 May 2005 509 Product Version 4.1.5 Encounter User Guide RC Extraction Thickness 0.20840 TopWidth 0.17500 BottomWidth 0.13100 WidthDev 0.00000 Resistance 0.1365 0.131 0.1282 0.162 0.1249 0.185 0.1179 0.255 0.1123 0.395 0.1114 0.435 0.1104 0.495 0.1072 0.735 ThermalC1 0.00324 ThermalC2 0.00000 END Layer M2 ... LAYER M3 ... LAYER M4 ... LAYER M5 ... LAYER M6 ... VIA CONT TopLayer M1 BottomLayer POLY Resistance 12.50000 END VIA VIA_1 ... VIA VIA_2 ... VIA VIA_3 ... VIA VIA_4 ... VIA VIA_5 ... END_PROCESS_VARIATION ... EXTENDED_CAP_TABLE ... # SolverExe: /abc/def/ghi/install/sun4v/tools/bin/coyote # Solver Type: coyote 1.01 6 6 1 0.870005 0.290005 3.9 0 0 5 May 2005 510 Product Version 4.1.5 Encounter User Guide RC Extraction 3 1 0 0 440 300 140 280 0 0.12 0.16 0.12 6.25 8.3333333 0.42 0.56 5 0 6.25 8.3333333 6.74432e-05 9.558965e-05 ... END_EXTENDED_CAP_TABLE May 2005 5 0 160 420 0.72 1.3888889 0.14 0.7 1.3888889 5.76285e-06 5 511 0 1 120 720 120 140 560 700 0.44 0.3 2.2727273 3.3333333 0.14 0.28 1000 0.0001126342 2.2727273 3.3333333 1.55548e-05 2.876825e-05 0 1.3888889 Product Version 4.1.5 Encounter User Guide RC Extraction Reading a Capacitance Table There are two ways to read in the capacitance table: ■ Use the following command in the Encounter configuration file: set rda_Input(ui_captbl_file) “xxx.capTbl” Or, set rda_Input (ui_captbl_file) “-typical fileName1 -best fileName2 -worst fileName3” ■ Use the readCapTable command to read the capacitance table after loading the design and before running extraction. Carefully observe the command log for any possible error messages. The number of metal layers specified in the PCS and the LEF file (if used) at the time of capacitance table generation must match or be higher than the actual number of layers used in your design (current LEF/DEF). The capacitance table contains standard names for metal layers (M1, M2…), not the names used in the LEF file. Note: You must read the capacitance table before specifying the extraction mode. May 2005 512 Product Version 4.1.5 Encounter User Guide RC Extraction Correlating Native Extraction With Sign-Off Extraction The Encounter software accommodates an extraction flow that uses process-dependent scaling factors to generate extraction values that are close to the sign-off extraction values. With these scaling factors, the results generated by the native extraction correlate to the results of sign-off extraction. The run time for the native extraction flow is much less than for sign-off extraction. Complete the following steps to generate the RC scaling factor to correlate native extraction results with sign-off extraction. 1. From the routed DEF, generate a SPEF file using the runQX command. For more information on generating a SPEF file, see “Sign-Off Extraction Using Fire & Ice QX” on page 522. 2. Generate a capacitance table file using the ICT process file(s). For more information, see “Generating a Capacitance Table” on page 506. 3. Read in the generated capacitance table. For more information, see “Reading a Capacitance Table” on page 512. 4. Generate a SPEF file using the Timing extractRC and rcOut commands. 5. Compare the SPEF file from native extraction with the SPEF file from sign-off extraction using the Ostrich parasitics correlation utility. Use the correlation utility to generate RC factors (scaling factors) for total capacitance, cross-coupling capacitance, and resistance. For more information, see “Correlating SPEF Files Using the Ostrich Utility” on page 514. The extracted values are accurate if the total capacitance scaling factor has a deviation that is within 20 percent of 1.0 (that is, 0.80 to 1.20). You can also use the Perl script spefCapCmp.pl to compare the SPEF files. For more information, see “Comparing SPEF Files Using a Perl Script” on page 517. 6. Specify these scaling factors using setRCFactor before running native (detailed) extraction. For more information, see “Defining the Scaling Factor” on page 521. 7. Rerun the extractRC command to generate a new SPEF file. This file contains capacitance and resistance values that correlate to the values in the Fire & Ice sign-off SPEF file. May 2005 513 Product Version 4.1.5 Encounter User Guide RC Extraction The following figure shows the flow for generating RC scaling factors. ICT File Fire & Ice QX (Sign -Off) Extraction Native (Detailed) Extraction generateCapTbl icecaps readCapTable icecaps.tch extractRC Routed DEF runQx Sign-Off SPEF SPEF 1 Compare SPEFs RC Factor setRCFactor +/- 20% Correlation Determine New RC Factors Set RC Factors Comparing the ICT File with the Technology File If the via and sheet resistance values defined in the ICT file are different from those defined in the LEF file, you might not get correlation between native and sign-off extraction. To correct the sheet resistance values, use a script called correctTechRes.pl. You can run the script from the UNIX prompt. This script resides in the $ENCOUNTER/bin directory. The script compares the sheet resistance values in the ICT file and technology file derived from the LEF information, and if the values are different, the values in the ICT file are used to update the technology file. Correlating SPEF Files Using the Ostrich Utility Use Ostrich to correlate the SPEF files generated using native (detailed) extraction and signoff extraction. Ostrich is a standalone utility in Encounter. Ostrich generates the scaling factors after correlating the SPEF files. You can then set the scaling factors for the next extraction cycle. May 2005 514 Product Version 4.1.5 Encounter User Guide RC Extraction To correlate the SPEF files, complete the following steps: 1. Type ostrich at the Encounter prompt. This opens the main Ostrich window. 2. In the Ostrich window, click on File - Import - SPEF. This opens the SPEF Import form. 3. In the SPEF Import form, specify the name of the sign-off SPEF file and a name in the Data Set Name field. Next, click on the Import button to add the SPEF values in the Ostrich window. To correlate the resistance values, select the Extract Resistance option. 4. Similarly, import the native extraction SPEF file using the SPEF Import form. May 2005 515 Product Version 4.1.5 Encounter User Guide RC Extraction 5. Click on Correlate - Build Plot option in the Ostrich Window. This opens the Build Correlation Plot window. 6. Select the Golden Setname and Target Setname corresponding to the sign-off SPEF, and native extraction SPEF respectively. 7. Select Build TCAP plots, Build RES plots, and Build XCAP plots options. Click on the Build button. May 2005 516 Product Version 4.1.5 Encounter User Guide RC Extraction 8. Click on the Correlate - draw Plot - plot option in the Ostrich window. This opens the plot window. The plot window displays the suggested scale factor. Comparing SPEF Files Using a Perl Script Use the Perl script spefCapCmp.pl to compare the SPEF files generated by the runQX and extractRC commands. You specify a range of total capacitance on a net to select the nets for comparison. This script resides in the $ENCOUNTER/bin directory. The Perl script generates the RC scaling factors for total capacitance and cross-coupling capacitance. If the capacitance scaling is outside the range of +/- 20% (0.8-1.2), you need to reevaluate the flow for possible mistakes during parasitics generation. Note: The script should only be used to set the cross-coupling capacitance scaling factor if both extractions were run in coupled RC mode and under the same conditions for grounding small coupling capacitances. The script compares the sum of all coupling capacitances for each net, not the individual net-to-net coupling capacitances. The safest way to compare the May 2005 517 Product Version 4.1.5 Encounter User Guide RC Extraction coupling capacitance part of the extraction tools is to set the threshold values for coupling capacitance as low as possible in the sign-off extractor. To run the Perl script, use the following command at the UNIX prompt: spefCapCmp.pl -ref signoff_file_name.spef -cmp file_name.spef [-minCap value] [-maxCap value] [-ex openNetFile] -ref signoff_file_name.spef Specifies the SPEF file generated by the runQX command. -cmp file_name.spef Specifies the SPEF file generated by the extractDetailRC command. -minCap value Specifies the minimum value, in picofarads, of the total capacitance on a net for the comparison script. The default value is 0.01. -maxCap value Specifies the maximum value, in picofarads, of the total capacitance on a net. The default value is 5.0. -ex openNetFile Specifies the name of the file that contains open nets to be excluded from the report file. Note: You may want to set the minCap value higher than the default 10 fF in order to correlate the results better for nets that have much higher total capacitance. The Perl script generates the following output: ■ Report file spefCapCmp.rpt, which contains the scaling factors and statistical data for both total capacitance and cross-coupling capacitance. For more information, see “Example of a Report File” on page 519. ■ The tcap.plot file, which contains coordinates for plotting the comparison values for total capacitance. ■ The xcap.plot file, which contains coordinates for plotting the comparison values for cross-coupling capacitance. ■ The res.plot file, which contains coordinates for plotting the comparison values for resistance. To display a scatter plot of the comparison values, use the following command: xgraph -P -nl file_name.plot May 2005 518 Product Version 4.1.5 Encounter User Guide RC Extraction Note: xgraph is a public domain utility that you can download from the internet. Example of a Report File #Ref. Cap file: lambda_aftercrosstalkfix.spef #Cmp. Cap file: lambda_detailrc.spef #--------------------------------------------------------------------# # Total Capacitance Statistics # #--------------------------------------------------------------------# #Total Capacitance range considered: 0.0100 - #Total number of nets: 418399 #Total number of nets with nonzeoro lumped Cap: 213095 5.0000 [pF] #Total number of nets discarded (small lumped Cap): 152272.00 #Suggested Capacitance Scale Factor 0.9577 <---- (Ref. = FE(Cmp.)* 0.9577) #Mean (Cap Scalar): 1.04 #Total Sum of residual square: 22.89 #Variance: 0.00 #Standard deviation: 0.02 #Coefficient of variation: 1.90% #Normal distribution range (sigma): 1.00 to 1.08 # ---------------------------------------------# Correlation results: #of Nets % # ---------------------------------------------# Nets [..., 0.1]: 0 0.00 # Nets [0.1, 0.2]: 0 0.00 # Nets [0.2, 0.3]: 0 0.00 # Nets [0.3, 0.4]: 0 0.00 # Nets [0.4, 0.5]: 0 0.00 # Nets [0.5, 0.6]: 0 0.00 # Nets [0.6, 0.7]: 0 0.00 # Nets [0.7, 0.8]: 0 0.00 # Nets [0.8, 0.9]: 800 0.38 # Nets [0.9, 1.0]: 20004 9.39 # Nets [1.0, 1.1]: 24729 11.60 # Nets [1.1, 1.2]: 10048 4.72 # Nets [1.2, 1.3]: 3224 1.51 # Nets [1.3, 1.4]: 1164 0.55 May 2005 519 Product Version 4.1.5 Encounter User Guide RC Extraction # Nets [1.4, 1.5]: 454 0.21 # Nets [1.5, 1.6]: 227 0.11 # Nets [1.6, 1.7]: 90 0.04 # Nets [1.7, 1.8]: 54 0.03 # Nets [1.8, 1.9]: 11 0.01 # Nets [1.9, 2.0]: 10 0.00 # Nets [2.0, ...]: 8 0.00 152272 71.46 # Nets discarded : #--------------------------------------------------------------------# # Cross Coupling Capacitance Statistics # #--------------------------------------------------------------------# #Total Capacitance range considered: 0.0100 - #Total number of nets: 418399 #Total number of nets with nonzeoro lumped XCap: 5.0000 [pF] 87593 #Total number of nets discarded (small lumped Cap): 25846.00 #Suggested Cross Coupling Cap. Scale Factor 1.1975<---- (Ref. = FE(Cmp.) * 1.1975) #Mean Cross Coup. : 0.84 #Total Sum of residual square: 29005.81 #Variance: 0.47 #Standard deviation: 0.69 #Coefficient of variation: 82.32% #Normal distribution range (sigma): -0.54 to 2.21 # ---------------------------------------------# Correlation results: #of Nets % # ---------------------------------------------# Nets [...., 0.1]: 38 0.04 # Nets [0.1, 0.2]: 36 0.04 # Nets [0.2, 0.3]: 113 0.13 # Nets [0.3, 0.4]: 269 0.31 # Nets [0.4, 0.5]: 756 0.86 # Nets [0.5, 0.6]: 1710 1.95 # Nets [0.6, 0.7]: 4500 5.14 # Nets [0.7, 0.8]: 14351 16.38 # Nets [0.8, 0.9]: 22407 25.58 # Nets [0.9, 1.0]: 12530 14.30 # Nets [1.0, 1.1]: 3534 4.03 # Nets [1.1, 1.2]: 1011 1.15 # Nets [1.2, 1.3]: 314 0.36 May 2005 520 Product Version 4.1.5 Encounter User Guide RC Extraction # Nets [1.3, 1.4]: 109 0.12 # Nets [1.4, 1.5]: 43 0.05 # Nets [1.5, 1.6]: 13 0.01 # Nets [1.6, 1.7]: 5 0.01 # Nets [1.7, 1.8]: 1 0.00 # Nets [1.8, 1.9]: 0 0.00 # Nets [1.9, 2.0]: 1 0.00 # Nets [2.0, ...]: 6 0.01 25846 29.51 # Nets discarded : Defining the Scaling Factor You can specify the scaling factors in the following three ways: 1. Change the technology file. You can change the ScaleFactor in the technology file. This scaling is used for each technology. 2. Store the value in the configuration command by using the following commands: set rda_Input(ui_cap_scale) "NUMBER" set rda_Input(ui_xcap_scale) "NUMBER" set rda_Input(ui_res_scale) "NUMBER" 3. Use the following Tcl command: setRCFactor -cap scaleFactor -xcap scaleFactor -res scaleFactor For information on the setRCFactor command, see setRCFactor in the Encounter Text Command Reference. The value specified in the Tcl command supersedes the value in the configuration command, which supersedes the value in the technology file. The default value for all scaling factors is 1.0. May 2005 521 Product Version 4.1.5 Encounter User Guide RC Extraction Sign-Off Extraction Using Fire & Ice QX Fire & Ice® QX is the gate-level extraction engine accessible through the Encounter software for generating detailed parasitics. You can perform sign-off extraction after running WRoute or NanoRoute. Note: Fire & Ice QX requires a separate license. Fire & Ice is also used with native extraction to generate an RC scaling factor. For more information, see “Correlating Native Extraction With Sign-Off Extraction” on page 513. The Fire & Ice extraction engine uses a suite of 3-D models that are generated once per process. During extraction, Fire & Ice geometrically analyzes each conductor in all three dimensions, generates parameters based on specific 3-D regions, and then passes the parameters to the models for capacitance calculation. The models use an influence region called a dynamic halo to account for all near-body and multi-level interconnect capacitive effects, including the impact of crossover fringe, corners, and capacitive shading. The 3-D extraction techniques do not rely on pattern-matching techniques, so they do not produce boundary errors. This type of modeling extracts and maintains both lumped and fully distributed net-to-net coupled capacitance. The following figure shows the sign-off extraction flow. Clock Tree Generation ICT Process File Route Run IceCaps or get icecaps.tch from technology vendor such as TSMC/UMC Run runQX icecaps.tch sign-off.spef You can use the Extraction Setup form located in the Encounter Timing menu for sign-off extraction. You can access this form by choosing Timing – Fire & Ice Extract RC from the Encounter menu. May 2005 522 Product Version 4.1.5 Encounter User Guide RC Extraction Inputs for Fire & Ice Sign-Off Extraction Fire & Ice gate-level extraction is a DEF-based flow. When you perform sign-off extraction through the Encounter interface, a routed DEF will automatically be created. The following inputs are required before you can start sign-off extraction: ■ DEF file—A Design Exchange Format (DEF) file contains the design-specific information of a circuit and is a representation of the design at any point during the layout process. ■ IceCaps technology (ICT) file—This file is generated by IceCaps, a built-in functionality of Fire & Ice. For most technologies you can get this file from the technology vendors such as TSMC and UMC. For technologies that are not available through the technology vendors, you enter the fabrication process information into an ASCII-format interconnect technology (ICT) input file. The ICT file is then used as input to IceCaps, which in turn generates the technology file. For more information on creating the ICT files, see Appendix A “Creating the ICT File”, in the Encounter User Guide. ■ Cell library database—This database is created prior to gate-level extraction using the Gen Lib option in the Extraction Setup form. ■ Fire & Ice QX command file—This file contains commands and variables that define the extraction environment (technology filename, library name, and so on), specifies the net(s) to extract and how to extract them, controls the resistance and capacitance extraction, and specifies the extraction outputs. May 2005 523 Product Version 4.1.5 Encounter User Guide RC Extraction May 2005 524 Product Version 4.1.5 Encounter User Guide 19 Calculating Delay The following chapter describes how to calculate delays using either the Encounter delay calculator or the SignalStorm® nanometer delay calculator. ■ Overview on page 526 ■ Before You Begin on page 526 ❑ Operating Conditions on page 526 ❑ ECSM Libraries on page 527 ❑ Using IPDB-based ECSM Libraries on page 527 ■ Delay Calculation Modes and Related Controls on page 529 ■ Choosing A Delay Calculation Engine on page 530 ■ Running Delay Calculation on page 530 May 2005 525 Product Version 4.1.5 Encounter User Guide Calculating Delay Overview You can perform delay calculation at various stages of the design flow to continuously validate your timing. Encounter provides two delay calculator engines that you can use: ■ Encounter delay calculator engine Used to provide quick delay calculation for design prototyping, optimization, and general timing analysis. ■ SignalStorm nanometer delay calculator Used to perform final delay calculation and timing analysis. SignalStorm provides better accuracy, can calculate multi-driver nets, and uses more advanced ESCM modeling. Before You Begin In order to perform delay calculation, you must have a placed design loaded in Encounter. Delay calculation uses information from the following data files: ■ A DSPF-format or SPEF-format netlist that contains the detailed parasitic resistance and capacitance of the interconnect, and the gates that are used to drive this interconnect. ■ .lib file (Timing information) ■ Timing constraints file ■ LEF file Delay calculation generates the following information: ■ Optionally, an SDF file, which provides delay information for instances and RC interconnect. ■ SignalStorm also generates a report file, which provides delay information, the signal slew rate, and interconnect loading information. Operating Conditions Encounter does not automatically import operating conditions from the SDC constraints. Therefore, you must ensure that operating conditions are specified before running delay calculation. Use the setOpCond commands to specify the minimum and maximum libraries, and operating conditions. May 2005 526 Product Version 4.1.5 Encounter User Guide Calculating Delay ECSM Libraries By default Encounter automatically translates the Liberty (.lib) timing library data into ECSM format, when you choose to use SignalStorm for delay calculation. When translating the .lib timing data, Encounter uses the current configuration of minimum and maximum timing libraries and operating conditions specified. The ECSM data is stored in memory only, not to disk. Using IPDB-based ECSM Libraries If you have existing ECSM/IPDB libraries from SPICE characterization, you can still load them into Encounter using backward compatible options. Note: Using the automatic translation mode and loading ECSM IPDBs are mutually exclusive; they cannot be used together in the same design. ➤ Set the following mode variable in your Encounter initialization script (current_working_directory/.encrc file): set dbgSignalStormCompatibleMode 1 The setDelayCalMode command parameters and forms used to load ECSM IPDBs become available. In the automatic translation mode (dbgSignalStormCompatibleMode 0), these parameters and forms are disabled. Loading ECSM Libraries You can also use the ECSM/IPDB-based mode to load an existing ECSM library. 1. Choose Design - Design Import and click on the Misc. tab. This opens the Misc. page of the Design Import form. 2. Specify the name of the ECSM library in the ECSM DB field in the SignalStorm Library panel. 3. Click Load. You can also load ECSM libraries using the loadECSMDB command: loadECSMDB ECSM_DB_NAME Or, you can add the following line to the .conf file: rda_Input(ui_sigstormlib) “myECSM.ipdb” May 2005 527 Product Version 4.1.5 Encounter User Guide Calculating Delay Selecting ECSM Operating Corners If you load an existing ECSM library into Encounter using the ECSM/IPDB-based mode, you must set the operating conditions to use for delay calculation. 1. Choose Timing – Specify Analysis Condition – Specify Delay Calculation Mode. The Delay Calculation Mode form displays. 2. Select SignalStorm for the calculation mode. 3. Specify the ECSM process corners to use for maximum and minimum delay calculation in the Slow Corner Process Name and Fast Corner Process Name fields. Note: Click the Check Available Process Names button to find out which process corners have been loaded into the library. 4. Click OK or Apply. You can also specify operating corners using the setDelayCalMode command: setDelayCalMode -signalstorm -slowCorner ecsmProceesCornerName -fastCorner ecsmProceesCornerName May 2005 528 Product Version 4.1.5 Encounter User Guide Calculating Delay Delay Calculation Modes and Related Controls Delays are calculated differently, depending on the number of terminals (fanouts) a net has and the Elmore time constant. The following table lists the calculation modes and related controls used by Encounter for delay calculation. Fanouts >= 1,000 1,000 > Fanouts <= 100 100 > Fanouts and Elmore > 5ps 5ps > Elmore Algorithm Uses the default delay parameters. Uses simplified delay calculation mode. Uses full RC delay calculation mode. Uses simplified delay calculation mode. Cell Delay Uses lumped C lookup with a default value of 0.5 pF. Uses lumped C lookup from total parasitics on the net. Uses full RC. Uses lumped C lookup from total parasitics on the net. Uses Elmore delay. Uses full RC. Uses Elmore delay. Uses lumped C lookup from total parasitics on the net. Uses full RC. Uses lumped C lookup from total parasitics on the net. Interconnect None Slew Degradation None Uses full RC. None Controls Fanout threshold is controlled by the -elmore option in the buildTimingGraph command. The default value is 100 fanouts. The value is controlled by the setDefaultNetLoad command. Wire Delay Uses the default value of 1 ns. The value is controlled by the setDefaultNetDelay command. Driver Slew Rates Uses the default value of 120 ps. The value is controlled by the setInputTransitionDelay command. May 2005 Fanout threshold is controlled by the setUseDefaultDelayLimit command. The default value is 1,000 fanouts. (Slews are degraded across interconnect.) 529 No control for minimum Elmore threshold. Product Version 4.1.5 Encounter User Guide Calculating Delay Choosing A Delay Calculation Engine 1. Choose Timing – Specify Analysis Condition – Specify Delay Calculation Mode. The Delay Calculation Mode form displays. 2. Select Default to use the Encounter delay calculator, or SignalStorm to use the SignalStorm delay calculator. Alternatively, you can specify the delay calculation engine by issuing the setDelayCalMode text command: ■ Issue the following command to specify the Encounter delay calculator: setDelayCalMode -default ■ Issue the following command to specify the SignalStorm delay calculator: setDelayCalMode -signalStorm Running Delay Calculation 1. Choose Timing – Calculate Delay. 2. (Optional) Select Ideal Clock to force the clock nets on each flip-flop input pin to use 0. Note: Use the setAnalysisMode command parameters to control how timing and delay calculation are performed before and after clock tree synthesis 3. (Optional) Specify an SDF filename in which to save the delay information in the SDF Output File field. By default, Encounter saves the delay information in the default SDF file named topModule.sdf. 4. Click OK or Apply to calculate delay. Alternatively, you can run delay calculation by issuing the following text command: delayCal For example, the following command calculates both interconnect and cell delays, and saves the results to the SDF file named TOPCHIP_SP.sdf: delayCal -sdf TOPCHIP_SP.sdf May 2005 530 Product Version 4.1.5 Encounter User Guide 20 Timing Analysis The goal of timing analysis is to verify that a design meets timing requirements under a specified set of timing constraints, such as arrival and departure times, operating conditions, slew rates, false paths, and path delays. Performing timing analysis lets you determine how fast a design can run without incurring timing violations. You can use the results of timing analysis to fine tune and debug the speed-limiting, critical paths in a design. You can perform timing analysis using Cadence and Synopsys constraint formats and timing libraries, such as TLF, .lib, and Stamp Models. This chapter presents the following topics: ■ Timing Analysis Features on page 532 ■ Before You Begin on page 533 ■ Results on page 535 ■ Reading Timing Libraries on page 535 ■ Reading Timing Constraints on page 536 ■ Setting Operating Conditions on page 540 ■ Calculating Clock Latency on page 541 ■ Defining RC Corners on page 542 ■ Specifying Timing Analysis Modes on page 544 ■ Clock Reconvergence Pessimism Removal on page 568 ■ Analyzing Timing Problems on page 574 ■ Performing Blackbox What-If Timing Analysis on page 576 May 2005 531 Product Version 4.1.5 Encounter User Guide Timing Analysis Timing Analysis Features Timing analysis includes the following features and capabilities: Static Timing Analyzer (STA) Use STA to: ■ Perform setup time analysis, which analyzes violating paths due to timing ■ Perform hold time analysis ■ Perform analysis in ideal and propagated mode ■ Report asynchronous violating paths ■ Report violating paths after running pre-clock tree synthesis (CTS) skew What-If Timing Analysis Use what-if timing analysis to modify instance cell timing information to reach top level timing requirements, after which you can manually change the timing model of a standard cell or modify the timing arcs of black boxes. Once you have defined the initial timing model of the black boxes, you can modify arc definitions and verify the consequences in timing analysis. Wireload Model Generation in Hierarchical and Flat Format The delay information in the technology library applies to the timing arcs from input ports to output ports of each cell and the corresponding wire delays. The cell delays and the wire delays are expressed as a function of the physical characteristics of the nets in the design, such as wire capacitance and wire resistance. A wireload model uses the fanout count of a net and estimates its capacitance and resistance. The wireload models in the hierarchical format are generated for cells and instances based on external nets (hierarchical view). The wireload models in the flat format are generated for cells and instances based on internal nets (flat view). Minimum and Maximum Timing Analysis To read in libraries with multiple operating conditions for minimum and maximum analysis, you can: ■ Define the libraries in the configuration file or in the Encounter GUI May 2005 532 Product Version 4.1.5 Encounter User Guide Timing Analysis ■ Specify the setOpCond command ■ Specify the setTimingLibrary command (optional) ■ Specify the setAnalysisMode command Timing Analysis Ideal and Propagated Modes The following table shows the global analysis modes for timing analysis. . setAnalysisMode Clock Propagation Clock Latency -noSkew Forced Ideal No Effect -skew -noClockTree Forced Ideal SDCs in Effect -skew -clockTree *SDCs in Effect **SDCs in Effect * Clocks synthesized in Encounter are propagated. ** The set_clock_latency command is overridden by overlapping set_propagated_clock constraints. Before You Begin Before running timing analysis, read in the timing libraries, timing constraints, and the netlist. Optionally, you can also set the following conditions: ■ Specify the delay calculation and RC extraction values Use the Timing and Power pages in the Design Import form to specify these values. For more information, see “Design Import – Timing” on page 179. ■ Specify the operating conditions to use for timing analysis Use the operating conditions to specify process, voltage, and temperature values. Operating conditions are defined in the timing library and read into the Encounter session when you import the design. For more information, see “Setting Operating Conditions” on page 540. ■ Specify the report mode you want to use for timing analysis. There are two modes used for timing analysis: Common Timing Engine (CTE) static timing analysis report mode and Encounter static timing analysis report mode, which is the default mode. May 2005 533 Product Version 4.1.5 Encounter User Guide Timing Analysis To use the Common Timing Engine static timing analysis report mode, set the setCteReport command. After setting this command, you can use the following commands: ❑ The checkTA command performs a variety of consistency and completeness checks on the timing constraints specified for a design. ❑ The reportClock command creates reports containing the clock information from the timing constraints file. However, only the -clk and the -outfile options are currently supported. ❑ The reportIpoSlacks command creates an output file that contains path delays in the common timing engine (CTE) mode. ❑ The reportIpoViolation command reports the detail data paths that do not meet timing in the common timing engine (CTE) mode. The software reports the paths based on slack value criticality, path pair enumeration, short form reporting, and constraint reporting based on clock skew or async. ❑ The reportTA command generates a timing report that provides information about the various paths in the design. For more information on the CTE command options, see “Timing Commands” in the Encounter Text Command Reference. To return to the Encounter static timing analysis report mode after running CTE, set the setFeReport command. Important Do not toggle between the two different report modes in a timing analysis session. Remain in one report mode, setCteReport or setFeReport for the entire session. ■ Check and report timing libraries by generating the timing library report. ■ Check and report cell footprints by generating the cell footprint report. ■ Define RC corners for timing analysis. You can set the RC corner as best, typical, or worst. The software uses these values for late and early setup and hold times during timing analysis. For more information, see “Defining RC Corners” on page 542. ■ Specify the analysis mode you want to use for timing analysis. There are three types of analysis modes: single, best-case worst-case (BC-WC), and on-chip variation. For more information, see “Specifying Timing Analysis Modes” on page 544. May 2005 534 Product Version 4.1.5 Encounter User Guide Timing Analysis Results After performing timing analysis, you can identify all timing violations and slacks. You can also identify all of the critical paths in combinatorial or clocked circuits at both block and chip level. Timing analysis generates the following reports, which you can use to determine whether your design operates at the required clock frequency: ■ Timing slack report ■ Timing violation report ■ Transition timing violation report ■ Clock waveform report Reading Timing Libraries The timing library contains the timing models provided by the ASIC or intellectual property (IP) vendors. You can read in the library files while importing the design using the Design Import menu command. You can use the Design – Design Import form to specify the timing libraries. If you enter information in only one of the MaxTiming Libraries, Min Timing Libraries, or Common Timing Libraries fields, Encounter runs single value analysis: both setup and hold analysis use the libraries entered in that field. If you provide values for both Max Timing Libraries and Min Timing Libraries, Encounter performs bestcase-worstcase analysis. If you read in both Min and Max library groups, the software uses Max library delay values for setup and Min library delay values for hold time calculations. To change this behavior, you can set the -max and -min parameters of the setTimingLibrary command to the same group. For example, to run setup and hold analysis using Max Timing Libraries, use the following command: setTimingLibrary -max Max -min Max Specifying Different Timing Libraries for Setup And Hold Checks You use the setTimingLibrary command to change the library that is used for minimum delay and maximum delay path calculations. The default value of the setTimingLibrary command is as follows: setTimingLibrary –max Max –min Min May 2005 535 Product Version 4.1.5 Encounter User Guide Timing Analysis The command uses the delay values from Max library during setup checks and the delay values from the Min library for hold checks. To perform setup analysis at the BC corner and hold analysis at the WC corner, use the following command: setTimingLibrary –min Max –max Min You can accordingly set the operating condition by using the following command: setOpCond -maxLibrary stdcellbest -max bccom -minLibrary stdcellwst -min wccom Resolving Discrepancies in Timing Libraries If a set of timing library files has different time unit or capacitive load unit values, the timing analysis program cannot resolve these inconsistent values. The timing libraries must be checked. If the timing tables in the timing library are not what you expect, check the timing library by using the reportTimingLib command, or the Timing Library menu command. Reading Timing Constraints To ensure that your design meets the timing requirements, you must specify what the requirements are by setting the constraints. You can use the timing constraints to set: ■ Timing context for constraint assertions. ■ Operating condition of the design. ■ Boundary conditions such as input and output delays. ■ Slew rates ■ Path exceptions such as false paths, path delays and cycle additions. ■ Disable certain paths in the design. Constraints Quick Reference The following constraints are written out when you use the writeTimingCon command: ■ all_clock ■ all_inputs ■ all_outputs May 2005 536 Product Version 4.1.5 Encounter User Guide Timing Analysis ■ create_clock ■ create_generated_clock ■ current_design ■ current_instance ■ find ■ filter ■ get_cells ■ get_clocks ■ get_designs ■ get_generated_clocks ■ get_lib_cells ■ get_lib_pins ■ get_nets ■ get_pins ■ get_ports ■ get_references ■ get_unix_variable ■ remove_from_collection ■ set_annotated_check ■ set_case_analysis ■ set_clock_gating_check ■ set_clock_latency ■ set_clock_skew ■ set_clock_transition ■ set_clock_uncertainty ■ set_disable_clock_gating_check ■ set_disable_timing May 2005 537 Product Version 4.1.5 Encounter User Guide Timing Analysis ■ set_dont_touch Use the set_dont_touch constraint to constrain nets, instances, and cells. If the set_dont_touch constraint in the timing constraints file is overly constrained, running timing optimization does not correct the timing because timing optimization honors the constraint. ■ set_dont_touch_network ■ set_dont_use ■ set_drive ■ set_driving_cell ■ set_false_path ■ set_fanout_load ■ set_input_delay ■ set_input_transition ■ set_load ■ set_logic_one ■ set_logic_zero ■ set_max_capacitance ■ set_max_delay ■ set_max_fanout ■ set_max_time_borrow ■ set_max_transition ■ set_min_delay ■ set_multicycle_path ■ set_output_delay ■ set_propagated_clock ■ set_resistance Some constraints are expanded by the writeTimingCon command. That means that these constraints are collection of objects and when you use the writeTimingCon command, the May 2005 538 Product Version 4.1.5 Encounter User Guide Timing Analysis list of objects they represent are written out instead of the original constraint. For example, set_false_path -from [add_to_collection {AB}{C}] is written out as set_false_path -from {ABC}. The following commands are expanded: ■ add_to_collection ■ all_connected ■ foreach_in_collection ■ source May 2005 539 Product Version 4.1.5 Encounter User Guide Timing Analysis Setting Operating Conditions Integrated circuits display performance differences depending on the fabrication process, voltage, and the temperature (PVT) characteristics. The nominal values for these parameters and the corresponding delay information are contained in the technology library. Each technology library contains one or more operating condition. Each operating condition is identified by name and specifies the PVT characteristic. This information is used to calculate accurate cell delays from the nominal cell delays and the derating factors. You can use a single set of operating conditions for setup and hold analysis, or you can specify minimum and maximum conditions. In Encounter, you can specify the operating conditions using the setOpCond command or the Specify Operating Condition menu command. Depending on the design requirements, you can use the following parameters of the setOpCond command: ■ -library Sets the operating condition from a single library. You can define a single operating condition from a library, and the software uses the PVT characteristics associated with that library for every library in the design. When you use this parameter in multiple setOpCond commands, the software uses the value specified in the last command. For example, consider the following commands: setOpCond setOpCond setOpCond setOpCond setOpCond setOpCond WCCOM -library wcTestLib BCCOM -library bcTestLib WCCOM -library wcTestLib1 BCCOM -library bctestLib1 -library wcTestLib2 -library bcTestLib2 In this case, the software uses the last value defined (bcTestLib2). Therefore, the operating conditions in the bcTestLib2 library are used for both setup and hold analysis. ■ -forceLibrary Note: This parameter provides backward compatibility with previous versions of Encounter. Cadence does not recommend the use of this parameter. Sets the operating condition for each library. Use this parameter to specify different operating conditions for different libraries in a single session. For example, consider the following commands: setOpCond setOpCond setOpCond setOpCond May 2005 -max -min -max -min max min max min -forceLibrary -forceLibrary -forceLibrary -forceLibrary wcTestLib bcTestLib wcTestLib1 bctestLib1 540 Product Version 4.1.5 Encounter User Guide Timing Analysis setOpCond -max max -forceLibrary wcTestLib2 setOpCond -min min -forceLibrary bcTestLib2 In this case, the software sets the max operating condition for the cells defined in the library wcTestLib, where max is defined in the wcTestLib. Similarly, the operating condition of the cells defined in the bcTestLib2 library is set to min, where min is defined in the bcTestLib2 library. In setup analysis, the cells in each library, the wcTestLib, wcTestLib1, and wcTestLib2 libraries use the max operating condition defined in the corresponding libraries. Similarly, in hold analysis the cells in bcTestLib, bctestLib1, and bcTestLib2 use the corresponding min operating conditions. ■ -min minOpCond [-minLibrary minLib] -max maxOpCond [-maxLibrary maxLib] Specifies the operating condition used for hold or setup analysis. For example, consider the following command: setOpCond -max max -maxLibrary wcTestLib -min min -minLibrary bcTestLib In this case, the software uses the max operating condition defined in wcTestLib for setup analysis and the min operating condition defined in bcTestLib for hold analysis. Calculating Clock Latency The Encounter software calculates clock latency based on the following two settings: ■ Analysis mode set using the setAnalysisMode command. ■ The set_propagated_clock and set_clock_latency constraints values. Depending on these settings, the clock latency can be equal to either 0.0 or the value of the set_clock_latency constraint, or the delay computed by propagation on the design. The Encounter software sets the clock latency according to the following precedence rules: 1. If you do not specify setAnalysisMode -noskew, clock latency is equal to 0.0. 2. If you do not specify the set_propagated_clock or set_clock_latency constrains, clock latency is equal to 0.0. 3. If you specify set_clock_latency, but do not specify set_propagated_clock, the clock latency is equal to the value of set_clock_latency. 4. If you specify set_propagated_clock and setAnalysisMode -noClockTree, the clock latency is equal to 0.0 or set_clock_latency value (if set). 5. If you specify set_propagated_clock, and setAnalysisMode -autoDetectClockTree, and do not specify setAnalysisMode -clockTree, clock latency is equal to 0.0 or the set_clock_latency value (if set). May 2005 541 Product Version 4.1.5 Encounter User Guide Timing Analysis 6. In all other cases, clock latency is equal to propagated_delay. Defining RC Corners Before performing timing analysis, you can define which process corners (best, worst, or typical) will be used for setup and hold checks. The procedure for defining process corners is as follows: 1. Generate an ICT file for each process corner. For an example ICT file, see Appendix A “Creating the ICT File”, in the Encounter User Guide. 2. Generate three separate capacitance tables. For more information on generating capacitance tables, see “Capacitance Table Generation Flow”, in the Encounter User Guide. 3. Use the defineRCCorner command to define the process corner for setup and hold checks. The following example shows the use of the defineRCCorner command: defineRCCorner -late {best | typical | worst} temp -early {best | typical | worst} temp Best, typical, and worst correspond to the ICT files and the capacitance tables generated with the genCapTbl command. May 2005 542 Product Version 4.1.5 Encounter User Guide Timing Analysis The following figure shows the flow for extracting parasitic and defining RC corners for timing analysis. Read ICT Technology File(s) (best, typical, worst corners) Generate Capacitance Table(s) (best, typical, worst corners) Read Cap Table Extract RC Define RC Corners generateCapTbl command readCapTable command extractRC command defineRCCorner command Setup/Hold Timing Analysis May 2005 543 Product Version 4.1.5 Encounter User Guide Timing Analysis Specifying Timing Analysis Modes The Encounter software provides different timing analysis modes. The software performs different calculations for setup and hold checks for each mode. The timing analysis modes are divided as follows: ■ Single Timing Analysis Mode on page 546 In single analysis mode, delay values are scaled based on one operating condition. ■ Best-Case Worst-Case (BC-WC) Timing Analysis Mode on page 550 The BC and WC operating conditions or corners are vastly different. Therefore two paths on a chip cannot use two different operating conditions at the same time for setup or hold analysis. In BC-WC analysis mode the Encounter software checks the design for two extreme operating conditions. The software uses the maximum delays for all paths during setup checks and minimum delays for all paths during hold checks. ■ On-Chip Variation (OCV) Timing Analysis Mode on page 561 OCV is the small difference in the operating parameter value across the chip. Each timing arc in the design can have a minimum and a maximum delay to account for the on-chip process, voltage and temperature variation. In OCV mode, the software calculates the delay for one path based on maximum operating condition while calculating the delay for another path based on minimum operating condition for setup or hold checks. Definition of Early and Late Paths The timing analysis modes described in this section refer to early and late paths and their usage in slack calculation. The early and late path are the longest and the shortest paths respectively. May 2005 544 Product Version 4.1.5 Encounter User Guide Timing Analysis The following figure shows setup check with late (shown in solid line) launch clock and early capture clock (shown in dotted line). Figure 20-1 Setup Check D D Q CK GB CK GB Capture Clock D1 Q D1 D2 D2 Launch Clock The following figure shows hold check with early launch clock (shown in dotted line), and late capture clock (shown in solid line). Figure 20-2 Hold Check D D Q CK GB CK GB Launch Clock Q D1 D1 D2 D2 Capture Clock May 2005 545 Product Version 4.1.5 Encounter User Guide Timing Analysis Single Timing Analysis Mode In this mode the Encounter software uses a single set of delays (using one library group) based on one set of process, temperature and voltage conditions. In this mode, you specify one operating condition using the setOpCond command. To specify the operating condition with one library group, specify the following command: setOpcond opcondname –library libname To set the timing analysis mode as single, use the -single parameter of the setAnalysisMode command. Setup Check in Single Timing Analysis Mode For setup check, the software checks the late launch clock and late data paths against early capture clock path. For zero slack value in a setup check, the following condition should be met: launch clock late path + data clock late path <= capture clock early path + clock period – setup Hold Check in Single Timing Analysis Mode For hold check the software compares the early arriving data against the late arriving clock at the end point. For zero slack value in a hold check, the following condition should be met: launch clock early path + data clock early path >= capture clock late path + hold May 2005 546 Product Version 4.1.5 Encounter User Guide Timing Analysis Example 20-1 Setup Check in Single Timing Analysis Mode The following figure shows the setup check on the path from FF1 to FF2. 3.6 Data Late Path FF1 Launch Clock Late Path D 0.8 U1 D Q 1.9 Data Early Path 0.6 U2 FF2 Setup 0.5 U3 Capture Clock Early Path The software uses a library to scale all delays at WC conditions. For setup check the software considers two paths between the two registers, FF1 and FF2. The software considers only the late path delay to calculate slack during setup check. The following values are assumed in this example: Data late path delay = 3.6 Data early path delay = 1.9 Clock source latency = none Wire delay = 0 Clock period = 4 Clock Mode = Propagated clock mode The software computes the slack as follows: Launch clock late path delay = 0.8 + 0.6 =1.4 Data late path delay = 3.6 Capture clock early path delay = 0.8 + 0.5 = 1.3 Setup = 0.2 Data arrival time = 1.4 + 3.6 = 5 Data required time = 4 + 1.3 - 0.2 = 5.1 Slack = 5.1 - 5 = 0.1 May 2005 547 Product Version 4.1.5 Encounter User Guide Timing Analysis Example 20-2 Hold Check in Single Timing Analysis Mode The following figure shows the hold check on the path from FF1 to FF2. 2.6 Data Late Path FF1 Launch Clock Early Path D 0.6 U1 D Q 1.0 Data Early Path 0.4 U2 FF2 Hold 0.3 U3 Capture Clock Late Path The software uses a library to scale all delays at BC conditions. The following values are assumed in this example: Clock source latency = none wire delay = 0 clock period = 4 Clock Mode = Propagated clock mode The software computes the slack as follows: Launch clock early path delay = 0.6 + 0.4 = 1.0 Data early path delay = 1.0 Capture clock late path delay = 0.6 + 0.3 = 0.9 Hold = 0.1 Data arrival time = 1 + 1 = 2 Data Required Time = 0.1 + 0.9 = 1 Slack = 2 – 1 = 1 May 2005 548 Product Version 4.1.5 Encounter User Guide Timing Analysis Performing Timing Analysis in Single Analysis Mode To perform timing analysis in single analysis mode, complete the following steps: 1. Load in the library file by sourcing the configuration file with the following line: set rda_Input(ui_timelib,max) "${libDir}/stdcell.lib” You can also load the library using the Design Import menu command. 2. Set the timing libraries to be used during setup or hold. setTimingLibrary –max Max –min Max 3. Set the operating condition for setup analysis. setOpCond worst –library stdcell You can also use the library defaults by not specifying any setOpCond or by specifying setOpCond {}. 4. Set the analysis mode to single, setup and propagated clock mode. setAnalysisMode -single -setup –skew -clockTree 5. Generate the timing reports for setup. reportTA or reportViolation 6. set the operating condition for hold analysis. setOpCond best –library stdcell 7. Set the analysis mode to hold and propagated clock mode. setAnalysisMode –hold –skew –clockTree 8. Generate the timing reports for hold. reortTA –hold or reportViolation -hold May 2005 549 Product Version 4.1.5 Encounter User Guide Timing Analysis Best-Case Worst-Case (BC-WC) Timing Analysis Mode In BC-WC timing analysis mode, the Encounter software considers two operating conditions. The software checks both operating conditions in one timing analysis run. To set the timing analysis mode as BC-WC, use the -bcWc parameter of the setAnalysisMode command. You can use the set_clock_latency constraint to set the source latency for a clock in both ideal and propagated mode for setup and hold checks. You can also use the constraint to set the network latency for an ideal clock. The specified source or network latency affects the early and late clock paths for both capture and launch clocks for both min and max operating conditions. The software considers the network latency that you set using the set_clock_latency –max or –min constraint for ideal clocks only. Setup Check in BC-WC Mode For setup check, the software calculates delay values from the Max library group for data arrival time, and network delay of both launch and capture clocks (in propagated mode). The software scales the delay values using the operating condition that you specify using the setOpCond -max command. To define the operating condition, use the following command: setOpCond –max WCopcondname –maxLibrary WClibname For zero slack value in a setup check, the following condition should be met: Launch clock_latepath (max) + data_latepath (max) <= Capture clock_earlypath (max) + clock_period – setup Where, max is the delay at the WC operating condition. The source latency in both ideal and propagated modes for setup checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock late path (max) set_clock_latency –source –late –max value Or, set_clock_latency –source –late value May 2005 550 Product Version 4.1.5 Encounter User Guide Timing Analysis Clock Path (Operating Condition) Constraint Used Capture clock early path (max) set_clock_latency –source –early –max value Or, set_clock_latency –source –early value The network latency in ideal mode for setup checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock late path (max) set_clock_latency -max value Capture clock early path (max) set_clock_latency -max value HOLD Check in BC-WC Mode For HOLD check, the software uses the delay values from the Min library for the data arrival time, and network delay of both launch and capture clocks (in propagated mode). The software scales the delay values using the operating condition that you specify using the setOpCond -min command. To specify the operating condition, use the following command: setOpCond –min minopcondname –minLibrray minlibname For zero slack value in a hold check, the following condition should be met: Launch clock_earlypath (min) + data_earlypath (min)>= Capture clock_latepath (min) + hold Where, min is delay at the BC operating condition. The source latency in both ideal and propagated modes for hold checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock early path (min) set_clock_latency –source –early –min value Or, set_clock_latency –source –early value May 2005 551 Product Version 4.1.5 Encounter User Guide Timing Analysis Clock Path (Operating Condition) Constraint Used Capture clock late path (min) set_clock_latency –source –late –min value Or, set_clock_latency –source –late value The network latency in ideal mode for hold checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock early path (min) set_clock_latency -min value Capture clock late path (min) set_clock_latency -min value Note: You can also use one library containing two operating conditions in this mode. Example 20-3 Setup Check in BC-WC Timing Analysis Mode The following shows the setup check on the path from FF1 to FF2. 3.5 Data Late Path FF1 Launch Clock Late Path D 0.7 U1 D Q 1.9 Data Early Path 0.6 U2 FF2 Setup 0.5 U3 Capture Clock Early Path The software uses the Max library to scale all delays at WC conditions. The following values are assumed in this example: Clock source latency = none wire delay = 0 May 2005 552 Product Version 4.1.5 Encounter User Guide Timing Analysis clock period = 4 Clock Mode = Propagated clock mode The software computes the slack as follows: Launch clock late path delay = 0.7 + 0.6 = 1.3 Data late path delay = 3.5 Capture clock early path delay = 0.7 + 0.5 = 1.2 Setup = 0.2 Data arrival time = 1.3 + 3.5 = 4.8 Data required time = 4 + 1.2 – 0.2 = 5 Slack = 5 - 4.8 = 0.2 Example 20-4 Hold Check in BC-WC Timing Analysis Mode The following figure shows the hold check on the path from FF1 to FF2. 2.3 Data Late Path FF1 Launch Clock Early Path D 0.5 U1 D Q 1.0 Data Early Path 0.4 U2 FF2 Hold 0.3 U3 Capture Clock Late Path The software uses the Min library to scale all delays at BC conditions. The following values are assumed in this example: Clock source latency = none wire delay = 0 clock period = 4 Clock Mode = Propagated clock mode The software computes the slack as follows: May 2005 553 Product Version 4.1.5 Encounter User Guide Timing Analysis Launch clock early path delay = 0.5 + 0.4 = 0.9 Data early path delay = 1.0 Capture clock late path delay = 0.3 + 0.5 = 0.8 Hold = 0.1 Data arrival time = 0.9 + 1 = 1.9 Data required time = 0.1 + 0.8 = 0.9 Slack = 1.9 - 0.9 = 1 Performing Timing Analysis in BC-WC Analysis Mode To perform timing analysis in BC-WC analysis mode, complete the following steps: 1. Read in the min and max libraries by sourcing the configuration file with the following lines: set rda_Input(ui_timelib,max) "${libDir}/stdcellwst.lib” set rda_Input(ui_timelib,min) "${libDir}/stdcellbest.lib” You can also load the library using the Design Import menu command. 2. Specify BC-WC operating conditions to be used during setup and hold. setOpCond –max wccom–maxLibrary stdcellwst –min bccom –minLibrary stdcellbest You can also use the software defaults by not specifying any operating conditions 3. Set the analysis mode to BC-WC, setup and propagated clock mode. setAnalysisMode -bcWc –setup –skew –clockTree 4. Set the timing engine as CTE. setCteReport 5. Generate the timing reports for setup. reportTA –setup 6. Set the analysis mode to hold and propagated clock mode. setAnalysisMode –hold –skew -clockTree 7. Generate the timing reports for hold. reportTA -hold Note: You can also use the reportViolation command to generate reports in Encounter static timing analysis report mode. May 2005 554 Product Version 4.1.5 Encounter User Guide Timing Analysis Using setTimingDerate with BC-WC Analysis Mode When you use the setTimingDerate command in BC-WC timing analysis mode, the Encounter software uses scaling factors to consider on-chip variation for each BC and WC corner. Data And Launch Clock Delay The following figure shows a graph of the clock and data delay. Capture Clock Delay A timing path around the WC and BC operating conditions or corners might have setup or hold violations if the data or clock delay values vary as a result of on-chip variation. A timing path has setup violations if the delay value of the capture clock is less as compared to its value at the WC corner. In the figure above, the corner 1 represents the setup violation. The slack value at corner 1 is more pessimistic than the WC corner. To specify the pessimism and emulate minimum delay for capture clock, you can scale the delay by a scale factor of less than 1. Similarly, corner 3 represents setup violation, and corner 2 and 4 represent hold violations. The design might have the following setup and hold violations around all four corners due to on-chip variation: ■ Corner 1 has setup violations if the delay value of the capture clock is less than its value at the WC corner. To specify the pessimism, you scale the capture clock delay value by a scale factor of less than 1. May 2005 555 Product Version 4.1.5 Encounter User Guide Timing Analysis Note: Alternatively, you can use the setTimingDerate command to scale data path and launch clock delay by a value greater than 1 instead of scaling the capture clock delay by a value less than 1. ■ Corner 2 has hold violations if the delay value of the data or launch clock is less than their value at the WC corner. To specify the pessimism, you scale the data and launch clock delay by a scale factor of less than 1. ■ Corner 3 has setup violations if the delay value of the data or launch clock is more than their value at the BC corner. To specify the pessimism, you scale the data and launch clock delay by a scale factor of more than 1. ■ Corner 4 has hold violations if the delay value of the capture clock is more than its value at the BC corner. To specify the pessimism, you scale the capture clock delay value by a scale factor of more than 1. The following table summarizes the delay values used for all four corners: Corner Violation Data Path Delay Launch Clock Delay Capture Clock Delay (1) WC Setup WC WC WC x scaling value<1 (2) WC Hold WC x scaling value<1 WC x scaling value<1 WC (3) BC Setup BC x scaling value>1 BC x scaling value>1 BC (4) BC Hold BC BC BC x scaling value>1 Note: You can use the setTimingDerate –data –clock –min –max –early –late command to scale the delays. The software scales both cell and net delays. The following table lists the parameters of the setTimingDerate command that you can set for scaling the delay values for data, launch and capture clock paths: Check Data Launch Clock Capture Clock Setup -late -late -early -max -max -max -data -clock -clock -early -early -late -min -min -min -data -clock -clock Hold May 2005 556 Product Version 4.1.5 Encounter User Guide Timing Analysis By default, setup analysis is done at WC corner and hold analysis is done at BC corner. To check setup at BC and hold at WC, change the default values of the setTimingLibrary command. For example around the BC corner, you can use the following command: setTimingLibrary –min Min –max Min. Example 20-5 Setup and Hold Checks in Corner 3 and Corner 4 The following figure shows the delays at BC corner. 2.3 FF1 D D Q 0.4 U2 0.5 U1 FF2 1.0 0.3 U3 The setup and hold checks are calculated for the path from FF1 to FF2. The following values are assumed in this example: setTimingDerate –max –late 1.2 (corner 3) for setup check setTimingDerate –min -clock –late 1.1 (corner 4) for hold check clock source latency = none Clock mode = propagated clock mode Wire delay = 0 Clock period = 4 The software computes the slack for setup check as follows: Launch clock late path delay = 0.9 x 1.2 = 1.08 Data late path delay = 2.3 x 1.2 = 2.76 Capture clock early path delay = 0.5 + 0.3 = 0.8 Setup = 0.2 Data arrival time = 1.08 + 2.76 = 3.84 May 2005 557 Product Version 4.1.5 Encounter User Guide Timing Analysis Data required time = 4 + 0.8 – 0.2 = 4.6 Slack = 4.6 – 3.84 = 0.76 The software computes the slack for hold check as follows: Launch clock early path delay = 0.5 + 0.4 = 0.9 Data early path delay = 1.0 Capture clock late path delay = 1.1 x 0.8 = 0.88 Hold = 0.1 Data arrival time = 1.0 + 0.9 = 1.9 Data required time = 0.88 + 0.1 = 0.98 Slack = 1.9 – 0.98 = 0.92 The following table shows the parameters that were scaled in this example: Corner Violation Data Launch Clock Capture Clock 3 Setup Delay x 1.2 Delay x 1.2 Delay 4 Hold Delay Delay Delay x 1.1 To perform timing analysis to report setup and hold violations for BC setup and BC hold corner, complete the following steps: 1. Read in the fast library by including the following line in the configuration file: set rda_Input(ui_timelib,min) "${libDir}/fast.libî 2. Scale the late clock and data paths for setup. setTimingDerate –max –late 1.2 3. Scale the late paths for hold. This is the capture clock path. setTimingDerate –min –late 1.1 4. Use the min library for both setup and hold calculations. setTimingLibrary -max Min -min Min 5. Select the BC operating condition from the fast library. setOpCond best –library fast 6. Set the analysis mode to setup and propagated clock mode. May 2005 558 Product Version 4.1.5 Encounter User Guide Timing Analysis setAnalysisMode -setup –skew -clockTree 7. Generate the timing reports for setup. reportViolation 8. Set the analysis mode to hold and propagated clock mode. setAnalysisMode -hold –skew -clockTree 9. Generate the timing reports for hold. reportViolation Example 20-6 Setup and Hold Violations in Corner 1 and Corner 4 The following script sets the scaled on-chip variation of 20 percent near the WC and 10 percent for BC corner for setup and hold paths respectively: set rda_Input(ui_timelib,min) "${libDir}/fast.libî set rda_Input(ui_timelib,max) "${libDir}/slow.libî setTimingDerate -max -early 0.8 -late 1.0 setTimingDerate -min -early 1.0 -late 1.1 setTimingLibrary -max Max -min Min setOpCond –min Best –minLibrary fast –max Worst –maxLibrary slow setAnalysisMode -setup –skew -clockTree reportViolation setAnalysisMode -hold –skew -clockTree reportViolation The following table shows the parameters that were scaled in this example: Violations Data Launch Clock Capture Clock SETUP Delay Delay Delay x 0.8 HOLD Delay Delay Delay x 1.1 May 2005 559 Product Version 4.1.5 Encounter User Guide Timing Analysis Example 20-7 Setup and Hold Violations in Corner 1 and Corner 2 The following script sets the scaled on-chip variation of 20 percent near the WC corner for setup and hold paths: set rda_Input(ui_timelib,max) "${libDir}/slow.libî setTimingDerate -early 0.8 -late 1.0 setTimingLibrary -max Max -min Max setOpCond Worst –library slow setAnalysisMode -setup –skew -clockTree reportViolation setAnalysisMode -hold –skew -clockTree reportViolation The following table shows the parameters that were scaled in this example: Violations Data Launch Clock Capture Clock SETUP Delay Delay Delay x 0.8 HOLD Delay x 0.8 Delay x 0.8 Delay Note: The setTimingDerate command does not scale delays set using constraints. For example latency values set using set_clock_latency or arrival times set using set_input_delay are not scaled. You can use reportTimingDerate to report current settings. Limitation of the setTimingDerate Command in FE Timing Analysis Mode The setTimingDerate command does not support delays read from sdf file. May 2005 560 Product Version 4.1.5 Encounter User Guide Timing Analysis On-Chip Variation (OCV) Timing Analysis Mode OCV mode assumes that capture clock, launch clock, and data path can have maximum or minimum delays in setup and hold analysis. OCV is crucial in clock insertion part of the flow where you need to consider the minimum delay and maximum delay clock and data signals concurrently using Min and Max libraries or using derating factors and values from a single library. To set the timing analysis mode as OCV, use the -onChipVariation parameter of the setAnalysisMode command. Note: You can use this mode for performing timing analysis only. Following constraints are supported in OCV mode: ■ set_clock_latency ■ set_driving_cell ■ set_drive ■ set_load ■ set_resistance Setup Check In OCV mode setup check the software uses the timing delay values from the Max library group for the data and the launch clock network delay. The software uses the delay values from the Min library group for the capturing clock network delay assuming that the clocks are set in propagated mode. Note: You can also use one library instead of max and min libraries. For zero slack value in a setup check, the following condition should be met: Launch clock_latepath (max) + data_latepath (max) <= Capture clock_earlypath (min) + clock_period –setup May 2005 561 Product Version 4.1.5 Encounter User Guide Timing Analysis The source latency in both ideal and propagated modes for setup checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock late path (max) set_clock_latency –source –late –max value Or, set_clock_latency –source –late value Capture clock early path (min) set_clock_latency –source –early –min value Or, set_clock_latency –source –early value The network latency in ideal mode for setup checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock late path (max) set_clock_latency -max value Capture clock early path (max) set_clock_latency -min value Hold Check In OCV hold check, the software uses the timing delay values from the Min library for the data arrival time and launch clock network delay. The software uses delay values from the Max library for the capturing clock network delay assuming that the clocks are set in propagated mode. For zero slack value in a hold check, the following condition should be met: Launch clock_earlypath (min) + data_earlypath (min)>= Capture clock_latepath (max) +hold The source latency in both ideal and propagated modes for hold checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock early path (min) set_clock_latency –source –early –min value Or, set_clock_latency –source –early value May 2005 562 Product Version 4.1.5 Encounter User Guide Timing Analysis Clock Path (Operating Condition) Constraint Used Capture clock late path (max) set_clock_latency –source –late –max value Or, set_clock_latency –source –late value The network latency in ideal mode for hold checks is defined in the constraints used by various clock paths as follows: Clock Path (Operating Condition) Constraint Used Launch clock early path (min) set_clock_latency -min value Capture clock late path (min) set_clock_latency -min value May 2005 563 Product Version 4.1.5 Encounter User Guide Timing Analysis Example 20-8 Setup Check in OCV Timing Analysis Mode The following figure shows the setup check on the path from FF1 to FF2. Data Late Path 3.5/3.0 FF1 Launch Clock Late Path D 0.7/0.5 U1 D Q 1.9/1.2 Data Early Path 0.6/0.4 U2 FF2 0.5/0.3 U3 Setup Delay Values Shown As: max/min Capture Clock Early Path The software uses the Max library to scale all delays at WC conditions and Min library to scale all delays at BC conditions. The following values are assumed in this example: Clock source latency = none wire delay = 0 clock period = 4 Clock Mode = Propagated clock mode The software computes the slack as follows: Launch clock late path delay (max) = 0.7 + 0.6 = 1.3 Data late path delay (max) = 3.5 Capture clock early path delay (min) = 0.5 + 0.3 = 0.8 Setup = 0.2 Data arrival time = 1.3 + 3.5 = 4.8 Data required time = 4 + 0.8 – 0.2 = 4.6 Slack = 4.6- 4.8 = -0.2 May 2005 564 Product Version 4.1.5 Encounter User Guide Timing Analysis Example 20-9 Hold Check in OCV Timing Analysis Mode The following figure shows the hold check on the path from FF1 to FF2. Data Late Path 3.5/3.0 FF1 Launch Clock Late Path D 0.7/0.5 U1 D Q 1.9/1.2 Data Early Path 0.6/0.4 U2 FF2 0.5/0.3 U3 Hold Delay Values Shown As: max/min Capture Clock Early Path The software uses the Max library to scale all delays at WC conditions and Min library to scale all delays at BC conditions. The following values are assumed in this example: Clock source latency = none wire delay = 0 clock period = 4 Clock Mode = Propagated clock mode The software computes the slack as follows: Launch clock early path delay (min) = 0.5 + 0.4 = 0.9 Data early path delay (min) = 1.2 Capture clock late path delay (max) = 0.7 + 0.5 = 1.2 Hold = 0.1 Data arrival time = 0.9 + 1.2 = 2.1 Data required time = 0.1 + 1.2= 1.3 Slack = 2.1 - 1.3 = 0.8 May 2005 565 Product Version 4.1.5 Encounter User Guide Timing Analysis Performing Timing Analysis in OCV Mode With Two Libraries And Operating Conditions To perform timing analysis in OCV analysis mode, complete the following steps: 1. Read in the min and max libraries by sourcing the configuration file with the following lines: set rda_Input(ui_timelib,max) "${libDir}/slow.lib” set rda_Input(ui_timelib,min) "${libDir}/fast.lib” You can also load the library using the Design Import menu command. 2. Specify OCV operating conditions to be used during setup and hold. setOpCond –min best –max worst –minLibrary fast –maxLibrary slow 3. Set the analysis mode to OCV and propagated clock mode. setAnalysisMode –onChipVariation –skew –clockTree 4. Generate the timing reports for setup. reportTA –late or reportViolation -setup 5. Generate the timing reports for hold. reportTA -early or reportViolation -hold Using setTimingDerate with OCV Analysis Mode When you use the setTimingDerate command in OCV timing analysis mode, the Encounter software uses -min with the early paths and -max with the late paths. The setTimingDerate command affect the following paths in OCV mode: Violations Data Launch Clock Capture Clock SETUP -max (-late) -max (-late) -min (-early) -data -clock -clock -min (-early) -min (-early) -max (-late) -data -clock -clock HOLD Performing Timing Analysis in OCV Mode With Single Library And Operating Condition To perform timing analysis in OCV analysis mode, complete the following steps: May 2005 566 Product Version 4.1.5 Encounter User Guide Timing Analysis 1. Read in the min and max libraries by sourcing the configuration file with the following lines: set rda_Input(ui_timelib,max) "${libDir}/stdcell.lib” You can also load the library using the Design Import menu command. 2. Specify OCV operating conditions to be used during setup and hold. setOpCond -library stdcell WCCOM 3. Set the analysis mode to OCV and propagated clock mode. setAnalysisMode –onChipVariation –skew –clockTree 4. Scale the minimum delays to 80 percent of WCCOM using slow library. setTimingDerate -early 0.8 -late 1.0 Note: The min delays are used for both setup and hold checks. 5. Generate the timing reports for setup. reportTA –late or reportViolation -setup 6. Generate the timing reports for hold. reportTA -early or reportViolation -hold May 2005 567 Product Version 4.1.5 Encounter User Guide Timing Analysis Clock Reconvergence Pessimism Removal Clock Reconvergence Pessimism Removal (CRPR) is the process of identifying and removing the pessimism introduced in the slack reports for clock paths when the clock paths have a segment in common. In the on-chip variation methodology (using the setAnalysisMode -BcWc and the setTimingDerate commands or setAnalysisMode -ocv), during setup checks if both the launch clock_late path and the capture clock_early path share a portion of the clock network, then for the common clock network, a pessimism equal to the difference in maximum and minimum delay values is introduced in the slack values. When you use the setAnalysisMode -BcWc and the setTimingDerate commands, the software calculates maximum delay value by multiplying the delay by the scale value that you set using setTimingDerate –late. Similarly, the software calculates the minimum delay value by multiplying the delay by the scale value that you set using setTimingDerate -early. When you use the setAnalysisMode -ocv command, the software uses the maximum and minimum operating conditions to calculate the minimum and maximum delays. In this case also if you specify one operating condition, the software uses the setTimingDerate command. As shown in Figure 20-3, the setup check at FF2 compares the maximum delay data at the D pin against minimum delay clock at the CLK pin. The maximum delay data at FF2/D consists of a sum of maximum signal delay from FF1/Q to FF2/D, the maximum delay from CLK_SOURCE to FF1/CLK, and the delay from FF1/CLK to FF1/Q. Similarly, the minimum delay clock arrival time at FF2/CLK is the minimum delay from CLK_SOURCE to FF2/CLK. May 2005 568 Product Version 4.1.5 Encounter User Guide Timing Analysis Figure 20-3 Example Signal Path t1 t2 CLK_SOURCE B1 Branching Node t3 D Q FF1 D Q FF2 CLK CLK B2 B3 t4 The setup check equation for the example in Fig 20-3 with pessimism is as follows: t 1max + t 2max + t 3max ≤ t 4min + t pa – t su where, t1 = Delay value for launch clock late path t2 = Delay between FF1/CLK and FF1/Q t3 = Delay between FF1/Q and FF2/D t2 + t3 = Delay value for late data path t4 = Delay value for capture clock early path tpa = Period adjustment tsu = Setup time The setup check equation incorrectly implies that the common clock network, B1, can simultaneously use maximum delay for the launch clock late path (clock source to FF1/CLK) and minimum delay for the capture clock early path (clock source to FF2/CLK). You use the CRPR to remove this pessimism. Setup check equation using CRPR is as follows: t 1max + t 2max + t 3max ≤ t 4min + t pa – t su + t crpr May 2005 569 Product Version 4.1.5 Encounter User Guide Timing Analysis Where, tcrpr = Difference in the maximum and minimum delay from the clock source to the branching node Similarly, hold check equation using CRPR is as follows: t 1min + t 2min + t 3min + t crpr ≤ t 4max + t H Where, t1 = Delay value for launch clock early path t2 = Delay between FF1/CLK and FF1/Q t3 = Delay between FF1/Q and FF2/D t2 + t3 = Delay value for early data path t4 = Delay value for capture clock late path tcrpr = Difference in the maximum and minimum delay from the clock source to the branching node tH = Hold time For example, you use the following setTimingDerate command for setup check delays in Figure 20-3 on page 569 in scaled on-chip variation analysis methodology: setTimingDerate -max –late 1 –early 0.9 –clock With the setTimingDerate command, if the delay through B1 is 1ns, the software removes the pessimism of 0.1ns. Without CRPR the analysis tool incorrectly assumes that B1 can have a delay of 1 and 0.9. The common path pessimism time (tcrpr) is calculated as follows: B1 * Late Derate - B1 * Early Derate = tcrpr Therefore, tcrpr = 1.0ns * 1.0 - 1.0ns * 0.9 = 0.1ns CRPR And Reconvergent Logic If a design contains reconvergent logic on the clock path, the timing analysis software might assume certain pessimism while calculating slack. May 2005 570 Product Version 4.1.5 Encounter User Guide Timing Analysis The following figure shows a circuit for which timing analysis is done in single analysis mode. D Late Clock Path U2 CLK U1 U4 D Q FF1 D Q FF2 CLK CLK U3 S Early Clock Path In this case, if set_case_analysis is not set at point S of the multiplexer, the timing analysis tools assume different delay values for early and late paths. For example, if early path has delay of 0.5, and late path has delay of 1ns, a pessimism equal to 0.5 is introduced in the design. The above pessimism is not specific to single analysis mode only; it also applies to best-case/ worst-case and on chip variation methodology. Encounter uses a threshold of zero during pessimism removal. That means no pessimism remains in the analysis. For limitations of CRPR, see “Limitation of CRPR in FE Timing Analysis Mode” on page 574, and “Limitations of CRPR in CTE Timing Analysis Mode” on page 574. CRPR Flow To remove this pessimism, use the -crpr parameter in the reportSlacks, reportViolation, or reportTA commands. In Encounter, the following flow supports the CRPR feature: 1. Load the timing constraints. loadTimingCon top.sdc 2. Set the analysis mode to setup, and propagated clock. setAnalysisMode -setup -skew -clockTree 3. Set the derating values. setTimingDerate -late 1 -early 0.9 -clock 4. Run timing analysis. buildTimingGraph May 2005 571 Product Version 4.1.5 Encounter User Guide Timing Analysis 5. Generate timing report. You use the -crpr parameter in the reportViolation, reportSlacks or reportTA command to remove delay pessimism from paths that have a portion of the clock network in common. reportViolation -crpr or, reportSlacks -crpr or, reportTA -crpr Timing Analysis Results Before and After CRPR The following example shows a timing report generated before CRPR analysis. *info: Report constrained paths * Path type: max (data) * Format: long * Through: ff2/D(t) ff1/CK(t) *** Found 1 violating paths *** -------------------------------------------------------------------------------Path #: 1 Startpoint: ff1/Q (clocked by CLK1 R, latency: 0.363) Endpoint: ff2/D (Setup time: 0.189, clocked by CLK1 R, latency: 0.388) Early Max Clock Paths Derating Factor : 0.900 Late Max Data Paths Derating Factor : 4.800 Late Max Clock Paths Derating Factor : 1.100 Data required time: 3.025 (skew: 0.025 adjusted 1 cycle) Data arrival time: 3.213 Slack: -0.188 (SETUP VIOLATION) Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load (pf) Cell Location (um) ff1 CK->Q (DFFHQX1) 1.175f/1.175r 1.175f/1.175r 0.058f/0.056r 0.002 (0.00, 0.00) n8 0.000f/0.000r 1.175f/1.175r u9 A->Y (BUFX2) 0.640f/0.478r 1.815f/1.653r 0.063f/0.066r 0.002 (0.00, 0.00) n9 0.000f/0.000r 1.815f/1.653r u10 A->Y (BUFX2) 0.614f/0.452r 2.429f/2.105r 0.045f/0.046r 0.002 (0.00, 0.00) n10 0.000f/0.000r 2.429f/2.105r u11 A->Y (BUFX2) 0.595f/0.430r 3.024f/2.535r 0.045f/0.046r 0.001 (0.00, 0.00) May 2005 572 Product Version 4.1.5 Encounter User Guide Timing Analysis n11 0.000f/0.000r 3.024f/2.535r ff2 CK^^D (DFFHQX1) 0.189f/0.142r 3.213f/2.677r 0.041f/0.040r (0.00, 0.00) The following example shows a timing report generated after CRPR analysis: *info: Report constrained paths * Path type: max (data) * Format: long * Through: ff2/D(t) ff1/CK(t) *** Found 1 violating paths *** -------------------------------------------------------------------------------Path #: 1 Startpoint: ff1/Q (clocked by CLK1 R, latency: 0.363) Endpoint: ff2/D (Setup time: 0.189, clocked by CLK1 R, latency: 0.388, pessimism: 0.038) Early Max Clock Paths Derating Factor : 0.900 Late Max Data Paths Derating Factor : 4.800 Late Max Clock Paths Derating Factor : 1.100 Data required time: 3.063 (skew: 0.063 adjusted 1 cycle) Data arrival time: 3.213 Slack: -0.150 (SETUP VIOLATION) Object name Delta r/f (ns) Sum r/f (ns) Slew (ns) Load (pf) Cell Location (um) ff1 CK->Q (DFFHQX1) 1.175f/1.175r 1.175f/1.175r 0.058f/0.056r 0.002 (0.00, 0.00) n8 0.000f/0.000r 1.175f/1.175r u9 A->Y (BUFX2) 0.640f/0.478r 1.815f/1.653r 0.063f/0.066r 0.002 (0.00, 0.00) n9 0.000f/0.000r 1.815f/1.653r u10 A->Y (BUFX2) 0.614f/0.452r 2.429f/2.105r 0.045f/0.046r 0.002 (0.00, 0.00) n10 0.000f/0.000r 2.429f/2.105r u11 A->Y (BUFX2) 0.595f/0.430r 3.024f/2.535r 0.045f/0.046r 0.001 (0.00, 0.00) n11 0.000f/0.000r 3.024f/2.535r ff2 CK^^D (DFFHQX1) 0.189f/0.142r 3.213f/2.677r May 2005 573 0.041f/0.040r (0.00, 0.00) Product Version 4.1.5 Encounter User Guide Timing Analysis Limitation of CRPR in FE Timing Analysis Mode ■ CRPR does not consider the set_clock_latency –early –late –source constraint. For example, if you set the following constraint for the reconvergent logic in Figure 20-2 on page 545, set_clock_latency –source –early 0.2 –late 0.3 CLK CRPR does not remove the pessimism caused by using 0.2 ns for early path and 0.3ns for late path clocks during timing analysis. ■ CRPR does not remove pessimism in ideal mode. If you set the following constraint, set_clock_latency –max 0.5 –min 0.1 CLK CRPR does not adjust the slack to remove the pessimism. ■ CRPR is not removed when there are multiple clocks reaching a register. Limitations of CRPR in CTE Timing Analysis Mode ■ CRPR is not supported in IPO. ■ For a path between two latches during time borrowing check, both the launch and the capture clock paths are assumed to be late (as opposed to one early and one late). Therefore the software computes zero pessimism. Analyzing Timing Problems In addition to the detailed timing violation report, the following report commands can be helpful in analyzing timing problems: ■ reportAnalysisMode Reports the current setting for building the timing graph. Use setAnalysisMode to change the settings. ■ reportClock Reports the clock information from the loaded timing constraints files during design import. ■ reportClockDomains Reports the clock domain setting for building the timing graph. ■ reportCapViolation May 2005 574 Product Version 4.1.5 Encounter User Guide Timing Analysis Reports the nets that exceed the maximum capacitance constraints set by the timing library and timing constraints file. ■ reportMostCritPath -clk * -pin pinName Reports the longest path (worst slack) between all clocks (with rise and fall edges). ■ reportTranViolation Reports the nets that exceed the maximum transition constraints set by the timing constraints file. ■ reportTA Used in the CTE mode, generates a timing report that provides information about the various paths in the design. The report typically contains data on the delay through the entire path. The start node and the end node of each path is identified. ■ checkTA Used in the CTE mode, performs a variety of consistency and completeness checks on the timing constraints specified for a design. Use the checkTA command after setting all constraints but before any timing analysis commands, such as reportTA to verify that the timing environment is complete and self-consistent. ■ reportIpoSlacks Creates an output file that contains path delays in the common timing engine (CTE) mode. Use this command during and immediately after timing optimization for fast reporting of the Encounter timing graph built during timing optimization. ■ reportIpoViolation Reports the detail data paths that do not meet timing in the common timing engine (CTE) mode. The software reports the paths based on slack value criticality, path pair enumeration, short form reporting, and constraint reporting based on clock skew or async. Use this command during and immediately after timing optimization for fast reporting of the Encounter timing graph built during timing optimization. Resolving Buffer-Related Problems You may encounter some of the following buffer-related problems when running timing analysis: ■ The logical cell or buffer equivalence, based on cell functionality not used during timing optimization, can cause timing optimization to ignore timing violations. May 2005 575 Product Version 4.1.5 Encounter User Guide Timing Analysis ■ If an incorrect buffer footprint name was entered for the set of buffers to run timing optimization, use the reportFootPrint command to list the current footprint information. ■ If the in_place_swap_mode:match_footprint statement is in the timing library, then timing optimization matches up all the cells with same cell_footprint name and logical cell or buffer equivalence will not be used. ■ If the in_place_swap_mode:match_footprint statement does not exist, then timing optimization derives logical cell equivalence based on matching function:boolean_eq. ■ If you want the logical cell equivalence based on matching, comment out the in_place_swap_mode:match_footprint statement in the timing library. Performing Blackbox What-If Timing Analysis You use blackboxes in large designs containing hierarchical flows when gate-level details are not available at the beginning of the design cycle. You can easily modify the timing model of a blackbox at the top level because it is not a hard macro. Using the Encounter software, you can make quick modifications to the timing model of a blackbox, and run timing analysis to check the impact of the modifications. This feature is known as what-if timing budgeting. The Encounter software provides the blackbox timing commands to support what-if timing budgeting. For more information on blackbox timing commands, see Chapter 1, “Blackbox Timing Commands,” in the Encounter Text Command Reference. May 2005 576 Product Version 4.1.5 Encounter User Guide Timing Analysis The following diagram shows the blackbox what-if budgeting flow. setBlackBoxTimingMode Set one time for all the blackboxes of the design setBlackBoxClockLatency -init Work for each blackbox setBlackBoxDriveType setBlackBoxCombDelay setBlackBoxSeqDelay setBlackBoxTimingCheck setBlackBoxClockLatency -new Top TA Okay? getBlackBoxAssertions getBlackBoxClockLatency deleteBlackBoxTimingAssertions checkBlackBoxTiming What-if command file .lib SDC, DC, PT saveBlackBoxTimingAssertions saveBlackBoxTimingModel saveBlackBoxConstraints Prerequisite Prior to using blackbox timing commands, you must load the blackbox timing models into the database because the blackbox timing commands simulate the modifications of the timing arcs. If you do not have timing models in the early design phase, you can use the setBlackBoxClockPort command to create clock ports. You can then use the clock port to create timing arcs. Timing Models Supported for What-If Timing Analysis The Encounter software supports two timing models for blackbox timing analysis: intrinsic and normalized. You can select only one mode at a time. Figure 20-4 shows the Intrinsic timing model. May 2005 577 Product Version 4.1.5 Encounter User Guide Timing Analysis Figure 20-4 Intrinsic Timing Model 5 4 5 4 1 3 2 7 The data types associated with the numbers in the Figure 20-1, and the corresponding commands that you use to specify that data is as follows: # Data Type Command 1 Combinational delay from an input port to the input of setBlackBoxCombDelay the driver. 2 Delay from the clock input port to the data input port. setBlackBoxTimingCheck 3 Sequential delay from the clock input port to the input setBlackBoxSeqDelay of the driver. 4 Type of Driver. setBlackBoxDriveType 5 Driver input slew. 7 Clock insertion delay to internal registers. setBlackBoxClockLatency An intrinsic timing model uses the following formula for timing arcs ending on output ports: Delay = constant delay + driver delay (look-up table) If you do not use slew specifications in an intrinsic timing model, the timing arc is a twodimensional timing table containing input slew and output capacitance dependencies. With slew specifications, the timing arc is only load dependent. Figure 20-5 shows the normalized timing model. May 2005 578 Product Version 4.1.5 Encounter User Guide Timing Analysis Figure 20-5 Normalized Timing Model 5 4 5 4 6 1 2 7 6 3 The data types associated with the numbers in Figure 20- 2, and the corresponding commands that you use to specify that data is as follows: # Data Type Command 1 Combinational delay from an input port to the output setBlackBoxCombDelay port. It includes the driver delay. 2 Delay from the clock input port to the data input port. setBlackBoxTimingCheck 3 Sequential delay from the clock input port to the data setBlackBoxSeqDelay output port. It includes the driver delay. 4 Driver type. setBlackBoxDriveType 5 Driver input slew. 6 Total driver output net capacitance. 7 Clock insertion delay to internal registers. setBlackBoxClockLatency A normalized timing model uses the following formula for timing arcs ending on output ports: Delay = constant delay - driver delay* + driver delay (look-up table) Where, constant delay = Timing arc delay including driver delay driver delay * = Constant delay considering an input slew and an output capacitance constant delay - clock latency must be greater than driver delay * May 2005 579 Product Version 4.1.5 Encounter User Guide Timing Analysis In a normalized timing model mode driver input slew is always required. In this mode, timing arcs are only load dependant. If you do not specify the driver total output net capacitance, the software takes real net capacitance into account. Using the What-If Timing Commands You can perform the following tasks with the what-if timing commands: ■ Selecting Timing Model Use the following command to select the timing mode: ❑ ■ setBlackBoxTimingMode Modifying Timing Arcs While what-if commands are the same for both intrinsic and normalized timing models, the delay value specified in the commands for the combinatorial and the sequential timing arcs has different meaning. The driver output net capacitance is a characteristic of the normalized timing model only. Whenever you create or modify a timing arc, the timing graph is updated automatically. The Encounter software recomputes the entire timing arc whenever any of the parameter such as clock insertion delay, timing arc delay or driver type is modified. Use the following commands to modify timing arcs: ■ ❑ setBlackBoxDriveType ❑ setBlackBoxCombDelay ❑ setBlackBoxSeqDelay ❑ setBlackBoxTimingCheck ❑ setBlackBoxClockLatency Getting Timing Arcs Assertions Use the following command to get blackbox timing arc assertions: ❑ ■ getBlackBoxTimingAssertions Saving Timing Arcs Assertions Use the following command to save blackbox timing arc assertions: ❑ ■ saveBlackBoxTimingAssertions Deleting Timing Arcs Assertions May 2005 580 Product Version 4.1.5 Encounter User Guide Timing Analysis Use the following command to delete the blackbox timing arc assertions: ❑ ■ deleteBlackBoxTimingAssertions Checking Timing Assertions Use the following command to check the blackbox timing assertions: ❑ ■ checkBlackBoxTiming Generating Blackbox Timing Models After modifying the blackbox timing model (in memory) using the what-if command, you can generate a updated timing model (.lib) Use the following command to generate an updated .lib file: ❑ ■ saveBlackBoxTimingModel Generating Blackbox SDC constraints The Encounter software generates the blackbox timing constraints considering the toplevel environment of the blackbox. It provides a higher convergence for a top-down flow. The software generates drive, load and transition as IN context. The software generates the input and output delays as OUT context taking into account the last modifications done when you use the what-if commands. Use the following command to save the blackbox constraints: ❑ May 2005 saveBlackBoxConstraints 581 Product Version 4.1.5 Encounter User Guide Timing Analysis May 2005 582 Product Version 4.1.5 Encounter User Guide 21 Timing Optimization This chapter describes how to reduce delays in paths with violations, how to improve transition times, and how to correct capacitance violations. ■ Overview on page 584 ■ Performing Pre-CTS Optimization on page 586 ■ Performing Post-CTS Optimization on page 591 ■ Performing Post-Route Optimization on page 595 ■ Performing Post-CTS and Post-Route Optimization with Cadence PKS on page 599 ■ optDesign Parameter Matrix on page 601 ■ Useful Skew on page 602 ■ Optimizing Timing Using a Rule File on page 605 ■ Performing Timing Optimization When the Constraint File Includes the set_case_analysis Constraint on page 605 ■ Reducing Leakage Power on page 605 ■ Using Cell Footprints on page 607 ■ Viewing Added Buffers on page 607 ■ Timing Optimization Mode Defaults For Effort Levels on page 607 ■ Naming Conventions on page 611 May 2005 583 Product Version 4.1.5 Encounter User Guide Timing Optimization Overview The Encounter software includes a command, optDesign, which supports an easy-to-use timing closure flow. The optDesign command enables you to close timing and correct signal integrity and design rule violations at each stage of the design process. The optDesign command performs the following optimizations: ■ Corrects DRVs ■ Reduces total negative slack ■ Optimizes setup time for all path groups on the initial pass, then on register-to-register paths on the second pass ■ Fixes hold time violations (optional) ■ Performs useful skew optimization (optional) ■ Reclaims area (optional) The Encounter software uses some or all of the following techniques when optimizing the design, depending on the design stage and the options you specify: ■ Adding buffers ■ Resizing gates ■ Restructuring the netlist ■ Remapping logic ■ Swapping pins ■ Deleting buffers ■ Moving instances ■ Applying useful skew The optDesign command sets the minimum recommended and appropriate set of options for the following modes, based on the state of the design (-preCTS | -postCTS | -postRoute): ■ setAnalysisMode ■ setTrialRouteMode ■ setOptMode/setIPOMode May 2005 584 Product Version 4.1.5 Encounter User Guide Timing Optimization ■ setExtractRCMode Before You Begin Before you can run timing optimization, your design must be placed. Important To run timing optimization successfully, you must have reserved placement space of more than five percent of the targeted final design utilization to ensure that there is room to add buffers and remap the network to meet timing requirements. You must do the following tasks before running timing optimization: ■ Create and load footprints correctly. ■ Set the Encounter software to handle assign nets. Check the Verilog netlist for assign statements. If assign statements exist, use one of the following procedures to enable optimization to work on those nets (they are equivalent): ■ ■ ❑ Use setDoAssign on before loading the design data. ❑ Use set rda_Input(assign_buffer) {1} in the configuration file. Set the default and detailed extraction scale factors. Refer to the following commands: ❑ generateRCFactor ❑ setRCFactor Set input transitions for the high fanout nets for delay calculation to use on high fanout networks. Results The optDesign command appends the log file with the following information: ■ Worst negative slack, total negative slack, and the number of failing paths. The optDesign command also reports hold violations if you have specified the -hold parameter in post-CTS or post-route mode. The optDesign command writes the values to the log file and writes reports to the working directory. ■ Total number of instances added and deleted. ■ Number of max_tran, max_cap, and max_fanout violations May 2005 585 Product Version 4.1.5 Encounter User Guide Timing Optimization ■ Utilization The optDesign command produces five violation reports: ■ All path groups (no path group specified) ■ Register-to-register ■ Input-to-register ■ Register-to-output ■ Input-to-output The reports contain information about the following violations for the top 50 critical paths: ■ Setup violations ■ Hold violations ■ DRVs The optDesign command also reports the following DRV types: ■ max_cap ■ max_tran ■ max_fanout Depending on whether you are running pre-CTS, post-CTS, or post-route optimization, the optDesign command writes the reports for each path group to the timingReports subdirectory directory (or a directory you specify with outDir) in the run directory: ■ designName_preCTS_pathGroup.tarpt ■ designName_postCTS_pathGroup.tarpt ■ designName_postRoute_pathGroup.tarpt For more information, see “Timing Optimization Commands” in the Encounter Text Command Reference. Performing Pre-CTS Optimization The Encounter software enables you to optimize timing for a placed design before you synthesize the clock tree. This first optimization step identifies and repairs the large number of timing problems occurring in the early stages of the implementation process. May 2005 586 Product Version 4.1.5 Encounter User Guide Timing Optimization Note: At any design stage, optDesign ignores the order in which you specify parameters. This section discusses the following topics: ■ Optimizing in Pre-CTS Mode for the First Time on page 587 ■ Rapid Timing Optimization for Design Prototyping on page 587 ■ Pre-CTS Timing Optimization Options on page 588 ■ Incremental Pre-CTS Optimization on page 588 ■ Changing Default Settings in Pre-CTS Mode on page 589 ■ Running Pre-CTS Optimization from the GUI on page 590 Optimizing in Pre-CTS Mode for the First Time ■ To optimize timing for first time in your design, use the following command: optDesign -preCTS This command first reduces delays globally on all nets by buffering and gate sizing, then performs path-based optimization using optimization methods such as netlist restructuring and pin swapping. By default, optDesign -preCTS performs the following operations in the order given: ❑ Global timing optimization ❑ DRV repair ❑ Additional timing optimization on the critical paths The optDesign -preCTS command is equivalent to the following command: optDesign -preCTS -drv -setup ■ To repair DRVs only, use the following command: optDesign -preCTS -drv ■ To repair setup violations only, use the following command: optDesign -preCTS -setup Rapid Timing Optimization for Design Prototyping ■ To optimize using low effort mode for design prototyping, use the following commands: setOptMode -lowEffort optDesign -preCTS May 2005 587 Product Version 4.1.5 Encounter User Guide Timing Optimization The optDesign command performs gate resizing and global buffer insertion, but does not perform netlist restructuring nor DRV repair. For other supported low effort options, see “Low Effort” on page 607. Pre-CTS Timing Optimization Options You can use the following optDesign features separately or in combination. ■ To perform optimization with useful skew, use the following commands: setOptMode -usefulSkew optDesign -preCTS ■ To perform optimization on specific path groups, use the following commands: clearClockDomains setClockDomains -fromType domainName -toType domainName optDesign -preCTS For example, to perform optimization on register-to-register paths, use the following commands: clearClockDomains setClockDomains -fromType register -toType register optDesign -preCTS Note: If you specify a path group, optDesign preserves the path group setting. In the previous example, subsequent commands affect the register-to-register path group only. To set a new clock domain, specify clearClockDomains, followed by the definition of the clock domain you want to select. For example, to reset the path group to input-to-register, use the following commands after you run optDesign: clearClockDomains setClockDomains -fromType input -toType register To specify all path groups, use the following command: clearClockDomains setClockDomains -all ■ To reclaim area during optimization, use the following commands: setOptMode -reclaimArea optDesign -preCTS Incremental Pre-CTS Optimization After using optDesign -preCTS to initially optimize timing in your design you can optimize incrementally to correct remaining violations on critical paths that contain violations. May 2005 588 Product Version 4.1.5 Encounter User Guide Timing Optimization Note: Incremental optimization only optimizes setup times and area (optional). ■ To perform incremental optimization use the following command: optDesign -preCTS -incr ■ To perform incremental optimization with useful skew, use the following commands: setOptMode -usefulSkew optDesign -preCTS -incr ■ To perform incremental optimization on specific path groups, use the following commands: clearClockDomains setClockDomains -fromType domainName -toType domainName optDesign -preCTS -incr For example, to perform incremental optimization on register-to-register paths, use the following commands: clearClockDomains setClockDomains -fromType register -toType register optDesign -preCTS optDesign -preCTS -incr ■ To perform an incremental optimization including reclaimArea, use the following commands: optDesign -preCTS setOptMode -reclaimArea optDesign -preCTS -incr You can use the above features separately or in combinations. Changing Default Settings in Pre-CTS Mode You can change or add parameters for the following commands and parameters that -optDesign runs automatically: setAnalysisMode The optDesign command sets -noClockTree and -noClkSrcPath by default: You cannot override these values. You can add other options. setClockDomain The optDesign command uses the options you specify. The default is all path groups. setExtractRCMode The optDesign command sets the extraction mode to -default. You cannot change this mode. Ensure that you set the appropriate extraction scale factor. May 2005 589 Product Version 4.1.5 Encounter User Guide Timing Optimization setOptMode The optDesign command sets the following options: ■ -drcMargin If you use setOptMode -drcMargin, this value is added to a dynamically calculated, internal margin. For example, if you set a margin of 0.2 (20 percent), this multiplies the max_cap and max_tran SDC constraints by 0.8. The margin can be positive or negative. If you set a margin of -0.2, this multiplies the max_cap and max_tran SDC constraints by 1.20. The optDesign command writes the margin value to the log file. ■ -holdTargetSlack If you use setOptMode -holdTargetSlack, this value is added to a dynamically calculated, internal margin. The optDesign command writes the hold target slack value to the log file. ■ -setupTargetSlack If you use setOptMode -setupTargetSlack, this value is added to a dynamically calculated, internal margin. The default -setupTargetSlack value is 0. The optDesign command writes the setup target slack value to the log file. You cannot override -noPreserveRoute. You cannot set -incrTrialRoute and you can override other options. setTrialRouteMode You can add options, but never override the default settings. The optDesign command sets the -handlePreRoute parameter. Running Pre-CTS Optimization from the GUI 1. Select Optimization from the Timing menu. The Optimization form is displayed. 2. Select preCTS. 3. Click Advanced to set advanced options. (optional) 4. Click OK. The Encounter software runs optDesign -preCTS using the other options you specify. May 2005 590 Product Version 4.1.5 Encounter User Guide Timing Optimization For more information, see “Timing Menu” in the Encounter Menu Command Reference. Performing Post-CTS Optimization The Encounter software enables you to optimize timing after the clock tree has been built. The goals of post-CTS optimization include: ■ Fixing remaining design rule violations ■ Fixing hold time violations ■ Optimizing remaining setup violations ■ Correcting timing with propagated clocks ■ Reducing area Note: At any design stage, optDesign ignores the order in which you specify parameters. This section discusses the following topics: ■ Correcting Violations in Post-CTS Mode on page 591 ■ Post-CTS Timing Optimization Options on page 592 ■ Incremental Post-CTS Optimization on page 593 ■ Changing Default Settings in Post-CTS Mode on page 594 ■ Running Post-CTS optDesign from the GUI on page 595 Correcting Violations in Post-CTS Mode ■ To optimize timing after the clock tree has been built, use the following commands: optDesign -postCTS The optDesign command corrects DRVs, then setup violations. ■ To repair design rule violations only, use the following command: optDesign -postCTS -drv ■ To repair setup violations only, use the following command: optDesign -postCTS -setup ■ (Optional) To repair DRVs and setup violations, you can use the following command: May 2005 591 Product Version 4.1.5 Encounter User Guide Timing Optimization optDesign -postCTS -drv -setup This is the default behavior, so you are not required to specify these two parameters. If you do, the software first repairs DRVs, then setup violations, regardless of the order in which you specify the parameters. ■ To repair hold violations only, use the following command: optDesign -postCTS -hold ■ To repair setup and hold violations, use the following command: optDesign -postCTS -setup -hold These operations take place sequentially, not concurrently. Regardless of the order in which you specify the options, optDesign first repairs setup violations, then repairs hold violations as long as these repairs do not worsen setup times. Post-CTS Timing Optimization Options ■ To perform optimization on specific path groups, use the following commands: clearClockDomains setClockDomains -fromType domainName -toType domainName optDesign -postCTS For example, to perform optimization on register-to-register paths, use the following commands: clearClockDomains setClockDomains -fromType register -toType register optDesign -postCTS ■ To reclaim area during optimization, use the following commands: setOptMode -reclaimArea optDesign -postCTS ■ To take advantage of useful skew when optimizing timing in post-CTS mode, use the following commands: setOptMode -usefulSkew optDesign -postCTS If you have already performed detail routing on the clock tree, the Encounter software performs global and detailed ECO routing automatically using NanoRoute™ in post-CTS useful skew mode. If you do not want optDesign to do this, specify the -noECORoute parameter as follows: setOptMode -usefulSkew optDesign -postCTS -noECORoute If you specify -noECORoute before running optimization, the Encounter software performs trial routing to estimate clock delays. May 2005 592 Product Version 4.1.5 Encounter User Guide Timing Optimization ■ To run post-CTS optimization if your design has a clock mesh, use the following commands: setOptMode -noUsefulSkew optDesign -postCTS Incremental Post-CTS Optimization After you have initially optimized timing using optDesign -postCTS, you can optimize incrementally to repair violations only on paths that contain violations. ■ To perform optimization on specific path groups, use the following commands: clearClockDomains setClockDomains -fromType domainName -toType domainName optDesign -postCTS -incr For example, to perform incremental optimization on register-to-register paths, use the following commands: clearClockDomains setClockDomains -fromType register -toType register optDesign -postCTS -incr ■ To optimize setup time incrementally and reduce area, use the following commands: setOptMode -reclaimArea optDesign -postCTS -incr ■ To take advantage of useful skew when optimizing timing in incremental post-CTS mode, use the following commands: setOptMode -usefulSkew optDesign -postCTS -incr If you have already performed detail routing on the clock tree, the software performs global and detailed ECO routing automatically using NanoRoute in post-CTS useful skew mode. If you do not want the software to do this, specify the -noECORoute parameter as follows: setOptMode -usefulSkew optDesign -postCTS -noECORoute -incr If you specify -noECORoute before running optimization, optDesign performs trial routing to estimate clock delays. ■ To run incremental post-CTS optimization if your design has a clock mesh, use the following commands: setOptMode -noUsefulSkew optDesign -postCTS -incr May 2005 593 Product Version 4.1.5 Encounter User Guide Timing Optimization Changing Default Settings in Post-CTS Mode You can change or add parameters for the following commands and parameters that -optDesign runs automatically: setAnalysisMode The optDesign command sets -noClockTree and -noClkSrcPath by default: You cannot override these values. You can add other options. setClockDomain The optDesign command uses the options you specify. The default is all path groups. setExtractRCMode The optDesign command sets the extraction mode to -default. You cannot change this mode. Ensure that you set the appropriate extraction scale factor. setOptMode The optDesign command sets the following options: ■ -drcMargin If you use setOptMode -drcMargin, this value is added to a dynamically calculated, internal margin. For example, if you set a margin of 0.2 (20 percent), this multiplies the max_cap and max_tran SDC constraints by 0.8. The margin can be positive or negative. If you set a margin of -0.2, this multiplies the max_cap and max_tran SDC constraints by 1.20. The optDesign command writes the margin value to the log file. ■ -holdTargetSlack If you use setOptMode -holdTargetSlack, this value is added to a dynamically calculated, internal margin. The optDesign command writes the hold target slack value to the log file. ■ -setupTargetSlack If you use setOptMode -setupTargetSlack, this value is added to a dynamically calculated, internal margin. The default -setupTargetSlack value is 0. The optDesign command writes the setup target slack value to the log file. The -noPreserveRoute, -incrTrialRoute, and -preserveRoute options have no effect on optDesign. You can override other options. May 2005 594 Product Version 4.1.5 Encounter User Guide Timing Optimization setTrialRouteMode You can add options, but never override the default settings. The optDesign command sets the -handlePreRoute parameter. Running Post-CTS optDesign from the GUI 1. Select Optimization from the Timing menu. The Optimization form is displayed. 2. Select postCTS. 3. Click Advanced to set advanced options. (optional) 4. Click OK. The Encounter software runs optDesign -postCTS using the other options you specify on this form. Performing Post-Route Optimization The goals of post-route optimization include: ■ Repairing timing problems and design rule violations without introducing new problems ■ Resolving signal integrity (SI) issues This section discusses the following topics: ■ Correcting Violations in Post-Route Mode on page 596 ■ Correcting Signal Integrity Violations on page 597 The Encounter software corrects setup violations and design rule violations unless you specify otherwise. The software performs incremental RC and delay calculation, and runs NanoRoute™ to perform ECO routing. If filler cell definitions were provided during design import, the software removes and adds them as needed. For filler cells handling you must either specify the following commands: setSIMode -cmdAddFill {addFiller -cell FILL32 FILL16 ........FILL1} setSIMode -cmdDeleteFill {deleteFiller -cell FILL32 FILL16 ........FILL1} or set the following global variables: set rda_siFlow(cmdDeleteFiller) "addFiller -cell FILL32 FILL16 ........FILL1" set rda_siFlow(cmdAddFiller) "deleteFiller -cell FILL32 FILL16 ........FILL1" May 2005 595 Product Version 4.1.5 Encounter User Guide Timing Optimization If you set these global variables, the settings are saved to the configuration file. During post-route optimization, there should be very few violations that need correction. The primary sources of these timing violations include: ■ Inaccurate prediction of the routing topology during pre-route optimization due to congestion-based detour routing ■ Minor correlation issues between default and detailed RC extraction. ■ Incremental delays due to parasitics coupling Important Because the violations at this stage are due to inaccurate modeling of the final route topology and the attendant parasitics, it is critical at this point not to introduce any additional topology changes beyond those needed to fix the existing violations. Making unnecessary changes to the routing at this point can lead to a scenario where fixing one violation leads to the creation of others. This cascading effect creates a situation where it becomes impossible to close on a final timing solution with no DRVs. One of the strengths of post-route optimization is its ability to simultaneously cut a wire and insert buffers, create the new RC graph at the corresponding point, and modify the graph to estimate the new parasitics for the cut wire without re-doing extraction. To take even more advantage of this feature, you can provide an external SPEF generated by a sign-off extraction tool for improved convergence. If you do, you must provide a full SPEF (reduced SPEF does not work), and one of the following conditions must be met: ■ The SPEF must be generated with node locations using the starN format. The runQX command in Encounter has been enhanced to output this format using the spefOutput starN option. For example: runQX -spefOutput starN. or ■ The resistance values in the LEF file must match those in the technology file used by Fire & Ice or starRC to generate the SPEF, which enables Encounter extraction to match the routes with the SPEF RC graph. Note: At any design stage, optDesign ignores the order in which you specify parameters. Correcting Violations in Post-Route Mode ■ To optimize timing after detailed routing, use the following command: optDesign -postRoute May 2005 596 Product Version 4.1.5 Encounter User Guide Timing Optimization The optDesign command corrects DRVs and setup violations, as it does in pre-CTS and post-CTS modes. The optDesign -postRoute command is equivalent to the following command: optDesign -preCTS -drv -setup The optDesign command also performs an additional register-to-register optimization if the worst negative slack does not occur on a register-to-register path. The optDesign command cuts wires during buffer insertion and resizing. If you do not provide a SPEF file, optDesign simultaneously cuts the RC graph at the corresponding point to estimate RCs on the cut wires. In post-route mode, the software refines placement, then runs NanoRoute in ECO mode to reroute affected wires. The Encounter software extracts RCs (except if you provide a SPEF file) and reports final timing results. After post-route optimization is complete, you can run a signoff extractor and compare the results with those generated by the Encounter software. The optDesign command enables you to correct only hold violations during post-route optimization, without correcting setup violations. You can benefit from correcting hold violations before correcting setup violation because the hold repairs might cause more setup violations, which you can correct in a later step. ■ To correct only hold violations in post-route mode, specify the following commands: optDesign -postRoute -hold The optDesign command sets the setupTargetSlack value to .1. Hold repair does not degrade slack to less than the setupTargetSlack value. You can override this value by specifying setOptMode -setupTargetSlack before you run optDesign. ■ To correct setup and hold violations, use the following command: optDesign -postRoute -setup -hold The optDesign command performs these operations sequentially, not concurrently. The software repairs a hold violation only if it does not make setup slack worse than the setup target slack on a path. Correcting Signal Integrity Violations ■ To correct signal integrity violations when optimizing timing in post-route mode, use the following command: optDesign -postRoute -si In addition to the timing violations caused by inaccurate route topology modeling, the parasitic cross-coupling of neighboring nets can cause the following problems that need to be addressed in high speed designs: May 2005 597 Product Version 4.1.5 Encounter User Guide Timing Optimization ❑ An increase or decrease in incremental delay on a net due to the coupling of its neighbors and their switching activity. ❑ Glitches (voltage spikes) that can be caused in one signal route by the switching of a neighbor resulting in a logic malfunction. This command has its maximum effect once most other timing-related issues have been corrected. It uses CeltIC to perform the SI analysis and corrects any problems found by using a combination of buffer resizing and routing modifications. Use the optDesign -postRoute -si command only after using the optDesign -postRoute command. ■ To correct setup, hold, and signal integrity violations, use the following command: optDesign -postRoute -setup -hold -si The optDesign command performs these operations sequentially, not concurrently. Instead, this command performs the following operations sequentially: ■ ❑ Post-route setup repair ❑ Post-route hold repair ❑ Post-route signal integrity repair for glitches, noise and setup violation after including signal integrity effects. To input a SPEF file for use during post-route signal integrity optimization, use the following commands. spefIn spefFileName optDesign -postRoute -si Changing Default Settings in Post-Route Mode You can change or add parameters for the following commands and parameters that -optDesign runs automatically: setAnalysisMode The optDesign command sets -clockTree and -clkSrcPath. You can override other options. setClockDomain The optDesign command uses the options you specify. The default is all path groups. setExtractRCMode The optDesign command sets the extraction mode to -detail. You cannot change this mode. Ensure that you set the appropriate extraction scale factor. May 2005 598 Product Version 4.1.5 Encounter User Guide Timing Optimization setSIMode The -si option sets setSIMode -useTimer PKS_IPO as default, but you can set CTE, PKS, or PT instead. You can override any settings. setTrialRouteMode You can add options, but never override the default settings. The optDesign command sets the -handlePreRoute parameter. Running Post-Route Optimization from the GUI 1. Select Optimization from the Timing menu. The Optimization form is displayed. 2. Select postRoute. 3. Click Advanced to set advanced options. (optional) 4. Click OK. The Encounter software runs optDesign -postRoute using the other options you specify on this form. Performing Post-CTS and Post-Route Optimization with Cadence PKS You can use PKS as an alternative to the native Encounter engine for post-CTS and postRoute timing optimization. This section discusses the following topics: ■ Running PKS with Text Commands on page 599 ■ Running PKS from the GUI on page 600 ■ Fine-Tuning Cadence PKS Optimization from the GUI on page 600 Running PKS with Text Commands The Encounter software enables you to run Cadence PKS in post-CTS or post-route mode. ■ To run Cadence PKS in post-CTS mode, use the following command: optDesign -postCTS -pks May 2005 599 Product Version 4.1.5 Encounter User Guide Timing Optimization ■ To run Cadence PKS in post-route mode, use the following command: optDesign -postRoute -pks Running PKS from the GUI To run Cadence PKS in post-CTS or post-route modes, complete the following steps: 1. From the main menu, select Timing – Optimization. The Optimization form is displayed. 2. Click on postCTS or postRoute. 3. Click Advanced. The Advanced Options form is displayed. 4. Click Use PKS. Fine-Tuning Cadence PKS Optimization from the GUI The Encounter software also provides access to advanced Cadence PKS options, which allow you greater flexibility to fine-tune your optimization. To run the Encounter interface to Cadence PKS in post-CTS mode, complete the following steps: 1. From the main menu, select Timing – Optimization. The Optimization form is displayed. 2. Select postCTS. 3. Click on the Advanced button. The Advanced Options form is displayed. 4. Click on Run PKS. The Physical Synthesis Optimization form is displayed. When you click OK, the software runs the runPhySyn command with the parameters corresponding to the options you set. To run the Encounter interface to Cadence PKS in post-route mode, complete the following steps: 1. From the main menu, select Timing – Optimization. May 2005 600 Product Version 4.1.5 Encounter User Guide Timing Optimization The Optimization form is displayed. 2. Select postRoute. 3. Click on the Advanced button. 4. Click on Advanced PKS. The Post Route Optimization form is displayed. When you click OK, the software runs the postRouteOpt command with the parameters corresponding to the options you set. For more information on the Cadence PKS user interface, see the following commands in “Timing Menu” in the Encounter Menu Reference. ■ Synthesis Optimization ■ Post-RouteOptimization optDesign Parameter Matrix optDesign -preCTS -post -postRoute CTS -incr -pks -si -setup -drv -hold -preCTS N/A – – – – – + + – -postCTS – N/A – + + – + + + -postRoute – – N/A + + + + + + -incr + + + N/A – – + – + -pks – + + – N/A + + – + -si – – + – + N/A + – + -setup + + + + + + N/A + + -drv + + + – – + + N/A – -hold – + + + + + + – N/A Legend + You can use the option in the row together with the parameter in the column. – You cannot use the option in the row together with the parameter in the column. May 2005 601 Product Version 4.1.5 Encounter User Guide Timing Optimization Legend N/A The options in the row and column are identical. Useful Skew The useful skew feature in the Encounter software modifies the clock arrival time on sequential elements in order to improve the data path timing between sequential elements. The Encounter software provides two approaches, depending on whether you have run CTS: ■ Pre-CTS mode Advances the clock signal for critical path startpoints. The start point must be a sequential element: No input paths are allowed. ■ Post-CTS mode Delays the clock signal for critical path end points. The endpoint must be a sequential element: No output paths are allowed. Pre-CTS Mode To take advantage of useful skew during pre-CTS optimization, use the following commands: setOptMode -usefulSkew optDesign -preCTS For more information on the following commands, see “Timing Optimization Commands” in the Encounter Text Command Reference. ■ setOptMode ■ optDesign The software determines the sequential instances whose clock signals can be advanced, then generates two files: latency_file.sdb and scheduling_file.cts. ■ latency_file.sdc This latency file models the proposed clock advancement for timing analysis. ■ scheduling_file.cts This file contains scheduling information for clock tree synthesis. You must specify this file when you specify the CTS constraints, for example: May 2005 602 Product Version 4.1.5 Encounter User Guide Timing Optimization specifyClockTree -clkfile scheduling_file.cts specifyClockTree -clkfile original_constraints.cts You can change the names of the latency and scheduling files by using the following commands: setLatencyFile fileName setSchedulingFile fileName You can use the following commands to report the names of the latency and schedule files: getLatencyFile getSchedulingFile For more information on the following commands, see “Timing Optimization Commands” in the Encounter Text Command Reference: ■ getLatencyFile ■ getSchedulingFile ■ setLatencyFile For more information on the following command, see “Clock Tree Synthesis Commands” in the Encounter Text Command Reference. ■ specifyClockTree Post-CTS Mode To take advantage of useful skew during post-CTS optimization, use the following commands: setOptMode -usefulSkew optDesign -postCTS In this case, the clock tree is already in place. The software determines the sequential instances whose clock signals can be delayed, and adds buffers or inverters to their clock nets accordingly. If the clock is already detail routed, these commands perform ECO routing on the clock tree after useful skew optimization. Controlling Useful Skew Optimization You have the option to control how the Encounter software employs useful skew by using the setUsefulSkewMode command. If you choose specific cells for clock tree synthesis, you should use setUsefulSkewMode -useCells to specify the cells to use for padding the clock nets. If you have no constraint May 2005 603 Product Version 4.1.5 Encounter User Guide Timing Optimization on the type of cells allowed in the clock tree, you can omit this option, and the software selects the best combination of cells to achieve the required delay. For example, if you want clock buffers or inverters only, specify the following command: -setUsefulSkewMode -useCells {…} The -maxSkew parameter causes the software to advance or delay sequential elements more aggressively than it does by default, without degrading the worst negative slack. With this parameter, the tool skews other registers as much as possible regardless of the worst slack on a particular register. This approach can help with difficult timing closure situations. In post-CTS mode, critical paths probably have been fully optimized, so further traditional optimization cannot dramatically improve timing. To close timing, you might need to delay the endpoint clock pins more than the useful skew feature would do by default, by only padding the clock nets until the data path meets the target slack. To take advantage of this feature, use the following command: setUsefulSkewMode -maxSkew To exclude boundary sequential cells in useful skew calculations, use the following command: setUsefulSkewMode -noBoundary If you do not specify this parameter, -boundary is selected. In addition, the software takes boundary cells into account and ordinary sequential elements into account when calculating useful skew. To use NanoRoute detail routing to route nets that are added or changed during useful skew optimization, use the following commands: setUsefulSkewMode -ecoRoute To limit the amount of slack the Encounter software can borrow from neighboring flip-flops when performing useful skew operations, use the following command: setUsefulSkewMode -maxAllowDelay The Encounter delay calculation and RC extraction methods might differ from those of signoff tools, so other setup violations might occur if the Encounter tool borrows too much slack. By having control over slack borrowing, you can prevent these setup violations. Limiting borrowed skew also limits the clock tree skew to avoid large hold violations. If you do not specify this parameter, the Encounter software automatically borrows the amount of slack needed (there is no maximum) to reduce setup violations. To report the current setUsefulSkew settings, use the following command: getUsefulSkew For more information on the following command, see “Timing Optimization Commands” in the Encounter Text Command Reference: May 2005 604 Product Version 4.1.5 Encounter User Guide Timing Optimization ■ setUsefulSkewMode Optimizing Timing Using a Rule File In a partitioned design, top-level and leaf partitions are generated. Before implementation, the leaf partitions’ timing models are not completely accurate. Because accurate timing cannot be derived without accurate timing models for leaf partitions, rule-based optimization is a more suitable option than timing analysis-based optimization at this design stage. You can use the rules file for the top-level design by using the insertRepeater or optFanout command. Performing Timing Optimization When the Constraint File Includes the set_case_analysis Constraint If you include the set_case_analysis constraint in the timing constraint file, The Encounter software sets a constant value on specified signals before performing timing analysis. This constant value is then propagated through the path. If you use the same timing constraint file for timing optimization, the software does not perform timing optimization on the constant nets because the delays are 0. If you want to perform timing optimization on these nets, you must first specify setAnalysis -noCaseAnalysis. Reducing Leakage Power The Encounter software enables you to reduce leakage power in your design without degrading timing. After your design meets timing, you can run the following command to view the total leakage power in the design: reportLeakagePower If you want to obtain a report file, run reportLeakagePower with the -outfile fileName option. The following example is a leakage report showing the total leakage power in microwatts, along with cell usage statistics. For each library, the number of cells used in the design and the total leakage power dissipated by the cells are listed. Total leakage power = 785.079708uW Cell usage statistics: May 2005 605 Product Version 4.1.5 Encounter User Guide Timing Optimization Library normalVt, 49265 cells (64.855650%), 733.007529uW (93.367269%) Library highVt, 26696 cells (35.144350%), 52.072179uW (6.632725%) Run the following command to resize low voltage threshold gates in the design to gates with a higher voltage threshold, while maintaining timing: optLeakagePower This command only resizes cells that have positive slack. Cells that belong to any library are candidates for swapping. Run the following command to swap only cells belonging to library myLib: optLeakagePower -library myLib Cells in other libraries are not swapped. After running the optLeakagePower command, you can create a new leakage power report to view results. reportLeakagePower -outfile fileName Troubleshooting Leakage Power Problems If you run the optLeakagePower command and obtain no leakage power reduction, use the following methods to troubleshoot the problem: ■ Check the leakage power report. Use the following command: reportLeakagePower If the report shows the cell leakage power is 0 µW, this is a good indication that your technology library does not carry cell_leakage_power attributes for the cells, or those attributes have been annotated as 0. For example, Library slow, 9424 cells (99.294068%), 0.000000uW (0.000000%) shows that the slow library has no leakage information. ■ If you run optLeakagePower -force -postRoute, and do not see leakage power reduction, also make sure that the high vt cells and low vt cells have the exact same physical footprint. ■ The optLeakagePower command does not touch cells that are marked as +FIXED. To change the attribute, use the following database commands: dbSetIsInstPreplaced [dbGetInstByName your_Instance_name] 0 ■ Make sure that all the LEF files and timing libraries for all the vt cells (high-vt, low-vt, and normal vt), have been loaded, so optleakagePower can achieve maximum May 2005 606 Product Version 4.1.5 Encounter User Guide Timing Optimization performance. One way to verify whether you load in all the necessary LEF files is by using the following commands: reportLeakagePower optLeakagePower -force reportLeakagePower If the reports before and after optLeakagePower are the same, then most likely there are LEF files and timing libraries for a high vt or normal vt library that has not been loaded. Load those libraries first, then rerun the optLeakagePower command. Using Cell Footprints In general, timing optimization relies on information in the footprint file. For example, the optFanout command adds cells only if they are defined in the buffer footprint file. However, netlist restructuring operations do not rely on footprints, and are insensitive to whether or not a cell is defined in the footprint file. To prevent all operations (including restructuring operations) from using a given cell, specify the “DontUse” mechanism from the library or the sdc constraint file. Viewing Added Buffers After running timing optimization, you can use the Design Browser to view the newly added buffer and instance names. The newly inserted buffer or instance and the newly created net name are annotated with the prefix FE_. See “Naming Conventions” on page 611 for more information. Timing Optimization Mode Defaults For Effort Levels The following tables show the defaults and availability of parameters for the setOptMode command in low, medium, and high effort modes. Low Effort The following table shows defaults and availability of parameters for -lowEffort mode. setOptMode Parameter Default -addInst | -noAddInst -addInst May 2005 607 Product Version 4.1.5 Encounter User Guide Timing Optimization -addPortAsNeeded | -neverAddPort -addPortAsNeeded -deleteInst | -noDeleteInst -deleteInst -downsizeInst | -noDownsizeInst -downsizeInst -drcMargin 0 -fixDRC | -noFixDRC -fixDRC -fixFanoutLoad | -noFixFanoutLoad -noFixFanoutLoad -keepPort Off: Can specify -maxDensity 0.95 -moveInst | -noMoveInst -noMoveInst Cannot specify -moveInst -noFootPrintChange | -footPrintChange -footPrintChange -noOptimizeAssignNet | -optimizeAssignNet -optimizeAssignNet -noOptimizeConstantNet | -optimizeConstantNet -optimizeConstantNet -noPreserveRoute | -incrTrialRoute | -noIncrRoute -incrTrialRoute -optimizeFF | -noOptimizeFF -optimizeFF -reclaimArea | -noReclaimArea -noReclaimArea Cannot specify -reclaimArea -restruct | -noRestruct -noRestruct Cannot specify -restruct -simplifyNetlist | -noSimplifyNetlist -noSimplifyNetlist Cannot specify -simplifyNetlist -swapPin | -noSwapPin -noSwapPin Cannot specify -swapPin -targetSlack 0.0 -updateClockSkew | -noUpdateClockSkew -updateClockSkew May 2005 608 Product Version 4.1.5 Encounter User Guide Timing Optimization -usefulSkew | -noUsefulSkew -noUsefulSkew Cannot specify -usefulSkew Medium Effort The following table shows defaults and availability of parameters for -mediumEffort mode. setOptMode Parameter Default -addInst | -noAddInst -addInst -addPortAsNeeded | -neverAddPort -addPortAsNeeded -deleteInst | -noDeleteInst -deleteInst -downsizeInst | -noDownsizeInst -downsizeInst -drcMargin 0 -fixDRC | -noFixDRC -fixDRC -fixFanoutLoad | -noFixFanoutLoad -noFixFanoutLoad -keepPort Off: Can specify -maxDensity 0.95 -moveInst | -noMoveInst -noMoveInst Cannot specify -moveInst -noFootPrintChange | -footPrintChange -footPrintChange -noOptimizeAssignNet | -optimizeAssignNet -optimizeAssignNet -noOptimizeConstantNet | -optimizeConstantNet -optimizeConstantNet -noPreserveRoute | -incrTrialRoute | -noIncrRoute -incrTrialRoute -optimizeFF | -noOptimizeFF -optimizeFF -reclaimArea | -noReclaimArea -noReclaimArea -restruct | -noRestruct -noRestruct Cannot specify -restruct May 2005 609 Product Version 4.1.5 Encounter User Guide Timing Optimization -simplifyNetlist | -noSimplifyNetlist -noSimplifyNetlist Cannot specify -simplifyNetlist -swapPin | -noSwapPin -noSwapPin Cannot specify -swapPin -targetSlack 0.0 -updateClockSkew | -noUpdateClockSkew -updateClockSkew -usefulSkew | -noUsefulSkew -noUsefulSkew Cannot specify -usefulSkew High Effort The following table shows defaults and availability of parameters for -highEffort mode. setOptMode Parameter Default -addInst | -noAddInst -addInst -addPortAsNeeded | -neverAddPort -addPortAsNeeded -deleteInst | -noDeleteInst -deleteInst -downsizeInst | -noDownsizeInst -downsizeInst -drcMargin 0.0 -fixDRC | -noFixDRC -fixDRC -fixFanoutLoad | -noFixFanoutLoad -noFixFanoutLoad -keepPort Off: Can specify -maxDensity 0.95 -moveInst | -noMoveInst -moveInst -noFootPrintChange | -footPrintChange -footPrintChange -noOptimizeAssignNet | -optimizeAssignNet -optimizeAssignNet -noOptimizeConstantNet | -optimizeConstantNet -optimizeConstantNet May 2005 610 Product Version 4.1.5 Encounter User Guide Timing Optimization -noPreserveRoute | -incrTrialRoute | -noIncrRoute -incrTrialRoute -optimizeFF | -noOptimizeFF -optimizeFF -reclaimArea | -noReclaimArea -noReclaimArea -restruct | -noRestruct -restruct -simplifyNetlist | -noSimplifyNetlist -noSimplifyNetlist -swapPin | -noSwapPin -swapPin -targetSlack 0.0 -updateClockSkew | -noUpdateClockSkew -updateClockSkew -usefulSkew | -noUsefulSkew -noUsefulSkew Naming Conventions Instance Description Command FE_OCPN Net name added by critical path optimization. optDesign FE_OCPC Instance name added by critical path optimization. optDesign FE_FHN Net name added by hold time repair optDesign FE_FHC Instance name added by hold time repair. optDesign FE_RC Instance created by netlist restructuring. optDesign FE_RN Net created by netlist restructuring. optDesign FE_OFN Buffer net name added by rule-based buffer insertion insertRepeater/ optFanout FE_OFC Buffer instance name added by rule-based buffer insertion insertRepeater/ optFanout FE_PHC Cell name added by post-route hold repair. optDesign FE_PHN Net name added by post-route hold repair. optDesign FE_PSC Cell name added by post-route setup repair. optDesign FE_PSN Net name added by post-route setup repair. optDesign May 2005 611 Product Version 4.1.5 Encounter User Guide Timing Optimization May 2005 612 Product Version 4.1.5 Encounter User Guide 22 Interactive ECO This chapter describes how to use the interactive ECO feature, and how to compare physical design data. The chapter presents the following topics: ■ Overview on page 614 ■ Before You Begin on page 614 ■ Results on page 614 ■ Adding Buffers on page 614 ■ Changing the Instance Cell on page 616 ■ Deleting Buffers on page 618 ■ Displaying Buffer Trees on page 619 ■ Naming Conventions for Interactive ECO on page 620 ■ Comparing Physical Design Data on page 620 May 2005 613 Product Version 4.1.5 Encounter User Guide Interactive ECO Overview The Interactive ECO feature enables you to run manual incremental updates to the design to repair timing or transition time violations. You can run Interactive ECO after running placement, timing optimization, or signal integrity analysis (CeltIC/SI). If you performed trial route and RC extraction on the design, and the timing graph was built before running an ECO, then the trial route data, RC extraction data, and timing graph are incrementally updated. Before You Begin Before you can perform interactive ECO, the following conditions must be met: ■ You must place and route the design, ■ You must load the design into the current session. Results The following output files are generated: ■ Updated netlist ■ Updated placement Adding Buffers You can add one buffer at a time on a net. 1. To open the Interactive ECO form, select Timing – Interactive ECO from the Encounter menu. May 2005 614 Product Version 4.1.5 Encounter User Guide Interactive ECO This opens the Interactive ECO form. The Add Buffer page is selected. 2. Enter the net name in the Net field. Type the net name, or click on a displayed net in the design display window and click get selected. 3. In the Buffer field, enter the cell type name of the buffer cell to add, or click on the arrow to right of the field and select a buffer from the list. 4. Select an Offload option. There are four ways to specify the buffer connection. ➤ To connect the added buffer to drive all the receivers, specify All Terms. Use this to reduce the delay and output transition time of a weak driver driving a large capacitive load. ➤ To connect the added buffer to drive the listed receivers, specify Listed Terms. This provides full flexibility for building an arbitrary buffer connection. ➤ To connect the added buffer to drive only noncritical receivers, select By Slack. This checks the timing graph for noncritical receivers and offloads those from the critical path, and could improve critical path timing by penalizing noncritical path delays. ➤ To add a buffer on a route (after you have routed the design), select By Routing. When the buffer is added, the route closest to the selected location is cut and the buffers are inserted on that route. 5. Enter location for the buffer. May 2005 615 Product Version 4.1.5 Encounter User Guide Interactive ECO You can use the automatically assigned locations, enter the locations, or click on an area in the design display window and click get coord. 6. To evaluate the effects of the ECOs before you commit the change, do one of the following: a. To evaluate through-object slack only, click Eval. b. To evaluate slack for the most critical path, click Eval All. Encounter displays a slack report based on the options you select. Note: You can only use these evaluation features if you have first selected By Routing. 7. (Optional) To legalize placement of the ECO changes, click Do Refine Placement. 8. Click Apply. Note: You can also add a buffer around the I/O pin of a block using the attachIOBuffer command. The following text command and parameters provide equivalent or additional functionality: ■ addBuffer For more information, see “Interactive ECO Commands” in the Encounter Text Command Reference. Changing the Instance Cell You can upsize or downsize instances. Upsizing an instance that drives a large load can improve the driver delay and the transition time at the receivers. You can also downsize an instance on the noncritical path to reduce the loading of its driver on the critical path. 1. To open the Interactive ECO form, select Timing – Interactive ECO from the Encounter menu, and click the Change Inst Cell tab. May 2005 616 Product Version 4.1.5 Encounter User Guide Interactive ECO The Change Inst Cell page is displayed. 2. In the Instance field, enter the hierarchical instance name to be changed. Type the instance name, or click an instance in the design display window and click get selected. 3. Enter the replacement cell name in the New Cell field. Type the cell name, or use the pull-down menu to select a cell. 4. To evaluate the effects of the ECOs before you commit the change, do one of the following: ➤ To evaluate through-object slack only, click Eval. ➤ To evaluate slack for the most critical path, click Eval All. Encounter displays a slack report based on the options you select. 5. (Optional) To legalize placement of ECO changes, click Do Refine Placement. 6. Click Apply. The following text command and parameters provide equivalent or additional functionality: ■ changeCell For more information, see “Interactive ECO Commands” in the Encounter Text Command Reference. May 2005 617 Product Version 4.1.5 Encounter User Guide Interactive ECO Deleting Buffers You can delete redundant buffers that cause extra delay. Buffers are typically over-added by synthesis tools based on wireload models. 1. To open the Interactive ECO form, select Timing – Interactive ECO from the Encounter menu, and click the Delete Buffer tab. The Delete Buffer page is displayed. 2. Enter the buffer instance name to be removed in the Inst field. Type the instance name, or click an instance in the design display window and click get selected. 3. Select a deletion option. 4. To evaluate the through-object slack caused by the ECOs, before you commit the change, click on the Eval button. Encounter displays a slack report. 5. (Optional) To legalize placement of ECO changes, click Do Refine Placement. 6. Click Apply. The following text command and parameters provide equivalent or additional functionality: ■ removeBuffer May 2005 618 Product Version 4.1.5 Encounter User Guide Interactive ECO For more information, see “Interactive ECO Commands” in the Encounter Text Command Reference. Displaying Buffer Trees You can inspect the routing topology of the buffer tree after it is created. If the buffer tree requires correction, you can rebuild or modify it through the other three pages in the Interactive ECO form. 1. To open the Interactive ECO form, select Timing – Interactive ECO from the Encounter menu, and click the Display Buffer Tree tab. The Display Buffer Tree page is displayed. 2. To select a buffer tree, enter the net name in the Net field. You can type the net name, or click a net in the design display window and click get selected. 3. (Optional) To legalize placement of ECO changes, click Do Refine Placement. 4. Click Apply. The following text command provide equivalent or additional functionality: ■ displayBufTree For more information, see “Interactive ECO Commands” in the Encounter Text Command Reference. May 2005 619 Product Version 4.1.5 Encounter User Guide Interactive ECO Naming Conventions for Interactive ECO After running interactive ECO, you can use the Design Browser to view the newly added instance names, prefixed with FE_. The interactive ECO operation naming conventions are described in the following table: Name Prefix Description FE_ECON A net added by interactive ECO FE_ECOC An instance added by interactive ECO Comparing Physical Design Data After making changes to a DEF file, you can compare the new file to the information stored in the Encounter database. You can perform this comparison after you perform ECO. Use the following command to compare physical design data: defComp defFile -reportFile fileName The default filename is defPhyDiff.rpt The report file includes the following information: ■ VERSION statement VERSION num num ■ Specifies the file version number. UNITS statement UNITS num num ■ Specifies the unit for the values such as coordinates, width, and so on. ADDINST statement ADDINST instName cellName x y orientation instName Specifies the instance name. cellName Specifies the master cell name of the instance. May 2005 620 Product Version 4.1.5 Encounter User Guide Interactive ECO x y Specifies the coordinates of the instance. orientation Specifies the orientation of the instance. The orientation can be one of the following: N, FN, S, FS, W, FW, E, FE, as used by DEF file. Note: The report provides the connectivity of added instances in the NETS section described below. ■ DELINST statement DELINST instName cellName x y orientation The arguments have the same meaning as described in ADDINST statement. ■ CHANGECELL statement CHANGECELL instName oldCellName newCellName The master cell of the instance instName is changed from oldCellName to newCellName. The coordinate, orientation and connectivity of the instance are not changed. If a master cell is changed along with any of coordinate, orientation and connectivity, Encounter considers this change as a deletion and addition of the instance. Rather than including a CHANGECELL statement, the file contains one pair of DELINST and ADDINST statements. ■ MOVEINST statement MOVEINST instName [COORD oldX oldY newX newY] [ORIENT oldOrientation newOrientation] The statement contains the COORD phrase if the instance instName has moved, and the ORIENT phrase if the instance has changed orientation. ■ ADDNET statement ADDNET netName netName ■ Specified the name of a added net. DELNET statement DELNET netName netName ■ Specifies the name of the deleted net. ADDPIN statement May 2005 621 Product Version 4.1.5 Encounter User Guide Interactive ECO ADDPIN netName instName pinName ■ netName Specifies the net from which the pin is added. instName Specifies the instance name of the added pin. pinName Specifies the name of the added pin. DELPIN statement DELPIN netName instName pinName ■ netName Specifies the net from which the pin is deleted. instName Specifies the instance name of the deleted pin. pinName Specifies the name of the deleted pin. CHANGEROUTE and ENDCHANGEROUTE statements CHANGEROUTE netName ENDCHANGEROUTE These statements mark the beginning and end of the CHANGEROUTE section that contains changes on the routing segment on net netName. The wire change statements are included between the CHANGEROUTE and ENDCHANGEROUTE statements. ■ POWERROUTE and ENDPOWERROUTE statements POWERROUTE netName ENDPOWERROUTE These two statements mark the beginning and the end of the POWERROUTE section that contains the power routing differences between two DEF files. The wire change statements are included between the POWERROUTE and ENDPOWERROUTE statements. ■ Wire change statements The ADDWIRE, DELWIRE, ADDVIA, and DELVIA statements appear between the CHANGEROUTE and ENDCHANGEROUTE statements, or POWERROUTE and ENDPOWERROUTE statements. ❑ ADDWIRE statement ADDWIRE layerName width x1 y1 x2 y2 layerName Specifies the layer name of wire segment added to the net. width Specifies the width of the wire segment added to the net. May 2005 622 Product Version 4.1.5 Encounter User Guide Interactive ECO x1 y1 Specifies the left or bottom coordinate of wire segment added to the net. x2 y2 Specifies the right or top coordinate of wire segment added to the net. ❑ DELWIRE statement DELWIRE layerName width x1 y1 x2 y2 layerName Specifies the layer name of wire segment deleted to the net. width Specifies the width of the wire segment deleted to the net. x1 y1 Specifies the right or top coordinate of wire segment deleted from the net. x2 y2 Specifies the left or bottom coordinate of wire segment deleted from the net. ❑ ADDVIA statement ADDVIA [botLayerName bx1 by1 bx2 by2] topLayerName tx1 ty1 tx2 ty2 botLayerName Specifies the bottom layer name of the via added to the net. bx1 by1 Specifies the lower-left coordinate of bottom layer of the via added to the net. bx2 by2 Specifies the top-right coordinate of bottom layer of the via added to the net. topLayerName Specifies the top layer name of via added to the net. tx1 ty1 Specifies the lower-left coordinate of top layer of the via added to the net. tx2 ty2 Specifies the top-right coordinate of top layer of the via added to the net. Note: For turnvias, Encounter reports topLayerName only. ❑ DELVIA statement DELVIA [botLayerName bx1 by1 bx2 by2] topLayerName tx1 ty1 tx2 ty2 botLayerName May 2005 Specifies the bottom layer name of via deleted from the net. 623 Product Version 4.1.5 Encounter User Guide Interactive ECO bx1 by1 Specifies the low-left coordinate of bottom layer of the via deleted from the net. bx2 by2 Specifies the top-right coordinate of bottom layer of the via deleted from the net. topLayerName Specifies the top layer name of via deleted from the net. tx1 ty1 Specifies the low-left coordinate of top layer of the via deleted from the net. tx2 ty2 Specifies the top-right coordinate of top layer of the via deleted from the net. Note: For turnvias, Encounter reports topLayerName only. ■ ADDOBS statement ADDOBS layerName x1 y1 x2 y2 ■ layerName Specifies the layer name for the obstruction added. x1 y1 Specifies the low-left coordinate of the obstruction. x2 y2 Specifies the top-right coordinate of the obstruction. DELOBS statement DELOBS layerName x1 y1 x2 y2 layerName Specifies the layer name of the obstruction deleted. x1 y1 Specifies the lower-left coordinates of the obstruction. x2 y2 Specifies the upper-right coordinates of the obstruction. May 2005 624 Product Version 4.1.5 Encounter User Guide 23 Analyzing and Repairing Crosstalk This chapter describes how to use CeltIC™ crosstalk analyzer for cell-based designs to analyze crosstalk, and NanoRoute™ to repair crosstalk violations, such as glitch violations and noise-on-delay. This chapter presents the following topics: ■ Overview on page 626 ■ Before You Begin on page 628 ■ Results on page 628 ■ Performing Crosstalk Prevention on page 628 ■ Preparing the Data on page 629 ■ Analyzing Crosstalk on page 630 ■ Repairing Crosstalk Violations on page 631 ■ Performing Incremental Crosstalk Analysis and Repair on page 631 ■ Performing Sign-Off Crosstalk Analysis and Repair on page 632 May 2005 625 Product Version 4.1.5 Encounter User Guide Analyzing and Repairing Crosstalk Overview Crosstalk is the undesired electromagnetic coupling between signal lines that causes functional failures and delay variation. Crosstalk effects might slow down or speed up the delay depending on the transition direction of the two coupling nets. Encounter supports signal integrity (SI) operations that include crosstalk prevention, analysis, and repair. Encounter uses an advanced crosstalk repair algorithm which features: ■ Victim driver upsizing ■ Buffer insertion ■ Aggressor downsizing ■ Aggressor rip-up ■ Victim spacing and protection Note: CeltIC and nanoRoute are seamlessly integrated with these tools to perform all crosstalk analysis and repair operations. May 2005 626 Product Version 4.1.5 Encounter User Guide Analyzing and Repairing Crosstalk Analyzing and repairing crosstalk is part of the signal integrity closure repair loop, which reduces both timing and crosstalk violations starting from the prevention stage to the postroute optimization stage in the design flow. Encounter Import Placed & Optimized Design PREVENTION Encounter SI-Aware Timing & Placement Optimization NanoRoute SI-Driven & Timing-Driven Routing Encounter or QX ANALYSIS RC Extraction CeltIC Noise Violation File (celtic.eco) Noise Analysis S I Encounter/PKS/CTE Incremental SDF (celtic.sdf) Timing Analysis C l o s u r e R e p a i r L o o p Exceeds # of Iterations? Yes No Glitch Timing Criteria Met? Yes FINISH No Are Glitch and Timing Results Improving? Yes No Encounter REPAIR Repair Noise on Delay Encounter Glitch Violation Repair NanoRoute Post-Route and SI-Repair Routing May 2005 627 Product Version 4.1.5 Encounter User Guide Analyzing and Repairing Crosstalk Before You Begin The following design data files are required in order to repair crosstalk violations: ■ Netlist ■ SDC (timing information) ■ Routed Encounter database or DEF file (placement and routing information) The following library files are required in order to repair crosstalk violations: ■ LEF file (Physical library)) ■ .cdB file, ECHO model, or user-defined noise (UDN) model (Noise library) ■ .lib or TLF (Timing library) ■ Encounter extended capacitance table file ■ Fire & Ice® QX gate-level extraction tech file and library (optional) Note: Before you begin, ensure that your routed design meets all timing requirements. Results Analyzing and repairing crosstalk is an iterative process. Encounter performs crosstalk analysis and makes repairs, then repeats the process until all crosstalk violations are repaired. When finished, Encounter produces the following outputs: ■ A DEF file that contains clean timing and no crosstalk violations ■ Incremental SDF file ■ Various incremental and sign-off reports, located in the log file. Performing Crosstalk Prevention 1. Place and optimize your design. 2. Run timing and signal integrity driven routing with NanoRoute. May 2005 628 Product Version 4.1.5 Encounter User Guide Analyzing and Repairing Crosstalk NanoRoute uses signal-integrity-driven routing to change the topology to reduce coupling capacitance. For more information, see “Preventing and Repairing Crosstalk Problems” on page 429. Preparing the Data In order to analyze and repair crosstalk violations properly, you must prepare you data correctly. 1. Read in signal integrity related data and libraries. a. Generate the noise library. Use the make_cdb utility that is included with CeltIC to create the characterized noise library. You can use an Echo, XILM or cdB noise library for analyzing and repairing crosstalk violations. However, Echo models are more pessimistic and should only be used if you cannot generate a cdB library. Use XILM only for hierarchical signal integrity analysis when you have a block that was previously modeled this way. The make_cdb utility can be run in interactive mode or in batch mode. For information on how to use the make_cdb utility, see the “make_cdB Noise Characterizer User Guide.” 2. Check that the data and libraries are correct, and that there are no timing violations. b. Check your congestion map and resolve any highly congested areas using the following command: congOpt c. Correct transition time violations using the following commands: reportDRV fixDRVViolation -postRoute or optDesign timeDesign d. Perform RC Extraction and Correlation You can use both the native RC extraction and sign-off RC extraction using Fire & Ice to extract the routed design. To correlate native extraction results with sign-off extraction, you compare SPEF files from basic and sign-off extraction to generate the new scaling factors for total capacitance, cross-coupling capacitance, and resistance. Using these scaling factors, the native extraction results are closer to the sign-off extraction results, while only taking a fraction of the run time required for May 2005 629 Product Version 4.1.5 Encounter User Guide Analyzing and Repairing Crosstalk sign-off extraction. For more information, see “Correlating Native Extraction With Sign-Off Extraction”. 3. Read in a placed and routed database. restoreDesign your_design.dat your_topCell or loadConfig your_design.conf defin your_routed.def Analyzing Crosstalk Encounter uses either native or standalone CeltIC to perform crosstalk analysis. CeltIC calculates delay to cross-coupling effects on each net and produces delays in the form of a standard delay format (SDF) file. This delay is backannotated to Encounter to incorporate delay due to crosstalk effects. The resulting glitch violations are stored in the celtic.eco file. Standalone CeltIC generates output files and stores them in the ./celtic working directory. For more information, see the CeltIC User Guide. ➤ Use the Run CeltIC Crosstalk Analysis form in the Encounter Menu Guide or the runCeltIC command to specify noise analysis information such as: ❑ Mode—Native or sign-off ❑ Effort—High or low ❑ Process technology ❑ Switching windows and TWF file ❑ Block noise models Important Before performing crosstalk analysis, you must generate RC values for crosstalk coupling capacitance. Use the setExtractRCMode command to set RC extraction mode and the extractRC command to execute the extraction. Applying switching windows automatically calls the setExtractRCMode -detail -noReduce command. May 2005 630 Product Version 4.1.5 Encounter User Guide Analyzing and Repairing Crosstalk Repairing Crosstalk Violations The following factors determine how crosstalk violations are repaired: ■ Whether you are performing incremental crosstalk repair or sign-off repair. ■ The size of your design. There are two basic ways that Encounter repairs crosstalk violations: ■ Placement-based repair For repairing noise delay violations, Encounter uses buffer insertion and resizing, aggressor downsizing, aggressor rip-up, victim net spacing, and protection to fix critical nets in the design. ■ Routing-based repair Encounter uses NanoRoute to repair noise-on-delay violations using the following techniques: wire spacing, net ordering, layer selection, minimization of long parallel wires, and shielding. Performing Incremental Crosstalk Analysis and Repair Incremental crosstalk analysis and repair performs an incremental noise analysis and repair on your design. The incremental mode only runs on touched nets that need analysis and repair. Incremental analysis and repair is an iterative process. It continues to analyze and repair crosstalk until there are no glitch violations remaining, and negative slack with coupling delay equals negative slack without coupling delay. Note: In order to view the noise nets after incremental crosstalk analysis and repair, you must first rerun the runCeltic command to update the CeltIC .eco and .txt files. Incremental crosstalk analysis and repair includes the following tasks: 1. Performing noise analysis using the integrated version of CeltIC (native). 2. Performing timing analysis using timing window files (TWFs). 3. Repairing noise-on-delay violations. 4. Repairing glitch violations. May 2005 631 Product Version 4.1.5 Encounter User Guide Analyzing and Repairing Crosstalk 5. Performing signal integrity-aware ECO routing using the integrated version of NanoRoute (native). You can modify the steps in this flow by setting the appropriate parameters in the setSIMode command and running the fixCrosstalk command. ➤ To perform incremental analysis and repair on your design, use the Fix Crosstalk form, or issue the following command: fixCrosstalk -incremental Performing Sign-Off Crosstalk Analysis and Repair Sign-off crosstalk analysis and repair performs a complete sign-off quality analysis and repair of the entire design. Sign-off analysis and repair is an iterative process. It continues to analyze and repair crosstalk until there are no glitch violations remaining, and negative slack with coupling delay equals negative slack without coupling delay. Sign-off crosstalk analysis and repair includes the following tasks: 1. Performing noise analysis by calling the standalone version of CeltIC. 2. Performing timing analysis using the integrated CeltIC timing analyzer. 3. Repairing noise-on-delay violations. 4. Repairing glitch violations using. 5. Performing signal integrity-aware ECO routing by calling the standalone version of NanoRoute. 6. Extracting the RC parasitic data by calling Fire & Ice extraction. The previous tasks identify the tools you can use for optimal sign-off quality results. You are not limited to using only these tools when performing the sign-off closure flow. Note: You can modify the steps in this flow using the appropriate parameters in the setSIMode command and running the fixCrosstalk command. ➤ To perform a complete sign-off analysis and repair on your design, use the Fix Crosstalk form, or issue the following command: fixCrosstalk -signOff May 2005 632 Product Version 4.1.5 Encounter User Guide 24 Power Analysis This chapter describes how to use the Encounter power analysis software to analyze the power usage, power grid IR drop, and power grid electromigration (EM) of a design. This chapter presents the following topics: ■ Overview on page 635 ■ Before You Begin on page 636 ■ Results on page 638 ■ Displaying Macro Current Source Locations on page 639 ■ Running Power Analysis with Encounter on page 639 ■ Running Power Analysis in Simple Estimate Mode on page 641 ■ Running Power Analysis with VoltageStorm on page 643 ■ Creating a Power Pad Location File on page 644 ■ Using Auto Fetch on page 646 ■ Simple Decoupling Capacitor Modeling on page 647 ■ Viewing the Power Graph on page 647 ■ Viewing Power Analysis Results with Debussy Waveform on page 648 ■ Saving Rail Analysis Values on page 649 ■ Power/Rail Summary Report on page 649 ■ Power Graph Report on page 650 ■ Instance Average Power Report on page 651 ■ Net Average Power Report on page 651 ■ Instance Power Data File on page 652 May 2005 633 Product Version 4.1.5 Encounter User Guide Power Analysis ■ Instance Voltage File on page 652 ■ Boundary Voltage File on page 653 ■ Display Setting File on page 654 ■ Calculating EM Values for Wires and Vias on page 655 ■ Log of Physical Connectivity to Power Grid on page 655 ■ Operating Voltage Recognition on page 656 ■ Removing Power Consumption for Specified Pins or Ports on page 656 May 2005 634 Product Version 4.1.5 Encounter User Guide Power Analysis Overview The Encounter™ power analysis software enables you to ■ Create reports and waveforms that tell you the average power consumption of the design. ■ Create displays that show either the average or the peak IR drop on the power nets, and report the instance voltages due to IR drop. ■ Create displays that show areas in which average power consumption could cause EM violations. Additionally, an interface to the VoltageStorm® PE power integrity verification solution enables you to perform sign-off power grid analysis and display those results in Encounter. To use this interface, you must have VoltageStorm software and a license to run it. Important If you have used previous versions of the Encounter power analysis software, results from the current version might look different than you expect. In versions prior to 2.3, the software reported peak IR drop and EM values. In version 2.3 and later, the software always reports average EM values. By default, the software also reports average IR drop values, but you can specify that peak IR drop values be reported instead. Power Analysis Modes Power analysis can be run in two types of floorplanning modes and three types of power analysis modes, for a total of six mode combinations. The two floorplanning modes are floorplan and layout. ■ Floorplan Mode Use this mode to run power analysis in the early floorplanning stages, after power rings and stripes are created, but before power rails and follow pins are connected. This mode allows early feedback on power consumption, IR drop, and EM violations while the floorplan is being developed. ■ Layout Mode Use this mode to run power analysis on a complete or near complete floorplan. The chip’s power structure must be complete, power rails must be in place, and power pins must connect to the power structures. These power pins must exist in the LEF file for all May 2005 635 Product Version 4.1.5 Encounter User Guide Power Analysis cell types used in the design. Cells that are not connected to the power structure are not included in the analysis. The two power analysis modes are statistical and simulation-based. In addition, you can run a separate rail analysis. ■ Statistical Mode Use this mode for performing power analysis early in the design flow. This mode has dummy clock, pre-CTS, and post-CTS clock options. ❑ In the dummy clock option, only a specified percent (probability) of all nets toggle at a specified clock rate. ❑ In the pre-CTS or post-CTS option, the design is divided into the clock domains, and each clock domain’s clock rate and net toggling probability can be specified. For more information, see Power Analysis: Statistical Mode in the Encounter Menu Reference. ■ Simulation-Based Mode Use this mode for performing power analysis at later stages in the design flow. This mode requires a Verilog® value change dump (VCD) input file. For more information, see Power Analysis: Simulation-Based in the Encounter Menu Reference. ■ Rail Analysis: Average Mode Use this mode for performing rail analysis that examines the IR drop or EM violations of existing power structures. For more information, see See Rail Analysis: Average Mode in the Encounter Menu Reference. Before You Begin Before you can perform power analysis, you must prepare your design by completing a series of tasks. For information about these tasks, see “Setting Up Power Analysis” on page 637. You must also have the following input files: ■ Design file ■ Power pad location files May 2005 636 Product Version 4.1.5 Encounter User Guide Power Analysis ■ Instance power data file (optional) ■ Verilog VCD file (for simulation-based power analysis) ■ Cell libraries containing power grid views (for VoltageStorm) Setting Up Power Analysis To set up the design for Power Analysis, complete the following steps: 1. Import the design. For more information, see “Importing and Exporting Designs” on page 77. 2. (Optional) Issue the globalNetConnect command. This command is required when power and ground nets in the SPECIALNETS section of the DEF file do not contain the complete connectivity information. For more information, see globalNetConnect in the Encounter Text Command Reference or Global Net Connections in the Encounter Menu Reference. 3. Load or design a floorplan. For more information, see “Floorplanning the Design” on page 215. 4. Create the main power structures (rings and stripes). For more information, see “Power Planning and Routing” on page 255. 5. Connect the power structures to all the I/O pad instances and blocks. For more information, see “Power Planning and Routing” on page 255. Note: You can also load the power and ground stripes from a back-end tool in DEF or TDF format, using defIn or tdfIn commands. 6. Run Amoeba placement. For more information, see “Placing the Design” on page 285. 7. Run Trial Route. 8. Run Extract RC. May 2005 637 Product Version 4.1.5 Encounter User Guide Power Analysis Results The results of power analysis depend on the tools used to perform the analysis. ■ Running power analysis in statistical mode produces the following: ❑ A power graph ❑ A report that contains the average power usage, worst IR drop, and worst EM violation ❑ An instance power file ❑ An instance voltage file ❑ A boundary voltage file (produced when you issue the savePartition command for hierarchical designs) Note: The Encounter log file contains a set of messages that indicates how many instances had physical connectivity to the power grid. For more information, see “Log of Physical Connectivity to Power Grid” on page 655. ■ ■ Running power analysis in simulation-based mode produces the following: ❑ A power graph ❑ A report that contains the average power usage, worst IR drop, and worst EM violation ❑ An instance power file ❑ An instance voltage file ❑ A boundary voltage file (produced when you issue the savePartition command for hierarchical designs) Running rail analysis produces the following: ❑ A power graph ❑ A report that contains the amount of power used for rail analysis, worst IR drop, and worst EM violation ❑ An instance voltage file ❑ An instance power file May 2005 638 Product Version 4.1.5 Encounter User Guide Power Analysis Displaying Macro Current Source Locations Use the Display Macros I Source Location form to display the macro current source location for blocks. (The I in the title of this form stands for current.) The power pins of a block are both the power source for the block’s contents, and the sinks for the power grid external to the macro. The white circles in the design display area represent the current source locations for the macro. ■ For floorplan mode, the current source locations for blocks are distributed along the grid the block is in. For each area of the block (that is, an area bounded by power stripes or the block macro boundary), four current source locations are displayed, one each for the top, bottom, left, and right side of the area. Adjacent areas can share a source location. The following diagram shows an example of how the software can set up current source locations. 1 Block Macro 4 2 Power Stripes Current Source Locations 3 M5 M6 ■ For layout mode, the displayed macro current source locations are at the power pins, and a current source is displayed for each power pin connection to the block. Running Power Analysis with Encounter To run power analysis, complete the following steps: 1. Make sure the timing library is complete with power attributes. The timing library file(s) should contain the cell_leakage_power library attribute for .lib or CELL_SPOWER for TLF for all cells. This cell attribute represents the static power May 2005 639 Product Version 4.1.5 Encounter User Guide Power Analysis usage when a gate is not switching. If this attribute is missing, then no static power usage is reported for average power. Another cell library attribute is internal_power for .lib, or INTERNAL_ENERGY or SC_ENERGY for TLF. This attribute represents the cell’s internal power usage due to switching and instantaneous short circuit current between power and ground when the internal cell switches state. If this attribute is missing, then no internal power usage is reported for average power. Each power or ground net should use cells that have the same nominal voltage defined in the library. If timing libraries do not have nominal voltages defined, the default bias voltage, which is 3.3 V, is used. If a cell does not have a power model in the timing library, the power analysis software assumes 3.3 V as its operating voltage. Note: The operating voltage is calculated using the voltage value of the majority of the cells. Since filler cells do not have timing or power models, the power analysis software excludes filler cells when calculating the operating voltage. Filler cells are not reported as unclocked instances and are not included in the Instance Voltage file. If the power or ground net under analysis uses instances that have different nominal voltage values, the power analysis software determines which voltage is used by the greatest number of instances and uses that voltage value for all instances. Note: A warning message is displayed if nominal voltages are not defined or if multiple nominal voltages are defined for a single net, as shown in the following example: **WARN: **WARN: **WARN: **WARN: Net vdd has 200112 instances at 3.3V, 9 instances at 1.62V. Using 3.3V for all instances. Libraries without nominal voltages defined are defaulted to 3.3V. Please ensure that all libraries have nominal voltages defined. 2. Create the power and ground rings for the I/O power pads to connect power to the I/O instances, and create power and ground rings for all the blocks. 3. (Optional) Load the power and ground structures from back end design tools in DEF or TDF formats. Use the defIn or tdfIn command to load the power and ground data. Note: For floorplan mode, standard cells do not need to be connected to power and ground. When power analysis runs, it will automatically add the power or ground routes for the standard cells. You can view this by clicking All Colors on the main Encounter window and selecting Power Graph from the Color Preference form. You must zoom in to see the graph. 4. Create a pad location file for each net to be analyzed, to indicate voltage source reference points. May 2005 640 Product Version 4.1.5 Encounter User Guide Power Analysis Each power and ground net must have at least one pad location. For example, if the design has three power nets (such as VCC, VDD, VSS), then at least three pad locations are needed for running power analysis, one on each voltage source. These locations are usually at the I/O power pads, but you can change the locations to investigate better power pad locations. For more information, see Edit Pad Location in the Encounter Menu Reference. 5. After all the I/O pad instances and all the blocks are connected to power and ground, run Place, Trial Route, and Extract RC. Note: Alternatively, if you have a SPEF file, you can use the spefIn command to read RC data from the SPEF file. For floorplan mode, it is not necessary to connect the I/O pad instances to power. 6. Run power analysis in statistical mode or simulation-based mode. For more information, see Power Analysis: Statistical and Power Analysis: SimulationBased in the “Power Menu” chapter of the Encounter Menu Reference. Tip If you make any changes to the design after running power analysis, rerun it to create a new IR drop graph, EM violation display, and power report. Depending on your change, you may need to rerun Place, Trial Route, or Extract RC before you rerun the power analysis. Running Power Analysis in Simple Estimate Mode To perform a simple estimate of power consumption using multiplier values instead of a power library, complete the following steps. 1. Create a file that contains the following keywords, along with values for each keyword: ❑ clock_rate value value is in MHz, default is 100 ❑ toggle_probability value default is 0.2 ❑ Estimate_switching_power {use_extracted_cap | value} value is in pf ❑ May 2005 Estimate_leakage_power 641 Product Version 4.1.5 Encounter User Guide Power Analysis This optional keyword does not use a value ❑ Estimate_internal_power slew load_cap slew is in ns and load_cap is in pf) ❑ Clock_driver cell_name power_in_Watts number_of_flops This keyword can be used in pre-CTS mode, where no clock tree is present, to compute clock tree power and distribute the power to flip-flops ❑ cell_internal_energy_and_leakage_power_file filename This optional keyword specifies a file that contains the cellname, internal energy in picojoules, and leakage power in Watts ❑ create_cell_internal_energy_and_leakage_power_file filename This optional keyword specifies that the power analysis software create a cell_internal_energy_and_leakage_power_file 2. Issue the updatePower command with the -estimate parameter, as shown in the following example: updatePower -estimate estimationfile.txt -pad design.vdd.pp VDD Alternatively, issue the updatePower command with the -estimate parameter and the -toggleFile parameter to trace clock domains, as shown in the following example: updatePower -estimate estimationfile2.txt -toggleFile togglefile.tg -pad design.vdd.pp VDD Estimation Parameter File The following example shows the contents of a file named estimationfile.txt: clock_rate 200 toggle_probability 0.3 Estimate_switching_power use_extracted_cap Estimate_leakage_power Estimate_internal_power 0.120 0.1 The following example shows the contents of a file named estimationfile2.txt, which contains the Clock_driver keyword: clock_rate 200 toggle_probability 0.3 Estimate_switching_power use_extracted_cap Estimate_leakage_power Estimate_internal_power 0.120 0.1 Clock_driver CLOCK_BUF 0.0001 2 May 2005 642 Product Version 4.1.5 Encounter User Guide Power Analysis Running Power Analysis with VoltageStorm If you have VoltageStorm software and a license to run it, you can run VoltageStorm using Encounter menus and commands. For detailed information about using VoltageStorm, see the VoltageStorm Hierarchical PGS Manual. VoltageStorm Power Grid Analysis Flow VoltageStorm enables a high capacity hierarchical sign-off power grid analysis flow based on power grid views. It helps you verify that the power grid network on your chip does not suffer from IR drop, ground bounce, or electromigration problems. The following recommended sequence uses both Encounter and VoltageStorm software: 1. Use Encounter to perform a flat power grid analysis and create boundary voltages for specified partitions on a design with partitions specified but not committed. 2. Use Encounter power analysis for each partition to create an instance power file. 3. Execute VoltageStorm for each partition using the boundary voltages generated in the previous step and the instance power file. 4. Use VoltageStorm to create a detailed power grid view of the partition for use at the top level. 5. Use Encounter at the top level of the partitioned design to create the instance power file and include partition power using the instance power data file. 6. Execute VoltageStorm at the top level using power grid views of all partitions. This sequence ensures: ■ Accurate block-level power analysis using boundary voltages. ■ Accurate block modeling with a detailed power grid view. ■ Accurate top level hierarchical analysis using block power grid views. The detailed power grid view and block-level power consumption combine to provide detailed grid analysis profiles without loading the block’s netlist. Running VoltageStorm To use VoltageStorm, complete the following steps: May 2005 643 Product Version 4.1.5 Encounter User Guide Power Analysis 1. Prepare data for power analysis. See “Setting Up Power Analysis” on page 637 for more information. 2. Run power analysis in either statistical or simulation-based mode to generate an instance power file. See Power Analysis: Statistical and Power Analysis: Simulation-Based in the Encounter Menu Reference for more information. 3. Choose Power – Run VoltageStorm. This opens the VoltageStorm Analysis form. For more information, see VoltageStorm Analysis in the Encounter Menu Reference. 4. Specify the following required values on the VoltageStorm Analysis form: ❑ Net name. ❑ Library List (see Library Generation - Basic in the Encounter Menu Reference). ❑ Instance power file (this was generated during power analysis). ❑ Pad location file (this was generated before running power analysis). 5. Set additional options on the VoltageStorm Analysis form. 6. Click OK or Apply. If VoltageStorm runs without errors, you will see a message stating that VoltageStorm is exiting normally. 7. Choose Power – Display Rail Analysis Results. This opens the Display Rail Analysis Results form. For more information, see Display Rail Analysis Results in the Encounter Menu Reference. Creating a Power Pad Location File The location of voltage sources is the starting point for the rail analysis. The power analysis software obtains voltage source locations for a particular net, such as VCC, VDD, and VSS, from that net’s power pad location file. You must mark points on the power structures as voltage source reference points, then store that information in the power pad location file. identify the voltage source reference points Power pad location files are used during all stages of power analysis. To create a new power pad location file, complete the following steps: May 2005 644 Product Version 4.1.5 Encounter User Guide Power Analysis 1. Choose Power – Edit Pad Location. This automatically changes the Encounter display to the Physical view and opens the Edit Pad Location form. 2. Specify the power net or ground net name in the Net field. You can only edit the pad location file for one net at a time. 3. Click Auto Fetch. This automatically populates the Pad Location List with the pad locations based on properties defined in the LEF file. For information about setting up a LEF file for use with Auto Fetch, see “Using Auto Fetch” on page 646. Note: You may need to reissue the globalNetConnect command for Auto Fetch to function properly if the power pads were not defined in the data base at the time that the globalNetConnect command was first issued. 4. Click Save. This opens the Save Pad Location File form. 5. Specify a location for the pad location file, then click OK. This saves the pad location file, clears the Pad Location List, and closes the Save Pad Location form. Pad location displays are updated immediately after clicking Auto Fetch, Delete, or Add. The IR drops leading from the pad locations are displayed after running power analysis. You can also use the Display Pad Location form to display the pad locations in the design display area. The pad locations are displayed as yellow circles for each x and y coordinate, marking the voltage source reference points for running power analysis. If a boundary voltage value exists for the location, it is shown as a solid yellow circle. A voltage value equal to the nominal voltage is treated as if there were no boundary voltage value, and is represented by a hollow yellow circle. The IR drop at pad locations is 0. Note: The yellow circles display only in the Physical view. Use the Clear button on the Edit Pad Location form after you save the pad location file before you use Auto Fetch again. To clear the Pad Location List, click Clear. Once the Pad Location List is cleared, you can begin creating a pad location file for a new net. May 2005 645 Product Version 4.1.5 Encounter User Guide Power Analysis Using Auto Fetch To use Auto Fetch, the following conditions must be met: ■ The LEF macro for power pads must contain the CLASS PAD POWER statement. ■ Block power and ground pins must have DEF attributes +USE POWER or +USE GROUND. In addition, if a pad contains multiple pins associated with different power and ground nets, Specify CLASS CORE for the port of the pin that belongs to the net that uses the pad as a DC source. If none of the ports is CLASS CORE, then Auto Fetch includes that pad as a DC source for multiple nets. ■ If the power or ground pad is routed, the power analysis software assumes a DC source on every layer that connects to the routed port. ■ If the power or ground pin is not routed, the power analysis software assumes a DC source only on the closest power or ground wire. The following example shows the portion of a LEF file with a pad that contains pins for VDD and VSS. MACRO VVDD CLASS PAD POWER PIN VDD USE POWER PORT CLASS CORE ... END VDD PIN VSS USE GROUND PORT ... END VSS ... In this example, since PIN VDD has CLASS CORE specified, Auto Fetch only uses VDD as a DC source. If CLASS CORE was not specified, both VDD and VSS pins would be used as DC sources. Note: Use a different .pp file for each net. May 2005 646 Product Version 4.1.5 Encounter User Guide Power Analysis Simple Decoupling Capacitor Modeling You can use the power analysis software to model cells with negative current separately for power and ground pins. Specify a negative value for power in the instance power file for decoupling cells in order to see the effect in the rail analysis. Power analysis does not automatically identify the decoupling cells. The following example shows how to specify an instance power data file with the decoupling capacitor cells: DECAP_1 -0.001 DECAP_2 -0.001 Both DECAP_1 and DECAP_2 are modelled to similarly supply 1 mA current for a 1 V system. Viewing the Power Graph The power analysis software creates a power graph that is a representation of the power and ground net structure used by power analysis to construct the resistor network to perform IR drop and EM analysis. To view the power graphs, complete the following steps: 1. Use the Display Rail Analysis Results form to select the type of results to be displayed. 2. Click the Physical View icon to the left of the design display area. 3. Open the Color Preferences form by clicking the All Colors button above the Colors Tool area. 4. Click the V (Visibility) and S (Selectability) button for Power Graph. 5. (Optional) To get a better view, deselect Net, SNet, and Obstruct. This helps clear the design display area. 6. Zoom in to the area of interest. To see a power graph report after you run a power analysis or rail analysis, complete the following steps: 1. Use the Display Rail Analysis Results form to select the type of results to be displayed. 2. Click the Physical View icon to the left of the design display area. 3. Open the Color Preferences form by clicking the All Colors button above the Colors Tool area. May 2005 647 Product Version 4.1.5 Encounter User Guide Power Analysis 4. Click the V (Visibility) and S (Selectability) button for Power Graph. 5. (Optional) To get a better view, deselect Net, SNet, and Obstruct. This helps clear the design display area. 6. Select one or more power rails within the design display area. You can select multiple rails by holding the Shift key while clicking each rail. 7. Press the Q key. The Attribute Editor for object type Power Graph displays. In addition, a report appears in the Encounter console. The format of the report is shown in the following example: probing node 550 on net "VDD": location: ( 1196.6300 436.2400 ) um layer: M1 Bounding Box: ( 1170.8400 435.6100 ) ( 1222.4200 436.8700 ) um V: 1596.740801 mV instance I: 0.000000e+00 mA DC source I: 0.000000e+00 mA East neighbour: node: 37 location: ( 1226.4200 436.2400 ) um layer: M1 width: 1.2600 um V: 1596.897615 mV I: -6.566913e-02 mA R: 2.387929e+00 ohm West neighbour: node: 549 location: ( 1166.7150 436.2400 ) um layer: M1 width: 1.2600 um V: 1596.583330 mV I: 6.566913e-02 mA R: 2.397948e+00 ohm Viewing Power Analysis Results with Debussy Waveform You can use the Debussy Waveform (nWave) tool and the FSDB file generated during simulation-based power analysis to view the power consumption profile. May 2005 648 Product Version 4.1.5 Encounter User Guide Power Analysis To load the waveform file, use the Load Power Waveform File form. Saving Rail Analysis Values To save EM, IR Drop, and Instance Voltage Drop values for any net that has been analyzed, use the Save Rail Analysis Results form. Power/Rail Summary Report The power analysis software generates a power/rail summary that report average power by the cell category, the worst average IR drop, and the number of voltage nodes (matrix size) in the rail resistor network. This is an indirect performance indicator. An example of the report, for power analysis using a dummy clock, is shown below. ############################################## # The Power Analysis Report for VDD net # ############################################## power supply: 1.8 v average power(default): 1.3013e+01 mw average switching power(default): 7.7149e-01 mw average internal power(default): 8.5106e+00 mw average leakage power(default): 5.0067e-05 mw average user specified power(default): 3.7308e+00 mw average power by clock domain category: clock domain(dummy, 0.2) : 1.3013e+01 mw unclock domain: 0.0000e+00 mw average power by cell category: core: 9.3131e-01 mw block: 1.2082e+01 mw io: 5.0000e-09 mw average power(considered in rail analysis): 1.3013e+01 mw worst IR drop average analysis: 3.0327e-03 v number of nodes in rail network: 9784 nodes worst EM: "M1" 9.0839e-02 mA/u "M2" 2.4120e-03 mA/u "M3" 2.7492e-02 mA/u "M4" 6.5211e-02 mA/u "M5" 2.1230e-01 mA/u "M6" 1.7649e-01 mA/u "V12" 1.7505e-02 mA/cut "V23" 1.7505e-02 mA/cut "V34" 1.7505e-02 mA/cut "V45" 1.7055e-02 mA/cut "V56" 1.3955e-02 mA/cut biggest toggled net: DTMF_INST/m_clk no. of terminal: 40 total cap: 7.4697e+02 ff May 2005 649 Product Version 4.1.5 Encounter User Guide Power Analysis Power Graph Report The Power Graph Report provides detailed information for each net rectangle on the power graph. The following example report shows excerpts from a report that is generated when you issue the updatePower command with the -reportRailAnalysis parameter for net VDD: # HEADER: NET_NAME : VDD LENGTH_UNIT : um CURRENT_UNIT : mA RESISTANCE_UNIT : ohm WIRE_EM_UNIT : mA/um VIA_EM_UNIT : mA/cut VOLT_UNIT : mV NET_BIAS_VOLTAGE : 3299.999952 MAX_VDROP_CG : 0.018798 IR_ANALYSIS_MODE : AVERAGE # POWER GRAPH: # nodeId : ( llx lly ) ( urx ury ) nodeId1 nodeId2 nodeId3 ... # where nodeId(n) are neigbhouring nodes of nodeId # and nodId == 0 represent DC reference nodes 0 : ( 37.1400 -8.7400 ) ( 38.4800 -3.7400 ) 18 1 : ( -22.1800 -20.6400 ) ( -18.1800 -16.6400 ) 2 # WIRE VOLTAGE CURRENT: # nodeId1 nodeId2 R layerName Width V1 V2 I 1 2 0.274275 M1 4.0000 3.299994 3.299994 1.025500e-03 2 3 0.274275 M1 4.0000 3.299994 3.299995 1.025500e-03 # VIA VOLTAGE CURRENT: # nodeIdTop nodeIdBottom R viaName NumCuts V1 V2 I 14 1 0.10625 VIAGEN12_7 16 3.299994 3.299994 1.025500e-03 15 3 0.10625 VIAGEN12_7 16 3.299995 3.299995 1.025500e-03 # WIRE EM: # nodeId : V EM [Emlimit|NONE] [EM_VIOLATION] 1 : 2.5637e-04 3.299994 2 : 2.5637e-04 3.299994 # VIA EM: # nodeId : V EM [Emlimit|NONE] [EM_VIOLATION] 14 : 6.4094e-05 3.299994 15 : 6.4094e-05 3.299995 # INSTANCE: May 2005 650 Product Version 4.1.5 Encounter User Guide Power Analysis # InstName ((x1 y1) (x2 y2)) vddCurrent worstVoltage # ( pinName ( pinNodeId pinCurrent pinVoltage ) ...) com2 ( -7.2800 -4.1600 ) ( -2.0800 6.2400 ) 7.4844e-06 3.299981 ( VDD ( 10 7.4844e-06 3.299981 ) ) Instance Average Power Report The Instance Average Power Report provides detailed power information for a particular cell, as well as for the net. The following example report shows the power consumption of cell inst_1 as well as the total power consumption for the net vdd!. ################################################## # The Instance Average Power Report for VDD net # ################################################## # Power calculation mode: statistic simulation # Operating bias voltage: 1.62 Volt # Units for power: Watts # Format: Instance Total-Power Internal-Power Switching-Power Leakage-Power ########################################################################### DTMF_INST/i_10048 5.224669e-06 -3.604321e-03 3.609545e-03 5.764000e-10 DTMF_INST/PLLCLK_INST 7.178137e-06 -5.017416e-03 5.024594e-03 1.458000e-10 .########################################################################### # Sum: 7.353887e-02 3.889689e-04 7.314740e-02 2.499547e-06 # No. of instances: 5942 ########################################################################### Net Average Power Report The Net Average Power Report provides detailed power information for a particular net. The following example report shows the power consumption of net CLK. ############################## # # The Net Average Power Report # # Operating Voltage = 2.5 Volt ############################################################################## # Net Load Toggle Switching # Cap (pF) Rate (per sec) Power (Watt) May 2005 651 Product Version 4.1.5 Encounter User Guide Power Analysis ############################################################################# CLK 7.709138e+00 4.942857e+07 1.190787e-03 .. ################################################################################ # Total nets = 11 # Total Capacitance = 23.5889 pF # Total Switching Power = 0.0037382 Watts ################################################################################ Instance Power Data File The instance power data file is an ASCII file containing the instance power values for a design. Each line in the file contains a single instance name followed by the instance power value (in watts). This file is created during power analysis, and can also be used as input for subsequent power analysis runs and by the VoltageStorm software. The following example shows the format of this file: # InstanceName PowerInWatt # ---------------------------------DTMF_INST/ROM_INST 0.005 DTMF_INST/RESULTS_INST 0.01 The InstanceName column contains the instance name. The PowerInWatt column contains the instance power number, which overwrites or fills in the missing power number in the design that is being analyzed for power consumption. Specifying the block power consumption in this file eliminates the need to edit a .lib file to provide such information. The total current consumption is equally distributed to all power pins. Instance Voltage File The instance voltage file is an ASCII file that can be used by any delay calculator to perform instance voltage based calculations. Using this file facilitates IR Drop aware timing. The following example shows the format of this file for power nets: VERSION CREATION CREATOR PROGRAM May 2005 "1.0" ; "Mon Oct 28 11:49:28 2002" ; "CADENCE" ; "First Encounter" ; 652 Product Version 4.1.5 Encounter User Guide Power Analysis DIVIDERCHAR DESIGN UNITS "/" ; "dtmf_chip" ; VOLTAGE VOLT 1 ; INSTANCESUPPLY 5905 VDD 1.8 POWER ; - DTMF_INST/i_10048 1.799744 CLKBUFXL ; - DTMF_INST/RAM_128x16_TEST_INST/i_10074 1.799683 CLKBUFX3 ; - DTMF_INST/RAM_128x16_TEST_INST/i_14 1.799760 MX2X1 ; - DTMF_INST/RAM_128x16_TEST_INST/i_13 1.799692 MX2X1 ; ... The following example shows the format of this file for ground nets: VERSION CREATION CREATOR PROGRAM DIVIDERCHAR DESIGN UNITS "1.0" ; "Mon Oct 28 11:50:02 2002" ; "CADENCE" ; "First Encounter" ; "/" ; "dtmf_chip" ; VOLTAGE VOLT 1 ; INSTANCESUPPLY 5832 VSS 0 GROUND ; - DTMF_INST/i_10048 0.000294 CLKBUFXL ; - DTMF_INST/RAM_128x16_TEST_INST/i_14 0.000158 MX2X1 ; - DTMF_INST/RAM_128x16_TEST_INST/i_3 0.000327 MX2X1 ; - DTMF_INST/RAM_128x16_TEST_INST/i_0 0.000333 MX2X1 ; ... Each line in this file contains the following values: instance_name voltage master_cell_name. Note: A negative voltage value in this file indicates a supply current. For more information, see “Simple Decoupling Capacitor Modeling” on page 647. Boundary Voltage File The boundary voltage file is created by the power analysis software when you issue the savePartition command for hierarchical designs. The format of this file is: May 2005 653 Product Version 4.1.5 Encounter User Guide Power Analysis x y layerName [pad_instance_name | voltage] where x y are the coordinates for the DC source location. layername is the name of the layer that contains the DC source. Note: Only a generic layer name, such as M1 or M2 should be used. pad_instance_name is the name of the power pad. voltage is a real number that indicates the voltage value of the DC source at that location. Note: You can specify either pad_instance_name or voltage, but do not specify both. If a voltage value is not specified, the ideal voltage value is used. Display Setting File The Display Setting file saves the filter-related settings specified on the VoltageStorm Results Display form. By default, this file has a .dsf file extension. The Display Setting file has the following syntax: ir|tc|rc|rj|er|vc|vv|iv {v1 min1 max1} {v2 min2 max2} {v3 min3 max3} {v4 min4 max4} {v5 min5 max5} {v6 min6 max6} {v7 min7 max7} {v8 min8 max8} Note: The triplets in this file use the same syntax as the displayVStormResults -filter command. The following example shows a .dsf file that displays IR drop values from 1.79914 to 1.8: ir {1 1.79989 1.8} {1 1.79978 1.79989} {1 1.79968 1.79978} {1 1.79957 1.79968} {1 0 1.79957} {1 1.79936 1.79946} {1 1.79925 1.79936} {1 1.79914 1.79925} When you save the filter range information, if any required value is not specified, it is saved as 0. When you load the .dsf file, if any required value is not specified, all subsequent values are ignored. Note: This feature is only available from the Display VoltageStorm Settings form and does not have an equivalent text command option. May 2005 654 Product Version 4.1.5 Encounter User Guide Power Analysis Calculating EM Values for Wires and Vias The following diagram shows an example of a wire and via configuration. M1 Current = 6 mA Number of cuts = 9 Width = 3 µm M2 M1 ■ The EM value for a wire is calculated as the current in the segment divided by the width of the segment. For example, if the current in M1 is 6 mA and the width is 3 µm, then the calculated EM is 2.0 mA/µm. The segments will display in red if you specify a limit of 1. 647 mA/µm. ■ The EM value for a via is calculated as the current in the via connecting two layers divided by the number of cuts. For example, if the current in V12 is 6 mA and there are nine cuts, then the EM is calculated as 0.67 mA/cut. The vias will not display in red if you specify a limit of 1.647 mA/cut. Log of Physical Connectivity to Power Grid The Encounter log file contains a set of messages that indicates how many instances had physical connectivity to the power grid. In addition, the log contains messages that indicate why a particular instance is not connected. ■ A message that an instance is not geometrically connected to a net indicates that the pin connection to the net may be missing for that instance. ■ A message that an instance is not reachable by a DC source on a net indicates that the instance is connected to a power or ground wire, but that wire may not be connected to a portion of the grid that is attached to a DC source. May 2005 655 Product Version 4.1.5 Encounter User Guide Power Analysis Operating Voltage Recognition If timing libraries do not have nominal voltages defined, a default voltage of 3.3 V is used. If multiple voltages are used within the design, the power analysis software determines which voltage is used by the greatest number of instances, then uses that voltage value for all instances. Removing Power Consumption for Specified Pins or Ports Sometimes the power analysis software provides a result that is too pessimistic because power consumption is calculated for test nets that contain pins or ports that will not be consuming power in the actual design. To obtain a more accurate result, you can specify to the power analysis software that these pins or ports do not consume power. To perform power analysis with the removal of power consumption considerations for specified pins or ports, complete the following steps: 1. Set up a .sdc file that contains the following statement: set_case_analysis 0 listOfPinOrPortNames 2. Import the .sdc file into the design. 3. Run power analysis in statistical mode. The results will not including power consumption for any pins or ports that you specified in the set_case_analysis statement. May 2005 656 Product Version 4.1.5 Encounter User Guide 25 Verifying Violations This chapter describes how to verify the violations in your design. The chapter presents the following topics: ■ Verifying Connectivity on page 658 ■ Verifying Metal Density on page 659 ■ Verifying Geometry on page 661 ■ Verifying Process Antenna on page 662 ■ Verifying AC Limit on page 665 ■ Viewing Violations on page 667 ■ Clearing Violation on page 669 ■ Loading Violation Report on page 669 May 2005 657 Product Version 4.1.5 Encounter User Guide Verifying Violations Verifying Connectivity You can verify the connectivity of your design to detect and report various conditions, such as open nets, antennas, loops, and partial routing for all nets or specified nets in your design. You can use the command to create violation markers in the design window and generate a violation report. There is no database impact unless you choose to save the design, which saves the violation markers. For regular wires, the Encounter software checks the connectivity using the center line of the wire segments and center of the vias. For special wires, the command checks the whole geometry. If a via or wire is slightly offset from where it should be, the software reports an error. The software also detects connectivity loops based on the end points of a regular wire segment center line or the center of a via. It reports geometry loop violations. Before You Begin Before you verify connectivity, the following conditions must be met: ■ The design must be routed. ■ The design must be loaded into the current Encounter session. Results After verifying connectivity, you can use information in the violation report to repair connectivity violations. You can use the Viewing Violations command for interactive viewing and highlighting of violation markers. Related Text Command The following text command provides equivalent or additional functionality: ■ verifyConnectivity May 2005 658 Product Version 4.1.5 Encounter User Guide Verifying Violations Verifying Metal Density The Encounter software allows you to check whether the metal density for each routing layer is within the minimum and maximum density values specified in the LEF file or by the setMetalFill command. Before You Begin Before you verify metal density, the following conditions must be met: ■ Metal density values must be specified in the LEF file or by the setMetalFill command. ■ The design must be detail routed. ■ The design must be loaded into the current Encounter session. Metal Density Statements in the LEF File The following statements in the Layer (Routing) section of the LEF file define the minimum and maximum metal density and how to analyze the density. ■ MINIMUMDENSITY ■ MAXIMUMDENSITY ■ DENSITYCHECKWINDOW ■ DENSITYCHECKSTEP ■ FILLACTIVESPACING For more information, see the LEF/DEF Language Reference. Results The verification process generates a report file containing information about the metal density that is not within the minimum and maximum density range. Related Text Command The following text command provides equivalent or additional functionality: May 2005 659 Product Version 4.1.5 Encounter User Guide Verifying Violations ■ verifyMetalDensity May 2005 660 Product Version 4.1.5 Encounter User Guide Verifying Violations Verifying Geometry The Encounter software allows you to verify the physical layout of your design, such as widths, spacing, and internal geometry of objects. You can specify the checks that you want to perform on the design, disable checking and reporting of selected design rule violations, and set limits for errors and warnings to report. You can disable checks when phantom violations arise because of discrepancies in the way mask-level data is presented. For example, cell internal obstructions and pins might be represented in a way that causes the verifier to report design rule violations that do not exist in the mask-level layout. You can verifying geometry at the following stages in the flow: ■ After placing the design. ■ After adding power stripes and rings and running power routing. ■ After running detailed routing. Before You Begin Before you verify geometry, the design must meet the following conditions: ■ The following LEF statements must be specified: ❑ CLEARANCEMEASURE ❑ USEMINSPACING statements for obstructions and pins For more information, see the LEF/DEF Language Reference. ■ The design must be routed. Results Verifying geometry creates markers corresponding to geometry violations in the database. Related Text Commands The following text command provides equivalent or additional functionality: ■ verifyGeometry May 2005 661 Product Version 4.1.5 Encounter User Guide Verifying Violations Verifying Process Antenna The process antenna verification command in Encounter checks for routing that violates the maximum charge caused by the process antenna effect (PAE) on the pins and reports violations on pins that have a process antenna ratio larger than the maximum allowed ratio specified for the routing layer. This feature fully supports the 0.09 µm process antenna rules for major foundries. It handles PAE violations on any metal layer. The PAE calculations use a geometry-based approach and do not double count metal areas for vias or wires. It provides a detailed process antenna report including the metal area, diffusion area, and target ratio for each pin. It also performs PAE checks on hierarchical designs. The report file lists all the violated nets and includes process antenna information. Optionally, it can also report all other nets. For more information on PAE, see Appendix D, “Calculating and Fixing Process Antenna Violations,” in the LEF/DEF Language Reference. Before You Begin Before performing process antenna verification, complete the following tasks: ■ Perform signal routing. ■ Ensure the antenna keywords are specified in the LEF file; for example, ❑ ANTENNAAREARATIO for LEF layers ❑ ANTENNAGATEAREA and ANTENNADIFFAREA for macro pins Results After verifying process antenna violations, you can use information in the violation report to repair process antenna violations. You can use the Verify – Violation Browser command for interactive viewing and highlighting of violation markers. Related Text Commands The following text command provides equivalent or additional functionality: ■ verifyProcessAntenna May 2005 662 Product Version 4.1.5 Encounter User Guide Verifying Violations Sample Process Antenna Report The following example shows a detailed process antenna report file: D1 (2) U0 (BUF) A [1] [1] [1] MET: THO: Area: 1.10 S.Area: 2.10 G.Area: 100.00 D.Area: Fact: 0.90 PAR: 0.01 Ratio: 0.10 (Area) Fact: 1.00 PAR: 0.02 Ratio: 0.10 (S.Area) CAR: 0.01 Ratio: 0.00 (C.Area) CAR: 0.02 Ratio: 0.00 (C.S.Area) Area: 0.20 S.Area: 0.00 G.Area: 100.00 D.Area: Fact: 1.00 PAR: 0.00 Ratio: 0.00 (Area) CAR: 0.00 Ratio: 0.00 (C.Area) S.Area: 51.20 G.Area: 100.00 D.Area: Fact: 1.10 PAR: 0.15 Ratio: 2.50 (Area) Fact: 0.90 PAR: 0.46 Ratio: 0.00 (S.Area) CAR: 0.16 Ratio: 0.00 (C.Area) CAR: 0.48 Ratio: 0.00 (C.S.Area) WMET: Area: 13.27 0.00 0.00 300.00 The report uses the following terms: Area: Metal area S.Area: Metal side area G.Area: Gate area D.Area: Diffusion area Fact: Metal (side) area adjusted factor PAR: Partial antenna ratio CAR: Cumulated antenna ratio Ratio: Target antenna ratio (Area) Metal area (S.Area) Metal side area May 2005 663 Product Version 4.1.5 Encounter User Guide Verifying Violations (C.Area) Cumulated metal area (C.S.Area) Cumulated metal side area May 2005 664 Product Version 4.1.5 Encounter User Guide Verifying Violations Verifying AC Limit The Encounter software allows you to check for AC current violations on signal nets. The software calculates the root mean square current (Irms) at the driver output. The software then compares the value of Irms with the ACCURRENTDENSITY tables in the LEF file that contains the root mean square limit values for routing layers. If the calculated Irms for a net exceeds the ACCURRENTDENSITY limit for any of the routing layers or widths used by the net, the software generates an error and attaches a violation marker to the net. The software checks each routing segment separately. The Encounter software calculates the current for every wire segment in the net, therefore eliminating the false violations that might be caused by assuming the same current. This feature is useful for calculating current at the inputs where the current is not as strong due to branching and tapering of wires. The software checks the ACCURRENTDENSITY tables for the following conditions: ■ If there is no table for a routing layer, the verifyACLimit command gives a warning and assumes infinite limit for the layer. ■ If the RMS table is present for a cut-layer, the verifyACLimit command gives a warning and ignores the table. ■ If PEAK and AVERAGE tables are present, the software ignores them. Note: While ACCURRENTDENSITY in the LEF file is in mA/micron, the verifyACLimit command reports it in mA. The verifyACLimit command reads the value in mA/micron based on the wire width, and then multiplies this value by the wire width to get the limit shown in the report. Before You Begin Before verifying AC limit, complete the following tasks: ■ Perform RC extraction. ■ Perform timing analysis. Results After verifying AC limit violations, you can use information in the violation report to repair AC current limit violations. Use the fixACLimitViolation command to repair the violations. You can use the Verify – Violation Browser command for interactive viewing and highlighting of violation markers generated after you use this command. May 2005 665 Product Version 4.1.5 Encounter User Guide Verifying Violations Related Text Commands The following text command provides equivalent or additional functionality: ■ verifyACLimit May 2005 666 Product Version 4.1.5 Encounter User Guide Verifying Violations Viewing Violations The Verification menu’s Violation Browser form allows you to interactively view and highlight violation markers generated after you use one or more verification commands. Before You Begin ■ Place and route the design. ■ Use one or more verification commands. Violation Browser Features ■ The form displays the number of violations. A description of the violation is displayed when you click on a violation in the violation list. The description also contains actual and target values for AC limit violations, process antenna violations, and geometry spacing violations. An actual value is the current value, and a target value is the value defined in the LEF file. The violation list is displayed in the display window. ❑ Click the + or - sign to collapse or expand the listings of each violation type. ❑ Use the First, Previous, Next, Last, Up, and Down buttons to navigate through the list of violations. The browser displays the violations in the following hierarchical order: + tool + type + subtype Description where the tool, type, and subtype value correspond to the value you specify using the createMarker command. Their default value is Other. ■ Use cross probing between the design display area in the Encounter software and the Violation Browser form. To display the details of a violation in the Violation Browser form, double-click the violation marker in the design display area. If there are violation markers for overlapped objects, select the top most marker in the design display area and press the space bar on your keyboard to navigate through the other markers. The type and name of the selected violation is displayed in the lower left corner of the Encounter window. Use the q key to select a violation and highlight it in the Violation Browser form. May 2005 667 Product Version 4.1.5 Encounter User Guide Verifying Violations ■ Use the Zoom buttons to change the display for a violation. ■ Select a violation from the list and use any of the following buttons: ❑ Highlight Color ❑ Highlight Violations ❑ De-Highlight Violations ❑ Delete Violations ❑ Mark Violations as False ❑ Mark Violations as True ■ Generate a report file. The report file is a text file containing all the violation information. Click the Save button to generate the report file. ■ Limit the number of violation to display using the Show Types panel in the Settings page of the form. ■ Limit the area to display using the Show Area panel in the Settings page of the form. ■ Filter the violations to display using the Other Filters panel in the Settings page of the form. Related Text Commands The following text commands provide equivalent or additional functionality: ■ violationBrowser ■ violationBrowserReport May 2005 668 Product Version 4.1.5 Encounter User Guide Verifying Violations Clearing Violation Use the Verify – Clear Violation menu command to clear all the violation markers in your design. Note: There is no GUI form for this command. Loading Violation Report You can load an Assura or Calibre violation marker file to view the violations in the Violation Browser. Use the Verify – Load Violation Report form to load the report file. Results After loading the violation report, you can view Assura or Calibre violations. Use the Verify – Violation Browser command for interactive viewing and highlighting of the violation markers. Related Text Command The following text command provides equivalent or additional functionality: ■ loadViolationReport May 2005 669 Product Version 4.1.5 Encounter User Guide Verifying Violations May 2005 670 Product Version 4.1.5 Encounter User Guide A Creating the ICT File The first step involved in modeling the parasitic interconnect capacitance and resistance of your design is to specify the fabrication process information in an ICT file by using the syntax defined in this section. You can use any text editor to enter this information. Note: Although there are no file-naming restrictions for ICT files, you should name your ICT by using the process name with the .ict file extension, as follows: process_name.ict (ICT file) Fabrication process information consists of the following: ■ The minimum spacing and minimum width of the conductors as specified in the design rules for the conductor layers ■ The thicknesses of the conductor layers ■ The heights of the conductor layers above the substrate (measuring height from the field) or as a delta from a previously defined lower-level conductor layer ■ The resistivities of the conductor layers ■ The interlayer planar dielectric constant, its height above the substrate (measuring height above the field), and its thickness ■ The names of the top conductor layer of a via, the bottom conductor or diffusion layer of the via, and the contact resistance of the via ■ The names of the wells The rest of this section describes the syntax and format of the ICT file containing the process information for your design. For more information on generating the ICT files and using the icecaps command, see the Fire & Ice QX Gate-Level Extraction manual. May 2005 671 Product Version 4.1.5 Encounter User Guide Creating the ICT File Format Lines in the ICT file are in the following general format: command name {argument_list} where argument_list is a list of field-value pairs. The fields in this syntax are separated by white space. ViewICT, IceCaps, and RCgen ignore blank lines. Note: A backslash (\) is generally required for line continuation, but it is not required if you are using braces ({}) to define a list. Data All data entered into the ICT file should be the actual physical fabrication process information, not the drawn data. Comments A pound-sign character (#) at the beginning of a line indicates text that ViewICT, IceCaps, and RCgen treat as comments. Case Sensitivity All keywords in the ICT file are case-insensitive. However, the arguments are case-sensitive. Keywords consist of all command and field names. Warnings and Errors The ViewICT utility displays all errors, warnings, and informational messages onscreen and writes them in a log file. Warnings and errors include the corresponding line number. Invalid Layer Names The “NX” string is an invalid layer name. Commands This section describes the commands available in the ICT file. May 2005 672 Product Version 4.1.5 Encounter User Guide Creating the ICT File All command fields are enclosed in braces ({}). Process The process command specifies the background dielectric constant. Use it only once in the ICT file. Syntax process name {background_dielectric_constant value} or process name { background_dielectric_constant value } This syntax contains the following parameters: ■ name Specifies the name of the process. ■ background_dielectric_constant value Specifies the dielectric constant for the region above the top passivation layer or last dielectric layer. This field is required. Example process “Process_Example” { background_dielectric_constant 1.0 } Well The well command defines the well layers. It is an optional command that you can use to differentiate capacitance to a well from capacitance to the substrate. Syntax well name { } May 2005 673 Product Version 4.1.5 Encounter User Guide Creating the ICT File Name specifies the name of the well layer. Anything placed in the brackets is ignored. Example well nwell { } well pwell { } Conductor The conductor command defines conductor layers. You can specify the height of a conductor layer in three ways: ■ Height (absolute) ■ Delta height (relative) ■ Upto (maximum top down) You can use more than one of these methods per conductor definition as long as the numbers are valid. All measurements are in microns unless otherwise specified. Syntax conductor name {field1 value1 ... fieldN valueN} or conductor name { field1 value1 ... fieldN valueN } You can specify the field-value pairs in any order. This syntax contains the following parameters: ■ name Specifies the name of the conductor layer. May 2005 674 Product Version 4.1.5 Encounter User Guide Creating the ICT File ■ min_spacing value Specifies the minimum spacing permitted by the technology between two conductors (wires) on a layer. ■ min_width value Specifies the minimum width of a conductor. ■ height value Specifies the layer’s height above the substrate. ■ delta_height value Specifies the layer’s height relative to the top of another layer. This parameter must be used with delta_layer. ■ delta_layer layer_name Specifies the reference layer for delta_height. It must be a layer that has already been defined. The reference layer must be a conducting layer, a dielectric layer, or a passivation layer. This parameter must be used with delta_height. ■ thickness value Specifies the layer’s thickness. ■ upto value Specifies the layer’s top surface height above the substrate. This value is equal to the height plus the thickness. You only need to specify two of the three or four parameters (height, {delta_height, delta_layer}, thickness, upto) to complete the geometrical definition of a conductor layer. ■ resistivity value|[value width]+ Specifies the layer’s sheet resistivity, in ohms per square. You can enter the resistivity value as a constant, or you can enter value-width pairs as a piecewise linear function. You may want to use the value-width pairs to account for width-dependent resistivity. If you enter value-width pairs, the syntax is as follows: resistivity value1 width1 value2 width2 ... valuen widthn If the width of the wire is less than the minimum width, width1, use the minimum value, value1. If the width of the wire is greater than the maximum width, widthn, use the maximum value, valuen. For widths between value-width pairs, Fire & Ice QX, IceCaps, and RCgen determine the resistivity value through linear interpolation. ■ gate_forming_layer [true|false] May 2005 675 Product Version 4.1.5 Encounter User Guide Creating the ICT File Specifies that this layer forms the gate. The polycide or polysilicon layer is a typical gateforming conducting layer. ■ field_poly_diffusion_spacing value Specifies the lateral spacing between field polycide and diffusion for transistor-level parasitic extraction. There is no lateral separation between gate polycide and diffusion. ■ PnR_widths [value]+, PnR_spacings [value]+ Allows you to provide design widths and spacings used in the layout to the technology file generation program. These are not necessary for accurate extraction of parasitics if the design widths and spacings are within small perturbations of the minimum process widths and spacings. However, if the design widths and spacings are routinely different from the specified process parameters, it is recommended that you provide these values to the technology file generator. ■ capacitor_only_layer_to layer_name Specifies that the current layer be used solely to create high capacitance values in the design and that it is located a few angstroms above or below the layer_name layer. Layers having the capacitor_only_layer_to keyword set are not extracted. ■ wire_top_enlargement E top Specifies the enlargement, either positive or negative, of the top edge of the wire. See Figure A-2 on page 678. ■ wire_bottom_enlargement E bottom Specifies the enlargement, either positive or negative, of the bottom edge of the wire. See Figure A-2 on page 678. The required fields in this syntax are min_spacing, min_width, resistivity, gate_forming_layer, min_net_fill_spacing, X_fill_fill_spacing, Y_fill_fill_spacing, unit_fill_region, and two of the following three parameters: ■ height (or delta_height and delta_layer) ■ thickness ■ upto Figure A-1 on page 677 illustrates these parameters. May 2005 676 Product Version 4.1.5 Encounter User Guide Creating the ICT File Figure A-1 Geometric Fields in a Conducting Layer M1 M1 POLYCIDE Thickness of M1 Height of M1 “Upto” of M1 Substrate Wire-Width Values You can use the wire_edge_enlargement statement with the wire_top_enlargement statement or the wire_bottom_enlargement statement, or both in the ICT file. If you use the wire_edge_enlargement statement with either or both of these statements, the width of the wires defined by wee_widths must be biased as follows: drawn_width + ((top + bottom) / 2) When calculating resistivity as a function of width, you must use the wire_top_enlargement and wire_bottom_enlargement values to correct the resistance-width pairs. If a table of wire-edge enlargement values is available, Fire & Ice QX uses the wire widths in the table, which always include biasing and wire-edge enlargement. If this table is not available, Fire & Ice QX calculates the resistance as follows: rho* L / (drawn_width + (top + bottom) / 2 + (top + bottom) / 2) where rho is the sheet resistivity. Fire & Ice QX uses wire-width values in the following order: 1. Drawn width 2. Biased width 3. Edge-enlarged width 4. Resistivity as a function of width May 2005 677 Product Version 4.1.5 Encounter User Guide Creating the ICT File Figure A-2 on page 678 illustrates the defining of the conductor layer. Figure A-2 Example Conductor Definition 0.3 µm ... M1 0.25 0.16 0.35 0.20 8.6 true 0.25 µm 0.16 µm 0.25 µm 0.3 µm 0.2 µm POLYCIDE 0.30 0.30 0.85 0.25 8.0 false ... conductor “POLYCIDE” { min_spacing min_width height thickness resistivity gate_forming_layer } conductor “M1” { min_spacing min_width height thickness resistivity gate_forming_layer } 0.85 µm 0.35 µm Substrate Example conductor “POLYCIDE” { min_spacing 0.25 min_width 0.16 height 0.35 upto 0.55 resistivity 8.6 gate_forming_layer true } conductor “M1” { min_spacing 0.30 min_width 0.30 delta_layer POLYCIDE delta_height 0.30 thickness 0.25 resistivity 8.0 gate_forming_layer false wire_top_enlargement 0.01 wire_bottom_enlargement -0.01 wire_edge_enlargement { wee_widths 0.18 0.00 0.26 May 2005 0.30 678 0.34 Product Version 4.1.5 Encounter User Guide Creating the ICT File wee_spacings 0.18 wee_adjustments 0.00 0.00 0.10 0.10 0.20 0.30 0.00 0.00 0.00 0.00 0.10 0.20 0.20 0.26 -0.10 0.00 0.00 0.00 0.10 0.20 0.30 -0.10 -0.10 0.00 0.00 0.00 0.10 0.34 -0.20 -0.20 -0.10 0.00 0.00 0.00 0.38 } } Dielectric The dielectric command defines dielectric layers. All measurements are in microns unless otherwise specified. Syntax dielectric name {conformal value field1 value1 ... fieldN valueN} or dielectric name { conformal value field1 value1 ... fieldN valueN } You can specify the field-value pairs in any order. The syntax for planar dielectrics contains the following parameters: ■ name Specifies the name of the dielectric layer. ■ conformal false Specifies that the dielectric is planar. This field is required. ■ height value Specifies the layer’s height above the substrate. May 2005 679 Product Version 4.1.5 Encounter User Guide Creating the ICT File ■ thickness value Specifies the layer’s thickness. ■ dielectric_constant value Specifies the dielectric constant for this material. ■ delta_height value Specifies the layer’s height relative to the top of another layer. ■ delta_layer layer_name Specifies the reference layer for delta_height. It must be a layer that has already been defined. A reference layer can be a conducting layer or a dielectric layer. ■ upto value Specifies the layer’s top surface height above the substrate. This value is equal to the height plus the thickness. You only need to specify two of the three parameters (height (or {delta_height, delta_layer}), thickness, upto) to complete the geometrical definition of a dielectric layer. The required fields in the specification for planar dielectrics are conformal, dielectric_constant, and two of the following three parameters: ■ height (or {delta_height and delta_layer}) ■ thickness ■ upto Figure A-3 on page 681 illustrates the planar dielectric syntax. May 2005 680 Product Version 4.1.5 Encounter User Guide Creating the ICT File Figure A-3 Planar Dielectric Syntax ... M1 diel_M1_L 0.30 µm 0.10 µm height (1.00 µm) ... dielectric “diel_M1_L” { conformal FALSE height 1.00 thickness 0.10 dielectric_constant 7.00 } dielectric “diel_M1_H” { conformal FALSE height 1.10 thickness 0.30 dielectric_constant 4.00 } diel_M1_H Substrate ... Passivation The passivation command defines passivation layers. The passivation layers are usually placed on top of the last metal layer and should be placed higher than the dielectric layers. Syntax The syntax of this command is the same as that of the dielectric command, except that name specifies the name of the passivation layer. See “Dielectric” on page 679 for information on this syntax. The passivation layers are usually placed on top of the last metal layer and should be placed higher than the dielectric layers. Figure A-4 on page 681 illustrates the defining of the passivation layer. Figure A-4 Passivation Syntax ... topThickness (0.2 µm) passivation “NonuniformConformalPass1” { conformal TRUE expandedFrom METAL_6 height 7.70 thickness 0.30 topThickness 0.20 sideExpand 0.20 dielectric_constant 5.70 } sideExpand (0.20 µm) Metal_6 Height (0.77 µm) ... May 2005 0.3 µm Substrate 681 Product Version 4.1.5 Encounter User Guide Creating the ICT File Example passivation “NonuniformConformalPass1” { conformal TRUE expandedFrom METAL_6 height 7.70 thickness 0.30 topThickness 0.20 sideExpand 0.20 dielectric_constant 5.70 } Via The via command defines vias or contacts. Syntax via name {top_layer value bottom_layer value contact_resistance value} This syntax contains the following parameters: ■ top_layer value Specifies the name of the top conductor. ■ bottom_layer value Specifies the name of the bottom conductor or diffusion layer. ■ contact_resistance value Specifies the contact resistance of the via, in ohms. Example via “V A1” { top_layer METAL_2 bottom_layer METAL_1 contact_resistance 7.9 } May 2005 682 Product Version 4.1.5 Encounter User Guide Creating the ICT File Following is a sample specification of a local interconnect via layer. The name of the conductor and the name of the via are the same. conductor “LI” { min_spacing min_width height thickness resistivity gate_forming_layer } 0.3 0.35 0.55 0.60 0.40 FALSE via “LI” { top_layer LI bottom_layer POLYCIDE contact_resistance 2.000 } Note: Local interconnect is a layer, usually thicker than the polysilicon layer, that can be deposited after polysilicon and can connect to source-drain regions on the polysilicon layer. Sample ICT File Following is a sample ICT file. # # # Copyright (c) 2003 Cadence Design Systems, Inc. ######################################################################### # Process declaration. ######################################################################### process “DIFFERENT_KINDS_OF_DIELECTRIC” { background_dielectric_constant 1.0 } ######################################################################### # Well declarations. ######################################################################### well nwell {} May 2005 683 Product Version 4.1.5 Encounter User Guide Creating the ICT File well pwell {} ######################################################################### # Diffusion declarations. ######################################################################### diffusion “N_SOURCE_DRAIN” { # Tox is (height of POLYCIDE thickness resistivity } diffusion “P_SOURCE_DRAIN” { thickness resistivity } thickness of diffusion) = (0.35 - 0.3455) = 0.0045um 0.3455 7.7 0.3455 8.3 ######################################################################### # Conducting layer declarations. ######################################################################### conductor “POLYCIDE” { min_spacing min_width height thickness resistivity gate_forming_layer } conductor “METAL_1” { min_spacing min_width height thickness resistivity gate_forming_layer } conductor “METAL_2” { min_spacing min_width height thickness May 2005 0.25 0.16 0.35 0.20 8.6 true 0.23 0.23 1.05 0.53 0.086 false 0.28 0.28 2.38 0.53 684 Product Version 4.1.5 Encounter User Guide Creating the ICT File resistivity 0.086 # The key words TRUE and FALSE are not case sensitive. gate_forming_layer FALSE } conductor “METAL_3” { min_spacing 0.28 min_width 0.28 height 3.71 thickness 0.53 resistivity 0.086 gate_forming_layer false } conductor “METAL_4” { min_spacing 0.28 min_width 0.28 # delta_height + delta_layer is an alternative to height. delta_height 0.80 delta_layer METAL_3 # “height” is then redundant but it’s okay to specify. # height 5.04 thickness 0.53 resistivity 0.086 gate_forming_layer false } conductor “METAL_5” { min_spacing 0.28 min_width 0.28 height 6.37 thickness 0.53 resistivity 0.086 gate_forming_layer false } conductor “METAL_6” { min_spacing 0.46 min_width 0.44 height 7.70 thickness 0.99 resistivity 0.035 gate_forming_layer false } May 2005 685 Product Version 4.1.5 Encounter User Guide Creating the ICT File ######################################################################### # Dielectric and passivation layer declarations. ######################################################################### ######################################################################### # Base dielectric from substrate... ######################################################################### dielectric “First_dielectric” # Starts at height zero. conformal height thickness dielectric_constant } { FALSE 0.00 0.35 3.90 # Simple planar dielectric starts at the bottom of POLYCIDE # and ends at 1.08um which is 0.03um above the bottom of M1. dielectric “SimplePlanar1” { # Starts at height of Poly conformal height thickness dielectric_constant } FALSE 0.35 0.73 4.00 ######################################################################### # M1 level... ######################################################################### # Now a planar intra-metal (M1) dielectric starts 0.03um above from the # bottom of M1. dielectric “PlanarIntraMetal1” { conformal FALSE # # Starts at height of M1 height 1.08 # Laterally intersect with M1 thickness 0.03 May 2005 686 Product Version 4.1.5 Encounter User Guide Creating the ICT File dielectric_constant 7.00 } # The second intra-metal dielectric across M1 # and on top of “PlanarIntraMetal1”. dielectric “PlanarIntraMetal2” { # Yet another intra-metal planar dielectric layer. conformal FALSE height 1.11 upto 1.15 # OR # thickness 0.04 dielectric_constant 3.00 } # # # # # # # # # # # # # # A conformal dielectric. When specifying a conformal dielectric (whether it is uniform or non-uniform, we must use “conformal TRUE”, “expandedFrom”, “sideExpand”, and “topThickness” together. 1. “conformal” must be set to TRUE. 2. “expandedFrom” can be a metal layer or a dielectric/passivation layer. The conformal dielectric layer must be expanded from its immediate lower (metal/dielectric/passivation) layer. It cannot be expanded from a planar dielectric layer. 3. “thickness” is the bottom dielectric thickness. 4. “sideExpand” specifies the side thickness. 5. “topThickness” is the thickness of the dielectric above the top of the “expandedFrom” layer. dielectric “conformalAtTopOFM1” { # Conformal above M1 conformal TRUE expandedFrom METAL_1 # and starts from the top of “PlanarIntraMetal2” height 1.15 # Base/Bottom thickness of the conformal dielectric. thickness 0.43 May 2005 687 Product Version 4.1.5 Encounter User Guide Creating the ICT File # The thickness of the dielectric above the “expandedFrom” object, i.e. M1. topThickness 0.43 # This is the side thickness of the dielectric. sideExpand 0.43 dielectric_constant 4.10 } dielectric “SimplePlanar2” { # From top of M1 to bottom of conformal height thickness dielectric_constant } M2 FALSE 1.58 0.80 4.00 ######################################################################### # M2 level... ######################################################################### # An uniform conformal dielectric starting from the bottom of M2. dielectric “UniformConformal1” { conformal TRUE expandedFrom METAL_2 # Height of M2 delta_height 0.00 delta_layer SimplePlanar2 # height 2.38 thickness 0.50 topThickness 0.50 sideExpand 0.50 dielectric_constant 3.00 } # A nonuniform conformal dielectric is one when any one of “thickness”, # “sideExpand”, and “topThickness” are different. dielectric “NonuniformConformal1” { conformal TRUE May 2005 688 Product Version 4.1.5 Encounter User Guide Creating the ICT File height thickness expandedFrom sideExpand topThickness dielectric_constant 2.88 0.10 UniformConformal1 0.03 0.05 7.00 } dielectric “SimplePlanar3” { conformal height thickness dielectric_constant } FALSE 2.98 0.73 4.10 ######################################################################### # M3 level... ######################################################################### # A special case of conformal dielectric. dielectric “NonuniformConformal2” { # Humps over M3 with side and top thicknesses equal to 0.17 um and 0.50 um, respectively. conformal TRUE expandedFrom METAL_3 height 3.71 # Note that the bottom thickness is thicker than M3! thickness 0.90 topThickness 0.50 sideExpand 0.17 dielectric_constant 4.10 } dielectric “SimplePlanar5” { conformal height # Upto the bottom of M4. upto dielectric_constant } May 2005 FALSE 4.61 5.04 3.00 689 Product Version 4.1.5 Encounter User Guide Creating the ICT File ######################################################################### # M4 level... ######################################################################### dielectric “NonuniformConformal3” { conformal TRUE expandedFrom METAL_4 # Height of M4 height 5.04 thickness 0.30 topThickness 0.30 sideExpand 0.10 # Special case. See SimplePlanar6. dielectric_constant 4.10 } dielectric “PlanarIntraMetal3” { # Planar intrametal dielectric. conformal FALSE height 5.34 upto 5.44 dielectric_constant 3.10 } dielectric “PlanarIntraMetal4” { # Top off the top of NonuniformConformal3. height 5.44 upto 5.87 dielectric_constant 3.00 } dielectric “SimplePlanar6” { conformal FALSE height 5.87 # Upto the bottom of M5. upto 6.37 # NOTE that it has the same dielectric constant as NonuniformConformal3. # This makes “NonuniformConformal3” a special case. dielectric_constant 4.10 } ######################################################################### # M5 level... May 2005 690 Product Version 4.1.5 Encounter User Guide Creating the ICT File ######################################################################### dielectric “UniformConformal3” { conformal TRUE expandedFrom METAL_5 height 6.37 thickness 0.10 topThickness 0.10 sideExpand 0.10 dielectric_constant 7.20 } dielectric “PlanarIntraMetal5” { # Special planar dielectric which intersects “UniformConformal3” conformal FALSE height 6.47 thickness 0.40 dielectric_constant 3.00 } dielectric “PlanarIntraMetal6” { # Another special planar dielectric which intersects “UniformConformal3” conformal FALSE height 6.87 thickness 0.10 dielectric_constant 4.00 } dielectric “PlanarIntraMetal7” { # Yet another special planar dielectric which intersects “UniformConformal3” conformal FALSE height 6.97 thickness 0.03 dielectric_constant 7.00 } ######################################################################### passivation “PlanarPass1” { # From top of M5 to bottom of conformal height thickness dielectric_constant May 2005 M6. FALSE 7.00 0.70 4.00 691 Product Version 4.1.5 Encounter User Guide Creating the ICT File } ######################################################################### # M6 level... ######################################################################### passivation “NonuniformConformalPass1” { conformal TRUE expandedFrom METAL_6 height 7.70 thickness 0.30 topThickness 0.20 sideExpand 0.20 dielectric_constant 5.70 } passivation “PlanarPass2” { conformal FALSE height 8.00 upto 8.89 dielectric_constant 4.30 } ######################################################################### passivation “PlanarPass3” { conformal height thickness dielectric_constant } FALSE 8.89 1.00 3.00 ######################################################################### # Contacts and Via declarations. ######################################################################### via “CONT” { top_layer METAL_1 bottom_layer POLYCIDE contact_resistance 7.8 } via “CONT” { top_layer METAL_1 May 2005 692 Product Version 4.1.5 Encounter User Guide Creating the ICT File bottom_layer N_SOURCE_DRAIN contact_resistance 11 } via “CONT” { top_layer METAL_1 bottom_layer P_SOURCE_DRAIN contact_resistance 10 } via “VA1” { top_layer METAL_2 bottom_layer METAL_1 contact_resistance 7.9 } via “VA2” { top_layer METAL_3 bottom_layer METAL_2 contact_resistance 8.2 } via “VA3” { top_layer METAL_4 bottom_layer METAL_3 contact_resistance 8.1 } via “VA4” { top_layer METAL_5 bottom_layer METAL_4 contact_resistance 8.0 } via “VA5” { top_layer METAL_6 bottom_layer METAL_5 contact_resistance 4.0 } May 2005 693 Product Version 4.1.5 Encounter User Guide Creating the ICT File May 2005 694 Product Version 4.1.5 Encounter User Guide B ECO Flows This appendix summarizes the variety of Engineering Change Order (ECO) flows possible with Encounter, and outlines the current approach for each flow. ■ Overview on page 696 ■ Pre-Mask ECO Changes from an ECO File on page 698 ■ Pre-Mask ECO Changes from a New Verilog File on page 702 ■ Pre-Mask ECO Changes from a New DEF File on page 705 ■ Pre-Mask ECO Changes from New OpenAccess Data on page 709 ■ Post-Mask ECO Changes from a New Verilog Netlist on page 713 ■ Post-Mask Gate Array Style ECO from a New Verilog Netlist on page 718 May 2005 695 Product Version 4.1.5 Encounter User Guide ECO Flows Overview Many types of ECO flows are possible. The ones outlined in this appendix cover the most common cases. You can use these flows directly, or you can modify them for your design. For an example ECO file, see the “ECO Directives” chapter in the Encounter Text Command Reference. Assumptions The ECO flows in this appendix assume the following: ■ The old Verilog netlist and the new Verilog netlist have already been uniquified such that no Verilog module is instantiated more than once. ■ Your design uses an existing floorplan. ■ Your old placement, special routing, and routing information is saved in one of the Encounter formats, DEF, and so forth. Flows This appendix describes various types of ECO flows: ■ Pre-Mask ECO Changes from an ECO File on page 698 Allows you to use an ECO file to make changes to the netlist. ■ Pre-Mask ECO Changes from a New Verilog File on page 702 If you make changes to the netlist, this is the recommended flow to use to load the new netlist and restore all the physical data from the previously saved design. ■ Pre-Mask ECO Changes from a New DEF File on page 705 Allows you to make external changes that include new cell placements from a DEF file, while preserving your previous placement, optimization, and optionally, previous routing information; for example, a clock tree with placements and specialized buffer insertion with placements. ■ Pre-Mask ECO Changes from New OpenAccess Data on page 709 Allows you to make external changes that include new cell placements from an OpenAccess database, while preserving your previous placement, optimization, and May 2005 696 Product Version 4.1.5 Encounter User Guide ECO Flows optionally, previous routing information; for example, a clock tree with placements and specialized buffer insertion with placements. ■ Post-Mask ECO Changes from a New Verilog Netlist on page 713 ❑ ■ Allows you to make late logic changes after the masks are made. This flow uses preexisting spare cells, so no poly/diffusion changes are allowed, and only the routing is modified. You can direct the software to make routing changes only on specific layers. Post-Mask Gate Array Style ECO from a New Verilog Netlist on page 718 ❑ May 2005 Allows you to make late logic changes after the masks are made. This flow uses preexisting gate array style filler cells to create new cells. No poly/diffusion changes are allowed, and only the routing is modified. 697 Product Version 4.1.5 Encounter User Guide ECO Flows Pre-Mask ECO Changes from an ECO File In this flow, your design is placed and possibly routed, and you want to make a small number of changes using an ECO file methodology. The changes are done before the masks are made so it is a pre-mask ECO flow, and there is no need to keep the original poly/diffusion patterns. For example, you might want to apply a small number of late logical changes, but you want to keep as much of the previous placement, optimization, clock tree, and routing to avoid disturbing previous timing/SI optimization and repair. Preparation Before starting the flow steps, you should have the following files available: ■ oldchip.enc oldchip.enc.dat/ Create these files by using the saveDesign command after the previous placement, optimization, and routing steps. or ■ oldchip.conf oldchip.v oldchip.def Create the first three files by using the saveConfig, saveNetlist, and defOut commands after the previous placement, optimization and routing steps. The new Verilog file (newchip.v) is typically created by manually editing the old Verilog netlist. Note: If you want to preserve routing, your existing design must contain the antenna diode cells that were added during the previous routing. or ■ oldchip.eco This file contains the list of changes to be applied to the old netlist. The changes required (see the loadECO command syntax) are typically created manually. You might be able to create an ECO file more easily by using ADDINST and DELETEINST rather than creating a new Verilog file. May 2005 698 Product Version 4.1.5 Encounter User Guide ECO Flows Flow ■ Read the old netlist ■ Compare netlists ■ Load the ECO file ■ Write the new netlist (optional) ■ Remove filler cells ■ Perform incremental placement ■ Add filler cells ■ Perform incremental or final routing ■ Trim metal fill Steps 1. Read the old Verilog netlist, floorplan, and placement information into Encounter. restoreDesign oldchip.enc or loadConfig oldchip.conf defIn oldchip.def This step reads in the following information: ❑ Old libraries and global power connections ❑ Old timing constraints or new constraints, if necessary ❑ Special routing, placement, and optionally, old routing information ❑ Old filler cells, end caps, well taps, and other cell information 2. Load the ECO file to incrementally update the current netlist to match the new netlist. loadECO oldchip.eco During this step, ❑ Instances and nets that are only in the old Verilog are deleted (for example, an old clock tree). Some Verilog ports may now be unconnected due to deleted nets. ❑ New instances are still unplaced. May 2005 699 Product Version 4.1.5 Encounter User Guide ECO Flows ❑ New ports and nets are created in Verilog modules as needed to connect instances in different Verilog modules. ❑ If any nets are deleted, the routing attached to the net is also deleted. ❑ If any nets are modified, the routing on those nets is left unchanged for later repair. ❑ Global power connections are done automatically based on the rules from the configuration file or floorplan file loaded earlier. 3. (Optional) Write out new Verilog netlist. saveNetlist oldchip_after_eco.v The oldchip_after_eco.v and newchip.v netlists should be identical, with one exception: the newly-created Verilog module ports and nets might have different names because they are automatically generated whenever a new connection is made between separate Verilog modules. 4. Remove filler cells or notch fill (if present). deleteFiller -prefix FILL deleteNotchFill 5. Perform incremental placement. ecoPlace Unplaced instances are placed; however, previously placed cells are not moved and routing is unaffected. Note: You can manually preplace critical cells before using the ecoPlace command by placing the cell in the bottom, left corner, selecting it, and then moving it graphically. For example: placeInstance i1/i2/i3 0 0 selectInst i1/i2/i3 6. Add filler cells back into the rows. addFiller -cell FILL4 -prefix FILL -fillBoundary addFiller -cell FILL2 -prefix FILL -fillBoundary addFiller -cell FILL1 -prefix FILL -fillBoundary Global power connections are done automatically based on rules loaded from the configuration or floorplan file earlier. 7. Incremental or final route. setNanoRouteMode routeWithEco true globalDetailRoute May 2005 # set for incremental routing 700 Product Version 4.1.5 Encounter User Guide ECO Flows NanoRoute automatically detects opens and shorts, and incrementally routes any nets that are incomplete or have violations. 8. (Optional) Add notches. fillNotch 9. (Optional) If the original design contained metal fill, trim the metal fill: trimMetalFill Cadence recommends that you use this command to trim metal fill during the ECO process instead of deleting and adding the metal fill again. 10. Continue with the normal post-routing flow (analysis, repair, add metal fill, notch fill, verify, sign-off, and so forth). May 2005 701 Product Version 4.1.5 Encounter User Guide ECO Flows Pre-Mask ECO Changes from a New Verilog File In this flow, your design is placed and possibly routed, and you want to make a few changes. The changes are done before the masks are made, so it is a pre-mask ECO flow and there is no need to keep the original poly/diffusion patterns. Preparation Before starting the flow steps, you should have the following files available: ■ oldchip.conf Create this file by using the saveConfig command, which creates data for libraries, timing constraints, global power connections, and so on. ■ oldchip.fp oldchip.fp.spr Create these files (floorplan, special routing, placement, and routing) by using the saveFPlan command. or ■ oldchip.def Create this file (DEF formats for floorplan, placement, special routing, optionally routing) by using the defOut command. ■ newchip.v The new Verilog file is typically created by manually editing the old Verilog netlist. Note: If you want to preserve routing, your existing design must contain the antenna diode cells that were added during the previous routing. Flow 1. Read the new netlist 2. Load old floorplan/placement/routing data 3. Remove filler cells and notches (optional) 4. Perform incremental placement May 2005 702 Product Version 4.1.5 Encounter User Guide ECO Flows 5. Add filler cells (optional) 6. Perform incremental or final route 7. Add notches 8. Trim metal fill Steps 1. Read the new netlist. loadConfig newchip.conf # same as oldchip.conf except use newchip.v or loadConfig oldchip.conf 0 set rda_Input(ui_netlist) “newchip.v” commitConfig The netlist Includes old libraries, global power connections, and so forth. It typically uses old timing constraints, however new timing constraints can be used. 2. Read the old floorplan, special routes, placements and routing from the old netlist files. loadFPlan oldchip.fp ecoDefIn -reportFile ecoDefIn.rpt oldchip.def applyGlobalNets During this step, ❑ Matching instances receive old placements. ❑ Instances existing only in the oldchip.def file are ignored, so they are not added to the current netlist. ❑ Changed instances (new cell) are assigned a new cell and are left unplaced. ❑ Physical-only cells in the old netlist (marked with +SOURCE DIST in the DEF) get added (for example, well taps, end caps, and filler cells). ❑ Instances that are only in the new netlist are left unplaced. ❑ Routing for existing or modified nets is restored (possibly with opens or shorts). ❑ Routing for deleted nets is removed. 3. Remove filler cells or notch fill (if present). deleteFiller -prefix FILL deleteNotchFill May 2005 703 Product Version 4.1.5 Encounter User Guide ECO Flows 4. Do incremental placement. ecoPlace Unplaced instances are placed, previously placed cells are not moved, and routing is unaffected. You can manually preplace critical cells before using the ecoPlace command by placing the cell in the bottom, left corner, selecting it, and then moving it graphically. placeInstance i1/i2/i3 0 0 selectInst i1/i2/i3 5. Add filler cells back into the rows. addFiller -cell FILL4 -prefix FILL -fillBoundary addFiller -cell FILL2 -prefix FILL -fillBoundary addFiller -cell FILL1 -prefix FILL -fillBoundary Global power connections are performed automatically based on rules loaded from the configuration or floorplan file earlier. 6. Do incremental or final route. ecoRoute NanoRoute automatically detects modified and new nets, and incrementally routes any nets that are incomplete or have violations. 7. (Optional) Add notches. fillNotch 8. (Optional) If the original design contained metal fill, trim the metal fill: trimMetalFill Cadence recommends that you use this command to trim metal fill during the ECO process instead of deleting and adding the metal fill again. May 2005 704 Product Version 4.1.5 Encounter User Guide ECO Flows Pre-Mask ECO Changes from a New DEF File In this flow, your design is placed and possibly routed, and you want to make a few changes with known cell placements from a new DEF file. Examples of this flow include: ■ Bringing in an external clock tree after placement ■ Bringing in external optimizations such as new buffers or cell resizing ■ Bringing in external post-route fixes such as new buffers or cell resizing Preparation Before starting the flow steps, you should have the following files available: ■ oldchip.enc oldchip.enc.dat/ Create these files by using the saveDesign command after the previous placement, optimization, and routing steps. or ■ oldchip.conf oldchip.v oldchip.def Create these files by using the saveConfig, saveNetlist, and defOut commands after the previous placement, optimization and routing steps. ■ newchip.def The new DEF file is typically created by an external tool, or possibly done manually to fix a few critical post-route violations with specific placements required. Any necessary physical cells (+SOURCE DIST) are expected to also be in the new DEF. You must start with the old Verilog and update the Verilog modules with new ports and nets as required to match the new DEF netlist. You need to make sure the DEF instance names match the expected Verilog names (for example, a new buffer added to the output of instance /i1/i2/i3 should have a name such as /i1/i2/mynewbuf_i100), otherwise spurious Verilog ports will be created. May 2005 705 Product Version 4.1.5 Encounter User Guide ECO Flows Flow 1. Read the old floorplan/netlist 2. Compare the old netlist to DEF 3. Load the ECO file 4. Write the modified netlist (optional) 5. Read the new placement data 6. Perform incremental or final routing 7. Trim metal fill Steps 1. Read the old Verilog netlist, floorplan, and placement information into Encounter by doing one of the following: restoreDesign oldchip.enc or loadConfig oldchip.conf defIn oldchip.def This step reads in the following information: ❑ Old libraries and global power connections ❑ Old timing constraints (could be new constraints if necessary) ❑ Special routing, placements and optionally old routing ❑ Old filler cells, end caps, well taps, and other cell information 2. Compare the current old netlist to the new DEF netlist to create an ECO file. ecoCompareNetlist -def newchip.def -outFile oldchip.eco The ECO file has all the changes required to make the current netlist match the new netlist. Physical-only cells are ignored (for example, +SOURCE DIST cells such as filler, end caps, and well taps). Examine the ECO file to ensure it is correct. 3. Load the ECO file to incrementally update the current netlist to match the new netlist. loadECO oldchip.eco During this step, May 2005 706 Product Version 4.1.5 Encounter User Guide ECO Flows ❑ Instances and nets that are only in the old Verilog are deleted (for example, an old clock tree). Some Verilog ports may now be unconnected due to deleted nets. ❑ New instances are still unplaced. ❑ New ports and nets are created in Verilog modules as needed to connect instances in different Verilog modules. ❑ If any nets are deleted, then any routing attached to the net is also deleted. ❑ If any nets are modified, then any routing on those nets is left unchanged for later repair. ❑ Global power connections are done automatically based on the rules from the configuration file or floorplan file loaded earlier. 4. (Optional) Write out the modified Verilog netlist. saveNetlist oldchip_after_eco.v The oldchip_after_eco.v file should be the same netlist as newchip.def, although it is possible for the net names to be different (any new DEF net names that connect across multiple Verilog modules may be renamed). If you need a DEF file that has exactly the same net names, you can use the defOut command. 5. Read in the new placements. defIn newchip.def During this step, ❑ All instance placements are updated, including unplaced instances. Typically any existing old instances are not moved, but nothing prevents them from moving if the new DEF moved them. ❑ Remove the deleteFiller command before using defIn if the new DEF contains different fill, end cap, or well tap cells (+SOURCE DIST). If the filler cells are not changed, the deleteFiller command is not necessary. If the new DEF does not have any filler cells, the filler cells (if any) from the old DEF are left in place. ❑ If any instances are still unplaced, the ecoPlace command can be used to place them after removing any notch-fill or metal-fill wiring using the editDelete command. ❑ If only legalization of the placement is needed, the refinePlace command can be used. ❑ If routing is in the new DEF file (typically from the routing done on the old netlist), the routing will also be read in, and it will replace the routing on existing nets. 6. Perform incremental or final routing. May 2005 707 Product Version 4.1.5 Encounter User Guide ECO Flows setNanoRouteMode routeWithEco true # set for incremental routing globalDetailRoute NanoRoute automatically detects opens and shorts, and incrementally routes any nets that are incomplete or have violations. 7. (Optional) If the original design contained metal fill, trim the metal fill: trimMetalFill Cadence recommends that you use this command to trim metal fill during the ECO process instead of deleting and adding the metal fill again. 8. Continue with the normal post-routing flow (analysis, repair, notch-fill, metal-fill, verify, sign-off, and so forth). May 2005 708 Product Version 4.1.5 Encounter User Guide ECO Flows Pre-Mask ECO Changes from New OpenAccess Data In this flow, your design is placed and possibly routed, and you want to make a few changes with known cell placements from a new OpenAccess database. Examples of this flow include: ■ Bringing in an external clock tree after placement ■ Bringing in external optimizations such as new buffers or cell resizing ■ Bringing in external post-route fixes such as new buffers or cell resizing Preparation Before starting the flow steps, you should have the following files available: ■ designLib/topCell/oldLayout Create the data using the saveOaDesign command after the previous placement, optimization, and routing steps. or ■ oldchip.conf oldchip.v designLib/topCell/oldLayout Create these files by using the saveConfig, saveNetlist, and oaOut commands after the previous placement, optimization and routing steps. ■ designLib/topCell/newLayout The new OpenAccess database is typically created by an external tool, or possibly done manually to fix a few critical post-route violations with specific placements required. Any necessary physical cells (DEF +SOURCE DIST) are expected to also be in the new OpenAccess database. You must start with the old Verilog and update the Verilog modules with new ports and nets as required to match the new OpenAccess database connectivity. You need to make sure the OpenAccess instance names match the expected Verilog names (for example, a new buffer added to the output of instance /i1/i2/i3 should have a name such as /i1/i2/mynewbuf_i100), otherwise spurious Verilog ports will be created. May 2005 709 Product Version 4.1.5 Encounter User Guide ECO Flows Flow ■ Read the old floorplan/netlist ■ Compare the old netlist to OpenAccess database ■ Load the ECO file ■ Write the modified netlist (optional) ■ Read the new placement data ■ Perform incremental or final routing ■ Trim metal fill Steps 1. Read the old Verilog netlist, floorplan, and placement information into Encounter by doing one of the following: restoreDesign oldchip.enc or restoreOaDesign designLib topCell oldLayout or loadConfig oldchip.conf oaIn designLib topCell oldLayout This step reads in the following information: ❑ Old libraries and global power connections ❑ Old timing constraints (could be new constraints if necessary) ❑ Special routing, placements and (optionally) old routing ❑ Old filler cells, end caps, well taps, and other cell information 2. Compare the current database to the new OpenAccess database to create an ECO file. ecoCompareNetlist -oa designLib topCell newLayout -outFile oldchip.eco The ECO file has all the changes required to make the current netlist match the new netlist. Physical-only cells are ignored (for example, +SOURCE DIST cells such as filler, end caps, and well taps). Examine the ECO file to ensure it is correct. 3. Load the ECO file to incrementally update the current netlist to match the new netlist. loadECO oldchip.eco May 2005 710 Product Version 4.1.5 Encounter User Guide ECO Flows During this step, ❑ Instances and nets that are only in the old Verilog are deleted (for example, an old clock tree). Some Verilog ports may now be unconnected due to deleted nets. ❑ New instances are still unplaced. ❑ New ports and nets are created in Verilog modules as needed to connect instances in different Verilog modules. ❑ If any nets are deleted, then any routing attached to the net is also deleted. ❑ If any nets are modified, then any routing on those nets is left unchanged for later repair. ❑ Global power connections are done automatically based on the rules from the configuration file or floorplan file loaded earlier. 4. (Optional) Write out the modified Verilog netlist. saveNetlist oldchip_after_eco.v The oldchip_after_eco.v file should be the same netlist as in designLib/ topCell/newLayout, although it is possible for the net names to be different (any new OpenAccess net names that connect across multiple Verilog modules may be renamed). If you need a OpenAccess database that has exactly the same net names, use the oaOut command. 5. Read in the new placements and routing. oaIn designLib topCell newLayout During this step, ❑ All instance placements are updated, including unplaced instances. Typically any existing old instances are not moved, but nothing prevents them from moving if the new OpenAccess database moved them. ❑ If the new OpenAccess database has different filler, end cap, or well tap cells (DEF +SOURCE DIST), the old filler cells should first be removed with the deleteFiller command before using the oaIn command. If the filler cells are not changed, the deleteFiller command is not necessary. If the new OpenAccess database does not have any filler cells, the filler cells (if any) from the old design are left in place. ❑ If any instances are still unplaced, the ecoPlace command can be used to place them after removing any notch-fill or metal-fill wiring using the editDelete command. ❑ If only legalization of the placement is needed, the refinePlace command can be used. May 2005 711 Product Version 4.1.5 Encounter User Guide ECO Flows ❑ If routing is in the new OpenAccess database (typically from the routing done on the old netlist), the routing will also be read in, and it will replace the routing on existing nets. 6. Perform incremental or final routing. setNanoRouteMode routeWithEco true # set for incremental routing globalDetailRoute NanoRoute automatically detects opens and shorts, and incrementally routes any nets that are incomplete or have violations. 7. (Optional) If the original design contained metal fill, trim the metal fill: trimMetalFill Cadence recommends that you use this command to trim metal fill during the ECO process instead of deleting and adding the metal fill again. 8. Continue with the normal post-routing flow (analysis, repair, notch-fill, metal-fill, verify, sign-off, and so forth). May 2005 712 Product Version 4.1.5 Encounter User Guide ECO Flows Post-Mask ECO Changes from a New Verilog Netlist In this flow, the design is taped out and has errors. There is a new Verilog file that only has a few logical changes from the old Verilog file. You want to use pre-existing spare cells so the poly/diffusion and lower layers are not changed, and only the metal and via layer masks need to be modified. To save mask cost, you can direct the software to perform routing changes only on specific layers. Preparation Before starting the flow steps, you must have the following files: ■ oldchip.enc oldchip.enc.dat/ Create these files by using the saveDesign command after the previous placement, optimization, and routing steps. or oldchip.conf oldchip.v oldchip.def Create these files by using the saveConfig, saveNetlist, and defOut commands after the previous placement, optimization and routing steps. The old Verilog already has spare cells in it. They are typically added to the original Verilog by creating spare cells at the top-level or inside a Verilog module(s) just to hold the spare cells. For example, a Verilog module named mySpareCells is added with as many spare cells as required inside this Verilog module. You can identify the spare cells before the original placement by using the following command: specifySpareGate -inst mySpareCells The placer spreads the spare cells evenly throughout the design. If the design is hierarchical, you can add more spare cells inside modules that are likely to change. If the cells are at the top-level with a naming convention such as SPARE_1, SPARE_2, and so forth, then you can identify them with the following command: specifySpareGate -inst SPARE*. If you cannot avoid making changes on all layers, you can add spare cells after reading the original Verilog. Create an ECO file containing a list of ADDINST commands to create May 2005 713 Product Version 4.1.5 Encounter User Guide ECO Flows spare cells and ADDHIERINST commands to create new Verilog modules. Read the ECO file with the loadECO command and identify the spare cells by using the specifySpareGate command before placement. ■ oldchip.fp (Optional) You can either save the floorplan in the DEF file or in the floorplan file. If your DEF file does not contain the required floorplan information, you must use saveFPlan to generate oldchip.fp. ■ newchip.v The new Verilog file is identical to the old Verilog file (including antenna diode cells created during routing) except for a small number of manual fixes for logic errors. Flow 1. Read the new netlist 2. Load old floorplan/placement/routing data 3. Specify spare cells 4. Remove notches 5. Perform incremental placement 6. Save the modified design 7. Perform incremental or final route 8. Add notches 9. Trim metal fill Steps 1. Read the new netlist. loadConfig newchip.conf # same as oldchip.conf except use newchip.v or loadconfig oldchip.conf 0 set rda_Input(ui_netlist) “newchip.v” commitConfig May 2005 714 Product Version 4.1.5 Encounter User Guide ECO Flows The netlist Includes old libraries, global power connections, and so forth. It typically uses old timing constraints, however new timing constraints can be used. 2. Read the old floorplan, special routes, placements and routing from the old netlist files. loadFPlan oldchip.fp #optional ecoDefIn -postMask -suffix _spare -reportFile ecoDefIn.rpt oldchip.def applyGlobalNets Note: You do not need to use the loadFPlan command if all floorplan information already exists in the oldchip.def file; however, you must use loadFPlan if oldchip.def contains only placement and routing information. During this step, ❑ The -postMask option ensures that deleted items are also restored. ❑ Matching instances get old placements. ❑ Any instance existing only in the oldchip.def file (deleted cells) is kept in the design, and its name is appended with the string specified by -suffix. For example, if you specify -suffix _spare, instance i1/i2/i3 is changed to i1/i2/i3_spare. ❑ Changed instances (new cell) are assigned a new cell and are left unplaced. ❑ Physical-only cells in the oldchip.def file (marked with +SOURCE DIST in the DEF) are added; for example, well taps, end caps, and filler cells. ❑ Instances that are only in the new netlist are left unplaced. ❑ Routing for existing or modified nets is restored (possibly with opens or shorts). ❑ Routing for deleted nets is also restored. The ecoRoute command removes the nets according to the -modifyOnlyLayer option. ❑ All unplaced cells are mapped to spare cells during ECO placement in a later step. 3. Specify the spare cell list. specifySpareGate -inst SPARE* 4. Remove notch fill (if present). deleteNotchFill Note: Do not do this step if you plan to freeze metal layers, because this command modifies all layers. 5. Do incremental placement. ecoPlace -useSpareCells May 2005 715 Product Version 4.1.5 Encounter User Guide ECO Flows ❑ In the post-mask flow, you must specify -useSpareCells to ensure that ecoPlace is switched to mapping mode. In this mode, ecoPlace maps all unplaced cells to spare cells. ❑ The ecoPlace command automatically chooses a spare cell that is identical to the cell being mapped. 6. (Optional) Swap spare cells. ecoSwapSpareCell i_9649 spare1 ❑ At this step of the flow, all the newly-added cells should be mapped. In this step, you can use the ecoSwapSpareCell command to manually change the mapping. ❑ i_9649 is the instance name of the placed cell that ecoSwapSpareCell swaps with spare cell spare1. ❑ spare1 must be a spare cell specified in the previous step. Use the specifySpareGate command if necessary. 7. (Optional) Save the modified design. saveDesign design.eco.enc Saving the design before you run ecoRoute allows you to explore different modifyOnlyLayers ranges without repeating all of the previous steps. 8. Do incremental or final routing. ecoRoute -modifyOnlyLayers 2:3 ❑ You can use the -modifyOnlyLayers option to restrict the modifications to a specified range of metal layers. ❑ If the -modifyOnlyLayers range begins with layer 2, and the spare cell pins are only available from metal 1, then the ecoRoute command automatically drops a VIA12 via. This behavior is not available if the -modifyOnlyLayers range does not begin with 2. ❑ The ecoRoute command might not be successful if the specified layer range is not sufficient to meet the changes required. You must restore the design from the previous step, then use a different range, such as 2:4, 1:3, and so on. ❑ The unused routing segments of deleted and modified nets will appear in the SPECIALNETS section of the DEF file. 9. (Optional) Add notches. fillNotch Note: Skip this step if you specify freeze metal layers, because this command modifies all layers. May 2005 716 Product Version 4.1.5 Encounter User Guide ECO Flows 10. (Optional) If the original design contained metal fill, trim the metal fill: trimMetalFill Cadence recommends that you use this command to trim metal fill during the ECO process instead of deleting and adding the metal fill again. May 2005 717 Product Version 4.1.5 Encounter User Guide ECO Flows Post-Mask Gate Array Style ECO from a New Verilog Netlist The design is taped out and has a small number errors. There is a new Verilog netlist that has a few logical changes from the old Verilog netlist. You want to use pre-existing gate array style filler cells that can be programmed with metal layers so the poly/diffusion and lower layers are not changed, and only the metal and via layer masks need to be modified. The new netlist is typically created manually by modifying the old netlist, and any new instances are chosen from cells with a GACORE site. Preparation Before starting the flow steps, do the following: ■ ■ Create a library of GACORE cells as follows: ❑ All cells have a common transistor pattern. ❑ The cells are a fixed number of CORE sites wide. For example, the width of a GACORE site might be four times the width of a CORE site. ❑ The logical cells are programmed by metal1 for various AND and OR type gates. ❑ Filler cells use the same transistor pattern (for example, GAfiller). Pre-place the GACORE filler cells before the final routing in the old design: ❑ Encounter requires an overlayed row pattern for the GACORE cells. Before the final routing (pre-mask), commands such as the following are used: defIn garows.def addFiller -cell GAfiller -prefix GAFILL -fillBoundary addFiller -cell fill2 -prefix FILL -fillBoundary addFiller -cell fill1 -prefix FILL -fillBoundary ■ Follow these rules for the Verilog netlist: ❑ Any new instance is only chosen from the GACORE cells. ❑ Any instance can be deleted (it will be left in the netlist as a sparecell). Before starting the flow steps, you must have the following files: ■ oldchip.enc oldchip.enc.dat/ May 2005 718 Product Version 4.1.5 Encounter User Guide ECO Flows Create these files by using the saveDesign command after the previous placement, optimization, and routing steps. or oldchip.conf oldchip.v oldchip.def Create these files by using the saveConfig, saveNetlist, and defOut commands after the previous placement, optimization and routing steps. The old Verilog already has spare cells in it. They are typically added to the original Verilog by creating spare cells at the top-level or inside a Verilog module(s) just to hold the spare cells. For example, a Verilog module named mySpareCells is added with as many spare cells as required inside this Verilog module. You can identify the spare cells before the original placement by using the following command: specifySpareGate -inst mySpareCells The placer spreads the spare cells evenly throughout the design. If the design is hierarchical, you can add more spare cells inside modules that are likely to change. If the cells are at the top-level with a naming convention such as SPARE_1, SPARE_2, and so forth, then you can identify them with the following command: specifySpareGate -inst SPARE*. If you cannot avoid making changes on all layers, you can add spare cells after reading the original Verilog. Create an ECO file containing a list of ADDINST commands to create spare cells and ADDHIERINST commands to create new Verilog modules. Read the ECO file with the loadECO command and identify the spare cells by using the specifySpareGate command before placement. ■ oldchip.fp You can either save the floorplan in the DEF file or in the floorplan file. If your DEF file does not contain the required floorplan information, you must use saveFPlan to generate oldchip.fp. ■ newchip.v The new Verilog file is identical to the old Verilog file (including antenna diode cells created during routing) except for a small number of manual fixes for logic errors. ❑ May 2005 719 Product Version 4.1.5 Encounter User Guide ECO Flows Steps 1. Read the new netlist. loadConfig newchip.conf # same as oldchip.conf except use newchip.v or loadconfig oldchip.conf 0 set rda_Input(ui_netlist) “newchip.v” commitConfig The netlist Includes old libraries, global power connections, and so forth. It typically uses old timing constraints, however new timing constraints can be used. This procedure reads in the following information: ❑ The new netlist ❑ Old libraries and global power connections ❑ Old timing constraints (could be new constraints if necessary) 2. Read the old floorplan, special routes, placements, and routing from the old netlist files. loadFPlan oldchip.fp ecoDefIn -useGACells GACORE -suffix _spare -reportFile ecoDefIn.rpt oldchip.def applyGlobalNets ❑ The -useGACells GACORE option implies -useSpareCells. ❑ This procedure reads in the following information: ❍ Special routing, placements, and old routing ❍ Old filler cells, end caps, well taps, and other cell information ❑ Deleted GACORE cells that are only in the old DEF are deleted (they will be added back by GACORE site filler cells later in the flow). ❑ Regular standard cells that are only in the old DEF file are implicitly deleted by leaving them in place and changing the name from i1/i2/i3 to i1/i2/i3_SPARE. The input pins of these new spare cells are tied to the ground net or tie-low cell. ❑ New GACORE instances are left unplaced. ❑ Global power connections are made automatically based on the rules from the configuration file or floorplan file loaded earlier. May 2005 720 Product Version 4.1.5 Encounter User Guide ECO Flows Any GACORE rows in the old design are restored; normal CORE rows are also restored. GACORE rows could optionally come from a separate DEF file if they are not saved with the old design. 3. Specify the spare cell list. specifySpareGate -inst SPARE* 4. Remove notch fill (if present). deleteNotchFill Note: Do not do this step if you plan to freeze metal layers, because this command modifies all layers. 5. Do incremental placement. deleteFiller -prefix GAFILL ecoPlace -useGACells GACORE addFiller -cell -GAFiller -prefix GAFILL -fillBoundary This procedure does the following: ❑ Removes GACORE filler cells to leave gaps for the ecoPlace command. The ecoPlace command snaps GACORE cells to the GACORE row sites. Routing is unaffected. ❑ Puts back the GACORE filler cells in any leftover gaps. ❑ ecoPlace maps cells not matching the GACORE to the available spare cells. ❑ ecoPlace places the GACORE cells in a legal placement location. 6. (Optional) Swap spare cells. ecoSwapSpareCell i_9649 spare1 ❑ At this step of the flow, all the newly-added cells should be mapped. In this step, you can use the ecoSwapSpareCell command to manually change the mapping. ❑ i_9649 is the instance name of the placed cell that ecoSwapSpareCell swaps with spare cell spare1. ❑ spare1 must be a spare cell specified in the previous step. Use the specifySpareGate command if necessary. 7. (Optional) Save the modified design. saveDesign design.eco.enc Saving the design before you run ecoRoute allows you to explore different modifyOnlyLayers ranges without repeating all of the previous steps. 8. Do incremental or final route. May 2005 721 Product Version 4.1.5 Encounter User Guide ECO Flows setNanoRouteMode -routeinsertantennadiode false ecoRoute -modifyOnlyLayers 2:3 During this step, ❑ NanoRoute automatically detects opens and shorts, and incrementally routes any nets that are incomplete or have violations. ❑ Disable insertion of antenna diode cells. The poly/diffusion layers cannot be modified, so only layer-hopping can be used to avoid process antenna violations. ❑ You can use the -modifyOnlyLayers option to restrict the modifications to a specified range of metal layers. ❑ If the -modifyOnlyLayers range begins with layer 2, and the spare cell pins are only available from metal 1, then the ecoRoute command automatically drops a VIA12 via. This behavior is not available if the -modifyOnlyLayers range does not begin with 2. ❑ The ecoRoute command might not be successful if the specified layer range is not sufficient to meet the changes required. You must restore the design from the previous step, then use a different range, such as 2:4, 1:3, and so on. ❑ The unused routing segments of deleted and modified nets will appear in the SPECIALNETS section of the DEF file. 9. (Optional) Add notches. fillNotch Note: Skip this step if you specify freeze metal layers, because this command modifies all layers. 10. (Optional) If the original design contained metal fill, trim the metal fill: trimMetalFill Cadence recommends that you use this command to trim metal fill during the ECO process instead of deleting and adding the metal fill again. May 2005 722 Product Version 4.1.5 Encounter User Guide Index Numerics batch mode, running NanoRoute in 402 binding keys, for wire editing 353 Blackbox Timing Analysis, described 576 blackboxes converting to fences or partitions 159 deleting 160 flows 159 incremental pin assignments 167 pin assignments for 166, 167 pins 166 specifying, methods of 158 block halos orientation of 245 saving 246 viewing 246 block pins orientation of, changing, to resolve route congestion 388 block rings around power domains 277 creating 258 specifying coordinates with 258 block-level partitions, creating 193 blocks changing module status from fence 192 displaying macro current source location 639 boundary voltage file, and power analysis 653 bounding box, defining 227 buffer trees, inspecting routing topology of in interactive ECO 619 buffers added during timing optimization, viewing 607 attaching to I/O pins in interactive ECO 616 hole punch 183 inserting 184 problems with, in timing analysis 575 bump arrays 100 bumps assigning 105 cell pads, and I/O assignment files 48 cells, I/O assignment files and 44 cross probe between APD and 64-bit mode, starting 65 A AC current violations, checking 665 Amoeba placement general principles 293 overview 286 and partition cuts 293 preroutes and blockages 291 running on areas of severe congestion 295 view 293 antenna cells ensuring connectivity after inserting with NanoRoute 452 highlighting after inserting with NanoRoute 453 antennas, trimming 362 area I/O See also flip chip placement, and I/O assignment files 44 placement, performing 288 assign nets, removing from Verilog netlist 85 Astro or Apollo, using with NanoRoute 456 attributes NanoRoute 404 persistency of 404 VoltageStorm cell library cell_leakage_power 639 internal_power 640 auto fetch pad locations 645 Auto Fetch, using 646 automatic mode of CTS 318 Automatic Power Planning (APP), described 264 B back-end designer, and approach to basic floorplanning 217 May 2005 723 Product Version 4.1.5 Encounter User Guide Encounter 131 I/O assignment files and 45 routing 105 viewing flight lines 105, 128, 133 bus names, and partition pin guides 173 and maximum skew value 326 NanoRoute attribute section 337 order of items in 333 clock tree synthesis. See CTS clones, orientation of, in partitions 161 clustering, netlist 313 CML file, example for flip chip 137 command-line help and man pages 74 Common Timing Engine. See CTE configuration files loading 82 congestion checking with NanoRoute 417 post-placement 314 resolving with density screens 388 resolving by reorienting block pins 388 congestion analysis table, generated by NanoRoute 417 congestion distribution report in Trial Route 381 usage and routing overflow percentage values in 381 congestion distribution table acceptable values in 378 valued described 383 congestion map used by NanoRoute 395, 418 congestion markers, in Trial Route, described 378 connectivity loops, detecting 658 console, Encounter, described 69 constraint files, with timing budgets for partitions 474 constraint reader, commands supported 59 conventions, syntax and typographic 24 coordinates, using to specify block rings or core rings 258 core design area, and I/O pads 288 core dimensions margin, described 219 size, described 219 core rings creating 258 specifying coordinates with 258 core size, determining 224 core-to-I/O distance, specifying in partitioning 163 correlation between native and sign-off extraction, assuring 514 C capacitance comparison, graph and report 518 capacitance table basic 508, 509 creating 507 example 508 extended 508, 509 generating 506 reading 512 CCAR, editing wires with 369 CDSDoc (online documentation), accessing 74 cell blockage visibility, controlling 368 cell delay specification, and CTS 325 cell padding and clock buffers 290 and highly localized clocks 290 and placement space 290 cell timing model, and CTS 329 cell_leakage_power, VoltageStorm cell library attribute 639 channel estimation, reporting example 191 channelless designs, and feedthroughs 180 clock buffers, and cell padding 290 clock fanout buffers, limiting 341 clock grouping, and CTS 326 clock mesh 593 clock nets routing guide file in CTS for NanoRoute 337 routing with NanoRoute 427, 428, 435 setting attributes for in NanoRoute 427 clock tree specification file automatic gated CTS section 340 clock grouping data section 339 clock tree topology section 339 contents 333 creating 333 to 349 example 333 macro model data section 338 May 2005 724 Product Version 4.1.5 Encounter User Guide cross-probing bumps, between APD and Encounter 131 crosstalk correcting violations with NanoRoute 429 effect on incremental delay 626 overview 626 preventing violations with NanoRoute 429 crosstalk analysis, specifying noise analysis mode 630 CTE using for timing-driven routing with NanoRoute 422 CTS automatic mode 318 and gated clocks 319 and nets 318 and cell delay specification 325 cell timing model requirement 329 clock buffers, and cell padding 290 clock designs with tight areas 329 clock grouping and automatic mode 326 clock tree specification file automatic gated CTS section 340 clock grouping data section 339 clock tree topology section 339 contents 333 creating 333 to 349 example 333 macro model data section 338 NanoRoute attribute section 337 order of items in 333 files required for 316 gating cells, defined 343 hierarchical CTS analysis 327 highly localized clock, and cell padding 290 and INSERTION_DELAY statement 325 log file headings 349 macro model delay specification 325 manual mode 317 modes 317 and module placement utilization 329 padding cells, moving 343 and pin balancing for macro models 329 and pin instance delay specification 325 May 2005 and port delay specification 325 preparatory procedure 316 and recommended placement utilization 290 tracing clock trees 319 cut areas, and rectilinear partitions 162 cut layers, using NanoRoute to repair PAE violations on 453 cuts, creating for power domains 274 cutting shielding wires 361 D data checking before importing a design 78 exporting 88 importing 88 database saving, with NanoRoute 396 database units (DBU), adjusting the value of for NanoRoute 397 DBU. See database units debugging NanoRoute 458 Debussy Waveform tool, viewing waveform file with 648 decoupling capacitor modeling 647 DEF files comparing with database 620 comparison file format 620 demand, defined in Trial Route 382 density screens, using to resolve route congestion 388 density, calculating 224 design checking 60 checking data before importing 78 display area, described 218 importing 78 saving files 87 detailed routing description of 395 running in NanoRoute 414 violations, troubleshooting 414, 458 die size described 219 dielectric layer syntax 679 differential signal routing 134, 267 diodes, highlighting after inserting with 725 Product Version 4.1.5 Encounter User Guide NanoRoute 453 display area, for floorplanning 218 Display Setting file 654 VoltageStorm 654 distributed routing, running with NanoRoute 407 documentation, online, accessing 74 documents, related, list of 25 reading 512 overview 502 preparatory procedure F fabrication process information 671 fanouts, clock buffer, limiting 341 fat via, definition of 443 feature license matrix, for Encounter products 32 feature summary First Encounter Ultra 28 Nano Encounter 29 Nano Encounter DBS 29 NanoRoute Ultra 30 SoC Encounter 30 feedback buffer 180 feedthrough buffers, insertion of, and limitations 181 feedthrough insertion, and partitioning 180 feedthroughs 178 to 185 buffers vs. routing 178 and channelless designs 180 channel-type 184 inserting 178, 179 routing 183 fences changing module status to block 192 constraints 220 converting from blackboxes 159 module constraint types 220 and partition pins 172 restrictions 220 field solvers, 2-D and 3-D 507 file selection, general description 83 files boundary voltage 653 Display Setting, VoltageStorm 654 Estimation Parameter 642 ICT comparing with LEF file 514 sheet and via resistance values in 514 instance power data 652 instance voltage 652 pad location 644 power pad location fetching automatically 645 saving 645 E ECO naming conventions, table of 620 netlist, updating 294 placement 294 general principles 294 routing, NanoRoute 434 ECO flows alternative pre-mask 702 description 696 GACORE cells 718 post-mask from new netlist 713 post-mask gate-array 718 pre-mask 698 pre-mask from new DEF 705 Edit Route form populating 354 effective utilization (EU value) 223 electrostatic discharge cells 100 EM values, calculating for wires and vias 655 Encounter console, described 69 Encounter software, starting 66 encrypting libraries 50 endcap cells placing 310 removing 310 environment, run-time, setting 64 Estimation Parameter file 642 EU value 223 exporting TDF files 91 extraction and capacitance comparison graph and report 518 capacitance table basic 508, 509 example 508 extended 508, 509 generating 506 May 2005 503 726 Product Version 4.1.5 Encounter User Guide required for CTS 316 routing blockage, generating 157 TDF, importing and exporting 91 tile description format 143 timing constraints 474 updating during a session 96 updating incrementally 96 waveform, viewing with Debussy Waveform tool 648 filler cells adding 308 adding to power domains 282 implant layers 308 removing 310 replacing during process antenna repair with NanoRoute 452 Flight 219 flight lines definition 219 for bumps 105, 128, 133 flip chip defined 100 flows bump flow 108 tile flow 120 methodology 100 route feasibility report example 138 routing bumps to I/O driver cells 128 testing package routing feasibility 130 tile description file format 143 useful tasks 144 floorplan data, types 89, 91 display, described 218 loading 254 saving 254 floorplan files, containing routing blockage data 157 floorplan objects and partition feedthroughs 183 and power domains 270 floorplanning modes for power analysis floorplan 635 layout 635 overview 216 relative 235 to 241 row spacing 225 sequence 217 steps 217 front-end designer, and approach to basic May 2005 floorplanning 217 G GACORE cells ECO flows 718 gated clocks, and CTS automatic mode 319 gating cells, defined for CTS 343 gcells definition of 394 gcells, obstructed and overflowed, summarized in Trial Route congestion distribution report 382 GDS files map file format 94 merging 93 global net connections 259 global routing description of 394 running in NanoRoute 414 guide constraints 220 guides, module constraint types 220 H halos, see block halos hard blocks, changing status of partition from 192 help, command-line 74 hierarchical clock tree analysis, and CTS 327 to 328 hierarchical designs timing budgeting, methods for 472 hole punch buffers, inserting 184 horizontal and vertical tracks, summarized in Trial Route congestion distribution report 381 I I/O assignment files multiple I/O rows in 44 ICT file case sensitivity 672 commands 672 contents 671 example 683 727 Product Version 4.1.5 Encounter User Guide format 672 ICT files comparing with LEF file 514 sheet and via resistance values in 514 implant layers, for filler cells 308 implementation block-level 151 top-level 153 importing TDF files 91 tile cell design data 86 incremental delay crosstalk effect on 626 insert 178 INSERTION_DELAY statement, and macro models in CTS 325 inserts 179 instance average power report 651 instance groups adding an instance to 226 deleting 226 saving to netlist 226 specifying 223 instance power data file 652 instance voltage files 652 example for power and ground nets 652 instantiation, of power plan template 266 interactive ECO naming conventions, table of 620 overview 614 interconnect capacitance modeling creating ICT file 671 to 693 internal_power, VoltageStorm cell library attribute 640 I/O assignment files and area I/O placement 44 and bump cell pads 48 bump cells and 44 bumps and 45 creating 42 described 42 examples of I/O pads in 46 module pins in 48 rule-based, creating 46 I/O pads core dimension size 219 inside core design area 288 and I/O assignment files 46 I/O pins, adding buffers to, in interactive ECO 616 May 2005 island, and routing feedthroughs 184 J JTAG cells placement of 292 K keyboard shortcuts, for wire editing 353 L layers changing during wire editing 365 routing, checking metal density of 659 LEF files checking for availability before importing 78 comparing with ICT file 514 example for flip chip 137 LEF statements for metal density 659 for process antenna calculations 662 for verifying geometry 661 libraries checking for availability before importing 78 multiple threshold voltage 605 timing 50, 536 license matrix, for Encounter products 32 licenses checking out 68 controlling for multi-threading 66, 410 controlling for super-threading 409, 410 product, table of 64 load unit values, inconsistency in, and effect on timing analysis 536 log file, congestion analysis table in 417 M macro current source location 639 location, displaying for blocks 639 macro model delay, and CTS 325 macro models, pin banancing for 329 728 Product Version 4.1.5 Encounter User Guide man pages, command-line 74 manual mode of CTS 317 map file format, described 94 master partitions, defined 160 maximum fanouts, limiting for clock buffers 341 maximum skew value, and clock tree specification file 326 maximum wire width, fixing violations of 363 metal density checking 659 LEF statements for 659 metal fill adding 469 definition of 460 LEF parameters for 461 overview 460 preparatory procedure 460 recommendations for 462 setting parameters for 461 trimming 470 problems caused by vias 468 minimum cut violations, fixing 261 minimum spacing violations, fixing 261 modes CTS, automatic 318 CTS, manual 317 power analysis 635 power analysis, floorplan 635 power analysis, layout 635 module constraint types described 220 fence 220 guide 220 and physical design size 221 region 221 soft guide 221 module fences, restrictions 220 module guides 220 and partition pins 172 module pins, and I/O assignment files 48 module placement utilization, and CTS 329 module placement, examples of 247 to 253 module status, changing from fence to block 192 modules assigning to power domains 272 placement utilization and CTS 329 May 2005 MSV (multiple supply voltage) overview 270 power analysis 282 power domains, assigning modules to 272 rectilinear power domains 274 use model 271 to 282 multi-cut vias, using 443 multiple I/O rows, specifying in I/O assignment file 44 multiple supply voltage. See MSV multi-threading controlling licenses for 66, 68, 410 running 68 running with NanoRoute 69 running with WRoute 69 N naming conventions for ECO 620 for timing optimization 611 NanoRoute adjusting process antenna calculations for 453 adjusting the database units (DBU) value for 397 Astro or Apollo, using with NanoRoute 456 attributes characteristics of 404 compared with options 404 batch mode, running 402 clock nets routing 428 setting attributes for 427 commands to run within Encounter environment 401 comparison of batch and native mode 402, 434 congestion analysis table, using 417 congestion map 395, 418 congestion, checking 417 connectivity, power and ground pins 452 crosstalk correcting violations 429 preventing violations 429 CTE, using 422 database, saving 396 729 Product Version 4.1.5 Encounter User Guide debugging 458 detailed routing 414 distributed routing 407 ECO routing 434 evaluating violations in 435 generating tracks for 398 global routing 414 hard spacing, forcing 450 multi-threading, running 69 nets, shielding 445 nondefault rule routing 450 nondefault spacing in 450 options compared with attributes 404 crosstalk prevention 431 list of. See setNanoRouteMode in the Encounter Text Command Reference multi-threading 412 process antenna repair 454 super-threading 412 via optimization 443 overlapping cells, checking for 397 overview 394 pin access, improving 397 pins, checking for under power routes 398 postroute optimization in 416 preparatory procedure 397 prerouted nets, skipping during routing 434, 446 routing accelerating 407 batch mode 402 clock nets 427, 435 detailed 395 distributed 407 ECO 433 global 394 shielded 445 signal-integrity driven 431 standalone mode 403 statistics report 399 strategy 413 super-threading 408 wide wires 450 shielded routing 445 signal integrity, preventing problems with 429 soft spacing 450 soft spacing routing 450 May 2005 standalone, running from Encounter 402 super-threading running 408 stopping 409 table of violations 437 tapering wires in 450 timing engine, specifying 422 timing graph, using with standalone NanoRoute 423 timing-driven routing 441 troubleshooting design problems 458 vias optimizing 443 rotated, checking for 450 using multi-cut 443 violations on upper layers 439 marker placement for 435 process antenna, repairing 452 table for evaluating 437 native extraction default mode 504 defined 504 detailed mode 504 flow, illustrated 504 See also extraction, sign-off extraction net attributes characteristics of in NanoRoute 404 net average power report 651 net group names, and partition pin guides 173 net names, and partition pin guides 173 netlist clustering 313 netlists ECO, updating 294 and feedthroughs 178 preparing 41 saving instance groups to 226 Verilog, concatenating for a partitioned design 195 Verilog, removing Assign nets from 85 nets and CTS automatic mode 319 deleting violated nets 442 names, and partition pin guides 173 shielding, in NanoRoute 445 noise analysis mode, specifying for crosstalk analysis 630 nominal voltage 640 nondefault rule routing, NanoRoute 450 730 Product Version 4.1.5 Encounter User Guide nonrectangular partitions 162 P O package routing feasibility testing, using APD 130 pad location file 640 creating 644 padding cells moving in CTS 343 partition cuts, and Amoeba placement 293 partition data, and restoring top-level floorplan 194 partition feedthroughs, defining 183 partition pin guides and bus names 173 and net group names 173 partition pinS guide objects 157 partition pins assigning 167 guide names, changing 173 guides, adding 172 ranges 176 snapping 176 partitioning block-level 193 channel estimates, reporting example 191 concatenating netlists of 195 core-to-I/O distance, specifying 163 feedthrough insertion 180 loading 197 overview 146 restoring 197 restoring top-level floorplan 194 running 192 saving 196 top-level 192 partitions adding cut areas to rectilinear 163 changing status from hard block 192 converting from blackboxes 159 master, defined 160 multiple instantiations 160 nonrectangular 162 pin assignments for 167 pin blockage 174 pin editing 177 pin guides 172 pins 166 rectilinear 170 obstructed gcell information, summarized in Trial Route congestion distribution report 382 OCV 561 on-chip variation 561 online documentation (CDSDoc), accessing 74 OpenAccess exporting data 92 restoring a design 87 saving a design 88 operating voltage 640 operating voltage, default 656 optimization, within pin guides 173 optimizing vias 443 options NanoRoute characteristics and persistency of 404 compared with attributes 404 crosstalk prevention 431 list of. See setNanoRouteMode in the Encounter Text Command Reference multi-threading 412 process antenna 454 route acceleration 412 super-threading 412 via optimization 443 orientation, of blocks, changing 388 orientation key 235 Ostrich parasitics correlation utility 514 OverCon #Gcell, definition of 417 overflow percentage values, in Trial Route congestion distribution report 381 overflowed gcells, summarized in Trial Route congestion distribution report 382 overlapping cells, checking for in NanoRoute 397 overlapping objects selecting 357 May 2005 731 Product Version 4.1.5 Encounter User Guide creating 162 repeated 160 specifying 156 and timing budgets for 474 passivation layer example 682 path groups 593 peripheral I/O, and flip chip 100 physical connectivity, and power grid, report on 655 physical design size, and module constraint types 221 physical layout, verifying 661 physical libraries creating 38 physical prototyping, overview of in SoC Encounter 35 physical-only cells, removing 310 pin access, improving for NanoRoute 397 pin alignment, illustrated 177 pin assignments incremental, for partitions 168 rectilinear 170 and rectilinear edges 162 pin balancing, and macro models 329 pin blockage 174 pin guides location 172 and optimization 173 pin instance delay specification, and CTS 325 pin order, preserving in pin guide 172 pins blackbox assigning 166 partition assigning 166 preventing creation of 157 when created in absence of partition pin guide objects 157 underneath power routes, checking for in NanoRoute 398 visibility 357 PKS constraints, reading 59 placement area I/O, performing 288 general sequence 287 loading files 314 rectilinear 293 saving data 314 timing-driven 312 May 2005 window 295 placement area constraints, and spare cells 289 placement blockages, general principles for 291 placement constraint area, determining 289 placement space, and cell padding 290 placement utilization, recommended value for CTS 290 planar dielectric syntax 679 port delay specification, and CTS 325 post-CTS optimization 591 postplacement congestion 314 post-route optimization 595 postroute optimization, in NanoRoute 416 power analysis and boundary voltage file 653 decoupling capacitor modeling 647 flow using Encounter and VoltageStorm 643 for MSV designs 282 instance average power report 651 instance power data file 652 and instance voltage file 652 modes simulation-based 636 statistical 636 net average power report 651 overview 635 pad location file 640, 644 power graph report 650 power graph, viewing 647 power/rail summary report 649 preparatory procedure 636 rail analysis 636 results 638 running 639 setup procedure 637 simple estimate mode 641 and SPEF files 641 and VoltageStorm 643 waveform file, viewing 649 power consumption profile, viewing 648 power domains adding filler cells 282 adding power stripes to 262, 278 boundaries 281 creating block rings around 277 cuts, creating 274 732 Product Version 4.1.5 Encounter User Guide defined 270 and floorplan objects 270 overview 270 rectilinear 274 timing libraries 281 unsupported tools 270 power graph report 650 power grids, and physical connectivity data report 655 power pad location file fetching automatically 645 saving 645 power plan template block rings 265 creating 264 design 266 instantiation 266 IP blocks 265 power analysis data 267 stripes 265 power planning, overview 256 power routing, overview 257 power structures, creating, preparatory procedure 256 power waveforms, viewing 648 power/rail summary report 649 example 649 pre-CTS optimization 586 preferences initialization files for 72 session, setting 72 prerouted nets, skipping routing on 434, 446 PrimeTime format, and timing constraint file creation 474 timing graph, using for timing with NanoRoute 426 process antenna violations verifying 662 process antennas adjusting NanoRoute calculations for 453 ensuring antenna cell connectivity 452 methods NanoRoute uses to repair violations from 452 NanoRoute options for repairing violations from 454 repairing by changing routing layers 452 repairing by diode insertion 452 May 2005 product licenses order of checking out table of 64 68 R rail analysis 636 ranges, for partition pins 173 RC extraction. See extraction, native extraction, sign-off extraction RC scaling factors generating 513 methods for specifying 521 reclaiming area 593 rectilinear boundaries, identification of 170 rectilinear pin assignments 170 rectilinear placement 293 rectilinear power domains 274 rectilinear shape, defining 227 rectilinear shapes, and pin assignments 170 redundant vias, using 443 regions, module constraint types 221 related documents, list of 25 relative floorplanning examples of 237 to 240 orientation Encounter 235 LEF/DEF 236 overview 235 placement 237 to 239 saving commands for 237 relative floorplans loading 241 reshaping 238 to 240 restoring 241 repeated partitions. See partitions reports capacitance comparison 519 instance average power 651 NanoRoute 399 net average power 651 physical connectivity data and power grids 655 power graph 650 power/rail summary 649 routing statistics 399 used by NanoRoute 399 wire length 399 restoring 733 Product Version 4.1.5 Encounter User Guide designs from previous software versions 88 OpenAccess designs 87 ring pins connecting 261 rotated vias, checking for with NanoRoute 398 route congestion, resolving by inserting density screens 388 by reorienting block pins 388 routers choosing NanoRoute or WRoute 394 routes removing while editing 354 reshaping 367 routing See also NanoRoute choosing NanoRoute or WRoute 394 clock nets with NanoRoute 427, 435 differential 134, 267 feedthroughs 183 routing blockage file, generating 157 routing bumps to I/O driver cells 128 routing feedthroughs, inserting 184 routing guide file, from CTS 337 routing layers, checking metal density of 659 routing resources, and channelless designs 180 routing strategy, NanoRoute 413 row configurations, types supported 225 row spacing, standard 225 rule-based I/O assignment files, creating 46 run-time environment, setting 64 scan functionality, general principles for 296 scan nets, reordering 296 scheme format, mapping LEF vias and layers to 456 search and repair omitted in NanoRoute detailed routing 414 phases of, in NanoRoute 415 segments deleting 357 selecting wire shapes 357 session preferences, setting 72 set_dont_touch constraint, implications of for timing analysis 538 severe congestion, reducing with Amoeba placement 295 shapes, wire 357 sheet resistance values, and ICT files 514 shielded routing with NanoRoute 445 shielding wires cutting 361 SI. See signal integrity signal integrity crosstalk effect on incremental delay 626 in timing optimization 595 incremental mode 631 NanoRoute, using to prevent problems 429 preventing problems using NanoRoute 429 setting NanoRoute options for 431 signal routers choosing NanoRoute or WRoute 394 See also extraction, native extraction sign-off extraction described 522 requirements 523 simple estimate mode, in power analysis 641 simulation-based mode, in power analysis 636 slot. See routing feedthrough soft guides, module constraint types 221 spare cells distribution of 289 and placement area constraints 289 specifying during floorplanning session 289 S Sbox. See switch box scaling factors, RC specifying, methods for 521 scan cells, and placement 296 scan chains reordering 296 flows 298 native approach 297, 297 to 301 scanDEF approach 297, 302 to 307 scan files loading 307 saving 307 May 2005 734 Product Version 4.1.5 Encounter User Guide special route loading 258 saving 258 specification file, for CTS. See clock tree specification file SPEF files comparing files from runQX and extractDetailRC commands 517 and power analysis 641 SRoute overview 257 Stamp models defined 51 preparing 51 standalone NanoRoute running from Encounter 402 using a timing graph with 423 standard cell density, calculating 224 standard cells placing 105 statistical mode, in power analysis 636 stripes, adding to power domains 262, 278 super-threading controlling licenses for 410 definition of 407 features of 407 license considerations for 409 running in NanoRoute 408 stopping 409 supply, defined, in Trial Route 382 switch box, definition of 395 syntax conventions 24 timing violations, analyzing 574 timing analysis overview 531 preparatory procedure 533 and buffer problems 575 timing budgeting and hierarchical designs 472 methods for, in hierarchical designs 472 timing budgets constraint files for partitions, generating 474 for partitions 474 values for, analyzing 488 timing closure design flow, preparing data for 61 timing constraings importing from PKS 59 timing constraints file, and set_dont_touch constraint 538 file 474 importing 59 preparing 51 read by Encounter PrimeTime, Design Compiler 51 timing engine, specifying for NanoRoute 422 timing graph commands to generate for NanoRoute 424 generating with CTE 424 using with PrimeTime and NanoRoute 426 using with standalone NanoRoute 423 timing libraries for power domains 281 preparing 50 timing models, for cells in CTS 329 timing optimization added buffers, viewing 607 clock domains 588, 589, 592, 593 effort levels, defaults 607 hold violations 597 incremental 589, 593 incremental,path groups 589 incremental,useful skew 589 inputting a SPEF file 598 low-effort mode 587 naming conventions 611 path groups 588, 592 T tapering wires, NanoRoute 450 target utilization 221 TDF files, importing and exporting 91 technology file 38 template, for power plans 264 tie-hi input pins 311 tie-lo input pins 311 tie-off cell instances adding 311 removing 311 tile cell importing design data 86 tile description file format for flip chip 143 tile library loading guidelines 142 May 2005 735 Product Version 4.1.5 Encounter User Guide U post-CTS 591 post-route 595 pre-CTS 586 reclaiming area 588, 592 and set_case_analysis timing constraint 605 signal integrity violations 597 useful skew 588, 592 using multiple threshold voltage libraries 605 viewing added buffers 607 timing reports, commands for generating 574 timing-driven placement 312 timing-driven routing, NanoRoute 441 top-level floorplan, restoring with partition data 194 top-level partitioning 192 total density, calculating 224 tracks generating for NanoRoute 398 tracks, horizontal and vertical, summarized in Trial Route congestion distribution report 381 Trial Route analyzing values in congestion distribution table 378 congestion distribution report 381 obstructed and overflowed gcells in 382 congestion distribution table acceptable values in 378 values described 383 congestion markers, overflow values and 379 data for, deleted during partitioning 192 demand, defined 382 design analysis requirements 378 loading 378 overview 374 preparatory procedure 374 route congestion, resolving 387 saving 378 supply, defined 382 troubleshooting NanoRoute violations (table) 437 troubleshooting problems with NanoRoute 458 TU (target utilization) value 221 typographic conventions 24 May 2005 upper layer violations, NanoRoute 439 useful skew 593 controlling optimization 603 described 602 post-CTS 592, 593, 603 pre-CTS 588, 589, 602 user-defined ring 258 V verifying AC limit 665 connectivity 658 geometry 661 metal density 659 physical layout 661 process antenna violations 662 verifying AC limit ACCURRENTDENSITY tables checks 665 Verilog checking for availability before importing 78 Verilog netlists concatenating for a partitioned design 195 creating for entire design 195 creating from a DEF file 78 removing Assign nets from 85 unique for use in CTS, scan, and IPO features 41 vertical and horizontal tracks, summarized in Trial Route congestion distribution report 381 via fat, definition of 443 via resistance values, and ICT files 514 via syntax 682 vias changing 366 deleting 354 EM values, calculating for 655 example 682 metal area excluded from process antenna calculations 453 optimizing 443 optimizing in selected nets 444 736 Product Version 4.1.5 Encounter User Guide rotated, checking for in NanoRoute 450 using multi-cut (redundant) 443 vias, minimizing the number of 444 ViewICT errors and warnings 672 views Amoeba 293 Violation Browser, features of 667 violation markers clearing from design 669 highlighting 667 imported from NanoRoute to Encounter 435 NanoRoute placement of 435 and verifying connectivity 658 viewing 667 violation report, database impact of 658 violations deleting violated nets 442 evaluating in NanoRoute 435 fixing minimum cut 261 fixing minimum spacing 261 in NanoRoute, evaluation table 437 repair strategies for 442 timing, analyzing 574 voltage nominal 640 operating 640 voltage level shifters inserting 282 to 283 and MSV 281 voltage source reference points 640 VoltageStorm 655 Display Setting file 654 power analysis with Encounter 643 running 643 running with Encounter menus and commands 643 overview 352 wire groups, adding with wire editor 360 wire layers, changing 365 wire length report 399 wire tapering, in NanoRoute 450 wire width changing 363 fixing violations of 363 wires cutting 361 duplicating 364 editing with CCAR 369 EM values for, calculating 655 extending automatically 359 moving with arrow keys 356 with mouse 355 stretching 364 trimming 362 wizard for creating power plan template 264 WRoute, when to use 394 W waveform file, viewing with Debussy Waveform tool 648 well-tap cells placing 309 removing 310 wide wires, routing with NanoRoute 450 window placement 295 wire editing binding keys 353 May 2005 737 Product Version 4.1.5 Encounter User Guide May 2005 738 Product Version 4.1.5