ICC Design Planning

IC Compiler™
Design Planning
User Guide
Version L-2016.03, March 2016
Copyright Notice and Proprietary Information
©2016 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to
Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with
Synopsys, Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated
documentation is strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.
Synopsys, Inc.
690 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com
IC Compiler™ Design Planning User Guide, Version L-2016.03 ii

Copyright Notice for the Command-Line Editing Feature
© 1992, 1993 The Regents of the University of California. All rights reserved. This code is derived from software
contributed to Berkeley by Christos Zoulas of Cornell University.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
following conditions are met:
1.Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer.
2.Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with the distribution.
3.All advertising materials mentioning features or use of this software must display the following acknowledgement:
This product includes software developed by the University of California, Berkeley and its contributors.
4.Neither the name of the University nor the names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Copyright Notice for the Line-Editing Library

© 1992 Simmule Turner and Rich Salz. All rights reserved.
This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of
the University of California.
Permission is granted to anyone to use this software for any purpose on any computer system, and to alter it and
redistribute it freely, subject to the following restrictions:
1.The authors are not responsible for the consequences of use of this software, no matter how awful, even if they arise
from flaws in it.
2.The origin of this software must not be misrepresented, either by explicit claim or by omission. Since few users ever
read sources, credits must appear in the documentation.
3.Altered versions must be plainly marked as such, and must not be misrepresented as being the original software.
Since few users ever read sources, credits must appear in the documentation.
4.This notice may not be removed or altered.
IC Compiler™ Design Planning User Guide, Version L-2016.03 iii

IC Compiler™ Design Planning User Guide, Version L-2016.03 iv
Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
1. Introduction to Design Planning

Design Planning Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Design Planning Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Hierarchical Methodology for Design Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Design Partitioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Deciding on the Physical Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Hierarchical Floorplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Padding the Plan Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Shielding Plan Groups or Soft Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Assigning Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Creating Soft Macros From the Plan Groups . . . . . . . . . . . . . . . . . . . . . . . 1-9
Pushing Down Physical Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Hierarchical Timing Closure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Early Chip-Level Timing Feasibility Check . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Timing and Signal Integrity Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Clock Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
2. Creating a Floorplan
Supported Types of Floorplans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Channeled Floorplans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Abutted Floorplans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Narrow-Channel Floorplans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
v
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide Version L-2016.03
L-2016.03
Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Connecting Power and Ground Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Adding Power, Ground, and Corner Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Setting the I/O Pad Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Setting the Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Saving the Pin and Pad Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Reading an Existing Pad and Pin Constraints File . . . . . . . . . . . . . . . . . . . . . . 2-8
Reporting the Pad and Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Removing the Pad and Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Initializing the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Creating a Rectangular Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Creating a Simple Rectilinear Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Creating a Complex Rectilinear Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Refining the Floorplan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Adjusting the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Manually Modifying the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Defining the Die Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Removing Cell Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Adding Cell Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Defining the Wire Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Adjusting the I/O Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
Saving the Floorplan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
Writing the Floorplan File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
Writing the Floorplan to a DEF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Floorplan Physical Constraints in Design Compiler . . . . . . . . . . . . . . . . . . . . . . 2-29
Extracting Physical Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Exporting Physical Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Reading In an Existing Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Reading DEF Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Reading Floorplan Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Copying a Floorplan From Another Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
3. Automating Die Size Exploration

MinChip Technology Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Routing Congestion Considerations for MinChip Technology . . . . . . . . . . . . . . . . . . 3-4
Contents vi
IC Compiler™ Design Planning User Guide Version L-2016.03
Power Network Considerations for MinChip Technology . . . . . . . . . . . . . . . . . . . . . 3-4

Macro Placement Considerations for MinChip Technology . . . . . . . . . . . . . . . . . . . 3-5
Macro Blockage Considerations for MinChip Technology. . . . . . . . . . . . . . . . . . . . . 3-5
Floorplan and I/O Cell Considerations for MinChip Technology . . . . . . . . . . . . . . . . 3-7
MinChip Technology Command and GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Using MinChip Technology With Multivoltage Designs . . . . . . . . . . . . . . . . . . . . . . . 3-10
4. Handling Black Boxes

Black Box Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Reading Netlists Containing Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Converting Logical Black Boxes to Physical Black Boxes. . . . . . . . . . . . . . . . . . . . . 4-5
Converting Physical Black Boxes to Logical Black Boxes. . . . . . . . . . . . . . . . . . . . . 4-6
Sizing Black Boxes by Width and Height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Sizing Black Boxes by Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Creating a FRAM View For a Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Constraining Routing Over Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Setting the Black Box Estimation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Creating Quick Timing Models for Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Writing a Quick Timing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Loading a Quick Timing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Propagating Timing Information to Soft Macros . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Creating Unique Cell Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
5. On-Demand-Loading Flow for Large Designs

On-Demand-Loading Design Planning Flow Overview. . . . . . . . . . . . . . . . . . . . . . . 5-2
On-Demand Netlist Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Viewing Plan Group Information in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Creating the Reduced Netlist and Full Netlist in Separate Runs . . . . . . . . . . . . 5-9
Using Distributed Processing in the On-Demand-Loading Flow . . . . . . . . . . . . 5-10
Converting Additional Plan Groups to Reduced Plan Groups . . . . . . . . . . . . . . 5-12
Improving Compression on Plan Groups With Side Loads . . . . . . . . . . . . . . . . 5-12
Chapter 1: Contents
Contents vii
1-vii
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
On-Demand-Loading for Multicorner-Multimode Designs . . . . . . . . . . . . . . . . . 5-14

Features Not Supported by the create_on_demand_netlist Command. . . . . . . 5-15
Removing On-Demand Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Reporting and Querying Information About On-Demand Netlists. . . . . . . . . . . . . . . 5-16
Cell Placement in the On-Demand-Loading Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Timing Budgeting Using On-Demand Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Using Black Boxes in the On-Demand-Loading Flow . . . . . . . . . . . . . . . . . . . . . . . . 5-18
UPF Support in the On-Demand-Loading Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Committing Plan Groups Within the On-Demand-Loading Flow. . . . . . . . . . . . . . . . 5-22
6. Virtual Flat Placement

Virtual Flat Placement Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Virtual Flat Placement Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Congestion-Driven Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Timing-Driven Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Hierarchical Gravity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Exploration Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Simultaneous Placement and Pin Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Virtual Flat Placement Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Virtual Flat Placement Strategy Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Macro-Related Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Automatic Grouping of Macros Into Arrays . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Fixing Macros in Place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
Macro Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Macro Setup Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Macro Minimum Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Macros on Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Pin Routing Aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Sliver Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Snap Macros to User Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
Congestion-Related Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
Net Weighting Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Miscellaneous Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
Reset to Default Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Block Constraint File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Contents viii
Flip-Chip Driver Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Automatic Hierarchy Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Hierarchical Gravity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Honor Multivoltage Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Spread Spare Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Virtual In-Place Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Hard Macro Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Macro Array Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Macro Placement Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
Relative Location Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37
Blockages, Margins, and Shielding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Placement Blockages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Keepout Margins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-42
Relative Placement Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-44
Placing Relative Placement Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46
Using the Default Relative Placement Flow . . . . . . . . . . . . . . . . . . . . . . . . 6-46
Using the Relative Placement Cells Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Propagating Relative Placement Groups by Commit and Uncommit . . . . . . . . 6-48
Committing Relative Placement Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
Uncommitting Relative Placement Groups . . . . . . . . . . . . . . . . . . . . . . . . . 6-49
Design Flow for Hierarchical Relative Placement Groups . . . . . . . . . . . . . 6-49
Placement Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50
Placement Quality of Results Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51
Evaluating Macro Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-52
Total Wire Length Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54
Floorplan Editing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54
Removing Cell Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-56
Packing Hard Macros Into an Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-57
Manually Adjusting the Hard Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58
Using Constraints With the Core and Die Editing Commands. . . . . . . . . . . . . . 6-59
Voltage Area Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-59
Supported Voltage Area Physical Boundary Scenarios. . . . . . . . . . . . . . . . . . . 6-63
Updating Voltage Areas in a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-64
Removing Voltage Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-64
Placing Multiply Instantiated Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-64
Chapter 1: Contents
Contents ix
1-ix
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
Identifying Multiply Instantiated Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-65

Creating Unique Block Abstractions From Multiply Instantiated Modules. . 6-65
Removing the Multiply Instantiated Module Property . . . . . . . . . . . . . . . . . 6-66
Identifying Multiply Instantiated Module Plan Groups . . . . . . . . . . . . . . . . . . . . 6-66
Shaping Multiply Instantiated Module Plan Groups . . . . . . . . . . . . . . . . . . . . . . 6-67
Placing and Analyzing Multiply Instantiated Module Plan Groups. . . . . . . . . . . 6-67
Copying the Cell Placement of a Plan Group . . . . . . . . . . . . . . . . . . . . . . . 6-69
Copying Placement Blockages and Boundaries . . . . . . . . . . . . . . . . . . . . . 6-69
Restoring the Placement of Cells in Plan Groups . . . . . . . . . . . . . . . . . . . 6-70
Flipping Multiply Instantiated Module Plan Groups . . . . . . . . . . . . . . . . . . . . . . 6-70
Horizontal Requirements for Plan Group Locations . . . . . . . . . . . . . . . . . . 6-71
Vertical Requirements for Plan Group Locations . . . . . . . . . . . . . . . . . . . . 6-72
QoR Analysis of Multiply Instantiated Module Plan Groups . . . . . . . . . . . . . . . 6-72
7. Plan Groups
Plan Group Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Create Plan Group Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Remove Plan Group Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Plan Group Padding Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Remove Plan Group Padding Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Add Block Shielding Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Remove Block Shielding Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Shape Plan Group Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Controlling the Placement and Shaping of Plan Groups and Macros. . . . . . . . . . . . 7-16
Analyzing and Manipulating the Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Opening the Hierarchy Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Exploring the Hierarchical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Manipulating the Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Merging the Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Flattening the Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
Using Relative Placement Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Plan Group Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
Physical-Only Cells in Plan Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25
Contents x
Reporting Channel Routing Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26

DFT-Aware Design Planning Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Generating and Using SCANDEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29
Performing Plan Group-Aware Scan Chain Optimization . . . . . . . . . . . . . . . . . 7-29
Using Plan Group-Aware Repartitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29
Committing Physical Hierarchy Changes After Scan Chain Optimization . . . . . 7-30
Checking the SCANDEF Data Against the Netlist . . . . . . . . . . . . . . . . . . . . . . . 7-31
8. Performing Power Planning

Performing Power Network Synthesis on Single-Voltage Designs . . . . . . . . . . . . . . 8-2
Saving the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Defining Logical Power and Ground Connections . . . . . . . . . . . . . . . . . . . . . . . 8-3
Applying Power Rail Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Applying Power Ring Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Creating Virtual Pads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Synthesizing the Power Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Committing the Power Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Performing Power Network Synthesis on Multivoltage Designs . . . . . . . . . . . . . . . . 8-7
Saving the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Selecting a Voltage Area and Specifying Synthesis Constraints . . . . . . . . . . . . 8-8
Setting Layer Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Setting Ring Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Setting Global Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Synthesizing the Power Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Creating Template-Based Power Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Defining Power Plan Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Creating a Power Plan Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Retrieving Power Plan Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Reshaping Power Plan Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Reading and Writing Power Plan Regions . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
Creating the Power Ring Template File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Power Ring Template Side Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Power Ring Template Advanced Rules Section . . . . . . . . . . . . . . . . . . . . . 8-20
Creating the Power Ring Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
Reporting and Removing Power Ring Strategies . . . . . . . . . . . . . . . . . . . . 8-22
Compiling the Power Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
Template-Based Power Ring Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
Chapter 1: Contents
Contents xi
1-xi
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
Creating Rings Around Voltage Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23

Aligning Rings With Standard Cell Rails. . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
Creating Rings Around a User-Specified Polygon . . . . . . . . . . . . . . . . . . . 8-26
Creating Rings Around Macro Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
Creating Corner Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28
Creating Partial Power Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29
Creating Power Rings with Varying Segment Widths . . . . . . . . . . . . . . . . . 8-30
Creating Template-Based Power Meshes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Defining Power Plan Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Creating the Power Mesh Template File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Power Mesh Template Layer Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
Creating and Using Parameters in a Template File . . . . . . . . . . . . . . . . . . 8-35
Power Mesh Template Advanced Rules Section . . . . . . . . . . . . . . . . . . . . 8-36
Creating the Power Mesh Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41
Reporting and Removing Power Mesh Strategies . . . . . . . . . . . . . . . . . . . 8-43
Compiling the Power Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
Template-Based Power Mesh Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46
Creating a Simple Power Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47
Creating a Power Plan Strategy for a Multivoltage Design . . . . . . . . . . . . . 8-48
Creating Power Straps on Macro Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
Creating a Power Grid in an Abutted Voltage Area. . . . . . . . . . . . . . . . . . . 8-51
Creating Extension Finger Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-53
Creating Pad Ring Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-55
Inserting Straps into the Channel Area. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-56
Aligning Power Straps with Power Switches . . . . . . . . . . . . . . . . . . . . . . . . 8-57
Nonuniform Power Straps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-59
Creating Power-Switch Arrays and Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-60
Power Switch Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-61
Selecting the Proper Power-Switch Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-62
Defining a Power Switch Placement Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 8-63
Creating a Power-Switch Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-64
Creating a Power-Switch Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-64
Exploring Different Switch Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-67
Optimizing Power Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-68
Connecting Power Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-68
Analyzing the Power Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-69
Performing Power Network Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-70
Creating Connectivity Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-70
Contents xii
Performing Power Analysis With Switching Activity Information . . . . . . . . . . . . 8-71

Annotating Switching Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-71
Performing Power Network Analysis for Each Cell Instance. . . . . . . . . . . . 8-72
Viewing the Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-73
Displaying the Voltage Drop Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-73
Displaying the Resistance Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-75
Displaying the Electromigration Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
Displaying the Instance Voltage Drop Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
Displaying the Instance Power Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
Displaying the Instance Power Density Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
9. Performing Clock Planning

Clock Plan Options Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Compile Clock Plan Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Generating Clock Network and Source Latency for Each
Clock Pin of Each Plan Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Creating a Virtual Clock for I/O Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
Clock Planning on Multivoltage Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Plan-Group-Aware Clock Tree Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Clock Planning for Abutted Floorplans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Checking for Electromigration After Clock Tree Synthesis . . . . . . . . . . . . . . . . . . . . 9-8
Power Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Power Budget Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Extra Power Straps on Higher Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
10. Performing In-Place Timing Optimization

Performing In-Place Timing Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Running Trace Mode In-Place Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Reporting Trace Mode Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
Exiting the Trace Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Using In-Place Optimization With Multivoltage Designs . . . . . . . . . . . . . . . . . . . . . . 10-7
Performing In-Place Optimizations Based on Pin Locations. . . . . . . . . . . . . . . . . . . 10-7
Virtual In-Place Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Chapter 1: Contents
Contents xiii
1-xiii
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
11. Performing Routing-Based Pin Assignment

Setting Block-Level Pin Assignment Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Specifying Global Pin Assignment Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Specifying Pin Constraints for Special Conditions . . . . . . . . . . . . . . . . . . . . . . . 11-3
Reserving Narrow Channels for Special Nets . . . . . . . . . . . . . . . . . . . . . . 11-3
Keeping Bus Bits Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Reserving Space for Clock Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Reporting Pin Assignment Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Specifying Constraints for Individual Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Ignoring Constraints for Individual Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Performing Pin Assignment on Soft Macros and Plan Groups . . . . . . . . . . . . . . . . . 11-7
Performing Plan-Group-Aware Global Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Improving the Quality of the Global Routing for Pin Assignment . . . . . . . . 11-9
Improving the Performance of the Global Router . . . . . . . . . . . . . . . . . . . . 11-10
Placing Soft Macro and Plan Group Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
Performing Block-Level Pin Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
Committing the Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
Adjusting the Position of Placed Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13
Aligning Soft Macro Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13
Ordering Pins Alphabetically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14
Removing Soft Macro Pin Overlaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14
Adding Feedthrough Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Excluding Feedthroughs on Clock Nets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Specifying Net and Feedthrough Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Reporting Feedthrough Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Previewing Feedthrough Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20
Creating Feedthrough Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Performing Pin and Feedthrough Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Removing Feedthrough Ports, Nets, and Buffering . . . . . . . . . . . . . . . . . . . . . . 11-22
Adding Feedthrough Pins on Multivoltage Designs . . . . . . . . . . . . . . . . . . . . . . . . . 11-23
Setting Voltage Area Feedthrough Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 11-23
Creating Voltage Area Feedthroughs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23
Creating Feedthroughs Only on Voltage Areas . . . . . . . . . . . . . . . . . . . . . . . . . 11-24
Creating Feedthroughs on Voltage Areas Coincident with Plan Groups . . . . . . 11-24
Creating Feedthroughs on Voltage Areas Not Coincident with Plan Groups. . . 11-24
Contents xiv
Reporting Voltage Area Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25

Removing Voltage Area Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25
Performing Pin Placement With Multiply Instantiated Modules. . . . . . . . . . . . . . . . . 11-25
Setting Pin Assignment Constraints for Multiply
Instantiated Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25
Performing Plan-Group-Aware Routing for Multiply
Instantiated Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26
Selecting a Master Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26
Committing a Master Multiply Instantiated Module Plan Group. . . . . . . . . . . . . 11-27
Using Pin Guides for Pin Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-27
Creating Pin Guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-27
Using Pin Guides for Block-Level Off-Edge Pin Placement . . . . . . . . . . . . . . . . 11-29
Creating Pin Guides for Feedthroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-29
Reporting Pin Guide Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Checking for Off-Edge Pin Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Checking Pin Assignment and Pin Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Checking the Pin Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Checking the Pin Alignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-32
12. Performing Timing Budgeting

Timing Budgeting Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Performing Pre-Budget Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Running the Timing Budgeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Setting Block-Level Timing Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
Performing Fast Time to Budget Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
Checking the QoR of the Timing Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
Generating a Quick Timing Model for the Partitions of Large Designs . . . . . . . . . . 12-11
Quick Timing Model Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Performing Timing Budgeting On Plan Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Budgeting With Multiply Instantiated Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
Performing Budgeting on Multiple Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
Performing Distributed Timing Budgeting for Multiple Scenarios . . . . . . . . . . . . . . . 12-25
Performing Hierarchical Signal Integrity Budgeting. . . . . . . . . . . . . . . . . . . . . . . . . . 12-26
Chapter 1: Contents
Contents xv
1-xv
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
Block-Level Hierarchical Signal Integrity Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27

Top-Level Hierarchical Signal Integrity Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27
Performing Post-Budget Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-28
Performing Clock Latency Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-30
Creating Budgets to Reflect Real Clock Latencies . . . . . . . . . . . . . . . . . . . . . . 12-30
13. Committing the Physical Hierarchy

Converting Plan Groups to Soft Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Splitting the Soft Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3
Pushing Physical Objects Down to the Soft Macro Level . . . . . . . . . . . . . . . . . . . . . 13-4
Using the Margin Option for Pushing Down Objects . . . . . . . . . . . . . . . . . . . . . 13-6
Pushing Down Routing in Multiply Instantiated Modules . . . . . . . . . . . . . . . . . . 13-7
Pushing Physical Objects Up to the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
Handling 45-Degree Redistribution Layer Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Committing the Hierarchy of Plan Groups With Power Domains . . . . . . . . . . . . . . . 13-10
Converting Soft Macros to Plan Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
Appendix A. Using the Flip-Chip Flow

Flip-Chip Implementation Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Preparing the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
I/O Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Bump Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Creating an Initial Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
Using a Die-Driven Flip-Chip Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
Instantiating Bump Cells and Designating Matching Types . . . . . . . . . . . . . . . . A-7
Creating a Pattern of Bump Cells in a Ring Configuration . . . . . . . . . . . . . A-8
Creating an Array of Bump Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10
Designating Matching Types for Bump Patterns . . . . . . . . . . . . . . . . . . . . . . . . A-11
Placing Flip-Chip I/O Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
Defining the Location for Flip-Chip Drivers . . . . . . . . . . . . . . . . . . . . . . . . . A-13
Placing Flip-Chip Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
Designating a Matching Type for Flip-Chip Drivers. . . . . . . . . . . . . . . . . . . A-16
Assigning Nets From Bumps to I/O Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16
Merging Multiple Flip-Chip Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18
Contents xvi
Reporting Crossover Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18

Using a Package-Driven Flip-Chip Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19
Importing Bump Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21
Saving Bump Cell Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23
Defining Flip-Chip Driver Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23
Designating the Driver Matching Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24
Defining the Flip-Chip Placement Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24
Setting Options for Flip-Chip Driver Placement . . . . . . . . . . . . . . . . . . . . . . . . . A-24
Placing Flip-Chip Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-25
Routing Flip-Chip Bumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-25
Specifying Redistribution Layer Routing Rules . . . . . . . . . . . . . . . . . . . . . . . . . A-27
Performing Redistribution Layer Global Routing . . . . . . . . . . . . . . . . . . . . . . . . A-27
Analyzing Redistribution Layer Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28
Performing Redistribution Layer Detail Routing . . . . . . . . . . . . . . . . . . . . . . . . . A-28
Resolving Redistribution Layer Routing Congestion . . . . . . . . . . . . . . . . . . . . . A-29
Performing Incremental RDL Routing and Route Optimization . . . . . . . . . . . . . A-30
Writing Flip-Chip Nets to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-33
Creating Stacked Vias on Pad Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-33
Using Flip-Chip Structures in Cover Macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-35
Creating RDL Net Shielding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-35
Creating Tapered Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-38
Connecting Floating Bump Cells to Ring Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39
Summary of the Flip-Chip Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39
Appendix B. Data Flow Analyzer

Starting the Data Flow Analysis Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3
Expanding and Merging Logic Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-4
Moving and Reshaping Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6
Saving and Loading Expanded Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6
Examining Hard Macro Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6
Examining Net Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8
Tracing Macro and I/O Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13
Chapter 1: Contents
Contents xvii
1-xvii
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
Reporting Module Connection Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16

Highlighting Registers in Macro-to-Macro Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16
Setting Placement Gravity for Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19
Editing Macro Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19
Editing Macro Placement in the Layout View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-22
Copying Macro Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-24
Setting Macro Group Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-25
Closing the Data Flow Analysis Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-25
Configuring the CDE Desktop for DFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-26
Data Flow Analysis Control Center Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-27
Index
Contents xviii
Preface
This preface includes the following sections:
• About This Guide
• Customer Support
xix
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
About This Guide

The Synopsys IC Compiler™ tool provides a complete netlist-to-GDSII or
netlist-to-clock-tree-synthesis design solution, which combines proprietary design planning,
physical synthesis, clock tree synthesis, and routing for logical and physical design
implementations throughout the design flow.
This guide describes the IC Compiler implementation and integration flow; the companion
volume, IC Compiler Design Planning User Guide, describes the design planning flow.
Audience
This user guide is for design engineers who use the IC Compiler tool to implement designs.
To use the IC Compiler tool, you need to be skilled in physical design and design synthesis
and be familiar with the following:
• Physical design principles
• The Linux or UNIX operating system
• The tool command language (Tcl)
Related Publications
For additional information about IC Compiler, see the documentation on Synopsys SolvNet
at the following address:
https://solvnet.synopsys.com/DocsOnWeb
You might also want to see the documentation for the following related Synopsys products:
• Design Compiler®
• Milkyway Environment™
• IC Validator
• Hercules™
• PrimeRail
®
• PrimeTime PX
Preface
About This Guide xx
Release Notes
Information about new features, changes, enhancements, known limitations, and resolved
Synopsys Technical Action Requests (STARs) is available in the IC Compiler Release Notes
in SolvNet.
To see the IC Compiler Release Notes,
1. Go to the Download Center on SolvNet located at the following address:
https://solvnet.synopsys.com/DownloadCenter
2. Select IC Compiler, and then select a release in the list that appears.
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier Indicates syntax, such as write_def.
Courier italic Indicates a user-defined value in syntax, such as

write_def file_name.
Courier bold Indicates user input—text you type verbatim—in

examples, such as
prompt> write_def design.def
[] Denotes optional arguments in syntax, such as

write_def [-version version]
... Indicates that arguments can be repeated as many

times as needed, such as pin1 pin2 ... pinN.
| Indicates a choice among alternatives, such as

low | medium | high
Ctrl+C Indicates a keyboard combination, such as holding

down the Ctrl key and pressing C.
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Edit > Copy Indicates a path to a menu command, such as

opening the Edit menu and choosing Copy.
Preface 1: Preface
Chapter
About This Guide 1-xxi
xxi
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
L-2016.03
Customer Support
Customer support is available through SolvNet online customer support and through
contacting the Synopsys Technical Support Center.
Accessing SolvNet
SolvNet includes a knowledge base of technical articles and answers to frequently asked
questions about Synopsys tools. SolvNet also gives you access to a wide range of Synopsys
online services including software downloads, documentation, and technical support.
To access SolvNet, go to the following address:
https://solvnet.synopsys.com
If prompted, enter your user name and password. If you do not have a Synopsys user name
and password, follow the instructions to register with SolvNet.
If you need help using SolvNet, click HELP in the top-right menu bar.
Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys Technical
Support Center in the following ways:
• Open a support case to your local support center online by signing in to SolvNet at
https://solvnet.synopsys.com, clicking Support, and then clicking “Open A Support
Case.”
• Send an e-mail message to your local support center.
❍ E-mail support_center@synopsys.com from within North America.
❍ Find other local support center e-mail addresses at
http://www.synopsys.com/Support/GlobalSupportCenters/Pages
• Telephone your local support center.
❍ Call (800) 245-8005 from within North America.
❍ Find other local support center telephone numbers at
http://www.synopsys.com/Support/GlobalSupportCenters/Pages
Preface
Customer Support xxii
1
Introduction to Design Planning 1
You can use design planning and chip-level analysis capabilities to perform a feasibility
analysis on designs of various sizes and complexities. The IC Compiler tool supports both
flat and hierarchical design planning to enable fast exploration of the design to reduce die
size and to implement a final, optimized, and detailed floorplan.
This topic includes the following sections:
• Design Planning Features
• Design Planning Overview
• Hierarchical Methodology for Design Planning
1-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Design Planning Features

Design planning in the IC Compiler tool provides basic floorplanning and prototyping
capabilities for flat and hierarchical designs, such as:
• Incomplete or problematic netlist handling
• Automatic die size exploration
• Black box module and cell support
• Fast placement of macros and standard cells
• Packing macros into arrays
• Plan group creation and shaping
• In-place optimization
• Prototype global routing analysis
• Hierarchical clock planning
• Pin assignment on soft macros and plan groups
• Timing budgeting
• Hierarchy conversion
• Pin assignment and refinement
Power network synthesis, applied during the feasibility phase of design planning, provides
automatic synthesis of local power structures within voltage areas. Power network analysis
performs voltage drop and electromigration analysis. Power network analysis can be
applied to partial, complete, or power structures created by power network synthesis. Both
power network synthesis and power network analysis can be used for single or multisupply
designs. You can also perform low-power planning for multithreshold-CMOS designs.
MinChip technology in the IC Compiler tool explores potential die configurations to
determine the smallest routable die size for your design while maintaining the relative
placement of hard macros and I/O cells. Optionally, the flow uses power network synthesis
for power routing that meets voltage drop requirements and routing estimation technology to
access routing feasibility.
Chapter 1: Introduction to Design Planning

Design Planning Features 1-2
Design Planning Overview

Design planning is an integral part of the RTL to GDSII design process. During design
planning, you assess the feasibility of different implementation strategies early in the design
flow for both flat and hierarchical designs. For large designs, design planning is critical
because large designs are more likely to have long interblock paths whose delays can make
timing closure difficult, leading to time consuming and unpredictable tapeout schedules. As
chips migrate to smaller and smaller technology nodes, design size and design complexity
makes the designs more vulnerable to potential timing and power problems and therefore,
more in need of careful planning early in the design flow.
In the design planning context, floorplanning is the process of sizing and placing cells and
blocks in a way that makes later physical design steps more effective. Floorplanning in a
hierarchical flow also provides a basis for estimating the timing of the top-level interconnect
for verification. Floorplanning allocates timing budgets to each block based on the top-level
timing estimation. Floorplanning can also be an iterative process that reshapes and replaces
blocks, reallocates the timing budgets, and rechecks the top-level timing until an optimal
floorplan is reached.
An effective floorplan helps ensure timing closure in many ways: by placing blocks so that
critical paths are short, by preventing routing congestion that can lead to longer paths, by
eliminating the need for routing over noise-sensitive blocks, and so on. The challenge is to
create a floorplan with good area efficiency, to conserve silicon real estate and to leave
sufficient area for routing.
Similarly, design planning supports power planning, including low-power design techniques
that can be used in multivoltage designs and multithreshold-CMOS power switching. Power
network synthesis and power network analysis enable designers to create power structures
that meet voltage drop and electromigration specifications while minimizing the
consumption of routing resources. The placement engine recognizes power domains and
keeps together the cells of the same power domain. After you define voltage areas, power
network synthesis creates power meshes for all voltage areas simultaneously.
Floorplanning also helps to reduce IR drop and electromigration problems through
strategies such as placing blocks with the highest power consumption close to the periphery
of the chip and preventing the concentration of blocks in any one area.
The IC Compiler tool supports complete hierarchical design planning for both channeled and
abutted layout styles. For more information, see “Supported Types of Floorplans” in
Chapter 2.

Design Planning Overview 1-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Hierarchical Methodology for Design Planning

Use a hierarchical design methodology to enable a “divide and conquer” approach for large
designs. By dividing the design into multiple blocks, sometimes referred to as subblocks,
modules, or lower-level blocks, you can work on the blocks separately and in parallel from
RTL through physical implementation. Working with smaller blocks can reduce overall
runtime.
Consider using a hierarchical methodology in the following scenarios:
• The design is large, complex, and requires excessive computing resources to process
the design.
• You anticipate that a number of blocks might have problems, which might cause the
schedule to slip. Using a hierarchical methodology allows late design changes to be
made to individual blocks without disturbing the rest of the design.
• The design contains hard intellectual property (IP) macros such as RAMs, or the design
was previously implemented and can be converted and reused.
After the initial design netlist is generated in Design Compiler topographical mode, you can
use the hierarchical methodology for design planning in the IC Compiler tool. Design
planning is performed during the first stage of the hierarchical flow to partition the design into
blocks, generate hierarchical physical design constraints, and allocate top-level timing
budgets to lower-level physical blocks.
Figure 1-1 shows the hierarchical flow steps for design planning.

Hierarchical Methodology for Design Planning 1-4
Figure 1-1 Hierarchical Design Planning Flow

Read the netlist
(read_verilog) Setup plan-group-aware routing
(set_route_zrt_common_options
-plan_group_aware all_routing)
Remove multiply instantiated modules

(uniquify_fp_mw_cel) Plan-group-aware global routing
(route_zrt_global
-effort minimum)
Read the Synopsys Design Constraints
(read_sdc) Perform in-place optimization
(optimize_fp_timing)
Read the I/O physical constraints
(read_pin_pad_physical_constraints)
Perform clock planning
(compile_fp_clock_plan)
Create the initial floorplan
(create_floorplan)
Perform pin assignment
(place_fp_pins)
Perform initial virtual flat placement
(create_fp_placement)
Perform timing budgeting
(allocate_fp_budgets)
Legalize the placement
(legalize_placement)
Commit the hierarchy
(commit_fp_plan_groups)
Create and shape plan groups
(create_plan_groups)
(shape_fp_blocks) Refine the pin assignment
(check_fp_pin_assignment)
(check_fp_pin_alignment)
Perform power network synthesis
(synthesize_fp_rail)
Perform power network analysis

(analyze_fp_rail)

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
See Also
• Design Partitioning
• Hierarchical Floorplanning
• Hierarchical Timing Closure
Design Partitioning
The first step in a hierarchical design project is to determine the physical partitioning. When
deciding on the physical partition of a large design, you should consider the following
factors:
• Size
Ensure the size of the blocks is appropriate for the virtual flat IC Compiler implementation
flow. It is easier to floorplan with blocks of similar size, so small blocks should be grouped
and large blocks divided when appropriate.
• Function
Partition your design using its functional units for verification and simulation purposes.
Consider top-level connectivity and minimal block pin counts to avoid congestion and
timing issues.
• Floorplan style
Different floorplan styles require different physical hierarchies to support them. An
abutted floorplan style has no top-level logic and a channeled floorplan has either a small
or large amount of top-level logic.
• Common hierarchy with Design Compiler topographical mode
To exchange SCANDEF information at the block level and the top level, the physical
hierarchy used in Design Compiler topographical mode must also be used in the IC
Compiler tool.
During the design planning stage, a physical partition is represented by a plan group. A plan
group is a physical constraint for placing the cells of the same group together physically.
Each plan group represents a module in the logic hierarchy that you want to implement as a
physical block and contains only cells that belong to that module. The IC Compiler tool
supports both rectangular and rectilinear plan groups. For more information, see “Plan
Group Overview” in Chapter 7.

Deciding on the Physical Partitions

The IC Compiler tool provides the following features to help you decide on the physical
partitions:
• Using the Hierarchy Browser
You can use the hierarchy browser to navigate through the design hierarchy and to
examine the logic design hierarchy and display information about the hierarchical cells
and logic blocks in your design. You can select the hierarchical cells, leaf cells, or other
objects you want to examine in layout or schematic views.
To open the hierarchy browser, select one of the following menu items:
❍ In the layout window, choose Partition > New Hierarchy Browser View
❍ In the main window, choose Hierarchy > New Hierarchy Browser View
The view window consists of two panes with an instance tree on the left and an object
table on the right. The instance name of the top-level design appears at the top of the
instance tree.
When you create the physical hierarchy, you should use the existing modules in the
original logical hierarchy for the physical partitions. If you cannot use the original logical
hierarchy, you can use the merge_fp_hierarchy and flatten_fp_hierarchy
commands to modify the logical hierarchy.
For more information, see “Analyzing and Manipulating the Hierarchy” in Chapter 7.
• Performing Virtual Flat Placement
You can run virtual flat placement by using the create_fp_placement command to
identify the logical hierarchy modules that can be used as physical partitions. If you do
not know how the blocks are to be partitioned, you can run virtual flat placement without
any partition constraints. The resulting log file contains information about the hierarchy
nodes that are automatically selected for physical partitioning. The suggested physical
partitioning is based on size so that the physical hierarchy is well balanced.
The hierarchical gravity feature keeps cells of a hierarchical design logic block physically
together in the chip layout. This type of grouping usually results in better placement
because designs tend to partition well along hierarchical boundaries.
For more information, see “Virtual Flat Placement Overview” in Chapter 6.
• Placing and Shaping Plan Groups
Based on the distribution of cells resulting from the initial virtual flat placement, you can
use the shape_fp_blocks command to place, shape, and size plan groups
automatically inside the core area. After placement and shaping, you can adjust the
boundaries of the plan groups to finalize the floorplan.
For more information, see “Shape Plan Group Command” in Chapter 7.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Hierarchical Floorplanning
Hierarchical floorplanning includes the following steps:
• Padding the Plan Groups
• Shielding Plan Groups or Soft Macros
• Assigning Pins
• Creating Soft Macros From the Plan Groups
• Pushing Down Physical Objects
Padding the Plan Groups

In the hierarchical design phase, you should add padding around plan group boundaries by
using the create_fp_plan_group_padding command. Plan group padding sets placement
blockages on the internal and external edges of the plan group boundary to prevent cells
from being placed in the space around the plan group boundaries. If you place cells too
close to the plan group boundaries, congestion and implementation issues might occur.
The plan group padding is visible in the layout window. The plan group padding is dynamic,
which means that it follows the changes of the plan group boundaries.
For more information, see “Plan Group Padding Command” in Chapter 7.
Shielding Plan Groups or Soft Macros

To avoid congestion and crosstalk issues between a block and the top level, you can add
modular block shielding to plan groups and soft macros by using the
create_fp_block_shielding command. The shielding creates rectangular metal layers
around the outside of the soft macro boundary or plan group in the top level of the design or
around the inside boundary of the soft macro or plan group, or both.
Usually, you can selectively create metal layers to block the router from routing long nets
along the block boundaries. Note, however, that even if you block layers in the preferred
direction, nets can still sometimes be routed along the block boundaries. In that case, you
can consider blocking all layers. The block shielding is created along the soft macro
boundaries, but it leaves narrow openings to access the pins.
For more information, see “Add Block Shielding Command” in Chapter 7.

Assigning Pins
You can assign pins for soft macros in your design during floorplanning. Pins can be
constrained to fixed locations, or adjusted to align with the pin placement of pins in other
macros. You can create pin guides to restrict the possible placement locations of soft macro
pins. Feedthrough nets can be used to route signals through soft macros and reduce the
total path length. You can also block feedthrough creation to prevent a net from entering a
soft macro.
For more information, see “Setting Block-Level Pin Assignment Constraints” in Chapter 11.
Creating Soft Macros From the Plan Groups

You can convert selected plan groups or all plan groups with placement constraints into soft
macro CEL views by using the commit_fp_plan_groups command. Each soft macro is a
CEL view of the block in the same Milkyway design library. All related design information,
including the netlist, floorplan, pin assignment, and power plan is saved in the CEL view.
You can use the CEL view directly for block implementation in the IC Compiler tool.
For more information, see “Converting Plan Groups to Soft Macros” in Chapter 13.
Pushing Down Physical Objects

In the hierarchical design planning phase, most of the changes that are made to the
floorplan and the netlist are done at the full-chip level and inherited by the soft macros after
committing the plan groups. In some cases, however, changes to your design must be made
at the top level. You can do this by using the push_down_fp_objects command to push
down the physical objects such as routing, route guides, blockages, cells, and cell rows,
from the top level to the soft macro level. You can also use the push_up_fp_objects
command to push objects up from a soft macro back up to the top level.
For more information, see “Pushing Physical Objects Down to the Soft Macro Level” in
Chapter 13 and “Pushing Physical Objects Up to the Top Level” in Chapter 13.
Hierarchical Timing Closure

Timing closure in a hierarchical design is more challenging than that in a flat design. In a
hierarchical design, timing optimization might not be able to analyze or change all the logic
of the timing paths that are causing violations. Therefore, a hierarchical design needs a
more sophisticated flow to achieve timing closure.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The timing closure tasks in a hierarchical design include the following features:
• Early Chip-Level Timing Feasibility Check
• Timing and Signal Integrity Budgeting
• Clock Planning
Early Chip-Level Timing Feasibility Check

You can check the timing of the entire design at various stages of the design planning flow
by using the check_timing and report_timing commands. Depending on the options you
set, you can get reports on valid paths for the entire design or for specific paths,
unconstrained paths, and timing slack. The timing report helps evaluate why some parts of
a design might not be optimized. You can also use the check_fp_timing_environment
command to check zero wire delay timing and timing bottlenecks.
If the early timing check shows serious timing violations, you should run in-place
optimization by using the optimize_fp_timing command to improve the timing of your
design. When performing timing optimization, the command honors the plan groups defined
in the hierarchical design as well as the scan chain connections from the SCANDEF. The
result predicts potential critical paths in the design. Negative slack on interblock paths after
in-place optimization should not exceed 20 percent of the clock cycle time.
For more information, see “Performing In-Place Timing Optimization” in Chapter 10.
You should analyze the results, identify the root causes of the timing issues, and resolve
them before proceeding to the next steps.
Timing and Signal Integrity Budgeting

After the design passes the early timing feasibility checks, you can perform timing budgeting
on plan groups by using the allocate_fp_budgets command. The timing budgeting
determines the corresponding timing boundary constraints for each top-level soft macro or
plan group (block) in the design. If your design meets the timing boundary constraints for
each block when the block is implemented, the top-level timing constraints are satisfied.
Timing budgeting generates the SDC constraints and attributes for all the individual plan
groups. These constraints and attributes are then transferred to the individual soft macro
blocks when the hierarchy is committed by using the commit_fp_plan_groups command.
Timing budgeting can also consider crosstalk effects across soft macro boundaries when
generating SDC constraints.
Timing budgeting on plan groups runs with full-chip timing. It honors pin locations and
feedthrough nets assigned to the plan groups. Reasonable timing budgets result from good
chip-level timing.
For more information, see “Performing Pre-Budget Timing Analysis” in Chapter 12.

Clock Planning
Clock planning is an optional step in the design planning flow. You can use clock planning
to estimate the clock tree insertion delay and skew in a hierarchical design. It also helps you
determine the optimal clock pin locations on blocks.
If you use clock planning, run it before pin assignment. Clock planning inserts anchor cells
to isolate the clock trees inside the plan group from the top-level clock tree. It then runs fast
clock tree synthesis for each plan group to estimate the clock skew and insertion delay. The
tool annotates clock tree synthesis results on floating pins that are defined on the anchor
cells. Clock planning synthesizes the top-level clock tree to the anchor cell floating pins.
For hierarchical timing closure, clock planning is also used to generate realistic clock latency
through budgeting to fix timing violations. Top-level timing violations result not only from
delays on combinational logic between registers but also from clock skew between
launching and capturing registers. In a hierarchical design, clock tree synthesis inside each
soft macro cannot consider clock skews with the top level and other soft macros. In the
top-level integration phase, clock skews among different soft macros can cause setup and
hold violations on interblock paths. It is very hard to fix these violations without changing the
soft macros. To estimate the chip-level clock skew issues for block-level implementation,
consider using clock planning.
For more information, see “Clock Plan Options Command” in Chapter 9.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

2
Creating a Floorplan 2
This chapter describes how to create and refine a floorplan from an existing netlist or
floorplan description. The floorplan describes the size of the core; the shape and placement
of standard cell rows and routing channels; standard cell placement constraints; and the
placement of peripheral I/O, power, ground, corner, and filler pad cells.
• Supported Types of Floorplans
• Preparing the Design
• Initializing the Floorplan
• Refining the Floorplan
• Adjusting the I/O Placement
• Saving the Floorplan Information
• Reading In an Existing Floorplan
• Copying a Floorplan From Another Design
2-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Supported Types of Floorplans

The IC Compiler tool supports different floorplan methodologies to meet the requirements of
your design. The channeled, abutted, and narrow-channel floorplan methodologies are
described in the following sections.
• Channeled Floorplans
• Abutted Floorplans
• Narrow-Channel Floorplans
Channeled Floorplans
Channeled floorplans contain spacing between blocks for the placement of top-level macro
cells, as shown in the floorplan example in Figure 2-1.
Figure 2-1 Channeled Floorplan
Abutted Floorplans
In the abutted floorplan methodology, blocks are touching and the tool does not allocate
space for macro cell placement between blocks. Designs with abutted floorplans do not
require top-level optimization, as all logic is pushed down into the blocks. However, abutted
floorplans might require over-the-block routing to meet design requirements. This floorplan
style also requires more attention to feedthrough management. Routing congestion might
also become an issue for abutted floorplan designs. An example of an abutted floorplan is
shown in Figure 2-2.
Chapter 2: Creating a Floorplan

Supported Types of Floorplans 2-2
Figure 2-2 Abutted Floorplan
Narrow-Channel Floorplans
The narrow-channel floorplan methodology provides a balance between the channeled
floorplan and abutted floorplan methodologies. You can abut certain blocks in the design
where top-level cells are not needed. In other areas, you can reserve a channel between
certain blocks for top-level clock routing or other special purpose cells. An example of a
narrow-channel floorplan is shown in Figure 2-3.
Figure 2-3 Narrow-Channel Floorplan

Supported Types of Floorplans 2-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Preparing the Design

Before initializing the floorplan, you must read the design netlist and create unique instances
of any multiply instantiated modules. For more information about this operation, see the IC
Compiler Implementation User Guide. After reading the design, you must prepare the power
and ground ports and set the constraints for the design.
• Connecting Power and Ground Ports
• Adding Power, Ground, and Corner Cells
• Setting the I/O Pad Constraints
• Setting the Pin Constraints
• Saving the Pin and Pad Constraints
• Reading an Existing Pad and Pin Constraints File
• Reporting the Pad and Pin Constraints
• Removing the Pad and Pin Constraints
Connecting Power and Ground Ports

Use the derive_pg_connection command to create logical connections between power
and ground pins on standard cells and macros and the power and ground nets in the design.
For more information about the derive_pg_connection command, see “Creating Logical
Power and Ground Connections” in the IC Compiler Implementation User Guide.
Adding Power, Ground, and Corner Cells

Physical-only cells for power, ground, and corner placement might not be part of the
synthesized netlist and must be added to the design. Use the create_cell command to
add a leaf or hierarchical cell to the current design.
create_cell
cell_list
[reference_name]
[-view view_name]
[-freeze_silicon]
[-hierarchical]

Preparing the Design 2-4
Setting the I/O Pad Constraints

Before initializing the floorplan, you can create placement and spacing settings for I/O pads
by using the set_pad_physical_constraints command.
set_pad_physical_constraints
objects | -pad_name pad_name
[-side side_number]
[-order order_number]
[-offset offset_distance]
[-orientation reflect | optimizeReflect]
[-min_left_iospace min_space_left]
[-min_right_iospace min_space_right]
[-chip_level_distance {keyword_value_pairs}]
[-lib_cell]
[-lib_cell_orientation {l_orient t_orient r_orient b_orient}
This command specifies the pad cell ordering, orientation, placement side, offset from die
edge, and pad-to-pad spacing for each I/O pad. After setting the constraints with the
set_pad_physical_constraints command, the create_floorplan command places the
I/O pad cells accordingly. The constraints are stored in the Milkyway database when you
save the design.
The create_floorplan command places constrained pads first. Any unconstrained pads
are placed next, using any available pad location. The tool does not place unconstrained
pads between consecutively ordered constrained pads.
The initialize_rectilinear_block command places pads based on constraints set by
using the set_pad_physical_constraints command, as well as pins based on
constraints set by using the set_pin_physical_constraints command. The tool first
checks that the constraints set by both commands are correct. If no constraint errors exist,
the tool places the pins and then places the pads.
Note:
Pins and pads cannot be placed on the same side of a block created by using the
initialize_rectilinear_block command.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The following example script portion describes two corner pad locations and several I/O pad
locations for the floorplan.
Example 2-1 Pad Constraints Script Example
create_cell {cornerll cornerlr cornerul cornerur} cornercell
create_cell {vss1left vss1right vss1top vss1bottom} vsscell
# additional create_cell commands not shown
set_pad_physical_constraints -pad_name "cornerul" -side 1

set_pad_physical_constraints -pad_name "cornerur" -side 2
# additional corner pad constraints not shown
set_pad_physical_constraints -pad_name "pad_iopad_0" -side 1 -order 1

set_pad_physical_constraints -pad_name "pad_iopad_1" -side 1 -order 2
# additional left side pad constraints not shown
set_pad_physical_constraints -pad_name "pc_be_iopad_0" -side 2 -order 1

set_pad_physical_constraints -pad_name "pc_be_iopad_1" -side 2 -order 2
# additional top side pad constraints not shown
set_pad_physical_constraints -pad_name "sdram_A_iopad_0" -side 3 -order 1

set_pad_physical_constraints -pad_name "sdram_A_iopad_1" -side 3 -order 2
# additional right side pad constraints not shown
set_pad_physical_constraints -pad_name "CK_iopad" -side 4 -order 1

set_pad_physical_constraints -pad_name "CKn_iopad" -side 4 -order 2
# additional bottom side pad constraints not shown
Figure 2-4 shows the floorplan created by these constraints.

Figure 2-4 Floorplan With Pad Placement
Setting the Pin Constraints

You can use the set_pin_physical_constraints command to set constraints on
individual pins or nets. Use the set_fp_pin_constraints command to set global
constraints for a block. If a conflict arises between the individual pin constraints and the
global pin constraints, the individual pin constraints have higher priority. The constraints are
stored in the Milkyway database. For more information about setting pin constraints with the
set_pin_physical_constraints command, see “Specifying Constraints for Individual
Pins” in Chapter 11.
Saving the Pin and Pad Constraints

You can save the current pin and pad constraints for your design with the
write_pin_pad_physical_constraints command, or by choosing Floorplan > Write Pin/
Pad Physical Constraints in the GUI.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
write_pin_pad_physical_constraints
[-library lib_name]
[-cell cell_name]
[-constraint_type side_only | side_order | side_location]
[-pin_only | -pad_only]
[-objects object_list]
file_name
This command creates a constraints file that contains the

set_pin_physical_constraints and set_pad_physical_constraints commands that
you can use to reapply pin and pad constraints. The positional information for the pins and
pads is based on their current location in the design.
Reading an Existing Pad and Pin Constraints File

Use the read_pin_pad_physical_constraints command (or choose Floorplan > Read
Pin/Pad Physical Constraints in the GUI) to read a file that contains the
set_pin_physical_constraints and set_pad_physical_constraints commands. The
read_pin_pad_physical_constraints command applies the constraints to the current
design or to another design that you specify.
read_pin_pad_physical_constraints
[-append]
[-cell name]
constraints_file
The constraints defined in the file can either remove the current constraints or append to
them, based on the behavior you choose. For example, if physical constraints for pin A are
specified and you do not define any constraints for pin A in the constraints file, the
read_pin_pad_physical_constraints command removes the existing physical
constraints on pin A by default. To maintain the existing constraints and append new
constraints contained in the constraints file, specify the -append option (or click the
“Append” check box in the GUI).
Reporting the Pad and Pin Constraints

Use the report_pin_pad_physical_constraints command to display a list of
set_pin_physical_constraints and set_pad_physical_constraints commands that
define the pin and pad constraints for the current design.
report_pin_pad_physical_constraints
[-cell name]
[-pin_only | -pad_only | -chiplevel_pad_only]
[objects]

You can report only pin constraints, only pad constraints, only chip-level pad constraints, or
all constraints depending on the command options you specify.
Removing the Pad and Pin Constraints

Use the remove_pin_pad_physical_constraints command to remove all constraints
previously set by using the set_pin_physical_constraints and
set_pad_physical_constraints commands.
remove_pin_pad_physical_constraints
[-cell name]
[-pin_only | -pad_only | -chiplevel_pad_only]
[objects]
You can remove only pin constraints, only pad constraints, only chip-level pad constraints,
or all constraints based on the command options you specify. You can also remove
constraints from a design other than the current design.
Initializing the Floorplan

After setting constraints, you can create the initial floorplan. The floorplan can be a
rectangular or rectilinear shape.
• Creating a Rectangular Floorplan
• Creating a Simple Rectilinear Floorplan
• Creating a Complex Rectilinear Floorplan
Creating a Rectangular Floorplan

Use the create_floorplan command (or choose Floorplan > Create Floorplan in the GUI)
to define a rectangular chip boundary and periphery based on aspect ratio, width and height,
or number of cell rows. The command also places I/O pad and corner cells based on the
constraints you defined by using set_pin_physical_constraints commands.

Initializing the Floorplan 2-9
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
create_floorplan
[-bottom_io2core distance]
[-control_type aspect_ratio | width_and_height | boundary]
[-core_aspect_ratio ratio]
[-core_utilization ratio]
[-flip_first_row]
[-keep_io_place]
[-keep_macro_place]
[-keep_std_cell_place]
[-left_io2core distance]
[-min_pad_height]
[-no_double_back]
[-pad_limit]
[-right_io2core distance]
[-start_first_row]
[-top_io2core distance]
[-use_vertical_row]
The following examples are created by using different options with the create_floorplan
command. Figure 2-5 shows a floorplan created by using the create_floorplan command
with no options.
icc_shell> create_floorplan
Figure 2-5 Floorplan With No Options Specified
Figure 2-6 shows a floorplan created by using the -control_type aspect_ratio option.
The following example shows the complete create_floorplan command. These two

options set the aspect ratio for the design. In this example, the aspect ratio is 2.0, which
creates a floorplan with a height equal to twice the width.
icc_shell> create_floorplan -control_type aspect_ratio \
-core_aspect_ratio 2.0
Figure 2-6 Floorplan With Aspect Ratio of 2.0
Figure 2-7 shows the first few rows of a floorplan created by using the create_floorplan
command with the -start_first_row option. The -start_first_row option begins row
pairing at the bottom of the core area.
icc_shell> create_floorplan -start_first_row

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 2-7 Floorplan With Row Pairing at the Core Bottom

STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
STANDARDCELLROW
command with the -flip_first_row option. The -flip_first_row option flips the first
row at the bottom of the floorplan.
icc_shell> create_floorplan -flip_first_row
Figure 2-8 Floorplan With First

STANDARD CELLRow
ROW Flipped
STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
command with the -no_double_back option. The -no_double_back option prevents
flipping or pairing of standard cell rows.
icc_shell> create_floorplan -no_double_back

Figure 2-9 Floorplan With No Row Flipping

STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
ROUTINGCHANNEL
STANDARDCELLROW
command with the -use_vertical_row option. The -use_vertical_row option creates
standard cell rows in a vertical orientation.
icc_shell> create_floorplan -use_vertical_row
Figure 2-10 Floorplan With Vertical Rows

STANDARDCELLROW
WORLLECDRADNATS
STANDARDCELLROW
WORLLECDRADNATS
STANDARDCELLROW
WORLLECDRADNATS
STANDARDCELLROW
Figure 2-11 shows a zoomed-in view of a floorplan created by using the create_floorplan
command with the -bottom_io2core and -left_io2core options. These options set the
distance between the core and the pad cells on the bottom and left sides of the die.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
icc_shell> create_floorplan -core_utilization 0.8 \

-left_io2core 50 -bottom_io2core 100
Figure 2-11 Floorplan With I/O Pad to Core Spacing
Creating a Simple Rectilinear Floorplan

Use the initialize_rectilinear_block command (or choose Floorplan > Initialize
Rectilinear Block in the GUI) to create L-shaped, T-shaped, U-shaped, or cross-shaped
rectilinear blocks.

initialize_rectilinear_block
[-control_type ratio | length]
[-core_side_dim { side_a side_b side_c
side_d [side_e side_f]}]
[-core_utilization ratio_val]
[-flip_first_row]
[-keep_io_place]
[-keep_macro_place]
[-keep_std_cell_place]
[-no_double_back]
[-orientation N | W | S | E ]
[-row_core_ratio ratio_val]
[-shape L | T | U | X]
[-start_first_row]
[-use_current_boundary]
[-use_vertical_row]
You can vary the edge dimensions and rotation by specifying command options. The
initialize_rectilinear_block command shares several options with the
create_floorplan command; for more information, see “Creating a Rectangular
Floorplan” on page 2-9. For complex rectilinear floorplans, use the create_boundary
command with the initialize_rectilinear_block command, as described in “Creating
a Complex Rectilinear Floorplan” on page 2-19.
The initialize_rectilinear_block command honors constraints set by using the
set_pad_physical_constraints and set_pin_physical_constraints commands. Use
these two commands to restrict the location of pins and pads on the periphery of the
floorplan. Note that pins and pads cannot be placed on the same side of a block created by
using the initialize_rectilinear_block command. For more information about the
set_pad_physical_constraints command, see “Setting the I/O Pad Constraints” on
page 2-5. For more information about the set_pin_physical_constraints command,
see “Setting the Pin Constraints” on page 2-7.
Figure 2-12 shows a floorplan created by using the initialize_rectilinear_block
command with the -shape T option, which creates a T-shaped rectilinear block.
icc_shell> initialize_rectilinear_block -shape T

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 2-12 T-Shaped Rectilinear Block

command with the -shape L option, which creates an L-shaped rectilinear block.
icc_shell> initialize_rectilinear_block -shape L
Figure 2-13 L-Shaped Rectilinear Block


command with the -shape X option, which creates a cross-shaped rectilinear block.
icc_shell> initialize_rectilinear_block -shape X
Figure 2-14 Cross-Shaped Rectilinear Block

command with the -shape T and -orientation S options, which creates a T-shaped
rectilinear block that is rotated 180 degrees.
icc_shell> initialize_rectilinear_block -shape T -orientation S

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 2-15 T-Shaped Rectilinear Block Rotated 180 Degrees

command with the -shape, -control_type ratio, and -core_side_dim options. The
following command creates a T-shaped floorplan with a base section three times longer than
the top section. For more information about which dimension argument controls which edge,
see the man page or the graphic in the dialog box in the GUI.
icc_shell> initialize_rectilinear_block -shape T -control_type ratio \
-core_side_dim { 1 1 3 1 3 1}

Figure 2-16 T-Shaped Rectilinear Built Using User-Specified Dimensions
Creating a Complex Rectilinear Floorplan

You can create complex rectilinear floorplans by using the create_boundary command.
create_boundary
[-coordinate rectangle |
-poly {point point ...} | -by_terminal]
[-core]
[-left_offset l_offset]
[-right_offset r_offset]
[-top_offset t_offset]
[-bottom_offset b_offset]
[design | -lib_cell_type type]
Use the create_boundary command together with the initialize_rectilinear_block

command. The create_boundary command defines a floorplan based on a simple
rectangle or a more complex shape based on the points of a polygon.
To create a complex rectilinear floorplan, define the perimeter by using the
create_boundary command. Next, use the initialize_rectilinear_block
-use_current_boundary command to initialize the floorplan using your boundary
specification.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 2-17 shows a floorplan created by using the create_boundary command and the
initialize_rectilinear_block -use_current_boundary command.
icc_shell> create_boundary -poly {{0 0} {0 3000} {1000 3000} \
{1000 2000} {2000 2000} {2000 3000} {3000 3000} {3000 0} \
{2000 0} {2000 1000} {1000 1000} {1000 0}}
icc_shell> initialize_rectilinear_block -use_current_boundary
Figure 2-17 H-Shaped Floorplan
Refining the Floorplan

After creating a floorplan, you can refine the floorplan with the adjust_fp_floorplan
command or by making manual adjustments by using the tools in the GUI.
• Adjusting the Floorplan
• Manually Modifying the Floorplan
Adjusting the Floorplan

After you have created the floorplan by using the create_floorplan command or the
initialize_rectilinear_block command, you can make adjustments by using the
adjust_fp_floorplan command. The adjust_fp_floorplan command supports many
of the same arguments as the create_floorplan command.

Refining the Floorplan 2-20
adjust_fp_floorplan
[-core_aspect_ratio ratio]
[-core_height height]
[-core_utilization utilization]
[-core_width width]
[-die_height height]
[-die_origin {x y}]
[-die_width width]
[-fc_in_core number | -fc_periphery number]
[-flip_first_row true | false]
[-maintain_placement]
[-min_pad_height true | false]
[-no_double_back true | false]
[-number_rows rows]
[-remove_filler_io]
[-row_core_ratio ratio]
[-sm_utilization utilization]
[-start_first_row true | false]
[-use_vertical_row true | false]
Figure 2-18 shows a floorplan that was initialized and modified by using the following
commands.
icc_shell> create_floorplan -core_utilization 0.8 -left_io2core 30 \
-bottom_io2core 30 -right_io2core 30 -top_io2core 30
icc_shell> adjust_fp_floorplan -use_vertical_row true -left_io2core 100 \
-bottom_io2core 300 -right_io2core 100 -top_io2core 300 \
-core_aspect_ratio 3.0
In this example, the adjust_fp_floorplan command makes the following changes to the
layout:
• Changes the row orientation to vertical
• Expands the spacing between the core and I/O pads from 30 microns to 100 microns on
the left and right
• Expands the spacing between the core and I/O pads from 30 microns to 300 microns on
the top and bottom
• Changes the core aspect ratio to 3.0

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 2-18 Adjusted Floorplan

Original Floorplan Floorplan after
adjust_fp_floorplan
Manually Modifying the Floorplan

You can perform detailed corrections to the floorplan, such as changing the die area,
modifying standard cell rows, and changing wire tracks.
• Defining the Die Area
• Removing Cell Rows
• Adding Cell Rows
• Defining the Wire Tracks
Defining the Die Area

You can redefine the die area by using the set_die_area command. This command
accepts two coordinates that define the lower-left corner and upper-right corner of the die
specified by using the -coordinate {x1 y2 x2 y2} option. The coordinate specifies the
lower-left and upper-right corner of the die. For more information about this option, see the
man page.
For example, the following command defines a new die area rectangle with a lower-left
corner at {0 0} and an upper-right corner at {3000 3000}. The get_attribute command
confirms the die area set by the set_die_area command.

icc_shell> set_die_area -coordinate {0 0 3000 3000}

1
icc_shell> get_attribute [get_die_area] bbox
{0.000 0.000} {3000.000 3000.000}
Removing Cell Rows

You can remove cell rows from the floorplan by using the cut_row command (or by
choosing Floorplan > Cut Site Row in the GUI).
cut_row
[-all | -within {coordinates}
This command removes all cell rows in the design or only the rows in the specified area. For
example, the following command removes the cell rows in the die area bounded by the
coordinates {0 0} and {1000 1000}.
icc_shell> cut_row -within {{0 0} {1000 1000}}
1
Adding Cell Rows

You can add cell rows to the floorplan by using the add_row command (or by choosing
Floorplan > Add Site Row in the GUI).
add_row
-within { {llx lly} {urx ury} } |
{ {x1 y1} {x2 y1} {x2 y2} ... {x1 y1} }
[-allow_overlap]
[-bottom_offset bottom_offset]
[-direction horizontal | vertical]
[-flip_first_row]
[-left_offset left_offset]
[-minimal_channel_height channel_height]
[-no_double_back]
[-no_start_from_first_row]
[-right_offset right_offset]
[-snap_to_orthogonal_row_direction existing_row | wire_track | none]
[-snap_to_row_direction wire_track | tile_width | none]
[-tile_name tile_name]
[-top_offset top_offset]
The command inserts cell rows based on the configuration options you provide and
implements the rows based on the current floorplan. If you specify a design area that already
contains rows, the add_row command does not create an overlap condition with the existing
rows.
To create cell rows in a rectangular region, use the -within option and specify the lower-left
and upper-right points of the rectangle. To create cell rows in a rectilinear region, use the
-within option and specify the points that define the boundary of the region. To align the

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
cell rows, use the -snap_to_row_direction and -snap_to_orthogonal_row_direction

options.
By default, new rows snap to the wire track in the direction of the row, and snap to existing
rows in the orthogonal direction. If there are no existing rows with the same unit tile, the new
rows snap to the wire track in the orthogonal direction instead. If there are rows that exist in
the area specified by the -within option, the tool issues an error message and exits the
command. You can create overlapping rows by specifying the -allow_overlap option to
the add_row command. For more information, see the man page.
For example, the following commands remove the cell rows from the die area bounded by
the coordinates {375.770 375.770} and {1778.790 1000.200}, and then add new rows
with the -no_double_back option.
icc_shell> cut_row -within {{375.770 375.770} {1778.790 1000.200}}
1
icc_shell> add_row -within {{375.770 375.770} {1778.790 1000.200}} \
-no_double_back
Info: 138 rows are added.
1
Figure 2-19 shows the section of floorplan modified by using the add_row command. Note
that the rows in the bottom half of the cutout are inserted by using the add_row
-no_double_back command, while the rows in the top half of the cutout were originally
inserted without using the -no_double_back option.
Figure 2-19 Floorplan After Reinserting Rows

Defining the Wire Tracks

You can create routing tracks in the floorplan by using the create_track command (or by
choosing Floorplan > Create Track in the GUI).
create_track
-layer layer
[-space track_pitch]
[-count number_of_tracks]
[-coord start_x_or_y]
[-dir X | Y]
[-bounding_box track_boundary_box]
[-width value]
[-reserved_for_width true | false]
[-nets nets]
Figure 2-20 shows a floorplan created with the create_track command. In this example,
the remove_track command removes all existing routing tracks, and then the
create_track command creates routing tracks on METAL3 in the preferred direction with
a pitch of 0.5. The report_track command reports the routing track direction, startpoint,
number of tracks, and pitch for each set of routing tracks in the design.
icc_shell> remove_track -all
1
icc_shell> create_track -layer METAL3 -space 0.5
1
icc_shell> report_track
****************************************
Report track
Design : TEST
Version: F-2011.09
Date : Mon Aug 1 14:50:01 2011
****************************************
Layer Direction Start Tracks Pitch Attr
------------------------------------------------------------------------
Attributes :
usr : User defined
def : DEF defined
METAL3 Y 0.250 4307 0.500 usr
1

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 2-20 Floorplan After Inserting Wire Tracks
Adjusting the I/O Placement

You can refine the spacing and relative locations of the I/O pads in your design by using the
adjust_fp_io_placement command (or by choosing Floorplan > Adjust I/O Placement in
the GUI).
adjust_fp_io_placement
[-side l | r | t | b]
[-spacing float]
[-pitch float]
[-offset float]
[-undo]
[list of IO cells]
The adjust_fp_io_placement command operates on one side of the chip at a time and
supports an undo function that reverts the design to its previous state. Figure 2-21 shows a
floorplan adjusted by using the adjust_fp_io_placement command. In this example, the
original pad spacing is 30 microns as specified by using the
set_pad_physical_constraints -min_left_iospace command. The
adjust_fp_io_placement -side l -spacing 1 command changes the spacing between
the I/O pads to 1 micron for pads on the left side of the chip.

Adjusting the I/O Placement 2-26
icc_shell> adjust_fp_io_placement -side l -spacing 1

Information: Adjusting placement of IO cells on specified sides ( left )
Information: Using spacing constraint, spacing = 1.000000 microns.
Information: packing IOs to the center.
1
Figure 2-21 Floorplan With Adjusted I/O Pads
Saving the Floorplan Information

After you create the floorplan, you can save a Tcl script that describes the floorplan by using
the write_floorplan command or save a DEF file by using the write_def command.
• Writing the Floorplan File
• Writing the Floorplan to a DEF File
• Floorplan Physical Constraints in Design Compiler
Writing the Floorplan File

You can write the current floorplan to a Tcl file by using the write_floorplan command (or
by choosing Floorplan > Write Floorplan in the GUI).

Saving the Floorplan Information 2-27
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
write_floorplan
[-all]
[-cell design_name]
[-create_bound]
[-no_bound]
[-no_create_boundary]
[-no_placement_blockage]
[-no_plan_group]
[-no_route_guide]
[-no_voltage_area]
[-objects object_collection]
[-pin_guide]
[-placement {placement_info_types} [-create_terminal]]
[-preroute]
[-user_shape]
[-net_shape]
[-row]
[-sm_all]
[-sm_bound]
[-sm_cell_row]
[-sm_placement {placement_info_types}]
[-sm_placement_blockage]
[-sm_plan_group]
[-sm_preroute]
[-sm_route_guide]
[-sm_track]
[-sm_voltage_area]
[-track]
file_name
The write_floorplan command creates a Tcl file that contains objects, placement, and
attribute information for I/Os, terminals, standard cells, hard macros, and routing tracks in
the floorplan. The Tcl file is used to rebuild the floorplan by using the read_floorplan
command. You can control the information written to the Tcl file by using command options.
The command does not write relative placement group and relative placement keepout
information.
The write_floorplan command does not write standard cell placement information in the
floorplan exploration flow if the database is created by the Design Compiler tool in
topographical mode. The write_floorplan command issues the following message to
alert you that standard cell placement information is not written to the floorplan Tcl script:
Warning: Standard cell placement output was suppressed in write_floorplan
because this is a DCG database (APL-083)
The following example uses the write_floorplan command with no options to create die
area information.
icc_shell> write_floorplan floorplan_1.tcl
1

Writing the Floorplan to a DEF File

You can save the current floorplan to a DEF file by using the write_def command (or by
choosing File > Export > Write DEF in the GUI).
write_def
-output output_file_name
[-version def_version]
[-unit conversion_factor]
[-compressed]
[-rows_tracks_gcells]
[-vias]
[-all_vias]
[-nondefault_rule]
[-lef lef_file_name]
[-regions_groups]
[-components]
[-macro]
[-fixed]
[-placed]
[-pins]
[-blockages]
[-specialnets]
[-notch_gap]
[-pg_metal_fill]
[-nets]
[-routed_nets]
[-diode_pins]
[-floating_metal_fill]
[-scanchain]
[-no_legalize]
[-verbose]
The write_def command writes the floorplan information, including the design netlist,
layout, and constraints, to a DEF file. The following example uses the write_def command
to write the floorplan to a DEF file.
icc_shell> write_def -version 5.6 -vias -all_vias -pins -nets \
-diode_pins -specialnets -notch_gap -pg_metal_fill -scanchain \
-no_legalize -output "chip.def"
Floorplan Physical Constraints in Design Compiler

To improve timing, area, and power correlation between the Design Compiler and IC
Compiler tools, you can read your mapped Design Compiler netlist into the IC Compiler tool,
create a basic floorplan, export the floorplan, and read the floorplan back into the Design
Compiler tool. The write_def and write_floorplan commands write floorplan

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
information that can be used to create a floorplan that supports this flow. The following
sections describe the commands and options necessary to write the floorplan file by using
the write_def and write_floorplan commands.
Extracting Physical Constraints

To export floorplan information from the IC Compiler tool for use in Design Compiler
topographical mode, you can use the write_def command to export physical design data
and write the data to a Design Exchange Format (DEF) file. You can read the DEF file into
Design Compiler in topographical mode. The following example uses the write_def
command to write physical design data to the floorplan_for_DC.def file.
icc_shell> write_def -version 5.7 -rows_tracks_gcells -macro -pins \
-blockages -specialnets -vias -regions_groups -verbose \
-output floorplan_for_DC.def
Exporting Physical Constraints

To export floorplan information from the IC Compiler tool for use in Design Compiler
topographical mode, you can use the write_floorplan command. The write_floorplan
command writes a Tcl script that you read into Design Compiler topographical mode to
re-create elements of the floorplan of the specified design. The following example uses the
write_floorplan command to write out all placed standard cells to a file called
floorplan_for_DC.tcl.
icc_shell> write_floorplan -placement {io hard_macro soft_macro} \
-create_terminal -row -create_bound -preroute floorplan_for_DC.tcl
Reading In an Existing Floorplan

You can read existing floorplan data saved in a DEF file or a Synopsys Tcl file.
• Reading DEF Files
• Reading Floorplan Files
Reading DEF Files

To read a DEF file, use the read_def command (or choose File > Import > Read DEF in the
GUI).

Reading In an Existing Floorplan 2-30
read_def
[-check_only]
[-enforce_scaling]
[-no_incremental]
[-verbose]
[-turn_via_to_inst]
[-inexactly_matched_via_to_inst]
[-lef lef_file_names]
[-snet_no_shape_as_user_enter]
[-snet_no_shape_as_detail_route]
[-preserve_wire_ends]
def_file_names
The following command reads the chip.def DEF file.

icc_shell> read_def chip.def
By default, the read_def command is additive; it adds the physical data in the DEF file to
the existing physical data in the design. To replace rather than add to existing data, use the
-no_incremental option on the command line (or deselect Incremental in the dialog box in
the GUI).
To analyze the input DEF files before annotating the objects on the design, enable
check-only mode by using the -check_only option. The check-only mode provides
diagnostic information about the correctness and integrity of the DEF file. The check-only
mode does not annotate any DEF information into the Milkyway database.
icc_shell> read_def -check_only design_name.def

Reading In an Existing Floorplan 2-31
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Reading Floorplan Files

You can use the read_floorplan command to import a previously saved floorplan file. A
floorplan file is Tcl script file created by using the write_floorplan command (or by
choosing Floorplan > Write Floorplan in the GUI). For more information about creating a
floorplan file, see “Writing the Floorplan File” on page 2-27. To display each command as it
is executed, specify the -echo option. For more information about this command, see the
man page.
Note:
If the power and ground nets are not explicitly defined in your netlist, you must create the
power and ground connections by using the derive_pg_connection command before
reading the floorplan file. For more information about the derive_pg_connection
command, see “Creating Logical Power and Ground Connections” in the IC Compiler
Implementation User Guide.
The following example reads a floorplan from the chip.tcl file. The file was previously saved
by using the write_floorplan command.
icc_shell> read_floorplan chip.tcl
Copying a Floorplan From Another Design

To copy physical data from the layout (CEL) view of one design in the current Milkyway
design library to another, use the copy_floorplan command (or choose
Floorplan > Copy Floorplan in the GUI).
copy_floorplan
[-library design_library_name]
-from design_name
[-macro]
[-filler]
[-pad]
[-power_plan]
[-verbose]
Specify the design from which to copy the physical data by using the -from option (or by
specifying the design name in the “From cell” box in the GUI). The following example copies
the floorplan from the design named design1.
icc_shell> copy_floorplan -from design1

Copying a Floorplan From Another Design 2-32
This command copies the following physical data:

• General floorplan data
This includes information such as the design boundary, the core boundary, the
placement rows, the placement sites, and the wire tracks.
• Obstructions
These include information such as placement blockages (soft and hard), keepout
margins (soft and hard), all route guides, and move bounds (soft and hard).
• Cell instances
These include fixed, soft-fixed, and placed cells (such as macros, pads, and preplaced
standard cells), as well as physical cells (such as corner pads, filler cells, and via cells).
Note:
All cell instances are copied; there is no way to select specific cell types to copy.
• Preroutes
These include power and ground preroutes, clock preroutes, signal preroutes, and
shielding.
• Power net connections
• Plan groups
• Macro cell placement (optional)
To copy the macro cell placement information, use the -macro option (or choose “Copy
macro placement” in the GUI).
• I/O pad placement (optional)
To copy the I/O pad placement information, use the -pad option (or choose “Copy IO pad
placement” in the GUI).
• Filler cell placement (optional)
To copy the filler cell placement information, use the -filler option (or choose “Copy
Filler cells placement” in the GUI).
• Power plan (optional)
To connect the power nets and copy the power planning information, use the
-power_plan option (or choose “Connect power net and copy power planning data” in
the GUI).

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The command does not copy the following data:

• SCANDEF
• Voltage areas and power domains
• Data from the FILL view, such as floating metal fill or notch and gap
By default, the copy_floorplan command overwrites the existing physical data in the
design. To avoid this, use the -incremental option (or choose “Incremental
(non-overwriting) in the GUI).
Note:
You must ensure netlist consistency between the designs. The command does not
perform netlist consistency checks during the copy process.
The copy_floorplan -incremental command copies the rows from the source cell to
the destination cell, even if there are existing rows in the destination cell.
For detailed information about the copy_floorplan command, see the man page.

3
Automating Die Size Exploration 3
This chapter describes how to use MinChip technology in the IC Compiler tool. MinChip
technology applies automation to determine the smallest routable die size for your design
while maintaining the relative placement of hard macros and I/O cells. You can enable
power network synthesis to ensure that the floorplan meets voltage drop requirements. The
input is a flat Milkyway CEL view.
MinChip technology uses the estimate_fp_area command to iterate through different
design size estimates. If the floorplan can be routed, the estimate_fp_area command
finds the smallest routable die size. If the initial floorplan cannot be routed, the
estimate_fp_area command produces a routable floorplan with a larger core area.

• MinChip Technology Flow
• Routing Congestion Considerations for MinChip Technology
• Power Network Considerations for MinChip Technology
• Macro Placement Considerations for MinChip Technology
• Macro Blockage Considerations for MinChip Technology
• Floorplan and I/O Cell Considerations for MinChip Technology
• MinChip Technology Command and GUI
• Using MinChip Technology With Multivoltage Designs
3-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
MinChip Technology Flow

Figure 3-1 shows design flow using MinChip technology, and the steps that occur inside the
flow.
Figure 3-1 MinChip Technology Flow
Design Data
estimate_fp_area
Routable?
Floorplan
Y N
Reduce Increase
size size
Trial Route
Place design
Optimize Design
Route power
MinChip
Global route
Design Closure
N
Reason to stop?
Route
Y
Done
Tapeout
Chapter 3: Automating Die Size Exploration

MinChip Technology Flow 3-2
The estimate_fp_area command performs the following steps in the MinChip technology
flow:
1. Estimates the core size and shape for a given core and cell utilization.
During the search for a minimal die size, filler pads and filler cells are automatically
deleted to minimize the pad-limited characteristics of the design. When the size of the die
changes, any previous placement blockages, preroutes, and routing guides are also
automatically deleted.
To ensure that the results are consistent between each design iteration, the following
settings are held constant:
❍ The original side and placement order of the I/O pads on the input design cell
❍ The relative placement of the hard macros
❍ The shape (aspect ratio) of the core area
2. Places all the design cells.
For a given core size, the command performs virtual flat placement in incremental mode
to place all the design cells.
3. Performs global routing on the design.
After cell placement, the command routes the design as follows:
❍ Performs a fast, virtual route. The command estimates the wire length and calculates
the routing resources.
❍ Performs prototype global routing until the specified global route cell overflow
percentage is reached.
❍ Performs prototype global routing to report that the design is unroutable when local
hot spots cause a very long runtime.
4. Analyzes the routing.
After the design is routed, the tool performs routing analysis. The tool reports the number
and percentage of nets routed, and the overall global route cell overflow percentage
when a design is unroutable.
The estimate_fp_area command stops processing the design when any of the following
occur:
• The routing target is met.
• The utilization bounds are exceeded.
• Overlaps of hard macros would be formed.

MinChip Technology Flow 3-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• The IR drop is exceeded.

• The design is pad limited.
Routing Congestion Considerations for MinChip Technology

To produce the best results for chip size reduction, make sure that your design is routable,
can achieve timing closure, and the netlist is stable with no major logic changes expected in
the gate-level netlist. All design rule violations should be corrected before running MinChip.
You should apply MinChip technology only to netlists and floorplans that have completed
implementation and optimization in the IC Compiler tool. If the final netlist is larger than the
netlist input to MinChip technology, it might not fit the optimized floorplan. MinChip
technology supports both rectangular and rectilinear floorplans.
If your design is unroutable, MinChip technology increases the size of the design. You
should correct any routing congestion issues in your design, such as macros overlapping
other macros or existing power routing that makes pins inaccessible, before running
MinChip.
Power Network Considerations for MinChip Technology

Run power network synthesis on the existing floorplan before running the
estimate_fp_area command to ensure that all the power network synthesis options are set
properly.
To run power network synthesis in the MinChip technology flow, specify the
-power_net_names and -ir_drop_value options to the estimate_fp_area command.
Because the power mesh and rings consume routing resources, you can achieve a better
estimate of die size by creating the power network in the MinChip technology flow. The
command creates a two-layer power mesh on the uppermost layers that meets the specified
IR drop target. If you do not specify an IR drop target, the default is 10 percent of the supply
voltage.
If your design requires a custom power structure, write a custom power network synthesis
script containing the synthesize_fp_rail command and run the script using the
-run_pns_script option of the estimate_fp_area command. The script creates the
custom power structure according to the specified width, pitch, and offset of the core rings,
block rings, and power straps. Absolute coordinates should not be used in the custom power
network synthesis script, except for virtual power pads. The virtual pad locations are scaled
appropriately by the estimate_fp_area command for each design iteration. You can
specify either the -run_pns_script option or the -power_net_names option, but not both.
If your power network synthesis script contains virtual power pads, the pad locations are
scaled appropriately by the estimate_fp_area command.

Routing Congestion Considerations for MinChip Technology 3-4
Use a script to run the prerouter to create power and ground connections to the power and
ground pins of standard cells in your design. Run the prerouter after you run power network
synthesis. This is important if you use power network synthesis to form a mesh on the
uppermost layers. The prerouter creates stacked vias to connect the METAL1 layer
preroutes to the upper layer mesh. To run the preroute script using the estimate_fp_area
command, specify the script name with the -run_preroute_script option. Running the
estimate_fp_area command with the -run_preroute_script option accounts for
METAL1 routing resources and stacked vias during die size reduction.
If your design contains hard macros with power and ground rings, MinChip technology can
compress the space between adjacent hard macros by merging the power and ground rings
of the adjacent hard macros.
Macro Placement Considerations for MinChip Technology

The estimate_fp_area command maintains the relative location, alignment, horizontal and
vertical ordering of all fixed macros. You can also reduce the die or core size until the fixed
macros abut. The relative location of unfixed macros might change in the MinChip
technology flow, therefore, you should fix the placement of any critical macros before
running MinChip technology.
If there are standard cells with fixed placement in your floorplan, the estimate_fp_area
command might place hard macros on top of the standard cells. Unfix all standard cells
before running the command.
The set_fp_placement_strategy -sliver_size command specifies the minimum
channel size that is allowed to be populated by standard cells. If the distance between two
objects (core edges, blockages, or macros) is less than or equal to the specified sliver size
before running the estimate_fp_area command, this distance is not reduced by the
estimate_fp_area command. By default, the sliver size is 0.0 and the placer can place
standard cells in any channel that has room. For more information on creating channels
between macros, see “Sliver Size” on page 6-20.
Macro Blockage Considerations for MinChip Technology

Macro blockages are placement blockages assigned to macros. If at least 70 percent of the
blockage area covers a macro, the estimate_fp_area command assigns the blockage to
the macro. As the estimate_fp_area command iterates and produces different die size
results, macro blockages move together with assigned macros. If a blockage covers two or
more macros, it is randomly assigned to one macro. If macro padding cannot be used, you
should create a hard macro blockage over each macro rather than one large blockage over
a set of macros. The estimate_fp_area command might create blockage overlaps to
reduce the die size, but does not create macro overlaps.

Macro Placement Considerations for MinChip Technology 3-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The estimate_fp_area command honors both soft and hard blockages when you specify
the -keep_blockages option. Blockages can be assigned to an edge or macro based on the
relationship between the blockage and the edge or macro. You should delete all
nonessential blockages before running the estimate_fp_area command. Use macro
padding to create space if necessary.
A blockage that extends over an entire edge of the core area is called an edge blockage. In
some cases, edge blockages are used to reserve space for power rings and prevent cell
placement near the core boundary. For example, consider a design that requires a core ring
on the METAL1 and METAL2 layers as part of the power mesh. An edge blockage prevents
standard cell placement near the core boundary and allows the estimate_fp_area
command to create the power rings after cell placement. In the MinChip technology flow, the
relative placement of edge blockages is maintained in relation to the core area.
For most designs, the minimum allowable macro spacing can be achieved by using the
set_keepout_margin command and the set_fp_placement_strategy -sliver_size
strategy setting. Placement blockages are not required to maintain separation between
macros in the MinChip technology flow. Note that the estimate_fp_area command honors
both soft and hard placement blockages if you specify the estimate_fp_area
-keep_blockages command.
If you specify a sliver_size parameter value, and the distance between two objects, such
as macros, core edges, or blockages, is less than or equal to the sliver_size value before
running the estimate_fp_area command, this distance is maintained by the
estimate_fp_area command.
If there are no overlaps between the macro padding, and the distance between the macros
is less than or equal to the sliver_size value, the estimate_fp_area command does not
reduce the space between the hard macros.
If there are overlaps between the macro padding, and the distance between the macros is
less than or equal to the sliver_size value, the estimate_fp_area command does not
reduce the space between the hard macros, and the macro padding remains overlapped
with the other padding.
If there is no set_fp_placement_strategy -sliver_size strategy setting or keepout
margin specified for a fixed macro, and one placement blockage exists over a set of multiple
hard macros, the estimate_fp_area command abuts the macros. When you run the
estimate_fp_area command, the tool does not reduce the size of the placement blockage.
Instead, it blocks some of the core area, preventing the placement of the standard cells. If
there is a hard macro keepout, macros can be packed until the keepout region abuts.
See Also
• “Sliver Size” on page 6-20
• “Blockages, Margins, and Shielding” on page 6-40

Macro Blockage Considerations for MinChip Technology 3-6
Floorplan and I/O Cell Considerations for MinChip Technology

The estimate_fp_area command minimizes the die size by reducing the size of the
floorplan. You can constrain the floorplan by restricting the tool to use the current die width,
height, or aspect ratio. You can also specify minimum and maximum values for the width
and height. If you specify minimum width or height, the estimate_fp_area command can
create a die size with a utilization greater than 95 percent. If you specify maximum width or
height, the estimate_fp_area command can create a die size with a utilization less than 30
percent.
The estimate_fp_area command deletes I/O cells marked as type filler. Note that some
I/O cell libraries might contain pads that are marked as type filler. To ensure that the I/O
pads are not deleted, change these cell types before you run the estimate_fp_area
command.
If your design has standard cells in the core that are marked as type filler, you must
explicitly delete these before running the estimate_fp_area command.
If your design contains multiple I/O rings, the estimate_fp_area command changes the
relative locations of the inner and outer rings to reduce die area. You can specify the
-maintain_iopad_alignment option of the estimate_fp_area command to scale only the
spaces that are shared by all I/O rings on the same side of the chip. This helps maintain the
original center or edge alignments between I/O pads in the inner and outer I/O rings.
Figure 3-2 shows an example of proportional and fixed I/O pad alignment.
Figure 3-2 Maintaining I/O Alignment
Original CEL view

with multiple I/O rings Proportional I/O ring scaling Maintain I/O alignment
The image on the left is the original CEL view with multiple I/O rings. The pads between the
I/O rings are aligned. When you run the estimate_fp_area command with the default
options, the command scales the I/O rings proportionally. As a result, the alignment between
the I/O pads and the I/O rings is lost, as shown in the center image. When you run the

Floorplan and I/O Cell Considerations for MinChip Technology 3-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
estimate_fp_area command and select the Maintain I/O pad alignment option, the
command reduces the die area by eliminating unnecessary space in the I/O ring and by
maintaining the I/O alignment between the I/O rings, as shown in the image on the right.
MinChip Technology Command and GUI

You can use MinChip technology to reduce the size of your chip using the
estimate_fp_area command:
estimate_fp_area
[-acceptable_overflow ratio]
[-core_sizing_only]
[-estimate_optimization]
[-fixed_edges list_of_edges]
[-increase_area area]
[-ir_drop_value target_value]
[-keep_blockages]
[-maintain_iopad_alignment]
[-maintain_power_structure]
[-max_height max_height]
[-max_width max_width]
[-min_height min_height]
[-min_width min_width]
[-power_net_names list_of_names]
[-replace_io]
[-run_pns_script pns_script_name]
[-run_preroute_script preroute_script_name]
[-save_as name]
[-shrink_only]
[-sizing_type fixed_width | fixed_height | fixed_aspect_ratio]
For more information about the command options, see the estimate_fp_area man page.
To use the GUI layout window to run the MinChip technology flow, choose Floorplan >
MinChip. This opens the dialog box shown in Figure 3-3.

MinChip Technology Command and GUI 3-8
Figure 3-3 Estimate Area GUI
Select Variable aspect ratio, Fixed aspect ratio, Fixed width, or Fixed height to control the
dimensions and aspect ratio during successive design iterations. You can specify minimum
and maximum values for the width and height. By default, the estimate_fp_area command
allows the aspect ratio to vary.
Select Keep blockages to retain all placement blockages in the floorplan. Select Replace IO
to delete all I/O cells and replace them based on physical constraints. Select Core sizing
only to change only the core size and retain the current I/O pad placement. Select Maintain
I/O pad alignment to retain the alignment between I/O pads in different rings. I/O pads in
inner and outer pad rings can change position and become misaligned by default. Select
Estimate Optimization to automatically reserve die area for optimization purposes for
designs that are not optimized. Select Increase area to reserve a specific amount of area in
square microns for optimization or other purposes. Select Fix edges and enter one or more
integers in the box to maintain the length of one or more edges of the die boundary. The
integers correspond to edges of the die boundary; the lower left-most edge is edge number
1 and the edges numbers increase as you proceed clockwise around the die boundary.

MinChip Technology Command and GUI 3-9
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Enter a floating-point value between 0.0 and 0.25 in the Acceptable overflow box to specify
an overflow ratio of global routing cells for the entire design. Enter the target IR drop in mV
for your design in the Max allowable IR drop value box to override the default of 10 percent
of the VDD voltage value. If you enter an IR drop value, you must also specify the power and
ground net names.
Select the Automatically create script to mimic power network and Power and ground net
pairs as {pwr gnd} options, and enter the net name pairs surrounded by braces ({}) to direct
the estimate_fp_area command to create scripts to build the power and ground network.
The command writes the scripts to the pna_output directory. Select Custom PNS script, and
enter the path name to the script, to run the estimate_fp_area command using your
custom power network synthesis script. Select Preroute script and enter the path name to
the script, to run the estimate_fp_area command using your custom power network
preroute script.
In the Save as box, enter the name of the design to be created by MinChip technology to
specify a nondefault name for the new design.
Using MinChip Technology With Multivoltage Designs

MinChip technology supports designs with voltage areas. When the estimate_fp_area
command iterates through different design size estimates to find the smallest die or block
size that meets the routability target, it automatically shrinks rectangular and rectilinear
voltage area boundaries by a similar percentage, as shown in Figure 3-4.
The estimate_fp_area command shrinks the voltage area boundary by the same amount
as the top-level block or cell. The relative macro placement of the top-level hard macros as
well as the macros inside the voltage areas is maintained.
If a voltage area cannot be placed correctly because the utilization bounds are too high, the
estimate_fp_area command stops shrinking the design. It also ensures that the aspect
ratio of the voltage area changes in accordance with any changes to the aspect ratio of the
top-level block or cell.
Figure 3-4 Voltage Area Sizing

Using MinChip Technology With Multivoltage Designs 3-10
Based on the power budget requirements, each voltage area in the core area can have
different power structures, as shown in Figure 3-5. Therefore, you should use a power
network synthesis script because the default run might not generate different power
structures for different voltage areas.
Figure 3-5 Multivoltage Design Power Structures

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

4
Handling Black Boxes 4
This chapter describes the various operations you can perform with black box modules and
cells in the IC Compiler tool using a virtual flat approach to creating the floorplan.
Milkyway defines a black box as any instance in the netlist that has neither a corresponding
leaf cell in a reference library nor a netlist module defined in terms of leaf cells. A black box
can have an empty module represented in the netlist where its ports and their directions are
defined. If the black box instance in the netlist does not have a corresponding module, the
direction of the ports in the black box are defined in the Milkyway database as bidirectional.
A black box can be represented in the physical design as either a soft macro or hard macro.
A black box macro has a fixed height and width. A black box soft macro sized by area and
utilization can be shaped to best fit the floorplan.
• Black Box Flow
• Reading Netlists Containing Black Boxes
• Converting Logical Black Boxes to Physical Black Boxes
• Converting Physical Black Boxes to Logical Black Boxes
• Sizing Black Boxes by Width and Height
• Sizing Black Boxes by Content
• Creating a FRAM View For a Black Box
4-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• Constraining Routing Over Black Boxes

• Setting the Black Box Estimation Mode
• Creating Quick Timing Models for Black Boxes
• Creating Unique Cell Instances
Chapter 4: Handling Black Boxes

4-2
Black Box Flow

The black box flow includes the following steps:
Figure 4-1 Black Box Flow
Read netlist
read_verilog
Create floorplan
create_floorplan
Import black boxes

import_fp_black_boxes
Size black boxes

estimate_fp_black_boxes
Create Quick Timing Models

create_qtm_model
Uniquify the design

uniquify_fp_mw_cel
For information about creating the floorplan, see “Initializing the Floorplan” on page 2-9. The
remaining steps are described in the following sections.
Reading Netlists Containing Black Boxes

To read a Verilog netlist, use the read_verilog command.
icc_shell> read_verilog verilog_file

Black Box Flow 4-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The tool reads the Verilog netlist and assigns a black box type to each black box module.
Table 4-1 describes the different types of black box modules read by the read_verilog
command.
Table 4-1 Black Box Types
Black box black_box_type Description Example Verilog module

type attribute
Data flow DF A data flow module contains module BB_DATAFLOW (IN, OUT);
assign statements for some input [7:0] IN;
module ports; other ports output [7:0] OUT;
are not connected. assign OUT=1'b0;
endmodule
Empty Empty An empty module contains module BB_EMPTY (IN, OUT);

only port statements; there input [7:0] IN;
are no assign or tie-off output [7:0] OUT;
statements. endmodule
Feedthrough Feedthru A feedthrough module module BB_FEEDTHRU (IN, OUT);

contains assign statements; input [7:0] IN;
each input and output is output [7:0] OUT;
connected. assign OUT = IN;
endmodule
Missing Missing A missing module is not Module is not in the Verilog netlist
defined in the Verilog netlist;
you must use the
-dirty_netlist option with
the read_verilog
command to import this type
of module.
Tie-off Tie-Off A tie-off module contains module BB_TIEOFF(OUT);

only outputs with each output [7:0] OUT;
output assigned to either assign OUT=1'b0;
1’b0 or 1’b1. endmodule
When the read_verilog command detects a logical black box module, it sets the
is_logical_black_box attribute to true and the black_box_type attribute to DF, Empty,
Feedthru, Missing, or Tie-Off. You can query these attributes with the get_cells
command to identify the logical black boxes in your design. For example, to retrieve all black
box modules of type Missing, use the following command:
icc_shell> get_cells -hierarchical \
-filter "is_logical_black_box==true && black_box_type==Missing"

Reading Netlists Containing Black Boxes 4-4
Converting Logical Black Boxes to Physical Black Boxes

To use black boxes in the design planning flow, you must import them by converting them
from logical black boxes to physical black boxes. After conversion to a physical black box,
the black box module is treated as a soft macro.
Note:
After you convert the logical black boxes to physical black boxes, you must treat the
design as a hierarchical design. This means that you must use the save_mw_cel
-hierarchy command when you save the design to ensure that both the top-level
design and the black box cells are saved.
To convert the black boxes, use the import_fp_black_boxes command (or choose
Floorplan > Blackboxes > Import Blackboxes in the GUI). You must specify the list of black
boxes to convert. On the command line, you can specify the black boxes by using the
get_cells command with the is_logical_black_box and black_box_type attributes to
identify the black boxes. In the GUI, select the black box instances from the “Importable
black boxes” list in the dialog box. To create a CEL view for every black box listed in the
“Importable black boxes” list, click Select All.
For example, to create a CEL view for all empty modules, enter the following command:
icc_shell> import_fp_black_boxes [get_cells -hier \
-filter "is_logical_black_box==true && black_box_type==Empty"]
The import_fp_black_boxes command performs the following attribute changes to the

converted black box cells:
• Changes the is_logical_black_box attribute to false.
• Changes the is_physical_black_box, is_black_box, and is_soft_macro attributes
to true.
By default, a maximum of 100 black boxes can be imported at one time. If you try to import
more than the maximum number of black boxes, the import is canceled. The limit of 100
black boxes prevents you from accidentally selecting all black boxes in a script when you
might have forgotten to specify one or more reference libraries. To import more than 100
black boxes, increase the number of importable black boxes by specifying the -max_count
option or by entering the value in the Maximum number of black boxes to import text box in
the GUI.

Converting Logical Black Boxes to Physical Black Boxes 4-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The import_fp_black_boxes command sets the size for each black box. By default, the
tool creates a bounding box of 300 microns on each side for the black box. You can change
the default black box size by using one of the following methods:
• Specify the side length
To create a square boundary with a side length other than 300 microns, use the
-side_length option.
• Specify the equivalent gate count and utilization

To create a boundary based on the number of equivalent gates in the black box and a
utilization value, use the -gate_count and -utilization options. If you specify only
the -gate_count option, the tool uses the default utilization value of 0.7 to determine the
size of the black box.
Note:
By default, the IC Compiler tool uses the standard gate area of a 2-input NAND gate
as the gate-equivalent size. You can change the gate-equivalent size by using the
set_fp_base_gate command. For information about the set_fp_base_gate
command, see “Sizing Black Boxes by Content” on page 4-7.
Converting Physical Black Boxes to Logical Black Boxes

When you import a black box module, the layout window contains an instance of the
physical black box. You can use the flatten_fp_black_boxes command to remove the
physical black box instance from the top-level design in the layout window and restore the
instance to a logical black box. The CEL view for the black box is retained in the library, but
does not have any effect on the top-level design where it was flattened. After you run the
flatten_fp_black_boxes command, the logical black box continues to exist as a module
in the Verilog netlist output.
Sizing Black Boxes by Width and Height

When you convert a logical black box to a physical black box, the tool assigns a size to the
black box. You can change the size of the black box cells to provide a more accurate
boundary by using the estimate_fp_black_boxes command (or by choosing Floorplan >
Blackboxes > Estimate Blackboxes in the GUI). You can specify a boundary for the black
box, the number of gate equivalents, or the hard macro contents for the black box. You can
also specify that the shape is fixed and have the tool treat the black box as a hard macro
rather than a soft macro.
A black box that is converted to a soft macro has a CEL view and is displayed in the layout
window with a thick boundary outline. A black box that is converted to a hard macro has a
FRAM view and is displayed in the layout window with a thin boundary outline.

Converting Physical Black Boxes to Logical Black Boxes 4-6
To set the black box boundary by width and height in microns, use the -sm_size {width
height} option with the estimate_fp_black_boxes command. In the GUI, select “Soft
macro size” and enter the values in the Width and Height text boxes. By default, the
command uses a utilization value of 1.0 when you specify the -sm_size option. You can
change the utilization by using the -sm_util option with the estimate_fp_black_boxes
command.
To specify a rectilinear black box boundary, specify the coordinates in microns of the
polygon by using the -polygon option with the estimate_fp_black_boxes command. In
the GUI, select “Soft macro polygon” and enter the coordinates in the associated text box.
Specify the polygon in the following format for both the command line and the GUI:
{{x1 y1} {x2 y2} ...{xn yn} {x1 y1}}
To prevent further changes to the shape of the black box, use the -fixed_shape option
with the estimate_fp_black_boxes command, or choose “Mark as fixed shape after
estimation” in the GUI.
Sizing Black Boxes by Content

You can specify the number of gate equivalents or the hard macro contents for the black box
by using the estimate_fp_black_boxes command (or by choosing Floorplan >
Blackboxes > Estimate Blackboxes in the GUI).
To specify the hard macros contained in the black box cell, use the -hard_macros option
with the estimate_fp_black_boxes command or choose “Estimate by enclosed hard
macros” in the GUI. The tool uses the area of the specified hard macros, but not the shape,
when estimating the black box size. Specify the hard macros in a comma-separated list. You
can specify multiple instances of the same macro by appending the macro count in
parentheses after the macro reference name. For example, to specify that the alu_bb black
box contains two instances of the ram16x128 hard macro and one instance of the ram32x64
hard macro, enter the following command:
icc_shell> estimate_fp_black_boxes {alu_bb} \
-hard_macros "ram16x128(2), ram32x64"

Sizing Black Boxes by Content 4-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The tool computes the gate-equivalent area by multiplying the size of the gate-equivalent
cell by the number of cells in the black box and dividing by the utilization. You specify these
parameters as follows:
• Gate-equivalent size
The default gate-equivalent size is the standard gate area of a 2-input NAND gate. You
can change the gate-equivalent size by using the set_fp_base_gate command to
specify either a gate from the library or an area.
❍ To specify a gate from the library, use the -cell option. For example, to set the
gate-equivalent size to the area of the nd02 library cell, enter
icc_shell> set_fp_base_gate -cell nd02
❍ To specify an area, use the -area option. For example, to set the gate-equivalent
size to 24 square microns, enter
icc_shell> set_fp_base_gate -area 24
• Gate-equivalent count
The gate-equivalent count is the number of gate equivalents that is needed to occupy the
same area as the actual cells in the black box. You must specify this value by using the
-sm_gate_equiv option with the estimate_fp_black_boxes command.
• Utilization
The default utilization is 0.7. To change the utilization, use the -sm_util option with the
estimate_fp_black_boxes command.
To prevent changing of the black box shape after size estimation, use the -fixed_shape
option with the estimate_fp_black_boxes command, or choose “Mark as fixed shape after
estimation” in the GUI.
Creating a FRAM View For a Black Box

If you are using a timing-driven flow, you must create a FRAM view for the black box after
performing black box pin assignment using the non-timing-driven flow. After you generate
the FRAM view, set it as a reference library and continue the flow from timing-driven
placement. For information about creating a FRAM view, see the Library Data Preparation
for IC Compiler User Guide.

Creating a FRAM View For a Black Box 4-8
Constraining Routing Over Black Boxes

By default, routing is not allowed over black boxes; routing resources are reserved for the
contents of the black box. You can make routing resources available over black boxes by
setting the min_layer and max_layer attributes on the black box cell.
For example, to allow routing over a black box on all layers above M6, select the black box
in the GUI and enter the following commands:
icc_shell> save_mw_cel -hierarchy
icc_shell> set bb_refname [get_attribute [get_selection] ref_name]
icc_shell> open_mw_cel ${bb_refname}
icc_shell> set_attribute [current_mw_cel] min_layer M1
icc_shell> set_attribute [current_mw_cel] max_layer M6
icc_shell> save_mw_cel
icc_shell> close_mw_cel ${bb_refname}
Note:
You must first save the top-level design, including the black boxes, before you can set
these attributes on black boxes.
Setting the Black Box Estimation Mode

You can set the status of black boxes in your design by using the
set_fp_black_boxes_estimated and set_fp_black_boxes_unestimated commands.
These commands set the sm_estimation_mode attribute on the specified black boxes. At a
later time, you can query the status of the black boxes by using the get_attribute
command.
The following sequence of commands shows how the import_fp_black_boxes,
estimate_fp_black_boxes, set_fp_black_boxes_estimated, and
set_fp_black_boxes_unestimated commands affect the sm_estimation_mode attribute
setting.
icc_shell> import_fp_black_boxes {alu_blackbox}
icc_shell> echo "sm_estimation_mode = [get_attr {alu_blackbox} \
sm_estimation_mode]"
sm_estimation_mode = unestimated
icc_shell> estimate_fp_black_boxes {alu_blackbox} -sm_size {500 500}

sm_estimation_mode = area

Constraining Routing Over Black Boxes 4-9
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
icc_shell> estimate_fp_black_boxes {alu_blackbox} \

-hard_macros "ram16x128(1), ram32x64"
sm_estimation_mode = gate_equivalent
icc_shell> set_fp_black_boxes_unestimated {alu_blackbox}

sm_estimation_mode = unestimated
icc_shell> set_fp_black_boxes_estimated {alu_blackbox}

sm_estimation_mode = area
Creating Quick Timing Models for Black Boxes

By default, black boxes cannot be used for timing analysis. However, you can enable timing
analysis in designs that contain black box cells by setting the fp_bb_flow variable to true
and creating quick timing models for the black boxes.
A quick timing model is an approximate timing model that is useful early in the design cycle
to describe the approximate timing of a black box. You create a quick timing model for a
black box by specifying the model ports, the setup and hold constraints on the inputs, the
clock-to-output path delays, and the input-to-output path delays. You can also specify the
loads on input ports and the drive strength of output ports.
Figure 4-2 shows a quick timing model representation of a black box. The constraint arcs
appear as dashed lines and the delay arcs appear as solid lines. Port CLK is a clock port,
ports A and B are input ports, and ports X and Y are output ports.
Figure 4-2 Quick Timing Model Representation of a Black Box
A
HoldA
SetupA X
CLKtoX
CLK
BtoY Y
B

Creating Quick Timing Models for Black Boxes 4-10
The arcs in this model are

• SetupA, which constrains port A. The constraining port is clock CLK.
• HoldA, which constrains port A. The constraining port is clock CLK.
• CLKtoX, which is a sequential delay arc from CLK to X.
• BtoY, which is a combinational delay arc from B to Y.
Note:
After all of the black boxes in the design are replaced with content, you should reset the
fp_bb_flow variable to false.
Figure 4-3 shows the flow used to create a quick timing model for a black box. You create
the quick timing model by specifying the model ports, the setup and hold constraints on the
inputs, the clock-to-output path delays, and the input-to-output path delays. You can also
specify the loads on input ports and the drive strength of output ports. After creating the
quick timing model, test it and refine it until the timing report meets your requirements. You
can continue to update the black box timing arcs by performing timing budgeting iteratively
until the full top-level timing analysis results are clean.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 4-3 Quick Timing Model Flow
Create quick timing models

using Tcl commands
Write the quick timing models

to .db files
Load quick timing models

Edit quick timing
models in text format
Analyze the timing report
and examine timing arcs
Is the timing No
report OK?
Yes
Continue
To create a quick timing model for a black box,

1. Specify that a new model is being created.
icc_shell> create_qtm_model qtm_bb
2. Specify the technology information, such as the name of the logic library, the maximum
transition time, the maximum capacitance, and the wire load information.
icc_shell> set_qtm_technology -library library_name
icc_shell> set_qtm_technology -max_transition trans_value
icc_shell> set_qtm_technology -max_capacitance cap_value
icc_shell> set_qtm_technology -wire_load_model wlm_name
3. Specify global parameters, such as setup and hold characteristics.

icc_shell> set_qtm_global_parameter -param setup -value setup_value
icc_shell> set_qtm_global_parameter -param hold -value hold_value
icc_shell> set_qtm_global_parameter -param clk_to_output \
-value cto_value

4. Define the ports.

icc_shell> create_qtm_port -type input in_port
icc_shell> create_qtm_port -type output out_port
icc_shell> create_qtm_port -type inout inout_port
icc_shell> create_qtm_port -type clock clk_port
5. Define the timing information for each port.

icc_shell> create_qtm_constraint_arc -setup -edge rise \
-from clk_port -to in_port -value arc_value
icc_shell> create_qtm_constraint_arc -hold -edge rise \
-from clk_port -to in_port -value arc_value
icc_shell> create_qtm_delay_arc -from_edge rise \
-from clk_port -to out_port -value arc_value
icc_shell> set_qtm_port_load -value drive_value in_port
icc_shell> set_qtm_port_drive -value drive_value out_port
6. (Optional) Generate a report that shows the defined parameters, the ports, and the
timing arcs in the quick timing model.
icc_shell> report_qtm_model
7. Save the quick timing model.

icc_shell> save_qtm_model
Writing a Quick Timing Model

To write out the quick timing model, use the save_qtm_model command. Use the -format
db | lib | script option to specify the output format for the model.
icc_shell> save_qtm_model format db
Loading a Quick Timing Model

To load the quick timing model, you need to add the .db file to the link_library variable,
as shown in the following example:
icc_shell> lappend link_library "dp_for_qtm/qtm_bb.db"
Propagating Timing Information to Soft Macros

In the typical hierarchical design flow, the commit_fp_plan_groups command converts
plan groups to soft macros and propagates TLUPlus model information to the soft macros.
As a result, soft macros in the typical hierarchical design flow contain TLUPlus model
information.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
In the black box flow, TLUPlus model information is not propagated to the individual black
boxes. To use TLUPlus model information, you must manually reload the TLUPlus files by
using the set_tlu_plus_files command before working on a soft macro created from a
black box.
Creating Unique Cell Instances

After importing and sizing the black box cells, use the uniquify_fp_mw_cel command to
create unique instances of multiply instantiated cells in the design as shown in the following
example.
icc_shell> uniquify_fp_mw_cel

Creating Unique Cell Instances 4-14
5
On-Demand-Loading Flow for Large Designs5
The on-demand-loading flow is a virtual flat design planning flow developed for large
designs. The flow decreases the amount of content in the plan groups by retaining only the
plan group interface logic. The on-demand-loading flow increases tool capacity and reduces
runtime during certain design planning steps without degrading the quality of results.
Information related to using the on-demand-loading flow is presented in the following
sections:
• On-Demand-Loading Design Planning Flow Overview
• On-Demand Netlist Command
• Removing On-Demand Netlists
• Reporting and Querying Information About On-Demand Netlists
• Cell Placement in the On-Demand-Loading Flow
• Timing Budgeting Using On-Demand Netlists
• Using Black Boxes in the On-Demand-Loading Flow
• UPF Support in the On-Demand-Loading Flow
• Committing Plan Groups Within the On-Demand-Loading Flow
5-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
On-Demand-Loading Design Planning Flow Overview

The on-demand-loading flow is designed to handle design planning for very large designs.
This flow involves the following five steps:
1. Create the floorplan using the full netlist. Use the design planning virtual flat placement
commands to create the plan groups, shape the plan groups, and perform macro
placement.
2. Create the on-demand netlist. This on-demand netlist contains the complete top-level
netlist, all the macros in the design, and the reduced plan group netlists. The reduced
plan group netlists contain only interface logic.
3. Using the on-demand netlist, continue with the remaining floorplanning steps, such as
high-fanout synthesis, routing, in-place optimization, and budgeting.
4. Commit the plan groups. In this step, the reduced plan groups are converted back to their
corresponding full netlists.
5. Perform block-level implementation and top-level timing closure tasks using the
full-netlist design representations.
The netlist of the reduced plan groups contain the following components:
• Cells, pins, and nets in the combinational input-to-output paths from the input ports to the
output ports
• Cells, pins, and nets in the combinational paths from the input ports to the edge-triggered
registers within the plan group
• Cells, pins, and nets in the combinational paths from edge-triggered registers within the
plan group to the output ports
• All macro cells residing in the plan groups
Figure 5-1 shows a typical on-demand-loading flow, using the design planning virtual flat
commands. Figure 5-2 shows the on-demand-loading flow when black boxes are present in
the design. The black box on-demand-loading flow can be used to floorplan large designs in
a shorter runtime.
Chapter 5: On-Demand-Loading Flow for Large Designs

On-Demand-Loading Design Planning Flow Overview 5-2
Figure 5-1 On-Demand-Loading Flow Using the Design Planning Commands
Floorplanning steps using the full netlist

Read netlist and uniquify instances
read_verilog, uniquify_fp_mw_cel
Create initial floorplan

create_floorplan
Create voltage areas and plan groups

create_voltage_area, create_plan_groups
Select MIM master instance

select_mim_master_instance
Virtual flat placement

create_fp_placement
Shape plan groups and voltage areas

shape_fp_blocks
Create on-demand netlist

create_on_demand_netlist; open_mw_cel your_ODN_CEL
Floorplan analysis
Floorplanning steps using the on-demand netlist

Read top-level SDC and UPF, derive PG connections
read_sdc, load_upf, derive_pg_connection
Associate MV cells & insert power switches

associate_mv_cells, create_power_switch_*
Derive PG connections
derive_pg_connection
Power network synthesis & analysis

compile_power_plan, analyze_fp_rail
High fanout net synthesis

optimize_fp_timing -hfs_only
Feedthrough optimization
optimize_fp_timing -feedthrough_buffering_only
Virtual in-place optimization

virtual_ipo
Timing budgeting
allocate_fp_budgets
Commit plan groups

commit_fp_plan_groups

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 5-2 On-Demand Loading Flow with Black Boxes
Floorplanning steps using the full netlist with black boxes

Read netlist with black boxes and uniquify instances
read_verilog, uniquify_fp_mw_cel

create_floorplan
Import and estimate black boxes

import_fp_black_boxes, estimate_fp_black_boxes
Select MIM master instance

select_mim_master_instance
Virtual flat placement

create_fp_placement
Flyline-based MIM pin assignment

place_fp_pins
Push down rows to black box & write out floorplan

push_down_fp_objects, write_floorplan
Create a soft macro for each black box

read_verilog, read_floorplan, create_fp_placement
Create on-demand netlist

create_on_demand_netlist; open_mw_cel your_ODN_CEL
Continue with the default on-demand flow

On-Demand Netlist Command

To create the on-demand netlist, use the create_on_demand_netlist command as
follows.
create_on_demand_netlist
[-on_demand_cell cell_name]
[-full_sdc_file sdc_file_name]
[-mcmm_map_file mcmm_map_file_name]
[-mcmm_setup_file mcmm_setup_file_name]
[-block_upf_map_file block_upf_map_file_name
[-check_block_upf_files] ]
[-block_sdc_map_file block_sdc_map_file_name]
[-block_mcmm_map_file block_mcmm_map_file_name]
[-pre_plan_group_abstraction_map_file map_file_name]
[-save_current_design]
[-work_dir dir_name]
[-host_options host_options_name]
[-test_host_options]
[-ignore_pins pin_list]
[-netlist_reduction_only | -save_block_netlist_only |
-save_internal_constraints_only]
[-incremental]
-plan_groups plan_groups | -soft_macros soft_macros
To create the on-demand netlist using the GUI layout window, first set the window task mode
to Design Planning if it is not already in that mode (File > Task > Design Planning). Choose
Partition > Create On Demand Netlist to open the dialog box shown in Figure 5-3.

On-Demand Netlist Command 5-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 5-3 On Demand Netlist GUI
In the On demand cell name box, enter the name of on-demand netlist for the command to
create. Select plan groups or soft macros in the target box, and specify one or more plan
groups or soft macros in the box. Alternatively, select All to specify all plan groups or hard
macros. Select the Ignore pins option and specify a collection of pins for which to ignore side
loads (clock pins are automatically ignored). This option removes flip-flops that are internal
to the plan group, even if they have a direct connection to the specified net at the top level

of the plan group. Select Input SDC file name to specify the name of the SDC constraints file
for entire design.
If your design is a multicorner-multimode design, select the MCMM setup file name option
to specify the name of the constraints file and select the MCMM map file name option to
specify the map file. Select the Block SDC map file name and Block MCMM map file options
to specify the name of the block-level map files. The map file contains a list of
multicorner-multimode mode name and variable pairs that are used to map the scenario
name to the SDC file. Note that you cannot select both the MCMM setup file name and Input
SDC file name options at the same time.
Select Pre plan group abstraction map file to specify the name of the map file that contains
a list of plan groups or soft macros and the name of the Tcl scripts to be run before creating
the on-demand netlist.
If your design has block-level UPF descriptions, enter the name of the map file that contains
a list of plan groups or soft macros and the name of the corresponding UPF file for each.
Select the Verify block UPF files option to first verify the map file and UPF files before
creating the on-demand netlist.
Select the Do only option and choose Netlist reduction, Save block netlist, or Save internal
constraints to run individual steps in the flow. Select Netlist reduction to create only the
reduced plan group netlists without creating the full plan group netlists. Select Save block
netlist to create the full plan group netlists, or select Save internal constraints to write the full
block-level plan group netlists with internal constraints.
By default, the netlist and constraint files generated by the on-demand netlist creation flow
are saved to the ODL_work directory. To save the files to another location, enter a different
directory path in the Work directory box. Select Run in parallel and enter the host options to
run the create_on_demand_netlist command on multiple machines in a distributed
computing network. To verify your host options before creating the on-demand netlist, select
Test host options to run a short test of the configuration you specified.
When creating an on-demand netlist, the tool
• Warns you that the tool is about to close all open designs as shown in Figure 5-4
Figure 5-4 Create On Demand Netlist Warning Message Box

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• Converts the current Milkyway design to a new Milkyway design that contains a reduced
netlist
The tool replaces the full netlist of each plan group with the corresponding reduced plan
group netlist. The new Milkyway design contains the complete top level, reduced plan
groups netlists, and all of the macros.
• Saves all the floorplan information, such as the plan group shapes, locations, and
placement information, in the internal database
• Saves all the constraints residing in the core of the plan groups in the internal database
• Sets the is_on_demand_netlist attribute to true for the reduced plan groups
• Closes the design after creating the on-demand netlist
Before you can use this on-demand netlist for the rest of the floorplanning flow, you need
to open the CEL view by using the open_mw_cel your_ODN_CEL command.
Viewing Plan Group Information in the GUI

The IC Compiler GUI displays utilization information based on the original, nonreduced set
of standard cells and macros for designs that contain an on-demand netlist. In Figure 5-5,
the “utilization: 0.714812” entry in the InfoTip in both plan group images refers to the
utilization of the plan group before netlist reduction. This number is computed based on the
original, nonreduced set of standard cells and macros. The “number_of_odl_standard_cell:
15237” and “odl_utilization: 0.657473” entries in the InfoTip for the reduced plan group are
computed based on the standard cell count in the reduced plan group. These two entries are
displayed only for designs that contain an on-demand netlist. The GUI displays the “ODL”
text on the status bar to indicate that the current design contains reduced plan groups.
The InfoTip also displays the status of the is_on_demand_netlist attribute for the plan
group under the mouse. The attribute is set to false for designs that contain the full netlist,
and true for designs that contain reduced plan groups.

Figure 5-5 GUI Display for On-Demand-Loading Flow

Full Plan Group Reduced Plan Group
When the current design is based on an on-demand netlist, the GUI displays “ODL” in the
status bar of the of the layout window. Figure 5-6 shows the lower-right corner of the layout
window that is displayed when you are viewing an on-demand netlist.
Figure 5-6 Status Bar Display for On-Demand Netlist
Creating the Reduced Netlist and Full Netlist in Separate Runs

For smaller designs, you can use a single create_on_demand_netlist command to create
the reduced plan group netlists, create the full plan group netlists, and write the internal
constraints for the plan groups in a single pass. For large, complex designs, you can create
the reduced plan group netlists and full plan group netlists by using multiple commands. By
using multiple commands, you can quickly write the on-demand netlist without creating the
full plan group netlists and constraints. To further speed up the on-demand netlist
processing, you can use the run_distributed_tasks command to enable distributed
processing capabilities. For more information, see “Using Distributed Processing in the
On-Demand-Loading Flow” on page 5-10.
To create the on-demand netlist as quickly as possible, use the
create_on_demand_netlist -netlist_reduction_only -on_demand_cell command.
The command creates the reduced plan group netlists, but does not save the netlist
contents or constraints for the full plan groups.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
For example, the following command creates only the reduced plan group netlists.
icc_shell> create_on_demand_netlist -plan_groups [get_plan_groups] \
-on_demand_cell Design_ODN -netlist_reduction_only
Before committing the plan groups to soft macros, you must create the full plan group
netlists by using the -save_block_netlist_only option. You must also annotate the full
block-level plan group netlists with internal constraints using the
-save_internal_constraints_only option before budgeting the design.
For example, the following commands write the full plan group netlists and constraint file.
icc_shell> create_on_demand_netlist –plan_groups [get_plan_groups] \
-save_block_netlist_only
icc_shell> create_on_demand_netlist –plan_groups [get_plan_groups] \
-save_internal_constraints_only –full_sdc_file sdc_file.sdc
Using Distributed Processing in the On-Demand-Loading Flow

The on-demand-loading flow reduces the runtime of the design planning flow. You can
further reduce the turnaround time of this flow by enabling distributed processing with the
-host_options option_name option to the create_on_demand_netlist command, or by
using the run_distributed_tasks command.
The -host_options option of the create_on_demand_netlist command selects the
distributed processing profile that is used by the command. You must define the distributed
processing profile by using the set_host_options command. Distributed processing
speeds up the creation of the reduced plan groups by creating them in parallel. By default,
distributed processing is not used and the reduced plan groups are created sequentially.
The create_on_demand_netlist command supports the following mechanisms for
distributed processing:
• Load Sharing Facility (LSF)
• Oracle Grid Engine
• rsh
• sh
To use distributed processing, you must have at least one of these distributed processing
systems configured in your compute environment. The following example uses the
set_host_options command to enable four distributed processes using Oracle Grid
Engine and uses the create_on_demand_netlist command to create the on-demand
netlist.

icc_shell> set_host_options -name my_grd_host_options \

-pool grd -submit_options {-P bnormal -l arch=glinux, \
cputype=amd64,mem_free=14G,mem_avail=14G -l \
qsc=f -cwd}
icc_shell> create_on_demand_netlist -on_demand_cell ORCA_ODL \
-plan_groups [get_plan_groups *] \
-work_dir ODL_GRD -host_options my_grd_host_options
Note:
Distributed processing requires one IC Compiler license for every four parallel tasks. For
example, to run eight parallel tasks, you must have two IC Compiler licenses. In the
previous GRD example, if only one IC Compiler license is available and there are more
than four plan groups, the tool begins processing four plan groups by using parallel
processing. When processing completes for one plan group, the tool submits the fifth
plan group to the GRD queue. The tool continues until all plan groups are processed.
You can also limit the number of submitted jobs by using the -num_processes option to
the set_host_options command; see the man page for more information about this
option.
You can test your distributed processing profile before you create the on-demand netlist by
using the create_on_demand_netlist -test_host_options command. The
create_on_demand_netlist -test_host_options command attempts to submit the
commands to the distributed processing network by using the distributed processing profile
specified by the -host_options option.
The following example uses the create_on_demand_netlist -test_host_options
command to test the my_host_options distributed processing profile. The final line in the
example, Information: host options test successful, indicates that the test
completed successfully.
-on_demand_cell ODN -work_dir ODL_work -netlist_reduction_only \
-test_host_options -host_options my_host_options
ODL: Work directory is /u/user/ODL_work
Information: Master creating task.
Information: Launching parallel job.
Block: N/A Stage:Launch_Parallel_Job Status:
Succeeded : Fri Oct 8 14:28:39 2010
Information: host options test successful.
To run individual scripts in the on-demand-loading flow by using distributed computing, use
the run_distributed_tasks command. The command runs the Tcl scripts based on the
configuration options specified by the set_host_options command. The following example
starts a distributed computing task and specifies that script1.tcl must run to completion
before starting script2.tcl. script3.tcl can run in parallel with both script1.tcl or script2.tcl.
icc_shell> run_distributed_tasks -host_options lsf_options \
-task_scripts {{script1.tcl ; script2.tcl} || script3.tcl} \
-output_directory run1

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Converting Additional Plan Groups to Reduced Plan Groups

After creating the on-demand netlist, you can further conserve compute resources by
converting additional plan groups to reduced plan groups. Use the -incremental option to
convert a specified set of plan groups and create a new on-demand netlist from an existing
on-demand netlist.
To convert additional plan groups to reduced plan groups,
1. Open the existing on-demand netlist cell created by a previous
create_on_demand_netlist command.
icc_shell> open_mw_cel ODN1
2. Use the create_on_demand_netlist command with the -incremental option to

convert the plan groups and to create a new on-demand cell name.
icc_shell> create_on_demand_netlist \
-plan_groups {plan_group_3 plan_group_4} -incremental \
-on_demand_cell ODN2
In this example, the tool creates the ODN2 on-demand cell and converts the
plan_group_3 and plan_group_4 plan groups to reduced netlists.
Improving Compression on Plan Groups With Side Loads

By default, the IC Compiler tool retains the side load cells that have a connection to a plan
group port. For example, a high-fanout signal, such as a scan enable or reset, can drive
many flip-flops within a plan group. By default, any flip-flop that is internal to the plan group,
but contains a connection to a plan group port, is retained in the reduced plan group netlist.
If your plan group contains many internal flip-flops with connections to a plan group port, you
might see poor compression of the reduced plan group netlist.

In the following example of poor compression, only 138 edge-triggered flip-flops are
removed from the reduced plan group netlist, resulting in less than 0.01 percent
edge-triggered flip-flop compression.
Information on plan_group_1 design:
Total number of cells: 2455514
Number of leaf cells: 2395249
Number of combinational cells: 931814
Number of level-sensitive latches: 1758
Number of edge-triggered flip-flops: 1446577
Number of nets: 2787899
Information on plan_group_1 plan group abstraction:
Information: Saving plan group abstraction to milkyway view
plan_group_1.CEL (ABS-103)
To exclude the side load flip-flop cells, specify the -ignore_pins option with a collection of
pins to be treated as high-fanout nets. The following example ignores the scan_enable and
reset pins on plan groups plan_group_1 and plan_group_2 and allows the tool to remove
internal flip-flops with connections to those ports.
icc_shell> create_on_demand_netlist -ignore_pins {
u1/plan_group_1/scan_enable \
u1/plan_group_1/reset \
u1/plan_group_2/scan_enable \
u1/plan_group_2/reset }
The following log file section, which was generated by the previous example, shows 95.1
percent edge-triggered flip-flop compression. In this example, the tool retained only 70348

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
edge-triggered flip-flops in the model, as compared to 1446439 without the -ignore_pins

option:
Information on plan_group_1 design:
Information on plan_group_1 plan group abstraction:
Information: Saving plan group abstraction to milkyway view
plan_group_1.CEL (ABS-103)
On-Demand-Loading for Multicorner-Multimode Designs

The on-demand-loading flow supports multicorner-multimode (MCMM) designs. If you are
performing design planning for a multicorner-multimode design, you must provide an
MCMM setup file and an MCMM map file by using the -block_mcmm_map_file option of the
create_on_demand_netlist command. Alternatively, you can enter the map file name in
the “Block MCMM map file name” box in the GUI. The command processes the design by
using the setup file and map file names that you specify.
The following block MCMM map file defines two MCMM setup files for two plan groups in the
design. Each line contains the instance name and the location of corresponding MCMM
setup file. Load this file by specifying the -block_mcmm_map_file option with the file name
for this file.
u_0 alu_mcmm_setup.tcl
u_1 reg_mcmm_setup.tcl

The following example shows the contents of the alu_mcmm_setup.tcl file used for creating
block-level MCMM settings.
set scenario1 ../inputs/mode_norm.sdc
set scenario2 ../inputs/mode_slow.sdc
create_scenario mode_norm
set_operating_conditions -analysis_type on_chip_variation \
-max_library lib1 -min_library lib1 -max WCCOM -min WCCOM
set_tlu_plus_files -max_emulation_tluplus ../libs/f_MF.tluplus \
-max_tluplus ../libs/f.tluplus -tech2itf_map ../libs/star.map_8M
read_sdc $scenario1
create_scenario mode_slow
set_operating_conditions -analysis_type on_chip_variation \
-max_library lib1 -min_library lib1 -max WCCOM -min WCCOM
set_tlu_plus_files -max_emulation_tluplus ../libs/f_MF.tluplus \
-max_tluplus ../libs/f.tluplus -tech2itf_map ../libs/star.map_8M
read_sdc $scenario2
Use the -block_mcmm_map_file option as shown in the following example to create the
on-demand netlist for a multicorner-multimode design. The report_on_demand_netlist
command is used to check the amount of netlist compression gained by applying the
create_on_demand_netlist command.
-block_mcmm_map_file block_mcmm_map.txt \
-on_demand_cell ODN
icc_shell> open_mw_cel ODN
icc_shell> report_on_demand_netlist
Note:
Do not load the full SDC constraints into the top-level design before creating the
on-demand netlist because loading the SDC constraints increases the memory required
to process your design. Use the -block_mcmm_map_file options of the
create_on_demand_netlist command instead.
Features Not Supported by the create_on_demand_netlist

Command
The following features are not supported by the on-demand-loading flow:
• Clock tree planning technology
• DFT operations
• Hierarchical manipulation of the on-demand netlist
• Commands that are not related to design planning

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Removing On-Demand Netlists

During the creation of the on-demand netlist, the create_on_demand_netlist command
saves the full netlists and the internal constraints for the plan groups. When you do not need
the on-demand netlist, you can remove this data by using the
remove_on_demand_netlist_data command. Note that you must open the Milkyway
design library to use the remove_on_demand_netlist_data command.
You can also remove the on-demand-loading work directory that was created by the
create_on_demand_netlist -work_dir dir_name command. The directory is a
temporary working directory and is not needed after successful on-demand data creation.
To remove the directory, use the /bin/rm –R directory_name command in a UNIX shell.
By default, the create_on_demand_netlist command creates a directory named
ODL_work.
Reporting and Querying Information About On-Demand Netlists

To report summary information about reduced plan groups, and report standard cell and
macro counts for the original plan groups, use the report_on_demand_netlist command.
The command performs the following actions:
• Lists the plan groups in the current design and reports which plan groups have the
reduced plan group netlists created by the create_on_demand_netlist command
• Reports which plan groups have the netlists saved during the on-demand netlist creation
• Reports which plan groups have the internal SDC constraints saved during the
on-demand netlist creation
• Reports the standard cell and macro cell counts for the original plan group
• Reports the standard cell and macro cell counts for the reduced, on-demand plan group
• Reports the compression for the reduced plan group
• Reports the area utilization for the original plan group
• Reports other statistics such as top-level cell count, top-level plus on-demand plan group
cell count, top-level plus original plan group cell count, and overall compression by using
the on-demand netlist
Example 5-1 shows an example of the information reported by the

report_on_demand_netlist command.

Removing On-Demand Netlists 5-16
Example 5-1 Information Reported by report_on_demand_netlist

*********************************************
Report : report_on_demand_netlist
Design : DesignA_ODL
Version : J-2014.09
Date : Fri Aug 8 14:07:43 2014
*********************************************
Design DesignA_ODL is an On-Demand Netlist.
Plan On Block Internal On Demand Orig Compres Orig

group Demand Netlist Const Cell Cell sion Cell
Netlist raints Count Count Util
-----------------------------------------------------------------
U0 true true true 78174 570344 0.86 59%
U1 true true true 78196 570344 0.86 59%
U2 true true true 156296 1140688 0.86 59%
U3 true true true 312636 2281376 0.86 61%
U4 true true true 20388 1319456 0.98 62%
U5 true true true 20388 1319456 0.98 62%
U6 true true true 37697 3371188 0.99 60%
U7 true true true 37697 3371188 0.99 60%
-----------------------------------------------------------------
Top design leaf cell count statistics:

---------------------------------------
PlanGroups (PGs) : 8
Top Level Cell Count : 1962607
Top + On Demand PG Cell Count : 2704079
Top + Original PG Cell Count : 15906647
Overall Compression : 0.83
To check if the current design in memory is an on-demand netlist, use the

query_on_demand_netlist command. This command returns a value 1 if the design is an
on-demand netlist and returns a value of 0 otherwise.
Cell Placement in the On-Demand-Loading Flow

In the virtual flat placement flow, the create_fp_placement command spreads standard
cells evenly throughout the design area. However, the on-demand-loading flow uses an
on-demand netlist that does not require the even distribution of standard cells within the
reduced plan groups. For these plan groups, the tool places higher priority on wire length
minimization and lower priority on the even distribution of standard cells. You can adjust the
balance between wire length minimization and the even distribution of standard cells by
setting the placer_max_cell_density_threshold variable.

Cell Placement in the On-Demand-Loading Flow 5-17
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The default placer_max_cell_density_threshold variable setting is 0.7 in the

on-demand-loading flow. The following command lowers the priority of wire length
minimization and increases the priority of the even distribution of standard cells:
icc_shell> set_app_var placer_max_cell_density_threshold 0.6
0.6
icc_shell> create_fp_placement
Note that the placer_max_cell_density_threshold variable does not affect the

placement of the top-level cells in the on-demand-loading flow; the top-level cells are evenly
distributed.
Timing Budgeting Using On-Demand Netlists

After you create the on-demand netlist, you can continue with the virtual flat design flow
using the reduced netlist as shown in the flow diagram in Figure 5-1. During the timing
budgeting step, the allocate_fp_budgets command checks the is_on_demand_netlist
attribute on the plan groups in the current design. If a plan group is using a reduced netlist,
the timing budgeter searches for its corresponding full netlist and internal constraints written
out by the create_on_demand_netlist command. The timing budgeter combines the
constraints from the reduced netlist and the internal constraints from the full netlist to create
the timing budget for the plan group. This complete set of budgeting constraints is retained
with the plan groups.
You can perform timing budgeting on multiple scenarios in the on-demand-loading flow by
specifying the allocate_fp_budgets -add_scenarios command. For more information,
see “Performing Budgeting on Multiple Scenarios” on page 12-24.
Using Black Boxes in the On-Demand-Loading Flow

The on-demand netlist creation flow supports designs that contain black boxes. In this flow,
you replace black boxes with soft macros before creating the on-demand netlist, The
on-demand netlist models the specified soft macros with abstracted, reduced plan groups.
To create the on-demand netlist for a design that contains black boxes,
1. Read the top-level Verilog netlist.
icc_shell> read_verilog leon3mp_bb.v
2. Uniquify the multiply instantiated modules.

icc_shell> uniquify_fp_mw_cel -store_mim_property {u0_0 u0_1}

Timing Budgeting Using On-Demand Netlists 5-18
3. Create the floorplan.

icc_shell> create_floorplan -control_type aspect_ratio \
-core_aspect_ratio 1 -core_utilization 0.7 -left_io2core 30 \
-bottom_io2core 30 -right_io2core 30 -top_io2core 30 \
-start_first_row
4. Import the block boxes and set an estimated size.

icc_shell> get_cells -hier -filter "is_logical_black_box==true"
{u0_0 u0_2 u0_3}
icc_shell> import_fp_black_boxes {u0_0 u0_2 u0_3}
icc_shell> estimate_fp_black_boxes -sm_size {1000.0 1000.0} {u0_0}
5. If the design contains multiply instantiated modules, select the master instance.
icc_shell> select_mim_master_instance u0_0
6. Create the initial placement.

icc_shell> create_fp_placement
7. Place the module pins.

icc_shell> place_fp_pins
8. Copy cell rows into the black boxes.

icc_shell> push_down_fp_objects -object_type rows \
-push_down_type copy_down
9. Write the top-level floorplan.

icc_shell> write_floorplan -create_terminal -create_bound \
-placement terminal -row -track leon3s.fp
10.Create soft macros for each black box.

foreach bbcel {leon3s leon3s_2 leon3s_3} {
current_mw_cel $bbcel
write_floorplan -create_terminal -create_bound \
-placement terminal -row -track $bbcel.fp
close_mw_cel
remove_mw_cel -all_versions $bbcel
read_verilog -verbose -cell $bbcel $bbcel.v
uniquify_fp_mw_cel -verbose
read_floorplan $bbcel.fp
# Uncomment the next line to place the soft macro
# create_fp_placement
close_mw_cel -save
}

Using Black Boxes in the On-Demand-Loading Flow 5-19
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
You can also use the run_distributed_tasks command to create the soft macros by
using distributed processing. This step must be performed in separate Milkyway
libraries. When distributed processing completes, each soft macro CEL view must be
copied into the Milkyway library for the design to replace the corresponding black box
CEL view.
11. Create the on-demand netlist.
-soft_macros {u0_0 u0_2 u0_3} \
-on_demand_cell Design_ODN \
-pre_plan_group_abstraction_map_file preabstraction.map \
-block_sdc_map_file block_sdc_map.file \
-block_upf_map_file block_upf_map.file
UPF Support in the On-Demand-Loading Flow

The IC Compiler tool supports IEEE 1801 Unified Power Format (UPF) commands in the
on-demand-loading flow. Use the -block_upf_map_file option with the
create_on_demand_netlist command to map the block-level UPF file names to plan
group names in your design. To test the contents of the mapping file, specify the
-check_block_upf_files option.
The following steps illustrate a partial flow used to process a design in the
on-demand-loading flow for designs that contain a UPF power intent description.
1. Create the UPF file for the top-level design.
The top-level netlist should contain all level-shifter, always-on, and isolation cells.
Power-switch cells are inserted by the IC Compiler tool.
2. If your design requires power switches at the top level for a shut-down power domain,
create a top-level voltage area.
3. Create the plan groups and a voltage area for each plan group.
Each voltage area must have the same boundary as its associated plan group. The
name of the voltage area, defined by the -name option with the create_voltage_area
command, should be the same as the power domain name.
icc_shell> create_plan_groups {plan_group_1 plan_group_2} \
-coordinate {x1 y1 x2 y2}
icc_shell> create_voltage_area {plan_group_1} \
-name domain_name_1 -coordinate {x1 y1 x2 y2}
icc_shell> create_voltage_area {plan_group_2} \
-name domain_name_2 -coordinate {x3 y3 x4 y4}
4. Create a UPF mapping file that contains a list of block name and UPF file name pairs as
follows:

UPF Support in the On-Demand-Loading Flow 5-20
plan_group_1 block1_UPF_file_name.upf
plan_group_2 block2_UPF_file_name.upf
5. Create the on-demand netlist and specify the UPF mapping file name with the
-block_upf_map_file upf_map_file_name option. You can also specify the
-mcmm_map_file and -mcmm_setup_file options for a multicorner-multimode design,
or specify the -block_sdc_map_file block_sdc_map_file_name option for a design
with a single scenario.
-on_demand_cell odn_cell_name \
-plan_groups [get_plan_groups *] \
-block_upf_map_file upf_map_file_name \
-block_sdc_map_file block_sdc_map_file_name
6. Open the on-demand cell, load the top-level UPF file, and load the full-chip SDC file.
icc_shell> open_mw_cel odn_cell_name
icc_shell> load_upf top_only_UPF_file_name.upf
icc_shell> read_sdc sdc_file_name.sdc
7. Create power and ground nets for the top- and block-level designs.
icc_shell> derive_pg_connection -create_nets
8. Create the power switch array or ring in the top- and block-level designs.
# Map the power switches
icc_shell> map_power_switch switch_name -domain domain_name \
-lib_cells cell_list
# Create the top-level power switch ring

icc_shell> create_power_switch_ring ...
# Create the block-level power switch array

icc_shell> create_power_switch_array ...
9. If your design contains top-level power switches for a shut-down power domain, connect
them with the connect_power_switch command. Specify the top-level voltage area
name with the -voltage_area option.
icc_shell> connect_power_switch -voltage_area Top_level_VA ...
10.Connect the block-level power-switch cells and specify DEFAULT_VA as the voltage
area name with the -voltage_area option.
icc_shell> connect_power_switch -voltage_area DEFAULT_VA ...
Note the following restrictions when using UPF in the on-demand-loading flow:
• The .ddc, black box, and multiply instantiated module flows are not supported.

UPF Support in the On-Demand-Loading Flow 5-21
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• Each plan group must have its own power domain and a corresponding voltage area.
Creating a plan group within the DEFAULT_VA is not supported because it does not
have its own power domain.
• You cannot create extra feedthrough ports during pin creation. Feedthrough ports must
exist in the original netlist.
• Isolation and level-shifter cells created with the set_isolation_control -location
parent command are supported in the scopeless type of UPF; however, -location
parent with “scope self” is not supported.
• You must use always-on buffers; the single-rail always-on methodology is not supported.
• Disjoint voltage areas are not supported.
• Designs that contain multiply instantiated modules are not supported.
• The -source, -sink, and -diff_supply_only options to the set_isolation
command are not supported in the on-demand-loading flow with UPF. You must prepare
the top-level and block-level UPF descriptions separately.
• Include any UPF commands required to resolve supply sets to supply nets in the
top-level-only UPF file.
Committing Plan Groups Within the On-Demand-Loading Flow

During the plan group commit step within the on-demand-loading flow, the
commit_fp_plan_groups command automatically checks if a plan group to be committed
has the is_on_demand_netlist attribute. If a plan group is using a reduced netlist, the plan
group is committed into a soft macro based on the content of the corresponding full netlist.
Additional feedthroughs can be created in the plan groups during the on-demand-loading
flow. The feedthroughs are not present in the original full netlist. In the commit plan group
process, they are added to the final committed netlist of the plan group.
If you have run optimization in the on-demand-loading flow, only changes to buffers on the
feedthrough nets are retained. All other changes are lost. Block implementation reoptimizes
the netlist based on the created budgets. The budgets are valid because budgeting is done
on the optimized netlist before the commit step.
Placement of the cells that are part of the on-demand netlist is maintained after the commit
step. The placement of cells that are not in the on-demand netlist is not maintained.
However, these cells do reside inside the plan group boundary; they are grouped together
near the lower-left corner of the plan group.

Committing Plan Groups Within the On-Demand-Loading Flow 5-22
6
Virtual Flat Placement 6
Virtual flat placement is the simultaneous placement of standard cells and macros for the
whole chip. The initial virtual flat placement is very fast and is optimized for wire length,
congestion, and timing. For designs with macros, plan groups, or voltage areas that have
not already been placed, virtual flat placement can help you decide on the locations, sizes,
and shapes of the top-level physical blocks.
• Virtual Flat Placement Overview
• Virtual Flat Placement Command
• Virtual Flat Placement Strategy Options
• Hard Macro Constraints
• Blockages, Margins, and Shielding
• Relative Placement Groups
• Placement Evaluation
• Floorplan Editing
• Voltage Area Planning
• Placing Multiply Instantiated Modules
6-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Virtual Flat Placement Overview

Virtual flat placement is the simultaneous placement of standard cells and macros for the
whole chip; it is a fast initial flat placement performed for design planning purposes. For
designs with macros, plan groups, or voltage areas that have not already been placed,
virtual flat placement can help you decide on the locations, sizes, and shapes of the
top-level physical blocks. This placement is “virtual” because it temporarily considers the
design to be entirely flat, without hierarchy. After you decide on the shapes and locations of
the physical blocks, you restore the design hierarchy and proceed with the block-by-block
physical design flow.
You can control the process of virtual flat placement to emphasize the most important
qualities needed for your design, such as timing, congestion avoidance, hierarchical gravity,
pin locations, scan chain connectivity, or fast turnaround. Because virtual flat placement is
relatively fast, you can explore different tradeoffs between these qualities before you finalize
the floorplan.
Virtual flat placement is typically done after the floorplan has been initialized with the
create_floorplan command or by using Floorplan > Create Floorplan in the GUI, but
before any macros or standard cells have been placed. The chip boundary should be
defined, the I/O pad cells placed, and the site rows defined. The timing constraints should
be set and meeting these constraints should be reasonably achievable. The power structure
is typically not yet defined, except possibly for the I/O pads.
Using virtual flat placement typically consists of the following steps:
1. Set the virtual flat placement strategy options by using the
set_fp_placement_strategy command.
2. Set the macro placement options by using the set_fp_macro_options command.

3. Define any necessary relative placement constraints.
4. Set the blockage, margin, and shielding options.
5. Perform virtual flat placement by using the create_fp_placement command.
6. Analyze the results for timing and congestion. Perform manual editing, if applicable.
7. If the results are not satisfactory, repeat steps 1 through 6.
Chapter 6: Virtual Flat Placement

Virtual Flat Placement Overview 6-2
Virtual Flat Placement Command

You can perform virtual flat placement by using the create_fp_placement command:
create_fp_placement
[-effort low | high]
[-max_fanout positive_integer]
[-no_hierarchy_gravity]
[-no_legalize]
[-incremental placement_string]
[-congestion_driven]
[-timing_driven]
[-num_cpus number_of_cpus]
[-plan_groups collection_of_plan_groups]
[-voltage_areas collection_of_voltage_areas]
[-optimize_pins]
[-write_placement_blockages]
[-exploration]
For information about the command options, see the create_fp_placement man page.
To perform virtual flat placement using the GUI layout window, first set the window task
mode to Design Planning if it is not already in that mode (File > Task > Design Planning).
Then choose Placement > Place Macro and Standard Cells. This opens the dialog box
Figure 6-1 Place Macro and Standard Cells Dialog Box
You can set the effort level to Low (the default) or High. The Low effort mode produces good
placement results for hard macros and plan groups. Select the High effort mode for even
better quality of results at the cost of more runtime.
Select one or more of the “Congestion driven,” “Timing driven,” and “Hierarchical gravity”
options to specify the types of placement optimization to apply. Select “Exploration mode” to

Virtual Flat Placement Command 6-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
perform very fast placement, without legalization, so that you can quickly explore various
placement alternatives. You can read more about these options in the following sections:
• “Congestion-Driven Placement” on page 6-6
• “Timing-Driven Placement” on page 6-6
• “Hierarchical Gravity” on page 6-6
• “Exploration Mode” on page 6-7
Click the Advanced Options button to open the dialog box shown in Figure 6-2.
Figure 6-2 Virtual Flat Placement Advanced Options Dialog Box
In the “Max fanout” box, enter the maximum fanout that you want to be considered during
placement optimization. The placer does not attempt to reduce the wire lengths of any net
that has a fanout greater than this number.
Select the “Incremental” option to perform incremental virtual flat placement on a design that
has already had virtual flat placement performed, and you want the placer to keep the

placement of existing cells where possible. You can choose the scope of the design on
which to perform incremental placement:
• All – The whole design
• Top level cells only – Top-level cells that do not belong to any plan group or voltage area
• Specified plan groups – Cells belonging to specified plan groups
• Specified voltage areas – Cells belonging to specified voltage areas
By default, placed cells are legalized by resolving overlaps and moving standard cells to
legal sites. To speed up the design planning flow, you can disable legalization of standard
cell placement and use the unlegalized design during exploration mode plan-group-aware
routing. To prevent legalizing, uncheck the “Legalize resulting placement” option. To disable
legalization before high-fanout synthesis and in-place optimization, set the
fpopt_no_legalize variable to true. You can legalize the placement separately by using
the legalize_placement command at a later time.
If you are performing virtual flat placement for a block and not for the whole chip, you can
optimize the I/O pin locations by selecting the “Optimize pins” option. In that case, the placer
locates the pins to minimize wire lengths, while observing any pin constraints that have been
set for the block. Performing placement and pin assignment simultaneously results in
smaller wire lengths for nets connected to the constrained pins. Figure 6-3 shows the overall
flow for using simultaneous placement and pin assignment at the block level.
Figure 6-3 Block-Level Simultaneous Placement and Pin Assignment Flow
Load DEF pin locations or

pin constraints
Set the pin assignment constraints

set_fp_pin_constraints
create_fp_placement -optimize_pins
-no_hierarchy_gravity
Select the “Ignore scan chain connectivity” option to have the placer ignore scan chain
connections during placement.
Select the “Write placement blockages into file” option to have the placer write all the
internally computed placement blockages into a file called design_planning_blockages.tcl.
These blockages include macro padding and channels narrower that the sliver size.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
In the “Number of CPUs” box, enter the number of CPUs to be used in parallel to work on
virtual flat placement.
Congestion-Driven Placement
The congestion-driven virtual flat placement flow is disabled by default. To enable it, use the
create_fp_placement -congestion_driven command or select the “Congestion driven”
option in the Place Macro and Standard Cells dialog box.
With congestion-driven placement, the placer makes a greater effort to reduce congestion
at the cost of runtime. It places cells close together to minimize wire length, but in congested
areas, it adds keepout padding around cells and moves the cells to make room for routing.
This can affect the amount of area occupied by macro arrays.
The keepout areas generated during congestion-driven placement are automatically
removed after placement is complete. If you plan to do incremental placement later, you can
save the generated keepouts by using the -write_placement_blockages option of the
create_fp_placement command or by selecting the “Write placement blockages into file”
option of the advanced options dialog box. Later, when you want to perform incremental
virtual flat placement, source the saved file, design_planning_blockages.tcl.
Timing-Driven Placement
The timing-driven virtual flat placement flow is disabled by default. To enable it, use the
create_fp_placement -timing_driven command or select the “Timing driven” option in
the Place Macro and Standard Cells dialog box.
With timing-driven placement, the placer makes a greater effort to improve timing by
keeping cells closer together along critical paths, including both standard cells and macro
cells. This takes more runtime because timing analysis must be performed along with
placement.
Hierarchical Gravity
The hierarchical gravity option is enabled by default. To disable it, use the
create_fp_placement -no_hierarchy_gravity command or uncheck the “Hierarchical
gravity” option in the Place Macro and Standard Cells dialog box.
The hierarchical gravity option tends to keep the cells belonging to each hierarchical design
logic block physically together. This type of grouping usually results in better placement
because designs tend to partition well along hierarchical boundaries. If there are no
user-created plan groups, the placement engine analyzes the logical hierarchy of the design
and uses blocks with reasonable sizes as the default plan groups.

You should disable hierarchical gravity if the design does not have hierarchy or if you know
that the existing logical hierarchy does not represent a good physical partitioning of the
design. Disabling hierarchical gravity saves runtime and allows the placement engine more
flexibility in placing the cells of a hierarchical block.
Figure 6-4 shows the effects of hierarchical gravity on virtual flat placement. The colored
regions represent the areas occupied by standard cells belonging to different hierarchical
blocks.
Figure 6-4 Placement With and Without Hierarchical Gravity
Without hierarchical gravity With hierarchical gravity
Exploration Mode
The exploration mode is disabled by default. To enable it, use the create_fp_placement
-exploration command or select the “Exploration mode” option in the Place Macro and
Standard Cells dialog box.
In the exploration mode, the placer performs virtual flat placement very fast so that you can
quickly explore different placement strategies. It uses the low-effort mode for speed and
places most cells coarsely, without considering timing or congestion, and does not legalize
the placement.
In a typical placement exploration flow, you perform an initial virtual flat placement in
exploration mode to determine the best plan group sizes, shapes, and locations. Using that
information, you create and shape the plan groups by using the create_plan_groups and
shape_fp_blocks commands. After that, you run virtual flat placement in exploration mode
again to get good-quality placement of hard macros, top-level cells, and interface cells.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
During the initial flat placement stage before plan group creation, the exploration mode
groups together logic from the same hierarchy as in the standard design planning flow,
although overlaps can occur because the placement is not legalized. This placement
provides sufficient information to determine plan group sizes, shapes, and locations.
At the hierarchical placement stage, when plan groups are in the core, the exploration mode
performs good-quality placement of top-level interface cells and macro cells. It places hard
macros with no overlap, but standard cells might overlap. It applies more effort to the
placement of top-level cells, interface cells, and any hard macros inside the plan groups. At
the end of hierarchical placement in exploration mode, the placement of hard macros,
top-level cells, and interface cells has the same quality as regular hierarchical placement.
The placement results are sufficient for you to perform top-level routability analysis.
Note:
The fast exploration flow does not support multiply instantiated modules, black boxes, or
multicorner-multimode operation, and it cannot be used with the -effort high,
-timing_driven, -congestion_driven, -incremental, or -optimize_pins options.
To get the best results in the least amount of time, observe the following guidelines in the
exploration flow:
• High-fanout synthesis
To perform high-fanout synthesis after virtual flat placement, use the
optimize_fp_timing –hfs_only command. When you use this command in the
exploration flow (after create_fp_placement -exploration), the tool performs
high-fanout synthesis in incremental mode, which is more efficient for analyzing the
clumped placement of existing buffers, and does not legalize the newly added buffers.
• Routing
The route_zrt_global -exploration true command performs fast, low-effort
routing for design exploration.
• Optimization
The optimize_fp_timing -feedthrough_buffering_only command, followed by
virtual in-place optimization, performs optimization without running the complete in-place
optimization flow. The virtual_ipo and virtual_ipo -end commands perform
in-place virtual timing optimization for fast optimization during design exploration.
• Timing budgeting
The allocate_fp_budgets –exploration command performs fast timing budgeting
during design exploration.
The following script shows a typical command sequence in a timing-driven exploration flow.
read_verilog ...
derive_pg_connection ...
create_floorplan

# Perform clumped, nonlegalized placement, hard macros overlapped

create_fp_placement -exploration
...
shape_fp_blocks
...
# Perform clumped, nonlegalized placement, hard macros NOT overlapped
create_fp_placement -exploration
# Power network synthesis

derive_pg_connection
synthesize_fp_rail ...
commit_fp_rail
# High-fanout synthesis, incremental, no legalization

optimize_fp_timing -hfs_only
# Plan-group-aware routing
mark_clock_tree
set_route_zrt_common_options -plan_group_aware ...
# Routing in exploration mode, routing done on nonlegalized cells

route_zrt_global -exploration true
place_fp_pins [get_plan_groups *]
# Virtual in-place optimization

optimize_fp_timing -feedthrough_buffering_only
virtual_ipo
...
virtual_ipo -end
# Timing budgeting
allocate_fp_budgets -exploration
# Commit plan groups

command_fp_plan_groups
Simultaneous Placement and Pin Assignment

You can simplify your design flow by performing simultaneous placement and pin
assignment for block-level designs. To do this, choose Placement > Place Macro and
Standard Cells, click Advanced Options, and then select “Optimize pins” in the dialog box.
Alternatively, you can use the create_fp_placement -optimize_pins command.
The placement engine places the cells near the port locations according to the pin
constraints (side, side and order, and side and location) that you have set. The result is a
virtual flat placement and pin assignment for block-level designs. Therefore, the overall
quality of simultaneous placement and pin assignment is superior to running placement and

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
pin assignment separately. The quality is measured by a smaller wire length of nets
connected to the constrained pins.
Figure 6-3 shows the design flow for the simultaneous placement and pin assignment for
block-level designs.
Virtual Flat Placement Guidelines

For better results, observe the following guidelines for virtual flat placement:
• Place and fix any macros that must be located in specific positions before invoking virtual
flat placement.
• Disable the hierarchical gravity feature by using create_fp_placement
-no_hierarchy_gravity if the design does not have hierarchy.
• Use the default dialog box settings and command settings if you are not sure about what
settings to use. Use lower-effort settings initially and higher-effort settings for detailed
floorplanning.
• Consider using high-effort settings for small- or medium-sized designs, even at early
stages of physical prototyping, for higher quality of results at the cost of slightly longer
runtimes.
• Increase the pin-count-based macro padding to at least 1.0 track per pin
(set_keepout_margin -tracks_per_macro_pin 1.0) to prevent congestion when
using the macros on edge feature (set_fp_placement_strategy -macros_on_edge).
Virtual Flat Placement Strategy Options

You perform virtual flat placement by using the create_fp_placement command or by
choosing Placement > Place Macro and Standard Cells in the GUI. The command options
let you select the effort level, the types of optimization performed, and a few other options.
Several additional virtual flat placement strategy options are available by using the
set_fp_placement_strategy command. These settings are not saved in the Milkyway

Virtual Flat Placement Strategy Options 6-10
database; you must set placement strategy options during each session. This is the
command syntax:
set_fp_placement_strategy
[-adjust_shapes on | off]
[-allow_misaligning_flips on | off]
[-auto_grouping none | user_only | low | medium | high ]
[-auto_grouping_max_columns integer]
[-auto_grouping_max_height height]
[-auto_grouping_max_rows rows]
[-auto_grouping_max_width width]
[-block_constraint_file file_name]
[-congestion_effort low | medium | high]
[-default]
[-fix_macros none | soft_macros_only | all]
[-flip_chip off | on | honor_reserved]
[-force_auto_detect_hierarchy on | off]
[-hierarchy_gravity_blocks list_of_block_names]
[-hierarchy_gravity_multi_level on | off]
[-honor_mv_cells on | off]
[-IO_net_weight weight]
[-macro_orientation automatic | all | orientation]
[-macro_setup_only on | off]
[-macros_avoid_hard_macro_blockage_vicinity on | off]
[-macros_min_distance_applies_to macro_cells]
[-macros_on_edge on | off | auto]
[-min_distance_between_macros distance]
[-min_distance_to_auto_array distance]
[-minimize_auto_grouping_channels on | off]
[-pin_routing_aware on | off]
[-plan_group_interface_net_weight weight]
[-sliver_size distance]
[-snap_macros_to_user_grid on | off]
[-spread_spare_cells on | off]
[-virtual_IPO on | off]
After you set these options, the settings apply to future virtual flat placement performed by
using the create_fp_placement command or by choosing Placement > Place Macro and
Standard Cells in the GUI. To view the current settings for these options, use the
report_fp_placement_strategy command as shown in the following example,

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
icc_shell> report_fp_placement_strategy
...
*** Macro related parameters ***
set_fp_placement_strategy -macro_orientation automatic | all | N
current setting: automatic
default setting: automatic
...
*** Congestion driven placement related parameters ***

set_fp_placement_strategy -congestion_effort low | medium | high
current setting: low
default setting: low
...
*** Net weighting related parameters ***

set_fp_placement_strategy -IO_net_weight <float>
current setting: 1.00
default setting: 1.00
...
The virtual flat placement strategy options are divided into the following categories:
• Macro-Related Options
• Congestion-Related Options
• Net Weighting Options
• Miscellaneous Options
Macro-Related Options
These are the strategy options that control hard macro placement:
[-allow_misaligning_flips true | false]
[-auto_grouping none | user_only | low | medium | high]
[-auto_grouping_max_columns columns]
[-auto_grouping_max_height distance]
[-auto_grouping_max_rows rows]
[-auto_grouping_max_width width]
[-fix_macros none | soft_macros_only | all]
[-macro_orientation automatic | all | orientation]
[-macro_setup_only on | off]
[-macros_avoid_hard_macro_blockage_vicinity true | false]
[-macros_min_distance_applies_to collection]
[-macros_on_edge on | off | auto]
[-min_distance_between_macros distance]
[-min_distance_to_auto_array distance]
[-minimize_auto_grouping_channels true | false]
[-pin_routing_aware on | off]

[-sliver_size distance]
[-snap_macros_to_user_grid on | off]
Additional macro placement constraints can be set with the set_fp_macro_options

command. For details, see “Hard Macro Constraints” on page 6-28.
Automatic Grouping of Macros Into Arrays

Placing macros into arrays reduces the scattering of macros, leaving larger continuous
areas for other placement. It can reduce wire lengths when a single net drives the same pin
of multiple macros in the array. Automatic grouping of macros is hierarchy-aware; macros in
the same physical hierarchy are more likely to be arrayed.
The -auto_grouping option controls the packing of macros into arrays. The option has five
possible settings:
• none – No macros are placed into arrays. User-defined arrays are not honored.
• user_only – Only user-defined arrays are honored.
• low (the default behavior) – Small macros of the same reference cell are arrayed, but
larger macros are not arrayed. User-defined arrays are honored.
• medium – Small- and medium-sized macros of the same reference cell are arrayed, but
larger macros are not arrayed. User-defined arrays are honored.
• high – Small macros and some larger macros are arrayed. User-defined arrays are
honored.
Figure 6-5 shows examples of macro array grouping results for the none, low (default), and
high settings for the -auto_grouping option.
Figure 6-5 Macro Array Grouping Options

-auto_grouping none -auto_grouping low -auto_grouping high
The -auto_grouping_max_columns columns, -auto_grouping_max_height height,

-auto_grouping_max_rows rows, and -auto_grouping_max_width width options

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
provide further control over the size of automatically generated macro arrays. Specify a
value of 0 for any of these options to disable them.
To reduce the number of channels between macros in the array, specify the
-minimize_auto_grouping_channels true option. Figure 6-6 shows the macro array
grouping results for this option set to false and true. Note that the macros in Figure 6-6
have pins only on one side and are placed nearly back-to-back.
Figure 6-6 Macro Array Channels
-minimize_auto_grouping_channels -minimize_auto_grouping_channels
false true
You can create additional spacing around the macro arrays with the
-min_distance_to_auto_array spacing option. Figure 6-7 shows the macro array
grouping results for a -min_distance_to_auto_array spacing of 0 and 20 microns
respectively.

Figure 6-7 Macro Array Spacing

-min_distance_to_auto_array 0 -min_distance_to_auto_array 20
To prevent the tool from flipping macros and causing a misalignment of the macros, specify
the -allow_misaligning_flips false option. Misalignments can be caused by keepout
margins that are not equal for each side of the macro.
Fixing Macros in Place

The -fix_macros option specifies which types of macros, if any, should be fixed in position
(not moved) during virtual flat placement. It has three possible settings:
• none (the default behavior) – None of the macros are fixed in position. All macros can
move during virtual flat placement.
• soft_macros_only – Soft macros are fixed in position. Hard macros can move during
virtual flat placement.
• all – All macros are fixed in position and cannot move during virtual flat placement.
This option setting affects macros during virtual flat placement only. The is_fixed attribute
status of each macro is not affected. Optimization commands used later in the flow might still
move macros that are fixed during virtual flat placement.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Macro Orientation
The -macro_orientation option can be used to restrict the allowed orientation of macros
during virtual flat placement. It can be set as follows:
• automatic (the default behavior) – The tool determines a good orientation to use for
each reference library cell based on the pin locations and uses that same orientation for
all instances of that macro.
• all – The tool can use any orientation for each macro instance.
• N – All macros are placed in the north orientation.
This option setting affects macros during virtual flat placement only.
Macro Setup Only

Use the -macro_setup_only on option to have the placer place the macros only (not
standard cells) and to quickly place them outside the core area, except for macros with
relative location constraints, which are still placed inside the core area. After you view the
results, you can use the Edit Toolbar to manually move the macros into the core area as
needed. You can lock the location of macros that you want to stay in place by setting the
is_fixed attribute to true or by using the GUI, and allow the placer to finish any remaining
placement.
Figure 6-8 shows the resulting macro placements with the macro setup-only mode set to
off and set to on.

Figure 6-8 Macro Setup-Only Option

-macro_setup_only off (default) -macro_setup_only on
Macro Minimum Distance

Macros are often placed as close together as possible. To specify a minimum distance
between macros, use the -min_distance_between_macros option and specify the
minimum distance in microns, as in the following example:
icc_shell> set_fp_placement_strategy -min_distance_between_macros 8.0
Macros are then placed with a minimum of 8.0 microns of spacing between them, as
measured from the macro padding, if any, to ensure that at least 8.0 microns of space is
available for standard cell placement.
Figure 6-9 shows the resulting macro placements with the distance between macros set to
0 microns and 20 microns.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 6-9 Minimum Distance Between Macros Option
-min_distance_between_macros 0 (default) -min_distance_between_macros 20
By default, the minimum spacing applies to all macros. To apply a minimum spacing only to
certain macros, use the -macros_min_distance_applies_to option and supply a
collection of macros, as in the following example:
icc_shell> set lev3RAM [get_cells {*/*/*RAM*}]
{I_ORCA_TOP/I_CONT_MEM/I_CONT_RAM_2_3 I_ORCA_TOP/I_CONT_MEM/...
... }
icc_shell> set_fp_placement_strategy -min_distance_between_macros 8.0 \
-macros_min_distance_applies_to $lev3RAM
Then all of the macros belonging to the collection are placed with a minimum spacing of at
least 8.0 microns between them. The minimum spacing between one of these macros and
a macro not belonging to the collection is one-half of the specified value, or 4.0 microns in
this example.
If the collection is empty or if the -macros_min_distance_applies_to option is not used,
the minimum spacing value applies to all macros.
Macros on Edge
Use the -macros_on_edge option to specify whether to place macros along boundary edges
or to allow them to be placed anywhere. This option can be set to off, on, or auto. The off
setting allows macros to be placed anywhere. The on setting forces placement of macros

along the boundary edges of the chip or plan group whenever possible. The auto setting
(which is the default behavior) tends to perform placement along the chip or plan group
boundary edges, but allows some macros to be placed away from edges.
Figure 6-10 shows examples of placement using -macros_on_edge off and
-macros_on_edge auto.
Figure 6-10 Macros on Edge Option
-macros_on_edge off -macros_on_edge auto (default)
Placing macros along boundary edges reduces the occurrence of fragment spaces and
leaves a larger open space in the middle for placement and routing.
If hard macros occupy a large percentage of the chip area, consider using the on setting.
Placing hard macros along the edges generally reduces congestion and improves
routability.
For a hierarchical design, set this option to off until you have shaped and placed the plan
groups inside the core area of the chip.
Macros-on-edge placement behavior depends on the hierarchical gravity placement feature.
When hierarchical gravity placement is enabled, the macros are placed on the edges of the
hierarchical boundaries of their respective plan groups. Otherwise, they are placed along
the edges of the chip. Hierarchical gravity is enabled by default, but it can be turned off by
using the -no_hierarchy_gravity option of the create_fp_placement command or
unchecking the “Hierarchical gravity” option in the Place Macro and Standard Cells dialog
box.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Pin Routing Aware

The -pin_routing_aware option specifies whether macro placement considers reserving
additional area for routing resources to pins of a block or plan group. By default,
pin-routing-aware placement is disabled. To enable this feature, specify the
-pin_routing_aware on option as in the following example:
icc_shell> set_fp_placement_strategy -pin_routing_aware on
With this option turned on, the placer considers pin information and creates macro-only
blockages along the edges of each plan group and soft macro so that macro cells do not
block the edges of the plan groups or soft macros. This reserves enough space along the
edges of the plan group or soft macro for pin assignment to place pins and for the router to
route nets to the pins.
Sliver Size
The -sliver_size option specifies the minimum channel size that is allowed to be
populated by standard cells. A sliver is a channel that is considered too small to allow
placement of any standard cells.
For example, suppose that you set the sliver size to 10 as follows:
icc_shell> set_fp_placement_strategy -sliver_size 10.0
In that case, the placer does not place any standard cells in a channel narrower than 10.0
microns wide, even if there is room for them. The default sliver size is 0.0, which means the
placer can place standard cells in any channel that has room.
You can use the -sliver_size option to prevent congestion in narrow channels that
currently contain standard cells. If there are several channels containing standard cells that
have a lot of congestion, set the sliver size to the largest width of those channels. The next
time you use the create_fp_placement command, the channels are cleared.
Figure 6-11 shows the placement of standard cells before and after setting the sliver size.
After placement with the sliver size set, the channels narrower than the specified sliver size
are left unfilled.

Figure 6-11 Channels Cleared by Setting the Sliver Size
Default behavior without sliver size setting After placement with sliver size
A sliver is a channel between any two of the following types of objects:

• A fixed or movable hard macro occupying at least 1/100 of the chip area
• A placement blockage occupying at least 1/100 of the chip area
• An edge of a plan group occupying at least 1/100 of the chip area
• An edge of the core area
The keepout margin of a hard macro is not included in the sliver size. Hard macro slivers are
measured from the edge of the keepout margin, not from the edge of the macro.
Snap Macros to User Grid

Use the -snap_macros_to_user_grid option to specify whether placed macros snap to the
user grid. It can be set to on or off. The default setting is off.
If you turn on this feature, the placer places the lower-left corner of each hard macro’s
bounding box on one of the grid points defined by the set_user_grid command. This
affects subsequent placement of macros but does not immediately affect existing placed
macros. This feature can be used to favorably align hard macros to power and ground
structures on upper metal layers.
Congestion-Related Options
These are the strategy options that control congestion-driven placement:
[-adjust_shapes on | off]
[-congestion_effort low | medium | high]

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The -adjust_shapes option determines whether the placer adjusts plan group shapes to
reduce congestion during congestion-driven placement. By default, this option is off and no
plan group shaping is performed during congestion-driven placement.
The -congestion_effort option controls the amount of effort applied to preventing
congestion during congestion-driven placement. It can be set to low, medium, or high. The
default behavior is low, in which the placer analyzes congestion by using the placement
congestion map. When this option is set to medium, the placer uses the routing congestion
map generated by the Zroute global router working at the minimum effort level. The high
setting is like the medium setting, except that the Zroute global router works at the default
effort level (medium) instead of the minimum level.
Net Weighting Options

These are the strategy options that control the amount of effort applied to minimizing
interface net lengths during virtual flat placement:
[-IO_net_weight weight]
[-plan_group_interface_net_weight weight]
The -IO_net_weight option specifies a weight applied to minimizing the lengths of I/O nets.
The default weight is 1.0, which gives I/O nets the same weight as all other nets. Specify a
lower weight, between 0.0 and 1.0, to give less weight to I/O nets; or specify a higher weight,
between 1.0 and 10.0, to give more weight to I/O nets. Set the weight higher to minimize I/
O net lengths, possibly at the expense of having longer nets elsewhere. Set the weight to
0.0 if I/O block placement has not been finalized and you want the placer help determine the
best I/O block locations.
Figure 6-12 shows flylines between I/O blocks and the rest of the chip after placement using
an I/O net weight of 1.0 (default) and an I/O net weight of 4.0. The I/O net lengths are shorter
when the higher weight is used.

Figure 6-12 I/O Net Weighting Results
Placement using default I/O net weight = 1.0 Placement using higher I/O net weight = 4.0
The -plan_group_interface_net_weight option specifies a weight applied to minimizing

the lengths of nets that cross the edges of exclusive plan groups. The default weight is 1.0.
Specify a lower or higher weight, in the range from 0.0 and 10.0, to apply less or more effort
in making these wires shorter. Specify a higher weight to pull cells closer to plan group
boundaries where interface nets cross that boundary.
Miscellaneous Options
These are miscellaneous strategy options that control virtual flat placement:
[-default]
[-block_constraint_file file_name]
[-flip_chip off | on | honor_reserved]
[-force_auto_detect_hierarchy on | off]
[-hierarchy_gravity_blocks list_of_names]
[-hierarchy_gravity_multi_level on | off]
[-honor_mv_cells on | off]
[-spread_spare_cells on | off]
[-virtual_IPO on | off]

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Reset to Default Settings

The set_fp_placement_strategy command option settings are cumulative. You can use
multiple commands to set multiple options. Each option remains in effect until you change it
with another set_fp_placement_strategy command.
To return all the set_fp_placement_strategy options to their default settings, use the
-default option:
icc_shell> set_fp_placement_strategy -default
To view the current settings, use the report_fp_placement_strategy command:

icc_shell> report_fp_placement_strategy
...
*** Macro related parameters ***
set_fp_placement_strategy -macro_orientation automatic | all | N
current setting: automatic
default setting: automatic
...
Block Constraint File

You can optionally set region and side-ordering constraints on specific blocks when
macros-on-edge placement is enabled (see “Macros on Edge” on page 6-18). To set the
constraints, create a block constraint file and use the -block_constraint_file option to
specify the file name. For example,
icc_shell> set_fp_placement_strategy -block_constraint_file my_blk_con
The block constraint file is a text file that lists the blocks, their respective regions where they
are to be placed, and an optional ordering number, in the following form:
fplModuleDestRegion block_name1 region_abbrev [order_number]
...
where block_name is the name of a plan group or second-level submodule, region_abbrev

is one of the region strings N, S, E, W, NE, NW, SE, or SW. (representing north, south, east, and
so on), and order_number is a relative ordering integer. For example,
fplModuleDestRegion PG_1 S 1
In this example, the blocks PG_1 through PG_4 are placed along the south edge of the chip
in numerical order.

Flip-Chip Driver Placement

The -flip_chip option specifies the placement method used for flip-chip drivers in the
design. It can be set to off, on, or honor_reserved. By default, it is set to off, which
disables flip-chip driver placement. Set it to on to enable flip-chip driver placement. The
honor_reserved setting causes the placer to perform reserved-slot insertion and
compression, if specified. Flip-chip driver placement occurs after placement of the signal
drivers. You must use the honor_reserved setting if you want to reserve driver slots.
Automatic Hierarchy Detection

The -force_auto_detect_hierarchy option of the set_fp_placement_strategy
command specifies whether the tool analyzes the logical hierarchy nodes that are left at the
top level of the design to determine if they are candidates for hierarchical gravity. This option
can be used on designs that contain existing plan groups either within the core area or
outside the core area. If the design does not contain plan groups, this option has no effect.
By default, this option is set to off.
If you set this option to on, the placement engine analyzes the logical hierarchy nodes that
are left at the top level of the design and not already assigned to any plan group to determine
if they are candidates for hierarchical gravity. If there are additional logical nodes outside of
the existing plan groups that contain top-level modules for grouping, the
create_fp_placement command places the cell instances inside these modules together.
This feature is based on the logical hierarchy only. Other placement constraints, such as
power domains or relative placement groups, do not affect the results.
Figure 6-13 shows an example of the logical hierarchy of a design in which there is an
existing plan group consisting of modules top/A11 and top/A12. When the auto-detect
hierarchy option is set to on, an additional logical hierarchy node outside of the existing plan
group is extracted. This logical hierarchy node consists of modules top/A13, top/A13/B12,
and top/A13/B13. The create_fp_placement command places the cell instances inside
these modules together.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 6-13 Example of Automatic Hierarchy Detection
TOP
Existing plan group Auto-detected hierarchy
A11 A12 A13
B11 B12 B13
Hierarchical Gravity
The -hierarchy_gravity_blocks option of the set_fp_placement_strategy command
specifies a list of blocks for hierarchical gravity placement. If you specify this option, the
create_fp_placement command does not perform automatic hierarchy detection. Instead,
it applies hierarchical gravity only to the blocks specified by using this option and any plan
groups already created in the design. This option can also be used on a netlist where the
logical hierarchy is flattened.
The -hierarchy_gravity_multi_level option, when set to on, specifies that the
create_fp_placement command considers multiple levels of logical hierarchy during
macro placement. The tool determines which hierarchy levels to consider based on macro
connectivity and places the macros from this hierarchy in close proximity. This option and
the -hierarchy_gravity_blocks option are mutually exclusive. By default, this option is
off.
Honor Multivoltage Cells

The -honor_mv_cells option of the set_fp_placement_strategy command specifies
whether to bring level-shifter and isolation cells closer to their respective voltage areas. The
default setting is off. Setting this option to on attaches a constraint to level-shifter and
isolation cells that causes them to be placed closer to their voltage areas. After setting this
option to on, you must use the link -force command to allow the placer to recognize the
dont_touch attribute on these cells.

Spread Spare Cells

By default, the create_fp_placement command spreads spare cells evenly across the
available space on the chip. Spare cells are cells that have no net connectivity, including
filler cells, and cells that connect only to high-fanout nets. To prevent even spreading of
spare cells, set the -spread_spare_cells option to off in the
set_fp_placement_strategy command. The default setting is on.
Virtual In-Place Optimization

The -virtual_IPO option of the set_fp_placement_strategy command specifies
whether virtual in-place optimization is performed during timing-driven virtual flat placement.
The default setting is off. Set this option to on to obtain better final timing results at the cost
of more runtime during timing-driven virtual flat placement.
Timing-driven placement is performed when you use the -timing_driven option with the
create_fp_placement command or select the “Timing driven” option in the Place Macro
and Standard Cells dialog box. With timing-driven placement, the placer makes a greater
effort to improve timing by keeping cells closer together along critical paths.
Virtual in-place optimization is the process of estimating the timing effects of optimization
performed by driver resizing and buffer insertion. This optimization is “virtual” because the
cells are not actually resized and buffers are not actually inserted. Instead, the tool
estimates the timing effects of optimization and annotates the design with the new timing
information. Estimating the timing effects of optimization is much faster than actually
performing the optimization.
The purpose of virtual in-place optimization is to allow the timing-driven placer to
concentrate its efforts on true critical paths and ignore timing paths that can be fixed later by
driver resizing or buffer insertion.
For example, a high-fanout net has a long delay that is easily fixed by buffer insertion.
Without virtual in-place optimization, the placer might see the long delay as a critical path.
As a result, it would try to place all the driven cells closer to the driver, an unnecessary action
that could hurt the timing of other paths by increasing the lengths of other wires connected
to the driven cells. However, with in-place optimization, the high-fanout net is annotated with
its optimized delay, so the placer ignores the timing of that net, and instead focuses its effort
on nets belonging to true critical paths.
Virtual in-place optimization can also be invoked as a separate process at any time in the
design planning flow by using the virtual_ipo command.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Hard Macro Constraints

You can control several aspects of hard macro placement during virtual flat placement by
using the set_fp_placement_strategy command. In addition, you can control other
aspects of hard macro placement by using the following commands:
• set_fp_macro_array – Sets macro array constraints
• set_fp_macro_options – Sets macro placement options
• set_fp_relative_location – Sets relative location constraints
The IC Compiler GUI makes it easy to set these constraints. To use the GUI, first make sure
that the command menus are in design planning mode (File > Task > Design Planning).
Then choose Placement > Macro Constraints, which opens the Macro Constraints dialog
box as shown in Figure 6-14.
Figure 6-14 Macro Constraints Dialog Box
The dialog box has three tabs, labeled Arrays, Options, and Relative. Click a tab to view a
list of macro constraints of that type that have been defined: array constraints, macro
placement options, or relative location constraints, respectively.
To create a new constraint, click the Add button. This opens another dialog box containing
the options for setting the constraints of the current tab setting.

Hard Macro Constraints 6-28
To edit or delete an existing constraint, select that constraint in the Macro Constraints list
and then click the Edit or Delete button.
The Color button applies a specified color to the display of the macros belonging to the
currently selected constraint. This feature helps you identify the location of the macros in the
layout view. The Zoom Fit button zooms the layout view to show just those macros.
The Reload button creates user-defined array constraints from automatically created arrays.
You can then edit these constraints to modify the automatically placed arrays.
For online help on using the dialog box, click its Help button.
The following subsections describe how to set the hard macro constraints:
• Macro Array Constraints
• Macro Placement Options
• Relative Location Constraints
After you set the hard macro constraints, close the Macro Constraints dialog box. When you
perform virtual flat placement by using the create_fp_placement command or by choosing
Placement > Place Macro and Standard Cells, the placer places the macros according to
the constraints you have set.
Macro Array Constraints

You can create user-defined arrays of hard macro cells. The cells are placed in the array
according to the constraints you specify.
When you create a user-defined array of hard macros, keep the following points in mind:
• The core area must be large enough to accommodate large macro arrays.
• You must specify the order of the macros for the array.
• You can group macros to form a one-dimensional or a two-dimensional array.
• Align one-dimensional and two-dimensional heterogeneous macro arrays by using the
“Align edges” option.
• Hard keepout areas are automatically created between the elements in the array.
If there are conflicting constraints on the macros, error messages are printed during
placement. However, the error messages do not print details about the conflicts.
Figure 6-15 shows some examples of one-dimensional and two-dimensional macro arrays.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 6-15 One-Dimensional and Two-Dimensional Macro Arrays
Two-dimensional macro arrays

One-dimensional macro arrays
B11 B12 B13

A1 A2 A3 A4
B21 B22 B22
1 x 4 array 2 x 3 array
C1 B11
B12
D1
B21 B22 B23
E1
Rectilinear B31 B32
array
3 x 1 array
Figure 6-16 shows different methods for aligning macros in an array: by macro edges, pin,
or offsets from core edges.
Figure 6-16 Alignment to Other Macros, Pins, and Edges
Align macro edges
Align
pins
Offset from core edge

(macro placement option)
You can specify macro array constraints with the set_fp_macro_array command:
set_fp_macro_array
-name string
[-elements collection_of_macro_cells]

[-align_edge t | b | l | r | c | top | bottom | left | right | center]

[-align_pins {list_of_two_pin_objects}]
[-x_offset float] [-y_offset float]
[-use_keepout_margin]
[-vertical] [-rectilinear]
[-align_2d lb | lc | lt | rb | rc | rt | cb | cc | cr |
left-bottom | left-center | left-top |
right-bottom | right-center | right-top |
center-bottom | center-center | center-top]
[-reset]
To report macro array constraints that have been set, use the report_fp_macro_array
command. For details, see the man pages for the set_fp_macro_array and
report_fp_macro_array commands.
To specify macro array constraints by using the GUI, first make sure that the command
menus are in design planning mode (File > Task > Design Planning). Then choose
Placement > Macro Constraints. In the Macro Constraints dialog box, click the Array tab if it
is not already selected. Then click the Add button. This opens the Macro Constraints - Add
Macro Array dialog box. See Figure 6-17.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 6-17 Macro Constraints - Add Macro Array Dialog Box
Macro cell
selection buttons
Macro cell name

array spreadsheet
Graphical preview of
array using current
constraint settings
The “Macro array name” box specifies a name for the macro array constraint. You can use
the default name or enter any name to identify this constraint.
Enter the dimensions of the array in the Rows and Cols boxes. A table displays an array of
cells having the specified dimensions. Enter the names of the macro cell instances into the
cells of the array. You can use the “Macro cells” selection buttons to select the macros
graphically from the layout view or select from a list of macro names.
Select the Rectilinear option if you want to allow rows or columns to have different numbers
of cells. In that case, you can leave some cells in the spreadsheet empty.
Select the Vertical option if you want a one-dimensional array to be placed as a vertical
column of cells rather than a row of cells.
The “Use keepout margin” option causes the macros to be placed as close together as
possible while observing the macro keepout margins. Alternatively, use the “Specified

offset” option to explicitly specify the minimum allowed spacing, in microns, between macro
edges in the x- and y-directions.
The “Align edges” option setting determines how to align the edges of macro cells of
different sizes in each row (or in each column if the Vertical option is selected). For a
one-dimensional array, the options are left, right, bottom, top, and center. For a
two-dimensional array, the options are left-bottom, left-top, left-center, and so on, so you can
specify the alignment in the x- and y-directions.
For an array containing exactly two macros, you can use the “Align two macro cells with
pins” option to align a specified pin of one macro to a specified pin of the other macro.
Click the Preview button to get a graphical preview of the array. The preview shows the
relative sizes, shapes, and alignments of macros in the array.
If you are satisfied with the preview, click the OK button to add the array constraint to the list
shown in the Macro Constraints dialog box. To edit this constraint, select it in the list in the
Macro Constraints dialog box and then click the Edit button.
Macro Placement Options

You can define placement constraints that restrict specified macro cells and macro arrays to
particular regions, orientations, and alignments. During virtual flat placement, macro cells
are flipped or rotated according to legal orientation constraints from the library or by
constraints you set.
You can specify the macro placement options with the set_fp_macro_options command:
set_fp_macro_options
collection_of_macro_objects
[-legal_orientations list]
[-anchor_bound tl | t | tr | r | br | b | bl |
l | tm | bm | lm | rm | c ]
[-x_offset float]
[-y_offset float]
[-align_pins list]
[-side_channel {left right top bottom}]
[-reset]
To report macro placement option settings, use the report_fp_macro_options command.

For details, see the man pages for the set_fp_macro_options and
report_fp_macro_options commands.
To specify macro placement options by using the GUI, first make sure that the command
Placement > Macro Constraints. In the Macro Constraints dialog box, click the Options tab
if it is not already selected. Then click the Add button. This opens the Macro Constraints -
Add Macro Options dialog box. See Figure 6-18.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 6-18 Macro Constraints - Add Macro Options Dialog Box
Copy selected macro

in layout view to
Macro objects box
View list of macros

and choose from list
Lock Macro objects
box to current selection
in layout view
macro placement area
In the “Macro objects” box, enter the names of one or more macro cell instances or macro
arrays to which the constraints apply. You can use the buttons to select the macros
graphically from the layout view or select from a list of macro instances and macro array
names.
You can use the “Align pins” option to place a single macro cell so that a specified pin of the
macro is aligned to a specified port, as shown in Figure 6-19. To do so, enter a single macro
name in the “Macro objects” box, select the “Align pins” option, and enter the port name and
the macro pin name. You can use the buttons to select the port and pin graphically or select
from a list of port names and macro pin names.

Figure 6-19 Aligning a Macro Pin to a Port

Port
DATA_IN[0]
Macro pin
DATA[0]
aligned
Core area
Use the “Legal orientations” options to restrict the allowed orientations of macro cells. If you
do not use this option, all orientations allowed in the physical library apply to the macro. This
option can be used for macro cells only, not macro arrays.
You can restrict placement of the macros or macro arrays to a specified region of the core
area such as the top half, the left half, or the bottom-right quadrant. To make such a
constraint, select the “Anchor bound” option and select the region to constrain by using the
“Value” list. Some of the possible choices are shown in Figure 6-20.
Figure 6-20 Anchor Bound Areas
top top-middle
bottom-left bottom-right bottom-middle
middle-left right center

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
For each anchor bound region setting, you can optionally specify an offset from the outside
edge or edges, further restricting placement of the macros or macro array. For example, if
you select “top” as the anchor bound, restricting placement to the top half of the core area,
you can also specify a “Y offset” or minimum distance away from the top core edge, as
Figure 6-21 Anchor Bound Offset From Outside Edge
Y offset
top
The “Anchor bound” is a soft bound, which means that the placer can move the macro cell
outside of the boundary area if there is not enough space available or if the cost is too high.
Whether or not you use the “Anchor bound” option, you can define side channels, which are
regions along the core edges where placement of macros is not allowed. To define side
channels, select the “Side channel” option and specify the channel sizes for the Left, Right,
Top, and Bottom edges of the core area, in microns. The macros are then placed at least the
specified distances away from the core edges. If a channel is not required on a side, leave
the channel at its default setting of zero. For example, if you set the Right channel to a
nonzero value, macros cannot be placed along the right edge within the specified distance.
If both anchor bound and side channel constraints are specified, both types of constraints
apply at the same time, as shown in the example in Figure 6-22.
Figure 6-22 Anchor Bound and Side Channel Constraints
y-offset for anchor bound
“top” anchor bound
Right-side channel
Click the Preview button to get a graphical preview of the anchor bound and side channel
constraints. In the example shown in Figure 6-23, the anchor bound constrains placement
to the blue area and the side channel constrains placement to the green area.

Figure 6-23 Anchor Bound and Side Channel Constraint Preview
If you are satisfied with the preview, click the OK button to add the placement constraint to
the list shown in the Macro Constraints dialog box. To edit this constraint, select it in the list
in the Macro Constraints dialog box and then click the Edit button.
Relative Location Constraints

A relative location constraint specifies the exact location of a macro cell with respect to an
object that has a fixed location, expressed as an x- and y-offset from the fixed object. The
macro to which the constraint applies is called the target macro. The fixed-location object is
called the anchor object. The anchor object can be the core area, a plan group, a fixed
macro cell, or a macro cell that is effectively fixed in place by having its own relative location
constraint.
You can specify relative location constraints with the set_fp_relative_location
command:
set_fp_relative_location
-name constraint_name
-target_cell cell_name
[-target_orientation N | S | E | W | FN | FS | FE | FW]
[-target_corner bl | br | tl | tr]
[-anchor_object object_name]
[-anchor_corner bl | br | tl | tr]
[-x_offset distance]
[-y_offset distance]

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The following additional commands operate on relative location constraints:

• report_fp_relative_location – Reports the relative location constraints that have
been set.
• extract_fp_relative_location – Extracts one or more relative location constraints
from the current layout, producing a set of set_fp_relative_location commands that
you can run later to restore the current placement.
• remove_fp_relative_location – Removes one or more relative location constraints
that have been set.
For detailed information about using these commands, see their man pages.
To specify relative location constraints by using the GUI, first make sure that the command
Placement > Macro Constraints. In the Macro Constraints dialog box, click the Relative tab
if it is not already selected. Then click the Add button. This opens the Macro Constraints –
Add Relative Location dialog box. See Figure 6-24.

Figure 6-24 Macro Constraints - Add Relative Location Dialog Box
Copy selected macro

in layout view to the
Name box
Lock the Name box to
the current selection in
layout view
View list of macros and
choose from list
anchor object, target
macro, and x- and
y-offset using current
constraint settings
The “Constraint name” box specifies a name for the relative location constraint. You can use
the default name or enter any name to identify this constraint.
Under “Anchor object,” in the Name box, enter the name of the anchor object, or leave this
box blank if the anchor object is the core area. The anchor object can be the core area, a
plan group, a fixed macro cell, or a macro cell that is effectively fixed in place by having its
own relative location constraint. Also, using the Corner list, specify the corner of the anchor
object from which to apply the x- and y-offsets.
Under “Target macro,” in the Name box, enter the name of the macro to which the constraint
applies. Also, using the Corner list, specify the corner of the target macro to be placed at the
x- and y-offsets from the anchor object. Select one Orientation option (N, W, S, E, FN, FW,
FS, or FE) to specify the orientation of the target macro to be placed.
In the “X offset” and “Y offset” boxes, enter the amount of offset from the anchor object
corner to the target macro corner, in microns. Each value can be positive, negative, or zero.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Click the Preview button to display a graphical preview of the anchor object, target object,
and x- and y-offsets between the active corners of these objects. The preview shows the
relative sizes, shapes, and alignments of the anchor and target objects.
If you are satisfied with the preview, click the OK button to add the relative location constraint
to the list shown in the Macro Constraints dialog box. To edit this constraint, select it in the
list in the Macro Constraints dialog box and then click the Edit button.
Blockages, Margins, and Shielding

A placement blockage is a region where hard macros cannot be placed. To create a
placement blockage, use the create_placement_blockage command or choose
Floorplan > Create Placement Blockage.
A keepout margin is a region along the edge of a macro where placement of other cells is
not allowed. To define a keepout margin for one or more macros, use the
set_keepout_margin command or choose Placement > Set Keepout Margin.
Block shielding is a strip of metal surrounding a macro that prevents crosstalk between wires
inside and outside the macro. To add shielding around macros or plan groups, use the
create_fp_block_shielding or choose Floorplan > Create Module Block Shielding.
Blockages and keepout margins are described in the following subsections. Shielding is
described in “Plan Group Overview” on page 7-3.
Placement Blockages
You might want to prevent the placement of hard macros in certain areas, for example, a
channel between two plan groups or next to a power pad. You can specify placement
blockages with the create_placement_blockage command:
create_placement_blockage
-bbox {llx1 lly1 urx1 ury1}
[-type {hard | soft | partial}]
[-blocked_percentage percentage]
[-no_register]
[-no_pin]
[-blocked_layers layers]
[-no_hard_macro]
[-name blockage_name]

Blockages, Margins, and Shielding 6-40
To report placement blockages that have been set, use the following script excerpt:
foreach_in_collection item [get_placement_blockages -quiet] {
puts "Name: [get_attribute $item name]"
puts " Type: [get_attribute $item type]"
puts " bbox: [get_attribute $item bbox]\n"
}
To remove placement blockages, use the remove_placement_blockage command. For

details on using these commands, see the man pages.
To specify placement blockages by using the GUI, choose Floorplan > Create Placement
Blockage. This opens the Create Placement Blockage dialog box. See Figure 6-25.
Figure 6-25 Create Placement Blockage Dialog Box
The Name box specifies a name for the blockage. You can use the default name or enter
any name to identify the blockage.
In the Coordinates box, enter the coordinates of the lower-left corner and upper-right corner
of the rectangular blockage area. To select the blockage area graphically in the layout view,
use the rectangle button next to the box.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Select one of the following five blockage types:

• Hard blockage – No hard macros or standard cells are allowed in the blockage area.
• Soft blockage – No hard macros or standard cells are placed in the blockage area
initially, but they can be moved into the area during optimization and legalization.
• Partial blockage – Hard macros or standard cells are allowed, but the placer prevents
them from occupying more than the specified percentage of the blockage area.
• Hard macro blockage – No hard macros are placed in the blockage area, but standard
cells and pins are allowed.
• Pin blockage – In the blockage area, the pin placer does not assign pins and the global
router does not add routes using the specified layer or layers.
Click OK or Apply to create the blockage.

You can control the display of blockages in the layout window by using the View Settings
panel (View > Toolbars > View Settings).
To remove blockages, use the remove_placement_blockage command.
As a result, the tool places automatically grouped macros away from hard macro blockages.
To allow the tool to place macros closer to hard macro blockages, specify the
-macros_avoid_hard_macro_blockage_vicinity false option to the
set_fp_placement_strategy command.
Keepout Margins
You can specify keepout margins or padding around some or all macros. During virtual flat
placement, all other cells, including standard cells and other macros, are placed outside the
specified margin. This can help prevent congestion and DRC errors.
This is the syntax of the set_keepout_margin command:
set_keepout_margin
[-type hard | soft]
[-outer {lx by rx ty}]
[-tracks_per_macro_pin value]
[-min_padding_per_macro value]
[-max_padding_per_macro value]
[-all_macros]
[-macro_masters]
[-macro_instances]
[-north]
[object_list]

To report keepout margins that have been set, use the report_keepout_margin
command. To remove keepout margins, use the remove_keepout_margin command. For
details on using these commands, see the man pages.
To specify keepout margins by using the GUI, choose Placement > Set Keepout Margin.
This opens the Set Keepout Margin dialog box. See Figure 6-26.
Figure 6-26 Set Keepout Margin Dialog Box
Under “Type,” select the keepout margin type, Soft or Hard. A soft keepout margin prevents
other cells from being placed within the margin, but the cells can be moved in during
optimization and legalization. A hard keepout margin never allows other cells within the
margin.
Under “Cells,” specify the cells affected by the command. You can choose all macros,
specified reference cells (“Specified masters” option), or specified cell instances. The
buttons next to the text box let you choose the cells graphically in the layout view or choose
from a list of cells.
Under “Outer margin,” select “Use specified outer keepout coordinates” to explicitly specify
the margins on each side of the macro, in microns.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
If you selected “All macros,” you can optionally select “Derive outer keepout coordinates” to
automatically calculate the margins of all macro cells. In that case, the margin is set
according to the number of pins on each side. An automatically calculated keepout is a hard
keepout constraint. By default, the margin for each side is set to the number of macro pins
multiplied by one-half the track width, which allows enough space for parallel connections to
the pins from both sides, as shown by the example in Figure 6-27.
Figure 6-27 Automatically Derived Keepout Margin
Keepout margin:
8 pins x 0.5 tracks/pin
= 4 tracks
8 pins
Hard macro
You can specify the number of tracks per pin used in the calculation. For a macro with a
large number of pins, use a value between 0.5 and 1.0 tracks per pin to reserve enough
room for routing the connections. You can also specify a minimum margin and a maximum
margin, in microns, to restrict the allowed range of calculated keepout margins. The default
maximum margin setting, -1, causes the maximum limit to be 40 times the metal1 pitch.
Select the “Set margin with respect to north orientation of the cell” to keep the specified
margin values with respect to the north orientation of the cell when the cell is rotated.
Click OK or Apply to create the keepout margins.
If you do not specify any keepouts, the placer automatically derives the keepouts using 0.5
tracks per pin by default.
You can control the display of keepout margins in the layout window by using the View
Settings panel (View > Toolbars > View Settings). Only explicit (not automatically
calculated) keepout margins can be displayed.
To remove explicit keepout margins, choose Placement > Report Keepout Margin.
Relative Placement Groups

The create_rp_group command creates relative placement groups. A relative placement
group is an association of cell instances, other hierarchical relative placement groups, and
placement keepouts. A group is defined by the number of rows and columns that it uses.

Relative Placement Groups 6-44
Use the add_to_rp_group command to add leaf cells to a relative placement group. The
relative placement information is automatically saved in the Milkyway design database when
you save the design in Milkyway format using the save_mw_cel command. It contains the
height and width of the top-level relative placement groups and the x- and y-offsets of the
cell instances, placement keepouts, and hierarchical relative placement groups for each
top-level relative placement group. The x- and y-offsets are used to anchor the relative
placement cell instance with respect to the lower-left corner (the relative placement’s origin)
of its corresponding relative placement group.
During the design planning flow, you can perform the following relative placement functions:
• Apply compression by using the -compress option.
• Specify the anchor location by using the -x_offset and -y_offset options.
• Specify the utilization percentage by using the -utilization option.
• Ignore the relative placement group by using the -ignore option.
However, you should not use the following relative placement functions during virtual flat
placement:
• Specifying the group alignment pin by using the -pin_align_name option.
• Specifying the right alignment by using the -alignment bottom_right option.
• Allowing keepouts over tap cells by using the -allow_keepout_over_tapcell option.
• Legalizing individual objects in a relative placement group.
You can use the create_fp_placement command to place cell instances in each relative
placement group during initial virtual flat placement. By using the create_fp_placement
and create_placement commands to place the cells in each relative placement group in
the same way, the create_fp_placement command can provide you with better wire length
and congestion estimates for your floorplan.
To achieve a good correlation between the create_fp_placement and
create_placement commands when placing the relative placement cells, the following
conditions apply.
• If the cell instances in one relative placement group belong to different move bounds, the
create_fp_placement command ignores this relative placement group. This also
applies to plan groups automatically extracted by the create_fp_placement command
based on the logical hierarchy.
• No cell instances are placed over relative placement keepouts.
• If any cell instance in one relative placement group is fixed, this relative placement
grouping is ignored by the create_fp_placement command and the cells are treated as
nonrelative placement cells.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The create_fp_placement -no_legalize command supports two types of relative

placement groups, including the macro-only and standard-cell-only relative placement
groups. The virtual flat placement stage allows the following relative placement objects to
occupy multiple column and row positions: leaf cells, keepouts (hard, soft, and space),
hierarchical groups, and relative placement cells.
Placing Relative Placement Groups

By default, relative placement is supported during initial virtual flat placement. The
create_fp_placement command extracts information about the relative placement groups
from the Milkyway database. A dummy cell, which contains both macros and standard cells
in one relative placement group, is created for each top-level relative placement group. The
Milkyway properties of the relative placement group are modified based on the new
locations of the placed dummy cells. All relative placement cell instances are temporarily
fixed. Any dummy cells related to the top-level relative placement groups are removed. This
allows the create_fp_placement command to place other standard cell instances over the
free spaces inside the relative placement bounding boxes.
The create_fp_placement command honors the specified placement keepouts when it
places the cell instances in the relative placement group, and no cell instances in the relative
placement group are placed over the keepout areas.
Using the Default Relative Placement Flow

Use the default relative placement flow if you do not want to fix the relative placement
groups after you run the create_fp_placement command.
Figure 6-28 shows the default relative placement flow.
Figure 6-28 Default Relative Placement Flow
create_fp_placement
place_opt
Use the legalize_placement command to automatically legalize the standard cells. The
standard cells in relative placement groups might be moved outside of the corresponding
relative placement bounding box during legalization.

Using the Relative Placement Cells Flow

Use the relative placement cells flow if your design contains either macro-only or standard
cell-only relative placement groups and you need to fix the relative placement groups after
floorplanning to ensure the exact relative placement constraints are met.
1. Define the relative placement constraints.
❍ Create the relative placement groups by using the create_rp_group command.
❍ Add relative placement objects to the groups by using the add_to_rp_group
command.
2. Run virtual flat placement by using the create_fp_placement -no_legalize
command.
3. Set the is_fixed attribute to true for all macros.
4. Legalize your design by using the legalize_placement command.
5. Set the is_fixed attribute to true for all relative placement cells.
6. Perform physical placement by using the place_opt command.
Figure 6-29 shows the flow for fixing the relative placement cells.
Figure 6-29 Fixing the Relative Placement Cells Flow
create_fp_placement -no_legalize
legalize_placement
Fix the relative placement cells
place_opt
Use this flow to perform virtual flat placement if your design contains relative placement
groups that have mixed macros and standard cells.
1. Run virtual flat placement by using the create_fp_placement -no_legalize
command.
2. Set the is_fixed attribute to true for all macros.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
3. Legalize your design by using the legalize_placement command.

4. Set the is_fixed attribute to true for all macros and standard cells in the relative
placement groups.
5. Continue the design planning flow.
Propagating Relative Placement Groups by Commit and Uncommit

During the commit and uncommit hierarchy steps of the design planning flow, the
commit_fp_plan_groups and uncommit_fp_soft_macros commands support relative
placement groups, including hierarchical relative placement groups. The
commit_fp_plan_groups command converts plan groups into new soft macros. If the plan
group includes relative placement groups, they are automatically propagated from the
top-level design to soft macros. The uncommit_fp_soft_macros command converts soft
macros into top-level plan groups. If the soft macro includes relative placement groups, they
are automatically propagated to the plan group that is at the top level.
Committing Relative Placement Groups

As described in the following steps, for each plan group that the commit_fp_plan_groups
command processes, the relative placement groups are searched to determine if they
belong to the plan group that is being committed.
1. All relative placement groups in the top-level design are examined and for each relative
placement group, the cell instances of the hierarchy are examined to see if they belong
to a descendant of a plan group’s logical hierarchy.
2. If cell instances that belong to each relative placement group are determined to be
logical descendants of the plan group’s logical hierarchical cell instance, the relative
placement group is processed by the commit_fp_plan_groups command, and an
exact copy of it is created in the new soft macro, according to its placement within the
plan group boundary.
Any keepout blockages associated with the relative placement group are pushed down,
and the cell instances are assigned to the relative placement group. The keepout
blockages are also checked to see if they are included within the plan group boundary. If
they extend outside the plan group boundary, a warning message is issued, but the
commit process continues.
3. After all relative placement groups that belong to the plan group are pushed down, a link
step occurs that populates hierarchical attachment lists in some of the relative placement
groups that have hierarchical trees. Relative placement group instances are also
instantiated.

Uncommitting Relative Placement Groups

For each soft macro that the uncommit_fp_soft_macros command processes, all relative
placement cells in the relative placement groups are replicated in the top-level design
according to the hierarchical cells and the hierarchical cell instance references within the
soft macro.
Design Flow for Hierarchical Relative Placement Groups

Figure 6-30 shows the flow for designs that contain hierarchical relative placement groups.
Figure 6-30 Hierarchical Relative Placement Group Design Flow
Place and legalize top-level design with
relative placement groups
Fix the locations of relative placement

groups with set_dont_touch_placement
Perform block-level place and route
uncommit_fp_soft_macros
write_rp_groups -all -nosplit \

-output afu.tcl
check_rp_groups -all -verbose
report_rp_group_options
Use the following flow for designs that contain hierarchical relative placement groups.
1. Place and legalize the design with hierarchical relative placement groups by using the
create_fp_placement -no_legalize and legalize_placement commands.
2. Convert plan groups into soft macros, also called child cells or physical blocks, by using
the commit_fp_plan_groups command.
The command extracts relative placement groups that belong to the plan group from the
top CEL view and pushes them down to soft macros. Each soft macro is a CEL view of
the block in the same Milkyway design library.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
3. Fix the locations of the relative placement groups, which include macros, by using the
set_dont_touch_placement command.
4. Perform place and route on each soft macro independently.

5. Convert all soft macros into plan groups by using the uncommit_fp_soft_macros
command.
During uncommit hierarchy, the soft macro child cell instances are pushed back up to the
top CEL view.
6. After the uncommit process, you can check the validity of the relative placement groups
by using the following commands:
icc_shell> write_rp_groups -all -nosplit -output afu.tcl
icc_shell> check_rp_groups -all -verbose
icc_shell> report_rp_group_options
Placement Evaluation
No straightforward criteria exist for evaluating the initial placement of hard macros.
Measuring the quality of results (QoR) is subjective and often depends on practical design
experience. You should observe some basic rules when measuring QoR, such as pushing
hard macros to the core boundary and aligning similar hard macros. However, the most
important issues are timing and routability.
QoR can be measured by the following criteria:
• Routability
You can measure the routability of your design by analyzing the routing congestion
produced by the global router. The data used to analyze congestion consists of a textual
report and visual heat maps that show where the routing congestion hotspots exist in the
design. Highly congested designs might not be routable. Hard macros tend to create
congestion around their edges and corners. You should analyze hard macro placements
for routability early in the design cycle.
• Timing
Timing calculations can use the placement information to better estimate interconnect
loading. The interconnect timing calculations should take into account detours in routes
caused by the presence of hard macros. Good placement minimizes timing violations.
• Wire length
Smaller values of total wire length are a good indicator of placement quality. The total
wire length is reported in the placement log file. You should monitor this number when
you assess multiple placement solutions.

Placement Evaluation 6-50
Another aspect of wire length is localized to hard macros. By looking at the signal (flyline)
connections of a hard macro, you can quickly determine whether the hard macro is
placed in an optimal location. For example, a hard macro placed in the lower-left corner
of the core area that is extensively connected to logic in the upper-right corner of the die
indicates a poor location for the hard macro.
• Data flow
If you know the logic and intended operation of the design, you can assess the data flow
by using the hierarchical browser at any stage in the design flow to observe where logical
modules and hard macros are physically placed. Using this technique can help you make
sensible placement decisions.
• Standard cell placement areas
You can visually assess the placement of macros and standard cells. Small areas
surrounded by hard macros usually cause congestion hot spots. Unless the connections
to and from standard cells in these areas are completely localized, it is difficult to
complete the connections from within these areas to the objects outside these areas.
Generally, a contiguous standard cell placement area without bottlenecks is desirable.
After passing these QoR measurements, the placement result qualifies as a good starting
point for further manual tuning.
Placement Quality of Results Report

You can generate a quality of results (QoR) report for virtual flat placement by using the
report_fp_placement command. The command reports the following information:
• Total wire length

• Number of regions with high density
• Number of regions with low density
• Number of overlaps between hard macros
• Number of overlaps between hard macros and standard cells
• Number of overlaps between plan groups
• Number of cells that are not inside their respective plan groups (or core area)
• Number of cells violating the core area
If your design does not have channels, you can use the -check_abutment option to check
for the abutment of each soft and hard macro with the surrounding macro cell instances. The
abutment check reports gaps detected between the macro cell instances.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Evaluating Macro Placement

Poor macro placement might cause high congestion, timing problems, and other design
issues. You can quickly evaluate the quality of the macro placement in your design and
report a placement score by using the evaluate_macro_placement command.
evaluate_macro_placement
[-ignore_std_cell_placement]
[-misaligned_channel_relative_weight weight]
[-net_detour_relative_weight weight]
[-swimming_pool_relative_weight weight]
[-thin_channel_relative_weight weight]
[-wirelength_relative_weight weight]
You can use the evaluate_macro_placement command to measure macro placement

quality and compare the results among several different design iterations. The command
produces a score between 0 and 100 that represents the relative level of placement issues
in your design. A lower score represents a relatively better placement.
You can fine-tune the weighted macro placement score by specifying the following options
to the evaluate_macro_placement command. Table 6-1 describes the command options
that control the weight settings.
Table 6-1 evaluate_macro_placement Weight Options
Option Description
-misaligned_channel_relative_weight Weight for consecutive channels in the same

direction that are not aligned.
-net_detour_relative_weight Weight for expected net detours due to macro

placement.
-swimming_pool_relative_weight Weight for regions surrounded by macros.
-thin_channel_relative_weight Weight for narrow channels between macros that are

wide enough for standard cell placement.
-wirelength_relative_weight Weight for the wirelength of nets connected to

macros.
By default, the weight is 0.2 for each of the previous options. If you specify a cumulative
weight that is not equal to 1.0, the tool adjusts each weight proportionally such that the sum
of all weights is 1.0.
The following examples illustrate the results of the evaluate_macro_placement command
on two different placements. In Figure 6-31, the design on the left contains a typical

placement. The design on the right of the figure contains a swimming pool in upper right of
the layout. This swimming pool region is a standard cell placement area that is completely
surrounded by hard macros.
Figure 6-31 Example Macro Placements
Typical placement Placement

with swimming pool
The output of the evaluate_macro_placement command for the typical layout shows a
weighted cost of 6. The command output is as follows:
icc_shell> evaluate_macro_placement
Reading database ...
Checking for macro overlaps ... none
Swimming pools ... area: 1506
Net detours ... length: 158215
Wirelength (nets connected to macros) ... 362009
Thin channels ... 4
Misaligned channels ...1 pair
relative actual weighted

metric cost weight weight cost
---------------------------------------------------------
swimming pools 3 1.000 0.200 0.600
net detours 1 1.000 0.200 0.200
wirelength 23 1.000 0.200 4.600
thin channels 2 1.000 0.200 0.400
misaligned channels 3 1.000 0.200 0.600
---------------------------------------------------------
overall cost 6

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The output of the evaluate_macro_placement command for the layout that contains the
swimming pool shows a weighted cost of 11. The command output is as follows:
icc_shell> evaluate_macro_placement
Reading database ...
Checking for macro overlaps ... none
Swimming pools ... area: 130578
Net detours ... length: 265286
Wirelength (nets connected to macros) ... 325924
Thin channels ... 2
Misaligned channels ...1 pair
relative actual weighted

metric cost weight weight cost
---------------------------------------------------------
swimming pools 28 1.000 0.200 5.600
net detours 2 1.000 0.200 0.400
wirelength 20 1.000 0.200 4.000
thin channels 2 1.000 0.200 0.400
misaligned channels 4 1.000 0.200 0.800
---------------------------------------------------------
overall cost 11
Total Wire Length Estimate

You can use the get_fp_wirelength command to evaluate the overall placement quality.
The command generates vertical, horizontal, and total wire length statistics for the top-level
signal nets in your design. It also calculates the virtual route wire length as a minimum length
needed to connect all the pins.
Floorplan Editing
You can use the IC Compiler tool to perform the following floorplan editing operations:
• Create and delete objects
• Move, rotate, align, distribute, and spread objects
• Fix and unfix objects for editing
• Undo and redo edit changes
• Resize, expand, reshape, and split objects

Floorplan Editing 6-54
You can perform many types of editing in the GUI layout view. To display or remove the
toolbars containing the editing command buttons, use View > Toolbars > Edit and View >
Toolbars > Advanced Edit. The editing buttons and their functions are shown in Figure 6-32.
Figure 6-32 GUI Editing Tools
Fix Edit
Unfix Edit
Toggle Snapping
Create Edit Group
Open Properties Dialog Box
Move/Resize Objects
Copy Objects
Delete Objects
Create Route Shapes (Advanced Route Tool)
Split Shapes
Stretch Wires
Window Stretch
Push Objects
Spread Wires
Rotation/Orientation (90 clockwise)
Set Object Shape (Rectangle)
Reshape Objects
Align/Distribute Objects
Move Pins on Edge
Cut With Fixed Shape
Expansion (Expand All)
Offset for Expand or Cut With Fixed Channel
For example, to move a hard macro, use the selection tool (arrow button) to select the
macro. Click the move and resize tool button. The pointer changes to a four-way arrow
shape. Place the pointer on the macro, and drag it to the new location.
Instead of clicking the move/resize button, you can go to the command menu and choose
Edit > Move/Resize, or you can press the M key on the keyboard. The command menu
shows the button and keyboard shortcut associated with the command, as shown in
Figure 6-33.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 6-33 Moving an Object With the Move/Resize Tool
For detailed information about using the GUI to perform editing tasks, see the “Editing a
Design” topic in IC Compiler online Help and the Using GUI Tools appendix in the IC
Compiler Implementation User Guide.
Removing Cell Placement

You can move (unplace) all movable macro cells or standard cells and place them in a new
location by using the remove_placement command. The command does not affect cells
with is_fixed true or dont_touch attributes assigned to them. This is the command
syntax:
remove_placement
[-object_type standard_cell | macro_cell | all]
[-new_location top_right | origin | center]
By default, the remove_placement command by itself moves all movable standard cells and
macro cells to outside of the chip and spreads them out, effectively taking you back to the
starting point of the placement task.

To move only the standard cells or only the macro cells, use the -object_type option. To
move the cells to the origin, chip center, or top and right sides of the chip, use the
-new_location option.
To delete other floorplan objects at the design planning stage such as placement blockages,
bounds, plan groups, voltage areas, plan group padding, and block shielding, choose
Floorplan > Delete Floorplan Objects in the GUI and select the type of objects you want to
delete. You can also use one or more of the following commands to remove floorplan
objects: remove_placement_blockage, remove_bounds, remove_plan_groups,
remove_route_guide, remove_voltage_area, remove_fp_plan_group_padding,
remove_fp_block_shielding, or remove_track.
Packing Hard Macros Into an Area

After performing virtual flat placement, you can specify an area (region) and automatically
pack selected hard macros along the edges of that area.
To automatically pack hard macros into an area,
1. Choose Placement > Pack Macro Cells.
The Pack Macro Cells dialog box appears. See Figure 6-34.
Figure 6-34 Pack Macro Cells Dialog Box
Alternatively, you can use the pack_fp_macro_in_area command.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
2. Set the options, depending on your requirements.

❍ Pack design – Packs all objects in the core area.
❍ Pack macro cells of specified plan groups – All hard macros belonging to the selected
plan groups are packed inside the plan group boundaries. If a plan group boundary is
outside the core area, any macros belonging to that plan group are ignored. Top-level
macros and macros belonging to other plan groups are also ignored.
❍ Pack all macro cells – Select this option to pack all macro cells inside the core area.
Any top-level macros are also packed into the remaining area.
❍ Pack specified macro cells – Select this option to pack only the specified macro cells
into the core area. If a polygon or rectangle is selected (it can be on any layer except
a blockage layer) together with hard macros, the hard macros are packed into the
selected polygon or rectangle.
❍ Preferred edges – Specify the edges along which to pack the macros.
You can specify one or more edges along which to pack the hard macros: Left, Right,
Top, or Bottom. These are the preferred edges for placing the macro cells. For
example, if you select Left, Top, and Bottom, the macro cells are placed along those
edges first, arranging them in a “C” shape.
Selecting all four edges causes the macro cells to be placed along all four edges,
arranging them in an “O” shape. This is different from specifying no edges, which
causes placement to be based on other considerations, such as wire length.
3. Click OK or Apply.
Manually Adjusting the Hard Macros

To manually adjust the hard macros, you should observe the following principles, in addition
to applying your own criteria:
• Follow the given relative locations from the hard macro placement command
(create_fp_placement).
• Avoid isolated standard cell placement areas enclosed by a ring of hard macros.
• Avoid narrow standard cell placement areas in channels (slivers) between hard macros.
• Align similar hard macros.
• Push large hard macros to the core boundary.
• Create a rectangular placeable area for standard cell placement.

The Align objects and Distribute objects buttons on the Edit toolbar are particularly helpful
for adjusting your hard macros.
Using Constraints With the Core and Die Editing Commands

You can use the -keep_placement and -keep_pad_to_core_distance options with the
editing commands that are relative to the core and die. Using these options makes it easier
and more convenient to refine and debug core and die commands.
These options are effective only when they are applied to the following core and die editing
commands:
set_object_boundary
resize_objects
set_object_shape
window_stretch
move_objects
cut_objects
When you move or change a core or die, you can use the move_objects -keep_placement
command to ensure that standard cells and hard macros remain within the boundary of the
parent object (for example, the core, the die, or a plan group).
You can use the -keep_pad_to_core_distance option to maintain the distance between
the core and the I/O pad cells. This option also maintains the distance between the core and
the die. This forces changes to the core and die to be made in tandem. If the I/O pad cells
are absent, the core-to-die distance is still maintained.
Note:
After moving or resizing objects, the resulting placement is not legalized. You must
explicitly legalize the placement by using the legalize_placement command.
Voltage Area Planning

You can automatically place and shape voltage areas, including voltage areas that are
physically nested. You can also create voltage areas outside the chip area.
This section includes the following topics:
• Supported Voltage Area Physical Boundary Scenarios
• Updating Voltage Areas in a Design
• Removing Voltage Areas

Voltage Area Planning 6-59
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Using the IC Compiler tool, you can define voltage areas at any level of a logic hierarchy. A
voltage area can be a single rectangular or rectilinear shape or can consist of multiple
disjoint rectilinear and rectangular shapes.
Power domains and voltage areas should maintain a one-to-one mapping relationship. A
power domain and its matching voltage area should have the same name and same set of
hierarchical cells. When a power domain is mapped with the voltage area, the associated
logic information is automatically derived from the power domain.
Voltage areas can be explicitly associated with existing power domains, or they can be
created without specifying any explicit association with power domains. They can also be
created when no power domains have been defined for the design.
A given voltage area can contain one or more physically nested voltage areas. A voltage
area must completely contain its nested voltage areas. These nested voltage areas
correspond to logically nested power domains. Voltage areas that would overlap physically
must be resolved into nonoverlapping, abutted rectangular or rectilinear subareas.
Intersecting voltage areas are not supported.
Planning the location and shape of voltage areas requires the following steps:
1. Create a voltage area of a specific geometry on the core area of the chip.
Choose Floorplan > Create Voltage Area.
The Create Voltage Area dialog box appears. See Figure 6-35.

Figure 6-35 Create Voltage Area Dialog Box
Alternatively, you can use the create_voltage_area command.

❍ Name – Specify the name of the voltage area you want to create.
If you specify this option, you must also provide a list of hierarchical cells that are
contained within the voltage area. The logical hierarchies are assigned to specific
voltage areas when you create or update these voltage areas.
❍ Power Domain – If your design contains power domains, you can use this option with
the corresponding power domain name to create a voltage area. Then the power
domain name is also the voltage area name. After the voltage area is created, the
power domain contains the corresponding boundary information.
In this case, do not specify a list of hierarchical cells. The cell list is provided in the
power domain definition. Power domains and voltage areas should maintain a
one-to-one mapping relationship. A power domain and its matching voltage area
should have the same name and same set of hierarchical cells. The tool places these
cells in the given voltage area. Using the power domain option ensures the correct
alignment of the logical hierarchies with the voltage areas.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
❍ Horizontal guard band width and Vertical guard band width – You can use guard
bands to ensure that no shorts occur at the boundaries of the voltage areas. Guard
bands define hard keepout margins surrounding the voltage areas. No cells, including
level shifters and isolation cells, can be placed within the guard band margins.
For example, use guard bands when the rows are the same for all the voltage areas.
The guard bands guarantee that the cells in different voltage areas are separated so
that power planning does not introduce shorts.
You can specify a guard band width in the horizontal and vertical direction when
creating or updating voltage areas.
❍ Target utilization – Specifies the target utilization for the voltage area during shaping.
You must specify a utilization value between 0.1 and 1.0. The default utilization is the
same value used for the rest of the design. Larger utilization values result in smaller
voltage areas, with less extra space allowed for routing.
To change the target utilization, you must use the remove_voltage_area command
to remove all voltage areas or specified voltage areas from the design, and then
re-create the voltage area and the new target utilization value.
❍ Bounding Boxes – If you know an ideal location for a voltage area, you can direct it
by specifying explicit coordinates. The voltage area geometry can be a rectangle or a
rectilinear polygon.
To define a rectangular voltage area, select the rectangular-shaped button, and type
the x- and y-coordinates for the lower-left and upper-right corners of the rectangle in
the Coordinates box.
To define a rectilinear voltage area, select the rectilinear-shaped button, and type the
x- and y-coordinates for each corner of the polygon in the Coordinates box.
After the user-defined voltage areas are created, the tool automatically derives a
default voltage area for placement of cells not specifically assigned to any voltage
areas.
❍ Set as fixed – You can place newly created voltage areas inside the core in fixed
locations. The voltage areas with the is_fixed attribute set to true are ignored by
the shape_fp_blocks command and are not reshaped. By default, this option is off.
❍ Color cell instances – (Optional) Select a method for coloring cells in the voltage area.
To disable cell coloring, select None.
To cycle through the available colors, select Cycle. This is the default.
To apply a specific color, select Specified and select a color in the color list.

3. Use the create_fp_placement command to place the design, keeping voltage area
cells together. You can also choose Placement > Place Macro and Standard Cells.
4. Use the shape_fp_blocks command and options to automatically shape and place the
voltage area boundaries. You can also choose Placement > Place and Shape Plan
Groups. For more information, see “Shape Plan Group Command” on page 7-12.
For more information about voltage areas in multivoltage designs, see Defining and Using
Voltage Areas in the IC Compiler Implementation User Guide. For more information about
nested voltage areas in multivoltage designs, see Handling Nested Voltage Areas in the IC
Supported Voltage Area Physical Boundary Scenarios

The following voltage area physical boundary scenarios are supported.
• The voltage area boundary encloses the plan group core boundary, as shown in
Figure 6-36.
Figure 6-36 Voltage Area Boundary Encloses Plan Group Boundary
TOP
Voltage area boundary
Plan group
core boundary
Plan
group
During commit hierarchy by using the commit_fp_plan_groups command, the physical

voltage area boundary is not copied down into the soft macro, and child cell instances
are not assigned logically to any nondefault voltage areas. The power domain is updated
to swap the hierarchical cell with the new cell instance.
During uncommit hierarchy by using the uncommit_fp_soft_macros command, the soft
macro child cell instances are pushed back up to the top CEL view, and are reassigned
logically to the original top cell nondefault voltage area.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• The voltage area boundary is contained by the plan group core boundary, as shown in
Figure 6-37.
Figure 6-37 Voltage Area Boundary Contained by Plan Group Boundary
TOP Plan group

Plan group
core boundary
Voltage area
boundary
During commit hierarchy, the physical voltage area boundary is copied down into the soft
macro, and the child cell instances are assigned logically to their respective voltage
areas. The effects on associated power domains are not considered.
During uncommit hierarchy, the soft macro child cells are assigned logically to the
original top cell nondefault voltage area.
Updating Voltage Areas in a Design

After you have created voltage areas and associated hierarchical cells with them, you can
use the update_voltage_area command to add or remove cells from specified voltage
areas. You can use the get_voltage_areas command instead of explicitly specifying
voltage area names. By adding or removing cells, you can adjust the utilization of the
voltage area. However, you might prefer to change the size of the voltage areas and keep
the utilization the same.
Removing Voltage Areas

Use the remove_voltage_area command to remove all voltage areas or specified voltage
areas from the design. This includes removing any move bounds and guard bands
belonging to the voltage area. If you remove a logically nested voltage area, the logical
hierarchy inherits the voltage properties of the parent hierarchy.
Placing Multiply Instantiated Modules

You can perform virtual flat placement of multiply instantiated modules. Multiply instantiated
modules are physically represented in the design as plan groups and have the same
reference. A set of these instantiated modules is called a multiply instantiated module group.

Placing Multiply Instantiated Modules 6-64
A design can have more than one multiply instantiated module group. If for example,
modules A1 and A2 have reference A, and modules B1 and B2 have reference B, two
multiply instantiated module groups are formed. Many designs use multiple instances of the
same logic block to create the required functionality. By using the same block for similar
operations, the design time is reduced.
• Identifying Multiply Instantiated Modules
• Identifying Multiply Instantiated Module Plan Groups
• Shaping Multiply Instantiated Module Plan Groups
• Placing and Analyzing Multiply Instantiated Module Plan Groups
• Flipping Multiply Instantiated Module Plan Groups
• QoR Analysis of Multiply Instantiated Module Plan Groups
Identifying Multiply Instantiated Modules

Before you can place the multiply instantiated modules, you must first determine which plan
groups and soft macros are to be considered as multiply instantiated modules. This can be
done by using the uniquify_fp_mw_cel -store_mim_property command to store the
multiply instantiated module information in the Milkyway database as a multiply instantiated
module property. After uniquification, other IC Compiler design planning commands can
access the multiply instantiated module information and treat the cell instances with these
attributes as multiply instantiated modules in the virtual flat placement design planning flow.
The uniquify_fp_mw_cel command uses the following syntax:
uniquify_fp_mw_cel -store_mim_property cell_instances
For example:
icc_shell> uniquify_fp_mw_cel \
-store_mim_property [get_cells {instA instB instC}]
If you specify the -store_mim_property option, the tool sets the mim_master_name
attribute to the reference design name for the specified cell instances.
Creating Unique Block Abstractions From Multiply Instantiated

Modules
The uniquify_fp_mw_cel command removes multiply instantiated hierarchical library cells
and creates a unique hierarchical library cell for each hierarchical cell instance. If your
design contains block abstractions, the command removes the specified multiply

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
instantiated block abstraction modules and creates unique block abstraction leaf cells. To
create unique block abstractions, specify the -block_abstractions instances option. If
you specify both the -block_abstractions and -store_mim_property options, the
multiply instantiated module (MIM) property is set on the instances you specify. In this case,
the allocate_fp_budgets command recognizes the instances as multiply instantiated
modules, even though the references are unique. Information to control transparent
interface optimization might be lost after running the uniquify_fp_mw_cel command. To
restore the transparent interface optimization settings, use the
set_top_implementation_options command.
Removing the Multiply Instantiated Module Property

You can use the remove_mim_property command to remove the multiply instantiated
module data for selected cell instances. You must specify a list of hierarchical cells for which
the multiply instantiated module data is to be removed. If a cell is not found, a warning
message is issued.
The cell instances are no longer treated as multiply instantiated modules; each cell instance
is treated as a unique reference cell.
The remove_mim_property uses the following syntax:
remove_mim_property collection_of_cells
For example:
icc_shell> remove_mim_property [get_cells instA]
Identifying Multiply Instantiated Module Plan Groups

Use the report_mim command to print a list of all multiply instantiated module plan groups
and block abstractions in the design. Multiply instantiated soft macro modules are also
identified by this command, although for placement, they are treated as hard macros.
Here is an example of a report:
icc_shell> report_mim
****************************
Report :MIM
Design :test.CEL;1
Version :E-2010.12
Date :Thu Oct 28 17:01:51 2010
***********************************
Master BLENDER is instantiated to:
Soft Macro: 1_ORCA_TOP/1_BLENDER_4


Reference Blender is instantiated 5 times.
Total 1 MIM references and 5 MIM instances.
MIM plan group flipping grid:x offset=425.5,x step=0.410
y offset=425.565,y step=7.380
MIM Report End
The report also provides information about the status of the copied placement data and
suggests a multiply instantiated module plan group flipping grid on which to place a multiply
instantiated module plan group. When the plan group is flipped, the standard cell placement
remains legal.
Shaping Multiply Instantiated Module Plan Groups

After running virtual flat placement by using the create_fp_placement command, you can
use the shape_fp_blocks command to shape the plan groups in each multiply instantiated
module group automatically. For more information, see “Shape Plan Group Command” on
page 7-12.
The plan groups in each multiply instantiated module group are shaped and sized
identically, as shown in Figure 6-38.
Figure 6-38 Plan Groups of Multiply Instantiated Module Groups in the Same Size and Shape
5 multiply instantiated
modules are the
same size (one family)
All corners of the multiply instantiated module plan groups are aligned on their row and
column placement boundaries and are placed in such a way that they can be legally flipped,
provided the rows are uniform.
Note:
The default plan group locations might not be aligned.
Placing and Analyzing Multiply Instantiated Module Plan Groups

Run the create_fp_placement command to place the macros and standard cells into fixed
placement plan group boundaries. However, the placement in the multiply instantiated
module groups will not be identical.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
You can use the copy_mim command and options to perform various manipulations during
the virtual flat placement stage on the multiply instantiated modules to determine which of
the plan groups in each multiply instantiated module group is the master instance of that
multiply instantiated module group.
The placement of the master instance is copied to the other plan groups in the multiply
instantiated module group. The copied information, which is saved to the Milkyway
database, contains the original placement of all the cells in the copied plan multiply
instantiated module plan groups relative to the lower-left corner of the plan group and the
orientation of the plan group.
The copy_mim command uses the following syntax:
copy_mim
[-type placement | blockage | boundary]
[-restore_placement]
mim_plan_group
The mim_plan_group argument specifies a list containing one multiply instantiated module
plan group.
In Figure 6-39, the placement is different in every plan group before running the copy_mim
command. After running the copy_mim command, the tool copies the cell placement of the
1_ALU multiply instantiated module to the other multiply instantiated modules in the same
group.
icc_shell> copy_mim -type placement 1_ALU
Figure 6-39 Before and After Running the copy_mim Command

Before running copy_mim After running copy_mim
As described in the following sections, you can create multiply instantiated modules with the
same cell placement, blockages, and shapes.

Copying the Cell Placement of a Plan Group

Use the copy_mim -type placement command to copy the cell placement of the specified
multiply instantiated module to all other multiply instantiated modules in the same group.
The command replicates the original placement of all the cells in the specified multiply
instantiated module relative to the lower-left corner of the plan group.
Note:
Placement blockages are not touched by this command. Errors are reported if the plan
group is not part of a multiply instantiated module group or the plan groups in the plan
group’s multiply instantiated module group do not have the same size and shape.
You can make more than one copy of a multiply instantiated module group; however,
previous versions are discarded because only one level of undo is supported.
You can use the report_mim command to list the copied multiply instantiated module
groups and their corresponding reference plan group. If the shapes or sizes of the plan
groups changed from the previous copy_mim -type placement command, this information
is also reported.
Copying Placement Blockages and Boundaries

Use the copy_mim -type blockage command to copy the placement blockages from the
specified multiply instantiated module to all the other plan groups in the same multiply
instantiated module group. This command uses the plan group orientation you set by using
the flip_mim command. For more information, see “Flipping Multiply Instantiated Module
Plan Groups” on page 6-70.
Use the copy_mim -type placement or copy_mim -type blockage command to reshape
each plan group that belongs to a multiply instantiated module group so that their
boundaries are identical to the specified plan group. The tool preserves the orientation of the
individual plan groups.
Figure 6-40 shows an example of a modified boundary applied to all the other multiply
instantiated modules in the same group.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 6-40 Modified Boundary Applied to Other Multiply Instantiated Modules in the Same
Group
shape_fp_blocks New modified boundary New boundary applied to all

multiply instantiated modules
in the same group
Restoring the Placement of Cells in Plan Groups

Use the copy_mim -restore_placement option to restore the placement of cells in the
specified plan group and all other plan groups in the same multiply instantiated module
group. The command also restores the orientation or flipping about the x- or y-axis.
Note:
Placement blockages are not touched by this command. Errors are reported if any size
or shape does not correspond to the original size or shape in the specified multiply
instantiated module group.
Flipping Multiply Instantiated Module Plan Groups

Use the flip_mim command to flip the placement of the cells in the multiply instantiated
module plan group and set the orientation. The resulting pins on the multiply instantiated
module are also flipped. After running the flip_mim command, the resulting placement is
the same as if the plan group was converted to a soft macro, flipped, and then converted
back to a plan group.
The flip_mim command uses the following syntax:
flip_mim
[-direction x | y]
plan_groups
Figure 6-41 shows a layout before and after running the flip_mim command.

Figure 6-41 Flipping Multiply Instantiated Modules

Before running flip_mim After running flip_mim
Only mirroring and flipping about the x- or y-axis is allowed for multiply instantiated module
plan groups. The command reports an error if the plan group is not rectangular.
During flipping, the bounding box of the plan group does not move.
Placement blockages are not flipped. However, the copy_mim -type blockage command
recognizes the flipped orientation.
Horizontal Requirements for Plan Group Locations

Consider the following horizontal requirements for plan group locations, when running the
flip_mim command. The requirements ensure that the cells in the plan group have the
same relative distance to the left and right plan group boundaries after flipping the plan
group horizontally.
• Snap the left and right boundaries of a plan group to the edge of a unit tile or to a location
that is one-half the unit tile width.
• Ensure that the plan group width is a multiple of the unit tile width.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Vertical Requirements for Plan Group Locations

Consider the following vertical requirements for plan group locations when running the
flip_mim command. The requirements ensure that the cells in a plan group have the same
relative distance to the top and bottom plan group boundaries after flipping the plan group
vertically. The cells are flipped and placed legally at the rows with the opposite orientation.
• Snap the top boundary of a plan group to the top-side of a row and snap the bottom
boundary of a plan group to the bottom-side of a row. Alternatively, you can snap both
the top and bottom boundaries of the plan group to a location that is one-half the row
height.
• Ensure that plan group height covers an even number of rows. (It must not be an odd
number of rows.)
QoR Analysis of Multiply Instantiated Module Plan Groups

Use the get_fp_wirelength command to run a quality of results (QoR) analysis of the
different multiply instantiated module plan groups.
The following options determine which plan group out of a set of multiply instantiated module
plan groups has the best placement with respect to timing.
• Plan Group Interface Nets – Reports the wire length of interface nets for all plan groups.
Interface nets have at least one pin inside the plan group and one pin outside the plan
group boundary.
• Plan Group Internal Nets – Reports the wire length of internal nets for all plan groups.
Internal nets have all their pins inside the plan groups.

7
Plan Groups 7
You can create plan groups for logic modules that need to be physically implemented as a
group. A plan group restricts the placement of cells to a specific region of the core area. You
can automatically place and shape objects in a design core, add padding around plan group
boundaries, and prevent crosstalk by adding block shielding to plan groups and soft macros.
• Plan Group Overview
• Create Plan Group Command
• Remove Plan Group Command
• Plan Group Padding Command
• Remove Plan Group Padding Command
• Add Block Shielding Command
• Remove Block Shielding Command
• Shape Plan Group Command
• Controlling the Placement and Shaping of Plan Groups and Macros
• Analyzing and Manipulating the Hierarchy
• Using Relative Placement Constraints
• Plan Group Utilization
7-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• Physical-Only Cells in Plan Groups

• Reporting Channel Routing Capacity
• DFT-Aware Design Planning Flow
Chapter 7: Plan Groups

7-2
Plan Group Overview

Plan groups provide a way to physically group together macro cells of the same logical
hierarchy during design planning. You can define the boundary of a plan group by specifying
a bounding box, overlapping rectangles, points on a polygon, or by a target aspect ratio or
utilization.
The plan group can be used for timing budgeting and pin creation. After refining the shape
of the plan group, you can convert the plan group to a soft macro which retains the size and
rectilinear shape of the original plan group.
The plan group boundary defines the legal placement area for macro cells in the logical
hierarchy of the plan group. The tool places all the macro cells that belong to the logical
hierarchy within the boundary. Cells that are not in the logical hierarchy are placed outside
the boundary. To better understand which macro cells belong to a plan group, you can
display each plan group in a unique color in the layout window.
To prevent routing congestion and DRC violations, you can add padding around the plan
group boundaries. Plan group padding is a placement blockage that is applied to the
specified internal or external edges of the plan group boundary to prevent cell placement in
those areas. You can use plan group padding to reserve space for pins after the plan group
is committed to a soft macro. The tool removes plan group padding when you commit the
plan group and the padding is represented as empty space in the soft macro.
When two signals are routed in parallel, crosstalk between the signals can occur. You can
reduce crosstalk by adding modular block shielding to plan groups and soft macros. Block
shielding is one or more rectangular metal layers around the plan group or soft macro
boundary. You can select which metal layers are used to create the module block shielding.
This prevents the router from routing long nets along the block boundaries. Note that, even
if you block layers in the preferred routing direction, the tool can create routes along the
block boundaries by using other metal layers. Consider blocking all layers to prevent the tool
from creating any routes along the block boundaries.
To handle signal integrity when creating hierarchical designs, the router must be prevented
from creating routes that are collinear to the soft macro or plan group boundary. To do this,
rectangles that the router creates are placed along and inside the edge of the soft macro or
plan group on metal layers whose preferred direction crosses the soft macro or plan group
boundary. If the plan groups are committed, the inner-boundary shielding is transferred to
the soft macro. The rectangles act as hierarchical signal shielding that allow only routes that
are perpendicular to the soft macro or plan group boundary to pass through the metal layers.
By preventing collinear routing along the soft macro and plan group boundaries, signal
crosstalk between routing in the soft macro and routing in the top-level channels is
minimized.

Plan Group Overview 7-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
You can use the plan groups to analyze pin and feedthrough placement for the module, and
identify potential issues before you finalize the pin locations. Using this information, you can
modify route guides or constraints on the router to achieve better pin locations.
After creating the plan group and refining its shape, you can convert the plan group to a soft
macro cell by committing the plan group. During conversion, the tool creates pins on the soft
macro and moves the macro cells belonging to the plan group from the top-level into the soft
macro. After the conversion, the floorplan contains the remaining top-level macro cells,
macros, and a soft macro cell for each plan group. You can now refine independently the
placement and routing for each soft macro.
Create Plan Group Command

You can create one or more plan groups by using the create_plan_groups command:
create_plan_groups
[-coordinate {coordinate_list}]
[-rectangle rectangle_area]
[-polygon {polygon_area}]
[-dimension {width height}]
[-target_aspect_ratio aspect_ratio]
[-target_utilization utilization]
[-is_fixed]
[-color integer]
[-cycle_color]
logic_cell_list
For information about the command options, see the create_plan_groups man page.
To create plan groups by using the GUI layout window, choose Floorplan > Create Plan
Group. This opens the dialog box shown in Figure 7-1.

Create Plan Group Command 7-4
Figure 7-1 Create Plan Group Dialog Box
Specify the level or levels of hierarchy that the plan groups contain by entering one or more
hierarchical cell names in the Hierarchical cell box. You can also click the browse button and
select one or more levels of hierarchy in the object browser. Separate multiple cell names
with spaces. Define the initial shape and size of the plan group by specifying the aspect
ratio, utilization, width and height, or coordinates which describe the plan group boundary.
The aspect ratio defines the height of the plan group divided by the width. You can draw a
rectangular shape for the plan group in the layout window by clicking the Region option,
clicking the Rectangle button, and drawing a rectangle in the layout. Click the Rectilinear
button and select points on the rectilinear boundary for the plan group to define a rectilinear
region. Select the Fixed location option to fix the coordinates of the plan group boundary.
Select one of the Color cell instances options to control the coloring of the standard cells in
the plan group. The Cycle option assigns a unique color to each individual plan group.
Remove Plan Group Command

Use the remove_plan_groups command to delete plan groups created with the
create_plan_groups command. Removing plan groups does not affect the placement of
standard cells in the layout.
remove_plan_groups
-all | plan_groups

Remove Plan Group Command 7-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
For information about the command options, see the remove_plan_groups man page.
To remove all plan groups by using the GUI layout window, choose Floorplan > Delete
Floorplan Objects > Delete All Plan Groups.
Plan Group Padding Command

You can create plan group padding by using the create_fp_plan_group_padding
command:
create_fp_plan_group_padding
[-internal_widths {left right top bottom}]
[-external_widths {left right top bottom}]
[plan_groups]
For information about the command options, see the create_fp_plan_group_padding

man page.
To create plan group padding by using the GUI layout window, first set the window task
Then choose Floorplan > Create Plan Group Padding. This opens the dialog box shown in
Figure 7-2.

Plan Group Padding Command 7-6
Figure 7-2 Create Plan Group Padding Dialog Box
Select All to apply the padding to all plan groups in the design, or select Specified and enter
the names of the plan groups to apply the padding. You can apply internal padding, external
padding, or both internal and external padding. Select the Same on all sides option and
enter a padding value in microns to apply the same padding to all sides of the plan group.
Select the Non-uniform option and enter values for the left, right, top, and bottom edges to
create different padding values for different plan group edges. Select the External padding
option and select Same on all sides or Non-uniform to add external padding to the plan
group.
To add only external padding, enter the external padding values and specify a padding value
of 0 for internal padding. You can also create only external padding by specifying the
-external_widths option to the create_fp_plan_group_padding command and
excluding the -internal_widths option.

Plan Group Padding Command 7-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 7-3 shows two adjacent plan groups of the same size with plan group padding. The
plan group on the left contains only external padding; the plan group on the right contains
both internal and external padding.
Figure 7-3 Two Plan Groups With Padding
Remove Plan Group Padding Command

Use the remove_fp_plan_group_padding command to delete plan group padding for one
or more plan groups. By default, the command removes all plan group padding from the
design. Specify individual plan groups to remove padding from only those plan groups.
remove_fp_plan_group_padding
plan_groups
For information about the command options, see the remove_fp_plan_group_padding

man page.
To remove all plan groups by using the GUI layout window, choose Floorplan > Delete
Floorplan Objects > Delete Plan Group Padding. Select the All option to remove all plan
group padding, or select Specified and enter the names of the plan groups to delete the plan
group padding.

Remove Plan Group Padding Command 7-8
Add Block Shielding Command

You can create block shielding for plan groups, soft macros, or the top-level of your design
by using the create_fp_block_shielding command.
create_fp_block_shielding
[-inside_boundary]
[-outside_boundary]
[-side_list {left | right | top | bottom}]
[-metal_layers layer_list ]
[-shielding_width factor_or_distance]
[-width_in_microns]
[-tie_to_net netname]
[-block_level]
[objects]
For information about the command options, see the create_fp_block_shielding man
page.
To create block shielding by using the GUI layout window, first set the window task mode to
Design Planning if it is not already in that mode (File > Task > Design Planning). Then
choose Floorplan > Create Module Block Shielding. This opens the dialog box shown in
Figure 7-4.

Add Block Shielding Command 7-9
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 7-4 Create Module Block Shielding Dialog Box
Select the Current design option to create block shielding around the current design. Select
the All option to create block shielding around all plan groups and soft macros in the design.
To create block shielding for only specified plan groups, select the Plan group option and
enter the names of one or more plan groups. To create block shielding for only specified soft
macros, select the Soft macro option and enter the names of one or more soft macros.
Select the Inside, Outside, or Both option to create block shielding inside the plan group or
soft macro boundary, outside the boundary, or both inside and outside. If you select the Both
option, the tool creates the inner shielding by using the specified width and the outer
shielding by using the specified width. You can specify the width of the shield in metal
pitches or in microns by selecting the Pitch or Microns option and entering the width value

Add Block Shielding Command 7-10
in the text box. Select the metal layers to use and select the sides on which to create the
block shielding.
By default, the block shielding is floating and not tied electrically to any other net. To connect
the block shielding to a net in the design, select the Tie to the net option and specify the net
name in the text box.
Figure 7-5 shows a plan group with block shielding both inside and outside the plan group
boundary.
Figure 7-5 Plan Group With Internal and External Block Shielding
Remove Block Shielding Command

Use the remove_fp_block_shielding command to delete all block shielding, or certain
segments of the block shield, from a specified plan group, soft macro, or throughout the
design. By default, the command removes all block shielding from the design.
remove_fp_block_shielding
[-inside_boundary]
[-outside_boundary]
[-side_list left | right | top | bottom]
[-metal_layers layer_list ]
[plan_groups_or_soft_macros]

Remove Block Shielding Command 7-11
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
For information about the command options, see the remove_fp_block_shielding man
page.
To remove all block shielding by using the GUI layout window, choose Floorplan > Delete
Floorplan Objects > Delete Module Block Shielding. Select the All option to remove all block
shielding throughout the design. To remove block shielding for only specified plan groups,
select the Plan group option and enter the names of one or more plan groups. To remove
block shielding for only specified soft macros, select the Soft macro option and enter the
names of one or more soft macros.
Select the Inside, Outside, or Both option to remove block shielding inside the plan group or
soft macro boundary, outside the boundary, or both inside and outside. Select the metal
shielding layers and sides on which to delete the block shielding.
Shape Plan Group Command

You can create the initial placement or reshape the boundaries for plan groups, black boxes,
voltage areas and soft macros in the design by using the shape_fp_blocks command.
shape_fp_blocks
[-rectilinear]
[-incremental target_utilization_driven | congestion_driven]
[-channels]
[-refine_placement]
[-constraint_file file_name]
[-top_down]
[-sliver_threshold threshold]
[-place_submacros]
For more information about the command options, see the shape_fp_blocks man page.
To create or modify the boundaries of the plan groups by using the GUI window, first set the
window task mode to Design Planning if it is not already in that mode (File > Task > Design
Planning). Then choose Placement > Place and Shape Plan Groups. This opens the dialog
box shown in Figure 7-6.

Shape Plan Group Command 7-12
Figure 7-6 Place and Shape Plan Groups Dialog Box
After you create plan groups with the create_plan_groups command, the tool places the
plan group shapes outside the placement area. The shape_fp_blocks command places
the plan group boundaries within the core area based on the options you specify. Figure 7-7
shows the design before and after running the shape_fp_blocks command.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 7-7 Plan Group Shaping

Before Plan Group Shaping After Plan Group Shaping
Select the Prefer rectilinear shapes option to enable the shape_fp_blocks command to
create rectilinear-shaped plan groups and soft macros around fixed macros associated with
the plan group. However, in cases where you have one small block and one large block in
your design, the small block is placed near one of the corners of the large block and creates
a rectilinear L-shaped boundary. L-shaped plan groups can be created even if no fixed
objects are encountered on the floorplan. By default, the shape_fp_blocks command
creates only rectangular plan groups or soft macros boundaries, unless the boundaries
overlap fixed macros.
Select the Run incrementally option to adjust the floorplan to meet the new plan group or
voltage area target utilizations, or to reduce the placement congestion in channels between
blocks or inside the blocks themselves. Choose the Target utilization driven option to adjust
the floorplan to meet the target utilization based on the set_fp_shaping_strategy
-utilization_slack settings. The plan group shapes should be similar to the design
before running the command. Use target utilization-driven shaping to make minor changes
to the shapes of the plan groups.
Select the Congestion driven option to resize and reshape the channels between the plan
groups and soft macros to improve congestion. The tool attempts to change the floorplan as
little as possible to reduce congestion in the channels between blocks and inside the blocks
themselves so that the estimates based on the congestion map are satisfied. If you select
this option, the command first attempts to use the congestion map created by global routing.
If a congestion map is not available, the command tries to use a placement congestion map.
If neither of the two congestion maps is available, the tool generates an error message.

If the placer places standard cells into widened channels after running congestion-driven
shaping, you can use the set_fp_shaping_strategy -add_channel_blockages
command to insert placement blockages into narrow, congested channels. You can use
hard placement blockages or partial blockages with the congestion density reflecting the cell
area that was initially inside the channel. Note that you should use hard placement
blockages in the channels if there is enough space, because the placement legalizer does
not obey partial blockages.
Select the Create routing channels option to create routing channels between plan groups,
black boxes, and soft macros. The channel widths are based on pin counts with
nonperpendicular connections to objects on the associated object edge. If you want
channels between the top-level blocks in your design, but the design is not pad limited in
size, set the initial core utilization slightly lower than the initial block utilizations. Begin by
using a utilization of 0.65 for the core and a utilization of 0.7 for the blocks. By default, the
tool abuts plan groups and does not create routing channels.
Select the Refine placement afterwards option to run virtual flat placement after shaping the
plan groups, soft macros, and black boxes. By default, the shape_fp_blocks command
does not run virtual flat placement after shaping the blocks.
Select the Top-down block placement mode option to perform an initial virtual flat placement
and shape the plan groups, soft macros, and black boxes in the design at the same time.
The shape_fp_blocks -top_down command is equivalent to running the
create_fp_placement command followed by the shape_fp_blocks command.
Select the Place sub macros option to shape the plan groups, soft macros, and black boxes
in the design and move hard macros to remove overlap. By default, the shape_fp_blocks
command creates the plan group boundaries but does not move hard macros, even if the
plan groups and hard macros overlap.
Select the Narrower than (microns) option and enter a width in microns to specify the
smallest channel width that can be created by the shape_fp_blocks command. This option
prevents thin slivers that can occur when there are many blockages, blockages with small
channels between each other, or blockages with small channels between the edge of the
plan group and the design core. By default, the Block small placement area option is
selected and the tool chooses a value for the smallest channel width.
Select the Use placement constraint file option and enter the name of the file that contains
the relative placement constraints to specify the relative location of plan groups and soft
macros with respect to each other. The constraint file contains one constraint per line. The
first word in the line is always the name of the constraint. For example,
fplModuleDestRegion plan_group_name region
where region is one of N, S, E, W, NE, NW, SE, SW, or a coordinate specified as {x,y}.
For a description of the relative placement constraints, see “Using Relative Placement
Constraints” on page 7-22.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Controlling the Placement and Shaping of Plan Groups and

Macros
You can use the set_fp_shaping_strategy command to control how the
shape_fp_blocks command and the Place and Shape Plan Groups dialog box place and
shape objects in the design core.
set_fp_shaping_strategy
[-add_channel_blockages none | partial | soft | hard]
[-adjust_macro_locations true | false]
[-avoid_power_grid true | false]
[-cell_area_driven none | respect_target_utilization |
ignore_target_utilization]
[-default]
[-distance_to_power_grid distance]
[-keep_top_level_together true | false]
[-max_shape_complexity rectangles]
[-min_channel_size size]
[-preserve_abutment true | false]
[-use_detailed_channel_size_estimation true | false]
[-utilization_slack slack]
For more information, see the set_fp_shaping_strategy man page. After setting the
shaping strategy values, you can confirm the current settings with the
report_fp_shaping_strategy command.
Note that the settings are not saved in the Milkyway design library.
Analyzing and Manipulating the Hierarchy

You can use the hierarchy browser to navigate through the design hierarchy and to examine
the logic design hierarchy and display information about the hierarchical cells and logic
blocks in your design. You can select the hierarchical cells, leaf cells, or other objects you
want to examine in layout or schematic views.
If you are not familiar with a design, you can explore the logic hierarchy to understand its
structure and gather information about the design objects. You can also use the hierarchical
browser to
• Highlight cells or blocks (and their leaf cells) with different colors in both the hierarchy
browser and the layout window
• Perform floorplan tasks such as creating plan groups and estimating black boxes
• Display design schematics of hierarchical cells
• View the hierarchical data interactively and switch between the layout view and the
hierarchy browser view for selection and highlighting

Controlling the Placement and Shaping of Plan Groups and Macros 7-16
• Perform probing between the logical hierarchy tree and the physical layout. This allows
you to select cell instances, highlight and unhighlight cells, turn flylines on and off, and
display the connectivity of selected modules and plan groups.

• Opening the Hierarchy Browser
• Exploring the Hierarchical Structure
• Manipulating the Hierarchy
Opening the Hierarchy Browser

To open the hierarchy browser, do one of the following:
• In the layout window, choose Partition > New Hierarchy Browser View
• In the main window, choose Hierarchy > New Hierarchy Browser View
The hierarchy browser window shows an instance tree on the left and an object table on the
right. The instance name of the top-level design appears at the top of the instance tree.
Figure 7-8 shows an example of a hierarchy browser.
Figure 7-8 Hierarchy Browser

Analyzing and Manipulating the Hierarchy 7-17
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The hierarchy browser indicates object types by displaying icons next to the cell names as
follows:
• Logical
❍ T – Top-level design
❍ BB – Black boxes
❍ H – Hierarchical module
❍ HM – Hard macro
❍ IO – I/O cell
❍ SC – Standard cell
❍ ILM – Interface logic model or block abstraction model
• Physical
❍ P – Plan group
❍ SM – Soft macro
To color-code the icons, right-click the hierarchy browser view and choose Set Colors on
Top Hierarchies.
Exploring the Hierarchical Structure

You can explore the complete hierarchical structure of your design and observe how many
hierarchical blocks are present. To explore the design hierarchy, you can
• Click the expansion button (plus sign) next to an instance name to expand the instance
tree, showing the names of the subblocks at the next level of hierarchy. You can also
right-click and select “Expand Tree Level” from the menu to display the Expand Tree
dialog box.
• Select an instance to display leaf cell information in the object table.
Shift-click or Control-click instance names to select combinations of instances. The
information includes cell instance names, cell types, and cell reference names.

• Display port and pin names or net names by selecting a port, pin, or net (rather than a
cell) in the text box above the object table list.
You can specify what types of information are displayed in the object table list.
Right-click inside the table and then choose Columns > More. You can then select the
details you want to display from the objects listed in the dialog box.
For more information about the hierarchy browser, see IC Compiler online Help.
Manipulating the Hierarchy

This section describes how to create a new level of hierarchy in the early design planning or
prototyping phase and how to remove a level of hierarchy from the current design.
• Merging the Hierarchy
• Flattening the Hierarchy
Merging the Hierarchy

You can rearrange the hierarchy in your design by selecting any number of cells and
merging them together into a new cell. Use the merge_fp_hierarchy command to perform
this operation.
merge_fp_hierarchy
[-cells cell_list]
[-design_name design_name]
[-input_sdc_file input_file_name]
[-load_back_sdc]
[-new_cell_name cell_name]
[-no_port_merging]
[-output_sdc_file output_file_name]
[-wrapper]
For more information about the command options, see the merge_fp_hierarchy man
page.
To merge cells within the hierarchy by using the GUI window, first set the window task mode
to Design Planning if it is not already in that mode (File > Task > Design Planning). Then
choose Partition > Merge Hierarchy. This opens the dialog box shown in Figure 7-9.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 7-9 Merge Hierarchy Dialog Box
Enter the name of the new container in the New cell name box. The tool creates the new cell
name and moves the selected cells beneath the new cell. Enter the reference name of the
new cell design created by merging the existing cells in the New design name box. Enter the
name of the cells to be merged in the Cells box.
You can update the Synopsys Design Constraints (SDC) file for your design to reflect the
new hierarchy created by the merge_fp_hierarchy command. Select Update SDC and
enter the name of the SDC file in the Input SDC file box and enter the name of the new SDC
file for the new hierarchy in the Output SDC file box. Select Load back updated SDC file to
reload the new SDC file for the updated design.
Select the Create wrapper option to create a wrapper on any existing leaf cell or hierarchical
logic modules. A wrapper is used to selectively expose internal connections and dangling
pins onto a wrapper interface so that any future changes made to these internal objects do
not affect the wrapper interface. The new wrapper module retains the pin names from the
logic modules. Note that if the new pin name on the wrapper is different from the one
connected inside the original cell pins, a file describing the mapping of the pin names is
automatically generated. You can also use this option to create a wrapper module for a
merged plan group before committing it to a soft macro. Note that pin assignment and
feedthrough generation occur only at the wrapper module. The original module under the
wrapper is not affected by any feedthrough insertion changes.
If there are changes in the netlist of the original logic modules, but the module interface is
still the same, you can insert the new netlist into the wrapper module, create a CEL view for

the new block and then link it to the top-level design. You do not have to run pin assignment
or generate feedthroughs again for the new netlist.
If you select the Create wrapper option, the Port merging option merges the ports that are
connected by the same interface net in the wrapper. Deselect the Port merging option to
prevent this behavior.
Flattening the Hierarchy

You can flatten (remove) a single level of hierarchy from your current design so that the logic
modules at the next lower level of hierarchy are merged into the current level of hierarchy.
This replaces a single hierarchical block with multiple blocks brought up from the lower level,
which raises all of those blocks up by one level of hierarchy.
To flatten a level of hierarchy,
1. Select Partition > Flatten Hierarchy.
The Flatten Hierarchy dialog box appears.
❍ Cells – Enter a list of cells (modules, plan groups, black boxes, hard macros, soft
macros, or leaf cell instances) in the current design that are to be flattened.
❍ Update SDC – Select this option to update the SDC file to reflect the changes to the
netlist.
Click in the “Input SDC file” box and enter the name of the SDC file to be updated.
The file should contain valid SDC commands for the current design.
Click in the “Output SDC file” box and enter the name of the resulting SDC output file
into which the updated SDC timing constraints are written.
❍ Load back updated SDC file – Select this option to reload the updated SDC file. The
updated SDC constraints are also automatically reloaded into the CEL view.
❍ Name Prefix – Select this option to specify the prefix to use when naming flattened
cells.
Simple name – Select this option to indicate that simple, nonhierarchical names are
to be used for cells that are flattened. The cells maintain their original names. This is
the default.
No backslash – Select this option to indicate that a backslash should not be added
before the hierarchy delimiter.
Specified prefix – Select this option to specify the prefix to be used when naming
flattened cells. The naming style is:
specified_prefix original_cell_name

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Alternatively, you can use the flatten_fp_hierarchy command.
Using Relative Placement Constraints

Relative placement constraints considered in a constraint file for guiding the placement and
shaping of objects are described as follows:
• fplNamedGroup groupName obj
Note:
Groups must first be defined by using the fplNamedGroup constraint.
If groupName is not a name of an existing group, this constraint creates one and places
obj in it. Obj can be a name of a block or another (already created) group. The block is a
soft macro, black box, or plan group. Grouping, in the context of these relative
constraints, can be viewed as a “pseudo hierarchy” because these are physical groups
that do not have to be related to the logic hierarchy of the netlist.
• fplRel relType obj1 obj2
relType (a type of relation)
Supported types are
❍ BT (bottom top): This means obj1 should be below obj2.
❍ LR (left right): This means obj1 is to be placed to the left of obj2.

Care should be taken to ensure consistency of these relative constraints. There is no
preprocessing to determine if conflicting constraints exist when running the
shape_fp_blocks command. For example, do not use both “fplRel BT o1 o2” and
“fplRel BT o2 o1” or other, more complicated and conflicting constraint sets. Likewise,
constraining some elements of group1 above elements of group2 while placing other
elements of group1 below elements of group2 creates unpredictable results. Do not
make relationships between an object and its group. Generally, relations should be on
the same grouping level.
• fplModuleDestRegion plan_group_name region
where region is one of { N | S | E | W | NE | NW | SE | SW} or an x- and
y-coordinate surrounded by braces, for example {10.700 1200.000}
The fplModuleDestRegion constraints can be applied to both top-level and lower-level
modules.

Using Relative Placement Constraints 7-22
Here is an example constraint file:

fplNamedGroup red plan_group1
fplNamedGroup red black_box_foo
fplNamedGroup blue plan_group2

fplNamedGroup blue plan_group3
fplNamedGroup green plan_group4
fplNamedGroup green black_box_bar
fplNamedGroup root red

fplNamedGroup root blue
fplNamedGroup root green
fplRel BT plan_group1 black_box_foo

fplRel LR plan_group3 plan_group2
fplRel BT green blue

fplRel LR red green
Plan Group Utilization

Utilization is the ratio of design area covered by cells to the available area for cell placement.
You can use the get_utilization command to report a utilization value for the entire
design or for a set of plan groups and soft macros. Command options specify the criteria
used to calculate utilization; you can exclude or include blockages and keepouts, depending
on your requirements.
get_utilization
[objects]
[-row_based]
[-consider_blockages none | hard | soft_and_hard]
[-consider_macro_keepouts]
[-treat_macros_like_blockages none | fixed | all]
[-flat]
The following examples use the design example in Figure 7-10. In the figure, region A is
occupied by standard cells, macro cells, placement blockages, and keepout margins.
Region B contains plan groups that contain only standard cells.

Plan Group Utilization 7-23
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 7-10 Utilization Calculation Design Example
A B
To display the utilization value for individual plan groups and soft macros in the design,
specify their names on the command line. The get_utilization command and the
ToolTip window report the same utilization value for the plan group.
icc_shell> get_utilization [get_plan_groups *]
plan group <I_ORCA_TOP/I_BLENDER_1> utilization: 0.889244
average utilization of plan groups: 0.891400
overall utilization of plan groups: 0.891392
0.891392

Plan Group Utilization 7-24
To report the utilization for the top-level design, use the get_utilization command with
no arguments. The get_utilization command with no options excludes plan groups from
the utilization calculation; the command calculates the utilization for region A and excludes
region B in Figure 7-10:
icc_shell> get_utilization
Top level utilization: 0.588681
0.588681
Use the -flat option to ignore plan group boundaries and include the plan group area in the
utilization calculation; the command includes both regions A and B in Figure 7-10 in the
utilization calculation.
icc_shell> get_utilization -flat
Top level utilization: 0.701213
0.701213
Use the -row_based option to exclude gaps between rows in the utilization calculation. If
gaps exist between standard cell rows in your design, the get_utilization -row_based
command reports a higher utilization than the get_utilization command.
The remaining options to the get_utilization command specify which objects are part of
the occupied area and which are part of the available area. For example, the
-consider_blockages hard option excludes hard blockages from being considered as
part of the available area and causes a higher utilization value to be reported. You can also
control the consideration of hard and soft blockages, macros, and macro blockages. For
details, see the man page for the get_utilization command.
Physical-Only Cells in Plan Groups

You can place physical-only cells, such as tap or filler cells, inside specific plan groups
during top-level virtual flat placement in design planning. After committing the plan groups,
the physical-only cells remain with the plan groups, and are not moved to the top level of the
design hierarchy. Note that physical-only cells that straddle the plan group boundary are
inserted into the hierarchy of the plan group. Table 7-1 summarizes the commands and
options that perform plan-group-aware physical-only cell placement.
Table 7-1 Plan-Group-Aware Physical-Only Cell Placement Commands
Command and option Description
add_end_cap -at_plan_group_boundary Places end cap cells at both sides of the vertical
boundary of the plan group. The tool inserts end
cap cells within the plan group boundary at the
hierarchy level of the plan group.

Physical-Only Cells in Plan Groups 7-25
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Table 7-1 Plan-Group-Aware Physical-Only Cell Placement Commands (Continued)
Command and option Description
add_tap_cell_array Inserts tap cells only within the specified plan

-plan_group {plan_groups} groups. Tap cells that straddle the plan group
boundary or are contained within the plan group
are inserted into the hierarchy of the plan group.
insert_stdcell_filler Inserts filler cells only within the specified plan

-plan_group {plan_groups} groups. Filler cells that straddle the plan group
boundary or are contained within the plan group
are inserted into the hierarchy of the plan group.
Reporting Channel Routing Capacity

You can use the report_channel_capacity command to display the number of tracks
available for routing in the channels between macros and plan groups. By default, the
command reports the number of available tracks and total number of tracks for each active
routing layer in all channels in the design. You can use the -layer, -rectangle,
-routing_rules, -max_channel_width, and -max_channel_length options to limit the
report output. For more information, see the report_channel_capacity man page.
The following example sets the active routing layers and reports the number of available
tracks in the design.
icc_shell> set_ignored_layers -min_routing_layer METAL \
-max_routing_layer METAL6
icc_shell> report_channel_capacity
****************************************
Report : channel capacity
-layers { METAL METAL2 METAL3 METAL4 METAL5 METAL6 }
-consider_pins true
-consider_global_routing false
Design : floorplan_init
Date : Tue May 21 11:42:23 2013
****************************************
HORIZONTAL CHANNEL (1158.185 1838.375) (1262.265 1841.245)

Horizontal capacity available: 16 of 18 (88.9%)
METAL 6 of 7 available (85.7%)
METAL3 6 of 7 available (85.7%)
Vertical capacity available: 483 of 563 (85.8%)
...

Reporting Channel Routing Capacity 7-26
DFT-Aware Design Planning Flow

In the IC Compiler design planning flow, you can use the optimize_dft -plan_group
command to optimize scan chains based on the physical hierarchy after you place and
shape the plan groups but before you perform pin cutting. This is useful when logical
hierarchy-based scan chains are suboptimal for the best physical design. The
plan-group-aware scan chain takes advantage of the flexibility of scan chain connections to
repartition and reorder the scan cells in a way that reduces the number of scan ports and
feedthroughs.
Note:
Scan chains in designs that contain multiply instantiated modules cannot be optimized
by using the optimize_dft -plan_group command.
Figure 7-11 shows where the optimize_dft -plan_group command is used in the
DFT-aware design planning flow.

DFT-Aware Design Planning Flow 7-27
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 7-11 DFT-Aware Design Planning Flow
IC Compiler Design Planning Flow

Milkyway
Design + Read design and full-chip SCANDEF file
open_mw_cel
SCANDEF
create_floorplan
Create plan groups

create_plan_groups
Place and shape plan groups

create_fp_placement / shape_fp_blocks
Optimize scan chains

optimize_dft -plan_group
Assign pins and create feedthroughs

place_fp_pins
Commit the design, update SCANDEF in Milkyway

Block-Level Flow For Each Block

Open Milkyway design
open_mw_cel
Perform optimization
place_opt / clock_opt / route_opt
Create Interface Logic Models or block abstraction models

create_ilm, create_block_abstraction
Top-Level Flow
Open Milkyway design
open_mw_cel
Perform top-level optimization

place_opt / clock_opt / route_opt

Generating and Using SCANDEF

The DFT Compiler tool uses the write_scan_def -expand list_of_instances
command to generate chip-level SCANDEF information that includes all the scan cells
inside the specified subblocks. You can load this SCANDEF information at the beginning of
the design planning process in the IC Compiler tool as follows:
• If the design input is .ddc, read the .ddc file with the SCANDEF embedded in it.
• If the design input is Verilog, read the ASCII SCANDEF file using the read_def
command.
Reading the SCANDEF information enables scan chain elements to have size_only
attributes applied. This prevents the scan chain elements from being reoptimized during
in-place optimization. As a result, the consistency between the scan chain netlist and
SCANDEF is maintained through the design planning stage.
Performing Plan Group-Aware Scan Chain Optimization

Using the optimize_dft -plan_group command performs scan chain repartitioning and
reordering. Repartitioning reallocates the scan cells to chains so that scan cells in the same
physical hierarchy that are close together form new scan chains. Reordering ensures that
the scan chains in the same physical hierarchy are adjacent to each other to minimize net
lengths that cross physical hierarchies. Plan group-aware scan chain optimization provides
the following benefits:
• Minimizes the number of unnecessary top-level scan-chain wires crossing between the
physical hierarchies.
• Minimizes congestion.
• Improves routability.
• Clusters together the scan cells of the same plan group. The entry and exit points of the
plan group and the top-level scan wires and ports are minimized.
• Optimizes the scan chain ordering based on the physical hierarchies for each top-level
scan chain and minimizes feedthroughs created for scan wires.
Using Plan Group-Aware Repartitioning

You can use the following command to control the plan group-aware repartitioning of the
scan chains during design planning:
set_optimize_dft_options -repartitioning_method \
none | single_directional | multi_directional | adaptive

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
For more information about this command and options, see the man page.
You can turn off repartitioning and perform only plan group-aware scan chain reordering by
using the following setting before running the optimize_dft -plan_group command:
icc_shell> set_optimize_dft_options -repartitioning_method none
Committing Physical Hierarchy Changes After Scan Chain

Optimization
When committing the physical hierarchy changes by using the commit_fp_plan_groups
command, the SCANDEF information is updated based on the plan groups. The original
logical hierarchy-based SCANDEF information is automatically updated to correspond to
the physical hierarchy in the design planning phase, and block-level SCANDEF information
is pushed down into the hierarchy, and the updated SCANDEF is stored in the Milkyway
CEL views for the blocks and top level, based on the physical hierarchy, as shown in
Figure 7-12.
Figure 7-12 Updating SCANDEF Data During Commit Hierarchy

When using the uncommit_fp_soft_macros command, note that the SCANDEF might be
different from the original file. Nevertheless, this SCANDEF is functionally equivalent to the
original.
Checking the SCANDEF Data Against the Netlist

The tool maintains the SCANDEF data that describes the scan-chain characteristics and
constraints, as well as the scan-stitched netlist. The netlist and SCANDEF data must be
consistent with each other. To validate their consistency, you can use the
check_scan_chain command in both the top level and the blocks. By default, a summary of
the consistency of all the chains is displayed.
Consistency checking is performed on elements between the START and STOP points of
the chain stubs. The check starts at the STOP point and proceeds backward. Each scan
chain stub is given a status after the checks are complete.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

8
Performing Power Planning 8
Power planning, which includes power network synthesis and power network analysis, is
required to create a design with good power integrity. A design with a robust power and
ground (PG) grid reduces IR drop and electromigration by providing an adequate number of
power and ground pads and rails. The power plan can be used to assess the routing
resources consumed by the power nets and to determine the impact on routability due to the
power plan. You can experiment with different power plans or fine-tune the existing power
plan by modifying the replay script and regenerating the power plan.
Power network analysis extracts the power network and performs an IR drop analysis. You
can use the analysis results to modify the power plan and reduce the IR drop to meet your
specification.
• Performing Power Network Synthesis on Single-Voltage Designs
• Performing Power Network Synthesis on Multivoltage Designs
• Creating Template-Based Power Rings
• Creating Template-Based Power Meshes
• Creating Power-Switch Arrays and Rings
• Analyzing the Power Network
• Viewing the Analysis Results
8-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Performing Power Network Synthesis on Single-Voltage Designs

The IC Compiler tool supports different flows for single-voltage designs and multivoltage
designs. For information about performing power network synthesis on multivoltage
designs, see “Performing Power Network Synthesis on Multivoltage Designs” on page 8-7.
The following sections outline the steps to perform power network synthesis for a
single-voltage design.
• Saving the Design
• Defining Logical Power and Ground Connections
• Applying Power Rail Constraints
• Creating Virtual Pads
• Synthesizing the Power Network
• Committing the Power Plan
The following illustration shows a typical power network synthesis flow for single-voltage
designs.
Figure 8-1 Power Network Synthesis for Single-Voltage Designs
Save the design
Define logical power and ground connections
Apply power network constraints
Create virtual pads
Synthesize the power network
Analyze IR drop
Modify constraints
Commit the power network
Create power rails
Chapter 8: Performing Power Planning

Performing Power Network Synthesis on Single-Voltage Designs 8-2
Saving the Design

Prior to running power network synthesis on your design, you should save the design by
using the save_mw_cel command. If you are not satisfied with the results of power network
synthesis, you can revert to the saved version and resynthesize using different constraints.
The following command saves the design before power network synthesis.
icc_shell> save_mw_cel -as floorplan_prepns
Defining Logical Power and Ground Connections

Use the derive_pg_connection command to create logical connections between power
and ground pins on standard cells and macros and the power and ground nets in the design.
For more information about the derive_pg_connection command, see “Creating Logical
Power and Ground Connections” in the IC Compiler Implementation User Guide.
Applying Power Rail Constraints

You must specify constraints before synthesizing the power network. The constraints
specify the width, direction, spacing, offset, and other parameters that the tool uses when
creating the rings and straps for the power network. Use the set_fp_rail_constraints
command or choose one of the GUI forms by choosing Preroute > Power Network
Constraints in the GUI and selecting one of the GUI forms to set the constraints.
The following example uses METAL2 as the vertical power rail and METAL3 as the
horizontal power rail. The first command removes the constraints on all layers and then the
next two commands constrain the power rails to limit the number of straps between 10 and
20 and sets a minimum width of 0.4 microns.
icc_shell> set_fp_rail_constraints -remove_all_layers
icc_shell> set_fp_rail_constraints -add_layer -layer METAL2 \
-direction vertical -max_strap 20 -min_strap 10 \
-min_width 0.4 -spacing minimum
icc_shell> set_fp_rail_constraints -add_layer -layer METAL3 \
-direction horizontal -max_strap 20 -min_strap 10 \
Applying Power Ring Constraints

The set_fp_block_ring_constraints command defines the constraints for the power
and ground rings that are created around plan groups and macros by using the
synthesize_fp_rail command. You can also choose Preroute > Multi-Voltage Power
Network Constraints > Block Rings Constraints in the GUI to set the constraints. The
set_fp_block_ring_constraints command syntax is as follows.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
set_fp_block_ring_constraints
-add | -remove | -remove_all |
-save_file file_name | -load_file file_name
-block blocks
-nets nets
[-block_type master | instance | plan_group | voltage_area]
[-all_blocks]
[-horizontal_layer layer]
[-vertical_layer layer]
[-horizontal_width distance]
[-vertical_width distance]
[-horizontal_offset distance]
[-vertical_offset distance]
[-spacing distance]
The following example adds a ring constraint for the current design. The horizontal layer is
constrained to the METAL5 layer with a width of 3 microns and an offset of 0.600 microns.
The vertical layer is constrained to the METAL6 layer with a width of 3 microns and an offset
of 0.600 microns. The ring constraint is applied around all instances with the cell names
ALU, CPU, or RAM using the VDD and VSS nets.
icc_shell> set_fp_block_ring_constraints -add \
-horizontal_layer METAL5 -vertical_layer METAL6 -horizontal_width 3 \
-vertical_width 3 -horizontal_offset 0.600 -vertical_offset 0.600 \
-block_type master -nets {VDD VSS} -block { ALU CPU RAM }
Creating Virtual Pads

You can create virtual pads to serve as temporary power sources for your design. Virtual
pads provide additional sources of current for the power network and do not require
modification of the floorplan. After experimenting with power network analysis using different
placements and numbers of virtual pads, you can modify your floorplan and insert additional
power pads based on your analysis.
To insert virtual pads into your design, use the create_fp_virtual_pad command. To
insert virtual pads using the GUI layout window, choose Preroute > Create Virtual Power
Pad. The create_fp_virtual_pad command syntax is as follows:
create_fp_virtual_pad
[-nets nets]
[-layer layer]
[-point {x y}]
[-load_file pad_file]
[-save_file output_pad_file]
The following example creates two virtual pads for the VDD net at coordinates 100,100 and
2000,2000.
icc_shell> create_fp_virtual_pad -nets VDD -point {100.000 100.000}
icc_shell> create_fp_virtual_pad -nets VDD -point {2000.000 2000.000}

You can save the current virtual pads to a file by using the -save option. The following
example saves the current virtual pads to the pads.rpt file and displays the content of the file.
icc_shell> create_fp_virtual_pad -save_file pads.rpt
Saving the virtual pad file pads.rpt successfully
icc_shell> sh cat pads.rpt

VDD
100.000 100.000 auto
2000.000 2000.000 auto
To re-create the virtual pads, use the create_fp_virtual_pad command with the
-load_file option. To remove the virtual pads created by using the
create_fp_virtual_pad command, use the remove_fp_virtual_pad command. The
remove_fp_virtual_pad -all command removes all virtual pads; you can also use the
remove_fp_virtual_pad command with the -net and -point options to remove individual
virtual pads.
Synthesizing the Power Network

You can perform power network synthesis on your design by using the
synthesize_fp_rail command. This command synthesizes the power network based on
the constraints you define. To create the power network, use the synthesize_fp_rail
command or choose Preroute > Synthesize Power Network in the GUI.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The synthesize_fp_rail command syntax is as follows:

synthesize_fp_rail
-nets nets
-synthesize_voltage_areas | -synthesize_power_switch_array
[-analyze_power]
[-create_virtual_rails layer]
[-honor_conn_view_layers conn_layer]
[-ignore_blockages]
[-lowest_voltage_drop]
[-output_directory directory_name]
[-pad_masters pad_reference_cells]
[-power_budget power]
[-read_default_power_file power_file_name]
[-read_pad_instance_file pad_instance_file_name]
[-read_pad_master_file pad_reference_cell_file_name]
[-read_power_compiler_file power_compiler_report_file]
[-read_prime_power_file prime_power_report_file]
[-synthesize_power_pads]
[-synthesize_power_plan]
[-target_voltage_drop target_voltage]
[-top_level_only]
[-use_pins_as_pads]
[-use_strap_ends_as_pads [-strap_ends_direction directions]]
[-use_strap_ends_as_pads]
[-voltage_areas voltage_areas]
[-voltage_supply voltage]
The following example synthesizes the power plan based on the constraints set previously
with the set_fp_rail_constraints command. The command synthesizes a power plan
using the VDD power net, the VSS ground net, and a supply voltage of 1.32V. The command
writes the voltage drop and electromigration results to the powerplan.dir directory.
icc_shell> synthesize_fp_rail -power_budget 800 -voltage_supply 1.32 \
-output_directory powerplan.dir -nets {VDD VSS} \
-synthesize_power_plan
The synthesize_fp_rail command generates the power plan based on the constraints
you provide. Rail analysis results for the design are saved to the ./pna_output directory; you
can use these results to examine the voltage drop, resistance, and electromigration and
perform other types of analysis on the power network. See “Analyzing the Power Network”
on page 8-69 for more information. If the target IR drop is greater than your specification,
change the power network constraints by using the set_fp_rail_constraints and
set_fp_block_ring_constraints commands. Figure 8-2 shows the power plan created
by running the synthesize_fp_rail command.

Figure 8-2 Power Network Synthesis Results Display
Committing the Power Plan

After creating a satisfactory power plan that meets your specifications for IR drop, you can
commit the power plan to convert the virtual power straps and rings to actual power wires,
ground wires, and vias. Use the commit_fp_rail command or click the Commit button on
the Preroute > Synthesize Power Network form in the GUI.
Performing Power Network Synthesis on Multivoltage Designs

The following sections outline the steps necessary to implement a power network in a
multivoltage design.
• Saving the Design
• Selecting a Voltage Area and Specifying Synthesis Constraints

Performing Power Network Synthesis on Multivoltage Designs 8-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The following illustration shows a typical power network synthesis flow for a multivoltage
design.
Figure 8-3 Multivoltage Power Network Synthesis Flow
Save the design
Select a voltage area
Specify synthesis constraints
Specify layer, ring, and global constraints
Analyze IR drop
Modify constraints, add power and ground pads
All voltage areas N

synthesized?
Run power network synthesis
Analyze results
N
Satisfactory results?
Commit power routes
Saving the Design

Prior to running power network synthesis on your design, you should save the design by
using the save_mw_cel command. If you are not satisfied with the results of power network
synthesis, you can revert to the saved version and resynthesize using different constraints.
The following command saves the design before power network synthesis.
icc_shell> save_mw_cel -as floorplan_prepns
Selecting a Voltage Area and Specifying Synthesis Constraints

Begin power network synthesis by selecting a voltage area and setting power network
synthesis constraints on that area. You must specify the power network synthesis
constraints before specifying the layer, ring, and global constraints on the voltage area.

Power network synthesis constraints include settings for the power and ground net names,
supply voltage, power budget, target IR drop, and power-switch name. Use the
set_fp_rail_voltage_area_constraints command, or choose Preroute > Multi-Voltage
Power Network Constraints > Voltage Area Constraints in the GUI to select the voltage area
and set the constraints. The set_fp_rail_voltage_area_constraints command syntax
used to set power network synthesis constraints is as follows:
set_fp_rail_voltage_area_constraints
-voltage_area voltage_area
[-nets pg_nets]
-voltage_supply supply_voltage
[-target_voltage_drop voltage]
[-power_switch power_switch_or_lib_cell]
Note:
To set the constraint for a power-down voltage area, you must specify the name of the
permanent power net followed by the name of the virtual power net. For example, use
the set_fp_rail_voltage_area_constraints -voltage_area VA1 -nets
VDD+VDD_Virtual command to assign a constraint on the VDD net for the power-down
voltage area named VA1. The command synthesizes both nets connected by
power-switch cells.
For a UPF design, the command inserts the power and ground net names automatically,
although you must provide supply voltage information. If you do not set the power
budget, power network synthesis assigns a power budget based on the ratio of the
instance area for this voltage area divided by the area of the entire design.
The following example sets a power network synthesis constraint on the VA1 voltage area
for the VDD and VSS power nets using a supply voltage of 1.5 V, a power budget of 200
mW, a target IR drop of 160 mV, and a power switch named SWITCH1.
icc_shell> set_fp_rail_voltage_area_constraints -voltage_area VA1 \
-power_budget 200 -power_switch SWITCH1 -voltage_supply 1.5 \
-target_voltage_drop 160 -nets {VDD VSS}

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Setting Layer Constraints

To assign layer constraints for a voltage area, use the
set_fp_rail_voltage_area_constraints command or choose Preroute > Multi-Voltage
Power Network Constraints > Voltage Areas Constraints in the GUI and click the Layer
constraints button. The layer constraints define the layer, direction, strap width, strap
spacing or density, and net type for the voltage area.
The set_fp_rail_voltage_area_constraints command syntax used to assign layer
constraints to the voltage areas is as follows:
-layer pg_layer
-direction vertical | horizontal
[[-max_strap max_strap_number]
[-min_strap min_strap_number]] |
[[-max_pitch max_pitch_distance]
[-min_pitch min_pitch_distance]]
[-max_width max_width_distance]
[-min_width min_width_distance]
[-spacing minimum | interleaving | distance]
[-mtcmos_net_type permanent | virtual]
The following example specifies a power network layer constraint on the VA1 voltage area
for layer METAL6. The layer direction is vertical, the maximum number of power straps is
128, the minimum number is 4, the minimum width is 0.1 microns, and the spacing is
minimum.
icc_shell> set_fp_rail_voltage_area_constraints -voltage_area VA1 \
-layer METAL6 -direction vertical -max_strap 128 -min_strap 4 \
Setting Ring Constraints

Ring constraints specify the layer, ring width, ring spacing, and strap extension parameters
used when creating power and ground rings around a voltage area. To assign ring
constraints for a voltage area, use the set_fp_rail_voltage_area_constraints

command with the appropriate options or choose Preroute > Multi-Voltage Power Network
Constraints > Voltage Areas Constraints in the GUI and click the Ring and Straps
constraints button.
The set_fp_rail_voltage_area_constraints command syntax used to create power
rings around voltage areas is as follows:
[-ring_nets ring_nets | -skip_ring]
[-horizontal_ring_layer h_ring_layer]
[-vertical_ring_layer v_ring_layer]
[-ring_width pg_ring_width]
[-ring_max_width max_ring_width]
[-ring_min_width min_ring_width]
[-ring_spacing distance_between_rings]
[-ring_offset distance_to_boundary]
[-extend_strap voltage_area_ring | core_ring | boundary |
voltage_area_boundary | pad_ring]
[-num_extend_straps number_extended]
[-extend_strap_direction directions_to_extend]
Note:
You can define constraints for the core ring only for the default voltage area. To generate
the core ring, select the default voltage area in the Voltage Area selection box, choose
the “Generate core rings” check box in the GUI, and specify the ring power and ground
net names in the Power Ground nets text box. You can generate a permanent ring in the
default voltage area.
Figure 8-4 shows the voltage rings created by using the following
set_fp_rail_voltage_area_constraints command:
icc_shell> set_fp_rail_voltage_area_constraints \
-voltage_area DEFAULT_VA -ring_nets {VDD VSS VDD1 VDD2} \
-horizontal_ring_layer { M9 } -vertical_ring_layer { M8 }

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-4 Core Rings for Default Voltage Area

VDD
VSS
VDD1
VDD2
VA1 VA2
The IC Compiler tool supports different techniques for extending power straps from the
voltage area. The -extend_strap voltage_area_ring option (“Voltage area ring” option
in the GUI) extends the straps to the power and ground ring for the voltage area. The
-extend_strap core_ring option (“Core ring” option in the GUI) extends the power and
ground straps to the power ring for the default voltage area. The -extend_strap boundary
option extends the straps to the top-level cell boundary. The -extend_strap pad_ring
option extends the straps to the top-level pad ring, and the -extend_strap
voltage_area_boundary option extends the straps to the boundary of the voltage area set
by using the create_voltage_area -coordinate command.
You can also control the direction used for extending the straps. Set the direction for power
rail extension by using the -extend_strap_direction option or by selecting the
appropriate check boxes in the “Direction for extending straps” section of the GUI. By
default, the command extends the power straps from all sides of the voltage area, unless
they are blocked by a constraint, a hard macro, or another voltage area.
The ground net is not extended out from each voltage area to the core ring because the
ground net is synthesized as a common net in the design. As a result, the ground net in each
voltage area is extended to the nearest ground straps outside the voltage area boundary.
Setting Global Constraints

Define global constraints by using the -global option with the
set_fp_rail_voltage_area_constraints command, or by clicking the Global
constraints button in the GUI. The list of global constraint options is the same as the list for
the set_fp_rail_constraints command.

Synthesizing the Power Network

After you set the power network constraints by using the
set_fp_rail_voltage_area_constraints command, you can perform power network
synthesis on your multivoltage design. The IC Compiler tool supports synthesis of all voltage
areas at the same time, or synthesis of each voltage area individually. Use the
synthesize_fp_rail command, or choose Preroute > Synthesize Power Network in the
GUI.
To synthesize the power network for the voltage areas, choose the “Synthesize power
network by voltage areas” option in the GUI. You can synthesize all voltage areas at the
same time by selecting the “All voltage areas” option. To synthesize a specific set of voltage
areas, select the “Specified voltage areas” option and enter the voltage area name in the
text box. Use the synthesize_fp_rail -synthesize_voltage_areas -voltage_areas
{ area_names } command to synthesize the power network for the specified voltage areas
from the command line, or do not use the -voltage_areas option to synthesize all voltage
areas.
Figure 8-5 shows the results of power network synthesis on multiple voltage areas. The
figure contains an IR drop map for each power and ground net in the different voltage areas.
Figure 8-5 IR Drop Maps for Different Nets and Voltage Areas
VDD1 for VDD2 for

VA1 VA2
VDD for VSS for

DEFAULT_VA all Voltage Areas

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Creating Template-Based Power Rings

The template-based power planning flow separates the description of the power and ground
ring and mesh architecture from the implementation details. You define the implementation
details for the power ring and power mesh in a template file. You can use the template file
across multiple designs that share the same technology. A power ring or power mesh
strategy associates the power nets in your design with the implementation details in the
template file. Separating the ring generation and mesh generation steps simplifies the
creation of the power network for your design.
The following sections describe the flow to create power rings by using the template-based
power network synthesis flow. For information about creating power meshes in the
template-based power network synthesis flow, see “Creating Template-Based Power
Meshes” on page 8-32.
1. Defining Power Plan Regions
2. Creating the Power Ring Template File
3. Creating the Power Ring Strategy
4. Compiling the Power Rings
5. Creating the Power Mesh Template File
6. Creating the Power Mesh Strategy
7. Compiling the Power Mesh
Defining Power Plan Regions

In the template-based power network synthesis flow, power plan regions define the area
used to create the power rings and power straps that form the power network. You can use
a power plan region as a working area to create power plan strategies or blockage areas for
other routing areas. Use the following commands to create and manipulate power plan
regions:
• create_power_plan_regions - Creates a power plan region
• update_power_plan_region - Reshapes a power plan region
• write_power_plan_regions - Writes out names and coordinates for all power plan
regions
• read_power_plan_regions - Reads in a power plan region names and coordinates file
written by the write_power_plan_regions command
• get_power_plan_regions - Retrieves a collection of existing power plan regions

Creating Template-Based Power Rings 8-14
Creating a Power Plan Region

A power plan region can combine a group of macro cells or user-specified input polygons.
You can also form a power plan region by upsizing or downsizing the boundary of the core
area, a voltage area or a set of macro cells. The command syntax for the
create_power_plan_regions command is as follows. For more information about these
options, see the man page.
create_power_plan_regions
region_name
[-core |
-group_of_macros macro_cells |
-polygon {polygon_area} |
-voltage_area voltage_area
[-exclude_macros macro_cells]
[-expand {x_offset y_offset}]
[-jog_threshold threshold]
[-macro_offset offset]
[-macro_offset_file file_name]
[-notch_threshold threshold]
[-remove_jog_method expand | shrink]
[-remove_notch_type convex | concave]
For example, the following command creates a power plan region based on the core area
and excludes two macro cells. This technique is useful in designs where you do not want to
create a power and ground grid that overlaps certain macro cells. In this case, the power
plan region forms a new power and ground grid region, and the tool creates power and
ground on the region.
icc_shell> create_power_plan_regions region_1 \
-exclude_macros {macro1 macro2} -core -expand -35 \
-notch_threshold 50 -macro_offset 35
Retrieving Power Plan Regions

Use the get_power_plan_regions command to retrieve a collection of power plan regions.
To retrieve the region names, bounding boxes, and boundary points for the power plan
regions, use the get_power_plan_regions command together with the get_attribute
command. The following example creates a power plan region named region_1 and
retrieves the name, bounding points, and bounding box for all power plan regions.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

-group_of_macros {U1/RAM U2/RAM}
All blocks have been successfully merged
1
icc_shell> get_power_plan_regions
{region_1}
icc_shell> get_attribute [get_power_plan_regions] name
region_1
icc_shell> get_attribute [get_power_plan_regions] points
{1310.980 1257.350} {1310.980 1135.225} {996.660 1135.225}
...
Reshaping Power Plan Regions

The update_power_plan_region command modifies the boundary of an existing power
plan region. You can use the update_power_plan_region command after you have
defined a power plan region. The syntax of the update_power_plan_region command is
as follows:
update_power_plan_region
-power_plan_region region_name
[-polygon {polygon_area}]
[-expand {x_dist y_dist}]
[-remove_jog_method expand | shrink]
[-jog_threshold threshold]
[-remove_notch_type convex | concave]
[-notch_threshold threshold]
Use the -polygon option to create a new boundary for the power plan region by specifying
bounding points. Use the -expand option to enlarge the power plan region boundary by a
specified amount. You can also specify the -expand option with a negative distance to
shrink the power plan region. Figure 8-6 shows a power plan region before and after running
the update_power_plan_region command with the -expand option.

Figure 8-6 Power Plan Region Expansion
Original power plan region update_power_plan_region \

-power_plan_region region1 \
-expand {20 20}
Use the -remove_notch_type and -notch_threshold options to remove the specified

notch type from the power plan region. Specify convex to remove notches that extend
outside the region; specify concave to remove notches that indent into the region. The
command removes any convex or concave notches with a width smaller than the threshold
specified by the -notch_threshold option. Figure 8-7 shows a power plan region before
and after running the update_power_plan_region command with the
-remove_notch_type concave and -notch_threshold 1000 options.
Figure 8-7 Notch Removal

-remove_notch_type concave \
-notch_threshold 1000
Use the -remove_jog_method and -jog_threshold options to remove jogs in the power
plan region. Specify -remove_jog_method expand to increase the size of the region;

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
specify -remove_jog_method shrink to decrease the size of the region. The command
removes any jog edge in the region that is shorter than the threshold specified by the
-jog_threshold option. Figure 8-8 shows a power plan region before and after running the
update_power_plan_region command with the -remove_jog_method expand and
-jog_threshold 1000 options.
Figure 8-8 Jog Removal

-remove_jog_method expand \
-jog_threshold 1000
Reading and Writing Power Plan Regions

To write out and read in a power plan region, use the write_power_plan_regions and
read_power_plan_regions commands. The write_power_plan_regions command
writes an ASCII file containing the coordinates of the power plan region. The following
example writes out a power plan region file, displays the contents, and reads the file.
icc_shell> write_power_plan_regions -output core.reg
1
icc_shell> sh cat core.reg
Begin Power Plan Region Definition: region_1
345.565 1843.705
1846.165 1843.705
1846.165 345.565
345.565 345.565
End Power Plan Region Definition
icc_shell> read_power_plan_regions core.reg
1

Creating the Power Ring Template File

The power ring template file is a text file that describes the metal layer, width, spacing, and
offset for the horizontal and vertical segments of the power ring and specifies advanced
rules for power ring vias and ring alignment to standard cells. A power ring template contains
a template header, one or more side sections, and an optional advanced_rule section.
If you specify unique template names, you can combine multiple power ring templates and
power mesh templates in a single template file. The power mesh template syntax is
described in “Creating the Power Mesh Template File” on page 8-32. Both the power ring
and power mesh templates support parameters. Using parameterizable templates, you can
assign power ring parameters when you implement the power rings and experiment with
different configurations without modifying the template. You can use parameters to define
width, spacing, and offset for the power rings. When you compile the power rings, you can
assign values to the parameters by using the set_power_ring_strategy command.
The power ring and power mesh template header uses the following syntax:
template : template_name (parameter1, parameter2, ...) {
You can also specify a header without parameters by using the following syntax:
template : template_name {
For more information about using parameters in templates, see “Creating and Using
Parameters in a Template File” on page 8-35.
Power Ring Template Side Section

The side section that follows the template header defines the layer, width, spacing and
offset for the power ring. You can create one or more side specifications in a single ring
template. The side section uses the following syntax:
# The side section defines the configuration of one or more sides of a
# rectangular or rectilinear ring. You can specify multiple side
# sections. Specify "horizontal" or "vertical" to assign properties
# for all horizontal or vertical sides. Specify side numbers to assign
# properties for individual ring segments. Side number settings
# override horizontal and vertical settings. Side numbering starts with
# 1 from the lowest leftmost edge of the pattern and increments in the
# clockwise direction.
side : horizontal | vertical | {index1, index2, ...} {
# The layer specification defines the layer used to

# create the ring segment
layer : layer_name

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
# The width specification defines the ring width of the

# sides. Specify one or more values that correspond to the number
# of nets defined by set_power_ring_strategy. If the number of
# nets in the strategy is greater than the number of width values
# defined here, the last width value is used for any undefined
# values. The unit is microns.
width : {width1, width2, ...}
# The spacing specification defines the spacing between rings for

# multiple nets. Specify "minimum" to use the minimum spacing from
# the technology file for the ring width. Specify one or more
# values corresponding to the number of ring nets defined in the
# ring strategy. The number of spacing values is equal to the
# number of rings minus one. The unit is microns.
spacing : minimum | {spacing1, spacing2, ... }
# The offset specification defines the separation between the

# inner edge of the innermost ring and the boundary of the ring
# contour. The unit is microns.
offset : offset
}
Power Ring Template Advanced Rules Section

The advanced_rule section enables or disables advanced options during ring creation. The
advanced_rule section uses the following syntax:
advanced_rule : on | off {
# align_std_cell_rail : on enables the tool to align

# horizontal rings with standard cell rails such that
# the rings do not block vias on other nets. By default
# this rule is off
align_std_cell_rail : on | off
# corner_bridge : on enables the tool to create via

# bridges to connect rings that belong to the same
# net. By default, this option is off
corner_bridge : on | off
# honor_advanced_via_rule : on honors via rules

# specified by the set_preroute_advanced_via_rule
# command. By default, this option is off
honor_advanced_via_rule : on | off
}

Creating the Power Ring Strategy

The power ring strategy associates the power ring template with the following design
characteristics and specifications:
• The list of power and ground nets for the power ring
• An extension specification for the power ring
• The routing periphery for the power ring
• A skip specification for the power ring
In the template-based power planning flow, the details of the power and ground rings are
defined within a template file. The template file supports complex, design-independent
power structures that can be used across several designs. See “Creating the Power Ring
Template File” on page 8-19 for more information about the power ring template file.
You can define multiple ring strategies for a single design. For multivoltage designs, you
might require a different strategy for each voltage area.
The set_power_ring_strategy command defines the strategy for the power rings in your
design. The syntax of the set_power_ring_strategy command is as follows:
set_power_ring_strategy
strategy_name
-nets nets
[ -core
| -voltage_areas voltage_areas
| -polygon {polygon_area}
| -macros macro_names
| -power_plan_regions power_plan_region_name]
[-template template_spec]
[-extension {extension_spec}]
[-skip {skip_spec}]
Each power ring strategy is identified by a unique strategy name. You can create more than
one strategy by running the set_power_ring_strategy command multiple times. The
power ring periphery is defined by the -core, -voltage_area, -polygon, -macros, or
-power_plan_regions option.
The extension strategy defines which ring segments to extend, the direction they extend,
and the distance of the extension. This option is specified by the -extension option. The
extension specification for the power ring contains the nets:, direction:, and sides:
keywords. If you omit one or more net names from the specification, the command extends
all the nets defined by the -nets option. You can specify the extension direction by including
the direction: keyword and up to four directions by using the letters L,R,T and B for left,
right, top, and bottom respectively. Vertical power ring segments extend only in the top and

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
bottom directions. Horizontal power ring segments extend only in the left and right
directions.
You can prevent the tool from creating all segments of the power ring by specifying the
-skip option of the set_power_ring_strategy command. The option omits the specified
power ring segments for each power net in the ring. Specify the power ring nets, sides, and
layers by using the following syntax:
-skip {{nets: net_name} {sides: {side_1 side_2 ...}} \
{layers: layer_name}}
You can specify multiple sides within braces. The lowest leftmost side of the ring periphery
is side 1. Side numbers increase as you proceed clockwise around the ring.
Reporting and Removing Power Ring Strategies

You can report existing power ring strategy settings for all defined strategies by using the
report_power_ring_strategy command. To delete one or more power ring strategies,
use the remove_power_ring_strategy command. To delete all power ring strategies, use
the -all option with the remove_power_ring_strategy command.
The following example shows the output of the report_power_ring_strategy and
remove_power_ring_strategy commands.
icc_shell> report_power_ring_strategy
******************************************
Report : Power Ring Strategy
Version: F-2011.09
Date : Mon Aug 22 16:38:45 2011
******************************************
Power Ring Strategy : ring_strategy_1
Net names : VDD1 VSS1
Template : ringtemplate.tpl
Routing region : region1
Net Extension : -- Nets -- -- Direction -- -- Sides --
Skip Side : -- Nets -- -- Layer -- -- Sides --
Power Ring Strategy : ring_strategy_2
Net names : VDD2 VSS2
Template : ringtemplate.tpl
Routing region : region2
Net Extension : -- Nets -- -- Direction -- -- Sides --
Skip Side : -- Nets -- -- Layer -- -- Sides --
1
icc_shell> remove_power_ring_strategy -all

Power plan strategy ring_strategy_1 is removed.
Power plan strategy ring_strategy_2 is removed.
1

Compiling the Power Rings

To add the power rings defined by the set_power_ring_strategy command to your
design, use the compile_power_plan command. The compile_power_plan command
uses the following syntax:
compile_power_plan
[-ignore_design_rules]
[-ring]
[-strategy strategy_name]
[-undo]
[-verbose]
[-write_default_template template_file_name]
To create a power ring for a power ring strategy, use the compile_power_plan -ring
-strategy strategy_name command.
Use the compile_power_plan -ring -write_default_template ring.tpl command to

write out an example power ring template to a file named ring.tpl. You can combine power
mesh and power ring templates within a single file if you make sure that each template name
is unique.
To compile the power rings using the GUI layout window, choose Preroute > Compile Power
Plan. See “Compiling the Power Mesh” on page 8-44 for more information about using the
GUI to compile the power rings in your design.
Template-Based Power Ring Examples

This section contains additional examples that show how to create template-based power
rings for different power network architectures.
Creating Rings Around Voltage Areas

The following design contains unique rings around three voltage areas. To implement this
power plan, do the following steps:
1. Create the ring.tpl template file.
template : ring_around_va {
side : horizontal {
layer : M3
width : 2.0
spacing : minimum
offset : 1.0
}
side : vertical {
layer : M4
width : 2.0

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
spacing : minimum
offset : 1.0
}
}
2. Set the power ring strategy.

icc_shell> set_power_ring_strategy strategy_1 -nets {VDD VSS} \
-voltage_areas VA1 -template ring.tpl:ring_around_va
icc_shell> set_power_ring_strategy strategy_2 -nets {VDD2 VSS VDD1} \
icc_shell> set_power_ring_strategy strategy_3 -nets {VDD3 VSS VDD1} \
3. Compile the power rings.

icc_shell> compile_power_plan -ring \
-strategy {strategy_1 strategy_2 strategy_3}
Figure 8-9 shows the layout with power rings around three voltage areas.
Figure 8-9 Rings Around Voltage Areas

Aligning Rings With Standard Cell Rails

The following design requires that the power and ground rings align with the standard cell
rails. To implement this power plan, do the following steps. Note that this power plan uses
parameters for the ring width and ring spacing.
1. Create the ring.tpl template file and include the align_std_cell_rail advanced rule
setting.
template : ring_align_stdcell(w,s) {
side : horizontal {
layer : M3
width : @w
spacing : @s
offset : 1.0
}
side : vertical {
layer : M4
width : @w
spacing : @s
offset : 1.0
}
advanced_rule : on {
align_std_cell_rail : on
}
}
2. Set the power ring strategy. The region_1 power plan region is defined outside this
procedure.
-power_plan_regions region_1 \
-template ring.tpl:ring_align_stdcell(2.0, minimum)

icc_shell> compile_power_plan -ring \
-strategy strategy_1

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-10 shows the layout with power rings aligned to standard cells.
Figure 8-10 Rings Aligned to Standard Cell Rails
Creating Rings Around a User-Specified Polygon

The following example creates a ring using a user-specified rectilinear pattern. In this
example, coordinates represents a set of x- and y-coordinates that describe the polygon.
1. Create the ring.tpl ring template file as described in the previous examples.
2. Create the power plan region with the specified coordinates.
-polygon { coordinates }
3. Create the power ring strategy.
-power_plan_regions region_1 -template ring.tpl

icc_shell> compile_power_plan -ring -strategy strategy_1

Figure 8-11 shows the layout with a power ring with a shape specified by a complex polygon.
Figure 8-11 Rectilinear Power Ring
Creating Rings Around Macro Cells

The following example creates rings around the Ram1, Ram2, Ram3, and Ram4 macro
cells.
1. Create the ring template file as described in the previous examples.
2. Create the power plan strategy.
-macros {Ram1 Ram2 Ram3 Ram4} -template ring.tpl


IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-12 shows the layout with power rings around the macro cells.
Figure 8-12 Power Rings Around Macro Cells
Creating Corner Bridging

Template-based power planning can create via bridges at ring corners to improve IR drop.
Do the following steps to create power rings with via bridges.
1. Create the ring template file. Note the corner_bridge advanced rule setting.
template : via_bridge(w,s) {
side : horizontal {
layer : METAL5
width : @w
spacing : @s
offset : 0
}
side : vertical {
layer : METAL6
width : @w
spacing : @s
offset : 0
}
corner_bridge : on
}
}

2. Create the power plan strategy.

icc_shell> set_power_ring_strategy strategy_1 -macros {Macro1} \
-nets {VDD VSS VDD VSS VDD VSS} \
-template via_bridge.tpl:via_bridge(2.0,minimum)
3. Compile the power ring.

Figure 8-13 shows a layout with standard corners and with additional via bridges at the
corners.
Figure 8-13 Layout Without and With Corner Bridging
corner_bridge : off corner_bridge: on
Creating Partial Power Rings

The following example creates partial power and ground rings around the specified group of
macros. Side numbering begins with side 1 at the leftmost edge at the bottom of the shape.
This example excludes sides 1 and 6 from the power ring.
1. Create the template file as shown in the previous examples.
2. Create the power plan region around the group of macros.
-group_of_macros {Ram1 Ram2}
3. Create the power ring strategy.

-power_plan_regions region1 -template ring.tpl \
-skip {{nets: {VDD VSS}} {sides: {1 6}}}

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

Figure 8-14 shows the layout after you run the previous steps.
Figure 8-14 Partial Power Ring With Excluded Sides
Creating Power Rings with Varying Segment Widths

The layout in Figure 8-15 contains a cross-shaped power ring with wider power segments
on the left, right, top and bottom sides. The power ring is created by defining a power plan
region and specifying wider power segments on sides 1, 4, 7, and 10 of the power ring. The
sides of the voltage area are labeled for reference.

Figure 8-15 Cross-Shaped Power Ring
To implement the cross-shaped power ring with wide and narrow ring segments,
1. Create the ring.tpl power ring template file and specify wider ring segments on sides 1,
4, 7, and 10.
template : wide_narrow_ring(narrow,wide) {
side : horizontal {
layer : METAL5
width : @narrow
spacing : minimum
offset : 0
}
side : vertical {
layer : METAL6
width : @narrow
spacing : minimum
offset : 0
}
side : {1 7} {
layer : METAL6
width : @wide
spacing : minimum
offset : 0
}
side : {4 10} {
layer : METAL5
width : @wide

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
spacing : minimum
offset : 0
}
}
2. Create the power plan region and power ring strategy.

-polygon {{900 500} {1300 500} {1300 900} {1700 900} {1700 1300} \
{1300 1300} {1300 1700} {900 1700} {900 1300} {500 1300} \
{500 900} {900 900} {900 500}}
icc_shell> set_power_ring_strategy ring_strategy_1 \

-nets {VDD VSS} -power_plan_regions region_1 \
-template ring.tpl:wide_narrow_ring(2.0,20.0)
3. Compile the power ring.

Creating Template-Based Power Meshes

As described previously, the template-based power planning flow separates the description
of the power and ground ring and mesh architecture from the implementation details. The
following sections describe the flow to create power meshes by using the template-based
power network synthesis flow. For more information about creating power rings in the
template-based power network synthesis flow, see “Creating Template-Based Power Rings”
on page 8-14.
Defining Power Plan Regions

In the template-based power network synthesis flow, power plan regions define the area
used to create the power meshes that form the power network. You can use a power plan
region as a working area to create power plan strategies or blockage areas for other routing
areas. For more information about creating power plan regions, see “Defining Power Plan
Regions” on page 8-14.
Creating the Power Mesh Template File

The power mesh template file is a text file that describes the width, spacing, pitch, offset,
and other characteristics of the power mesh. The power mesh template also supports
advanced rule definitions for strap optimization, strap alignment, strap insertion into channel
areas, and other design features. When you commit the power network, the tool creates the
power and ground mesh according to the power mesh definition in the template file, and the
power strategy set by the set_power_plan_strategy command.

Creating Template-Based Power Meshes 8-32
Template-based power planning supports parameterizable templates. This feature enables

you to define variables as placeholders for specific power mesh parameters and assign
values when you create the power mesh. The parameterizable template simplifies template
creation and maintenance by supporting template reuse and multiple templates within the
same file. Using parameterizable templates, you can assign values to the parameters, such
as width, offset, and spacing, by using the set_power_plan_strategy command.
Parameterizable templates allow you to easily experiment with different power strap
configurations without modifying the template. When you create the power plan, you can
assign values to the parameters by using the set_power_plan_strategy command.
A power mesh template contains a header, one or more layer sections, and an advanced
rule section. A template file can contain multiple power mesh and power ring templates. A
template header uses the following syntax:
template : template_name (parameter1, parameter2, ...) {
You can also specify a header without parameters by using the following syntax:
template : template_name {
Power Mesh Template Layer Section

The layer section defines the metal layer, strap width and other physical details of the strap
in the power mesh. You can create one or more layer definitions in a single power mesh
template. The layer section of the power mesh template uses the following syntax:
# The layer section defines the configuration of a layer in
# the power mesh. You can specify multiple layer sections.
layer : layer_name {
direction : horizontal | vertical
# The width specification defines the width of the power strap.

# Multiple widths correspond to multiple nets. The net order is
# defined by the strategy. The unit is microns.
width : {width1, width2, ...}
# The spacing specification defines spacing between power

# straps. Multiple spacings correspond to unique distances
# between multiple nets. The net order is defined by the
# strategy. The unit is microns.
spacing : minimum | interleaving | {spacing1, spacing2, ... }
# The number specification defines the number of straps in the

# power mesh.
number : strap_number

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
# The pitch value specifies the pitch between groups of nets

# defined by -nets argument of the set_power_plan_strategy
# command. The pitch between adjacent nets is controlled by the
# spacing parameter. The unit is microns.
pitch : pitch_between_net_groups
# The offset_type specification defines how the offset is

# calculated. offset_type: edge specifies that the offset is the
# distance between the routing region boundary and the inner edge
# of the first strap. offset_type: centerline specifies that the
# offset is the distance between the routing region boundary and
# the centerline of the first strap.
offset_type: centerline | edge
# The offset_start specification defines where the mesh placement

# begins. offset_start: boundary specifies that the placement
# begins at the boundary of the routing area defined in the
# strategy. Points {x y} specify the starting placement coordinate.
offset_start : boundary | {x, y}
# The offset specification defines the offset value. The unit is

# microns.
offset : offset_to_boundary_or_coordinate
# The trim_strap specification defines how power mesh straps are

# trimmed. trim_strap: true trims all wire segments that intersect
# less than two other wires. By default, all straps stop at the
# boundary of the routing area and the tool does not trim straps
# that touch the routing area boundary.
trim_strap : true | false

}
You can define multiple width or spacing values for nets defined in the layer section of the
strategy. If your strategy defines two or more nets with different widths and pitches, you must
define all widths and spacings by using braces, ({ }). For example, if your strategy contains
three nets VSS1, VSS2 and VSS3 with widths of 0.3, 0.35, and 0.5, and spacings of 0.2 and
0.25, you must include the following width and spacing definitions in your template file:
width : {0.3 0.35 0.5}
spacing : {0.2 0.25}
An example of the set_power_plan_strategy command that associates nets VSS1,

VSS2, and VSS3 with these width and spacing settings is:
icc_shell> set_power_plan_strategy -nets {VSS1 VSS2 VSS3}

Creating and Using Parameters in a Template File

You can pass parameters from the set_power_plan_strategy and
set_power_ring_strategy commands into the template. To replace a hard-coded value in
the template with a parameter, replace the numerical value with a parameter name
preceded by the at character (@) and add the parameter name to the template header. Do
not use parameters for keyword or Boolean values.
The following mytemplate.tpl template excerpt contains two templates: upper_grid and
lower_grid. The p1 and p2 parameters are declared in the header. The p1 parameter
replaces the numerical values for pitch for layers ME7 and ME5. The p2 parameter replaces
the numerical values for pitch for layer ME8 and ME6.
template : upper_grid(p1,p2) {
layer : ME7 {
pitch : @p1
...
}
layer : ME8 {
pitch : @p2
...
}
}
template : lower_grid(p1,p2) {
layer : ME5 {
pitch : @p1
...
}
layer : ME6 {
pitch : @p2
...
}
}
Using the previous template, the following set_power_plan_strategy commands specify

the template file, template name and parameter values to create the power plan. The first
command specifies the upper_grid template and sets parameters p1 and p2 to 3.0 and 9.0
respectively. The second command specifies the lower_grid template and sets parameters
p1 and p2 to 2.0 and 10.0 respectively.
icc_shell> set_power_plan_strategy s1 \
-template mytemplate.tpl:upper_grid(3.0,9.0)
icc_shell> set_power_plan_strategy s2 \
-template mytemplate.tpl:lower_grid(2.0,10.0)

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Power Mesh Template Advanced Rules Section

The advanced rule section of the template file controls various power mesh spacing and
alignment settings during mesh insertion with the compile_power_plan command. The IC
Compiler tool supports the following advanced rules in the template file:
• Optimize routing tracks
• Align strap with standard cell rails
• Insert straps inside channel area
• Honor the maximum distance from a standard cell to a power strap
• Align the straps with power-switch cells
• Honor advanced via rules
• Control stack via creation
The syntax for the advanced rules section is:

advanced_rule : on | off {
optimize_routing_tracks : on | off {
layer : layer_names # layers to optimize straps
alignment : true | false # perform alignment
sizing : true | false # perform automatic sizing
}
align_strap_with_stdcell_rail : on | off {
layer : layer_names # layers to align straps
align_with_rail : true | false
put_strap_in_row : true | false
}
# Insert extra straps inside the channel area when on

insert_channel_straps : on | off {
# Layer name of the extra straps inserted. If not
# specified, the tool uses the vertical layer from
# the template
layer : layer_names
# Width of the inserted straps, default is minimum

width : minimum | list_of_floats
# Spacing between inserted straps, default is minimum

spacing : minimum | list_of_floats
# Minimum spacing for channel strap insertion, straps

# are not inserted into channels narrower than
# the specified value
channel_threshold : float

# Only check if there is strap of the specified layer

# inside channel. If not, insert straps
check_one_layer : true | false
# Consider channels between placement blockages

# and between placement blockage and macros. By default,
# this directive is true and only
# channels between macros are considered
honor_placement_blockage : true | false
# Consider channels between voltage areas

# and between voltage areas and placement blockages.
honor_voltage_area : true | false
# Honor channels between hard keepout margins

honor_keepout_margins : true | false
# Space between boundary and macro or placement blockage is

# considered a channel
boundary_strap : true | false
}
honor_max_stdcell_strap_distance : on | off {
# Insert an extra strap if the distance between std

# cell area and the closest strap is greater than
# max_distance
max_distance : float
# Layer of the extra strap, default is the highest layer

# of straps in the template
layer : layer_name
# Distance between the extra strap and the nearest strap

offset : offset_values
}

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
# Insert extra straps to align with power-switch cells

align_straps_with_power_switch : on | off {
# Specify the power switch to align. By default, all

# cells with power-switch type are considered for
# strap alignment
power_switch : power_switch_name
# Layer of the alignment strap. If not specified, the

# vertical layer defined in layer section is used.
layer : layer_names
# Width of the alignment strap in microns. By default,

# the strap width defined in layer section is used.
width : float
# Direction of the alignment strap, the default is

# vertical
direction : vertical | horizontal
# Offset of the alignment strap from the center of the

# aligned pins on power switch. Default is 0
offset : offset_value
}
# Align the power and ground straps for the specified nets
# to the pins on the specified objects
align_straps_with_physical_cell : on | off {
# The master name of physical cell
cell: cell_name
# Direction of alignment straps

direction : horizontal | vertical
# Layer to align to the physical cell

layer : layer_name
# The pin name of the physical cell to align

# also check the net connectivity
pin : pin_name
# Width of the strap in microns

width : strap_width
# offset from the center of pin,

# positive for offset to the right
# negative for offset to the left
offset : offset
}

# Honor the advanced via rule set by the

# set_preroute_advanced_via_rule command.
honor_advanced_via_rule : on | off
# Define the stacked vias in the power grid. "all" creates vias at
# all strap intersections; "adjacent" creates vias only between
# adjacent layers without stacking vias; "specified" creates vias
# based on the connect_layers specification
stack_vias : all | adjacent | specified {
connect_layers : {lower_layer upper_layer}
}
}
Each advanced rule is associated only with its template. The following figures illustrate
different applications of the advanced rules.
Figure 8-16 shows the results after using the optimize_routing_tracks rule to control
strap width and spacing.
Figure 8-16 Layout Results Using optimize_routing_tracks
The insert_channel_straps advanced rule adds extra vertical straps in the channels
between hard macros. The tool identifies the channels between hard macros and skips
channels that contain synthesized straps or are too narrow for extra vertical straps. The tool
inserts extra vertical straps in the center of channels between hard macros. The
channel_threshold parameter defines the minimum threshold needed to insert straps.
You can select the layer and control the width and spacing of the strap. Figure 8-17 shows
an example where the tool inserts an extra strap.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-17 Strap Insertion
Figure 8-18 shows an example where the honor_max_stdcell_strap_distance rule is on

and the distance between the standard cell boundary to the power strap determines whether
a strap is inserted. In this design, if the distance is greater than 25 microns, a strap is
inserted. You can specify the layer used to insert the strap.
Figure 8-18 Channel Minimum Width for Strap Insertion
The align_strap_with_stdcell_rail rule controls strap alignment with the horizontal

power and ground rails of standard cells on the lowest horizontal metal layer. This rule can
also place the straps within the standard cell rails to avoid horizontal power straps
overlapping with the horizontal ground standard cell rails. An example is shown in
Figure 8-19.

Figure 8-19 Align Straps With Standard Cell Rails
Creating the Power Mesh Strategy

The power mesh strategy associates the power mesh template with the following design
characteristics and specifications:
• A list of power and ground nets for the power mesh
• An extension specification for the power mesh
• The routing area for the power mesh
• A blockage specification for the power mesh
• A template file name for the power mesh
In the template-based power planning flow, the details of the power and ground mesh are
defined within a template file. The template file supports complex, design-independent
power structures that can be used across several designs. See “Creating the Power Mesh
Template File” on page 8-32 for more information about the power mesh template file.
The power mesh strategy defines the routing area and a group of power and ground nets.
You can define multiple power mesh and ring strategies for a single design. For multivoltage
designs, you might require a different strategy for each voltage area.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The set_power_plan_strategy command defines the strategy for the power mesh in your
design. The syntax for the set_power_plan_strategy command is as follows:
set_power_plan_strategy
strategy_name
-nets nets
[-core |
-voltage_areas voltage_areas |
-polygon {polygon_area} |
-macros macro_names |
-power_plan_regions power_plan_region_name]
[-template template_spec]
[-extension {extension_spec}]
[-blockage {blockage_spec}]
Each power mesh strategy is identified by a unique strategy name. You can create multiple
strategies by running the set_power_plan_strategy command multiple times. The power
mesh area is defined by the -core, -voltage_area, -polygon, -macros, or
-power_plan_regions option.
The extension strategy defines which power mesh straps to extend, the direction they
extend, and the distance of the extension. This option is specified by the -extension
option. The extension specification for the power mesh contains the nets:, direction:,
and stop: keywords. If you do not specify one or more net names, the command extends
all the nets defined by the -nets option. You can specify the extension direction by including
the direction: keyword and up to four directions by using the letters L, R, T, and B for left,
right, top, and bottom respectively. By default, power and ground straps extend in all
directions.
The extension stop point for the power mesh is defined by the stop: keyword and one of the
following stop points: first_target, innermost_ring, outermost_ring,
design_boundary, or a user-specified distance. The first_target keyword specifies that
the power strap stops at the first wire segment of the same net; the innermost_ring
keyword specifies that the power strap stops at the innermost ring of the same net. The
outermost_ring keyword specifies that the strap stops at the outermost ring of the same
net, and the design_boundary keyword specifies that the strap extends to the boundary of
the current design. You can also specify a distance; the strap extends by the specified
distance from the boundary of the routing region. If you specify a negative distance, the tool
creates a gap between the strap end and the boundary. If you do not specify a stop point by
using the stop: keyword, the strap is not extended.
The following example defines a power mesh strategy named strategy1 that extends the
VDD1 and VDD2 nets in the left and bottom directions to the outermost ring, and extends
the VDD3 net in all directions.
icc_shell> set_power_plan_strategy strategy1 \
-nets {VDD1 VDD2 VDD3} -core -extension { \
{{nets: "VDD1 VDD2"} {direction: "LB"} {stop: outermost_ring}} \
{{nets: "VDD3"} {stop:design_boundary}}}

The -blockage option of the set_power_plan_strategy command specifies routing

restrictions in the routing area for the given power mesh strategy. You can specify multiple
blockages within the braces, with one blockage per group. Blockages are separated by
braces and contain the keywords nets:, layers:, and a destination keyword
voltage_area:, macro:, polygon:, plan_group:, or power_plan_region:. The
destination keywords require an associated value. The net names following the nets:
keyword are a subset of the nets specified by the -nets option. If you do not specify the
nets: keyword, the blockage applies to all the nets in the strategy. The layer names
following the layers: keyword are the routing layers on which the power and ground straps
are blocked. If you do not specify the layers: keyword, the blockage applies to all routing
layers. Use the voltage_area:, macros:, polygon:, or plan_group: keyword to represent
the blockage area.
To prevent placing the power and ground mesh over the VA1 voltage area, specify the
following syntax by using the -blockage option of the set_power_plan_strategy
command:
-blockage {{nets: "VDD"} {voltage_area: "VA1"}}
You can use a hyphen character ( - ) as a positional placeholder with the

set_power_plan_strategy -nets command. In the following example, the
compile_power_plan command ignores any specifications in the top.tpl template file that
refer to the second net name in the list. This feature enables template reuse.
icc_shell> set_power_plan_strategy strategy1 -core \
-nets {VDD1 - VDD3} -template top.tpl
Reporting and Removing Power Mesh Strategies

You can report existing power mesh strategy settings for all defined power mesh strategies
by using the report_power_plan_strategy command. To delete one or more power mesh
strategies, use the remove_power_plan_strategy command. To delete all power mesh
strategies, use the -all option with the remove_power_plan_strategy command.
The following example uses the report_power_plan_strategy and
remove_power_plan_strategy commands.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
icc_shell> report_power_plan_strategy
******************************************
Report : Power Plan Strategy
Version: F-2011.09
Date : Mon Aug 8 14:11:34 2011
******************************************
Power Plan Strategy : strategy1
Net names : VDD
Template : default.tpl
Routing region : core area
Net Extension : -- Nets -- -- Direction -- -- Stop at --
VDD LB outermost_ring
Blockage : -- Nets -- -- Area -- -- Layer --
1
icc_shell> remove_power_plan_strategy -all

Power plan strategy strategy1 is removed.
Compiling the Power Mesh

To create the power mesh defined by the set_power_plan_strategy command, use the
compile_power_plan command. Use the compile_power_plan
-write_default_template mesh.tpl command to write out an example power mesh
template to a file named mesh.tpl. You can combine power mesh and power ring templates
within a single file. The compile_power_plan command uses the following syntax:
compile_power_plan
[-ignore_design_rules]
[-ring]
[-strategy strategy_name]
[-undo]
[-verbose]
[-write_default_template template_file_name]
To compile the power mesh using the GUI layout window, choose Preroute > Compile
Power Plan. This opens the dialog box shown in Figure 8-20. You can also use this dialog
box in the GUI to add the power rings to your design. The dialog box lists the strategies
defined by using the set_power_plan_strategy command.

Figure 8-20 Compile Power Plan Dialog Box
You can preview the power mesh in the GUI before committing it. Click the Strategies button
to open the Power Plan Strategies dialog box and click the Preview tab. To preview nets,
select the Layers to preview, select the Nets option in the Nets section, and select Straps or
Rings to preview them. To preview routing areas, select the Routing Areas option. An
example power mesh preview is shown in Figure 8-21.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-21 Power Plan Preview
Template-Based Power Mesh Examples

This section contains additional examples that show how to create template-based power
meshes for different power network architectures.

Creating a Simple Power Mesh

The following example creates a simple power mesh for nets VDD, VDD1, VDD2, and VSS.
The pitch between the groups of horizontal straps is 60 microns and the pitch between the
vertical straps is 80 microns. The tool creates the straps within the VA1 voltage area. Use
the following steps to create the straps.
1. Create the template file and specify 60 as the horizontal pitch and 80 as the vertical pitch.
# power6080.tpl
template : default {
layer : METAL5 {
direction : horizontal
width : 5
spacing : minimum
number :
pitch : 60
offset_start : boundary
offset_type : edge
offset :
trim_strap : true
}
layer : METAL6 {
direction : vertical
width : 6
spacing : minimum
number :
pitch : 80
offset_type : edge
offset :
trim_strap : true
}
advanced_rule : off
}
2. Set the power plan strategy.

icc_shell> set_power_plan_strategy strategy_1 \
-nets {VDD VDD1 VDD2 VSS} -voltage_areas VA1 \
-template power6080.tpl
3. Compile the power plan.

icc_shell> compile_power_plan -strategy strategy_1

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
A section of the power straps created by these steps is shown in Figure 8-22.
Figure 8-22 Simple Power Mesh
Creating a Power Plan Strategy for a Multivoltage Design

Figure 8-23 represents a multivoltage design that contains four power domains, three
voltage areas, and a common ground net VSS. The voltage areas are defined as:
• TOP: Primary power nets VDD and VSS
• VA1: Primary power net VDD1
• VA2: Shutdown voltage area with the primary power net VDD2 and always-on power net
VDD
• VA3: Always-on voltage area with the primary power net VDD

Figure 8-23 Multivoltage Design
This design requires three power network strategies:

• VA3 and top shared power network strategy
• VA1 power network strategy
• VA2 power network strategy
To define the strategy, begin by assigning a strategy name. Identify the routing area, net
names, extensions, and blockages required for the strategy. In this example, the top-level
power and ground net names are VDD and VSS, and the routing area is the core area. The
VDD net extends in all directions except the top; the VSS net extends in all directions. The
VDD net is blocked by the USB macro cell and the VA1 voltage area. The VSS net is
blocked only by the USB macro cell. The strategy definition is as follows:
icc_shell> set_power_plan_strategy top_strategy \
-nets {VDD VSS} -core -blockage { \
{{nets: "VDD"} {voltage_area: "VA1"}} \
{macro: USB}} \
-extension { \
{{nets: "VDD"} {direction: "LRB"} {stop: outer_ring}} \
{{nets: "VSS"} {direction: "LRTB"} {stop: outer_ring}}} \
-template mytemplate.tpl:upper_grid(50,50)
The VA1 power network contains one net, VDD1, and uses the VA1 routing area. The VDD1
net extends left, right, and top. The definition for the VA1 strategy is as follows:

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
icc_shell> set_power_plan_strategy s1_strategy \

-nets VDD1 -voltage_areas VA1 \
-extension { \
{{nets: "VDD1"} {direction: "LRT"} {stop: outer_ring}}} \
-template mytemplate.tpl:upper_grid(20,40)
The VA2 power network contains the single VDD2 power net, and uses the VA2 routing
area. The VDD2 net does not extend and is blocked by the VA3 voltage area. The definition
for the VA2 strategy is as follows:
icc_shell> set_power_plan_strategy s2_strategy \
-nets VDD2 -voltage_areas VA2 \
-blockage { \
{{nets: "VDD2"} {voltage_area: "VA3"}}} \
-template mytemplate.tpl:lower_grid(20,20)
Note that each strategy references a unique template block defined within the
mytemplate.tpl template file. Using the same template file, you can create a unique power
and ground strap configuration for each voltage area by referencing different template
blocks and specifying unique template parameters. The template file syntax is discussed in
the following section.
Creating Power Straps on Macro Cells

The design shown in Figure 8-24 requires horizontal power straps on all macro cells that
have vertical power and ground straps. The number of straps is controlled by the cell height;
if the cell height is small than 120 microns, the tool creates one pair of VDD and VSS straps.
Otherwise, the tool creates two pairs.
Figure 8-24 Power Straps on Macro Cells

To implement this power plan, create two strategies: one for cells with a height of less than
150 um and one for cells with a height of more than 150 um. Use the following four steps to
create these straps:
1. Find all the macro cells with vertical pins, and divide them into two groups.
icc_shell> set vertical_pin_macros \
[filter_collection [all_macro_cells] "(orientation == S ) || \
(orientation == FS) || (orientation == N ) || \
(orientation == FN)"]
icc_shell> set cell100 [get_cells $vertical_pin_macros \
-filter height<150]
icc_shell> set cell200 [get_cells $vertical_pin_macros \
-filter height>150]
2. Create the 65nm.tpl template file with a parameter for the number of straps.
template : macro_strap(num_straps){
layer : M5 {
width : 3.0
spacing : minimum
number : @num_straps
pitch :
offset :
align :
trim_strap : true
advanced_rule : off
}
}
3. Set the power plan strategies.

icc_shell> set_power_plan_strategy macro_100 \
-nets "VDDC VSSC" -macros $cell100 \
-template 65nm.tpl:macro_strap(1)
icc_shell> set_power_plan_strategy macro_200 \
-nets "VDDC VSSC" -macros $cell200 \
-template 65nm.tpl:macro_strap(2)

icc_shell> compile_power_plan -strategy {macro_100 macro_200}
Creating a Power Grid in an Abutted Voltage Area

In the design shown in Figure 8-25, the voltage areas abut and the ground net VSS is
shared across voltage area boundaries. However, the power nets VDD1 and VDD2 do not
connect and stay on their respective sides; the nets are powered by different supplies.
Power nets VDD1 and VDD2 should be spaced by half the minimum spacing at the voltage
area borders to avoid a spacing rule violation.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-25 Abutted Voltage Areas
The following steps create the power plan for this design:
1. Create the mytemplate.tpl template file.
template : va_strap {
layer : METAL6 {
width : 10
spacing : minimum
number :
pitch : 82
offset : 7
trim_strap : true
}
layer : METAL7 {
width : 10
spacing : minimum
number :
pitch : 92
offset : 46
trim_strap : true
}
}

2. Create a strategy for each voltage area.

icc_shell> set_power_plan_strategy s1 -nets {VDD1 VSS} \
-voltage_areas VA1 \
-extension {{nets: VDD1} {direction: L} {stop: -half_space}} \
-template mytemplate.tpl:va_strap
icc_shell> set_power_plan_strategy s2 -nets {VDD2 VSS} \
-voltage_areas VA2 \
-extension {{nets: VDD2} {direction: R} {stop: -half_space}} \
-template mytemplate.tpl:va_strap
Note that the expression {stop: -half_space} defines a stopping point for the power
strap that is one half the minimum spacing distance within the voltage area. If you specify
{stop: half_space} without the minus sign, the command extends the strap to one
half the minimum spacing beyond the voltage area boundary. The minimum spacing is
defined in the technology file.
icc_shell> compile_power_plan -strategy {s1 s2}
Creating Extension Finger Connections

The design shown in Figure 8-26 contains macro cells with an internal power and ground
ring. To implement this power network, begin by creating a power and ground ring around
the macro cell. The preroute_instances command creates only one connection per top,
bottom, left, and right side for the VDD net and the VSS net. The rings in the macro cell must
connect to the chip-level power and ground ring by using extension fingers.
Figure 8-26 Power Plan

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-27 External Power Ring
To implement this power plan, define the routing area as the macro cell boundary and create
a reduced power plan region for each of the macro cells based on the macro cell boundary.
You can extend the power straps in each direction and limit the extension to first_target.
The following steps create the template-based power plan for this design.
template : top_two {
layer : METAL7 {
width : 1.5
spacing : interleaving
number : 10
pitch :
offset :
trim_strap : true
}
layer : METAL8 {
width : 2.0
spacing : interleaving
number : 10
pitch :
offset :
trim_strap : true
}
}

2. Define the power plan region and power plan strategy.

Using the macro as the routing area, create a blockage based on the internal area of
macro and extend the power straps to the outer ring.
icc_shell> create_power_plan_regions r_in \
-group_of_macros ramcell5 -expand -12.8
icc_shell> set_power_plan_strategy s_macro \
-macros ramcell5 -nets {VDD VSS} \
-blockage {power_plan_region: r_in} \
-extension {stop: outer_ring} \
-template mytemplate.tpl:top_two

icc_shell> compile_power_plan -strategy s_macro
Creating Pad Ring Connections

The design shown in Figure 8-28 connects power straps to pad rings.
Figure 8-28 I/O Pad Ring
To implement this power plan, define the power plan strategy and compile the power plan
as follows:
icc_shell> set_power_plan_strategy s_top -core \
-nets {VDD VSS} -extension {stop: pad_ring}
icc_shell> compile_power_plan -strategy s_top
The -extension {stop: pad_ring} option extends the VDD and VSS power straps to the
pad ring and connects them. When you specify this option, power straps that extend to the
pad or core ring can use an adjacent layer for routing to avoid a power or ground strap that
is blocking the extension. This applies only when the straps extend outside the core to
connect to a core or pad ring.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Inserting Straps into the Channel Area

The design shown in Figure 8-29 uses power straps within the channel area.
Figure 8-29 Channel Straps
During the design process, channel areas might form between adjacent macros; by default,
straps are not inserted into channels if the strap pitch does not place them there. You can
change this behavior by using advanced rule support.
To create straps in the channel area, set advanced_rule to on and set
insert_channel_straps to on in the advanced rules section. Define the layers, strap
width, spacing, and minimum channel threshold for the strap. The following template
skeleton enables channel straps that are routed using layer M5 with a strap width of 1.89
microns for channels that are 10 or more microns wide.
template : channel_strap {
layer : M5 {
# additional directives not shown
}
layer : M6 {
# additional directives not shown
}
# additional rules not shown
insert_channel_straps : on {
layer : {M5}
width : 1.89
spacing : minimum
channel_threshold : 10
}
}
}

Aligning Power Straps with Power Switches

The design shown in Figure 8-30 aligns power straps with power switches.
Figure 8-30 Power Straps and Switches
You can align power straps with power switches by setting the
align_straps_with_power_switch directive in the advanced_rule section to on. Specify
the power-switch name, layer, strap width, and direction for the power strap. The following
template skeleton aligns the power straps on layer ME6 with the power switches in the
vertical direction.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
template : align_strap {
layer : ME7 {
width : 1.00000
spacing : minimum
number : 6
pitch :
offset :
trim_strap : true
}
layer : ME6 {
width : 2.00000
spacing : minimum
number : 12
pitch :
offset :
trim_strap : true
}
align_straps_with_power_switch : on {
power_switch : HEAD16DM
layer : ME6 #strap layer
width : 2.0 #strap width
}
}
}

Nonuniform Power Straps

The layout shown in Figure 8-31 uses a nonuniform power grid.
Figure 8-31 Nonuniform Power Straps
To implement this power plan, create multiple power straps with unique individual spacing
and width values. Use a parameterized template and apply different values to the
parameters with the set_power_plan_strategy command.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
To implement this power plan, do the following steps:

template : nonuniform(p1,p2,p3,p4,p5) {
layer : METAL7 {
width : @p1
spacing : minimum
number : 36
pitch :
offset :
trim_strap : true
}
layer : METAL8 {
width : {@p1 @p2 @p3}
spacing : {@p4 @p5}
number : 12
pitch :
offset :
trim_strap : true
}
}
2. Set the power plan strategy by using parameters to represent power strap widths.
icc_shell> set_power_plan_strategy s_top \
-nets {VDD VDD1 VDD2} -core \
-template mytemplate.tpl:nonuniform(1.0,2.0,3.0,0.5,1.5)

icc_shell> compile_power_plan -strategy s_top
Creating Power-Switch Arrays and Rings

As process technology continues to scale to smaller and smaller geometries, the leakage
current of CMOS devices increases exponentially. An effective method of controlling
leakage power is to use multithreshold-CMOS technology with shutdown transistors. The
following sections illustrate the use of multithreshold-CMOS and power gating to reduce
leakage power in CMOS designs. The following sections describe the implementation of a
power-switch network in a multivoltage design.
• Power Switch Overview
• Selecting the Proper Power-Switch Strategy
• Creating a Power-Switch Array

Creating Power-Switch Arrays and Rings 8-60
• Creating a Power-Switch Ring

• Exploring Different Switch Configurations
• Optimizing Power Switches
• Connecting Power Switches
Power Switch Overview

You can implement power switching in your design during floorplanning to reduce static
leakage power to idle circuit blocks. Power switching is a technique that reduces leakage
power by cutting the flow of current between VDD and VSS while the circuit block is idle.
There are two types of power switches: header switches and footer switches. Header
switches with PMOS transistors are placed between VDD and the block power supply pins;
footer switches with NMOS transistors are placed between VSS and the block ground pins.
In many designs, only one type of switch is used. Switch cells are encapsulated within
standard cells.
Figure 8-32 Power-Switching Network Transistors
Header Switch Instantiation Footer Switch Instantiation

High threshold-voltage PMOS
transistors used for header
(VDD) power switching
CMOS logic block using low

Power-switching
threshold-voltage transistors
control signal
Power-switching
CMOS logic block using low control signal
threshold-voltage transistors
High threshold-voltage NMOS

transistors used for footer
(VSS) power switching

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The switching strategy shown in Figure 8-32 is a coarse-grain strategy; this strategy applies
power switching to the entire block through a single control. Multiple transistors in parallel
drive a common supply net for the block. In a fine-grain strategy, each library cell has its own
power switch, allowing fine-grain control over which cells are powered down. The fine-grain
approach has better potential for power savings, but requires more area.
Figure 8-33 shows the layout view of the power-switch array used to shut down power to a
circuit block. The power-switch network controls the current flow from the permanent power
network to the virtual power network. Permanent power is a constant supply that originates
from the top-level circuit pads and virtual power is switched by the power switch.
Figure 8-33 Power Switch and Power Rails
Selecting the Proper Power-Switch Strategy

Although power gating uses relatively large power-switch cells, the actual current available
to the switched power network might be less than that available on the permanent power
supply rails. The current reduction depends on the dynamic power requirements of the
shutdown block, the size of the voltage area, and the number of power-switch cells. The
physical placement of the power-switch cells is critical to achieve an acceptable IR
distribution within the shutdown block.
Two primary placement styles are used when placing power-switch cells: array-style
placement and ring-style placement. In the array-style approach, cells are placed in a
uniform grid within the voltage area. Array-style placement provides high drive current and

minimizes resistance, which in turn affects IR drop. The benefits of an array-style placement
include
• Greater control over IR drop distribution
• Better optimization that allows for fewer gating cells than the ring-style method
The shortcomings of the array-style approach include

• Less available cell placement area
• More difficult or impossible implementation with hard macros, as the existing placement
must be modified to accommodate power gates inside the voltage area
• Potentially more congestion or increase in area
• Potentially greater power grid complexity
In a ring-style approach, the tool places power-switch cells in a ring that surrounds the
shutdown voltage area. The benefits of a ring-style placement include:
• Easier power grid creation for the block
• Easier application to designs that contain hard macros, without the need for modification
inside the block. No extra cells or routing is required, with the exception of support for
retention, isolation, level shifting, and always-on logic.
• Easier connection of power and daisy chains by using abutment
A major limitation of the ring-style approach is that the IR drop impact might be unacceptable
toward the center of the voltage area as the distance increases from the power-switch cells.
The severity of the IR drop depends on the voltage area size, shape, and internal dynamic
power requirements of the block. For some designs, it might be impossible to implement a
ring-style approach without violating IR drop and inrush current requirements.
Defining a Power Switch Placement Strategy

You can use the set_power_switch_place_pattern_strategy command to define a
power switch placement pattern for the create_power_switch_array command.
set_power_switch_place_pattern_strategy
[-direction horizontal | vertical]
[-connect_mode HFN | DAISY]
[-driver driver_switch_cell]
[-pattern pattern_name]
[-flip]
[-connect_power_switch]

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Use this command to specify the pattern direction, daisy-chain or high-fanout net connection
mode, the driver switch cell name, whether the pattern is flipped during placement and
whether the power switch cells are connected during placement. Specify a name for the
pattern with the -pattern pattern_name option and use the same pattern name when you
specify the create_power_switch_array -place_pattern command.
Creating a Power-Switch Array

You can use the create_power_switch_array command to add power switches in a
uniform grid array inside the voltage area. After inserting the power switches, the command
legalizes the power switches and locks their position by setting the is_fixed attribute on
each power switch. The create_power_switch_array command syntax is as follows:
create_power_switch_array
-x_increment dx
-y_increment dy
[-lib_cell lib_cell_or_power_switch
[-individual_mode normal | staggered]]
[-voltage_area voltage_area]
[-bounding_box { {llx lly} {urx ury} }]
[-relative_to_voltage_area]
[-offset_to_voltage_area offset_spec]
[-design hierarchy_name]
[-start_row index]
[-start_column index]
[-orientation {N | W | S | E | FN | FE | FS | FW}]
[-respect avoid_object_types]
[-place_pattern place_pattern_name]
[-prefix prefix_name]
The following example creates a power-switch array by using the

create_power_switch_array command. The command instantiates the
POWERSWITCH1 cell in a staggered pattern within the V_DOMAIN1 voltage area with a
spacing between cells of 120 microns in the y-direction and 120 microns in the x-direction.
The command attaches the V_DOMAIN1_ prefix to each inserted power-switch cell.
icc_shell> create_power_switch_array -lib_cell POWERSWITCH1 \
-voltage_area V_DOMAIN1 -y_increment 120 -x_increment 120 \
-prefix V_DOMAIN1_ -individual_mode staggered
Creating a Power-Switch Ring

The create_power_switch_ring command creates a full or partial ring of switch cells
around the voltage areas or macro cells in your design. You can use command options to
control the cell density of the switch cell ring, the type of filler cells that are inserted between
the power-switch cells, the startpoint, the orientation, and other settings. The command
places only the power-switch cells; it does not connect the power, ground, and control pins.

The command does not honor blockages or existing cells, but a warning message is issued
if the inserted cells create conflicts. The create_power_switch_ring command syntax is
as follows:
create_power_switch_ring
-switch_lib_cell lib_cell_or_power_switch
[-vertical_switch_lib_cell lib_cell_or_power_switch
[-filler_lib_cell collection_of_filler_lib_cell_names]
[-vertical_filler_lib_cell collection_of_filler_lib_cell_names]
[-outer_corner_lib_cell outer_corner_lib_cell_name]
[-inner_corner_lib_cell inner_corner_lib_cell_name]
[-area_object voltage_area_or_macro
| -polygon {list_of_points}]
[-design hierarchy_name]
[-prefix string]
[-switch_orientation N | W | S | E | FN | FE | FS | FW]
[-outer_corner_orientation N | W | S | E | FN | FE | FS | FW]
[-inner_corner_orientation N | W | S | E | FN | FE | FS | FW]
[-density switch_density | -switch_number number_of_switches]
[-offset offset_values]
[-start_point {point}]
[-end_point {point}]
[-check_overlap]
[-same_orientation]
[-respect avoid_object_types]
[-x_increment dx]
[-y_increment dy]
[-place_pattern pattern_syntax]
[-continue_pattern]
You can create a power-switch ring with each power-switch cell in the same orientation by
specifying the -same_orientation option. Use the -x_increment and -y_increment
options to control the spacing of the power switches in the ring. If the power-switch cell is a
standard cell, the command automatically snaps the cell to the nearest site row and ignores
the -switch_orientation option.
The following example creates a power-switch ring around the DOMAIN1 power domain.
The command uses the SWITCH_HEADER power-switch cell and creates a ring pattern
using the FILLER and HEADER library cells. Figure 8-34 shows the ring created by using
the command in the example.
icc_shell> create_power_switch_ring -area_object DOMAIN1 \
-switch_lib_cell SWITCH_HEADER \
-place_pattern { { FILLER HEADER FILLER } * }

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-34 Power-Switch Ring
When you specify more than one power-switch cell by using the map_power_switch
command, you can reference a particular cell by using the switch_name:lib_cell_name
syntax with the -switch_lib_cell option to the create_power_switch_ring command.
The following example maps two power-switch cells to the SW switch name and places the
cell_2 cell in the power-switch ring.
icc_shell> map_power_switch SW –domain VA –lib_cells {cell_1 cell_2}
icc_shell> create_power_switch_ring -area_object INST \
-switch_lib_cell SW:cell_2
You can specify unique power switch cells for placement on the vertical edges of the power
domain by using the -vertical_switch_lib_cell and -vertical_filler_lib_cell
options of the create_power_switch_ring command. Use the -inner_corner_lib_cell
and -outer_corner_lib_cell options to specify the inner and outer corner cells. For
example, the following command places the sw_h power switch cell and filler_h filler cell on
the horizontal edges of the power domain, and places the sw_v power switch cell and filler_v
filler cell on the vertical edges. You can specify multiple filler cells in decreasing priority
within the braces ({}); the highest priority filler cell that fits the space is inserted into the
power switch ring.
icc_shell> create_power_switch_ring -switch_lib_cell sw_h \
-vertical_switch_lib_cell sw_v -filler_lib_cell {filler_h} \
-vertical_filler_lib_cell {filler_v} \
-outer_corner_lib_cell corner_outer \
-inner_corner_lib_cell corner_inner \
-area_object PD1 \
-switch_number 77
You can specify a UPF strategy name together with the -switch_lib_cell and
-vertical_switch_lib_cell options. The following example uses the
map_power_switch command to create a mapping between the PD1 power domain and the
sw_h and sw_v power switch cells.

icc_shell> map_power_switch -domain PD1 -lib_cells {sw_h sw_v} PSW

icc_shell> create_power_switch_ring -switch_lib_cell PSW:sw_h \
-vertical_switch_lib_cell PSW:sw_v \
-filler_lib_cell {filler_h} \
-area_object PD1
-switch_number 77
You can create the same power switch ring by using the following alternative syntax as
shown in the following example:
icc_shell> map_power_switch –domain PD1 –lib_cells {sw_h} PSW1
icc_shell> map_power_switch –domain PD1 –lib_cells {sw_v} PSW2
icc_shell> create_power_switch_ring -switch_lib_cell PSW1 \
-vertical_switch_lib_cell PSW2 \
-filler_lib_cell {filler_h} \
-area_object PD1
-switch_number 77
Exploring Different Switch Configurations

There are many possible configurations you can select when creating a power-switch array
network; the challenge is to determine the optimal configuration. You can use the
explore_power_switch command to estimate the IR drop of various power-switch array
configurations. The explore_power_switch command invokes both power network
synthesis and power network analysis and requires power network synthesis constraints set
by using the set_fp_rail_constraints command.
To perform power-switch exploration, provide the power-switch library cells for insertion, the
switch array x- and y-pitches, and the permanent and virtual supply names. The
explore_power_switch command automatically loops through the configurations you
provide and performs the following steps:
• Inserts header or footer arrays based on your specification
• Legalizes placement after power-switch insertion
• Logically connects permanent and virtual PG nets to power switches
• Performs multivoltage power network synthesis and creates a virtual power and ground
grid for all voltage areas
• Connects power switches automatically to the global supply

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• Preroutes standard cells if the -create_virtual_rails option is not specified

• Performs power network analysis on the current configuration by using the
analyze_fp_rail –nets {vdd+vdd_local} command
The explore_power_switch command creates a report containing a sorted list of

maximum IR drop values for all configurations. Based on the results of the command, you
can select the appropriate power-switch configuration to achieve the required IR drop for
your design.
The following command performs power-switch cell exploration on the current design. The
command explores the IR drop in the VA1 voltage area by instantiating the FOOTER8,
FOOTER16, and FOOTER32 power-switch cells using the x-spacing values of 25, 50, and
100 microns. The VIRTUAL_VSS virtual ground net and VSS real ground net are used in the
analysis. See the man page for a complete list of command options.
icc_shell> explore_power_switch \
-lib_cells {"FOOTER8" "FOOTER16" "FOOTER32"} \
-x_increment {25 50 100} -voltage_area VA1 \
-virtual_pg_net VIRTUAL_VSS -real_pg_net VSS
Optimizing Power Switches

After you insert power switches into a design, you can optimize the power switches by using
the optimize_power_switch command. The command sizes the power-switch cells to
attempt to reduce the IR drop to the target level set by using the
set_mtcmos_pna_strategy command. The following example uses the
optimize_power_switch command to optimize the power-switch network to achieve a
target IR drop of 120 mV.
icc_shell> set_mtcmos_pna_strategy -target_voltage_drop 120
icc_shell> optimize_power_switch -virtual_pg_net VIRTUAL_VDD \
-real_pg_net VDD
Connecting Power Switches

The control pins of the cells within the power-switch cell network must be connected to a
master sleep control signal. There are three connection styles: high fanout, daisy chain, and
fishbone. The high-fanout connection style uses a single net and buffers to simultaneously
power up the switch-cell network. The daisy-chain connection style enables the switch cells
in a sequential fashion and results in a lower inrush current. The fishbone configuration
connects power switches along the primary direction, either vertical or horizontal, then
creates additional routes to connect the remaining switches in the orthogonal direction.
Figure 8-35 shows a schematic view of these three connection schemes.

Figure 8-35 Daisy-Chain and High-Fanout Connection Styles

SLEEP SLEEP SLEEP
Daisy-Chain Configuration High-Fanout Configuration Fishbone Configuration
To connect the sleep control pins on the power-switch cells in daisy-chain mode, use the
connect_power_switch -mode daisy command. In the following example, the
connect_power_switch command connects the sleep control pins by using a daisy chain.
icc_shell> connect_power_switch -source SLEEP -port_name sleep_port \
-mode daisy -direction horizontal -verbose -voltage_area { VA1 VA2 }
To control how the tool creates connections to power switch cells during fishbone mode
routing, use the mv_mtcmos_detour_obstruction application variable. Set this variable to
true to avoid creating route connections in the orthogonal direction over hard macros and
create trunk lines in the primary direction on either side of the hard macro. This reduces the
routing over the hard macro and creates better quality of results.
Analyzing the Power Network

You can perform power network analysis on your design to predict the IR drop of different
floorplan and power routing configurations. Power network analysis extracts and analyzes
the power rail network connected to the net names you specify. You can analyze IR drop
and electromigration effects during initial power grid planning while the floorplan is
incomplete and the power ports of the standard cells are not yet connected. After detailed

Analyzing the Power Network 8-69
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
placement and power rail routing, you can verify that the size and quantity of the power nets
are adequate to power the design. The following sections describe the steps to perform
power network analysis on your design.
• Performing Power Network Analysis
• Creating Connectivity Views
• Performing Power Analysis With Switching Activity Information
Performing Power Network Analysis

To perform power network analysis on your design, use the analyze_fp_rail command or
choose Preroute > Analyze Power Network in the GUI. The analyze_fp_rail command
syntax is as follows:
analyze_fp_rail
-nets nets
[-analyze_power]
[-voltage_supply voltage]
[-pad_masters pad_masters]
[-read_pad_instance_file file_name]
[-read_pad_master_file file_name]
[-use_pins_as_pads]
[-top_level_only]
[-create_virtual_rails layer]
[-ignore_blockages]
[-ignore_conn_view_layers layer]
[-read_power_compiler_file file_name]
[-read_prime_power_file file_name]
[-read_default_power_file file_name]
[-output_directory directory_name]
Creating Connectivity Views

Use the create_connview command to invoke the Hercules connectivity engine to create
CONN views and current source files for hard macro cells in your design. Power network
analysis uses the create_connview command options and values that you specify,
together with those specified in the technology file for the Milkyway design library, to create
a Hercules runset.ev file. The Hercules connectivity engine uses the runset file and creates
a SMASH view in the database. After the SMASH view is created, the command uses this
data to create a CONN view for the hard macro cells. Power network analysis updates the
runset file each time you run the create_connview command.
For more information about the create_connview command, see the man page.

Performing Power Analysis With Switching Activity Information

The amount of power consumed by a design depends on the switching activity that occurs
within the design. You must provide an accurate model of the switching activity to produce
an accurate estimate of the power consumption for the design. Switching activity can be
annotated on design nets, ports, and cell pins.
After capturing the switching activity and annotating your design, you can invoke power
network analysis by using the analyze_fp_rail -analyze_power or
synthesize_fp_rail -analyze_power command. These commands calculate the
dynamic power value of each cell instance by considering the specified switching
probabilities and by using the obtained power values for IR drop analysis. For more
information, see “Performing Power Network Analysis for Each Cell Instance” on page 8-72.
Annotating Switching Activity

You can annotate the switching activity with one of the following methods:
• Use the set_switching_activity command to annotate particular design objects,
such as nets, pins, ports, and cell instances, of the current design.
Switching activity information consists of the static probability and the toggle rate. The
static probability is the probability that the value of the design object has a logic value 1.
It defines the percentage of time the signal is at a high state; the default is 0.5. The toggle
rate is the rate at which the design object switches between logic values 0 and 1 within
a time period. The following example defines a toggle rate of 0.25 and a static probability
of 0.4 for the CLK signal.
icc_shell> set_switching_activity -toggle_rate 0.25 \
-static_probability 0.4 CLK
For more information about the set_switching_activity command, see the man
page.
• Generate one or more switching activity interchange format (SAIF) files by using RTL or
gate-level simulation. Use the read_saif command to annotate the switching activity
information onto nets, pins, ports, and cells in the current gate-level design.
A SAIF file is typically generated within a simulation flow that contains a testbench. The
SAIF file contains the switching activity information organized in a hierarchical fashion,
where the hierarchy of the SAIF file reflects the hierarchy of the simulation testbench.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The following example uses the read_saif command in verbose mode to read the
data.saif file for the current design. The design appears as cpu/system_controller in the
SAIF file.
icc_shell> read_saif -input data.saif \
-instance_name cpu/system_controller
For more information about the read_saif command options, see the man page.
• Use default switching activity.
If no simulation data is available, the tool applies the built-in default toggle rate to analyze
the power consumption.
The switching activity of primary inputs and black box outputs cannot be propagated.
You can set the default toggle rate (0.1) and default static probability (0.5) for primary
inputs and black box outputs by using the power_default_toggle_rate and
power_default_static_probability variables. The default toggle rate value is the
value of the power_default_toggle_rate variable multiplied by the related clock
frequency. The clock can be specified by using the -clock option of the
set_switching_activity command. If no related clock is specified on the net, the
clock with the highest frequency is used. The default switching activity applied to these
objects is propagated throughout the design for power network analysis.
Performing Power Network Analysis for Each Cell Instance

After capturing the switching activity and annotating your design, you can invoke power
network analysis by using the analyze_fp_rail -analyze_power or
synthesize_fp_rail -analyze_power command to analyze the power information from
each cell instance in your design based on static probability and toggle rates. These
commands calculate dynamic power values for each cell instance by using the switching
probabilities and toggle rates that you specify. The power values are used to perform IR drop
analysis. Power is not calculated unless you specify the -analyze_power option.
In the following example, the voltage drop on the VDD net is analyzed by using a supply
voltage of 1.2 volts.
icc_shell> analyze_fp_rail -analyze_power -nets { VDD } \
-voltage_supply 1.2
You can use the -analyze_power option concurrently with the -power_budget and the
-read_default_power_file options.
Note:
If you use the -analyze_power option concurrently with the
-read_default_power_file option, the power specified in the default power file has a
higher priority than that calculated by the -analyze_power option.

Viewing the Analysis Results

After you complete power and rail analysis, you can check for power-related violations in
your design. The tool provides several analysis maps that overlay on the layout view of your
design, including a voltage drop map, a resistance map, an electromigration map, an
instance voltage drop map, an instance power map, and an instance power density map.
The following sections outline the steps to display the different power and rail analysis maps
available in the tool:
• Displaying the Voltage Drop Map
• Displaying the Resistance Map
• Displaying the Electromigration Map
• Displaying the Instance Voltage Drop Map
• Displaying the Instance Power Map
• Displaying the Instance Power Density Map
Displaying the Voltage Drop Map

After synthesizing the power network by using the synthesize_fp_rail command or by
choosing Preroute > Synthesize Power Network in the GUI, you can review the voltage drop
for different metal layers and locations in the layout. Choose Preroute > Power Network
Voltage Drop Map in the GUI to view the voltage drop map, or use the load_fp_rail_map
command. The tool reads the results data saved to the ./pna_output directory, constructs a
color-coded voltage drop overlay, and displays the overlay on the layout view. The
command also builds a color histogram that displays the distribution of voltage drop values.
Figure 8-36 shows an example voltage drop analysis overlay in the IC Compiler GUI.

Viewing the Analysis Results 8-73
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 8-36 Voltage Drop Map
You can configure the histogram and voltage drop map display by selecting threshold
voltages and metal layers in the GUI. To select only certain metal layers for IR drop analysis,
select or deselect the check boxes in the layers box on the PNA Voltage Drop panel of the
GUI. To enter a maximum or minimum threshold value for display in the histogram and
voltage drop map, select the “Max threshold” or “Min threshold” check box and enter the
value in the text box. To limit the voltage drop bins that are displayed, select or deselect the
check boxes in the histogram box in the PNA Voltage Drop panel of the GUI. After you
change the selection for either threshold or metal layers, click the Apply button to display the
updated histogram and voltage drop map.
To use the mouse to examine the voltage drop at individual locations in the layout, click the
Query button and move the pointer onto the layout view. As you move the pointer over
different points in the layout, the layout window displays the voltage drop at that point in the
query panel in the lower-left area of the layout.

To change the net for analysis, click the Reload button and select a net name in the Net
drop-down box. Click OK to view the results in the GUI.
Displaying the Resistance Map

The resistance map displays a map of resistivity values for the power network in your
design. The resistivity value at any instance pin or power grid location is the minimum path
resistance value of all independent path resistances to any voltage source location.
Figure 8-37 shows a series of paths to the chip_core/chip_core3/store.VDD pin; the lowest
resistivity value of 4.3 represents the resistivity for the node. You can use the resistance map
to check for unusually high values of resistivity, which might indicate missing vias or
disconnected nets in the power network.
Figure 8-37 Minimum Path Resistance
PAD_3 PAD_2
PAD_4 PAD_1
Instance pin name = chip_core/chip_core3/store.VDD

Min path resistance(resistivity) = 4.3 ohm
Use the load_fp_rail_map -nets net_name -type R command or choose Preroute >
Power Network Resistance Map in the GUI to load the map and histogram. The operation of
the GUI for changing the threshold values, histogram, metal layer selection, and query text
are similar to that for the voltage drop map; see “Displaying the Voltage Drop Map” on
page 8-73 for information about operating the GUI.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Displaying the Electromigration Map

Electromigration is the permanent physical movement of metal in thin wire connections
resulting from the displacement of metal ions by flowing electrons. Electromigration can lead
to shorts and opens in wire connections that can cause a functional failure. You can view the
electromigration analysis results for your design by using the load_fp_rail_map -nets
net_name -type EM command or by choosing Preroute > Power Network Electromigration
Map in the GUI. The operation of the GUI for changing the threshold values, histogram,
metal layer selection, and query text are similar to that for the voltage drop map; see
“Displaying the Voltage Drop Map” on page 8-73 for information about operating the GUI.
Displaying the Instance Voltage Drop Map

The instance voltage drop map displays voltage drop values for each instance in the design.
You can view instance voltage drop analysis results for your design by using the
load_fp_rail_map -nets net_name -type InstIR command or by choosing Preroute >
Power Network Instance Voltage Drop Map in the GUI. The operation of the GUI for
changing the threshold values, histogram, and query text are similar to that for the voltage
drop map; see “Displaying the Voltage Drop Map” on page 8-73 for information about
operating the GUI.
Displaying the Instance Power Map

The instance power map displays power values for each instance in the design. You can
view instance power analysis results for your design by using the load_fp_rail_map
-nets net_name -type P command or by choosing Preroute > Power Network Instance
Power Map in the GUI. The operation of the GUI for changing the threshold values,
histogram, and query text are similar to that for the voltage drop map; see “Displaying the
Voltage Drop Map” on page 8-73 for information about operating the GUI.
Displaying the Instance Power Density Map

The instance power density map displays power density values for areas of the design. You
can view instance power density analysis results for your design by using the
load_fp_rail_map -nets net_name -type PD command or by choosing Preroute >
Power Network Instance Power Density Map in the GUI. The operation of the GUI for
changing the threshold values, histogram, and query text are similar to that for the voltage
drop map; see “Displaying the Voltage Drop Map” on page 8-73 for information about
operating the GUI.

9
Performing Clock Planning 9
This chapter describes how to reduce timing closure iterations by performing clock planning
on a top-level design during the early stages of the virtual flat flow, after plan groups are
created and before the hierarchy is committed. For hierarchical timing closure, clock
planning can also be used to generate realistic clock latency through timing budgeting to fix
timing violations.
Clock planning minimizes clock skew by running block-level and top-level clock tree
synthesis during the early stages of the design flow. Clock planning determines the clock
budgets, allocates resources for clock buffers and clock routes, determines optimal clock pin
locations for soft macros, and estimates block-level insertion delays and skew for each plan
group. Having optimal clock pin locations is important to meet the final clock skew and
insertion delay targets with the optimal clock tree.
• Clock Plan Options Command
• Compile Clock Plan Command
• Generating Clock Network and Source Latency for Each Clock Pin of Each Plan Group
• Clock Planning on Multivoltage Designs
• Plan-Group-Aware Clock Tree Synthesis
• Clock Planning for Abutted Floorplans
• Checking for Electromigration After Clock Tree Synthesis
9-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Clock Plan Options Command

You can specify clock planning options during floorplanning with the
set_fp_clock_plan_options command.
set_fp_clock_plan_options
-anchor_cell cells
[-clock_nets clock_nets]
[-keep_block_tree true | false]
[-output_directory directory]
[-route_mode detail | global | none]
[-update_clock_latency true | false]
For more information about the command options, see the set_fp_clock_plan_options
man page.
To set clock plan options during floorplanning using the GUI window, first set the window
task mode to Design Planning if it is not already in that mode (File > Task > Design
Planning). Then choose Clock > Set Clock Plan Options. This opens the dialog box shown
in Figure 9-1.
Figure 9-1 Set Clock Plan Options Dialog Box
Enter the name of the clock nets on which to do clock planning in the Clock nets box. You
can type the names directly into the box, or click the browse button to the right of the box to
open a dialog box containing a list of clock nets. Enter the name of the clock buffer cell,
known as the anchor cell, to insert within the plan groups. All plan groups should use the
same buffer type. You cannot use an inverter as an anchor cell. The command inserts an
anchor cell in each plan group for each clock net that crosses the plan group boundary. The
anchor cells buffer the clock signal and isolate the top-level clock signal from the plan group
Chapter 9: Performing Clock Planning

Clock Plan Options Command 9-2
clock tree. The anchor cell is inserted inside the plan group at the center of the mass of
flip-flops that are connected to each clock net.
In the Route mode box, select Global route or Detailed route to route the top-level clock nets
after clock planning. The command creates clock pins and assigns a location where the
route crosses the plan group boundary. In the Output directory box, enter an alternate
directory name in which to write out all constraint files, log files, and generated reports from
clock planning. The default directory is cp_output. Select Keep block level tree to keep the
block-level tree after running the compile_fp_clock_plan command. By default, the
command removes the block-level clock tree after clock planning is complete.
Click the Set Clock Tree Options button to enter Interclock Delay Options, Clock Tree
References, Clock Tree Exceptions, Clock Tree Options, Optimize Pre-CTS Power Options,
and Clock Tree Optimization Options. You can also specify these options with the
set_inter_clock_delay_options, set_clock_tree_references,
set_clock_tree_exceptions, set_clock_tree_options,
set_optimize_pre_cts_power_options, and set_clock_tree_optimization_options
commands.
After setting the clock plan options, you can use the report_fp_clock_plan_options
command to report the settings. If no clock plan is set, the command reports the default
values. To reset the clock plan option settings, use the reset_fp_clock_plan_options
command.
Compile Clock Plan Command

After setting the clock plan options with the set_fp_clock_plan_options command, you
can create the clock plan with the compile_fp_clock_plan command.
compile_fp_clock_plan
[-operation_cond min | max | min_max]
[-anchor_only]
[-parallel]
For more information about the command options, see the compile_fp_clock_plan man
page.
To compile the clock plan during floorplanning by using the GUI window, first set the window
Planning). Then choose Clock > Compile Clock Plan. This opens the dialog box shown in
Figure 9-2.

Compile Clock Plan Command 9-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 9-2 Compile Clock Plan Dialog Box
The compile_fp_clock_plan command inserts anchor cells specified by the

set_fp_clock_plan_options command and synthesizes the clock trees within the plan
groups and at the top level. The command adds the cts_fixed attribute to the anchor cells
and new clock buffers; these cells are not moved during in-place optimization but can be
moved during clock tree optimization.
Select the operating condition for clock tree synthesis by choosing Max, Min, or Min/Max in
the Operation condition box. Choose the Insert anchor only option to only insert anchor cells
without synthesizing clock trees. Anchor cells are inserted at the “center of mass” of the
clock sinks inside the plan group. Note that, if you perform clock tree synthesis after anchor
cell insertion, the tool might insert buffers before and after the anchor cells inside the plan
group.
Select the Run parallel option to generate the clock trees within the plan groups using
multiple parallel processes. You must disable the -keep_block_tree option clock planning
option to use parallel processing.
The compile_fp_clock_plan command performs the following operations during clock
planning:
• Inserts anchor cells into the plan groups to isolate the plan group clock tree from the
top-level clock tree
• Performs fast clock tree synthesis within each plan group to estimate the insertion delay
and skew values at the input of the anchor cells
• Annotates the clock tree synthesis results onto the anchor cell floating input pins
• Synthesizes the top-level clock tree and connects it to the anchor cell floating input pins
• Runs global or detail routing on the clock interface nets

Compile Clock Plan Command 9-4
After you generate the clock tree with the compile_fp_clock_plan command, you can
generate detailed information for the clock trees in your design using the
report_clock_tree command. To generate the clock report using the GUI window, choose
Clock > Report Clock Tree. For more information about the clock tree report, see the IC
Generating Clock Network and Source Latency for Each

Clock Pin of Each Plan Group
For hierarchical timing closure, clock planning is also used to generate realistic clock latency
through budgeting to fix timing violations. Top-level timing violations result not only from
delays on combinational logic between registers, but also from clock skew between
launching and capturing registers.
When you perform clock planning operations, it enables the timing budgeter to generate
clock network and clock source latencies for each clock pin of each plan group in the design.
For more information, see “Performing Clock Latency Budgeting” on page 12-30.
• Clock network latency is the time a clock signal (rise or fall) takes to propagate from the
clock definition point in the design to a register clock pin.
Example:
icc_shell> set_clock_latency 2 -max -rise [get_clocks CLK]
• Clock source latency is the time a clock signal takes to propagate from its ideal waveform
origin point to the clock definition point in the design.
Example:
icc_shell> set_clock_latency 2 -source -max -rise [get_clocks CLK]
Figure 9-3 shows a design example with clock network latency and clock source latency.

Generating Clock Network and Source Latency for Each Clock Pin of Each Plan Group 9-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 9-3 Clock Network and Source Latency

Top
clk
Plan Group 2
clk
clk
Source Latency
Network Latency
Plan Group 1
Creating a Virtual Clock for I/O Paths

You can create a virtual clock for each plan group that describes the clock latency for
registers outside of the plan group. The naming syntax for virtual clocks created for clock
latencies outside the plan group is as follows:
• Clock signal for a register that initiates a signal (use two underscores):
clockname__v__in
• Clock signal for a register that captures a signal (use two underscores):
clockname__v__out
Note:
To minimize the number of virtual clocks, only the worst-case clock latency is created for
all input and output pins of plan groups initiated or captured by a virtual clock.
Figure 9-4 shows a virtual clock example.
• In plan group 1, the name of the input path is in1.
Top-level flip-flop A, which is clocked by clk1__v__in, has source latencies only.

Generating Clock Network and Source Latency for Each Clock Pin of Each Plan Group 9-6
• In plan group 1, the name of the output path is out1.

Flip-flop C in plan group 2 is clocked by clk1__v__out (clk2) and has both source and
network latencies.
• In plan group 2, the name of the input path is in2.
Flip-flop B in plan group 1 is clocked by clk2__v__in (clk1) and has both source and
network latencies.
Figure 9-4 Virtual Clock Example
Top
in2 C
clk2
clk1__v__out Plan Group 2
clk
in1 out1
A B
clk1__v__in clk1
Source Latency
Network Latency
clk2__v__in Plan Group 1
Data Latency
Clock Planning on Multivoltage Designs

You can create a clock network for a multivoltage design by inserting level-shifter cells into
clock nets that cross different power domains. Clock planning isolates each plan-group-level
clock net from the top-level clock tree by inserting an anchor cell. Note that your design must
already contain level-shifter cells to separate the power domain for each clock net.
If there is a level-shifter cell for an interface clock net (a net that comes from the top-level
clock net into a plan group), it is interpreted as an anchor cell. During clock planning, anchor
cells are inserted for each interface clock net only if they do not cross voltage areas. This
prevents the insertion of buffers and inverters into the wrong voltage areas. Clock planning

Clock Planning on Multivoltage Designs 9-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
isolates both plan-group-level clocks and voltage areas from the top-level clocks. Note that
feedthroughs created during clock planning might not honor the voltage area constraints for
all blocks in multivoltage domains.
Plan-Group-Aware Clock Tree Synthesis

You can perform plan-group-aware clock tree synthesis during clock planning. Clock tree
synthesis includes the following operations:
• Generates a clock tree that honors the plan groups while inserting buffers into the logic
hierarchy tree or, if it exists, into the corresponding physical region. The physical region
can be a voltage area, an exclusive move bound, or a plan group.
• Prevents new clock buffers from being placed on top of a plan group unless they drive
the entire subtree inside that particular plan group. This minimizes the number of clock
feedthroughs and simplifies the clock network for partitioning and budgeting.
To perform plan-group-aware clock tree synthesis during clock planning with fully abutted
floorplans, set the cp_full_abut_cts_region variable to true.
Clock Planning for Abutted Floorplans

You can perform hierarchical clock planning using the compile_fp_clock_plan command
on designs with fully abutted floorplans. This avoids possible DRC violations on nets going
through different plan groups.
From a placed design, set the cp_in_full_abut_mode variable to true to perform
hierarchical clock planning on fully abutted floorplans.
Run the compile_fp_clock_plan command to compile the clock trees inside plan groups
and build clock trees at the top level.
Note:
Clock tree planning resolves possible DRC violations on nets that connect to different
plan groups in a design, because the ideal clock buffer location is far from the plan group
that is associated with the logical hierarchy in which the buffer is added.
Checking for Electromigration After Clock Tree Synthesis

Cells in clock trees typically use more power than other cells because of the high switching
rate and the capacitive loads of large fanouts. If the cells of clock networks are physically
clustered or clumped together in the chip layout, excessive local currents through the power

Plan-Group-Aware Clock Tree Synthesis 9-8
supply rails can cause electromigration problems. To help prevent such problems, use the
set_clock_cell_spacing command, which ensures a minimum distance between clock
cells.
After clock tree synthesis has been completed, you can check for excessive local power
usage with the report_tile_power command. In the command, you specify the name of
the power or ground net to be analyzed, the supply voltage, the maximum allowable current
in the rails connected to standard cells, and the layer name of the rail if it is not the first metal
layer. For example,
icc_shell> report_tile_power -net VSS -current_budget 0.08 \
-voltage_supply 0.90 -guard_band_ratio 0.95
This command requests a chip power analysis of the VSS (ground) net, with the supply
voltage at 0.90 volts and a maximum rail current of 0.08 mA. An optional guard band ratio
further restricts the allowable maximum current to 95 percent of the nominal limit.
To determine whether this power constraint is met, the tool divides the standard-cell area
into units called power tiles. Each power tile consists of a set of standard cells supplied by a
segment of a power rail, extending from one via to another via, or from a via to the end of
the row. It then calculates the power consumed by all cells in the tile and compares this
value with the specified maximum current, subject to adjustment for the number of vias
associated with the rail segment and the guard band setting.
For each tile that exceeds the maximum allowable power, the command reports the total
power used in the tile, the total power budget for the tile, and the lower-left and upper-right
coordinates of the tile rectangle. For example,
...
Net : VSS
Supply Voltage : 0.900
Current Budget : 0.076
Standard Cell Rail Layer : METAL1
Power (mW) Power Budget (mW) Tile Bbox
-----------------------------------------------------------------
1.639e-01 1.368e-01 {{430.280 392.535} {482.300 399.915}}
1.639e-01 1.368e-01 {{639.370 392.535} {691.390 399.915}}
1.574e-01 1.368e-01 {{430.280 392.845} {482.300 400.225}}
1.710e-01 1.368e-01 {{639.370 392.845} {691.390 400.225}}
1.513e-01 1.368e-01 {{586.840 407.295} {639.370 414.675}}
1.575e-01 1.368e-01 {{586.840 407.605} {639.370 414.985}}
9.361e-02 6.840e-02 {{149.735 422.055} {731.350 429.435}}
9.342e-02 6.840e-02 {{150.790 422.365} {731.350 429.745}}
7.616e-02 6.840e-02 {{691.390 702.495} {731.350 709.875}}
7.254e-02 6.840e-02 {{691.390 702.805} {731.350 710.185}}
-----------------------------------------------------------------
Number of power tiles exceeding budget : 10

Checking for Electromigration After Clock Tree Synthesis 9-9
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The two different power budget values shown in the table represent the budgets for
single-via and two-via power tiles.
For more information about the report_tile_power command and its options, see the man
page for the command.
Power Tiles
A power tile typically consists of two rows of standard cells supplied by a single power or
ground rail extending between two vias, as shown in Figure 9-5. In this example, the ground
current is shared between two via connections, one at each end of the power tile. The
presence of two vias, one at each end of the tile, increases the total current that the rail can
handle.
Figure 9-5 Power Tile With a Via at Each End
VSS
VSS
This rail carries all the ground

current for the power tile
VDD
VSS
current current
VDD
Power tile height =
2 rows supplied by rail
Power tile width = Span of VSS rail between vias

A power tile can also consist of the standard cells extending from a via to the end of the row,
without a via at the other end of the tile, as shown in Figure 9-6. In that case, the rail must
be able to handle all of the current for the power tile where it connects to the single via.
Figure 9-6 Power Tile With a Single Via
Maximum current density in

VSS
This rail carries all the ground

rail occurs at via connection
current for the power tile
VDD
End of row
VSS with no via
current
VDD
Power tile width = Span from via to end of row
Power Budget Calculation

To determine whether the maximum current density constraint is met for the rail serving the
power tile, the tool compares the total power of the cells in the tile with this value:
PT = IB VR NV G
Where PT is the maximum allowable power of the tile, VR is the rail voltage, IB is the
budgeted maximum current for the rail, NV is the number of via connections to the power rail
in the tile (typically 2), and G is an optional guard band ratio specified in the
report_tile_power command. The default guard band ratio is 1.0.
For example, suppose that you specify the analysis for ground rails as follows:
For a power tile with a via at each end, the maximum allowable power of the tile is:
PT = (0.08 mA) x (0.90 volts) x (2) x (0.95) = 0.1368 mW
For a power tile with a via at just one end, the maximum allowable power of the tile is:
PT = (0.08 mA) x (0.90 volts) x (1) x (0.95) = 0.0684 mW

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
When you execute the report_tile_power command, the tool divides the standard cell
rows into power tiles according to the type of power rail (VDD or VSS) and the locations of
vias on those rails. Then it calculates the total power of each tile by adding up the power
used by each standard cell within the tile. If a standard cell extends beyond the end of the
tile, only the power corresponding to the fraction of the cell’s area within the tile counts
toward the total power of the tile.
Extra Power Straps on Higher Layers

Some power network synthesis flows apply additional via connections to high-power cells
using upper-layer metal layers. For example, in Figure 9-7, extra rail connections using the
METAL3 layer provide additional power and ground pathways for the current drawn by one
high-power cell. These additional pathways reduce the amount of current that must be
carried by the bottom-layer metal rail, easing any electromigration issues for that rail.
Figure 9-7 Power Tile With Three Vias
Extra connection using
VDD
VSS
VSS
higher-level metal layer
VDD
current current current current
VSS
VDD
Cell with high power usage
By default, the report_tile_power command does not consider the presence of

higher-level power supply connections. To consider them in the analysis, use the
-honor_extra_strap_layer option of the report_tile_power command. In that case,
the tool looks for additional power connections in higher layers, and if present, increases the
number of vias used to calculate the total tile budget. In this example, there are three vias
connected to the VSS rail in the power tile, providing four pathways for current flow out of
the rail, so the total power budget is calculated as follows:
PT = (0.08 mA) x (0.90 volts) x (4) x (0.95) = 0.2736 mW
To save runtime, use the -honor_extra_strap_layer option only if the design contains
extra power straps using higher layers.

10
Performing In-Place Timing Optimization 10
In-place timing optimization is used to improve the timing of a given design, and in particular,
to meet the timing constraints on the design. It is an iterative process based on virtual
routing. If you run in-place optimization after global routing, the tool deletes the global routes
and optimizes the design based on the virtual route timing.
• Performing In-Place Timing Optimization
• Running Trace Mode In-Place Optimization
• Using In-Place Optimization With Multivoltage Designs
• Performing In-Place Optimizations Based on Pin Locations
• Virtual In-Place Optimization
The optimization process starts with the most significant changes on multiple violation paths
that will quickly improve overall timing. Next, the scope is narrowed to focus on individual
paths. Netlist changes are committed only if the timing improves. The output is a legally
placed netlist that is plan group aware.
Three types of optimizations are performed: timing improvement, area recovery, and fixing
timing design rule violations. These optimizations preserve the netlist’s logical hierarchy,
and the physical locations of most cells change as little as possible.
10-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Several methods for improving timing are used, including

• Inserting buffers and inverters (legal locations are found automatically)
In the case of inverters, it is guaranteed that the polarity of the signals is preserved.
• Increasing or decreasing cell size (if the cell size is increased, the larger cell is
automatically adjusted to ensure that all cells are placed in legal locations)
• Moving cells
Similar to cell sizing, the cells are placed in legal locations.
Chapter 10: Performing In-Place Timing Optimization

10-2
Performing In-Place Timing Optimization

You can perform in-place timing optimization by using the optimize_fp_timing command:
optimize_fp_timing
[-area_recovery]
[-effort low | medium | high]
[-feedthrough_buffering_only]
[-fix_design_rule]
[-hfs_only]
[-keep_global_routes]
[-no_new_cells_at_top_level]
[-report_qor]
For more information about the command options, see the optimize_fp_timing man
page.
To perform in-place timing optimization using the GUI layout window, first set the window
Planning). Then choose Timing > In Place Optimization. This opens the dialog box shown in
Figure 10-1.
Figure 10-1 In Place Optimization Dialog Box
Select Add buffers for feedthrough nets only to skip timing optimization and only insert
buffers on feedthrough nets. Use this option only after performing pin placement with the
place_fp_pins command as described in “Performing Pin Assignment on Soft Macros and
Plan Groups” on page 11-7. You can use this option to minimize design changes at the late

Performing In-Place Timing Optimization 10-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
stages of design planning. The tool selects medium-sized buffers and inserts them near
each pin (port) location. During the optimization phases, in-place optimization might resize
or move these buffers. The buffers are added in the same hierarchy as the plan groups.
Select Perform high fanout synthesis optimization to skip timing optimization and perform
only high-fanout synthesis (HFS) on the design. You can combine this option with the Don't
add any new cells at top level option when implementing fully abutted or narrow channel
designs. Use this option, or the -hfs_only option with the optimize_fp_timing command,
to perform normal high-fanout synthesis. For incremental high-fanout synthesis, specify the
set_ahfs_options -incremental true command before running the
optimize_fp_timing –hfs_only command. Note the following limitations for the regular
and incremental high-fanout synthesis flows:
• Regular high-fanout synthesis is commonly used for the default flow
• Incremental high-fanout synthesis is required for the exploration flow to reduce runtime
• Regular high-fanout synthesis in the exploration flow is not well suited for analyzing the
clumped placement of pre-existing buffers
• Incremental high-fanout synthesis does not analyze preexisting buffers and their
placement
• Incremental high-fanout synthesis is optional for the regular high-fanout synthesis flow
These guidelines are based on the following QoR metrics: worst negative slack (WNS), total
negative slack (TNS), design rule check (DRC), and runtime.
Select High in the Effort row under Optimize timing if you want to use additional CPU time to
improve the timing of the design. By default, the tool uses Medium effort.
Select Fix design rules violations to repair violations during timing optimization. Design rule
violations, such as maximum transition time, maximum capacitance, and maximum fanout,
are repaired by inserting buffers, resizing gates, and performing high-fanout net synthesis
for medium- and high-fanout nets. When you run in-place optimization before global routing,
the routing and interconnects are preliminary and only major design rule violations are fixed.
After you finish global routing, optimization takes longer to run, but the results are based on
more accurate layout information.
Select Enable area recovery to apply additional processing time to reduce the cell area
without causing timing violations. The tool optimizes the area by removing some cells and
decreasing the size of other cells on timing paths with positive slack. Area recovery can
create additional die area that can be used for optimization of critical paths. Note that this
option might increase the timing delay on some noncritical timings paths, if the path does not
violate timing. For example, if the path has positive slack, area recovery might reduce this
slack to zero. Area recovery does not cause nonviolating paths (paths with nonnegative
slack) to become violating paths. Designs with high utilization benefit from area recovery,
but at the cost of higher runtimes.

Performing In-Place Timing Optimization 10-4
Select Keep global routes to prevent the tool from discarding global route information after
timing optimization. Select Don't add any new cells at top level to prevent the tool from
inserting new cells at the top level of the design; this option is useful on fully abutted and
narrow channel designs.
Select Report quality of results to display additional information regarding the worst negative
slack (WNS) and total negative slack (TNS) of the design, the utilization percentage of each
plan group and top level, the number of buffers added, and the number of cells sized for
each plan group and top level. An example quality of results report is as follows:
========== fpopt report ==========
-- timing --
WNS = 0.04 CLOCK = SYS_CLK PERIOD = 8.00
TNS = 0.00
-- utilization --
top utilization is 76.06
-- buffer added and sized --
total 0 plan groups
top level: added 0 new buffers sized 0 cells
1
Running Trace Mode In-Place Optimization

To improve capacity and runtime during in-place optimization, you can enable trace mode
by running the set_fp_trace_mode command. In trace mode, the tool optimizes only
top-level and interface paths, based on the options you specify.
Table 10-1 describes the set_fp_trace_mode command options. For more information
about these options, see the man page.
Table 10-1 set_fp_trace_mode Command Options
Command option Description
-include_top_logic Includes the top-level logic in the trace mode timing

netlist. By default, trace mode considers only
interface logic.
-verbose Prints additional informational messages.
Note:
To check if a design is in trace mode, use the get_fp_trace_mode command.
In trace mode, the tool considers only the top-level and interface paths, even though the
entire design is loaded.

Running Trace Mode In-Place Optimization 10-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
When trace mode timing is used in a flat design with plan groups defined for soft macros,
trace mode selectively filters paths by tracing only the nets and cells of timing paths at the
top level which cross plan group boundaries. Accordingly, the report_clock_timing
command reports only the timing violations on those paths. By using trace mode timing
analysis, you can detect and fix these timing violations in the early phases of the design flow.
This enables faster timing analysis by focusing on interface nets.
During the trace mode in-place optimization stage, only the interface logic or interface logic
plus top-level logic is optimized. This results in good QoR and might improve runtime.
Figure 10-2 illustrates the top-level, internal, and interface paths for trace mode timing.
Figure 10-2 Top-Level, Interface, and Internal Paths for Trace Mode Timing
Top
Plan Group 1 Plan Group 2
Top-level paths
Interface paths
Internal paths
Reporting Trace Mode Status

You can report the current option settings for trace mode by using the
report_fp_trace_mode_options command. The command shows whether top-level and
interface logic are included in the timing optimization. The following example shows a report
generated by the report_fp_trace_mode_options command.

Running Trace Mode In-Place Optimization 10-6
icc_shell> report_fp_trace_mode_options
Trace mode is set with following options:
interface : included
top : not included
verbose : off
1
Exiting the Trace Mode

To remove trace mode timing and return to the normal mode for timing analysis, use the
end_fp_trace_mode command. This command removes the trace mode design from
memory. After the next command that accesses the netlist of the design is used, it triggers
a reload of the entire design netlist.
Using In-Place Optimization With Multivoltage Designs

The optimize_fp_timing command detects multivoltage settings and performs
multivoltage-aware optimization. By following predefined multivoltage design rules, in-place
optimization improves timing by swapping cell instances. The command replaces cell
instances with cells of different sizes from within the same power domain and inserts buffers
that obey multivoltage design rules.
The tool handles always-on nets and honors power guides created by the
set_power_guide command during feedthrough buffer optimization. If a feedthrough net
has a power guide setting, the tool uses the appropriate buffers to satisfy the setting. The
tool uses normal buffering on nets that do not have a power guide setting.
Performing In-Place Optimizations Based on Pin Locations

You can use the optimize_fp_timing command after performing pin placement with the
place_fp_pins command. The tool chooses medium-sized buffers and inserts them near
each pin (port) location determined by the place_fp_pins command.
Virtual In-Place Optimization

The virtual_ipo command performs virtual in-place optimization on the design and
predicts timing after physical synthesis. During virtual in-place optimization, the tool
estimates the timing of the design by using analytical models and optimizes the design
timing without changing the placement or the netlist. As a result, the virtual_ipo
command can produce results faster than the optimize_fp_timing command. The output
from the virtual_ipo command contains estimated and annotated delays of cells and nets

Using In-Place Optimization With Multivoltage Designs 10-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
along paths that violate timing. Before using the virtual_ipo command in the exploration
flow, you should first add buffers on feedthrough nets by specifying the
optimize_fp_timing –feedthrough_buffering_only command before you run the
virtual_ipo command.
To remove timing data after performing virtual in-place optimization, use the virtual_ipo
-end command, which removes all back-annotation data inserted during the previous virtual
in-place optimization run. This operation is required after you have performed timing closure
using virtual in-place optimization, before proceeding to physical optimization. The virtual
in-place optimization flow is shown in Figure 10-3.
Figure 10-3 Virtual In-Place Optimization Flow
virtual_ipo
Timing Analysis
report_timing
virtual_ipo -end
For more information about virtual in-place optimization, see “Virtual In-Place Optimization”
in Chapter 6.

Virtual In-Place Optimization 10-8
11
Performing Routing-Based Pin Assignment 11
You can create top-level soft macro pins and plan group pins in hierarchical designs,
constrain the pins during pin creation, edit the soft macro pins, add feedthroughs, and
analyze the quality of the pin assignment results. The IC Compiler tool supports concurrent
pad and pin assignment.
• Setting Block-Level Pin Assignment Constraints
• Specifying Constraints for Individual Pins
• Performing Pin Assignment on Soft Macros and Plan Groups
• Adjusting the Position of Placed Pins
• Adding Feedthrough Pins
• Adding Feedthrough Pins on Multivoltage Designs
• Performing Pin Placement With Multiply Instantiated Modules
• Using Pin Guides for Pin Placement
• Checking Pin Assignment and Pin Alignment
11-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Setting Block-Level Pin Assignment Constraints

Prior to assigning pins, you can set constraints to specify the preferred locations and layers
for the pins in the soft macros and plan groups in your design. Global pin assignment
constraints apply to the entire design or the blocks you specify. The following sections
describe the global pin assignment constraints and physical pin assignment constraints
available in the IC Compiler tool.
Specifying Global Pin Assignment Constraints

You can set constraints on pins before performing pin assignment with the
set_fp_pin_constraints command.
[-allow_feedthroughs off | on]
[-allowed_layers layers]
[-block_level]
[-bus_ordering lsb_to_msb | msb_to_lsb | scrambled |
consistent_wirelengths]
[-corner_keepout_num_wiretracks wiretracks_number]]
[-corner_keepout_percent_side keepout_percentage]
[-exclude_clock_feedthroughs off | on]
[-exclude_feedthroughs nets]
[-exclude_hfn_feedthroughs hfn_number]
[-exclude_network]
[-exclude_scan_chain_net_feedthroughs off | on]
[-exclude_sides side_numbers]
[-feedthrough_map_file file_name]]
[-hard_constraints off | spacing | location | layer]
[-incremental off | on]
[-keep_buses_together off | on]
[-nets nets | -exclude_nets nets | -pins pins]]
[-no_stacking stacking_allowed | pg_pins_only | signal_pins_only | all]
[-pin_preroute_spacing preroute_spacing_number]
[-pin_spacing pin_spacing_number]
[-read_feedthrough_map off | on]
[-reserved_channel_nets nets]
[-reserved_channel_threshold channel_size]
[-scramble_skip skip_number]
[-use_physical_constraints off | on]
[blocks]
Pin constraints set with the set_fp_pin_constraints command are honored during pin
assignment on soft macros and plan groups. Pin assignment constraints are saved in the
Milkyway database.
Chapter 11: Performing Routing-Based Pin Assignment

Setting Block-Level Pin Assignment Constraints 11-2
The following command sets a pin placement constraint that allows the creation of
feedthrough ports on plan groups and soft macros. Bus bits are grouped together.
icc_shell> set_fp_pin_constraints -allow_feedthroughs on \
-keep_buses_together on
Specifying Pin Constraints for Special Conditions

You can use options of the set_fp_pin_constraints command to handle special
conditions in your design, such as narrow channels for special nets, bus bit ordering, and
detecting clock nets.
Reserving Narrow Channels for Special Nets

The set_fp_pin_constraints -reserved_channel_threshold command specifies the
maximum spacing between plan groups and soft macros for clock nets and other
user-specified nets. This feature is useful for floorplans that contain only narrow channels
between plan groups.
By default, the channel size is 0.0 and the command does not reserve a channel for special
nets. If you set a channel size greater than 0.0, any space between adjacent plan group
edges that are separated by less than this amount is considered a channel reserved for
special nets. You should set the -allow_feedthroughs option to off to exclude
feedthroughs on these special nets. Generally, feedthroughs are allowed for other nets.
During global routing, special nets can route freely through any space between the plan
groups. If the size of the space you specified is less than or equal to the threshold, other nets
are prevented from routing parallel to the direction of the channel. However, any net that has
a pin in the channel must enter the channel, regardless of whether it is a special net. For
example, the channel might contain pins because there are standard cells or small macros
in the channel area or there are pins on a block at the very edge of a plan group. In such
cases, the routing to these targets must enter the channel.
When this option is used during pin assignment, pins are discouraged on blocks that face
the channel unless they are perfectly aligned across the channel or are pins that belong to
special nets. The tool routes nonspecial nets by using other routing paths, or by creating
feedthrough pins.
Note:
Two voltage areas that face each other do not generate a reserved channel for special
nets. However, if your floorplan consists entirely of plan groups with narrow channels
between them and each plan group is a voltage area, you should allow voltage area
feedthroughs by using the set_fp_voltage_area_constraints
-allow_feedthroughs true command. Otherwise, both feedthroughs and channel
routing are restricted.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
You can use the set_fp_pin_constraints -reserved_channel_nets command to

specify a collection of nets which are permitted in the reserved channels. By default, this is
the set of all nets that are marked as clock nets in the Milkyway database.
If you use the -reserved_channel_nets option, the collection you specify must include all
nets to be routed in the reserved channels. These nets are implicitly marked as “exclude
feedthroughs” because they are routed through the channels. This option overrides any
previous reserved net specification.
Keeping Bus Bits Together

If you specify the set_fp_pin_constraints -keep_buses_together on command, the
plan-group-aware router automatically detects buses based on user-defined bus groups in
the Milkyway database. The tool groups bus pins together during pin assignment.
Reserving Space for Clock Pins

Before you set pin assignment constraints, you can ensure that there are optimal locations
reserved for clock net pins by using the mark_clock_tree -clock_net command. To
assign clock nets, the plan-group-aware router checks the net type in the Milkyway
database for nets with the “clock” net type. The command routes nets with the “clock” net
type before routing the remaining signal nets. If no clocks are detected, the command issues
a warning message indicating that there are no clock nets and requests that you run the
mark_clock_tree -clock_net command to mark the clock nets in the Milkyway database.
Reporting Pin Assignment Constraints

You can use the report_fp_pin_constraints command to display the pin assignment
constraints that are set for specified soft macros, plan groups, or ports. These constraints
control both pin assignment and pin placement.
Use the following command syntax to report pin constraints for each soft macro and plan
group in the design. The following example shows the output from the command for a design
containing a plan group.

icc_shell> report_fp_pin_constraints
report_fp_pin_constraints
------------------------------------------
Pin assignment options for plan group "U1":
Min layer for PG pins is metal2
Max layer for PG pins is metal6
Number of wire tracks between pins: 1
Number of wire tracks between preroutes and pins: 3
Allow overlapping pins on different layers
Soft constraint for pin-pin spacing
Soft constraint for pin location
Soft constraint for pin layer
No pins at the corners for 5 wiretracks
Create feedthrough ports
Consider internal placement.
Don't create EEQ pins
Don't retain movable pins
Physical constraints are in effect.
INFO: Global pin assignment options (for all blocks):

Create pins for tied high/low signal ports
Don't keep bus bits together
readFeedthroughMap on
inputFeedthroughMapFileName feedthroughs.txt
1
Specify the name of the soft macro or plan group on the command line to report pin
constraints for a specific soft macro or plan group.
icc_shell> report_fp_pin_constraints BLOCK1
Specify the -block_level option to report pin constraints for only the top level of the current
design.
icc_shell> report_fp_pin_constraints -block_level
You can use the report_fp_pin_constraints command to troubleshoot problems with

pin placement in your design. For example, if the tool is not placing some soft macro or plan
group pins, you should ensure that the pins are not excluded from placement. The tool skips
pin placement for pins that are connected to a net that is excluded by using the
set_fp_pin_constraints -exclude_nets command.
The following report shows that pins connected to nets datain_01, dataout_02, dataout_03,
data_internal1_06, data_internal2_04, and data_internal2_05 are excluded from placement
by the place_fp_pins command.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
icc_shell> report_fp_pin_constraints
------------------------------------------
Pin assignment options for plan group "PG1":
Min layer for PG pins is metal2
Max layer for PG pins is metal8
... more messages ...
List of 6 nets excluded from pin placement:
datain_01 data_internal2_04
dataout_02 data_internal2_05
dataout_03 data_internal1_06
Specifying Constraints for Individual Pins

You can use the set_pin_physical_constraints command to set constraints on
individual pins or nets in a block, soft macro, or plan group.
set_pin_physical_constraints
objects |
-pin_name pin_name [-cell cell_name] [-nets nets]
[-depth pin_depth]
[-exclude_sides exclude_side_numbers]
[-layers layers]
[-location point]
[-off_edge center | location | auto]
[-order order_number]
[-pin_spacing spacing]
[-side side_number]
[-width pin_width]
If a conflict arises between the individual pin constraints and the global pin constraints, the
individual pin constraints have higher priority. You can combine the -nets and -cell
options in the same command line. The constraints are stored in the Milkyway database. For
more information about the command options, see the set_pin_physical_constraints
man page.
The following example sets individual pin placement constraints on the datain_1 and
dataout_1 pins for the current design. The pins can be placed on layers metal3 and metal4.
The datain_1 pin is restricted to side 1, which is the bottommost left side of the module. The
dataout_1 pin is restricted to side 3.
icc_shell> set_pin_physical_constraints -pin_name { datain_1 } \
-layers { metal3 metal4 } -side 1
icc_shell> set_pin_physical_constraints -pin_name { dataout_1 } \
-layers { metal3 metal4 } -side 3
You can define constraints for specific plan group and soft macro pins in your design by
combining the -cell and -pin_name options of the set_pin_physical_constraints
command. The following example applies pin constraints to the datain_1 and dataout_1 pins

Specifying Constraints for Individual Pins 11-6
of the mod1 plan group. If you do not specify the -cell or -nets options, the constraints are
applied to the top-level pins.
icc_shell> set_pin_physical_constraints -pin_name { datain_1 } \
-cell mod1 -layers { metal3 metal4 } -side 1
icc_shell> set_pin_physical_constraints -pin_name { dataout_1 } \
-cell mod1 -layers { metal3 metal4 } -side 3
You can load a file containing set_pin_physical_constraints commands and apply the
constraints to a specific block by using the read_pin_pad_physical_constraints
command. The following example reads the pinconstraints.tcl file and applies the
constraints to the block1 plan group.
icc_shell> read_pin_pad_physical_constraints \
-cell block1 pinconstraints.tcl
Ignoring Constraints for Individual Constraints

By default, pin assignment honors any preexisting pin physical constraints set by using the
set_pin_physical_constraints command or the
read_pin_pad_physical_constraints command. To ignore preexisting physical
constraints on pins, use the set_fp_pin_constraints command with the
-use_physical_constraints off option as follows:
icc_shell> set_fp_pin_constraints -use_physical_constraints off
Performing Pin Assignment on Soft Macros and Plan Groups

After defining pin constraints by using the set_fp_pin_constraints and
set_pin_physical_constraints commands, you can assign pins at the top level of the
design, or to assign pins on soft macros and plan groups.
For top-level pin assignment, the tool considers the top-level connections to plan groups,
macros, and pad locations when it determines where to assign the pins. For block-level pin
assignment, the tool considers the cell placement inside the soft macro or plan group when
it assigns pin locations. The tool minimizes the wire lengths from the pins to the internal
connections within the soft macro or plan group. Use block-level pin assignment in a
bottom-up design flow.
The IC Compiler tool supports pin assignment on designs that contain mixed pads and
ports. Terminals are placed directly on top of and on the same layer as pad cells and bump
cells, and on soft macro pins that are internally connected to an I/O cell pin. This reduces the
RC delay between the primary signal I/O and the I/O cell to zero. When the I/O cell is located
within a soft macro child cell, a soft macro pin is placed on top of the I/O cell.

Performing Pin Assignment on Soft Macros and Plan Groups 11-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
If multiple I/O cell pins are assigned to the same pin connection, the tool creates electrically
equivalent terminals at the corresponding I/O cell pin locations. Except for bump cell pins,
an error occurs if the port to I/O cell pin connection is not one-to-one. Terminal placement
honors any specified physical pin constraints.
The pin assignment results are stored at the child level within the cell reference. If you open
a child cell after pin assignment and then close it without saving it, the pins are also
discarded.
Performing Plan-Group-Aware Global Routing

During pin placement, the tool performs global routing to determine the best pin locations for
each plan group and soft macro. You can set global routing options by using the
set_fp_pin_constraints and set_route_zrt_common_options commands.
By default, the place_fp_pins command performs global routing during pin placement.
You can run global routing and pin placement as separate steps by running the
route_zrt_global command, followed by the place_fp_pins -use_existing_routing
command. The -use_existing_routing option directs the command to perform pin
placement on plan groups by using the global routes from the previous run of
route_zrt_global.
Figure 11-1 shows the pin placement flow where you set global routing constraints and
perform global routing as separate steps.
Figure 11-1 Pin Placement Flow With Global Routing
Set pin assignment constraints
Perform plan-group-aware routing

set_route_zrt_common_options \
-plan_group_aware all_routing
route_zrt_global -exploration true
Place the plan-group pins

place_fp_pins [get_plan_groups]
Commit the hierarchy

Set the Zroute common route option to perform plan-group-aware routing by using the
set_route_zrt_common_options command as follows.
icc_shell> set_route_zrt_common_options -plan_group_aware all_routing

If you specify the -plan_group_aware common route option, the Zroute global router
becomes plan-group-aware. The Zroute global router reads the plan group definitions and
honors the pin placement constraints placed on the plan groups. The all_routing keyword
routes all the nets in the design and preserves the hierarchy and pin constraints for the pin
placement flow.
If you specify the set_route_zrt_common_options -plan_group_aware off command,
the Zroute global router ignores the plan groups and routes the design as flat. The default is
off.
Use the route_zrt_global command to perform plan-group-aware global routing as

follows.
icc_shell> route_zrt_global -exploration true
Improving the Quality of the Global Routing for Pin Assignment

Apply the following routing guidelines to create a more accurate pin assignment and
increase the effective usage of channel routing resources.
• Route nets completely inside the plan group if they exist only in the context of the
modules associated with the plan group hierarchy.
• Avoid routing nets without a connection to the logic modules associated with a plan
group over that plan group, unless feedthrough creation is allowed.
• Ensure that interface nets are routed across the plan group boundary at least as many
times as the number of ports on those nets for the associated logic module.
The router also tries to minimize the number of routes across the plan group boundary,
so that they exceed the number of ports only when necessary.
• Minimize jogs in the channels between plan groups.
• Route clock nets first, followed by signal nets.
Figure 11-2 shows an example of plan-group-aware global routing and pin assignment. The
picture on the left shows pins placed at the boundaries where the routes intersect the plan
group boundaries, as shown by the areas that are circled. The picture on the right shows the
actual pins created at the boundaries of the soft macros, as shown by the areas that are
circled. These are the exact locations where the routing crosses those boundaries.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 11-2 Plan-Group-Aware Global Routing and Pin Assignment

Plan-group-aware global Actual pins are created on
routing suggests pin the soft macro boundaries
locations at plan-group
boundaries
Improving the Performance of the Global Router

To increase the routing speed of the plan-group-aware global router, you can set the
-plan_group_aware Zroute common route option to top_level_routing_only during
floorplanning. This setting prevents subsequent route_zrt_global and place_fp_pins
commands from routing nets that are entirely contained within the plan groups. The
following command directs the router to perform global routing only at the top level of the
design.
icc_shell> set_route_zrt_common_options \
-plan_group_aware top_level_routing_only
Another technique to increase the speed of the global router is to use fast exploration mode
by specifying the -exploration true option to the route_zrt_global command. The
global router runs in a lower-effort mode that requires less processing time. Use the
congestion map to identify routing congestion hotspots.
Placing Soft Macro and Plan Group Pins

The place_fp_pins command performs pin placement on the soft macros and plan groups
in your design.

place_fp_pins
[[-block_level] [-effort low | high] |
-use_existing_routing]
[-include_flip_chip_style_connections]
[-retain_bus_naming]
[-verbose]
[-create_voltage_area_feedthroughs]
[-minimum_feedthrough_length route_length]
[soft_macros_or_plan_groups]
You can include plan group, black box, and soft macro reference names on a single
command line and perform pin placement in a single iteration by using the place_fp_pins
command. After performing pin placement, you can change the pin constraints and perform
an iterative pin placement.
The following example places the pins for the pg1 and pg2 plan groups. The -effort high
option specifies that the place_fp_pins command performs global routing in exploration
mode before placing the pins. By default, flyline routing is used for pin placement.
icc_shell> place_fp_pins -effort high [get_cells {pg1 pg2}]
Figure 11-3 shows a layout before and after pin placement by using the place_fp_pins
command.
Figure 11-3 Pin Placement on Plan Groups
Before plan group pin placement After plan group pin placement

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Performing Block-Level Pin Placement

You can assign pin locations for the top level of the current design by specifying the
-block_level option as shown in the following command.
icc_shell> place_fp_pins -block_level
Block-level pin assignment considers the cell placement, internal connections, and pin
constraints inside the soft macro cell.
Committing the Hierarchy

After finalizing the floorplan, you can commit the physical hierarchy by using the
commit_fp_plan_groups command to convert the plan groups in your design to soft
macros. The command also places pins physically on the soft macro. The placement of the
pins is based on the constraints you set by using the set_fp_pin_constraints command
and the set_pin_physical_constraints command, as well as the results of global
routing.
For more information about committing the hierarchy, see “Converting Plan Groups to Soft
Macros” on page 13-2.
During commit hierarchy, the commit_fp_plan_groups command converts plan groups to
soft macros by performing the following actions:
• Converts the design to a two-level hierarchical design (the design netlist is partitioned to
blocks and to the top level).
• Creates CEL views for each soft macro.
• Creates nets in the soft macros.
• Pushes cell rows (placement tiles) into the soft macro CEL views.
• Pushes power straps, ground straps, and standard cell preroutes down into each soft
macro CEL view.
• Pushes placement blockages down into each soft macro.
• Creates pin placement based on the routing results.
Note:
Commit hierarchy can take longer to run if power and ground straps and standard cell
preroutes are pushed down because each soft macro might require repair.
Plan groups that extend beyond the core boundary might have problems with pin and
feedthrough placement. Make sure that plan group boundaries are within the core
boundary.

The commit_fp_plan_groups command reports the plan groups converted to soft macros
and the number of pins converted for each plan group. The command also checks the
Milkyway database for any nets with the “clock” net type and assigns the pin slots for the
clock nets first. If no clocks are detected by pin placement during commit hierarchy, a
warning message is issued saying that no clock nets were found.
Adjusting the Position of Placed Pins

After placing soft macro and plan group pins by using the place_fp_pins command, you
can further adjust the placement of the pins by aligning the pins with other objects or
removing overlapping pins on different metal layers. The following sections describe the
commands used to align pins and remove overlaps.
Aligning Soft Macro Pins

You can align a set of soft macro pins relative to the pins on a reference macro by using the
align_fp_pins command.
align_fp_pins
[-align_with_child_hm_pins]
[-change_layer_width]
[-direction center | left | right | top | bottom]
[-fixed]
[-order_type low_to_high | high_to_low | net_connection]
[-propagate_single_pins]
[-reference object]
objects
The following example uses the align_fp_pins command to improve the alignment of the
mod2 soft macro pins with respect to the mod3 soft macro.
icc_shell> align_fp_pins -reference mod3 [get_pins "mod2/*"]
Figure 11-4 shows the mod2 and mod3 soft macros before and after pin alignment.

Adjusting the Position of Placed Pins 11-13
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 11-4 Pin Alignment on Soft Macros
Before pin alignment After pin alignment
Ordering Pins Alphabetically

You can place pins in alphabetical order by using the sort_fp_pins command. Specify the
-reverse option to reverse the sort order and order the pins in reverse alphabetical order.
The following example sorts the dataout pins on the mod2 module in reverse alphabetical
order.
icc_shell> sort_fp_pins -reverse [get_pins {mod2/dataout*}]
Removing Soft Macro Pin Overlaps

You can remove pin overlaps on soft macros and at the top level of the design by using the
remove_fp_pin_overlaps command.
remove_fp_pin_overlaps
[-cells cells]
[-pins pins]
The command moves the pins to remove the overlap without creating a spacing violation.
Fixed pins are not moved by the remove_fp_pin_overlaps command.
The following command removes overlaps on pins for the mod2 module.
icc_shell> remove_fp_pin_overlaps -pins [get_pins "mod2/*"]
Figure 11-5 shows two pins before and after overlap removal by using the
remove_fp_pin_overlaps command.

Adjusting the Position of Placed Pins 11-14
Figure 11-5 Overlap Removal
Before overlap removal After overlap removal
Note:
Pin overlap removal might fail if insufficient routing tracks are available or the pin
placement is overconstrained. Look for error messages in the console window after
performing this operation.
Adding Feedthrough Pins

The IC Compiler tool inserts feedthrough pins into plan groups and soft macros based on the
constraints and topology you define for your design.
Excluding Feedthroughs on Clock Nets

To exclude feedthrough generation on clock nets, specify the set_fp_pin_constraints
-exclude_clock_feedthroughs command or enable the “Exclude feedthroughs on clock
nets” option in the Add Pin Assignment Constraints dialog box in the GUI.
Specifying Net and Feedthrough Topology

You can provide user-specified feedthrough topology information to the router to control pin
placement. Save the net and feedthrough topology information to a file named
feedthroughMapIn, or specify the name of the feedthrough map file by using the

Adding Feedthrough Pins 11-15
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
-feedthrough_map_file option to the set_fp_pin_constraints command. The

feedthrough topology information describes how the tool should route a feedthrough net,
which blocks the feedthrough net passes through, and the feedthrough pin location and
metal layer used for the connection. The tool can also generate a mapping file that describes
the net and feedthrough topology for the design. You can edit the generated file and read in
the updated file to perform subsequent iteration in feedthrough placement, or create your
own feedthrough map file. The router implements the net and feedthrough topology
described in the feedthrough map file.
The general format of the feedthrough map file is:
Net_name1:
{Feedthrough block_name block_name ...}
{NoFeedthrough block_name block_name ...}
...
Net_name2:
{obj_type obj_name properties} {obj_type obj_name properties}
...
{Net_name3 Net_name4 Net_name5}:

...
Signal*:
RegPort[*]:
In the preceding example, block_name is the name of a plan group, soft macro, or black box
in your design, and obj_type can be Block, Pin, or Port. The Feedthrough and
NoFeedthrough keywords allow or prevent feedthrough routing through specified plan
groups, soft macros, and black boxes in your design. obj_name is a plan group, soft macro
or black box name, a top-level port name, a port name, or a pin name for an I/O pad. You
can use an asterisk (*) as a wildcard character to create a feedthrough definition for more
than one net at a time. You can also specify multiple net names within braces ({Net_name3
Net_name4 Net_name5}) for the same feedthrough definition.

The optional properties data contains additional information for each feedthrough.
Table 11-1 lists the supported property keywords and datatypes.
Table 11-1 Supported Feedthrough Object Properties
Keyword Datatype
side integer
offset float
layers list of layers
Note that the offset keyword cannot be used when you specify multiple nets by using
wildcards or multiple net names within braces. The following example defines the side,
offset and layers for the feedthrough in block2.
{Block block2 side 2 offset 100 layers {M3}}
The Feedthrough and NoFeedthrough keywords specify which plan groups, soft macros, or
black boxes the feedthrough net can pass. The feedthrough net can route through any of the
blocks specified by the Feedthrough keyword and cannot route through any of the blocks
specified by the NoFeedthrough keyword. To force a feedthrough on a block, specify the
Block keyword.
For example, the following feedthrough map file specifies that, for the DATA[0] signal,
feedthroughs can be created on blocks A and B and cannot be created on blocks C and D.
DATA[0]:
{Feedthrough A B}
(NoFeedthrough C D}
If the feedthrough map file contains a duplicate specification for a net, the tool uses the last
constraint in the file for that net. Note that nets that are not listed in the feedthrough map file
obey the current pin assignment constraints set by using the set_fp_pin_constraints
command. In addition, any feedthrough specification in the feedthrough map file takes
precedence over the set_fp_pin_constraints constraint settings.
You can provide only a partial specification for a feedthrough net. You are not required to
specify all connections along the route. Use the Block, Pin, or Port keywords to specify
only a portion of the feedthrough route. The tool creates feedthrough pins and completes the
route, even if the connections are not specified in the feedthrough map file.
Figure 11-6, Figure 11-7, and Figure 11-8 show example topologies and the control files
needed to produce the feedthrough topology. Note that Figure 11-7 illustrates a pairwise
constraint which specifies that the tool create a feedthrough on BlockB and a net connection

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
between blocks BlockA, BlockB, and BlockC. The tool connects the source to the target for
each pairwise constraint, regardless of any other feedthrough settings or constraints.
Figure 11-6 Feedthrough Topology Example 1
NetA
BlockA BlockC
BlockB
NetA:
{block BlockA} {block BlockB}

NetA
BlockA BlockC
BlockB
NetA:
{block BlockA} {block
or
NetA:

NetA
in
A BlockC
BlockB
NetA:
{port A} {block BlockB}
Note that you should specify a mapping file that does not over constrain the tool, which
might degrade the QoR. Also, do not mix the Feedthrough and NoFeedthrough keywords
with the Block, Port, and Pin keywords within the same net specification.
Use the following command to specify a mapping file named feedthroughs.txt that contains
the feedthrough configuration for the current design.
icc_shell> set_fp_pin_constraints -allow_feedthroughs on \
-read_feedthrough_map on -feedthrough_map_file feedthroughs.txt
When you run the preceding command, the place_fp_pins command reads the
feedthrough constraints from the file named feedthroughs.txt in the current working
directory.
Reporting Feedthrough Topology

To write out the feedthrough topology for the current design, use the
report_fp_feedthroughs command.
report_fp_feedthroughs
[-block_type {soft_macros plan_groups voltage_areas}]
[-connectivity_detail_file file_name]
[-feedthrough_map_file file_name]
[-output_feedthroughs {nets ports}]
[-preview_feedthroughs]
[-write_connectivity_detail]
[-write_feedthrough_map {blocks side offset layers}]

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The following example writes feedthrough mapping information containing block, side, offset
and layer constraints for plan groups and soft macros to the ftoutput.txt file.
icc_shell> report_fp_feedthroughs \
-write_feedthrough_map {blocks side offset layer} \
-block_type {plan_groups soft_macros} \
-feedthrough_map_file ftoutput.txt
To generate a table that lists the connectivity details for each feedthrough, use the
report_fp_feedthroughs -write_connectivity_detail -block_type block_type
command. By default, the command writes out a file named connectivityDetailOut. You can
specify the name of the output file by using the -connectivity_detail_file option. The
specified file lists the feedthrough driver, feedthrough load, feedthrough path, and number of
logical and physical connections for each feedthrough. The following
report_fp_feedthroughs command writes out the feedthrough connectivity details for the
soft macros in the design:
icc_shell> report_fp_feedthroughs -block_type soft_macros \
-write_connectivity_detail \
-connectivity_detail_file connectivity.txt
icc_shell> sh cat connectivity.txt
NAME NODE(LOG) DRIVER LOAD(s) CATEGORY NODE(PHYS) PATH
Clk 2 Dp Alu CUT 2 Dp>Alu
PSW[0] 1 Dp Alu,Alu CUT 2 Dp>Alu
PSW[2] 1 Dp Alu CUT 2 Dp>Alu
n939 2 Alu Dp CUT 2 Alu>Dp
Alu_Carry 2 Alu Dp CUT 2 Alu>Dp
Alu_Neg 2 Alu Dp CUT 2 Alu>Dp
Oprnd_A[2] 2 Dp Alu CUT 2 Dp>Alu
Oprnd_A[1] 2 Dp Alu CUT 2 Dp>Alu
Oprnd_A[13] 2 Dp Alu FEEDTHRU 2 Dp>Alu
Oprnd_B[5] 2 Dp Alu CUT 2 Dp>Alu
Oprnd_B[14] 2 Dp Alu FEEDTHRU 2 Dp>Alu
Op_Result[15] 2 Alu Dp FEEDTHRU 2 Alu>Dp
Op_Result[5] 2 Alu Dp CUT 2 Alu>Dp
Previewing Feedthrough Pins

You can analyze the routing pattern generated by the plan-group-aware router to review any
updated pin locations after global routing and preview feedthrough pin locations. The global
routing is analyzed with respect to routes crossing the boundaries of the plan groups or
voltage areas. This information can be used to output a list of feedthrough nets on plan
groups or voltage areas.
You can also use the GUI to preview feedthrough pins before you create them. See
“Performing Pin and Feedthrough Analysis” on page 11-21 for more information.

Use the report_fp_feedthroughs -preview_feedthroughs command to create a file

that lists the nets that are pending feedthrough creation. The following example writes the
list of pending feedthroughs for the plan groups in the design to the feedthrough_nets file.
icc_shell> report_fp_feedthroughs -preview_feedthroughs \
-output_feedthroughs nets -block_type plan_groups
icc_shell> sh cat feedthrough_nets

data_internal1_06 mod2
Creating Feedthrough Pins

After defining the feedthrough map for your design with the feedthrough map file, enable the
tool to read the feedthrough map file with the set_fp_pin_constraints
-read_feedthrough_map on command. Route your design with the route_zrt_global
command and insert the feedthrough pins with the place_fp_pins command. The
place_fp_pins command creates feedthroughs on plan groups, soft macros, and voltage
areas. For more information about creating feedthroughs in voltage areas of your design,
see “Adding Feedthrough Pins on Multivoltage Designs” on page 11-23.
To create feedthrough pins on the plan groups or soft macros in your design, use the
place_fp_pins command. In the following example, the place_fp_pins command creates
feedthroughs on the mod2 plan group.
icc_shell> place_fp_pins { mod2 }
Note:
Pin and feedthrough routing is highly dependent on both pin constraints and the quality
of the global routing.
If your design has terminals or I/O cells that overlap plan groups, you must use the
place_fp_pins -include_flip_chip_style_connections command to properly
create feedthroughs for all terminals.
Performing Pin and Feedthrough Analysis

You can use the GUI to examine individual feedthrough nets before and after the tool
creates the feedthrough pins. To preview feedthrough nets, choose Pin Assignment > Pin
and Feedthrough Analysis in the GUI, click the Preview tab and click the Refresh button to
load the list of pending feedthroughs. Click individual net names to highlight the feedthrough
in the layout window. Figure 11-9 shows the GUI highlighting a feedthrough net.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 11-9 Feedthrough Analysis GUI
After feedthrough creation, you can perform the following types of analysis on the pins in
your design.
• Explore top-level nets and nets that cross between plan groups or soft macros. Click the
“Explore” tab in the GUI to access this function.
• Perform detour analysis and rank nets by detour severity. Click the “Detour” tab in the
GUI to access this function.
• Check pin alignment on soft macro pins. Click the “Pin Alignment” tab in the GUI to
access this function.
• Perform pin assignment checks and view the results in the layout. Click the “Pin
Assignment” tab in the GUI to access this function.
Removing Feedthrough Ports, Nets, and Buffering

Use the remove_fp_feedthroughs command to remove feedthroughs from your design.
remove_fp_feedthroughs
[-blocks blocks]
[-include {buffered original}]
[-nets nets]
[-voltage_areas voltage_areas]

You can remove the feedthrough ports and nets that exist in your design, including those
created by other tools, from all soft macros, plan groups, and voltage areas. You can also
remove feedthrough ports, nets, and buffers by net name or block name.
For pure feedthroughs, the tool removes all ports and the child-level net. For regular
feedthroughs, one port remains as well as the child-level net.
When the tool removes a feedthrough port, the tool also deletes all the pins of that port. The
tool reconnects the nets for which feedthroughs are removed at the parent level of the logic
hierarchy.
Adding Feedthrough Pins on Multivoltage Designs

Multivoltage designs require special consideration when inserting feedthroughs. The
following sections describe the commands needed to create feedthroughs on plan groups
and voltage areas. The commands and flow depend on whether the voltage area coincides
with a plan group.
Setting Voltage Area Feedthrough Constraints

You can set voltage area feedthrough constraints by using the
set_fp_voltage_area_constraints command.
set_fp_voltage_area_constraints
[-allow_feedthroughs true | false]
[-create_feedthrough_module true | false]
[-exclude_feedthroughs nets]
[voltage_areas]
The voltage area constraints set by using the set_fp_voltage_area_constraints

command are saved in the Milkyway database.
Creating Voltage Area Feedthroughs

The create_voltage_area_feedthroughs command creates feedthroughs in voltage
areas based on the constraints set by using the set_fp_voltage_area_constraints
command.
create_voltage_area_feedthroughs
[-finalize_feedthroughs]
[-include_flip_chip_style_connections]
[-minimum_feedthrough_length route_length]
[-output_feedthroughs {nets ports}]
[-preview_feedthroughs]

Adding Feedthrough Pins on Multivoltage Designs 11-23
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The command uses the routing information from the global router to insert feedthroughs at
the points where a net crosses the voltage area boundary.
Note:
If your design has terminals or I/O cells that overlap voltage areas, you must use the
create_voltage_area_feedthroughs -include_flip_chip_style_connections
command to properly create feedthroughs for all terminals.
Creating Feedthroughs Only on Voltage Areas

To create feedthroughs only on voltage areas, enable feedthrough creation by specifying
the set_fp_pin_constraints -allow_feedthroughs on command. Perform
exploration-mode global routing by specifying the route_zrt_global -exploration true
command. Add the feedthroughs to the voltage areas by running the
create_voltage_area_feedthroughs command with the -finalize_feedthroughs,
-preview_feedthroughs, or -output_feedthroughs option.
icc_shell> set_fp_pin_constraints -allow_feedthroughs on
icc_shell> create_voltage_area_feedthroughs -finalize_feedthroughs
Creating Feedthroughs on Voltage Areas Coincident with Plan

Groups
To create feedthroughs on voltage areas that are coincident with plan groups, enable
feedthrough creation by specifying the set_fp_pin_constraints -allow_feedthroughs
on command. To place the plan group pins and create the feedthroughs, specify the
place_fp_pins -effort high command.
icc_shell> place_fp_pins -effort high
Creating Feedthroughs on Voltage Areas Not Coincident with Plan

Groups
To create feedthroughs on voltage areas that are not coincident with plan groups, you must
enable feedthroughs on both plan groups and voltage areas. Enable feedthrough creation
on plan groups by specifying the set_fp_pin_constraints -allow_feedthroughs on
command. Enable feedthrough creation on voltage areas by specifying the
set_fp_voltage_area_constraints -allow_feedthroughs true command. To place
the plan group pins and create the feedthroughs, specify the place_fp_pins -effort
high command.

Adding Feedthrough Pins on Multivoltage Designs 11-24
You can specify the -include_flip_chip_style_connections and

-retain_bus_naming options together with the -create_voltage_area_feedthroughs
option to the place_fp_pins command. The -include_flip_chip_style_connections
and -retain_bus_naming options are honored during feedthrough creation in voltage
areas.
icc_shell> set_fp_voltage_area_constraints \
-allow_feedthroughs true
icc_shell> place_fp_pins -effort high \
-create_voltage_area_feedthroughs [get_plan_groups]
Reporting Voltage Area Constraints

Use the report_fp_voltage_area_constraints command to display the options used to
control feedthrough creation on the voltage areas in your design. The following example
reports the existing voltage area feedthrough constraints for the current design.
icc_shell> report_fp_voltage_area_constraints
Voltage Area Feedthroughs
------------ ------------
va1 Allowed
DEFAULT_VA Not Allowed
Removing Voltage Area Constraints

Use the remove_fp_voltage_area_constraints command to reset the feedthrough
constraints for the specified voltage areas to their default values.
Performing Pin Placement With Multiply Instantiated Modules

The pin placement flow supports designs with multiply instantiated modules. The following
sections describe the special considerations for pin placement with multiply instantiated
modules. For information about determining which modules in your design are multiply
instantiated modules, see “Identifying Multiply Instantiated Modules” on page 6-65.
Setting Pin Assignment Constraints for Multiply

Instantiated Modules
Use the set_fp_pin_constraints command or choose Pin Assignment > Pin Constraints
in the GUI to apply pin constraints to multiply instantiated modules. For more information,
see “Specifying Global Pin Assignment Constraints” on page 11-2. The same pin
assignment constraints used in the pin placement flow are assigned on all instances of a

Performing Pin Placement With Multiply Instantiated Modules 11-25
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
multiply instantiated module set to avoid conflicts and potential problems during
plan-group-aware routing, and pin placement during commit hierarchy. If an instance of a
multiply instantiated module set has different pin assignment constraint settings, a warning
message is issued during the set_fp_pin_constraints step.
Note:
No feedthroughs are allowed for multiply instantiated modules.
Performing Plan-Group-Aware Routing for Multiply

Instantiated Modules
The plan-group-aware router performs global routing for multiply instantiated modules. (See
“Previewing Feedthrough Pins” on page 11-20.) You can analyze the results for each plan
group based on wire length, timing, and congestion reports. Based on this analysis, you
should be able to determine which instance to use as the master instance for the multiply
instantiated module.
The plan-group-aware router automatically turns off feedthroughs on multiply instantiated
modules.
Note:
If any multiply instantiated or unique modules are instantiated as CEL views in the design
and pin assignment has not been performed on them, the plan-group-aware router
issues an error message.
Selecting a Master Instance

Before committing a multiply instantiated module instance, you must first choose a master
instance by using the select_mim_master_instance command. The command
designates an instance as the “master” instance among a set of multiply instantiated
modules. All instances of the multiply instantiated module use the same specified master
instance. The master instance information is saved as a plan group property in the Milkyway
database.
The following command selects the block1 instance as the master instance.
icc_shell> select_mim_master_instance [get_cells {block1}]
Note:
If you do not select a master instance before committing the hierarchy, the
commit_fp_plan_groups command issues a warning and randomly chooses the first
multiply instantiated module instance as the master instance.

Performing Pin Placement With Multiply Instantiated Modules 11-26
Committing a Master Multiply Instantiated Module Plan Group

The commit_fp_plan_groups command converts plan groups to soft macros. Plan groups
for multiply instantiated module instances are also converted by this command. The master
instance plan group is converted to a soft macro, and the instances from the same multiply
instantiated module are converted to instances of the master soft macro.
Pin placement occurs during commit hierarchy for multiply instantiated module instances
based on the pin locations determined by the place_fp_pins command for the chosen
master instance and the plan-group-aware routing results. Pin placement supports multiply
instantiated module instances mirrored along both the x- and y-axes.
Using Pin Guides for Pin Placement

Pin guides create a boundary for pin placement. After you create a pin guide, pins for the
specified blocks can only be placed within the pin guide.
Creating Pin Guides

You can create rectangular or rectilinear pin guide shapes by using the create_pin_guide
command.
create_pin_guide
-bbox bounding_box_rect |
-boundary rectilinear_boundary
[-exclusive]
[-name pin_guide_name]
[-parents soft_macro_or_plan_group]
objects
You can create pin guides on soft macros, plan groups, or the current top-level cell to control
the placement of pins or ports on soft macros or plan groups. The tool creates pin guides
based on net names or pins names. The place_fp_pins command determines the best
location for the pins constrained by the pin guide.
Note:
Pin guides must intersect the module boundary in one contiguous area. Multiple
intersections imply that you want a feedthrough on the net. If there are two or more
external connections for the net, it is interpreted as a “real” feedthrough, that is, one of
the ports is the original port on the block, and the other is the new port.
The routing for the nets that have ports associated with the pin guides is constrained to
cross the corresponding soft macro or plan group boundaries through the interior of the pin
guide. As a result, pin assignment honors the pin guide regions and places pins within the
corresponding plan group or soft macro edge segment. If the pin guide overlaps more than

Using Pin Guides for Pin Placement 11-27
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
one edge of the soft macro, the router can choose to go through any edge segment that
overlaps that pin guide.
The pin guide is a polygon associated with a group of ports or pins and the overlapping plan
group or soft macro. Only one pin guide can be associated with any given pin on a soft
macro or plan group. If the pin guide does not overlap any soft macro or plan group, or if it
does not have any ports associated with it, it is disregarded during routing and pin
assignment.
The following command creates a rectilinear pin guide that constrains the pins connected to
the nets “data_internal*”. The pin guide intersects three plan groups: mod1, mod2, and
mod3. The coordinates {260 250} {292 250} {292 300} {390 300} {390 355} {260 355} and
{260 250} outline the pin guide.
icc_shell> create_pin_guide -name {pg1} \
-boundary {{260 250} {292 250} {292 300} {390 300} {390 355} \
{260 355} {260 250}} -parents {mod1 mod2 mod3} \
[get_nets data_internal*]
Figure 11-10 shows the design with pins placed by using a pin guide created by the previous
create_pin_guide command. The pin guide rectilinear region is highlighted.
Figure 11-10 Pin Placement With a Pin Guide

Using Pin Guides for Block-Level Off-Edge Pin Placement

You can restrict the placement of top-level pins in your design by using the
create_pin_guide and place_fp_pins -block_level commands. Pin placement is
restricted to the boundary of the pin guide you define. You can use the pin guide to create a
region for off-edge pins; the tool places pins on the wire track. Figure 11-11 shows an
example of an off-edge pin.
Figure 11-11 Region Constraints on Off-Edge Pins
Pins placed inside the pin guide

on the wire track
You can use the set_fp_pin_constraints -allowed_layers layers command to
restrict off-edge pin placement to a specified set of metal layers. The layers argument is a
collection of metal layers ordered consecutively.
Creating Pin Guides for Feedthroughs

You can specify the locations of feedthroughs on a soft macro or plan group by creating pin
guides for the feedthroughs.
Note:
The feedthrough guide controls only where the pins are placed on the block boundaries.
It does not control the routing inside the block.
If a pin guide shape passes through a soft macro or plan group, and if the feedthrough net
does not already touch the soft macro or plan group, a “pure” feedthrough is created. A
“pure” feedthrough has no internal connections with the block it passes through. Conversely,
if the feedthrough net has one or more cell instances within the block (soft macro or plan
group) that the net is connected to, one side of the feedthrough is counted as the original

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
port and the other side is a “regular” (connected) feedthrough. To ensure that the
connectivity of the feedthrough is clear, the pin guide shape should touch the port, plan
group, or soft macro that is connected to the net.
To generate feedthroughs that honor pin guides,
• Enable feedthrough creation by running the set_fp_pin_constraints
-allow_feedthroughs on command.
• Add the feedthrough block to the list of parent objects by specifying the
create_pin_guide -parents object command when creating the pin guide.
Feedthrough guides must meet the following criteria:

• A feedthrough pin guide on a block must have at least two connections on the net outside
the block. If it does not, the feedthrough pin guide is ignored and a warning message is
issued.
• A feedthrough pin guide must intersect the block boundary in at least two disjoint areas.
The IC Compiler tool supports the rectilinear feedthrough guide shapes shown in
Figure 11-12.
Figure 11-12 Rectilinear Feedthrough Pin Guide Shapes

Reporting Pin Guide Settings

You can report the current pin guide settings by using the report_pin_guides command.
Specify the -pins option to get detailed information about pin guides associated with
specified pins or specify the -nets option to get detailed information about pin guides
associated with specified nets.
Checking for Off-Edge Pin Placement

You can ensure that all pins are on an edge by using the
check_fp_pin_assignment -off_edge command. You can check for pins that are not
inside the associated pin guide by using the
check_fp_pin_assignment -outside_pin_guide command. You can check that pins on
macros are placed on wire tracks by using the check_fp_pin_assignment -block_level
-wiretrack command.
Checking Pin Assignment and Pin Alignment

You can analyze and evaluate the quality of the pin placement results by checking the
placement and alignment of soft macros and plan group pins in the design. You can refine
the pin assignment based on the results.
Checking the Pin Assignment

You can check or verify the placement of soft macro or plan group pins in a design by using
the check_fp_pin_assignment command.
check_fp_pin_assignment
[-block_level [-net_routing_constraints]]
[-layers]
[-macro_type soft_macros | hard_macros | all]
[-match_pin_shapes]
[-missing]
[-nets net_collection]
[-no_stacking]
[-off_edge]
[-outside_pin_guide]
[-pin_preroute_spacing]
[-pin_spacing]
[-pin_type signal_pins | pg_pins | all]
[-shorts]
[-single_pin connected | unconnected | all]
[-wiretrack [-preferred_wiretrack_only] [-allow_half_wiretrack]]
[objects]

Checking Pin Assignment and Pin Alignment 11-31
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The following example checks the pin assignment in the current design for pin spacing
violations by using the check_fp_pin_assignment -pin_spacing command.
icc_shell> check_fp_pin_assignment -pin_spacing
******************************************************************
Report: check_fp_pin_assignment
Design: top
Version: E-2010.12
Date: Tue Oct 5 16:34:29 2010
******************************************************************
-------------- Start Of Pin Spacing Checks -------------
Error: Pin to pin spacing constraints violated in soft macro "mod2":
1:pin "dataout_02" connected to net "data_internal2_02"
BBOX: (351.0500 251.7500) (351.1500 251.8500)
2:pin "dataout_01" connected to net "data_internal2_01"
BBOX: (351.1000 251.7500) (351.2000 251.8500)
-------------- End Of Pin Spacing Checks -------------
{mod2/dataout_01 mod2/dataout_02}
Checking the Pin Alignment

You can check the pin alignment in your design by using the check_fp_pin_alignment
command.
check_fp_pin_alignment
[-detour]
[-nets net_names]
[-report_nets]
[-tolerance value]
You can view a list of nets with pins that are not optimally aligned by pin assignment. The
list displays the total number of two-connection nets among the specified nets that have at
least one of their two connections inside a soft macro. The command also reports the
number and percentage of misaligned nets among the two-connection nets.
The following example lists pins in the design that have a detour tolerance greater than 10
percent. The following pin detour report displays the nets where the bounding box of the
standard cell macro pins on the net is smaller than the bounding box of all standard cells and
soft macros on the net.

icc_shell> check_fp_pin_alignment -report_nets -detour -tolerance 10

******************************************************************
Report: check_fp_pin_alignment detour check
Design: test
Version: F-2011.09
Date: Thu Jun 30 17:44:11 2011
******************************************************************
3 pin detours.
/******* Nets with pin detour, tolerance = 0.100000 ***************
data_internal1_09
data_internal1_02
data_internal1_07
*******************************************************************

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

12
Performing Timing Budgeting 12
During the design planning stage, timing budgeting is an important step in achieving timing
closure in a physically hierarchical design. The timing budgeting determines the
corresponding timing boundary constraints for each top-level soft macro or plan group
(block) in a design. If the timing boundary constraints for each block are met when they are
implemented, the top-level timing constraints are satisfied.
Timing budgeting distributes positive and negative slack between blocks and then
generates timing constraints in the Synopsys Design Constraints (SDC) format for
block-level implementation.
Timing budgeting distributes the timing constraints from the top level to the block level,
creating a new constraint set for each of the top-level blocks in the design. Budgeting also
allocates slack between blocks for timing paths crossing the block boundaries. Timing
budgeting propagates the timing constraints downward one hierarchical level at a time.
Timing budgeting also propagates timing exceptions to block-level constraint sets.
You can use the timing budgeting feature in virtual flat mode to generate constraints for plan
groups.
During timing budgeting, you can also create quick timing models for soft macros and plan
groups and load them into your design.
• Timing Budgeting Prerequisites
• Performing Pre-Budget Timing Analysis
12-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• Running the Timing Budgeter

• Generating a Quick Timing Model for the Partitions of Large Designs
• Quick Timing Model Command Summary
• Performing Timing Budgeting On Plan Groups
• Budgeting With Multiply Instantiated Modules
• Performing Budgeting on Multiple Scenarios
• Performing Distributed Timing Budgeting for Multiple Scenarios
• Performing Hierarchical Signal Integrity Budgeting
• Performing Post-Budget Timing Analysis
• Performing Clock Latency Budgeting
Chapter 12: Performing Timing Budgeting

12-2
Timing Budgeting Prerequisites

Before a cell can be budgeted, it has to meet the following requirements:
• It must be floorplanned with all cells legally placed. The closer the floorplan is to the final
layout, the better the budgeting results.
Note:
A globally routed design, while not required, results in budgets that are more
accurate.
• The top-level timing constraints must be loaded.
• The timing information available must be sufficient to successfully execute the timing
analyzer on the cell to be budgeted. This requires complete timing views for all top-level
soft and hard macros.
You can run budgeting on a design that does not have timing models for all soft macros.
If a soft macro does not have a timing model, the paths that interface with that macro are
automatically marked as false paths.
• Run a timing report on your top-level design before performing timing budgeting. If
design errors are reported during the timing report, budgeting cannot be run successfully.
• Timing paths should have reasonably small slack values.
Budgeting is effective only when your design is close to meeting timing. It would be very
difficult to meet timing if, for example, the worst negative slack was 10 nanoseconds and
the clock period was also 10 nanoseconds. Timing is considered reasonable, however,
if the worst negative slack is 10 percent or less but no more than 20 percent of the clock
period. If it is more than 20 percent of the clock period, you should carefully review the
results of the path timing report to determine the cause of the timing violations.
The most common cause of incomplete or missing constraints in the output timing
boundary files is that no timing path passes through the port for which constraints are
either incomplete or missing. This might be intended if false path specifications are
loaded. However, it might be caused unintentionally, for example, by incomplete or
incorrect timing views or by dangling nets.
Performing Pre-Budget Timing Analysis

You can perform pre-budget timing analysis on your design. The timing analysis is applied
to blocks (plan group or soft macro) or the top-level design. Pre-budgeting timing analysis
allows you to handle early checking of the timing rules and constraints set in the Synopsys
Design Constraints (SDC) file before your design is submitted to the budgeting process.

Timing Budgeting Prerequisites 12-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
By providing feedback on design and timing information, the timing checking analysis tool
can help you determine the feasibility of your design and its timing constraints.
You can generate a report file that contains additional design information for validating the
budgets assigned to each block in your design. You can use this report to analyze why
certain budgets are assigned to each block port and to debug the budgets generated by the
IC Compiler design planning timing budgeter.
The design information in the report file includes, but is not limited to, clocks in the design,
timing constraints in the design, timing exceptions in the design, delay distribution on the
worst timing path through the block ports, pins tied high or low, high negative slack on the
timing path, and so on.
To generate a pre-budgeting timing analysis report file,
1. Choose Timing > Floorplan Timing Environment Check.
The Timing Environment Analysis Options dialog box appears.
Alternatively, you can use the check_fp_timing_environment command.
2. Select the Budgeting Analysis tab. This is the default.
3. Enter the hierarchical cell name or plan group name and the pin names on which to apply
the budgeting analysis.
4. Select the options to use for performing budgeting analysis. The options you specify
determine the type of information that is written to the output report file.
5. Show reports on one or more of the following:
❍ Block pin statistics – For each block, prints the number of hierarchical pins that can
and cannot be budgeted and the total number of pins on the block. A hierarchical pin
is budgeted if timing constraints or exceptions are propagated to it. The default is on.
❍ Unbudgetable pins – Reports why pins cannot be budgeted. The default is on. A
hierarchical pin might not be budgeted for the following reasons:
The pin is not connected to a net.
The pin is not connected to a top-level net, but is connected to an internal net.
The pin is not connected to an internal net, but is connected to a top-level net.
Only fixed delay exists on one side of the pin. (There is nothing to budget, although
there is an input or output delay constraint on these pins.)
Timing paths through pins are not constrained.
The pin is constrained by a user-defined budget.

Performing Pre-Budget Timing Analysis 12-4
The pin is connected to a power or ground net, or it has a set_case_analysis

constraint on it.
The pin is either an input or output clock port.
❍ Unconstrained pins – For each block to be budgeted, lists the pin names that are not
constrained. A pin is unconstrained if no timing path goes through it. The default is on.
❍ Exception pins – For each block to be budgeted, lists the pin names that have timing
exceptions propagated to it. The exceptions are set_false_path,
set_multicycle_path, set_min_delay, or set_max_delay. The default is on.
❍ Static logic pins – For each block to be budgeted, lists the pins that are set to a static
logic state as a result of a case analysis statement. It reports if a block pin is tied high
(1) or low (0) by a power or ground net in the logical netlist. It also reports if a block
pin is set to a specific state by set_case_analysis, set_logic_one, or
set_logic_zero constraints. The default is on.
❍ Number of pin connections – Reports the number of pin connections from the
startpoint and the endpoint of the timing paths going through one block to other
blocks, through top-level standard cells, through pad cells, through top-level ports,
and through ports on the plan group.
Enter the number of pin connections to display for each type of net connection. The
default is 1.
❍ Delay violating cells – Lists the top-level cells of interface paths that have cell delays
greater than the specified percentage of the captured clock period. It traverses all the
critical paths per clock domain through the block pin.
The percent argument is required and must be greater than or equal to zero.
❍ Report to file – Prints the report to an output file in a single-line format. Enter the
name of the output file. The default is off.
❍ Output in table format – Formats the report in a table. If the report is in a table, it is
easier to read, but it might be difficult to parse using automated scripts. The default is
off.
6. Select the Timer and Bottleneck Analysis tab to generate timing and bottleneck reports.
You can show timing and bottleneck reports on:
❍ Zero wire delay – Performs zero wire delay analysis and reports the negative-slack
paths that have slack less than the negative percentage of the captured clock period.
This enables timing analysis in a special mode in which the wire delays are set to
zero. The default is off.
Specify a slack limit. The slack limit is the threshold percentage of the end clock
period for each negative-slack path. A timing path is printed in the output report file if
its slack is less than the negative percentage of the path’s captured clock period.

Performing Pre-Budget Timing Analysis 12-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
❍ Virtual IPO – Reports timing analysis results based on virtual in-place optimization.
The default timing report from this option uses a slack threshold of zero. The default
is off.
Specify a slack limit for the timing paths in the virtual in-place optimization timing
report. Only paths that have slack less than the slack percentage of the capture clock
period are reported.
❍ Bottleneck cells – Reports bottleneck cells. It lists the cells in the design that
contribute to multiple timing violations. It lists the leaf cell, its reference, and the
number of paths through the leaf cell that have timing violations. Based on this report,
you can check the fanin and fanout logic to determine the possible cause of the timing
bottleneck. The default is off.
❍ Run Virtual IPO – Disable this option if you do not want virtual in-place optimization
to run before reporting bottleneck cells. The default is to run virtual in-place
optimization.
❍ Slack limit – You can specify the slack limit for reporting bottleneck cells only. Only
timing paths having slack less than the slack limit are explored to locate bottleneck
cells. The default is 0.
❍ Maximum number of cells – You can specify the maximum number of bottleneck cells
to report. This allows you to limit the number of bottleneck cells reported for a design.
The default is 20.
❍ Maximum number of paths – You can optionally specify a maximum number of paths
to report.
7. Click OK.
The following information is printed in the report file for the whole design:
• Negative-slack paths based on zero wire delay
• Bottleneck cells
• Timing report based on virtual in-place optimization
The remainder of the report is divided by soft macro or plan group. All the timing
environment information related to one soft macro or plan group is printed together.
Running the Timing Budgeter

You can run the timing budgeter to perform proportional timing budgeting (the default) or
advanced timing budgeting based on virtual in-place optimization for plan groups or soft
macros in the design.

Running the Timing Budgeter 12-6
Proportional budgeting allocates positive and negative slack based on the actual physical
circuits in each path. It also allocates slack on the path based on the delay on the path
portions within individual blocks. Timing budgets are distributed proportionally to the worst
or best case delay that is actually present for each path (per clock domain) inside the
top-level soft macros. Portions of interface paths which are hierarchically in the top level are
considered fixed delays just as hard macros are considered as fixed delays. This means that
all slack for interface paths is budgeted solely to blocks.
After slack is allocated between blocks, the design is processed to generate a timing
constraints file in the Synopsys Design Constraints (SDC) format for each block that has a
timing model.
To run the timing budgeter,
1. Choose Timing > Allocate Budgets.
The Allocate Budgets dialog box appears.
Alternatively, you can use the allocate_fp_budgets command.
❍ Hierarchical cells – Select this option to specify a list of hierarchical cell names for
budgeting. By default, all plan groups and soft macros in the current design are
budgeted.
❍ Black box cells – Select this option if you want a list of black box cells to be budgeted
with black box timing models. The default is off.
Enter the names of the black box cells in the text box. Black box cells are not
budgeted unless they are included in this text box. Black box cells that have timing
models and are omitted from the text box are treated as hard macros.
❍ Fixed delay objects – Select this option to specify that certain objects that are
implemented have fixed delays that will not change in subsequent optimizations. The
list of objects includes plan groups, soft macro cells, hard macro cells, black boxes,
hierarchical cells for plan groups, pins of soft macros with hierarchical models, and
pins of hierarchical cells for plan groups.
The delay allocated to the timing paths passing through these pins during budgeting
is equal to the current delay.
Select the Plan groups option if you want a list of cells to be treated as hard macros
for budgeting purposes. The tool skips slack allocation for cells designated as fixed
delay cells. Timing budget that is usually distributed to the fixed delay cell is
distributed to other soft macros on the same timing path. The default is off.
❍ Output file name format specification – Enter the directory and naming style for the
output SDC constraints file. The syntax of the string specifies the directory to write the
SDC files and the type of names to output. If you specify outputdir/i.sdc, the IC

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Compiler tool writes instance names. The string outputdir/m.sdc requests the tool to
write reference names. One consolidated SDC file is written for designs that contain
multiply instantiated modules. See the man page for more information.
❍ Interblock logic – Select this option to fix top-level timing budget values during
budgeting. If you deselect this option, the tool performs proportional timing budgeting
at the top level as well as plan groups and soft macros.
❍ Exploration mode – Select this option to perform budgeting in exploration mode. See
“Performing Fast Time to Budget Analysis” on page 12-10 for more information about
this option. The default is off and the tool performs budgeting in the normal
floorplanning flow.
❍ Incremental budgeting – Select this option to perform budgeting in incremental mode.
During incremental budgeting, the timing budgeter retrieves block implementation
information from designs with hierarchical models and budgets the delays using this
information. The block-level slack of the worst timing paths through the block pins is
considered. The tool tightens budgets for pins associated with positive slack
numbers, and relaxes budgets for pins with negative slack numbers.
Note:
Use this option only on designs with interface logic models that were created with
the create_block_abstraction command. Designs that contain interface logic
models commands contain information about the block-level slack of the worst
path through the hierarchical pins. If the design contains plan groups or if the
block abstractions in the design do not have pins with negative slack information,
incremental budgeting issues an error message and stops.
❍ Split long lines – Select this option if you want the tool to split long SDC command
lines in the budget file by breaking the line and inserting the Tcl continuation
character (\) at the end of the line. The default is on.
❍ Write constraints for partial netlists – The allocate_fp_budgets command does not
create partial constraint files by default. Specify the -print_partial_constraints
option to generate partial constraint files for blocks with a partial netlist. Partial
netlists are commonly used in the on-demand-loading flow, the trace mode flow, and
the hierarchical flow using ILMs or block abstraction models. The partial constraint file
for blocks with a partial netlist is incomplete and contains only constraints for the
portion of the block netlist at the top level.
❍ Enable QTM model generation – Select this option to enable quick timing model
generation for the budgeted plan groups or soft macros. (This option is equivalent to
the create_qtm_model command.) The delay arcs and the constraint arcs that are
created in the quick timing models represent the budgets on the plan groups or soft
macros.
You can load the quick timing models for the soft macros or plan groups after they are
committed to soft macros. You can also generate a top-level timing report to check

the QoR of your budgets and identify potential problems before running optimization
on the individual blocks.
❍ Output QTM directory – Enter the name of the directory into which the quick timing
model files are written after the timing budgeting is finished. The default is the current
directory.
Setting Block-Level Timing Budgets

You can fine-tune the timing budget available for blocks by specifying the
set_budgeted_delay or set_minimum_budgeted_delay commands. Use the
set_budgeted_delay command to allocate an exact budget to a segment of a timing path
in a block. The set_minimum_budgeted_delay command allocates a minimum timing
budget to each specified block.
To validate your block-level timing adjustments, use the report_user_budgeted_delays
command. The command reports all timing budget values previously specified with the
set_minimum_budgeted_delay and set_budgeted_delay commands. To remove the
block-level timing adjustments, use the remove_user_budgeted_delays command.
The following example sets a budget of 0.5 library file units for the I_ORCA_TOP/
I_BLENDER_2 block and verifies the budget by using the report_user_budgeted_delays
command.
icc_shell> set_minimum_budgeted_delay \
-blocks I_ORCA_TOP/I_BLENDER_2 -delay 0.5
1
icc_shell> report_user_budgeted_delays
****************************************
Report : User budgets
Design : ORCA
Version: G-2012.06-ICC-SP4
Date : Tue Nov 13 11:52:43 2012
****************************************
---------------------------
Minimum budgets for blocks
---------------------------
Block Budget
----------------------------------------
I_ORCA_TOP/I_BLENDER_2 0.500 units
...

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Performing Fast Time to Budget Analysis

You can perform timing budgeting on an early design version using the -exploration
option to the allocate_fp_budgets command. Using this option, allocate_fp_budgets
adjusts input and output delay and load values for block constraints. This option eliminates
the need for an optimized netlist as a prerequisite for timing budget exploration.
Figure 12-1 shows a typical design planning flow for timing budget exploration.
Figure 12-1 Timing Budget Exploration Flow
Initial Placement
Create Plan Groups
Hierarchical Placement
Automatic High Fanout Synthesis
Plan-Group-Aware Routing
Finalize Routing
Feedthrough Buffering Only
allocate_fp_budgets -exploration
Commit
Checking the QoR of the Timing Budgets

After you have loaded the quick timing models into your design, you can check the QoR of
the timing budgets before running optimization for each individual block by using the
report_timing command to create a top-level timing report to see if there are any paths
with negative slack.
If the current budgets are either overconstrained or underconstrained, the timing report
shows such paths as negative or positive slack. To check the results for any negative slack

paths in the timing report, run a timing report for that path on a saved design with ILM or
block abstraction models.
Zero slack budgeted paths are reported in the timing report with a slack of zero. Because the
quick timing represents the timing of the blocks if they met the generated SDC budgets, the
top-level timing should converge to a slack of zero.
Generating a Quick Timing Model for the Partitions of Large

Designs
Large designs that might not fit as flat designs in the tool are automatically partitioned and
floorplanned. You can create a quick timing model for the partitions of large designs. The
input to the quick timing model that is generated is the CEL view of the partition. The quick
timing model, along with the top-level design, should fit in a design that is floorplanned in the
IC Compiler tool. The quick timing model timing generation for all CEL view partitions can
occur in parallel.
The generated quick timing model output for the partitions of large designs have the
following:
• Interface ports of the output quick timing model
The interface ports of the output quick timing model are based on the ports of the original
CEL view. The direction of the quick timing model ports is the same as the direction of
the ports in the Milkyway design.
• Sequential delay arcs (clock to output delay arcs)
If the worst slack path through the output port does not start at the input port of the
design, a sequential delay arc is created at the output port.
• Combinational delay arcs (input to output delay arcs)
If the worst slack path through the output port starts at the input port of the design, a
combinational delay arc is created.
• Setup and hold arcs (clock to input constraint arcs)
The worst slack paths for maximum and minimum delay mode are used to create setup
and hold arcs.
• Load information about input pins and drive information about output pins
The load value on the input port is the sum of all the pin and wire capacitances that are
connected to the input port. The driving cell of the output port is the cell that directly
drives the net connected to the output port.

Generating a Quick Timing Model for the Partitions of Large Designs 12-11
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Quick Timing Model Command Summary

Table 12-1 summarizes the commands in the quick timing model flow.
Table 12-1 IC Compiler Quick Timing Model Command Summary
To do this action Use this command
Begin defining a quick timing model create_qtm_model
Create a constraint arc create_qtm_constraint_arc
Create a delay arc for a quick timing model create_qtm_delay_arc
Create a drive type for a quick timing model create_qtm_drive_type

description
Create a generated clock for the model create_qtm_generated_clock
Create a load type for a quick timing model create_qtm_load_type

description
Create a path type in the quick timing model create_qtm_path_type
Create a quick timing model port create_qtm_port
Report model data report_qtm_model
Save the quick timing model save_qtm_model
Set a global parameter set_qtm_global_parameter
Set drive on a port set_qtm_port_drive
Set load on ports set_qtm_port_load
Set various technology parameters set_qtm_technology
Performing Timing Budgeting On Plan Groups

If you have a design with plan groups, the top-level design contains the complete design
netlist. The allocate_fp_budgets command generates the SDC constraints and attributes
for each individual plan group. These constraints and attributes are transferred to the
individual soft macro blocks when the hierarchy is committed. See “Converting Plan Groups
to Soft Macros” in Chapter 13.

Quick Timing Model Command Summary 12-12
Note:
The automatic transfer of budgeted timing SDC constraints and attributes works on
designs with single or multiple scenarios.
Timing budgeting on plan groups runs with full-chip timing. It honors the pin locations and
the feedthrough nets assigned to the plan groups.
Figure 12-2 shows the flow for performing timing budgeting on plan groups.
Figure 12-2 Performing Timing Budgeting on Plan Groups
Top-level design with plan groups
Timing budgeting
Commit hierarchy
Open individual soft macro
Link to load attributes and constraints
Note:
After committing the hierarchy using the commit_fp_plan_groups command, the
created soft macros do not have timing models. At this point, you might encounter a few
warning messages. These messages do not affect any physical design operations, such
as refining the pin assignment.
If you want to perform an early timing check at the top level after you commit the hierarchy,
do the following:
1. Save the soft macro CEL views by using the save_mw_cel -hierarchy command.
2. Close the soft macro CEL views by using the close_mw_cel command, which leaves
open only the CEL view for the top-level design.

Performing Timing Budgeting On Plan Groups 12-13
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
3. Generate hierarchical models for the soft macros from the top level by using the
create_block_abstraction command.
4. Run a top-level timing report using the hierarchical models.

This top-level timing report uses virtual-route based timing only, as there is no global
route or parasitic information for the hierarchical models.
Budgeting With Multiply Instantiated Modules

When multiply instantiated modules are present in the design, you must consider how the
constraints are treated for each module. When budgeting according to the master names of
the multiply instantiated modules, you can generate a single SDC constraint file, which
contains a single set of constraints for each individual block of the multiply instantiated
modules. A single SDC constraint file allows you to run a single optimization only one time.
You can also create multiple constraint files, one for each soft macro. Multiple constraint
files are generated if you budget according to instance names.
To generate a single master constraints file, use the allocate_fp_budgets
-file_format_spec output_dir/m.sdc command, which generates one master SDC file
for each set of multiply instantiated modules. To generate a separate constraints file for
each multiply instantiated module, use the allocate_fp_budgets -file_format_spec
output_dir/i.sdc command.
Conflicts might occur when budgeting according to instance names. In this case, the
strictest constraint is used if a conflict occurs.
Figure 12-3 shows a design example containing multiply instantiated modules.
Figure 12-3 Multiply Instantiated Module Design
BlockA BlockB
FF1 FF2
in out in out
D Q D Q
1 3 2 3 1
In this example the clock period is 10 ns and the budgets are allocated along the timing path
as shown in the figure. If BlockA and BlockB are independent, the set of corresponding input
and output constraints for each block are:

Budgeting With Multiply Instantiated Modules 12-14
BlockA:
set_input_delay 1 [get_ports in]
set_output_delay 6 [get_ports out]
BlockB:
If BlockA and BlockB are multiply instantiated modules, the delays cannot be correctly
combined by choosing the strictest value for each constraint. The combination of the delays
would result in the following constraint, which is impossible to meet for timing closure:
Instead, the budget values for the two multiply instantiated blocks are considered and the
delay combination resulting in the strictest budget is kept. For the design example, either of
the following constraint sets produces the correct result:
or
If the connectivity of the blocks gives a different budget for each block, the strictest
budgeting constraint is created. Given this set of constraints:
BlockA:
BlockB:
The constraint defining the strictest budget is kept as shown in the following example.
This approach is used in designs with plan groups and hierarchical models. For
multicorner-multimode designs, constraints for each scenario are resolved independently
for each active scenario.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Table 12-2 shows a list of conventions used when writing constraints to a combined SDC
file.
Table 12-2 Combined SDC File Constraint Guidelines and Examples
Command Description and examples
create_clock Clocks might connect to different pins in different instances. Also

different clocks might connect to the same pin, in different
instances. These conflicts are resolved by creating all the clocks
that connect to a specific pin in any instance on that pin in the
Master. This might result in multiple clock definitions on the same
pin, but the timer can use all of them.
Module1.sdc Module2.sdc Combined.sdc
create_clock -name clk create_clock -name clk create_clock -name clk

[get_ports {clk}] [get_ports {clk}]
create_clock -name clk create_clock -name clk create_clock -name clk

[get_ports {clk1}] [get_ports {clk2}] [get_ports {clk1 clk2}]
create_clock -name clk1 create_clock -name clk2 create_clock -name clk1 -add
[get_ports {clk}] [get_ports {clk}] [get_ports {clk}] create_clock
-name clk2 -add [get_ports
{clk}]
create_clock -name clk create_clock -name clk create_clock -name clk list
[get_ports {clk}] [get_pins {U1/A}] [[get_ports {clk}] [get_pins {U1/
A}]]
create_clock exception_clock Virtual clocks are generated to model exceptions. If an exception

affects one or more of the multiply instantiated modules, the
corresponding virtual clock is created.
create_generated_clock Clocks generated in different instances that have unique names are
treated the same as they are in individual SDC files. If generated
clocks are created with the same name have any conflicting
attributes (options -source, -multiply_by, -divide_by, -invert,
-master_clock), a warning is issued and a clock is selected for
output to the SDC file.

Table 12-2 Combined SDC File Constraint Guidelines and Examples (Continued)
create_generated_clock -name create_generated_clock -name create_generated_clock -name

clk_g1 -source U1/A clk_g2 -source U1/C clk_g1 -source U1/A
-multiply_by 2 U2/B -multiply_by 2 U2/D -multiply_by 2 U2/B
create_generated_clock -name
clk_g2 -source U1/C
-multiply-by 2 U2/D
create_generated_clock -name create_generated_clock -name create_generated_clock -name

clk_g -source U1/A clk_g -source U1/C clk_g -source U1/A
-multiply_by 2 U2/B -multiply_by 2 U2/D -multiply_by 2 U2/B
set_clock_uncertainty The uncertainty set on clocks is valid for the entire design and is the
same for all multiply instantiated modules. If uncertainty is defined
on ports or pins, the worst-case uncertainty value is used in the
merged SDC.
set_clock_uncertainty 0.5 set_clock_uncertainty 0.5 set_clock_uncertainty 0.5

[get_clocks clk] [get_clocks clk] [get_clocks clk]
set_clock_uncertainty 0.5 set_clock_uncertainty 0.6 set_clock_uncertainty 0.6

[get_ports clk1] [get_ports clk1] [get_ports clk1]
set_clock_latency The largest value among all latency values in the different SDC files
for the -max option for the same clock. Similarly, the smallest value
is chosen for the -min option.
set_clock_latency -max 0.2 set_clock_latency -max 0.3 set_clock_latency -max 0.3

[get_clocks {clk}] [get_clocks {clk}] [get_clocks {clk}]
set_clock_latency -min 0.1 set_clock_latency -min 0.2 set_clock_latency -min 0.1

set_clock_transition The same command is written for all multiply instantiated modules
in the combined SDC file.
set_propagated_clock The same command is written for all multiply instantiated modules
in the combined SDC file.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
set_input_delay Two set_input_delay commands are generated in the combined

SDC file if the set_input_delay statement for the same pin refers
to a given clock in one instance and a different clock in another
instance. If the delay values on the same port with respect to the
given clock are different for different instances, the value defining
the strictest budget is selected.
set_input_delay 2.3 -clock set_input_delay 5.8 -clock set_input_delay 2.3 -clock

[get_clocks {clk1}] -max [get_clocks {clk2}] -max [get_clocks {clk1}] -max
[get_ports {in}] [get_ports {in}] [get_ports {in}] set_input_delay
5.8 -add_delay -clock
[get_clocks {clk2}] -max
[get_ports {in}]
set_output_delay Two set_output_delay commands are generated in the

combined SDC file if the set_output_delay statement for the same
pin refers to a given clock in one instance and a different clock in a
another instance. If the delay values on the same port with respect
to the given clock are different for different instances, the value
defining the strictest budget is selected.
set_output_delay 2.3 -clock set_output_delay 5.8 -clock set_output_delay 2.3 -clock

[get_clocks {clk1}] -max [get_clocks {clk2}] -max [get_clocks {clk1}] -max
[get_ports {in}] [get_ports {in}] [get_ports {in}]
set_output_delay 5.8 -clock
[get_clocks {clk2}] -add_delay
-max [get_ports {in}]
set_false_path If the set_false_path exception refers only to clocks, pins or ports

outside the multiply instantiated modules, it is modeled by using
virtual clocks. If some of the pins are inside the multiply instantiated
modules, a one-to-one correspondence is required for all blocks.
Otherwise the set_false_path constraint is dropped from the
combined SDC file.
set_false_path -from set_false_path -from set_false_path -from


set_false_path -from set_false_path -from set_false_path -from

[get_clocks {clk_virtual1}] [get_clocks {clk_virtual2}] [get_clocks {clk_virtual1}]
set_false_path -from
[get_clocks {clk_virtual2}]
set_false_path -from [get_pins set_false_path -from [get_pins set_false_path -from [get_pins

{U1/A}] {U1/A}] {U1/A}]
set_false_path -from [get_pins set_false_path -from [get_pins no output for the exception
{U1/A}] {U2/A}]
set_multicycle_path If the set_multicycle_path exception refers only to clocks, pins,

and ports outside the multiply instantiated modules, it is modeled by
using virtual clocks. If all of the pins are inside multiply instantiated
modules, a set_multicycle_path statement is output in the
combined SDC file if there is a one-to-one correspondence for all
the multiply instantiated modules.
set_multicycle_path -from set_multicycle_path -from set_multicycle_path -from

set_multicycle_path -from set_multicycle_path -from set_multicycle_path -from

[get_clocks {clk_virtual1}] [get_clocks {clk_virtual2}] [get_clocks {clk_virtual1}]
set_multicycle_path -from set_multicycle_path -through set_multicycle_path -through

[get_clocks {clk_virtual2}] [get_pins {U1/A}] [get_pins {U1/A}]
set_multicycle_path -through
[get_pins {U1/A}]
set_multicycle_path -through set_multicycle_path -through No set_multicycle_path

[get_pins {U1/A}] [get_pins {U2/A}] statement.
set_min_delay If the set_min_delay exception refers only to clocks, pins, and

ports outside the multiply instantiated modules, it is modeled by
modules, a set_min_delay statement is output in the combined
SDC file if there is a one-to-one correspondence for all the multiply
instantiated modules.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
set_max_delay If the set_max_delay exception refers only to clocks, pins, and

ports outside the multiply instantiated modules, it is modeled by
modules, a set_max_delay statement is output in the combined
SDC file if there is a one-to-one correspondence for all the multiply
instantiated modules.
set_drive If different set_drive values exist for the same port in different
instances, largest resistance value is used for the -max option. The
smallest resistance value is used for the -min option. The options
-rise and -fall are treated separately.
set_drive 2 -max [get_ports set_drive 3 -max [get_ports set_drive 3 -max [get_ports

{in}] {in}] {in}]
set_drive -min [get_ports {in}] set_drive 3 -min [get_ports {in}] set_drive 2 -min [get_ports {in}]
set_driving_cell The library cell with the largest drive resistance to output is selected
if there are different library cell and pin paths for a given port in
different instances. If the set_driving_cell command for one port
has the same library cell and pin for different instances, but the
input_transition_rise or the input_transition_fall
numbers are different, the largest number for -max and the smallest
number for -min is output.
set_driving_cell -lib_cell INVX2 set_driving_cell -lib_cell INVX4 set_driving_cell -lib_cell INVX2

-pin Z [get_ports {in}] -pin Z [get_ports {in}] -pin Z [get_ports {in}]
set_driving_cell -lib_cell INVX2 set_driving_cell -lib_cell INVX2 set_driving_cell -lib_cell INVX2

-pin Z -input_transition_rise 0.5 -pin Z -input_transition_rise 0.7 -pin Z -input_transition_rise 0.7
-max [get_ports {in}] -max [get_ports {in}] -max [get_ports {in}]
set_input_transition The largest value for -max conditions and the smallest value for
-min conditions are chosen if different input transition numbers
exist for the same port in different instances. The -rise and -fall
options are treated separately.

set_input_transition -max 0.5 set_input_transition -max 0.7 set_input_transition -max 0.7

set_input_transition -min 0.5 set_input_transition -min 0.7 set_input_transition -min 0.5

set_load -pin_load The largest value for -max and the smallest value for -min are
chosen if the set_load -pin_load statements for the same port
on different instances have different values.
set_load -pin_load 10 -max set_load -pin_load 15 -max set_load -pin_load 15 -max

[get_ports {out}] [get_ports {out}] [get_ports {out}]
set_load -pin_load 10 -min set_load -pin_load 15 -min set_load -pin_load 10 -min

set_load -wire_load The largest value for -max and the smallest value for -min are
chosen if the set_load -wire_load statements for the same port
on different instances have different values.
set_load -wire_load 10 -max set_load -wire_load 15 -max set_load -wire_load 15 -max

set_load -wire_load 10 -min set_load -wire_load 15 -min set_load -wire_load 10 -min

set_port_fanout_number The largest value is output if the set_port_fanout_number for the

same port on different instances have different values.
set_port_fanout_number 10 set_port_fanout_number 20 set_port_fanout_number 20

set_logic_zero A one-to-one correspondence is required for all the blocks if some

of the pins with set_logic_zero statements are inside the multiply
instantiated modules. The set_logic_zero constraint is dropped
from the combined SDC file otherwise. The same is true for
set_logic_zero statements on ports.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
set_logic_zero [get_ports {in}] set_logic_zero [get_ports {in}] set_logic_zero [get_ports {in}]
set_logic_zero [get_ports {in}] no set_logic_zero statement for no set_logic_zero statement

port in for port in
set_logic_one A one-to-one correspondence is required for all the blocks if some

of the pins with set_logic_one statements are inside the multiply
instantiated modules. The set_logic_one constraint is dropped
from the combined SDC file otherwise. The same is true for
set_logic_one statements on ports.
set_case_analysis A one-to-one correspondence is required for all blocks in the pin

name and case analysis value if the pins are inside multiply
instantiated modules. Otherwise the set_case_analysis
constraint is dropped from the combined SDC file. The same is true
for set_case_analysis statements on the ports.
set_case_analysis 0 [get_ports set_case_analysis 0 [get_ports set_case_analysis 0 [get_ports

{in}] {in}] {in}]
set_case_analysis 0 [get_ports set_case_analysis 1 [get_ports No set_case_analysis

{in}] {in}] statement generated
set_case_analysis 0 [get_ports No set_case_analysis No set_case_analysis

{in}] statement for port in statement generated
set_operating_conditions Operating conditions must match exactly for all multiply instantiated
module instances for the generation of
set_operating_conditions statements.
set_operating_conditions -max set_operating_conditions -max set_operating_conditions -max

BCCOM BCCOM BCCOM
set_operating_conditions -max set_operating_conditions -max No

BCCOM WCCOM set_operating_conditions
statement generated.

set_disable_timing The list of disabled cells, pins or ports in the current design match
exactly for all multiply instantiated module instances for the
generation of set_disable_timing statements.
set_disable_timing -from A -to set_disable_timing -from A -to set_disable_timing -from A -to

Z [get_cells {U1}] Z [get_cells {U1}] Z [get_cells {U1}]
set_disable_timing -from A -to set_disable_timing -from B -to No set_disable_timing

Z [get_cells {U1}] Z [get_cells {U1}] statement generated
set_disable_timing -from A -to No corresponding No set_disable_timing

Z [get_cells {U1}] set_disable_timing statement generated
statement.
set_clock_gating_check A set_clock_gating_check statement is written to the combined

SDC file if it is present in at least one of the SDC files generated for
individual instances. If two different set_clock_gating_check
statements are applied to equivalent objects in the two SDC files,
the strictest constraint is written.
set_clock_gating_check -setup set_clock_gating_check -setup set_clock_gating_check -setup

0.5 [get_cells {U1}] 0.5 [get_cells {U1}] 0.5 [get_cells {U1}]

set_clock_gating_check -setup
0.7 [get_cells {U2}]

set_max_time_borrow The worst case maximum time borrow value is written to the
merged SDC file.
set_max_time_borrow 0.5 set_max_time_borrow 0.5

{latch1} {latch1}

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
set_max_time_borrow 0.5 set_max_time_borrow 0.6 set_max_time_borrow 0.5

{latch1} {latch1} {latch1}
set_max_transition The worst case maximum transition time value is written to the
merged SDC file.
set_max_capacitance The worst case set_max_capacitance value is written to the

merged SDC file.
set_max_capacitance 1.0 set_max_capacitance 1.5 set_max_capacitance 1.0

[get_ports port1] [get_ports port1] [get_ports port1]
set_min_capacitance The worst case set_min_capacitance value is written to the

merged SDC file.
set_min_capacitance 0.3 set_min_capacitance 0.4 set_min_capacitance 0.4

[get_ports port1] [get_ports port1] [get_ports port1]
set_max_fanout The worst case set_max_fanout value is written to the merged

SDC file.
set_max_fanout 10 [get_ports set_max_fanout 15 [get_ports set_max_fanout 10 [get_ports

port1] port1] port1]
Performing Budgeting on Multiple Scenarios

You can perform timing budgeting and generate constraints for each scenario for designs
that contain multiple scenarios. To minimize system resources, you can use the get
dominant scenario timing budgeting flow and activate only the dominant scenario.
Figure 12-4 illustrates the get dominant scenario timing budgeting flow. For large designs,
this flow requires less system resource than activating all scenarios at the same time.

Performing Budgeting on Multiple Scenarios 12-24
Figure 12-4 Get Dominant Scenario Timing Budgeting Flow
Perform virtual in-place optimization
Set first active scenario

set_active_scenarios
Perform timing budgeting on first scenario

allocate_fp_budgets
Set next active scenario

Set active scenario
set_active_scenarios
Perform timing budgeting on next scenario

allocate_fp_budgets -add_scenarios
The tool budgets all scenarios in two phases in the get dominant scenarios timing budgeting
flow. The tool first performs timing budgeting by applying the constraints for the dominant
scenario. Next, the tool budgets other scenarios when you specify the -add_scenarios
option and combines the constraints. This flow makes it possible to generate constraints for
all scenarios without making all scenarios active at the same time, reducing the system
resource requirements necessary for performing timing budgeting.
Note the following when using this flow:
• If you specify the -add_scenarios option without first performing an initial timing
budgeting run, the results are undefined.
• If you budget the same scenario twice by using two consecutive -add_scenarios
options, the results are undefined.
Performing Distributed Timing Budgeting for Multiple Scenarios

You can perform distributed timing budgeting to increase the number of budgeting scenarios
and decrease the overall runtime for timing budgeting. Distributed timing budgeting enables
you to run each scenario independently on a different machine, reducing the memory
requirement for timing budgeting.
Specify the -host_options name, -work_directory dirname, -pre_open_cell_script
prescriptname, and -post_open_cell_script postscriptname options to enable
distributed timing budgeting. The -host_options option creates a task for each scenario
and combines the results after the tasks complete. The -work_directory option specifies
the directory name for the distributed budgeting run. The default directory is ./TB_work_dir.
The -pre_open_cell_script option specifies the script file name that is run before

Performing Distributed Timing Budgeting for Multiple Scenarios 12-25
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
opening the cell in the distributed process. The -post_open_cell_script options specifies
the script file name that is run immediately after the distributed process opens the cell.
To use distributed timing budgeting, you must have a distributed processing system
configured in your compute environment. The following example uses the
set_host_options command to enable four distributed processes using the Oracle Grid
Engine and uses the allocate_fp_budgets command to perform distributed timing
budgeting.
icc_shell> set_host_options -name my_grd_host_options \
-pool grd -submit_options {-P bnormal -l arch=glinux, \
cputype=amd64,mem_free=4G,mem_avail=4G -l \
qsc=f -cwd}
icc_shell> allocate_fp_budgets \
-host_options my_grd_host_options \
-pre_open_cell_script pre.tcl \
-post_open_cell_script post.tcl
Note the following when performing distributed budgeting:

• Some implementation commands are disabled and should not be included in the
pre-open-cell and post-open-cell scripts
• Relative paths are not supported in the pre-open-cell and post-open-cell scripts, use
absolute paths instead
• The design being budgeted must be a multicorner-multimode design
Performing Hierarchical Signal Integrity Budgeting

Timing budgeting can consider crosstalk effects across soft macro boundaries when
generating SDC constraints. Hierarchical signal integrity budgeting can extract effective
drive strength for input pins and coupling capacitance for interface nets. The timing budgeter
can retrieve crosstalk analysis information from a hierarchical signal integrity module and
then write out this information to block pin attributes. Bringing the top-level crosstalk
information into the block level during budgeting makes it easier for block-level crosstalk
analysis to consider the crosstalk effects at the top level.
Before running timing budgeting, set the budgeting_enable_hier_si variable to true to
enable signal integrity budgeting and take the crosstalk timing effects across soft macro
boundaries into account.
icc_shell> set_app_var budgeting_enable_hier_si true
Run the timing budgeting command.

icc_shell> allocate_fp_budgets

Performing Hierarchical Signal Integrity Budgeting 12-26
The command processes the hierarchical signal integrity information during budgeting and
writes out this information about the block’s pin attributes.
The total effective drive strength is written out on block pins to represent the top-level
aggressor drive strength, and the total coupling capacitance is written out on block pins to
represent the total coupling capacitance in the block CEL view.
Block-Level Hierarchical Signal Integrity Flow

To run the block-level hierarchical signal integrity flow, do the following:
1. Enable the hierarchical signal integrity flow.
set_app_var budgeting_enable_hier_si true
2. Define the signal integrity options used for analysis or optimization.

set_si_options -static_noise true -delta_delay true
The -static_noise true option reduces static noise.
The -delta_delay true option optimizes the timing with crosstalk delay.
3. Perform routing and postroute optimization.
route_opt -xtalk_reduction
The tool performs crosstalk prevention during global routing and track assignment, and
crosstalk analysis and optimization during the postroute optimization phase.
4. Create a Milkyway signal-integrity-aware hierarchical model.
icc_shell> create_block_abstraction
icc_shell> save_mw_cel
Top-Level Hierarchical Signal Integrity Flow

To run the top-level hierarchical signal integrity flow, do the following:
1. Enable the hierarchical signal integrity flow.
set_app_var budgeting_enable_hier_si true
2. Define the signal integrity options used for analysis or optimization.

set_si_options -static_noise true -delta_delay true
The -static_noise true option reduces static noise.
The -delta_delay true option optimizes the timing with crosstalk delay.

Performing Hierarchical Signal Integrity Budgeting 12-27
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
3. Perform routing and postroute optimization.

route_opt -xtalk_reduction
The tool performs crosstalk prevention during global routing and track assignment, and
crosstalk analysis and optimization during the postroute optimization phase.
Performing Post-Budget Timing Analysis

After performing timing budgeting on a design, you can perform post-budget timing analysis
to generate a report containing budgeted and actual delays through a hierarchical block.
Note:
This command must be run during the same IC Compiler timing budgeting session in
which the budgets were created.
To perform post-budget timing analysis,
1. Choose Timing > Floorplan Budgeting Report.
The Budgeting Report window appears.
Alternatively, you can use the check_fp_budget_result command to generate a report
file.
2. Select “Check budget from command check_fp_budget_result” and enter the -blocks,
-pins, or -file_name options from the check_fp_budget_result command. You can
also select command options by clicking the “set option” button and entering the
-blocks, -pins and file name options in the pop-up dialog. A list of paths is displayed
based on the options you specify.
Alternatively, select “Check budget by selecting pin delay ranges of the blocks” and click
Load Table. The table is populated with Block Name and a count of pins within each
delay category. Select a check box and click Report to populate the Paths of budgeted
target pin on its delay table with the list of paths.
3. Select a Path Name from the list and click Path Inspector. A graphical representation of
the path is displayed as shown in Figure 12-5.

Performing Post-Budget Timing Analysis 12-28
Figure 12-5 Budgeting Report Window
A timing path starts at a startpoint and ends at an endpoint. Timing paths are divided into
segments. For each timing path segment, the report prints the actual and budgeted delay or
the fixed delay values of the segment. You can use this information to analyze the process
of generating budgets for your design.
You can also generate a text or HTML format post-budget timing analysis report using the
check_fp_budget_result command. For each pin on a block, the report lists the worst
case timing paths per endpoint clock domain that pass through the pin. For each path
segment on the timing path, the report lists the budgeted and actual delays for the path
segment.
To generate a plain text format report, specify the -file_name reportfile option. The
following example writes a plain text format report to the report.rpt file.
icc_shell> check_fp_budget_result -file_name report.rpt
Starting check_fp_budget_result ...
1

Performing Post-Budget Timing Analysis 12-29
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
To generate an HTML format report, specify the -file_name reportfile -html

-html_dir dirname options. The following example writes a plain text format report to the
report.rpt file, writes an HTML format report to the htmlreport directory, and lists the contents
of the htmlreport directory. The command generates an HTML file for each plan group in the
design. To view the HTML format report, open the htmlreport/index.html file in a browser.
icc_shell> check_fp_budget_result -html -html_dir htmlreport \
-file_name report.rpt
Starting check_fp_budget_result ...
1
icc_shell> sh ls htmlreport
I_ORCA_TOP_I_BLENDER_0.html
index.html
Performing Clock Latency Budgeting

You can perform clock latency budgeting. This budgeting feature uses information from files
built by clock planning to include clock latencies associated with real clock tree branches
that are external to the block being budgeted. Clock planning can create clock budgets for
each plan group inside the design to specify the source and network latencies whether or
not the clock has a sink inside the plan group.
The allocate_fp_budgets command creates virtual clocks to capture these latencies from
clock planning. This budgeting feature also generates real latency values in budgets for
physical clock ports created by clock planning on a block. The clock ports are created by the
clock planning features. These latencies are associated with real physical ports.
Creating Budgets to Reflect Real Clock Latencies

After clock planning, you can create budgets to reflect real clock latencies. This consists of:
• Creating real clock latency values on clock ports for the block.
• Creating input and output virtual clocks for interface path endpoints that are partially
outside the block.
The syntax for defining virtual clocks created for latencies outside the block is
clockname__v__in
and
clockname__v__out
Clocks launching (capturing) flip-flops on the top level have source latencies only.

Performing Clock Latency Budgeting 12-30
Clocks launching (capturing) flip-flops in blocks have both source and network latencies.
Clock latency budgeting is on by default if timing budgeting (allocate_fp_budgets
command) is run after clock planning.
You can enable (turn on) clock planning based latency values by setting the following
variable in the icc_shell to true (the default) before performing timing budgeting:
set virtual_clocks_from_cp true
To disable (turn off) clock planning based latency values, set the following variable in the
icc_shell to false.
set virtual_clocks_from_cp false
You can include latencies during budgeting for synthesized clock trees which were not
created during clock planning by setting the following variable to a value of true before
running the timing budgeter. The default is false.
icc_shell> set synthesized_clocks true
To disregard clock tree synthesis-based latency values, set the synthesized_clocks

variable to false.
icc_shell> set synthesized_clocks false
After you create budgets to reflect real clock latencies, check for the following:
• Ensure every real input clock port created by clock planning for a block budget has
calculated source and network latency statements in the block budget.
• Ensure latency statements in the budgets reflect the actual clock network delays in the
design.
• Ensure every input port set_input_delay and set_output_delay is referenced to a
virtual clock that has the latency for the launch or capture clock associated with the path
through the port.
• Check latencies in budgets against clock planning latency files.
Note:
Clock planning creates a source latency file and a network latency file for each clock
port in the tcp_output directory.
• Check that latencies in budgets are only for clock ports defined in the block budget file.
• Check latencies in clock planning latency files against the clock skew report.

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

13
Committing the Physical Hierarchy 13
This chapter describes how to commit the physical hierarchy after finalizing the floorplan by
converting plan groups into soft macros. Committing the hierarchy creates a new level of
physical hierarchy in the virtual flat design by creating CEL views for selected plan groups.
After committing the physical hierarchy, you can also uncommit the physical hierarchy by
converting the soft macros back into plan groups.
In addition, this section describes how to propagate top-level preroutes into soft macros and
recover all pushed-down objects in child cells to the top level. It also describes how to
commit plan groups with associated UPF power domains.
• Converting Plan Groups to Soft Macros
• Pushing Physical Objects Down to the Soft Macro Level
• Pushing Physical Objects Up to the Top Level
• Handling 45-Degree Redistribution Layer Routing
• Committing the Hierarchy of Plan Groups With Power Domains
• Converting Soft Macros to Plan Groups
13-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Converting Plan Groups to Soft Macros

Before converting plan groups to soft macros, your design should meet the following
requirements:
• All plan groups, standard cells, and hard macros are legally placed.
• The traditional pin assignment or pin placement flow is complete.
• In-place optimization, timing analysis, and timing budgeting are complete.
To convert plan groups to soft macros, use the commit_fp_plan_groups command.

[-push_down_power_and_ground_straps]
[-new_top_cell new_cell_name]
[plan_groups]
For more information about the command options, see the commit_fp_plan_groups man
page.
To commit plan groups to soft macros using the GUI layout window, first set the window task
Then choose Partition > Commit Plan Groups. This opens the dialog box shown in
Figure 13-1.
Figure 13-1 Commit Plan Groups Dialog Box
To commit only specific plan groups, choose the Specified option in the GUI and enter the
plan group names or choose the plan groups in the GUI. By default, the tool commits all plan
groups to soft macros. To copy the power and ground straps into the new soft macro and
delete them from the top-level, select the Push down power and ground straps into the child
cell option. By default, the tool keeps the power and group straps at the top level. To rename
Chapter 13: Committing the Physical Hierarchy

Converting Plan Groups to Soft Macros 13-2
the new soft macro, select the Commit to a new top cell option and enter the new name in
the Top cell name box. By default, the tool uses the instance name as the new cell name.
Committing the physical hierarchy performs the following actions on the design:
• Converts the virtual flat design to a two-level hierarchical design
• Removes standard cells and hard macros belonging to a plan group from the top-level
design and copies them down to the soft macro that is created for the plan group
• Creates nets in the soft macros based on the hierarchy preservation data
• Pushes placement blockages and route guides down to the soft macros
• Pushes power and ground straps and standard cell preroutes down into each soft macro,
if selected
After the tool converts the plan groups to soft macros, the standard cell instances within the
plan groups are moved to the new soft macros and the new soft macros reside in the same
location as the plan groups they replace. Cell utilization for the new soft macros is the same
as for the plan groups. The default utilization is based on the sum of the area of standard
cells and hard macros in the cell divided by the area in the core area bounding box of the
cell.
Splitting the Soft Macros

When you commit the soft macros, the tool creates a CEL view for each of the blocks in the
same Milkyway design library. To make it easier for different designers to work on different
blocks, you can split the Milkyway design library into multiple libraries by using the
split_mw_lib command. The command splits the top-level Milkyway design into new
Milkyway design libraries for each block and the top-level design. After splitting, the new
Milkyway design libraries inherit all the information, including the technology file and the
reference library path, from the original Milkyway design.
Figure 13-2 shows the splitting of soft macros to create separate design libraries.

Converting Plan Groups to Soft Macros 13-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure 13-2 Committing Plan Groups and Creating Separate Design Libraries
Milkyway Design Library
CEL Top
Milkyway Design Library Milkyway Design Library
CEL CEL Milkyway Design Library

Top Commit Top Split
CEL A
CEL CEL
a
A B A B Milkyway Design Library
CEL B
commit_fp_plan_groups split_mw_lib
After block-level implementation, you can link the different design libraries to the top-level
design by using the set_mw_lib_reference command.
Pushing Physical Objects Down to the Soft Macro Level

You can use the push_down_fp_objects command to copy physical objects from the top
level into the soft macros and create pins and feedthroughs in the soft macros. The physical
objects include routing, route guides, blockages, cells, and cell rows.
push_down_fp_objects
[-allow_feedthroughs]
[-connect_objects_to_child_nets]
[-create_pins]
[-freeze_push_down_nets]
[-include_shapes all | with_net_id | without_net_id]
[-layers layer_object_list]
[-margin {lx by rx ty}]
[-object_type {list_of_types}]
[-objects object_list]
[-overlap_checking on | off]
[-partial_overlap]
[-push_down_type push_down | cut_down | copy_down]
[-remove_routing]
[-row_offset_x offset]
[-row_offset_y offset]
[-to_object_type blockage | original_type]
[-wire_net_type {list_of_net_types}]
[soft_macros]
For more information about the command options, see the push_down_fp_objects man
page.

Pushing Physical Objects Down to the Soft Macro Level 13-4
To push down objects into the new soft macros using the GUI layout window, first set the
window task mode to Design Planning if it is not already in that mode (File > Task > Design
Planning). Then choose Partition > Push Down Objects. This opens the dialog box shown in
Figure 13-3.
Figure 13-3 Push Down Objects Dialog Box
To copy down objects only to specific plan groups, choose the Specified soft macros option
in the GUI and enter the soft macro instance names. By default, the tool copies down objects
to all soft macros. Select the object types for the objects you want to push down in the Types
of objects to be pushed down box. If you select Shapes, you can push down all shapes,
shapes that are part of a net, or shapes that are not part of a net.
Select Push down specified objects to restrict the push down operation to only the objects
you specify. Enter a Tcl command or the name of the specific objects in the text box, or
choose the objects in the GUI. By default, the tool pushes down all objects of the specific

IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
types that you selected. Select the push down mode to specify how the tool processes the
object. Select Push to create a copy of the object in the soft macro and delete it from the top
level. Select Copy to create a copy of the object in the soft macro and retain it at the top
level. Select Cut to create pins for the routing objects at the soft macro boundaries.
Select one or more option following Net types: Clock, Signal, or Power and Ground to push
those objects down into the soft macro. Select the Type of pushed down objects, Blockage
or Original, to specify whether routing or cell objects are changed to blockages or whether
they remain as routes or cells. Select Limit pushed down objects to specified layers, and
select one or more metal layers, to push down only objects on the selected layers.
Select Check objects overlaps to check for overlapping routing before pushing down the
routes. By default, the tool does not perform overlap checking. Select Freeze push down
nets to prevent the modification of push-down nets during push-down and optimization.
Select Allow feedthroughs to create new ports for feedthroughs on signal and clock nets,
and create a new net at the top level. Select Create pins to create pin shapes when the push
down mode is Copy. Select Remove routing to remove the route connections between the
pushed down cells. Select Retain bus naming to keep the bus naming convention, such as
"[number]", for the newly created child feedthrough ports and child feedthrough nets. Select
Connect copy down objects to their nets when you select Copy as the push down mode to
connect pushed down objects to their corresponding nets in the soft macro. Select Include
partially overlapped cells to push down cells that partially overlap the soft macro boundary.
Specify horizontal and vertical offset values to Offset between soft macro core and rows
when you copy down rows. Select Margin around soft macro boundary and specify values
in the Left, Right, Top and Bottom boxes to capture objects outside the soft macro boundary
and push them down into the soft macro as blockages.
Using the Margin Option for Pushing Down Objects

Figure 13-4 shows the usage of the -margin option to push-down objects based on an
offset from the cell boundary. The following push_down_fp_objects command treats
routing objects based on the overlap with the cell B boundary and margin boundary.
icc_shell> push_down_fp_objects -object_type {routing} \
-margin {10 10 10 10} [get_cells B]
Routing objects that overlap the boundary of cell B are pushed into cell B as routing, and
objects within the margin are pushed down as route guides or blockages.

Figure 13-4 Using Margin to Control Routing Push Down

Margin boundary
3 3 3
2 2 2
A 1 A 1 A 1
B 4 B 4 B 4
Before push down Top view Cell B view

after push down after push down
Pushing Down Routing in Multiply Instantiated Modules

Routes are pushed down differently in designs that contain multiply instantiated modules.
Only routes that overlap reference instances when processing power and ground nets, or
clock and signal nets without ambiguous connection, are pushed down. The tool checks the
routing alignment between the reference instance and nonreference instances and issues a
warning message if alignment is not maintained. For power and ground nets, gaps are
placed between the top-level power and ground straps and the PG pins for multiply
instantiated module instances that are not aligned with the reference instance and are not
surrounded by power and ground rings. These gaps allow power and ground routing to
connect the PG pins at a later time.
Pushing Physical Objects Up to the Top Level

You can use the push_up_fp_objects command to move objects from the soft macro level
to the top level of the design. The physical objects include routing, route guides, blockages,
cells, pins, pin guides, net shapes, and cell rows.
push_up_fp_objects
[-object_type {list_of_types}]
[-push_up_type push_up | copy_up]
[-layers layer_objects]
[-to_object_type routing | pins | blockage | original_type]
[-top_level_interface_nets net_objects]
[-remove_routing]
[-include pushed_down_objects_only | all]
[-include_shapes all | with_net_id | without_net_id]
[-ignore_not_push_down_nets]
[-child_objects child_objects]
[macros]

Pushing Physical Objects Up to the Top Level 13-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
For more information about the command options, see the push_up_fp_objects man
page.
To push up objects from soft macros to the top design level by using the GUI layout window,
first set the window task mode to Design Planning if it is not already in that mode (File > Task
> Design Planning). Then choose Partition > Push Up Objects. This opens the dialog box
Figure 13-5 Push Up Objects Dialog Box
To push up objects only from specific soft macros, choose the Specified soft macros option
in the GUI. Enter the soft macro instance names or choose the objects in the GUI. By
default, the command pushes up objects from all soft macros. Select the object types in the
Types of objects to be pushed up box. If you select Shapes, you can select all shapes,
shapes that are part of a net, or shapes that are not part of a net.
Select the All objects option to push up all cells, nets, shapes, and routing objects. Objects
that were pushed down and new objects created within the soft macro are pushed up by this
option. By default, the Pushed down objects only option is selected and the tool pushes up

Pushing Physical Objects Up to the Top Level 13-8
only objects that were previously pushed down. Select Collection of child objects and enter
a collection or Tcl command in the box to specify a collection of objects.
Select the Copy option following Push up mode to create a copy of the object at the top level
and retain the object within the soft macro. By default, the Push option is selected and the
tool creates a copy of the object at the top level and deletes the object in the soft macro.
Select Top level nets connected to soft macros and enter or select a top-level net name to
push up only objects connected to the specified nets.
Select Ignore non push-down nets to keep route objects at the soft macro level that are
connected to nets that were not pushed down. If you select this option, you must also select
the Routing option in Types of objects to be pushed up box. Select Remove routing between
pushed up cells to prevent the tool from connecting cells that are pushed up. By default, both
the cells and the routing between the cells is pushed up.
Use the Types of objects after push up from soft macro options to transform objects as they
are pushed up to the top level from the soft macro level. Select Routing to push up route and
pin objects as routes. Select Pins to push up soft macro pins as terminals. Select Blockages
to push up objects as blockages at the top level. By default, the Original option is selected
and pushed up objects retain the same type after they are pushed up.
Select Limit pushed up objects to specified layers and select one or more Metal layers from
the selection box to restrict the push up operation to the specified subset of metal layers.
Handling 45-Degree Redistribution Layer Routing

The push_up_fp_objects and push_down_fp_objects commands can support 45-degree
redistribution layer routing. During push down, the 45-degree routes are split at the
intersecting points between the soft macro boundaries and where the 45-degree routes are
added. Square-shaped pins are created at the intersection points during push-down; during
push up, these pins are deleted at the soft macro boundaries.
During push up, the 45-degree routes are restored to the original state before push down.
(Wires are merged at the intersection points between the soft macro boundaries and the
routes.)
If a net has no ambiguous connection to a soft macro and a feedthrough is not allowed,
routing that is collinear with a block boundary is pushed down.

Handling 45-Degree Redistribution Layer Routing 13-9
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Committing the Hierarchy of Plan Groups With Power Domains

The commit_fp_plan_groups command supports plan groups that have a Unified Power
Format (UPF) power domain associated with them. The power domain must be defined
completely within the hierarchical cell instance of the plan group that is being converted to a
soft macro. For more information, see the Multivoltage Design Flow chapter in the IC
During the commit hierarchy process, the top-level power domains associated with the plan
groups are pushed down into a new child cell. This also makes it possible for the top-level
design’s UPF constraints to be properly transferred and maintained. Embedded voltage
areas and power domains associated with those voltage areas are also pushed into the child
cell.
Near the end of the commit process, after the top-level hierarchical cell instance is replaced
with a top-level child cell instance, all corresponding power domains are removed from the
top-level cell, along with any voltage areas associated with the pushed down power
domains. This is done to avoid the duplication of power domains across the hierarchy. Any
top-level voltage area that was coincident with the plan group boundary is also removed
from the top-level design and treated as the default voltage area within the child cell
instance.
Note:
If a power domain extends beyond the boundaries of the plan group, it might contain
UPF elements that are outside the plan group. These elements are not committed to the
soft macro.
Converting Soft Macros to Plan Groups

You can use the uncommit_fp_soft_macros command to undo a previous
commit_fp_plan_groups command and convert soft macros into plan groups to create a
flat design.
uncommit_fp_soft_macros
[-push_up_preroutes pg | none]
[-remove_feedthroughs]
[objects]
For more information about the command options, see the uncommit_fp_soft_macros
man page.
To uncommit soft macros using the GUI layout window, first set the window task mode to
Design Planning if it is not already in that mode (File > Task > Design Planning). Then
choose Partition > Uncommit Soft Macros. This opens the dialog box shown in Figure 13-6.

Committing the Hierarchy of Plan Groups With Power Domains 13-10
Figure 13-6 Uncommit Soft Macros Dialog Box
The tool pushes up physical objects from the soft macro to their relative positions in the
top-level design. Any physical objects that make a physical connection to power and ground
nets are connected to the corresponding power and ground nets in the top-level design. The
tool copies object properties from the soft macro to the top-level design.
Select Specified in the Target soft macros box and enter or select the macros you want to
uncommit. By default, the All option is selected and the contents of all soft macros are
copied to the top level. Select the All option in the Preroutes to push up section to push up
all power, ground and detail routing, Select the Power and Ground option to push up only the
power and ground straps. Select None to avoid pushing up preroutes. Select Remove feed
through ports on soft macros to remove the feedthroughs from the selected soft macros. All
feedthrough nets and ports with suffixes of *_pft and *_rft are removed.
The tool copies the following objects from the soft macro to the top-level design:
• Standard cells
• Straps on power and ground nets
• Vias on power and ground nets
• Placement blockages, including soft placement blockages and the internal padding
around the boundary and cell rows
• Route guides
Note that the uncommit process does not remove the soft macros that were present before
running the commit_fp_plan_groups command. Any routing in the soft macros, except for
the power and ground preroutes, is deleted after you uncommit the hierarchy.

Converting Soft Macros to Plan Groups 13-11
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
During the uncommit process, when the soft macros are converted back into plan groups,
the uncommit_fp_soft_macros command automatically propagates the child level Unified
Power Format (UPF) constraints and other Milkyway data from the soft macro to the top
level of the design. The tool performs the following actions regarding UPF:
• Locates all power domains and their corresponding voltage area geometries and
instantiates them in the top-level design, according to how they were instantiated in the
soft macro. In the case of the topmost power domain in the soft macro, which has a
default voltage area, the voltage area is instantiated in the top-level design with the same
name as its corresponding power domain and with a geometry that is coincident with the
plan group boundary.
• Reconnects the newly instantiated top-cell power domains to existing Milkyway objects.

Converting Soft Macros to Plan Groups 13-12
A
Using the Flip-Chip Flow A
This appendix describes how to use the flip-chip flow in the IC Compiler tool. You can use
hierarchical or virtual flat implementation flows for designs with flip-chip structures. The IC
Compiler flip-chip interface can create both 45-degree and 90-degree redistribution layer
(RDL) routing.
The following two flip-chip design flows are supported in the IC Compiler tool:
• Package-driven, also referred to as a bump-driven flow, where flip-chip I/O driver
locations are optimally determined by package defined bump cell locations
• Die-driven, also referred to as an IC-driven flow, where individual bump cell locations are
optimally determined by the I/O driver placement
The IC Compiler flip-chip interface supports two design styles: single I/O driver ring and
multiple I/O driver ring. The tool places the flip-chip drivers in a ring formation along the
periphery of the chip.
In a flip-chip design, a bump cell represents a piece of metal or solder bump that forms an
electrical contact to the chip package. Similar to processing silicon wafers for wire bonding,
openings are made on the wafer to expose the metal contact points. Solder bumps are
formed on these metal contact points. The chip’s power, ground, and signal I/Os are
available through the solder bumps that are formed on the top side of the wafer during the
final processing step. The solder bumps on the chip make the physical connections to the
package substrate. The chip is connected to external circuitry (a circuit board, another chip,
or a wafer) by flipping it over so that the solder bumps connect to metal pads to complete the
A-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
interconnect. This is in contrast to wire bonding in which the chip is mounted upright and
wires are used to connect the chip pads to external circuitry.
The flip-chip driver is the I/O circuitry that drives or receives signals from or to the chip
through the bump. There are signal bump cells, which are connected to signal and clock
nets, and power and ground bump cells, which are connected to power and ground straps.
The locations of solder bumps on the chip are determined by the placement of the bump
cells. (The I/O driver cells are placed independently.) You can place bump cells on top of the
I/O drivers or anywhere within the core area. You can also place standard cells under bump
cells.
• Flip-Chip Implementation Flow Overview
• Preparing the Library
• Creating an Initial Floorplan
• Using a Die-Driven Flip-Chip Flow
• Using a Package-Driven Flip-Chip Flow
• Routing Flip-Chip Bumps
• Using Flip-Chip Structures in Cover Macros
• Creating RDL Net Shielding
• Creating Tapered Routes
• Connecting Floating Bump Cells to Ring Nets
• Summary of the Flip-Chip Commands
Appendix A: Using the Flip-Chip Flow

A-2
Flip-Chip Implementation Flow Overview

The IC Compiler tool supports two primary flows for flip-chip implementation: die-driven and
package-driven. In the die-driven flow, the bump locations are dependent on the die and
determine the bump locations for the IC package. Bump cells are not instantiated nor
connected to flip-chip I/O drivers as inputs in the Verilog netlist. The optimal bump
connections are determined by the placement of the flip-chip drivers and bump patterns.
In the package-driven flow, the IC package dictates the bump locations for the IC design. All
of the bump cells are instantiated and connected to flip-chip drivers as inputs within the
Verilog netlist. The physical locations for the bump cells are predefined by the package
designer. The optimal flip-chip I/O driver locations are determined during flip-chip driver
placement based on the predefined bump locations.
Figure A-1 shows the high-level die-driven and package-driven flow diagrams. The following
sections describe the steps in both flows.
Figure A-1 Flip-Chip High-Level Flows
Die-Driven Flow Package-Driven Flow
Setup library Setup library
Create floorplan Create floorplan
Instantiate bump cells Import bump locations
Designate driver matching type Define flip-chip driver sites
Place I/O drivers Designate driver matching type
Assign nets Define flip-chip grid
Route redistribution layer Set flip-chip options
Place I/O drivers

Optional steps
Route redistribution layer
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Flip-Chip Implementation Flow Overview A-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Preparing the Library

The IC Compiler tool recognizes flip-chip I/O drivers and bump cells only when they are
assigned the correct cell type and port type properties in the Milkyway design library. This
section describes the library preparation steps for the flip-chip I/O drivers and bump cells.
Library preparation must be done in the Milkyway Environment tool by using Milkyway
Scheme commands. Information about the Milkyway Environment tool is available on
SolvNet.
See Also
• I/O Drivers
• Bump Cells
I/O Drivers
To prepare the I/O drivers, open the design in the Milkyway Environment tool. Select
Scheme mode and perform the following operations:
• Set the cell type as IO Pad by using the cmMarkCellType command.
cmMarkCellType
setFormField "Mark Cell Type" "Cell Type" "pad"
formOK "Mark Cell Type"
• Set the PAD port as flipchip by using the dbSetCellPortTypes command.

dbSetCellPortTypes "libname" "cellname" '(
("PAD" "inout" "flipchip")
) #f
• Set the power and ground pins as flipchip by using the dbSetCellPortTypes
Milkyway command.
dbSetCellPortTypes "libname" "cellname" '(
("VDD "inout" "Power" "flipchip")
("VSS" "inout" "Ground" "flipchip")
) #f

Preparing the Library A-4
Bump Cells
You can maintain bump cells in the same Milkyway design library that you use for the I/O
driver cells. To prepare the bump cells, open the design in the Milkyway Environment tool.
Select Scheme mode and perform the following operations:
• Mark the bump cell as a flip-chip bump by using the cmMarkCellType command.
cmMarkCellType
setFormField mark_cell_type library_name lib
setFormField mark_cell_type cell_name cell
setFormField mark_cell_type cell_type "flip chip pad(bump)"
formOK mark_cell_type
• Set the port type.

dbSetCellPortTypes "/path/to/library" "BUMPCellName" '(
("BUMP" "inout" "FlipChip" "Universal"
) #f
• Create bump terminals (pins) on a redistribution routing layer by doing the following:
❍ Create a .lib file with a terminal name and a corresponding .db file. Without the .lib file,
all bump cells are treated as physical-only cells.
❍ Locate the layer for the octagonal-shaped passivation opening in the flip-chip bump
cell.
❍ Create a polygon in the CEL view by using the geAddPolygon command or choose
Milkyway: Create > Polygon. Query the polygon to get a list of vertices.
❍ Enter the name or number of the layer on which you want to create the polygon,
select the L45 routing option, and then add all the vertices.
You should now have an octagonal piece of metal in the bump CEL view.
❍ Add text to the layer by using the geAddText command. Use the text layer that
matches the newly created terminal.
❍ Create a FRAM view by using the auExtractBlockPinVia command.
The CEL and FRAM view should match the terminal name that you created in the .lib
file.
Figure A-2 shows the CEL and FRAM views of a bump cell.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Preparing the Library A-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure A-2 Bump CEL and FRAM Views

CEL view FRAM view
Creating an Initial Floorplan

Use the create_floorplan command to create an initial floorplan for your design, based
on the input control parameters such as target utilization, aspect ratio, core size, row
number, chip boundary, and wire tracks. You can also use the read_def command to import
a previously saved floorplan.
Using a Die-Driven Flip-Chip Flow

In a die-driven flow, the IC design dictates the flip-chip bump cell locations.
• The bump cells are not instantiated, nor are they connected to flip-chip I/O drivers in the
Verilog netlist.
• The connections between the I/O drivers and individual bump cell locations are
determined by the placement locations of the flip-chip I/O drivers and the bump pattern
placement.
• The connectivity between the I/O ports and the I/O drivers can be output in the Verilog
netlist.
The following topics are covered in this section:

• Instantiating Bump Cells and Designating Matching Types
• Designating Matching Types for Bump Patterns
• Placing Flip-Chip I/O Drivers
• Assigning Nets From Bumps to I/O Drivers
Figure A-3 shows the die-driven flip-chip flow.

Creating an Initial Floorplan A-6
Figure A-3 Die-Driven Flip-Chip Flow
Setup library
Create floorplan
Instantiate bump cells
Designate driver matching type
Place I/O drivers
Assign nets
Route redistribution layer
Instantiating Bump Cells and Designating Matching Types

After creating the floorplan in the die-driven flip-chip flow, you can instantiate the flip-chip
bump patterns and prepare the bump cells for assignment by designating matching types.
In the die-driven flip-chip flow, the tool places bump cells in a ring configuration or an array
configuration. The following sections describe the steps to create bump patterns and
designate matching types.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Using a Die-Driven Flip-Chip Flow A-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Creating a Pattern of Bump Cells in a Ring Configuration

You can instantiate a specified number of bump cells and place them in your design in a ring
configuration by using the place_flip_chip_ring command:
place_flip_chip_ring
-physical_lib_cell {cell_name}
-prefix prefix
-number num_bump
-bump_spacing spacing
-ring_number ring_number
-ring_spacing ring_spacing
-boundary boundary_box
[-left_orientation N | W | S | E | FN | FS | FW | FE]
[-same_orientation]
[-stagger_offset offset]
[-extra_spacing extra_spacing]
[-num_extra_spacing num_extra]
For more information about the command options, see the place_flip_chip_ring man
page.
Specify the name of the bump reference cell by using the -physical_lib_cell
{cell_name} option; you can specify only one library cell. The -prefix prefix_string
option specifies the prefix string used to create the cell name. For example, the argument
-prefix "BUMP_" specifies that the new bump cells are named BUMP_1, BUMP_2, and so
on. The -number bump_count option specifies the number of bump cells to place. The
place_flip_chip_ring command places bump cells until the specified number of bumps
is placed or until all the flip-chip bump locations in each specified ring are allocated.
Specify the spacing between bump cells by using the -bump_spacing spacing option;
specify the spacing between rings by using the -ring_spacing spacing option. Both
spacing values are specified in microns. The -ring_number count option specifies the
number of rings to create. The -boundary {x1 y1 x2 y2} option specifies the bounding
box for the outermost ring.
In the following example, the command creates and places 100 flip-chip bump cells using
the PAD80B library cell in a two-ring configuration. The spacing between the adjacent bump
cells and the adjacent ring cells is 70 microns, and the outermost ring occupies the rectangle
bounded by the coordinates {290 290} and {2940 1934}.
icc_shell> place_flip_chip_ring -physical_lib_cell {PAD80B} \
-prefix "BUMP_" -bump_spacing 70 -ring_number 2 \
-ring_spacing 70 -number 100 -boundary "290 290 2940 1934"
Figure A-4 shows the layout after running the previous command.

Figure A-4 Placing Bump Cells in a Dual Ring Configuration
By default, the command places bump cells on the left die edge in the North orientation,
bump cells on the top die edge in the East orientation, bump cells on the right edge in the
South orientation, and so on. To place all flip-chip bump cells in the same orientation, use
the -same_orientation option.
The -left_orientation orientation option specifies the orientation of the flip-chip
bump cells on the left die edge. When you specify both the -left_orientation and
-same_orientation options, the command places all flip-chip bumps in the same
orientation as specified by the -left_orientation option.
Figure A-5 shows two simple layouts containing bump cells. The layout on the left is created
without the -same_orientation option and the layout on the right is created with the
-same_orientation option.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure A-5 Flip Chip Bump Orientation
Creating an Array of Bump Cells

You can create a two-dimensional array pattern of flip-chip bumps by using the
place_flip_chip_array command:
place_flip_chip_array
-physical_lib_cell {phy_lib_cels}
-prefix prefix
-start_point {x y}
-number num_bump
-delta {x y}
-repeat {columns rows}
[-orientation N | W | S | E | FN | FE | FS | FW ]
[-cell_origin lower_left | center ]
For more information about the command options, see the place_flip_chip_array man
page.
Define the bump cell array by specifying the starting point and the x- and y-pitch for each
bump cell in the pattern. The place_flip_chip_array command can be used to place
power and ground bump cells in the chip core. The -start_point {x y} option defines the
starting point of the lower leftmost bump cell. The -delta {x y} option sets the horizontal
and vertical pitch for each bump cell in the array. The -repeat {columns rows} option
specifies the number of columns and rows in the array. The place_flip_chip_array
command places bump cells into the array pattern until the specified number of bumps is
placed, or until the array pattern is full.

The -physical_lib_cell, -prefix, and -number options operate in the same way as in
the place_flip_chip_ring command. For more information about these options see
“Creating a Pattern of Bump Cells in a Ring Configuration” on page A-8.
In the following example, the place_flip_chip_array command creates 28 flip-chip bump
cells and places them in a 7 by 4 array pattern, starting at the lower-left x- and y-coordinate
of {590 590}. The bump cells are named with the VDD_CORE_ prefix. The bump cells are
placed by using a 300 micron center-to-center pitch in both the horizontal and vertical
directions.
icc_shell> place_flip_chip_array -physical_lib_cell {PAD80B_P} \
-prefix "VDD_CORE_" -start_point {590 590} -number 28 \
-delta {300 300} -repeat {7 4}
Figure A-6 shows the layout after running the previous command.
Figure A-6 Placing Bump Cells in a 7 by 4 Array Pattern
Designating Matching Types for Bump Patterns

Before routing the flip-chip drivers to the flip-chip nets, you can associate flip-chip drivers
and bump cells by designating a matching type. The matching type for a cell has two primary
functions: provide support for driver-to-bump pairing and provide support for driver
placement. The tool assigns flip-chip drivers to flip-chip bump cells that have the same
matching type.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Use the set_matching_type -matching_type name command to designate bump pattern

matching types for the flip-chip bump cells, I/O drivers, and specified pins or I/O ports.
Specify the matching type by using the name argument; the matching type is associated
with a flip-chip driver or a flip-chip bump cell. You can run this command multiple times; the
new matching type setting overrides the existing matching type setting. The matching type
assigned to a driver can also be used to guide driver placement.
The following example assigns the matching type “signal” to all signal bump cells and I/O
drivers in the design that have a reference cell name beginning with BUMP_.
icc_shell> set_matching_type \
-matching_type "signal" [get_cells "BUMP_*"]
Use the report_matching_type command to display the matching type assigned to a

collection of driver and bump cells.
icc_shell> report_matching_type [get_cells "BUMP_*"]
******************************
Report : matching type
Design : flip_chip
Version: E-2010.12-SP1
******************************
----------------------------------------------------------------
Begin to report cell matching type:
cell matching type
BUMP_21 signal
BUMP_0 signal
BUMP_22 signal
BUMP_10 signal
BUMP_11 signal
BUMP_23 signal
Use the following command syntax to reset the matching type and allow the driver to match
any bump cell that does not have an assigned matching type.
icc_shell> set_matching_type -matching_type "" [get_cells "BUMP_*"]
Placing Flip-Chip I/O Drivers

After instantiating the bump cells in the die-driven flow, place the I/O drivers and assign
matching types in preparation for connecting the drivers to the bump cells. I/O drivers can
be placed in a ring, array, or strip configuration; the flip-chip grid defines the legal placement
locations for the I/O drivers. The following sections define the procedure for defining the
flip-chip placement grid, placing flip-chip I/O drivers, and assigning matching types.

Defining the Location for Flip-Chip Drivers

The set_flip_chip_driver_array, set_flip_chip_driver_ring, and
set_flip_chip_driver_strip commands define the legal locations of the driver cells,
whereas the place_flip_chip_drivers command actually places the drivers in the
defined legal locations.
Note:
The set_flip_chip_driver_strip command is preferred over the
set_flip_chip_driver_ring and set_flip_chip_driver_array commands
because it does not require you to specify the maximum driver size. The
set_flip_chip_driver_strip command can handle drivers of different widths.
The set_flip_chip_driver_strip command defines placement locations for flip-chip

drivers in rows or columns within a specified bounding box; the command syntax is
set_flip_chip_driver_strip
-bbox {{llx lly} {urx ury}}
[-driver_orientation N | W | S | E | FN | FS | FW | FE]
[-alignment left | top | right | bottom]
[-matching_type matching_type_list]
[-min_spacing spacing]
[-name strip_name]
If you specify the -matching_type option, bump cells with the same matching type only are
assigned to the drivers. You can rotate or mirror the driver placement by specifying the
-driver_orientation option and align the drivers to the left, right, bottom or top sides of
the bounding box by specifying the -alignment option. For more information about these
options, see the man page.
The following example creates two flip-chip driver strips. The command assigns the "signal"
matching type to the drivers and rotates the drivers by 180 degrees.
icc_shell> set_flip_chip_driver_strip -bbox {{0 0} {200 1000}} \
-driver_orientation S -matching_type {"signal"}
icc_shell> set_flip_chip_driver_strip -bbox {{300 0} {500 1000}} \
-driver_orientation S -matching_type {"signal"}
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
The set_flip_chip_driver_ring command defines the legal locations for flip-chip driver
cells in a ring configuration; the command syntax is as follows.
set_flip_chip_driver_ring
-matching_type {matching_type_list}
-max_driver_size {width height}
-max_driver_num_per_ring number
-min_driver_spacing spacing
-ring_number count
-ring_spacing spacing
-outer_ring boundary_box
[-orientation N | W | S | E | FN | FS | FW | FE]
[-num_extra_spacing count]
[-extra_spacing spacing]
[-stagger_drivers]
[-name ring_name]
Specify which drivers to place in a particular ring by using the -matching_type option; the
command places only the drivers with the specified matching types into the ring. Specify the
maximum width and height of the drivers by using the -max_driver_size option. Specify
the maximum number of drivers per ring by using the -max_driver_num_per_ring option.
Set the spacing between driver cells and the spacing between adjacent rings by using the
-min_driver_spacing and -ring_spacing options respectively. Specify the number of
rings by using the -ring_number option; specify the bounding box that defines the extent of
the outer ring by using the -outer_ring option.
The following example defines a peripheral ring of flip-chip drivers that meets the following
constraints:
• Driver is assigned a "blue" or "green" matching type
• Driver is less than 20 um in width
• Driver is less than 100 um in height
In addition, the command places the flip-chip drivers in two rings, with the outermost ring
bounded by the coordinates {100 100} and {900 900} and a spacing of 15.0 microns
between the two rings. Each ring can contain at most 150 drivers with a minimum spacing
of 1.2 microns between two adjacent drivers of the same ring.
icc_shell> set_flip_chip_driver_ring -ring_spacing 15.0 \
-matching_type {"blue" "green"} -max_driver_size {20 100} \
-max_driver_num_per_ring 150 -min_driver_spacing 1.2 \
-ring_number 2 -outer_ring {{100 100} {900 900}}
The set_flip_chip_driver_array command defines the legal locations for flip-chip driver
cells within an array configuration; the command syntax is as follows.

set_flip_chip_driver_array
-matching_type {matching_type_list}
-max_driver_size {width height}
-start_point {x y}
-dimension {column row}
-delta {x y}
[-orientation N | W | S | E | FN | FS | FW | FE]
[-name array_name]
Restrict the placement of drivers to a particular array by using the -matching_type option.
This technique can be used for multivoltage driver placement. Define the size of the largest
driver by specifying the -max_driver_size option. Specify the driver placement grid by
using the -delta and -dimension options; the -delta option specifies the pitch between
driver cells and the -dimension option specifies the number of columns and rows in the
driver array. Define the starting point at the lower-left corner of the driver array by specifying
the -start_point option.
The following command defines a flip-chip driver array of 2 columns and 20 rows, starting at
coordinate {0 100} on left edge of the die. The spacing between drivers is 60 microns, and
the largest flip-chip driver allowed is 180 microns in width by 60 microns in height:
icc_shell> set_flip_chip_driver_array -max_driver_size {180 60} \
-start_point {0 100} -dimension {2 20} -delta {0 60} \
-matching_type {"blue" "green"}
Placing Flip-Chip Drivers

To place the flip-chip drivers, use the place_flip_chip_drivers command:
place_flip_chip_drivers
[-matching_types {matching_type_list}]
[-pin_alignment]
[-snap_to_grid]
[-swapping_only]
For information about the command options, see the place_flip_chip_drivers man
page.
The place_flip_chip_drivers command places drivers with the io_pad and
flip_chip_driver cell types into legal placement locations specified by the
set_flip_chip_driver_array, set_flip_chip_driver_ring, or
set_flip_chip_driver_strip command. The tool places the drivers and minimizes wire
length; you can use the set_flip_chip_options command to assign different weights to
nets connecting drivers to bump cells and for nets connecting drivers to soft macros.
Place only drivers with a particular matching type by specifying the -matching_types
option. Minimize jogs in the route between the driver cell and the bump cell by specifying the
-pin_alignment option; the tool attempts to align the driver center with the bump center.
Snap the lower-left corner of the driver to the flip-chip grid by specifying the -snap_to_grid
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
option. The flip-chip grid is defined by the set_flip_chip_grid command. Use the
-swapping_only option to optimize the existing driver placement by swapping drivers of the
same size.
Designating a Matching Type for Flip-Chip Drivers

Similar to flip-chip bump cells, you can designate a matching type for a flip-chip driver or
flip-chip driver pin by using the set_matching_type command. Designating a matching
type on a driver pin associates the driver with a bump cell with the same matching type for
better driver placement. See “Designating Matching Types for Bump Patterns” on page A-11
for more information about matching types for flip-chip bump cells. The following example
sets the matching type “power” for the driver cell pad1.
icc_shell> set_matching_type -matching_type {"power"} pad1
The next example sets the matching type “ground” for the pin named PAD on the driver
ppad2.
icc_shell> set_matching_type -matching_type {"ground"} ppad2/PAD
Assigning Nets From Bumps to I/O Drivers

You can perform automatic net assignment by using the assign_flip_chip_nets
command:
assign_flip_chip_nets
[-matching_type matching_type_list]
[-prefix prefix]
[-uniquify num_to_uniquify]
[-multiple_terminal_pins pin_name_or_collection]
[-terminal_layers layer_name_or_collection]
[-terminal_names terminal_name_list]
[-eco]
Automatic net assignment logically connects flip-chip I/O drivers and bump cells. This
process is required because there is no logical connection between driver cells and bump
cells in the Verilog netlist in the die-driven flow. After logical connections are established,
you can route the bump nets between the flip-chip I/O drivers and bump cells.
The -matching_type option defines the list of matching types for the drivers and bumps to
be routed. Based on the current driver placement, the command finds the nearest
unassigned bump with the same matching type and assigns a logical net between the driver
and bump cell. The assign_flip_chip_nets command matches flip-chip bump cells to
drivers by using the shortest wire length method. The bump-to-driver connection net
assignments are updated in the Milkyway database for the die-driven flow.
The tool processes the automatic net assignment between drivers and bump cells based on
the assigned matching types set by using the set_matching_type command. Only drivers

and bump cells of an identical type are matched. Unspecified matching types are not
processed if you use the -matching_type option.
The following example performs automatic net assignment between the drivers and bump
cells assigned the matching type "west". The display_rdl_route_flylines command
displays the flylines between the driver and bump cells.
icc_shell> assign_flip_chip_nets -matching_type {"west"}
icc_shell> display_rdl_route_flylines
The results of the previous command are shown in Figure A-7.

Figure A-7 Flip-Chip Net Assignment
Automatic net assignment can handle various design scenarios, such as a driver cell with
multiple flip-chip pins, or a flip-chip pin with multiple terminals distributed far from each other.
These requirements occur primarily on VDD, VSS, and control pins of macro drivers. Net
assignment can also handle multiple pad pins per I/O driver, such as multiple bump cells
connected to a single I/O driver. For multiple terminal pins, net assignment can assign one
bump cell for each terminal. Net assignment can also handle multiple personality matching
between drivers and bump cells, such as "power" drivers to "power" bump cells and "signal"
drivers to "signal" bump cells. If the ports of a group of drivers are connected by the same
net, such as a VDD net, net assignment can create unique nets and assign a one-to-one
connection between each bump and each flip-chip driver port. Net assignment can also
create a many-to-one connection between a single bump and multiple flip-chip driver ports.
The following command performs a multiple-terminal-aware net assignment.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
icc_shell> assign_flip_chip_nets -matching_type "east" \

-multiple_terminal_pins DI/*
The following example performs one-to-one driver-to-bump matching. The

assign_flip_chip_nets command supports multiple uniquify modes; for more information
see the man page.
icc_shell> assign_flip_chip_nets -uniquify 1
Merging Multiple Flip-Chip Nets

You can merge multiple flip-chip nets into a single net by using the merge_flip_chip_nets
command:
merge_flip_chip_nets
-from from_nets
-to to_net
[-update_routing]
The merge_flip_chip_nets command disconnects all pins, I/O ports, and terminals from
a specified collection of flat nets and reconnects them to the newly merged net. Use the
-from option to specify the collection of nets to merge; the -to option specifies the new
name for the merged net. You should use the -update_routing option if you use the
merge_flip_chip_nets command after flip-chip redistribution layer routing.
The following command merges all nets that begin with the string VDD, such as VDD,
VDD_1, VDD_2, and VDD_3, into the single VDD net:
icc_shell> merge_flip_chip_nets -from [get_flat_nets VDD* -all] \
-to VDD -update_routing
Reporting Crossover Nets

To report crossover nets, use the report_flip_chip_flyline_cross command. The
report_flip_chip_flyline_cross command checks crossover net assignment and
determines if the flyline between a driver cell and a bump cell crosses any other flylines
between other driver cells and bump cells. If one net consists of multiple drivers and bump
cells, each net segment is tested against other driver cell and bump cell flylines.
The report generated by the report_flip_chip_flyline_cross command contains a list
of net pairs that cross each other; Example A-1 shows an example report.

Example A-1 report_flip_chip_flyline_cross Example

icc_shell> report_flip_chip_flyline_cross
******************************
Report : flyline cross
Design : chip1
Version: E-2010.12
******************************
----------------------------------------------------------------
The following net pairs cross each other

net1 net2
REG_ADDR_1[5] REG_ADDR_1[4]
TE1_ON_3 TE2_ON_3
DATA_2[28] REG_DATA_2[29]
REG_DATA_3[30] IDLE_3
REG_ADDR_3[1] REG_ADDR_3[2]
REG_DATA_2[9] REG_DATA_2[8]
R_TMU0_ON_2 R_TMU1_ON_2
PE_CLK_4 RESET_4
FE_CLK_4 BUSY_4
Total 9 crossing!
----------------------------------------------------------------
Using a Package-Driven Flip-Chip Flow

In a package-driven flow, the bump cells are imported and placed at physical locations
predefined by the flip-chip package designer. A design processed in the package-driven flow
has the following properties:
• The bump cells locations are defined in Design Exchange Format (DEF) or Advanced
Input Format (AIF) files.
• The bump cells instances, I/O driver instances, and the net connectivity between the
bump cells and I/O drivers are defined in the Verilog netlist.
• The I/O drivers are placed as close as possible to their associated bump cells.
• After the bump cells and I/O drivers are placed and the connectivity is defined, the
redistribution layer routes are created to connect the bump cells to the I/O drivers.
Figure A-8 shows the package-driven flip-chip flow.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Using a Package-Driven Flip-Chip Flow A-19
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure A-8 Package-Driven Flip-Chip Flow
Setup library
Create floorplan
Import bump locations
Define flip-chip driver locations
Designate driver matching type
Define flip-chip grid
Set flip-chip options
Place I/O drivers
Route redistribution layer Optional steps
Related Topics:
• Importing Bump Locations
• Saving Bump Cell Information
• Defining Flip-Chip Driver Locations
• Designating the Driver Matching Type
• Defining the Flip-Chip Placement Grid
• Setting Options for Flip-Chip Driver Placement
• Placing Flip-Chip Drivers

Importing Bump Locations

You can import bump locations in DEF or AIF format. To import them in DEF format, use the
read_def command as described in “Reading DEF Files” on page 2-30. To import bump
locations in AIF format, use the read_aif command:
read_aif
[-pad_to_ref_lib {{ pad_type ref_name N | S | E | W } {...}}]
[-ignore_assign_nets]
file_name
In a package-driven flow, bump cells are imported and placed in predefined physical
locations per the requirements of the flip-chip package. The read_aif command reads the
bump locations from an AIF file. Use the -pad_to_ref_lib option to remap the cell
reference in the AIF file. You can also change the orientation of the cell by specifying the S,
E, or W keyword. To place the bump cells without connecting them, specify the
-ignore_assign_nets option.
Example A-2 shows an AIF file that specifies bump cell locations for a design. Note that the
bump cell location coordinate {0 0} in an AIF file references the center of the die, while the
coordinate {0 0} in the tool refers to the lower-left die boundary.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Example A-2 Example AIF File

[DATABASE]
TYPE=AIF
VERSION=2.0
UNITS=UM
[DIE]
NAME=design
WIDTH=3230.000000
HEIGHT=2183.400000
[PADS]
PAD1 = POLY 16.570,40.000 40.000,16.570 40.000,-16.570
16.570,-40.000 -16.570,-40.000 -40.000,-16.570
-40.000,16.570 -16.570,40.000 16.570,40.000
PAD2 = SQUARE 40
PAD3 = RECT 60 20
[NETLIST]
;Netname Pad# Type Pad_X Pad_Y Ball#
net[00] PAD_0 PAD1 -1125.0000 -601.7000

net[01] PAD_1 PAD1 -825.0000 -601.7000
net[02] PAD_2 PAD1 -525.0000 -601.7000
net[03] PAD_3 PAD1 -225.0000 -601.7000
net[04] PAD_4 PAD1 75.0000 -601.7000
net[05] PAD_5 PAD1 375.0000 -601.7000
net[06] PAD_6 PAD1 675.0000 -601.7000
net[07] PAD_7 PAD1 975.0000 -601.7000
net[08] PAD_8 PAD1 -1125.0000 -301.7000
net[09] PAD_9 PAD1 -825.0000 -301.7000
net[10] PAD_10 PAD1 -525.0000 -301.7000
...
net[28] PAD_28 PAD2 -525.0000 -1.7000
net[29] PAD_29 PAD2 -225.0000 -1.7000
...
net[38] PAD_38 PAD3 675.0000 598.3000
net[39] PAD_39 PAD3 975.0000 598.3000

Figure A-9 shows the layout after importing the AIF file shown in Example A-2.
Figure A-9 Imported Bump Cells
Saving Bump Cell Information

You can write bump cell information, including the locations and net connections, to a DEF,
AIF, or Tcl file by using the write_def, write_aif, or write_floorplan command
respectively. Specify the name of the output file as an argument to the write_aif
command; there are no other command options. The following example writes the current
bump cell net connection, cell, and orientation information to the design.aif file.
icc_shell> write_aif design.aif
For more information about writing the floorplan information to a DEF or Tcl file, see “Writing
the Floorplan File” on page 2-27.
Defining Flip-Chip Driver Locations

You must define the legal locations for flip-chip driver placement. See “Defining the Location
for Flip-Chip Drivers” on page A-13 for information about defining the legal locations by
using the set_flip_chip_driver_strip, set_flip_chip_driver_ring, and
set_flip_chip_driver_array commands.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Designating the Driver Matching Type

I/O drivers and bump cells are associated by driver type. The tool assigns connections
between individual I/O drivers and bump cells based on matching type. Use the
set_matching_type command to designate matching types for both I/O drivers and bump
cells as described in “Designating a Matching Type for Flip-Chip Drivers” on page A-16.
Defining the Flip-Chip Placement Grid

You can define a flip-chip driver placement grid with the set_flip_chip_grid command:
set_flip_chip_grid
-grid_origin {x y}
-x_step x
-y_step y
Note that the flip-chip placement grid is not the same as the standard cell row and column
grid. Use the set_flip_chip_grid command to define the flip-chip placement grid by
setting the minimum array pitch for flip-chip driver placement. Set the origin of the grid by
specifying the -grid_origin option; set the horizontal and vertical grid spacing by
specifying the -x_step and -y_step options.
The following example specifies a flip-chip grid with a grid origin at (0,0) and a grid spacing
of 0.1 microns in both the x- and y-directions.
icc_shell> set_flip_chip_grid -grid_origin {0 0} \
-x_step 0.1 -y_step 0.1
Setting Options for Flip-Chip Driver Placement

You can set flip-chip driver placement options by using the set_flip_chip_options
command:
set_flip_chip_options
[-disable_driver_placement]
[-package_driven]
[-one_softmacro_per_island]
[-flip_chip_net_weight weight]
[-softmacro_net_weight weight]
[-signal_net_weight weight]
[-guardband_width {x y}]
[-multiple width | height | both]
Enable placement of flip-chip drivers based on fixed-bump location constraints by specifying

the -package_driven option. When multiple width or height flip-chip drivers are placed, you
can specify the -multiple option to allow the driver to consume more than one slot. See
the man page for additional options.

Placing Flip-Chip Drivers

To place the flip-chip drivers, use the place_flip_chip_drivers command. The
command places drivers with the “IO Pad” cell type into legal placement locations specified
by the set_flip_chip_driver_array, set_flip_chip_driver_ring, or
set_flip_chip_driver_strip command. The tool places the drivers and minimizes wire
length; you can use the set_flip_chip_options command to assign different weights for
nets connecting drivers to bump cells and for nets connecting drivers to soft macros. For
more information about the place_flip_chip_drivers command, see “Placing Flip-Chip
Drivers” on page A-15.
Routing Flip-Chip Bumps

Bump net routing, also referred to as redistribution layer (RDL) routing, redistributes the
wire-bonding pads to the bump pads without changing the placement of the I/O pads.
Typically, bump nets are routed on the top metal layer of the die.
Figure A-10 shows a cross section of redistribution layer routing.
Figure A-10 Cross Section Showing Redistribution Layer Routing
Note:
For peripheral I/O flip-chip design styles, single-layer routing on the top metal layer is
preferred. In addition, single-layer routing on the top metal layer minus one level
(dual-layer routing) is also allowed when necessary.
Figure A-11 describes the flow for performing redistribution layer routing.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Routing Flip-Chip Bumps A-25
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure A-11 Flip-Chip RDL Routing Flow

Specify RDL routing rules and options
define_routing_rule
set_net_routing_rule
set_route_rdl_options
Perform RDL global routing

route_rdl_flip_chip
Analyze RDL global routing

display_rdl_route_flylines
Perform RDL detail routing

route_rdl_flip_chip
Resolve RDL routing congestion

remove_route_by_type
push_rdl_route
Perform incremental routing

route_rdl_flip_chip
Optimize route pattern

optimize_rdl_route
See Also
• Specifying Redistribution Layer Routing Rules
• Performing Redistribution Layer Global Routing
• Analyzing Redistribution Layer Routing
• Performing Redistribution Layer Detail Routing
• Resolving Redistribution Layer Routing Congestion
• Performing Incremental RDL Routing and Route Optimization
• Writing Flip-Chip Nets to a File
• Creating Stacked Vias on Pad Pins

Specifying Redistribution Layer Routing Rules

Before routing the redistribution layer, you must set routing rules and options for the RDL
router. To set the RDL routing rules and options,
1. Define the routing rules with the define_routing_rule command
icc_shell> define_routing_rule rdl_routing \
-widths {M8 0.1 M9 0.1} -spacings {M8 0.1 M9 0.1}
The preceding command creates a new routing rule called rdl_routing for the M8 and M9
layers. The width and spacing values are set to 0.1 microns.
2. Apply the routing rule to the redistribution layer nets
icc_shell> set_net_routing_rule \
-rule rdl_routing {flip_chip_nets}
3. Specify the redistribution layer routing options
icc_shell> set_route_rdl_options \
-layer_bump_spacings {M8 2.5 M9 5} \
-layer_routing_angles {M8 45_degree M9 45_degree}
The preceding command sets the bump spacing at 2.5 microns for the M8 layer and 5
microns for the M9 layer, and specifies a routing angle of 45 degrees for both M8 and M9
layers.
The define_routing_rule command defines design-specific, nondefault routing rules that

are stored in the design database. For more information about the define_routing_rule
command, see the man page and the IC Compiler Implementation User Guide.
Performing Redistribution Layer Global Routing

The tool provides a redistribution layer router which supports 45- and 90-degree routing,
two-layer routing, automatic via creation, and both global and detail routing. To perform
redistribution layer global routing, route the redistribution layer with the
route_rdl_flip_chip command and -skip_detail_route option as follows:
icc_shell> route_rdl_flip_chip -skip_detail_route true \
-auto_via true -layers {M8 M9}
The -skip_detail_route true option directs the command to perform only global
redistribution layer routing and skip detail routing. The -auto_via true option inserts vias
while creating the redistribution layer routes. Alternatively, you can insert redistribution layer
vias in a separate step by specifying -auto_via false and using the
create_stack_via_on_pad_pin command to insert the vias.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Analyzing Redistribution Layer Routing

After performing redistribution layer global routing, use the display_rdl_route_flylines
command to visually inspect the redistribution layer routing result. The
display_rdl_route_flylines command displays a flyline between the driver and bump
cell for each redistribution layer net. View the flylines in the layout window to identify flyline
crosses that might be difficult to route. Alternatively, you can use the -open_nets option to
display flylines for all unrouted flip-chip nets as follows:
icc_shell> display_rdl_route_flylines -open_nets
Figure A-12 shows the layout after running the command.

Figure A-12 Flyline Showing an Open Flip-Chip Net
You can also display a list of flip-chip flylines that are crossed by using the
report_flip_chip_flyline_cross command. For more information see “Reporting
Crossover Nets” on page A-18.
Performing Redistribution Layer Detail Routing

After performing redistribution layer global routing and analyzing the routing result, use the
route_rdl_flip_chip command with the -reuse_existing_global_route true option
to perform redistribution layer detail routing as follows:
icc_shell> route_rdl_flip_chip -reuse_existing_global_route true \
-layers {M8 M9}
The -reuse_existing_global_route option skips global routing and reuses the existing
global routes when creating detail routes.

Resolving Redistribution Layer Routing Congestion

To adjust the redistribution layer routing to resolve routing congestion, use the
remove_route_by_type and push_rdl_route commands.
icc_shell> remove_route_by_type -nets {sd[0] sd[1]}
icc_shell> push_rdl_route -layer M9 -mode net -direction up \
-nets {sd[2]}
The remove_route_by_type command reduces redistribution layer routing congestion by

removing the specified routes from the design. To specify the routes to remove, use the
-nets option.
The push_rdl_route command moves redistribution layer routes based on the command
options you specify. To create additional space around a specified route, use the
push_rdl_route -layer layer -mode neighbor -nets target_net command, where
target_net is the net around which to create space. To control the number of redistribution
layer routes to move, specify the -sweep_range n option, where n is the number of nets to
move on each side of the target net. By default, the command moves 10 nets on each side
of the target net.
To move a specified route up, down, left, or right, use the push_rdl_route -layer layer
-mode net -nets target_net -direction up|down|left|right command. The tool
moves the net until the net is blocked by a routing obstruction or the net meets the bounding
box defined by the -bounding_box option.
Figure A-13 shows the layout result after running the push_rdl_route -layer layer
-mode net -nets target_net -direction down command. The dashed line represents
the original flip-chip net route.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure A-13 Flip-Chip Route Pushed in Down Direction
Original flip-chip route
Flip-chip route after

push
Performing Incremental RDL Routing and Route Optimization

After performing the initial detail redistribution layer routing and resolving route congestion,
you can further refine and optimize the redistribution layer routing. The tool provides the
create_rdl_power_extension, optimize_rdl_route, push_rdl_route,
route_rdl_differential, route_rdl_flip_chip, and split_rdl_route commands to
further optimize redistribution layer routing. This section describes several example
optimizations.
To move existing RDL routes and create additional routing channels for RDL power and
ground signals, use the optimize_rdl_route command with the
-reserve_power_resources option. Figure A-14 shows the layout before and after running
the following command:
icc_shell> optimize_rdl_route -layer {M9} -reserve_power_resources

Figure A-14 RDL Routing Before and After Optimization With -reserve_power_resources
To split one or more RDL routes into narrow, parallel routes, or copy RDL routes to adjacent
layers, use the split_rdl_route command. Command options control the width, spacing,
and layer destination of the parallel routes.
The following example splits the RDL route for net sd[3] into parallel routes with a width of 5
microns for each new route.
icc_shell> split_rdl_route -nets {sd[3]} -widths {M9 {5}}
The following example copies RDL net PAD_NET2 from layer M9 to layer M8 and inserts
vias every 30 microns.
icc_shell> split_rdl_route -nets {PAD_NET2} -mode adjacent_layer \
-from_layers {M9} -to_layers {M8} -via_interval 30
To create new RDL routes of the same length for up to 16 different RDL nets, or to modify
existing RDL routes, use the route_rdl_differential command. The following example
uses the route_rdl_differential command to modify existing RDL routes for nets sd[0]
and sd[3]. The command updates the RDL routes to create net shapes of the same length.
icc_shell> route_rdl_differential -layers {M9 M8} \
-nets {sd[0] sd[3]}
Figure A-15 shows the layout before and after running the route_rdl_differential
command. The nets are now the same length in the image on the right.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure A-15 Before and After route_rdl_differential
To widen the power and ground RDL nets to fill the available space between other RDL nets
and bump cells, use the create_rdl_power_extension command. The command avoids
creating DRC violations on the newly widened nets. You can also use this command to
remove widened RDL nets to power and ground pads if the nets were created earlier by the
create_rdl_power_extension command. The following example removes any existing
widened RDL nets created by the create_rdl_power_extension command on layer M9.
The second command creates new, widened nets to RDL power and ground bump cells on
layer M9 where space is available.
icc_shell> create_rdl_power_extension -layer M9 -mode remove
1
icc_shell> create_rdl_power_extension -layer M9 -mode new
Power Net: VDD
Ground Net: VSS
1
The create_rdl_power_extension command supports several options to modify RDL

power extensions. Use the -bbox {{x1 y1} {x2 y2}} option to extend or remove the RDL
power nets only within a specified bounding box. Use the -remove_nets nets option to
remove the specified RDL power extensions. You can combine the -bbox and
-remove_nets options to remove RDL power extensions only within a specified area.
Use the -width_variation {variation length} option to control the change in wire
width within the specified length of the RDL route. If you set the variation to zero, the tool
creates the RDL extension such that the wire maintains the same width throughout the route
extension, or decreases in width, but does not increase and decrease in width. Use the
-from_previous_extension true option to create an RDL power extension by connecting
to an existing extension.
Figure A-16 shows the layout result after specifying create_rdl_power_extension
-width_variation {1 20}. The option specifies that the width for the RDL routing net can
decrease by one micron for every 20 microns of route length.

Figure A-16 RDL Power Net Width Variation
Writing Flip-Chip Nets to a File

You can create a file containing the list of flip-chip nets in the current design by using the
write_flip_chip_nets command. Use the -file_name option to specify the output file
name. The contents of the output file can be used to create a list of target flip-chip nets to
route with the route_rdl_flip_chip command.
The following command writes the flip-chip nets to the bump_net_list file.
icc_shell> write_flip_chip_nets -file_name bump_net_list
Dumping successfully.
Creating Stacked Vias on Pad Pins

The create_stack_via_on_pad_pin command creates stacked vias between two
specified design layers to enable a connection between a flip-chip driver and a flip-chip pad.
Stacked vias connect the pad pins on the redistribution layer to lower layers of metal in your
design. Define the layers to be connected by specifying the -from_metal and -to_metal
options. When creating the stacked via, the command determines the size of the stacked via
based on the nondefault width routing rule and shape of the pad pin. The command finds the
largest pin shape for placing the via that does not cause a DRC violation. You must create
stacked vias before routing the flip-chip nets by using the route_rdl_flip_chip
command.
The following command creates stacked vias between the M6 layer and the M8 layer.
icc_shell> create_stack_via_on_pad_pin -from_metal M6 -to_metal M8
Created stack vias on 99 pad pin(s).
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
If you do not specify the -from_metal option, the command automatically searches for the
pin that is closest to the top layer and creates a stacked via on the pin. If there is inadequate
space to create a stacked via on the closest pin, the command searches for the next closest
pin. If you do not specify the -to_metal option, the command uses the top metal layer as
the redistribution layer.
If an object blocks the access to a pad pin, you can create an extension wire to connect the
pad pin and the stacked via. The -extend_layer, -min_length, and -max_length options
specify the layer on which to create the extension wire and the minimum and maximum
length for the extension wire. After creating the stacked via, the tool checks that the
extension wire meets the constraint specified by the -min_length and -max_length
options.
The following example creates a stacked via and an extension wire between the via and the
pad pin. The extension wire is created on the M8 layer and is between 10 and 100
technology file units in length.
icc_shell> create_stack_via_on_pad_pin -min_length 10 \
-max_length 100 -extend_layer M8
Figure A-17 shows the results of the preceding command on four different pad pins.
Figure A-17 Stacked Vias
Before After
create_stack_via_on_pad_pin create_stack_via_on_pad_pin

Using Flip-Chip Structures in Cover Macros

The IC Compiler tool supports flip-chip bump and cover cells in the logical netlist. You can
describe the logical connectivity between the flip-chip bump pads, cover cells and the I/O
drivers in the Verilog netlist.
You can change the flip-chip bump and cover cells from physical-only cells to become part
of the logical netlist by setting the following variable to true.
icc_shell> set_app_var disable_bump_cover_as_physical_only true
Setting this variable to the default of false treats bump and cover cells as physical-only
cells.
Creating RDL Net Shielding

You can create shielding wires to provide additional signal integrity around RDL nets. Before
inserting the shield nets, you must ensure adequate routing resource for the shield and
create a routing rule for the shield. To create shielding for RDL nets,
1. Define the routing rules with the define_routing_rule command.
The following command creates a new routing rule called rdl_net_shielding for the M9
layer. The width, spacing, shield width and shield spacing values are each 5 microns.
icc_shell> define_routing_rule rdl_net_shielding \
-widths {M9 5} -spacings {M9 5} -shield \
-shield_widths {M9 5} -shield_spacings {M9 5}
2. Specify the target nets for shielding with the set_net_routing_rule command.
icc_shell> set_net_routing_rule \
-rule rdl_net_shielding {sd[0] sd[1] sd[2] sd[3]}
3. Assign the net to connect to the shield with the set_route_rdl_options command. By
default, the RDL router uses the ground net with the largest number of ports as the
shielding net. This example also sets the width of the strap that connects the shield to the
VSS net or bump cell.
icc_shell> set_route_rdl_options -layer_bump_spacings {M8 2.5 M9 5} \
-shielding_net VSS -connect_edge_center false \
-layer_tie_shield_widths {M9 5}
4. Route the RDL nets.

icc_shell> route_rdl_flip_chip -layers M9 \
-nets {sd[0] sd[1] sd[2] sd[3] sd[4]}
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Using Flip-Chip Structures in Cover Macros A-35
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
5. (Optional) If the RDL routes require further optimization, use the push_rdl_route and
optimize_rdl_route commands to refine the layout.
6. Create the RDL net shields with the create_rdl_shield command.

icc_shell> create_rdl_shield -layers M9 \
-nets {sd[0] sd[1] sd[2] sd[3]} -shield_routing_tie true \
-shield_via_tie true -trim_floating false
...
Shielded 76% side-wall of (sd[3]) in layer M9
Shielded 10 nets in layer M9 with average ratio as follows
1) 94.00% (total shield ratio/number of shielded nets)
2) 97.55% (total shield length/total shielded net length)
1
Figure A-18 shows a bump cell and RDL route before and after adding the shield.
Figure A-18 RDL Net Before and After Shielding
Figure A-19 shows two different design implementations that contain tie straps; the left
image uses a tie strap width of 5 microns, and the right image uses a tie strap width of 15
microns.

Creating RDL Net Shielding A-36
Figure A-19 RDL Net With Two Different Tie Shield Widths
set_route_rdl_options \ set_route_rdl_options \
-layer_tie_shield_widths {M9 5} -layer_tie_shield_widths {M9 15}
The define_routing_rule command defines design-specific, nondefault routing rules that

are stored in the design database. For more information about the define_routing_rule
command, see the man page and the IC Compiler Implementation User Guide.
The set_net_routing_rule command assigns a routing rule to a set of nets. The
set_route_rdl_options command sets options for RDL routing. After setting the RDL
route options with the set_route_rdl_options command, you can report the settings with
the report_route_rdl_options command. The route_rdl_flip_chip command routes
RDL nets by using the RDL router.
The create_rdl_shield command creates shields around the specified RDL nets. Use the
-mode new option to create new shields for unshielded nets. Use the -mode unshield
option to remove existing shields from the design. Use the -mode reshield option to
remove existing shields and create new shields. Use the -shield_on_bump option to
specify whether shields are added to the bump cell or not. Use the -shield_via_tie option
to specify whether vias are added to the shields or not when connecting the shield to power
or ground. Use the -shield_routing_tie option to specify whether to tie shielding wires
with RDL routes. Use the -trim_floating option to specify whether to remove floating net
shapes that are part of the shield. The spacing, width, and other parameters of the net shield
are specified by the define_routing_rule command.
The create_rdl_shield command reports several metrics for the net shields created by
the command. For each net, the command reports the length of the net shield coincident to
the target net, divided by the length of the target net. A fully shielded net has 100% sidewall
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Creating RDL Net Shielding A-37
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
coverage. The command also reports the average shielding ratio for the shielded nets, and
the total shield length divided by the total shielded net length.
In the previous example, the create_rdl_shield command reported the following shield
coverage for net sd[3]:
Figure A-20 shows the pad connection for net sd[3]. Note that an obstruction prevented the
tool from completely surrounding the target net with a shield. Use the push_rdl_route and
optimize_rdl_route commands to adjust the layout to create additional routing resources
for net shields.
Figure A-20 Shield With Obstruction
Creating Tapered Routes

The tool provides support for RDL route tapering. You can apply RDL route tapering to
create narrower routes and improve the routability in designs with closely spaced pins or
limited routing resources on the RDL routing layer. To control RDL route tapering, specify
the -rdl_taper_distance and -rdl_taper_widths options with the
define_routing_rule command. The -rdl_taper_distance option sets the maximum
length in microns for tapered wires, and the -rdl_taper_widths option specifies pairs of
layer names and tapered route widths. These settings are also honored by the
push_rdl_route and optimize_rdl_route commands.
You can also control the type of endcap that is used to connect the RDL route to the pad or
vias. Use the -connect_pad_without_endcap option with the set_route_rdl_options
command to specify whether the tool inserts a tapered endcap or creates the connection
without an endcap. This setting is also honored by the push_rdl_route and
optimize_rdl_route commands.

Creating Tapered Routes A-38
Connecting Floating Bump Cells to Ring Nets

If your design contains floating bump cells, you can connect them to power or ground ring
nets during RDL routing. Specify the -route_to_ring_nets option with the
set_route_rdl_options command before running the route_rdl_flip_chip command
as shown in the following example. This option directs the router to connect the floating
bump cells to the outermost ring net you specify and create vias between the RDL nets and
the ring nets.
icc_shell> set_route_rdl_options -route_to_ring_nets {VDD VSS}
1
After setting the RDL routing option, verify the option setting with the
report_route_rdl_options command. The report displays the nets specified by the
set_route_rdl_options -route_to_ring_nets command.
icc_shell> report_route_rdl_options
****************************************
Report : report_route_rdl_options
Version: J-2014.09
Date : Wed Aug 13 16:04:49 2014
****************************************
----------------------------------------
RDL routing options:
----------------------------------------
...
Route to ring Nets: VDD VSS
Summary of the Flip-Chip Commands

Table A-1 provides a summary of the flip-chip commands. For more information, see the
appropriate man pages.
Table A-1 Summary of Flip-Chip Commands
Command Description
assign_flip_chip_nets Creates or reconnects nets between flip-chip

I/O drivers to bump cells.
create_stack_via_on_pad_pin Creates stacked vias for the I/O drivers from

the pad layer to the top metal layer for flip-chip
routing.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
Connecting Floating Bump Cells to Ring Nets A-39
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Table A-1 Summary of Flip-Chip Commands (Continued)
Command Description
display_rdl_route_flylines Displays the flylines for the specified

45-degree redistribution layer (RDL) nets in
the layout window of the IC Compiler GUI.
expand_flip_chip_cell_locations Proportionally expands or shrinks the relative

locations of the selected flip-chip bump or
driver cells.
get_rdl_nets Creates a collection of 45-degree RDL nets

that match the specified criteria.
merge_flip_chip_nets Disconnects pins, I/O ports, and terminals

from a specified collection of flat nets and
reconnects them to the newly merged net.
optimize_rdl_route Optimizes the 45-degree RDL routing

patterns.
place_flip_chip_array Creates the specified number of flip-chip

bump cells and places them in a
two-dimensional array pattern.
place_flip_chip_ring Creates the specified number of flip-chip

bump cells and places them in a ring
configuration.
push_rdl_route Moves the specified 45-degree RDL nets in a

specified direction or away from the specified
nets.
read_aif Reads the flip-chip bump locations from an

Advanced Input Format file.
remove_flip_chip_route Removes the specified flip-chip wires, paths,

and contacts to resolve routing congestion.
report_flip_chip_bump_attributes Reports the attributes set on the flip-chip

bump cells for flip-chip routing.
report_flip_chip_driver_bump Prints a table of bump cells and

corresponding nets and drivers.
report_flip_chip_flyline_cross Generates a report that lists flip-chip net pairs

that cross.

Summary of the Flip-Chip Commands A-40
Table A-1 Summary of Flip-Chip Commands (Continued)
Command Description
report_route_rdl_options Reports the RDL route settings specified by

the set_route_rdl_options command.
route_rdl_flip_chip Routes flip-chip nets to connect flip-chip I/O

drivers and bump cells using the 45-degree
RDL router.
set_flip_chip_bump_attributes Sets attributes on flip-chip bump cells for

flip-chip routing.
set_flip_chip_cell_site Modifies flip-chip driver cell site properties to

set different flip-chip driver legal location
constraints.
set_flip_chip_driver_array Defines the legal locations for flip-chip driver

cells to be placed in an array configuration.
set_flip_chip_driver_island Defines the flip-chip cell sites that form the

legal locations for the flip-chip drivers to be
placed in an island style. This command
cannot be used together with the
place_flip_chip_drivers command.
set_flip_chip_driver_ring Defines the legal locations for flip-chip driver

cells to be placed in a ring configuration.
set_flip_chip_driver_strip Defines the legal locations for flip-chip driver

cells to be placed in a strip configuration.
set_flip_chip_grid Creates equally-spaced grid points for

flip-chip driver placement.
set_flip_chip_options Sets general flip-chip driver placement

options.
set_matching_type Assigns the specified matching type to the

specified I/O drivers, bump cells or pins.
set_route_rdl_options Defines RDL router options.
update_flip_chip_pin_locations Updates the flip-chip bump I/O pin locations

for timing analysis.
write_flip_chip_nets Writes all bump to pad net names into a file.
AppendixA:A:Using
Chapter Usingthe
theFlip-Chip
Flip-ChipFlow
Flow
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

B
Data Flow Analyzer B
The GUI provides tools to analyze and improve the data flow through the physical design. If
your initial macro placement results in areas of high congestion, you can use the data flow
analysis window to perform the following tasks:
• View macro connections based on logic data flow by using logic connectivity analysis.
You can browse through the logic modules in the design hierarchy and examine the
relative sizes of the modules and the connectivity between them. You can also select
macros and physical nets that you want to examine in the layout view.
• Identify the flow of data by examining macro connectivity with advanced flyline analysis.
You can trace macro-to-macro and macro-to-I/O connections through standard cells.
You can also examine the traced connections and their characteristics by viewing flylines
from selected macro cells or I/O ports in the layout view.
• Modify macro placement, create and customize macro relative placement groups, and
copy macro array placement layouts by using interactive macro editing.

• Starting the Data Flow Analysis Tool
• Expanding and Merging Logic Modules
• Moving and Reshaping Modules
• Saving and Loading Expanded Modules
B-1
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
• Examining Hard Macro Placement

• Examining Net Connectivity
• Tracing Macro and I/O Connections
• Reporting Module Connection Details
• Highlighting Registers in Macro-to-Macro Paths
• Setting Placement Gravity for Modules
• Editing Macro Arrays
• Editing Macro Placement in the Layout View
• Copying Macro Placement
• Setting Macro Group Constraints
• Closing the Data Flow Analysis Window
• Configuring the CDE Desktop for DFA
• Data Flow Analysis Control Center Reference
Appendix B: Data Flow Analyzer

B-2
Starting the Data Flow Analysis Tool

After you finish placing the macros by using the create_fp_placement command, you can
use the Data Flow Analyzer to perform data flow analysis.
To start data flow analysis, choose Floorplan > Analyze Logic Connectivity in the GUI.
Alternatively, you can use the analyze_logic_connectivity command.
The DFA Control Center panel opens in the layout window. In the initial view, the layout
window shows the _TOP_ module object block beside the standard layout. The _TOP_
module represents the top-level of the design. The DFA Control Center panel contains tabs
which organize common tasks for data flow analysis. A brief description of the functions
available in each tab is described in “Data Flow Analysis Control Center Reference” on
page B-27. Common DFA operations are described in the following sections. Figure B-1
shows the layout window with the Data Flow Analysis tool active; in this example the
top-level module object block is expanded and a macro is selected.
Figure B-1 Data Flow Analysis View
DFA
Control Center
Tabs
Actions
Module Object
Blocks
Block-to-Block
Connections
Block-to-I/O
Connections
Macro-to-Macro
Flylines
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Starting the Data Flow Analysis Tool B-3
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Note that you should not save your design with the save_mw_cel command while DFA is
active. To save your design, first exit DFA by choosing File > Exit DFA from the DFA Control
Center, then use the save_mw_cel command to save your design.
Expanding and Merging Logic Modules

You begin data flow analysis by expanding the top module object block in the layout view.
After expanding the block, the tool hides the currently selected block and displays the child
modules within the next level of hierarchy. You can expand any module that contains child
modules and merge child modules back into their parent module. After merging the block
into the parent, the child module is hidden and the parent is displayed if it is not already
visible.
To expand the top level based on the number of hard macros or module area percentage,
1. Choose Tools > Auto hierarchy detection from the DFA Control Center.
2. Enter the minimum and maximum number of macros that are contained within each
block.
3. Enter the minimum and maximum module area percentage for each block.
4. Select Count OR Area, or Count AND Area, to use either or both count and area
constraints during module detection.
5. Click OK to perform hierarchy detection and expand the modules.
6. Click Close to close the dialog box.
The tool searches the design hierarchy and displays module object blocks for the modules
that meet your specified criteria.
You can also expand blocks by selecting them in the GUI. To expand individual module
object blocks,
1. Select the block by clicking inside the block. The block outline changes to a dashed line.
2. Choose Actions > Expand all children from the DFA Control Center, or click the right
mouse button and select Expand All Children from the context menu.
Figure B-2 shows the layout window before and after selecting the top module object block
and expanding the child modules.

Expanding and Merging Logic Modules B-4
Figure B-2 Before and After Expanding Child Modules
Module object blocks for black boxes are displayed with a dashed line. Each module object
block for a black box is labeled LBB for a logical black box or PBB for a physical black box.
Figure B-3 shows a design with four module object blocks displayed; two of the blocks are
black boxes. The lower-left block is a physical black box, and the lower-right block is a
logical black box.
Figure B-3 Data Flow Analysis With Black Boxes
To merge child modules into their parent module,

1. Select one or more module object blocks.
2. Choose Actions > Merge module(s) to parent from the DFA Control Center, or right-click
select “Merge Module(s) to Parent” from the context menu.
Alternatively, you can merge all modules into the top level by choosing Actions > Merge all
module(s) to top from the DFA Control Center.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Expanding and Merging Logic Modules B-5
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Moving and Reshaping Modules

You can rearrange and reshape the module object blocks in the layout view to better view
flylines and other information about the blocks. To move and reshape a module object block,
1. Select the move tool from the toolbar.
2. Select the module object block and drag it to the new location.
3. Hold the mouse over the boundary of the module object block, then drag the edge to
resize the block.
Saving and Loading Expanded Modules

You can save the current shapes, locations, and groups of the module object blocks to a text
file, and restore the same information from a text file. The tool also writes any notes
associated with the blocks to the file. To save the module shapes and locations,
1. Arrange the module object blocks by moving and reshaping them.
2. Choose File > Save modules to a file from the DFA Control Center.
3. Enter the file name and click OK.
To restore the module shape, location, group, and note information, Select File > Load
modules from a file and select a file you saved previously. The tool restores the shape and
location information, and attaches the notes to the module object blocks.
Examining Hard Macro Placement

You can use the tool to examine the logic modules that contain hard macros, their
hierarchical relationships, and the placement patterns of their macros in the layout view.
By default, the data flow viewer displays the module instance name on each expanded
module. You can display the number of hard macros and utilization for each module object
block in addition to the instance name. You can also view detailed information about each
module.
To display the number of hard macros in each expanded module, choose Settings > Show
module info in the DFA Control Center. Figure B-4 shows the layout view after enabling the
“Show module info” option. Additional information about a module object block is available
by moving your mouse cursor over the block to display the InfoTip.

Moving and Reshaping Modules B-6
Figure B-4 Module Object Blocks With Macro Count
To display the macros within a module object block,

1. Select the module object block.
2. Choose Actions > Macros of selected modules in the DFA Control Center.
3. Choose Settings > Mirror hierarchy colors to color the module object block the same
color as the macros.
The tool uses the current hierarchy color to highlight the macros. In Figure B-5, the mirror
hierarchy colors setting is also active.
Figure B-5 Show Macros of Selected Blocks
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Examining Hard Macro Placement B-7
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
To change the hierarchy color of the hard macros in the currently selected block, choose
Actions > Set hierarchy color in the DFA Control Center. If you enabled the “Mirror hierarchy
colors options” in the Settings tab, the tool also changes the color of the module object
block. Figure B-6 shows that layout after enabling “Mirror hierarchy colors” and choosing
Actions > Set hierarchy color to change the selected blocks to the next available color.
Figure B-6 Changing Hierarchy Color
To clear the color, select Actions > Unset hierarchy color in the DFA Control Center.
Examining Net Connectivity

You can view net connection information between module object blocks and I/Os with the
Data Flow Analysis tool. When you select a module object block, the tool displays a flyline
between the selected block and each other module object blocks and I/O side with a
connection to the block. In the middle of the net segment, the tool displays a number which
represents the number of connections between the blocks or between the block and I/Os.
Connections between blocks are shown in red and connections between blocks and I/Os
are shown in yellow. In Figure B-7, module object block u_m is selected and has net
connections to blocks u0_0, u0_1, u0_2, and u0_3, and net connections to the I/Os on each
side of the layout.

Examining Net Connectivity B-8
Figure B-7 Block-to-Block and Block-to-I/O Connections
To show connections between all module object blocks, choose Settings > “Show all module
connections” in the DFA Control Center panel. Connections between unselected modules
are displayed with light aqua-green connectivity lines. To move the module names to the
top-left corner of the rectangle, choose Settings > “Show module name top left”. Long
module names in the top-left corner are truncated to 10 characters. To see the full module
name in the InfoTip, hold the pointer over the module. Figure B-8 shows layout with these
option settings enabled.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure B-8 Show All Module Connections
To get more details on the net connections between module object blocks,
1. Move the pointer over the flyline and pause until the flyline displays as a dashed white
line.
2. Click the flyline to open the Connection Details dialog box.
Figure B-9 shows the Connection Details dialog box that is displayed after clicking the flyline
between modules u_m and u0_1. The dialog box lists 120 nets as inputs to block u_m, and
475 nets as outputs from block u_m.

Figure B-9 Connection Details Dialog Box
To display net flylines in the layout for specific nets, select one or more nets in the dialog
box. As you select the nets, the layout view is updated to display the flylines for the selected
nets as shown in Figure B-10.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure B-10 Flylines for Selected Nets
Note that you cannot select input and output nets at the same time.
To remove nets from the list of nets, select the net names and click Filter Nets. To restore
the nets to the list, choose Tools > Manage net filters from the DFA Control Center, select
the net names and click Remove.
To filter the lists of nets by fanout, enter the minimum fanout and maximum fanout values
and click Search. The list is updated to show only nets that meet the fanout criteria.
To group net names for a bus into a single entry, enter a regular expression in the Group Bus
Prefix box and select the check box. The default expression is [[0-9]+]. You should modify
the expression based on the bus naming convention for your design. When the Group Bus
Prefix option is active, click Show Non-bus Signals to include non-bus signals in the list of
nets. Figure B-11 shows the Connection Details dialog box before and after grouping the
nets by bus prefix by using the expression __[0-9]+_.
Figure B-11 Nets Before and After Bus Grouping
To list nets that contain a specified string, enter the search string regular expression in the
search box and click the Search button. For example, to search for all nets that contain the
string “HR”, enter .*HR.* as the search string.

Tracing Macro and I/O Connections

You can trace the macro or I/O connectivity through registers and standard cell gate logic by
extracting connectivity information and displaying flylines in the layout view. You can filter
the connections to display only a limited set of flylines. You can also save the connectivity
information in a file.
To display macro-to-macro, macro-to-I/O, or I/O-to-I/O flylines in the layout,
1. Choose Tools > Data flow flylines from the DFA Control Center.
2. Set the initial data extraction parameters by entering the maximum number of register
levels, maximum number of gate levels, and maximum fanout levels to trace. Click
Extract Data to continue.
The tool traces the logic in your design and extracts the flyline information for the
specified levels. If you performed this step earlier in your session, the tool proceeds
directly to the next step without prompting for the initial data extraction parameters.
3. Click the Macro_IO_Flyline tab if it is not already selected.
4. Select one or more hard macros or I/O ports and click Show Flylines.
The tool shows the flylines from the selected macros or I/Os that meet the criteria specified
in the dialog box as shown in Figure B-12. Flylines between macros and I/Os are displayed
in yellow and flylines between macros are displayed in pink. Make sure that at least one of
the Macro-Macro Flylines, Macro-I/O Flylines, I/O-I/O Flylines or Flylines Between Selection
options is selected.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Tracing Macro and I/O Connections B-13
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure B-12 Macro-to-Macro and Macro-to-I/O Flylines
To change the flylines that are displayed, select a new macro or change the selection
options in the dialog box and click Show Flylines. The Min Bus Pin Width option limits the
display to flylines that are part of a bus of the specified width or a larger width. The Num of
Flylines option limits the number of flylines displayed to the specified value. When you enter
a value N for the Num of Flylines option, only N flylines with the largest number of signals
are shown.
Click Save To File to write out a file containing the sources and destinations for the currently
displayed flylines. You can use this file to examine the connections to the currently selected
macros. Click Extract Data to rerun data extraction to expand the currently available register

levels and gate levels for flyline display. Click the Help button for more information about this
dialog box.
To display flylines that originate from a common driver and drive multiple macros,
1. Select one or more macros
2. Select the Common drivers (Macros only) option
3. Click Show Flylines
The tool redisplays the layout and shows flylines that drive both the selected macros and
other macros. In Figure B-13, the selected macro shares drivers with the other three macros
in the group.
Figure B-13 Macros With Common Drivers
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Reporting Module Connection Details

The data flow analysis tool can write a detailed report of connections between the currently
displayed module object blocks and between the blocks and I/O ports. The report contains
the following information:
• Input port to module connections
• Module to output port connections
• Detailed summary for each module:
❍ Number of submodules, macros, standard cells, and pins
❍ List of other modules with connections to the module, and the nets that connect the
modules
To generate the report,
1. Choose File > “Write verbose module report” from the DFA Control Center.
2. Enter an output report file name and click OK.
A short section of the report is as follows:

*********************************************
Report: DFA Module Info
Design : leon3mp
Version: I-2013.12-SP
Date : Fri Feb 7 16:16:36 2014
*********************************************
*********************************************
Input port to modules connections
*********************************************
u0_0 has 3 connections from input ports
tsti_0__SE_
test_cgtm
n94
...
Highlighting Registers in Macro-to-Macro Paths

You can use data flow analysis to display registers in the path between two or more macros.
To display different levels of registers between macros,
1. Choose Tools > Data flow flylines from the DFA Control Center.
2. Click the Reg_Highlight tab.

Reporting Module Connection Details B-16
The dialog box provides different options for tracing registers between macros. To show the
flylines, select Show Flylines To Levels, otherwise only the register locations are displayed
in the layout. To display flylines and registers for paths that contain one register, select Reg
Level 1, and so on. Select Dest Pins to show the flyline from the destination pin. To limit the
flyline display to only flylines between selected macros, select Flylines Between Selection.
After selecting the options, click Highlight Levels to update the Layout view with the new
selections.
To view flylines for individual paths that contain registers, click Show Level Info. As you
select a net in the Register Highlight Level Information dialog box, the tool displays a flyline
for each register-to-register or macro-to-register segment. Figure B-14 shows three paths
highlighted: a path with zero register levels, a path with one register level, and a path with
two register levels.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Highlighting Registers in Macro-to-Macro Paths B-17
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure B-14 Register Highlighting
To sort any column in ascending or descending order, right mouse click the column header
and select the sort direction. The dialog box lists net connections with 0, 1, 2, and 3 levels
of registers. To select more than one path, hold the Ctrl key while selecting additional nets.
Click Select All or Unselect All to change the selection, or Remove to remove the selected
nets from the list. You can recover removed nets by closing and reopening the dialog box.
To save the paths to a file, click Save To File.

Highlighting Registers in Macro-to-Macro Paths B-18
Setting Placement Gravity for Modules

Hierarchical placement gravity keeps together the cells that belong to each hierarchical
design logic block. This type of grouping usually results in better placement because
designs tend to partition well along hierarchical boundaries.
You can set hierarchical placement gravity for module object blocks in the tool. Create a
placement gravity list and set the hierarchy gravity as follows:
1. Choose one or more module object blocks.
2. Choose Tools > Add to gravity list from the DFA Control Center.
3. Choose Tools > Set hierarchy gravity from the DFA Control Center.
4. Select one or more module names from the list and click Set Selected, or click Set All to
use all of the listed blocks.
After you click Set Selected or Set All, the tool provides the selected modules to the
-hierarchy_gravity_blocks option of the set_fp_placement_strategy command. For
more information about hierarchy gravity, see “Hierarchical Gravity” on page 6-6.
Editing Macro Arrays

You can adjust the placement of a group of macros to reduce congestion and to improve
QoR. The macro array editor displays the selected macros in an array for easy
transformation and resizing. When you finish arranging the macros, you can update macro
placement or create a relative placement group.
To open the macro array editor,
1. Select the hard macros in the layout view.
2. Choose Tools > Edit macro array from the DFA Control Center.
The tool opens the Macro Array Editor and places the selected macros into the array. The
macros are aligned by their lower-left corners. The instance names of the selected macros
are displayed in the Selected Macros list.
Note that if the array dimensions are too large for the placement area, the tool displays a
warning at the top of the Macro Array Editor.
Figure B-15 shows the macro array editor window. For more information about this window,
click Help.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Setting Placement Gravity for Modules B-19
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure B-15 Macro Array Editor Window

Numbered list of
Zoom in instance names of
Fit Select and adjust
Zoom out channel sizes array elements
Add or remove
rows or columns
Adjust order or
orientation of
array elements
Immediately update Create relative Reverse

macro array placement placement group last edit
in layout view for array pattern
You can display the name of a macro in the Macro Array Editor by holding the pointer over
the macro in the array. To select a macro in the array, you can click the macro in the Macro
Array Editor or click its name in the Selected Macros list.
To adjust the view displayed in the Macro Array Editor, click the zoom-in or zoom-out button
at the top of the dialog box and drag a rectangle in the Array Pattern panel. Click the fit
button to fit the array in the view. You can display or hide the connection flylines by selecting
or deselecting the Show Flylines option in the bottom left corner of the window.
You can use the macro array editor window to
• Add or remove rows and columns in the array
• Adjust the order and orientation of array elements
• Drag and drop a macro into an empty location in the array

Editing Macro Arrays B-20
• Select and adjust channel sizes

• Reconfigure the array
• Create a relative placement constraint for the array pattern
If you need to reverse the most recent edit, click the Undo button. You can sequentially
reverse multiple edits.
You can add or remove rows and columns in the array. You can remove only an empty row
or column. You can also adjust the channel spacing between rows and columns. To add a
row above a macro, select the macro and click the Add Row button. To add a column on the
left side of a macro, select the macro and click the Add Column button. To remove a row,
select the row and click the Remove Row button. To remove a column, select the column
and click the Remove Column button.
To adjust the channel size for a row or column,
1. Click the row or column channel between the macros.
2. Enter the new spacing value in microns in the Set Row/Column Spacing dialog box.
3. Click OK.
You can reorder the array elements by moving macros from row to row or from column to
column. You can also let the tool sort the macros automatically.
To move a macro in the array,
1. Select the macro.
2. Click the button for the direction you want to move the macro: Up, Down, Left, or Right.
You can also drag and drop the macro to an empty location in the array.
To sort the array by instance name, click the Auto Sort button.
To flip a macro, select the macro and click the Flip button. If you click the Flip button multiple
times, the tool alternately flips the macro horizontally and vertically.
You can reconfigure the entire array by defining new dimensions for the array.
To reconfigure the macro array,
1. Click the Reconfigure Array button.
2. Enter the new values for row, column, row spacing and column spacing in the dialog box.
3. Click OK.
When you are satisfied with the macro array, you can apply the configuration to the macros
in your design by updating macro placement.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Editing Macro Arrays B-21
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
To update the macro placement in the layout view, click Apply. The tool applies the updated
location, spacing, and orientation information to the corresponding macros in the layout
view, and then snaps the group to the lower-left corner of the placement grid.
Note that if any of the macros in the array have an is_fixed attribute value set to true, the
tool prompts you to unfix the macros and continue. Click OK to unfix the macros, and Apply
to apply the changes. To cancel the edit, click Cancel.
Alternatively, you can save your edits by creating a relative placement group. For details,
see “Setting Macro Group Constraints” on page B-25.
Editing Macro Placement in the Layout View

You can use the macro editing toolbox to group, align, or distribute a set of macros. You can
also flip or rotate individual macros.
To open the macro editing toolbox, select the macros in the Layout window and choose
Tools > Macro Toolbox from the DFA Control Center. To align a group of macros, click the
Top, Left, Right, or Bottom button in the Macro Editing Toolbox dialog box. To distribute a
group of macros, enter the spacing value.
To evenly distribute spacing among the macros, type or select a spacing value in the
Distribute Objects box and click the L<-R, L->R, B/T, or T/B buttons. To create overlapping
macros, enter a negative spacing value in the Distribute Objects box. Figure B-16 shows the
results of selecting B/T and T/B with a spacing value of 10. Figure B-17 shows the results of
selecting L<-R and L->R with a spacing value of 10.

Editing Macro Placement in the Layout View B-22
Figure B-16 Distribute Macros Vertically
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Editing Macro Placement in the Layout View B-23
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Figure B-17 Distribute Macros Horizontally
To flip or rotate a macro or group of macros, select the macros and click Clockwise 90,
Counter CW 90, Flip by X axis, or Flip by Y axis. If you select a group of macros, the origin
of the rotation or flip is the center of the group.
When you are satisfied with the macro placement, you can create a relative placement
group. For more information, see “Setting Macro Group Constraints” on page B-25.
Copying Macro Placement

You can copy the macro placement of a module to another module. The tool searches for
matching macros based on hierarchical instance names and returns an array if it does not
find a match.
To copy the macro placement from one module to another module,
1. Select the module with the macro arrangement that you want to copy, and choose Tools
> Copy macro placement from the DFA Control Center.
2. Select the module to which you want to apply the macro placement and click OK.

Copying Macro Placement B-24
If the tool finds matching macros, it orients the macros in the selected module and moves
them to replicate the macro arrangement in the model module.
Setting Macro Group Constraints

When you edit macro placement in the macro array editor or the macro editing toolbox, you
can keep macros together by grouping them in relative placement groups.
To create a relative placement group,
1. Click the Group button in the macro array editor window or the Macro Editing Toolbox
dialog box.
The Macro Group Constraint dialog box appears. The Array Constraints box contains a
list of commands to create the relative placement group, add the macros to the group,
and set relative placement group options.
2. (Optional) Edit the commands in the Array Constraints box if necessary.
3. (Optional) To save the constraints in a tool command language (Tcl) script file, click Save
and enter the name of the constraints file.
4. Click Apply to execute the commands and create the relative placement group.
To remove individual relative placement groups,
1. Choose Tools > Remove group constraints from the DFA Control Center
2. Remove individual relative placement groups by selecting their names in the Macro
Group Constraints list and clicking Remove. Remove all the relative placement groups
by clicking Remove All.
Closing the Data Flow Analysis Window

The tool does not automatically save a command log when you close the data flow analysis
window. If you want to save a log of icc_shell commands that you used while working in the
window, you must save the log before you close the window.
To save the log of icc_shell commands in a file,
1. Choose File > Save logged commands from the DFA Control Center.
2. Select the file or type the file name and click Save.
To close the data flow analysis window, choose File > Exit DFA from the DFA Control
Center.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Setting Macro Group Constraints B-25
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Configuring the CDE Desktop for DFA

If you use the CDE desktop manager, set the configuration to ensure that pop-up windows
are displayed correctly for data flow analysis. To set the configuration,
1. Select the Style Manager on the CDE desktop.
Figure B-18 CDE Desktop
2. Click the Window icon in the Style Manager.

Figure B-19 Style Manager
3. Configure the window behavior as shown in Figure B-20 and click OK to save the
configuration.
Figure B-20 CDE Window Behavior

Configuring the CDE Desktop for DFA B-26
Data Flow Analysis Control Center Reference

The DFA Control Center panel contains tabs which organize common tasks for data flow
analysis. A brief description of the functions available in each tab is described in the
following tables.
Table B-1 File Tab Functions
File Tab Item Function
Save modules to a file Saves the settings in the Settings tab and the positions of the DFA
module object blocks to a file on disk. You can load the file at a
later time to restore the layout.
Load modules from a file Loads a previously saved DFA layout file and restores the
positions of the DFA module object blocks to their previously saved
locations. Settings from the Settings tab are also restored.
Load modules from plan Loads only module object blocks from plan groups. If your design
groups does not contain plan groups, this option is not available.
Write module report Writes a report that lists the number of input port-to-module
connections, and module-to-output port connections for each
module object block. The report also lists the number of
submodules, number of macros, macro area, number of standard
cells, standard cell area, number of pins/ports, and other
information for each module object block.
Write verbose module report Writes a detailed report of input port-to-module connections,
module-to-module connections, and module-to-output port
connections for each module object block. The report includes the
information generated by the “Write module report” action, and the
list of nets that connect the module object blocks and I/O ports.
Save logged commands Saves a file containing set_fp_placement_strategy and

remove_rp_groups commands that were performed during the
current DFA session. If you did not use these commands, no log
file is written.
Exit DFA Closes the DFA Control Center and exits data flow analysis.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
Data Flow Analysis Control Center Reference B-27
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Table B-2 Tools Tab Functions
Tools Tab Item Function
Auto hierarchy detection Searches for modules that meet the search criteria and displays
them as object module blocks in the GUI. The tool prompts you for
the minimum and maximum number of macros per block, and
minimum and maximum module area percentage.
Data flow flylines Displays flylines between macros and I/Os that meet the specified
criteria. The tool prompts you for the maximum fanout and
maximum number of register and fanout levels to trace before
displaying the flylines.
Manage net filters Opens the Net Filters dialog box, where you can add or remove net
name wildcard filtering for module-to-module and module-to-IO
port connection traces.
Edit macro array Opens the Macro Array Editor dialog box, which you can use to
change the architecture of the macro array and configure the
position or orientation of macros in the array.
Macro Toolbox Opens the Macro Editing Toolbox dialog box, which you can use to
align, distribute, and rotate the selected macros.
Copy macro placement Opens the Copy Macro Placement dialog box. Use this dialog box
to copy macro placement from the currently selected module
object block into another module object block. The tool orients the
hard macros of the selected destination module and moves them
to replicate the macro arrangement of the source module.
Select macros of selected Adds all macros of the currently selected module object blocks to
modules the current selection.
Remove group constraints Opens a dialog box that lists the current relative placement
constraints. Choose a macro group constraint and click Remove to
remove it, or click Remove All to remove all macro group
constraints.
Create movebound from Creates a placement movebound from one or more module object
module blocks. All hierarchical and leaf cells contained in the selected
modules are placed into the new movebound.
Add to gravity list Adds the currently selected module object blocks to the list of
blocks for applying hierarchy gravity.

Table B-2 Tools Tab Functions (Continued)
Tools Tab Item Function
Set hierarchy gravity Opens a list of candidate modules for hierarchy gravity. Use the
buttons at the bottom of the dialog box to set or remove hierarchy
gravity from the selected blocks.
Table B-3 Actions Tab Functions
Actions Tab Item Function
Expand all children Expands the currently selected module object blocks and show the
child modules for the blocks, and hide the selected block.
Expand all children w/ macros Expands the currently selected module object blocks that contain
macros and show the child modules for the blocks, and hide the
selected block.
Choose children to expand Opens a list of the child modules for the currently selected module
object blocks. Choose one or more children and click Apply to
perform the expansion.
Select related modules Adds all siblings of currently selected module object blocks to the
selection.
Merge module(s) to parent Merges selected module object blocks to their respective parent
modules and hide the selected modules.
Merge module(s) to top Merges all visible modules and show only the TOP module.
Group selected modules Creates a group of module object blocks from the selected blocks.
Ungroup selected groups Removes the group and expand the group into individual module
object blocks.
Show detail info Opens a dialog box that contains information about the selected
module object blocks. Information includes the number of
submodules, number of macros, macro area, number of standard
cells, standard cell area, number of pins/ports, whether
hierarchical gravity is set, and the connections between this
module and other modules.
Edit module note Creates a note for information about the module object block or
group. If a note already exists, this function opens the existing note
for editing.
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03
Table B-3 Actions Tab Functions (Continued)
Actions Tab Item Function
Set hierarchy color Assigns a new color to the selected modules and all children with
the set_hierarchy_color -cycle_color command.
Unset hierarchy color Removes any assigned hierarchy color from the selected modules
and any children with the unset_hierarchy_color command.
Ports of selected modules Adds to the current selection all physical I/O ports that are
connected to the currently selected modules.
Macros of selected modules Adds to the current selection all macros of currently selected
modules.
Deselect macros of selected Removes from the current selection all macros that belong to the
modules currently selected module object blocks.
Macros of visible modules Adds to the selection all macros that belong to the currently visible
modules.
Table B-4 Settings Tab Functions
Settings Tab Item Function
Select only DFA objects Changes the GUI settings to hide non-DFA elements and only
allow selection of DFA-related elements such as modules, groups,
I/O blocks, ports and macros.
Allow port selection Enables the selection of I/O ports in the GUI.
Allow macro selection Enables the selection of macros in the GUI.
Auto select macros Automatically selects the macros within the module object block in
the Layout window when you select the module object block itself.
Show only bus nets Displays flyline traces between modules that are bus nets. Buses
are defined by the bus_naming_style setting. Flylines for nonbus
signals are hidden.
Show IO connections Displays connections between module object blocks and I/O ports
in the display.
Show selected to selected Displays connections only between selected modules.

Table B-4 Settings Tab Functions (Continued)
Settings Tab Item Function
Show all module connections Displays connections between all modules.
Show module info Displays the number of hard macros and utilization in the bottom
left corner of the module.
Show module name top left Displays the name of the module at the top left of the block, instead
of the center of the block
Show module notes Displays module notes beneath their module.
Mirror hierarchy colors Draws module object blocks by using the same colors assigned to
hierarchies with the set_hierarchy_color command.
Minimum connection count Sets the lowest connection count to display.

filter
AppendixB:B:Data
Chapter DataFlow
FlowAnalyzer
Analyzer
IC
IC Compiler™
Compiler™ Design
Design Planning
Planning User
User Guide
Guide L-2016.03
Version L-2016.03

Index
B report_fp_placement 6-51
report_qtm_model 4-13
black boxes
set_qtm_global_parameter 4-12
create FRAM view 4-8
set_qtm_technology 4-12
flattening existing instances 4-6
set_switching_activity 8-71
managing the properties for 4-9
shape_fp_blocks multiple instantiated
sizing by gate equivalence 4-7 modules
block level designs, performing simultaneous shaping plan groups in (shape_fp_blocks)
placement and pin assignment 6-9 6-67
update_voltage_area 6-64
conventions for documentation 1-xxi
C copy_floorplan command 2-32
clock
creating
latency 9-5, 12-30
pin guides 11-27
clock planning
customer support 1-xxii
performing plan group-aware clock tree
synthesis 9-8
commands D
copy_floorplan 2-32
create_qtm_model 4-12 DEF file
create_voltage_area 6-61 reading 2-30
estimate_fp_area 3-10
flatten_fp_black_boxes 4-6
get_fp_wirelength 6-54
F
get_voltage_areas 6-64 floorplan file, reading 2-32
pack_fp_macro_in_area 6-57
read_def 2-30
read_floorplan 2-32
G
read_saif 8-71 get_voltage_areas command 6-64
IN-1
IN-1
H analyzing quality of 11-31

results, analyzing 11-1
hard macros
pin guides
creating a user-defined array 6-29
creating 11-27
manually adjusting 6-58
packing into an area 6-57 pin overlaps, removing 11-14
hierarchical model pin placement flow, detecting buses 11-4
flow for creating 5-5 pin placement, in-place optimization 10-7
instantiating and using at the top level 5-18 placement
overview 5-2 measuring QoR 6-50
viewing in GUI 5-22 plan group-aware routing, detecting buses
11-4
plan groups
I uncommit hierarchy 13-1
in-place optimization pre-budget timing analysis 12-4
pin placement 10-7 propagate preroutes 13-1
M Q
MinChip quick timing model for black boxes
using multivoltage designs 3-10 command summary 12-12
MinChip technology using Tcl commands to create 4-12
performing steps inside 3-3
multiple instantiated modules
placement of 6-65 R
multivoltage designs read_def command 2-30
using in MinChip 3-10 read_floorplan command 2-32
reading
DEF file 2-30
O real clock latencies, creating budgets for 12-30
optimizing pins for block level designs 6-10
overview of hierarchical models 5-2
S
soft macros
P discarded pins 11-8
packing hard macros 6-57 uncommit physical hierarchy 13-1
physical data SolvNet
copying 2-32 accessing 1-xxii
physical hierarchy documentation 1-xx
commit 13-1 switching activity, annotating 8-71
pin assignment
IN-2
Index IN-2
T V
timing budgeting voltage areas
creating real clock latencies 12-30 planning location and shape of 6-59
performing in design planning 12-1 removing commands
pre-budget timing analysis 12-4 remove_voltage_area 6-64
prerequisites 12-3 supporting physical boundary scenarios 6-63
running 12-7 updating 6-64
U
update_voltage_area command 6-64
IN-3
Index IN-3

ICC Design Planning

Uploaded by

Copyright:

Available Formats

ICC Design Planning

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ICC Design Planning

Uploaded by

Copyright:

Available Formats

IC Compiler™

IC Compiler™ Design Planning User Guide, Version L-2016.03 ii

Copyright Notice for the Line-Editing Library

IC Compiler™ Design Planning User Guide, Version L-2016.03 iii

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

1. Introduction to Design Planning

Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

3. Automating Die Size Exploration

Power Network Considerations for MinChip Technology . . . . . . . . . . . . . . . . . . . . . 3-4

4. Handling Black Boxes

5. On-Demand-Loading Flow for Large Designs

On-Demand-Loading for Multicorner-Multimode Designs . . . . . . . . . . . . . . . . . 5-14

6. Virtual Flat Placement

Flip-Chip Driver Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Identifying Multiply Instantiated Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-65

Reporting Channel Routing Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26

8. Performing Power Planning

Creating Rings Around Voltage Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23

Performing Power Analysis With Switching Activity Information . . . . . . . . . . . . 8-71

9. Performing Clock Planning

10. Performing In-Place Timing Optimization

11. Performing Routing-Based Pin Assignment

Reporting Voltage Area Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25

12. Performing Timing Budgeting

Block-Level Hierarchical Signal Integrity Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27

13. Committing the Physical Hierarchy

Appendix A. Using the Flip-Chip Flow

Reporting Crossover Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18

Appendix B. Data Flow Analyzer

Reporting Module Connection Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16

About This Guide

Courier Indicates syntax, such as write_def.

Courier italic Indicates a user-defined value in syntax, such as

Courier bold Indicates user input—text you type verbatim—in

[] Denotes optional arguments in syntax, such as

... Indicates that arguments can be repeated as many

| Indicates a choice among alternatives, such as

Ctrl+C Indicates a keyboard combination, such as holding

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

Edit > Copy Indicates a path to a menu command, such as

Contacting the Synopsys Technical Support Center

Design Planning Features

Chapter 1: Introduction to Design Planning

Design Planning Overview

Chapter 1: Introduction to Design Planning

Hierarchical Methodology for Design Planning

Chapter 1: Introduction to Design Planning

Figure 1-1 Hierarchical Design Planning Flow

Remove multiply instantiated modules

Perform power network analysis

Chapter 1: Introduction to Design Planning

Chapter 1: Introduction to Design Planning

Deciding on the Physical Partitions

Chapter 1: Introduction to Design Planning

Padding the Plan Groups

Shielding Plan Groups or Soft Macros

Chapter 1: Introduction to Design Planning

Creating Soft Macros From the Plan Groups

Pushing Down Physical Objects