IC Compiler™ II Design Planning User Guide
IC Compiler™ II Design Planning User Guide
IC Compiler™ II Design Planning User Guide
Guide
Version T-2022.03-SP1, April 2022
Copyright and Proprietary Information Notice
© 2022 Synopsys, Inc. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc.
and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All
other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is
strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
https://www.synopsys.com/company/legal/trademarks-brands.html.
All other product or company names may be trademarks of their respective owners.
Free and Open-Source Licensing Notices
If applicable, Free and Open-Source Software (FOSS) licensing notices are available in the product installation.
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.
www.synopsys.com
Contents
New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Related Products, Publications, and Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3
Feedback
Contents
3. Splitting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Split Constraints Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Split Constraints Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Split Constraints Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Split Constraints Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4. Creating a Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Supported Types of Floorplans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Channeled Floorplans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Abutted Floorplans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Narrow-Channel Floorplans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Reading the Verilog Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Creating Dense and Sparse Outline Views for Large Designs . . . . . . . . . . . . . . . . . 49
Creating an Initial Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Creating an L-, T-, or U-Shaped Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Creating a Complex Rectilinear Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Creating a Floorplan Based on a Physical Rules File . . . . . . . . . . . . . . . . . . . . . . . 54
Adjusting the Floorplan Aspect Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Defining Routing Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Flipping the First Row in the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Updating the Floorplanning Without Disturbing Specified Object Types . . . . . . . . . .60
Validating the FinFET Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Scaling the Die Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Reporting Floorplan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Reading, Writing, and Copying Floorplan Information . . . . . . . . . . . . . . . . . . . . . . . 65
Reading in Floorplan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Reading DEF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Writing Out Floorplan Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Copying Floorplan Objects From Block to Block . . . . . . . . . . . . . . . . . . . . . . . . 67
Creating and Validating Floorplan Rules for Advanced Technology Nodes . . . . . . . 73
Creating Additional Floorplan Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Floorplan Area Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Floorplan Enclosure Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Floorplan Halo Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4
Feedback
Contents
5
Feedback
Contents
6
Feedback
Contents
7
Feedback
Contents
8
Feedback
Contents
9
Feedback
Contents
10
Feedback
Contents
11
Feedback
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier bold Indicates user input—text you type verbatim—in examples, such
as
prompt> write_file top
Convention Description
Edit > Copy Indicates a path to a menu command, such as opening the Edit
menu and choosing Copy.
Customer Support
Customer support is available through SolvNetPlus.
Accessing SolvNetPlus
The SolvNetPlus site includes a knowledge base of technical articles and answers to
frequently asked questions about Synopsys tools. The SolvNetPlus site also gives you
access to a wide range of Synopsys online services including software downloads,
documentation, and technical support.
To access the SolvNetPlus site, go to the following address:
https://solvnetplus.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 sign up for an account.
If you need help using the SolvNetPlus site, click REGISTRATION HELP in the top-right
menu bar.
1
Introduction to Design Planning
The IC Compiler II tool is designed for efficient design planning, placement, routing, and
analysis of very large designs. You can use the design planning and chip-level analysis
capabilities to perform initial floorplanning and feasibility analysis.
For more information, see the following topics:
• Design Planning Overview
• Hierarchical Design Planning Flow
• Design Planning at Multiple Levels of Physical Hierarchy
• Design Validation During Design Planning
planning, you can create different voltage areas within the design and define a power plan
strategy for each voltage area. The tool creates the power and ground mesh based on
your specification, and it connects the macros and standard cells to the mesh. You can
quickly iterate on different power plan strategies to investigate different implementations
and select the optimal power plan.
The IC Compiler II tool supports complete hierarchical design planning for both channeled
and abutted layout styles. For more information, see Supported Types of Floorplans.
Design planning in the IC Compiler II tool provides the following features for developing
hierarchical and flat designs, such as
• Multi-Level Physical Hierarchy Floorplanning
• Advanced abstraction management for processing large designs
• Guided floorplanning with a graphical Task Manager
• Data flow analysis for macro management and placement assistance
• Fast placement of macros and standard cells
• Pattern-based power planning
• Power network description using UPF
• Virtual in-place timing optimization
• Pin placement and bus bundling
• Timing budgeting
design changes to individual blocks while maintaining minimal disruption to the design
schedule.
• 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 II 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.
The flow to implement a hierarchical design plan is shown in Figure 1.
Initialize design
Plan power network
(initialize_floorplan)
Place I/Os
Plan buses and repeaters
(place_io)
Shape blocks
Write design data
(shape_blocks)
See Also
• Design Partitioning
• Deciding on the Physical Partitions
Design Partitioning
After reading in the netlist and initializing the floorplan, you can determine the physical
partitioning for your hierarchical design project. When deciding on the physical partitions,
consider the following factors:
• Size
Partition your design with blocks of similar size. Small blocks should be grouped and
large blocks should be 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 II tool.
• Committing Blocks
After you decide on an initial partitioning, you can commit the blocks. Blocks are
committed early in the floorplanning flow, and abstract views are used to generate an
initial floorplan and timing budgets for the design.
For more information about committing blocks, see Committing Design Blocks.
all child interface pins within the full chip, the parent and child interfaces for mid-level sub-
chips and the primary pins at lowest level sub-chips. The entire design can proceed with
placement and optimization concurrently and in a distributed manner.
To examine critical timing paths in the layout or perform other design planning tasks,
you can interactively view, analyze, and manually edit any level of the design in a full-
chip context. You can choose to view top-level only or multiple levels of hierarchy.
When viewing multiple levels, interactive routing is performed as if the design is flat. At
completion, routes are pushed into children and hierarchical pins are automatically added.
The list of keywords related to design planning for the -checks option is shown in the
following list.
• dp_pre_floorplan
◦ Checks that the constraint mapping file specifies a UPF file for all blocks
◦ Checks that the Verilog files are in place for the outline view for blocks
• dp_pre_block_shaping
◦ Checks that the target utilization or area exists for all black boxes
◦ Checks that there is at least one block or voltage area to shape
◦ Checks that the core area and block boundaries are valid
◦ Checks that the block grid is set if the design contains multiply instantiated blocks
(MIBs)
◦ Performs the multivoltage checks related to the shape_blocks command
• dp_pre_macro_placement
◦ Checks that the preferred routing direction is set for the routing layers
◦ Checks that the tracks exist for routing layers
• dp_pre_pin_placement
• dp_pre_push_down
◦ Checks that the constraint mapping file specifies SDC files for all blocks
• dp_pre_timing_estimation (timing abstract checks)
◦ Checks that the top and block levels have defined modes and corners
◦ Checks that the top-level modes and corners have corresponding block-level
modes and corners
◦ Checks that the top level contains at least one clock, at least one scenario using a
nonestimated corner, and the corner has parasitic parameters
• dp_pre_timing_estimation (placement abstract checks)
2
Working in Design Planning Mode
The IC Compiler II tool supports a design planning mode that only enables functionality,
commands, and operations related to design planning tasks and restricts tool usage in
other areas.
The following topics describe how to use the IC Compiler II tool:
• User Interfaces
• Entering icc2_shell Commands
• Using Variables
• Using Application Options
• Viewing Man Pages
• Using Tcl Scripts
• Using Setup Files
• Using the Command Log File
• Running Tasks in Parallel
• Monitoring Distributed Tasks
User Interfaces
The IC Compiler II tool operates in the X windows environment on UNIX or Linux.
It provides a flexible working environment with both a shell command-line interface
and a graphical user interface (GUI). The shell command-line interface, icc2_shell, is
always available during a IC Compiler II session. You can start or exit a session in either
icc2_shell or the GUI, and you can open or close the GUI at any time during a session.
The IC Compiler II tool uses the tool command language (Tcl), which is used in many
applications in the EDA industry. Using Tcl, you can extend the icc2_shell command
language by writing reusable procedures and scripts (see the Using Tcl With Synopsys
Tools manual).
The following topics describe how to start and exit the tool using the command-line
interface.
• Starting the Command-Line Interface
• Exiting the IC Compiler II Tool
For information about using the GUI, see the IC Compiler II Graphical User Interface User
Guide.
You can include other options on the command line when you start icc2_shell. For
example, you can use
• -f script_file_name to execute a script
See Also
• Using the Command Log File
• Using Setup Files
• Using Tcl Scripts
See Also
• Viewing Man Pages
• To display the options supported by an icc2_shell command, enter the command name
with the -help option on the icc2_shell command line. For example, to see the options
supported by the report_timing command, use the following command:
icc2_shell> report_timing -help
Using Variables
In general, the IC Compiler II tool modifies default behavior by using application options
rather than application variables. The tool does support user-defined Tcl variables, as well
as a minimal number of application variables, such as the search_path variable.
Use the printvar command to list the variables.
Examples:
printvar *
printvar search_path
where category is the name of the engine affected by the application option. Some
application option categories have subcategories to further refine the area affected by the
application option.
Application options have either a global scope or a block scope.
• Block-scoped application options apply only to the block on which they are set. They
are saved in the design library and are persistent across tool sessions.
• Global-scoped application options apply to all blocks, but only within the current
session. They are not saved in the design library; you must specify them in each
icc2_shell session. You might want to consider adding the global settings to
your .synopsys_icc2.setup file.
To get a list of available application options, use the get_app_options command. By
default, this command lists all application options. To restrict the reported application
options, provide a pattern string as an argument to the command.
For example, to list all available application options, use the following command:
icc2_shell> get_app_options
To list all available timer application options, use the following command:
icc2_shell> get_app_options timer.*
For detailed information about application options, see “Application Options” in the IC
Compiler II Data Model User Guide.
See Also
• Using Setup Files
To display the man page for an icc2_shell application option, enter the man command
followed by the option name. You can also view the man page that summarizes all of the
application options for the following types of summaries:
• Category summaries
Enter the man command followed by category_options. For example, to see the man
page that summarizes all floorplan application options, use the following command:
icc2_shell> man plan_options
• Subcategory summaries
Enter the man command followed by category.subcategory_options. For example, to
see the man page that summarizes all floorplan placement application options, use the
following command:
icc2_shell> man plan.place_options
• Command summaries
Enter the man command followed by command_options. For example, to see the man
page that summarizes all application options that affect the report_timing command,
use the following command:
icc2_shell> man report_timing
If you enter the man command on the icc2_shell command line, the man page is displayed
in the IC Compiler II shell and in the console log view if the GUI is open. If you enter this
command on the console command line in the GUI, the man page is displayed in the GUI
man page viewer.
For more information about writing scripts and script files, see the Using Tcl With
Synopsys Tools manual.
Use one of the following methods to run a Tcl script:
• Use the -f option with the icc2_shell command when you start the IC Compiler II
tool.
• Use the source command from the icc2_shell command line.
• Choose File > Execute Script in the GUI.
If an error occurs when running a command, the IC Compiler II tool raises the
TCL_ERROR condition, which immediately stops the script execution. To tolerate errors
and allow the script to continue executing, either
• Check for TCL_ERROR error conditions with the Tcl catch command on the
commands that might generate errors.
• Set the sh_continue_on_error variable to true in the script file.
See Also
• Starting the Command-Line Interface
However, the data in the spreadsheet should be in a specific format and the spreadsheet
should be a CSV file. For the spreadsheet format, see the examples at the end of this
topic. When you use these examples to build your CSV file, ensure that you do not alter
any of the information that is highlighted in yellow. Altering this text in any way, such as
using some other text or not adhering to case-sensitivity might result in the non-generation
of the PG script.
The commands that are written out to the script file based on the spreadsheet data are as
follows. No other PG commands are supported.
• create_pg_composite_pattern
• create_pg_special_pattern
• create_pg_wire_pattern
• set_pg_strategy
• set_pg_strategy_via_rule
In the following example, the generate_pg_script command takes the data from the
special_pattern_spreedsheet.csv file and outputs the test.tcl file with the PG commands.
icc2_shell> generate_pg_script -input special_pattern_spreedsheet.csv \
-output test.tcl
See Also
• User Interfaces
• Using Application Options
• Using Tcl Scripts
The command returns the process id for the dpmanager task created by the command.
2. Start the distributed task.
icc2_shell> create_abstract -placement \
-host_options block_script -all_blocks
Submitting job for block BLENDER_0 ...
Submitting job for block BLENDER_1 ...
3. Monitor the running task in the Distributed Processing Manager window as shown in
Figure 2.
When all tasks are complete, the Distributed Processing Manager updates the Status
column to COMPLETED for all job/Task IDs, and updates the status in the Job History
window from not done to done.
You can open a maximum of two Distributed Processing Manager windows. To open a
second Distributed Processing Manager window, use the run_monitor_gui command
a second time. To kill any open Distributed Processing Manager windows and restart a
single window, use the run_monitor_gui -kill command.
The Distributed Processing Manager monitors the progress of the following commands, if
they are running in distributed mode:
• create_abstract -all_blocks | -blocks
• create_placement -floorplan
• estimate_timing
• merge_abstract
• shape_blocks
3
Splitting Constraints
To generate timing budgets, chip-level Synopsys Design Constraints (SDC) and UPF files
must be partitioned into top-level and block-level files. The IC Compiler II tool uses the top-
level constraints to constrain the top-level logic when abstract views of blocks are used.
For more information, see the following topics on splitting constraints:
• Split Constraints Flow
• Split Constraints Output Files
• Split Constraints Example 1
• Split Constraints Example 2
Note that if you already have block-level SDC and UPF constraints for your design, you
can ignore this section and continue without running the split_constraints command.
To split the chip-level SDC and UPF constraints,
1. Read in the full Verilog netlist.
icc2_shell> read_verilog -top ORCA.v
Note that the split constraints flow requires that you read the full Verilog netlist with the
read_verilog command. You cannot use the read_verilog_outline command for
this step.
2. Load and commit the UPF constraint file for the entire design.
icc2_shell> load_upf ORCA.upf
icc2_shell> commit_upf
The load_upf command reads in the UPF constraints and the commit_upf command
applies the UPF constraints to the design. The commit_upf command also tries to
resolve any conflicts between the power intent specified in the UPF file and the actual
power and ground nets in the design.
3. Set up the timing environment for the design.
For a design with multiple modes and corners, you must use one or more of the
following commands:
create_corner
create_mode
read_sdc
set_corner_status
set_parasitic_parameters
set_process_number
set_temperature
set_voltage
If your design uses UPF to describe the power network, you must use the
set_voltage command for all supply net groups defined in the UPF file.
4. Reset any previous budget constraints and specify the blocks for which to write out
constraints.
icc2_shell> set_budget_options -reset
icc2_shell> set_budget_options -add_blocks {I_ORCA_TOP/I_BLENDER_1 \
I_ORCA_TOP/I_BLENDER_2 I_ORCA_TOP/I_BLENDER_3 \
I_ORCA_TOP/I_BLENDER_4 I_ORCA_TOP/I_BLENDER_5 \
I_ORCA_TOP/I_BLENDER_6 I_ORCA_TOP/I_BLENDER_7}
If your design uses UPF to describe the power network, you must use the
set_voltage command for all supply net groups defined in the UPF file.
5. Split the timing constraints and UPF file into separate files for each block.
icc2_shell> split_constraints
If your design contains multiple levels of physical hierarchy, specify the intermediate
levels of hierarchy with the -design_subblocks option. The nested modules in the
design hierarchy are not abstracted when they are used in the context of their parent
block.
icc2_shell> split_constraints -design_subblocks {block_1 block_2}
• Retain internal constraints for subblocks when using hierarchical abstracts with the
-hier_abstract_subblocks block_names option. Use this option to indicate that the
specific blocks are represented as hierarchical abstracts.
• Write out constraint files only for certain modes with the -modes option.
icc2_shell> split_constraints -modes {s1.mode}
• Write out constraint files only for certain corners with the -corners option.
icc2_shell> split_constraints -corners {s1.corner}
• Compress the output constraint files with the -compress gzip option.
icc2_shell> split_constraints -compress gzip
• Specify the directory to use for the output with the -output option.
icc2_shell> split_constraints -output split2
In this example, ORCA is the top-level design and BLENDER_0 through BLENDER_6
are the modules. The split_constraints command creates the following files for the
top-level design and for each module that is specified with the set_budget_options
-add_blocks command:
• top.tcl: Provides corner and mode definitions, and sources all other files in the correct
order. Source only this file to apply the split constraints for the specified block.
• top.upf: Provides power constraints in UPF format..
• design.tcl: Provides design-wide constraints with mode and corner associations.
Contains set_corner_status commands to configure analysis settings for mode and
corner combinations.
• clocknets.tcl: Provides constraints for clock nets.
• mode_modename.tcl: Provides mode-specific constraints for clocks, exceptions,
latencies, and so on. The tool creates one Tcl file for each defined mode.
• corner_cornername.tcl: Provides corner-specific constraints for derating factors,
parasitic definitions, and PVT values. The tool creates one Tcl file for each defined
corner.
• scenario_scenarioname.tcl: Provides scenario-specific constraints for clock latency,
clock uncertainty, and other factors. The tool creates one Tcl file for each defined
scenario.
The split_constraints command also creates the constraint mapping file, mapfile,
which lists the SDC and UPF constraint files for each block. The content of the mapfile for
this example is as follows:
BLENDER_0 CLKNET BLENDER_0/clocknets.tcl
BLENDER_0 SDC BLENDER_0/top.tcl
BLENDER_0 UPF BLENDER_0/top.upf
...
BLENDER_6 CLKNET BLENDER_6/clocknets.tcl
BLENDER_6 SDC BLENDER_6/top.tcl
in1 in1
y
a1
ff1 ff2
clk clk
i1
This design example uses the following chip-level SDC constraints file.
The split_constraints command partitions the chip-level SDC constraints file into the
following top-level and block-level mode_modename.tcl constraint files.
i1
This design example uses the following top-level SDC constraints file.
The split_constraints command partitions the chip-level SDC constraints file into the
following top-level and block-level mode_modename.tcl constraint files.
4
Creating a Floorplan
This section 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.
For more information, see the following topics:
• Supported Types of Floorplans
• Reading the Verilog Netlist
• Creating Dense and Sparse Outline Views for Large Designs
• Creating an Initial Floorplan
• Creating an L-, T-, or U-Shaped Floorplan
• Creating a Complex Rectilinear Floorplan
• Creating a Floorplan Based on a Physical Rules File
• Adjusting the Floorplan Aspect Ratio
• Defining Routing Tracks
• Flipping the First Row in the Floorplan
• Updating the Floorplanning Without Disturbing Specified Object Types
• Validating the FinFET Grid
• Scaling the Die Area
• Reporting Floorplan Information
• Reading, Writing, and Copying Floorplan Information
• Creating and Validating Floorplan Rules for Advanced Technology Nodes
Channeled Floorplans
Channeled floorplans contain spacing between blocks for the placement of top-level macro
cells, as shown in the floorplan example in Figure 6. The spacing enables the tool to place
standard cells between blocks.
Abutted Floorplans
In the abutted floorplan style, 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 clock planning and feedthrough management.
Routing congestion might also become an issue for abutted floorplan designs. Due to the
difficulties in implementing an abutted floorplan, the narrow-channel floorplan style is often
used to minimize the spacing between blocks.
Narrow-Channel Floorplans
The narrow-channel floorplan style provides a balance between the channeled floorplan
and abutted floorplan styles. 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 8.
2. Read the Verilog netlist with the read_verilog_outline command and specify the
appropriate options.
icc2_shell> read_verilog_outline -top ORCA ORCA.v
The Verilog netlist outline reader in the IC Compiler II tool efficiently processes very large
designs. To conserve resources and minimize turnaround time, the netlist reader creates
an outline view of the blocks in the different levels of design hierarchy. The outline design
contains hierarchy, but no leaf cells or nets.
The read_verilog_outline command does not partition the design. To partition the
design, you commit the design blocks with the commit_block command and expand the
blocks to their full netlist representations with the expand_outline command. For more
information on committing blocks, see Committing Design Blocks.
You can also process a design in the full netlist flow by using the flat netlist reader. For
information about reading a design with the flat netlist reader, see the read_verilog
command.
contain only macro cells, and support only the size and interface information needed for
connectivity analysis.
To help define the contents of the outline views, the tool supports the allocation and
partition methods to determine which modules are marked as dense or sparse. Choose
the method to use by including the -partition or -allocation option with the
read_verilog_outline command. Alternatively, set the plan.outline.partition
application option to specify the method. By default, the partition method is used.
For data flow analysis, dense connectivity is needed in top-level modules. Use the
plan.outline.dense_module_depth application option to specify the module hierarchy
depth that should be marked as dense. By default, the depth is one and only the top-level
module is marked as a dense module. Alternatively, use the -depth option to override the
default setting. A value of -1 marks all non-sparse modules as dense. The hierarchy depth
overrides the target cell count specified by the -target_cell_count option.
Partition Method
In the partition method, the tool examines the modules in the hierarchy and determines
the module density based on the target block size and number of leaf cells in the block.
Top-level modules in the module hierarchy are marked as dense until the hierarchical
cell count beneath the module is less than a target block size. Buffers and inverters
are included in the hierarchical cell count. This technique maintains connectivity in the
top levels of hierarchy for data flow analysis. The target block size is specified by the
plan.outline.target_block_size application option; by default, the target block size is
1,000,000 leaf cells. The -target_block_size option can be used to override the default.
After the partition blocks are designated, small module hierarchies within each partition
are designated as dense modules to maintain connectivity for data flow analysis. The
target number of leaf cells to allocate to these module hierarchies is specified by the
plan.outline.glue_cell_count application option; by default the count is 100,000 leaf
cells. Specify a value of -1 to avoid marking any of the small modules as dense modules.
Buffers and inverters are not represented in the outline design and are not included in the
target glue cell count. The -glue_cell_count option can be used to override the default
setting.
Allocation Method
The allocation method is the default method for designating dense and sparse modules
and is used to explore as much of the design hierarchy as possible within a memory
budget of a maximum number of leaf cell instances. Specify the allocation method by
setting the plan.outline.partition application option to false or by specifying the
-allocation option to the read_verilog_outline command.
In the allocation method, modules that exceed a leaf cell count threshold are considered
to be large modules and are treated as sparse modules in the outline view. Buffers and
inverters are not represented in the outline design and are not included in the leaf cell
count. The leaf cell count threshold is specified by the plan.outline.large_threshold
application option; by default the leaf cell count is 10,000. Alternatively, use the
-large_threshold option to override the default setting.
Alternatively, select the Floorplan Initialization panel in the Floorplan Task Assistant
from the GUI.
2. If needed, refine the floorplan by running the initialize_floorplan command again
with different settings for the utilization ratio, side lengths, core-to-boundary spacing,
and other settings.
The initialize_floorplan command creates the floorplan according to the options you
specify. The floorplan is shown in Figure 9.
2. Adjust the length of the sides if needed by changing the arguments to the -side_ratio
or -side_length options and reissue the initialize_floorplan command.
To further change the shape of the floorplan, you must set the dimensions of the
floorplan boundary by specifying the -side_ratio {side_a side_b ...} option or
the -side_length {side_a side_b ...} option. See Figure 11 for a cross reference
between the position of the number in the argument and the edge on the floorplan
shape. This information is also available in the Task Assistant.
a b
a c ef
b a a d
b c f b
d e c
d
Note that the side ratios apply to the core boundary by default. To apply the ratios to the
die boundary, specify the -control_type die option.
The following example creates a U-shaped floorplan. The right arm is twice the width of
the left arm by specifying the -side_ratio option with 1 in the second (b) position and 2
in the sixth (f) position.
icc2_shell> initialize_floorplan -core_utilization 0.7 -shape U \
-orientation N -side_ratio {2 1 1 1 1 2} -core_offset 100 \
-coincident_boundary true
Yes
Yes
1. Determine the ratio between the width and height of the floorplan.
2. Use the initialize_floorplan command with the -side_ratio option to create a
floorplan with the specified width-to-height ratio.
icc2_shell> initialize_floorplan -core_utilization 0.7 -shape R \
-orientation N -side_ratio {3.0 1.0} -core_offset {100.0} \
-flip_first_row true -coincident_boundary true
Note that the ratios apply to the core boundary by default. To apply the ratios to the die
boundary, specify the -control_type die option.
Figure 14 shows two floorplans created by using different -side_ratio option settings
to produce different aspect ratios. The floorplan on the left is created by specifying
-side_ratio {3.0 1.0}, the floorplan on the right is created by specifying -side_ratio
{1.0 3.0}.
Figure 14 Floorplans With Aspect Ratios of 3.0 (left) and 0.33 (right)
To create these floorplans by using the Floorplan Task Assistant in the GUI,
1. Open the Floorplan Task Assistant by selecting Task > Task Assistant in the GUI and
selecting the Floorplan Initialization panel under Floorplan Preparation.
2. Select Core side ratio and enter a width/height value in the Aspect ratio box.
3. Click Preview to display a wireframe preview of the floorplan.
4. Click Apply to create the floorplan.
To create the floorplans shown in Figure 14, enter 3.0 in the Aspect ratio box to create the
floorplan on the left, or enter 0.33 to create the floorplan on the right.
tracks are created completely within the block boundary even if the block boundary is
larger than the core boundary.
You can also specify that subsequent grid points be created with respect to the
core area bounding box or the lower-left of the block bounding box by using the
-end_grid_relative_to option.
Alternatively, you can create routing tracks in the GUI by choosing Create > Track from the
menu.
Figure 15 shows a floorplan created with the create_track command. In this example,
the remove_tracks 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_tracks command reports the routing track direction, startpoint,
number of tracks, and pitch for each set of routing tracks in the design.
icc2_shell> remove_tracks -all
1
icc2_shell> create_track -layer METAL3 -space 0.5
{TRACK_0}
icc2_shell> report_tracks
****************************************
Report report_tracks
Design : TEST
...
****************************************
Layer Direction Start Tracks Pitch Attr
------------------------------------------------------------------------
METAL3 Y 0.250 4023 0.500 default
1
You can also create tracks based on nondefault rules with the create_track command.
For information about creating tracks with nondefault rules, see SolvNet article 3001923,
“How Can I Create Routing Tracks Based on Nondefault Rules (NDRs)?”
In Figure 16, the layout image on the left shows the layout created by using the
-flip_first_row true option, and the layout image on the right shows the
F
F
F
F
F
F
F
F
To create an offset between the boundary and the core, specify the -core_offset option
with the initialize_floorplan command as shown in the following example.
icc2_shell> initialize_floorplan -core_utilization 0.8 \
-core_offset {50 100}
• -keep_pg_route: Retain power and ground routes when updating the floorplan.
• -keep_detail_route: Retain all routes except power and ground routes when
updating the floorplan.
• -keep_placement {block}: Retain block placement when updating the floorplan.
• -keep_placement {io}: Retain terminal and pad placement when updating the
floorplan.
• -keep_placement {macro}: Retain macro placement when updating the floorplan.
• -keep_placement {all}: Retain terminal, pad, macro, block, standard cell, and
physical-only objects when updating the floorplan options.
To check for placement or boundary violations with respect to the FinFET grid, use the
check_finfet_grid command as follows:
icc2_shell> check_finfet_grid
...
Error: boundary point (0 101.97) of hard macro
'I_ORCA_TOP/I_PCI_TOP/I_PCI_WRITE_FIFO/PCI_FIFO_RAM_7'
is not on FinFET grid. (DPCHK-002)
Error: boundary point (0 101.97) of hard macro
'I_ORCA_TOP/I_PCI_TOP/I_PCI_WRITE_FIFO/PCI_FIFO_RAM_6'
is not on FinFET grid. (DPCHK-002)
...
To check specific object types, specify only those objects to the check_finfet_grid
command as follows:
icc2_shell> check_finfet_grid -objects [get_cells -hierarchical \
-filter "design_type==pad"]
...
Reporting violations in block ORCA ...
Error: boundary point (0 345.565) of io pad 'test_mode_iopad'
is not on FinFET grid. (DPCHK-002)
Error: boundary point (0 345.565) of io pad 'sdr_clk_iopad'
is not on FinFET grid. (DPCHK-002)
The following commands are aware of the FinFET grid in the tool:
• create_blackbox
• create_grid
• create_io_guide
• create_io_ring
• create_macro_array
• create_placement
• create_power_switch_array
• create_power_switch_ring
• create_site_array
• create_site_row
• initialize_floorplan
• place_io
• report_grids
• set_block_grid_references
• set_grid
• set_signal_io_constraints
• shape_blocks
• Reducing the size of the design can offer some potential benefits such as, smaller
the die, more the number of dies per wafer. However, ensure that you aim for minor
changes. Major changes can cause issues including excessive utilization or macros
not being able to fit in a design. You can consider this action successful when your
shrunken design is still routable, meets operating speed requirements, and also meets
allowable power consumption requirements.
• Enlarging the design can help with congestion.
Table 2 Options to the modify_die_area Command Control How Much the Die Area is
Resized
The following example shrinks the core area to 85% of its original size.
icc2_shell> modify_die_area -area_scaling_factor 0.85
The following example shrinks core height to 80% of the original height of the die, which is,
20% reduction.
icc2_shell> modify_die_area -height_scaling_factor 0.8
The following example increases the core height to 110% of the original height of the core,
which is a 10% increase.
icc2_shell> modify_die_area -height_scaling_factor 1.1
In the following example, the core area is shrunk to 85% of the original size but the
horizontal dimension is fixed.
--------------------------------------------------------------------------------
-------------------------------
Die Size Exploration Summary
--------------------------------------------------------------------------------
-------------------------------
Original Floorplan Layout
Utilization Ratio: 0.3934
Core Area: 3150962.2170
Core Width: 1775.3000
Core Height: 1774.8900
Boundary Co-ordinates: {350.0000 350.0000} {350.0000 2124.8900}
{2125.3000 2124.8900} {2125.3000 350.0000}
For a hierarchical design which might contain a mix of design and abstract block
representations, use the set_constraint_mapping_file and load_block_constraints
commands as follows:
icc2_shell> set_constraint_mapping_file floorplan/mapfile
icc2_shell> load_block_constraints -type FLOORPLAN -all_blocks
To analyze the syntax of the input DEF files before annotating the objects on the design,
specify the -syntax_only option.
icc2_shell> read_def -syntax_only orca.def
The following examples write out floorplan files for different design requirements:
• Write out macros and set origin, orientation, status, and other attributes.
icc2_shell> write_floorplan -output "macros" -objects [get_cells \
-physical_context -filter is_hard_macro==true]
• Write out pad cells and macro cells with a physical status of fixed or unplaced.
icc2_shell> write_floorplan -force -include cells \
-include_physical_status {fixed unplaced} -cell_types {pad macro}
• Write out clock, power, and ground nets to the DEF file; signal nets are excluded.
icc2_shell> write_floorplan -force -output nets \
-net_types {clock power ground}
the design view of an existing destination block. The designs can be in the same library or
in different libraries. A design label can be specified along with the block name.
The copy_floorplan command can include or exclude one or more object types when
copying. By default, all object types are copied. Use the -include object_type_list
or -exclude object_type_list option to specify the object types that are included or
excluded. Valid object types are as follows:
• blockages
• bounds
• cells
• corridors
• die_area
• edit_groups
• io_guides
• macros
• module_boundaries
• pin_guides
• pins
• route_guides
• rows
• tracks
• vias
• scan_chains
• routing_directions
• voltage_areas
• fills
• pg_metal_fills
• routing_rules
• pg_regions
• port
• supernet
• bundle
• topology_plan
• net_estimation_rule
The copy_floorplan command can also copy the following object types from the source
block to the destination block.
• block
• design
• routing_blockage
• shaping_blockage
• placement_blockage
• bound
• cell
• routing_corridor
• core_area
• edit_group
• fill_cell
• io_guide
• via
• shape
• net
• pin_guide
• pg_region
• routing_guide
• site_row
• site_array
• track
• voltage_area
• routing_rule
• port
• supernet
• bundle
• topology_plan
Use the -objects option to specify the collection of objects. Use other options to the
command to specify the source floorplan, destination floorplan, and which floorplan objects
are copied.
• Copy all floorplan information from the mem design with the “placed” label in the test
library to the currently opened block and library.
icc2_shell> copy_floorplan -from_block test:mem/placed
If you use the -force option, objects are copied to the existing floor plan with new
names even though they are present in the floor plan.
• Copy all floorplan information along with power switch logical connectivity information
from the mem design with the “placed” label in the test library to the mem_copy block
with the “placed” label in the test library by using the -to_block option.
icc2_shell> copy_floorplan -from_block test:mem/placed \
-to_block test:mem_copy/placed
Note:
The -force option has no effect on the power switch cells and connections.
This option does not rename the cells unlike other objects. Therefore,
if the cells already exist but not the logical connectivity, running the
copy_floorplan command again with the -force option creates only the
logical connections.
• Copy only floorplan information for blockages and bounds by using the -include
option.
icc2_shell> copy_floorplan -verbose -from_block test:mem/placed \
-to_block test:mem_copy/placed -include {blockages bounds}
• Copy all floorplan information except for blockages and bounds by using the -exclude
option.
icc2_shell> copy_floorplan -verbose -from_block test:mem/placed \
-to_block test:mem_copy/placed -exclude {blockages bounds}
• Copy only vias VIA_S_0 and VIA_C_0 from the source design to the destination design
by using the -objects option.
icc2_shell> copy_floorplan -verbose -from_block test:mem/placed \
-to_block test:mem_copy/placed \
-objects [get_vias {VIA_S_0 VIA_C_0}]
Table 3 shows examples of how the copy_floorplan works for some of the objects.
Table 3 How the copy_floorplan Command Works
When the supernet Copy to the Copy to the Copy to the Does not Copy to the
copied objects destination destination destination copy to the destination
do not exist in design design design destination design
the destination design
design
bundle Copy to the Copy to the Copy to the Does not Copy to the
destination destination destination copy to the destination
design design design destination design
design
net_estimation_rule Copy to the Cannot be Copy to the Does not Copy to the
destination specified destination copy to the destination
design with the design destination design
-objects design
option
topology_plan Copy to the Copy to the Copy to the Does not Copy to the
destination destination destination copy to the destination
design design design destination design
design
When the supernet Does not Does not Does not Cannot be Does not
copied objects copy to the copy to the copy to the specified copy to the
exist in the destination destination destination with the destination
destination design design design -exclude design
design option
bundle Does not Does not Does not Does not Copy to the
copy to the copy to the copy to the copy to the destination
destination destination destination destination design
design design design design
net_estimation_rule Does not Cannot be Does not Does not Copy to the
copy to the specified copy to the copy to the destination
destination with the destination destination design
design -objects design design
option
topology_plan Does not Does not Does not Does not Copy to the
copy to the copy to the copy to the copy to the destination
destination destination destination destination design
design design design design
Command Description
Command Description
After creating and checking the floorplan rules with the set_floorplan_area_rules,
set_floorplan_enclosure_rules, set_floorplan_halo_rules,
set_floorplan_spacing_rules, set_floorplan_width_rules, and
check_floorplan_rules commands, use the fix_floorplan_rules command to
modify the design based on the rules. The command performs the following changes to
the design:
• Moves macros to satisfy all grid-type spacing rules and enclosure rules from the block
boundary
• Creates a hard keepout margin around hard macros to satisfy spacing and halo rules
• Creates routing blockages after macro placement to satisfy all routing blockages to
macro enclosure and halo rules
• Creates placement blockages after macro placement to satisfy all width rules, spacing
rules to macros, enclosure rules from block boundary, and area rules for the standard
cell area
• Adjusts core area and block boundary to mitigate block boundary to core area
enclosure rule violations and core area width rule violations
• (Optional) Writes out a Tcl file that contains commands to implement the design
changes made by the fix_floorplan_rules command
The following example checks the floorplan rules, uses the fix_floorplan_rules
command to adjust the position of hard macros, and then performs a second check of
the floorplan rules. The second check shows that all floorplan rules are repaired by the
fix_floorplan_rules command.
icc2_shell> check_floorplan_rules
INFO: found 4 error(s) violate rule: rule_1
INFO: found 4 error(s) violate rule: rule_2
INFO: found 50 error(s) violate rule: rule_3
INFO: found 8 error(s) violate rule: rule_4
INFO: checking floorplan rules finished.
icc2_shell> check_floorplan_rules
INFO: found 0 error(s) violate rule: rule_1
INFO: found 0 error(s) violate rule: rule_2
INFO: found 0 error(s) violate rule: rule_3
INFO: found 0 error(s) violate rule: rule_4
5
Handling Black Boxes
The IC Compiler II tool supports black boxes for modules in the design planning flow.
A black box is a module that has no netlist, has only a partial netlist, or is not bound to
a higher level module. Use black boxes to continue design planning without requiring a
complete netlist for all modules. The tool supports block boxes for both physical and timing
purposes, and for all stages of design planning. Note that only physical hierarchies can be
black boxes in the tool.
The following design planning operations are available for black boxes:
• Multiply-Instantiated black box support
• Shaping
• Macro and standard placement (for partial netlist Black Boxes)
• PG Routing
• Pin assignment and feedthrough creation
• Push-down and pop-up
• Feedthrough buffering
• Abstract creation and merging
• Timing model creation
• Budgeting
The flow to create black box physical models and timing models is shown in Figure 18.
• hierarchy_hard_macro_count
• hierarchy_has_shadow_netlist
• hierarchy_has_shadow_netlist_only
• hierarchy_pad_cell_count
• hierarchy_physical_only_cell_count
• hierarchy_std_cell_count
• hierarchy_switch_cell_count
• is_unbound
• target_boundary_area
• Empty modules
Empty modules have a module definition but no content. Use the hierarchy count
attributes for standard cells and hard macros to identify these types of modules.
icc2_shell> get_attribute -objects $cells -name is_unbound
false
icc2_shell> get_attribute -objects $cells \
-name hierarchy_std_cell_count
0
icc2_shell> get_attribute -objects $cells \
-name hierarchy_hard_macro_count
0
icc2_shell> get_attribute -objects $cells \
-name hierarchy_has_shadow_netlist
false
• Partial modules
Modules with only a partial netlist contain an incomplete set of cells. Use the hierarchy
count attributes to identify these types of modules.
icc2_shell> get_attribute -objects $cells \
-name hierarchy_hard_macro_count
3
icc2_shell> get_attribute -objects $cells \
-name hierarchy_std_cell_count
119
• Feedthrough modules
Feedthrough modules contain net connections between input and output ports, but
contain no cells.
icc2_shell> get_attribute -objects $cells \
-name hierarchy_std_cell_count
0
icc2_shell> get_attribute -objects $cells \
-name hierarchy_hard_macro_count
0
icc2_shell> get_attribute -objects $cells \
-name hierarchy_has_shadow_netlist
true
icc2_shell> get_attribute -objects $cells \
-name hierarchy_has_shadow_netlist_only
true
• Tie-off modules
Tie-off modules have only output ports with are tied to a logical value.
icc2_shell> get_attribute -objects $cells \
-name hierarchy_std_cell_count
0
icc2_shell> get_attribute -objects $cells \
-name hierarchy_hard_macro_count
0
icc2_shell> get_attribute -objects $cells \
-name hierarchy_has_shadow_netlist
false
icc2_shell> get_attribute -objects $cells \
-name hierarchy_has_shadow_netlist_only
false
To find black boxes in the design created with the create_blackbox command, or to
check whether a specific module is a black box, check the design_type attribute of the
module as follows:
icc2_shell> get_cells -hierarchical \
-filter ref_block.design_type==black_box
{I_ORCA_TOP/I_BLENDER_0}
The GUI provides annotations in the Hierarchy Browser and Properties Editor to help
identify black boxes as shown in Figure 20.
For black boxes created from a partial Verilog netlist, you can specify a target utilization
with the following command:
icc2_shell> set_attribute -objects [get_cells I_ORCA_TOP/I_BLENDER_0] \
-name target_utilization -value 0.5
{u0_3}
2. Set the clock network delay, pin-to-pin delays, setup and hold constraints.
icc2_shell> create_blackbox_clock_network_delay ...
icc2_shell> create_blackbox_constraint ...
icc2_shell> create_blackbox_delay ...
icc2_shell> create_blackbox_drive_type ...
icc2_shell> create_blackbox_load_type ...
You create 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.
Black box timing information is stored in the design view. When an abstract is created from
a black box, specially marked cells, nets, and connections are created on-the-fly within the
abstract view. This approach enables timing on an empty or partial netlist and allows newly
created feedthroughs to be timed immediately without recreating the models.
For a partial black box, only the unconnected ports can be constrained with black box
timing constraints. Other ports on the partial black box should be constrained by using
Synopsys Design Constraints (SDC) files.
When generating timing budgets, the tool maintains the timing you specified with the black
box timing commands. To allow the budgeter to adjust the black box timing budgets, set
the plan.budget.bbt_fixed_delay application option as follows:
icc2_shell> set_app_options -name plan.budget.bbt_fixed_delay \
-value false
plan.budget.bbt_fixed_delay false
You would not typically run the split_constraints command to generate UPF
constraints for black boxes or empty modules. If a net does not have a real driver,
the primary supply for the domain is used. Black boxes are the only hierarchical cells
where the set_port_attributes command or the set_related_supply_net (SRSN)
command can be used to override the supply information.
You should create abstracts for black boxes in your design, as this creates black box
timing cells. In addition to providing drive and load information for outputs and inputs,
these cells also provide drivers and receivers on the net and enable mulitvoltage-related
commands such as check_mv_design to perform as expected.
6
Planning I/Os and Flip-Chip Bumps
After creating the floorplan, you can instantiate the I/O drivers and bump cells for your
design. The IC Compiler II tool supports advanced features for unconstrained and
constraint-based placement of I/O drivers and flip-chip bump cells. You can create I/O
placement constraints and specify the ordering, xy coordinate, and placement side for
each I/O. The tool supports both package-driven and die-driven I/O placement flows, and
you can adapt the tool for different chip packaging scenarios. Different I/O driver styles,
such as pads with integrated drivers, are supported by the tool.
Chip I/Os can be placed along the chip periphery or in islands within the chip core.
Constraints include signal constraints and power constraints to specify I/O adjacency
requirements and power requirements. You can perform I/O placement by using Tcl
commands and GUI interfaces.
The flow for instantiating I/O drivers and pads is shown in Figure 22.
• Filler and break cells: the design_type attribute must be set to pad_spacer.
• Corner cells: the design_type attribute must be set to corner.
Property types and attribute settings on the frame view for flip-chip library cells can be
examined in the IC Compiler II Library Manager as shown in the following figure.
Note that the design_type attribute setting can be derived from the LEF file for the library
cell. A value of pad is created based on the "PAD" macro class in the LEF file. A value of
flip_chip_pad is created based on the "COVER BUMP" macro class in the LEF file.
Some attributes of a library reference cell can be overridden by using the set_attribute
command in the IC Compiler II tool. Attribute settings performed in the IC Compiler II tool
are not propagated to the reference library.
For macros, the default design_type attribute setting is macro and bump assignment is
not performed. To perform bump assignment for macros, you must create matching types
that include macros, pins of macros, or terminals of macro pins. Matching any part of the
macro is sufficient for the place_io command to identify a cell instance. To identify the
pins that are assigned to bumps, do one of the following:
• Explicitly include the pin in the matching type. This is the recommended methodology.
• Set the class attribute to bump for any terminal pin during library preparation, or use
the set_attribute command in the IC Compiler II tool.
You can also use four create_io_guide commands to create I/O guides on the left, top,
right, and bottom sides of the die.
icc2_shell> create_io_guide -name "ring_left" -line {{0 300} 3000} \
-side left
{ring_left}
icc2_shell> create_io_guide -name "ring_top" -line {{300 3640} 3000} \
-side top
{ring_top}
icc2_shell> create_io_guide -name "ring_right" -line {{3680 3380} 3000} \
-side right
{ring_right}
icc2_shell> create_io_guide -name "ring_bottom" -line {{3380 0} 3000} \
-side bottom
{ring_bottom}
icc2_shell> get_io_guides
{ring_left ring_top ring_right ring_bottom}
Alternatively, you can use the Floorplan Task Assistant to create the I/O rings and I/O
guides in the GUI. Select Task > Task Assistant, then select Floorplan Preparation > I/O
Planning > I/O Ring and Guide. Enter the information for the I/O ring or I/O guide and click
Apply to create the ring or guide.
I/O Ring and I/O Guide Tasks
Use options with the create_io_ring and create_io_guide commands to control how
the ring is created:
• Assign a name to the ring with the -name option. The name is used as a prefix for the
I/O guide names.
icc2_shell> create_io_ring -name outer_ring
{outer_ring}
icc2_shell> get_io_rings
{outer_ring}
icc2_shell> get_io_guides
{outer_ring.left outer_ring.bottom outer_ring.right outer_ring.top}
• Create a ring inside an existing ring with the -inside option. The existing ring is used
as the outer boundary for the new ring.
icc2_shell> create_io_ring -name inner -inside outer_ring
• Specify the distance between the inner and outer ring boundaries with the -offset
option.
icc2_shell> create_io_ring -name inner -inside outer -offset 500
• Create a ring within a specific bounding box with the -bbox option.
icc2_shell> create_io_ring -bbox {{1000 1000} {2000 2000}}
• Specify a list of pad cell instances to assign to the ring with the -pad_cell_list
option.
icc2_shell> create_io_ring -pad_cell_list {pad_iopad_0 pad_iopad_1}
• Include specific I/O guides in the ring with the -guides option.
icc2_shell> get_io_guides
{ring_left ring_top ring_right ring_bottom}
• Specify the minimum distance between the startpoint of the I/O guide and the first I/O
driver, and the minimum distance between the endpoint of the I/O guide and the last
I/O driver with the -offset option of the create_io_guide command.
Editing, Reporting, and Removing I/O Guides and I/O Rings
• Add I/O pad cells to an I/O guide with the add_to_io_guide command.
icc2_shell> add_to_io_guide guide_left {pad_iopad_0 pad_iopad_1}
• Create a collection of I/O guides with the get_io_guides command and create a
collection of I/O rings with the get_io_rings command.
icc2_shell> get_io_guides
{guide_left guide_top guide_right guide_bottom}
icc2_shell> get_io_rings
{ring_outer}
• Remove I/O pad cells from an I/O guide with the remove_from_io_guide command.
icc2_shell> remove_from_io_guide guide_left {pad_iopad_0 pad_iopad_1}
total 2 cells removed from io guide
• Remove an I/O guide from an I/O ring with the remove_from_io_ring command.
icc2_shell> remove_from_io_ring ring_outer {guide_left guide_top}
• Report I/O rings or I/O guides in the block with the report_io_rings and
report_io_guides commands.
• Remove I/O rings or I/O guides from the block with the remove_io_rings and
remove_io_guides commands.
• Create a name for the bump array with the -name option.
• Specify a rectangular bounding box to contain the bump cells with the -bbox option.
icc2_shell> create_bump_array -lib_cell BUMP -delta {150 150} \
-bbox {{1000 1000} {3000 3000}}
• Create the bump array within a complex rectilinear shape with the -boundary option.
icc2_shell> create_bump_array -lib_cell BUMP -delta {150 150} \
-boundary {{1000 1000} {3000 1000} {3000 3000} {1000 3000}}
• Limit the bump array size by number of columns or number of rows with the -repeat
option. Bumps are centered in the die or bounding box.
icc2_shell> create_bump_array -lib_cell BUMP -delta {150 150} \
-repeat {5 5}
• Set the spacing between the lower-left corner of the bump array bounding box and the
lower-left corner of the bump cell instance at column 0 and row 0 with the -origin
option.
icc2_shell> create_bump_array -lib_cell BUMP -delta {150 150} \
-origin {1000 1000}
• Specify the orientation of each bump cell in the bump array with the -orientation
option.
icc2_shell> create_bump_array -lib_cell BUMP -delta {150 150} \
-orientation N
The inline keyword places bump cells at each point in the array specified by the
-delta option. The staggered_1 keyword places bump cells at points where the sum
of the column index and the row index is even. The staggered_2 keyword places
bump cells at points where the sum of the column index and the row index is odd.
Figure 25 shows a small bump placement example that uses these three placement
patterns.
The following bump pattern file is used in this example; the layout result is shown in
Figure 26.
# Bump pattern file for area I/O pad cluster
bump_lib_cell BUMP_PAD // Bump library cell
bump_pitch 150 // (A) Bump pitch
The pattern file specified by the -file_name option defines the bump library cell, bump
placement pitch, spacing, matching types, and other information used to create the bump
pattern. Commented lines begin with a pound sign (#), and inline comments begin with two
forward slashes (//). The pattern file uses the following format:
• bump_lib_cell: The bump library cell; specify the bump library cell as library_cell or
library_name/library_cell
• bump_pitch: The bump pitch in microns
• io_group: The I/O group description, surrounded by curly braces ({}), contains the
following information:
◦ I/O pad instance names: The list of instance names specified within curly braces.
Each instance name is specified within its own curly braces together with an
optional matching type prefix. If no matching type prefix is specified, the “s”
matching type prefix is used. Bump instance names are based on the I/O pad name
of the first instance.
In this example, the {vss g0_} item creates a bump cell with an instance name
of bus_3_n and a matching type named g0_bus_3. “g0_” is the matching type
prefix. “bus_3” is the first I/O pad specified and this string is used for all bump cell
instances created with this pattern file.
◦ orientation: (Optional) the orientation specification, either row, column, or
perpendicular.
If the orientation keyword is omitted, the command places the bump cells based
on the height and width of the I/O pad bounding box. If the width is greater than the
height, the tool places the bump cells in columns. If the height is greater than the
width, the command places the bump cells in rows.
◦ Pad ordering and spacing: The ordering and spacing list is specified within curly
braces; a pattern file can contain multiple ordering and spacing sections. The
specification is as follows:
▪ Center line offset: The distance in microns between the center line of new bump
cells the center line of the bounding box defined by the I/O pads
▪ Left or bottom first bump spacing: The distance between the left or bottom edge
of the I/O pad bounding box and the nearest bump cell center
▪ Left or bottom bump cells: The list of matching type prefixes corresponding to
the matching type prefixes defined in the list of I/O pad instances
▪ Right or top first bump spacing: The distance between the right or top edge of
the I/O pad bounding box and the nearest bump cell center
▪ Right or top bump cells: The list of matching type prefixes corresponding to the
matching type prefixes defined in the list of I/O pad instances
▪ orientation: (Optional) the orientation specification for this group, either row,
column, or perpendicular.
The following figure shows the layout result created by the example bump pattern file.
10
11
1
3
0
2
9
3_
3_
3_
3_
3_
3_
3_
3_
3_
3_
3_
3_
s_
s_
s_
s_
s_
s_
s_
s_
s_
s_
s_
s_
bu
bu
bu
bu
bu
bu
bu
bu
bu
bu
bu
bu
p_
_
_
s
p1
g1
g0
The following figure shows how the spacing values in the pattern file correspond to the
bump cell and I/O pad cell spacings in the layout.
bump_lib_cell BUMP_PAD
bump_pitch 150 // (A)
(D) io_group {
(B) {{bus_3} {bus_2}
...}
{orientation row}
{{-50} // (B)
{100} // (C)
{s ...} // Left bumps
(A) {75} // (D)
{s ...} // Right bumps
(C)
}
}
You can create more complex bump patterns by including multiple groups of row or
column specifications. The following bump pattern file creates three rows of bump cells by
including three groups of offsets and matching types. Each row contains two bumps to the
left of the I/O drivers and two bumps to the right of the I/O drivers.
# Pattern file for three bump rows
bump_lib_cell BUMP_PAD // bump lib cell
bump_pitch 200 // pitch
The layout result is shown in the following figure with cells highlighted by matching types.
s s p_ g0_
p1_ s g1_ s
s s s s
names for the bump cells in the block. Use the -hierarchy option to read in bump cell
and I/O pad locations and place the I/O pads in any level of physical hierarchy.
icc2_shell> read_aif bumps.aif
{{reference: VSS_EW}
{ratio: 7}
{prefix: VSS}
{connect: {VSSIO VSSIO} {VDD VDD1} {VSS VSS1}}}
Power IO constraints set successfully
1
In this example, -share {{2 VDD_NS} {3 VSS_NS}} allows up to two VDD power
pads to drive a single VDD bump cell, and three VSS power pads to drive a single VSS
bump cell.
• Define the number of signal pads that can be placed between successive power pads
with the -ratio option.
icc2_shell> set_power_io_constraints \
-reference_cell {VDD_NS VSS_NS} -ratio {{7 VDD_NS} {6 VSS_NS}}
In this example, the tool places no more than seven I/O pads between VDD_NS pad
cells, and no more than six I/O pads between VSS_NS pad cells.
• Specify the maximum spacing between successive power pads of the same type with
the -spacing option.
icc2_shell> set_power_io_constraints -reference_cell {VDD_NS VSS_NS} \
-spacing {{100 VDD_NS} {100 VSS_NS}}
• Specify the maximum distance between the starting point of the I/O guide and the
closest edge of the first power pad of the specified type with the -offset option.
icc2_shell> set_power_io_constraints -reference_cell {VDD_NS VSS_NS} \
-offset {{100 VDD_NS} {100 VSS_NS}}
Alternatively, you can write out the signal I/O placement constraints with the
write_io_constraints -filename constraint_file_name command and use the
set_signal_io_constraints -file constraint_file_name command to load the
constraints. The constraint file is useful when there is a large number of signal constraints
to specify. The following example loads signal I/O placement constraints from the
signal_io_constraints.txt constraints file.
icc2_shell> set_signal_io_constraints -file signal_io_constraints.txt
Signal IO constraints set successfully
1
icc2_shell> sh cat signal_io_constraints.txt
_default_io_ring1.left
{{order_only}
u_p/clk_pad_P1
u_p/sdclk_pad_P1
u_p/test_so_4_pad_P1};
Signal ordering begins at the lower-left pad for the left edge, the upper-left pad for the top
edge, the upper-right pad for the right edge, and the lower-right pad for the bottom edge
as shown in Figure 30.
top
Corner Corner
start end
start
end
right
left
start
end
end start
Corner Corner
bottom
In the following example, a signal I/O constraints file creates an ordering and spacing
constraint for the top I/O guide in the ring. The constraint creates an 80 micron gap
between the start of the I/O guide and the first signal I/O pad. A 55 micron pitch is used
to place the Pad_1, Pad_2, and Pad_3 I/O drivers. The constraint creates a 10 micron
spacing between the Pad_3 and Pad_4 I/O drivers, a 40 micron spacing between Pad_4
and Pad_5, a 60 micron spacing between Pad_5 and Pad_6, and no spacing between
Pad_6, Pad_7, and Pad_8. Example 15 shows the signal I/O constraint file, and Figure 31
shows the layout results after running the place_io command.
Pad_2
Pad_3
Pad_4
Pad_5
Pad_6
Pad_7
Pad_8
80
55 55 10 40 60
To set an offset value for each I/O pad, specify both the “Pad Name” and “Offset Value”
fields as shown in the following example. Any other fields, such as the “Comment” field in
this example, are for information only and are not used by the tool:
icc2_shell> sh cat iopads_offsets.csv
Pad Name,Offset Value,Comment
pad0,200,pad0 offset is 200
pad1,400,pad1 offset is 400
pad2,600,pad2 offset is 600
pad3,800,pad3 offset is 800
pad4,1000,pad4 offset is 1000
pad5,1200,pad5 offset is 1200
pad6,1400,pad6 offset is 1400
pad7,1600,pad7 offset is 1600
If your CSV file contains custom column names, create a map file with comma-separated
pairs of custom column names and standard column names and use the -map_file
option to specify the map file name with the set_signal_io_constraints command. The
following example uses the custom column names REFERENCE_CELL, PAD_NAME, and
PAD_OFFSET in the CSV file. The map file lists the custom column name and standard
column name, separated by a comma. Note that the REFERENCE_CELL column is not
used by the tool and is not included in the map file.
icc2_shell> sh head ioconstraints2.csv
REFERENCE_CELL,PAD_NAME,PAD_OFFSET
B4ISH1025_EW,pad_iopad_0,0
B4ISH1025_EW,pad_iopad_1,100
...
The following figure shows the design after running the place_io command without the
previous constraint and with the constraint.
To verify the assignments, use the RDL Flylines panel in the GUI to view the assignments.
Choose View > Flylines > RDL Flylines from the menu and select the RDL net names to
view the RDL flylines.
After creating the matching types, use the check_pre_place_io command with the
-matching_types option to check the following:
The place_io command applies the matching type assignments to the pad and bump
cells; this command is required to view the updated flylines with the RDL flylines panel.
Figure 34 shows the RDL flyline connections created by the place_io command. View
RDL flylines in the layout by choosing View > Flylines > RDL Flylines in the GUI.
• Create a collection of cells that are assigned a specified matching type name with the
get_cells command and matching_type.name attribute.
icc2_shell> get_cells -filter "matching_type.name == SIGNAL"
{pad_iopad_49 pad_iopad_48 ...
icc2_shell> get_cells -filter "matching_type.name =~ SIG*"
{pad_iopad_49 pad_iopad_48 ...
• Add I/O pad or bump cells to the matching type with the add_to_matching_type
command.
icc2_shell> add_to_matching_type match2 {pad_iopad_40 pad_iopad_41}
If you did not create any matching type assignments, the file is empty.
• Write out the default matching types assigned by the tool with the
write_matching_types -from_existing_assignment command.
icc2_shell> write_matching_types -from_existing_assignment \
-file_name existing.tcl
1
You can re-create the matching types at a later time by sourcing the file written by the
write_matching_types command.
icc2_shell> source existing.tcl
• Create a list of matching types and associated I/O pad or bump cells with the
report_matching_types command.
icc2_shell> report_matching_types match2
Matching Type Uniquify Object Type Object Name
------------------------------------------------------
match2 0 cell left_24_0
cell left_24_1
cell pad_iopad_42
cell pad_iopad_43
...
2. Write out the I/O placement constraints file based on the current I/O placement with the
write_io_constraints command.
icc2_shell> write_io_constraints -filename io_constraints.txt
1
icc2_shell> sh cat io_constraints.txt
_default_io_ring1.left
{{order_only} u_p/test_si_13_pad_P1
u_p/data_pad_1_x0_3_P1
u_p/data_pad_2_x0_3_P1
u_p/data_pad_2_x0_2_P1
...
The place_io command supports options to control how I/Os are placed. Use the
-io_guide io_guide_list option to place I/Os only in the specified I/O guides. If the
I/O guide is not long enough to contain all pads, the pads are placed after the endpoint
of I/O guides. Use the -rule rule_name option to specify a single routing spacing rule
for redistribution layer (RDL) routes. Use the -incremental option to place additional I/O
drivers for nonflip-chip designs.
Note that the place_io command removes existing filler cells if the physical_status
property is not set to fixed. This condition occurs when all pads are considered during
flip-chip I/O placement. If only a fraction of pads are incrementally replaced, then filler cells
are not removed.
If you dedicate a matching type to a collection of only bump cells, the tool does not
connect these bump cells to I/O drivers. Use this feature to reserve certain bump cells for
power or ground and avoid connecting the bump cells to I/O driver cells. If you apply a
matching type to I/O drivers, I/O driver pins, and I/O driver terminals, but do not assign a
matching type for bumps, the place_io command skips bump assignment and continues
to place other I/Os. If an I/O driver pin is already connected to a bump through a two-
pin net, the pad pin remains connected to the bump. For isolated pad cells which are not
assigned to an I/O guide, the tool locates the closest unassigned bump cell and calculates
a flyline route between the pad cell and bump cell. For groups of pad cells not within an
I/O guide, the tool creates a virtual I/O guide.
The write_io_constraints command supports options to control the name and contents
of the output file. Use -filename file_name option to specify the output constraints file
name. Use the -format order_only | spacing | pitch | fixed option to specify the
type of constraints to write to the output file. The order_only argument writes only pad
order information to the file. The spacing argument writes the spacing values between
pads and the pad cell names to the file. The pitch argument writes pad cell locations by
using cell pitch instead of spacing values and requires that all pad cells be placed evenly
in the I/O guide. The fixed argument specifies that all pad cells are fixed at their current
locations.
VDDO = 2V VDDO = 3V
corner
VSSO
VDDO
VDDI
VSSI
r
r
d
d
k
le
le
pa
pa
pa
pa
pa
ea
fil
fil
br
d
pa
For information about inserting these cells, see the following topics:
• Inserting Corner Cells
• Inserting Break Cells
• Inserting Filler Cells
• Place an existing corner cell instance at the intersection of the I/O guides named
“bottom” and “right.”
icc2_shell> create_io_corner_cell -cell corner_cell_1 {bottom right}
• In a design with multiple levels of hierarchy and overlapping blocks, insert a reference
of the corner cell named “CORNER” at the intersection of the I/O guides named “right”
and “top” and instantiate the corner cell within the I_ORCA_TOP block.
icc2_shell> create_io_corner_cell \
-reference_cell CORNER {right top} -force I_ORCA_TOP
Use the -location end option to place the break cell just after the end of the I/O
guide. Use the -location both option to place the break cell at both ends of the I/O
guide.
• Move the existing break_cell_1 instance 600 microns from the start of the I/O guide
named “left”.
icc2_shell> create_io_break_cells -cells break_cell_1 \
-location 600 left
• Insert a reference of the break cell named “BREAK” at the intersection of the I/O guides
named “top” and “right”.
icc2_shell> create_io_break_cells -reference_cells BREAK {right top}
• Insert filler cell references FILLER10A on I/O guides named “top” and “right”. An error
message is issued if gaps remain after inserting the filler cells.
icc2_shell> create_io_filler_cells -reference_cells FILLER10A \
-io_guides {right top}
Error: In IO guide right, filler cells cannot cover the gap
at (6500,6090) with length 2. (DPI-089)
• Insert filler cell references FILLER10A on the I/O guides named “guide_1” and force
the filler cell to be placed within the block named “top”. In this example, the guide_1 I/O
guide overlaps multiple blocks and the design contains multiple levels of hierarchy.
icc2_shell> create_io_filler_cells -reference_cells FILLER10A \
-io_guides guide_1 -force top
• Check for overlapping cells with the -overlap overlap_checks option, where
overlap_checks is one or more of: pad2pad, pad2filler, filler2filler, bump,
corner2pad, or all.
icc2_shell> check_io_placement -overlap {pad2pad bump}
---------- Start of Overlap Check ----------
Pad u488 and pad u547 overlap.
Pad u488 and pad u553 overlap.
Total 3 cells have overlap violation.
---------- End of Overlap Check ----------
• Check the placement of I/O cells against the minimum pitch specified for the I/O guide
with the -min_pitch option.
icc2_shell> check_io_placement -min_pitch
---------- Start of Min Pitch Check ----------
bus_0 to bus_4 violates min_pitch 5. Current spacing is 28.
bus_2 to bus_7 violates min_pitch 5. Current spacing is 42.
Total 2 violations are found.
---------- End of Min Pitch Check ----------
• Check whether I/O pad placement is consistent with the is_flipped attribute for the
pad with the -flipping option.
icc2_shell> check_io_placement -flipping
---------- Start of Pad Flip Check ----------
Pad bus_0 is not flipped, but has
is_flipped attribute set to true.
Total 3 violations are found.
---------- End of Pad Flip Check ----------
• Check for spaces between I/O cells, including pads, corners, fillers and break cells,
with the -gap option.
icc2_shell> check_io_placement -gap
---------- Start of Gap Check ----------
Cell bus_0 and cell bus_4 have a gap between them.
Total 2 cells have gap violation.
---------- End of Gap Check ----------
• Check the I/O pad placement against constraints set with the
set_signal_io_constraints command by using the -signal_constraints option.
icc2_shell> check_io_placement -signal_constraints
---------- Start of Signal I/O constraints Check ----------
The order of pad bus_1 and pad vss violates I/O guide
default_guide_0 order constraint.
The order of pad bus_6 and pad bus_1 violates I/O guide
default_guide_0 order constraint.
Total 2 violations are found.
---------- End of Signal I/O constraints Check ----------
Signal I/O constraints include order, pitch, spacing, offset of pads and boundary
spacing.
• Check whether I/O pads are placed on the correct I/O guides with the
-pad_to_guide_assignment option.
icc2_shell> sh cat padAssign
bus_5 default_guide_0 default_guide_2;
{bus_1 bus_6} default_guide_0;
-pad_assignment_file padAssign
---------- Start of Pad to Guide Assignment Check ----------
Pad bus_5 violates pad-to-guide constraints: assigned to
IO guide default_guide_0, but placed outside of
default_guide_0 with 500 gap.
Total 1 violation is found.
---------- End of Pad to Guide Assignment Check ----------
Use the -pad_assignment_file option to specify a file that contains I/O pads and
corresponding I/O guides. The format of the file is
pad1 guide1;
pad2 guide2 guide3;
{pad3 pad4} guide4;
where one or more I/O guides can be specified for a single pad or collection of pads,
and collections of I/O pads are surrounded with curly brackets ({}).
• Write the I/O placement report to a specific file with the -filename option.
icc2_shell> check_io_placement -filename io_placement_report.txt
• Write out I/O placement violation reports to a specific directory with the
-output_directory option.
icc2_shell> check_io_placement -output_directory io_checks
Writing IO placement checking reports to directory io_checks.
icc2_shell> ls io_checks/*
io_checks/bumpassignment_violations.rpt
io_checks/flip_violations.rpt
io_checks/gap_violations.rpt
io_checks/minPitch_violations.rpt
io_checks/overlap_violations.rpt
io_checks/pad2guide_violations.rpt
io_checks/powerIOConstraints_violations.rpt
io_checks/signalIOConstraints_violations.rpt
io_checks/unplacedpads_violations.rpt
The command creates the specified directory and writes out individual files for each
violation type.
6. (Optional) Write out an error database for the Error Browser in the GUI.
icc2_shell> report_rdl_routes -create_error_data verification
Use the verification keyword with the -create_error_data option to write out
error data for open and short violations. Use the flyline_only keyword to write out
flyline data.
Figure 36 shows the layout result after RDL routing. The RDL nets are routed at 90-degree
angles and connect the I/O drivers and bump cells.
• Create an RDL route on an adjacent layer that overlaps the current route by using the
split_rdl_routes command.
icc2_shell> split_rdl_routes -nets {pad[48] pad[49]} \
-mode adjacent_layer -via_interval 25 -from_layers MRDL \
-to_layers M9
The tool adds a parallel route on the M9 layer and inserts vias as shown in the upper
two routes in Figure 38.
• Split an existing route into multiple thin routes on the same layer with the
split_rdl_routes command and the -widths, -spacings, and -number_of_routes
options.
icc2_shell> split_rdl_routes -nets {pad[46] pad[47]} \
-widths {MRDL {2 2 2}} -spacings {MRDL {2 2}} \
-number_of_routes {MRDL 3}
The tool splits the existing route into multiple thin routes as shown in the lower two
routes in Figure 38.
• Create length-matched routes for the specified routes by using the
route_rdl_differential command.
icc2_shell> route_rdl_differential -layers {MRDL} \
-nets {pad[41] pad[43]}
The tool creates routes for the specified nets as shown in Figure 39.
• Create a tapered route by setting taper distances and widths with the
create_routing_rule command. Create the tapered route with the
route_rdl_flip_chip command.
icc2_shell> create_routing_rule taperrule \
-widths {MRDL 10 M9 10} -spacings {MRDL 10 M9 10} \
-rdl_taper_distances {MRDL 40 M9 40} \
-rdl_taper_widths {MRDL 5 M9 5}
icc2_shell> set_routing_rule [get_nets $rdl_nets] -rule taperrule
icc2_shell> route_rdl_flip_chip -layers {MRDL M9} -nets $rdl_nets
• Create an RDL route between a bump cell and a power ring net by setting the
flip_chip.route.route_to_ring_nets application option to the net name. Use
the flip_chip.route.route_to_stripe_nets application option to create an RDL
route between a bump cell and PG net shape in the PG mesh. The following example
specifies these application options.
icc2_shell> set_app_options \
-name flip_chip.route.route_to_ring_nets -value VDD1
icc2_shell> set_app_options \
-name flip_chip.route.route_to_stripe_nets -value VDD1
icc2_shell> route_rdl_flip_chip -layers $rdl_layers -nets VDD1
The layout for a typical flip-chip route is shown on the left; the layout for the flip-chip
route created by the preceding commands is shown on the right.
• Create additional stacked vias between RDL routes and I/O driver pins by setting the
flip_chip.route.extend_vias_on_pin application option as shown in the following
figure. By default, the value is false and the tool creates a simple connection to the
pin. Set the application option to true to extend the wire and insert additional stacked
vias. The width of the wire extension is the same as the wire width defined by the
routing rule. Set the application option to full_pin to extend and widen the wire to
cover the pin and insert additional stacked vias. The tool ignores the route width set by
the routing rule and attempts to cover the entire I/O driver pin.
icc2_shell> set_app_options \
-name flip_chip.route.extend_vias_on_pin -value full_pin
Figure 42 Additional Stacked Vias for RDL Routes to I/O Driver Pins
flip_chip.route.extend_vias_on_pin
false true full_pin
• Specify the bump-to-route spacing values in microns for each flip-chip routing layer by
using the flip_chip.route.layer_bump_spacings application option. You can also
use the sameNetRDLMetalToPadMinSpacing and diffNetRDLMetalToPadMinSpacing
technology file rules to specify the bump-to-route spacing.
icc2_shell> set_app_options \
-name flip_chip.route.layer_bump_spacings \
-value {{M9 10.0} {MRDL 10.0}}
flip_chip.route.layer_bump_spacings {}
The jogRDLKeepoutRange design rule specifies the keepout range between the bump
cell and the route. The following figure shows the RDL routing result for two different
jogRDLKeepoutRange settings.
jogRDLKeepoutRange=2.0 jogRDLKeepoutRange=5.0
reducing the number of U- and Z-shaped routes in the block and create additional space
for RDL power routes. Perform the following tasks to optimize RDL routes:
• Improve RDL routing.
icc2_shell> optimize_rdl_routes -nets $rdl_nets
Figure 45 shows the layout result before and after running the previous command.
• Move signal routes to create additional routing area for power and ground routes with
the -reserve_power_resources option.
icc2_shell> optimize_rdl_routes -layer {MRDL} -nets $rdl_nets \
-reserve_power_resources true
After running the command with this option, the amount of U- and Z-shaped routes
might increase. Figure 46 shows the layout result before and after running the previous
command.
2. Create the routing rule and specify the shield spacings and shield widths.
icc2_shell> create_routing_rule shieldrule \
-shield_spacings {MRDL 2 M9 2} -shield_widths {MRDL 5 M9 5} \
-widths {MRDL 6 M9 5}
Figure 48 shows the layout result with the -shield_on_bump option set to true (left)
and false (right).
• Create a side-wall shield on one side of a net by using the -half_shield option and
specifying one of the following values: up, down, left, or right. To create a shield on
the upper or lower side of a horizontal flyline, specify up or down. To create a shield
on the left or right side of a vertical flyline, specify left or right. By default, the
create_rdl_shields command creates side-wall shields on both sides of a net.
The following figures show nets before and after coaxial shielding:
Note the following additional considerations for top-level flip-chip routing in a design with
multiple levels of hierarchy:
• Blocks which contain I/O bump cells or pad cells must be preplaced.
• I/O pad cells can be placed at the top level or at the block level.
• I/O pad cells at the block level are considered as fixed.
• I/O guides are created at the top level.
• Matching types that assign top-level bumps to block-level I/O cells must be created at
the top level.
• I/O pads are placed at the block level for blocks that contain the I/O pads.
• Block-level I/O pads should be specified with the create_matching_type command.
• For block-level I/O pads not specified with the create_matching_type command, the
pin shapes should have their class attribute set to bump in the IC Compiler II Library
Manager.
For IC Compiler II versions before N-2017.09, you can use a frame-based flow to assign
bump cells to I/O drivers in the blocks. To prepare the frame view for I/O assignment,
1. Push into the block or edit the block that contains the I/O pad.
icc2_shell> set_working_design -push [get_selection]
2. (Optional) For power and ground pins, use the create_shape -port command to
create terminal shapes based on the pin shapes of the pad cell.
Pin shapes for I/O signal pins are created automatically in the next step by the
create_frame command.
To reduce runtime when creating frame views for multiple blocks, you can create
a script that contains the create_frame command and run the script with the
run_block_script command.
5. Select the block and change the view type to the frame view of the block.
icc2_shell> change_view -view frame [get_selection]
7. Select the terminals created in step 2 in the block and change the class attribute of
terminals to bump.
icc2_shell> set_attribute [get_selection] class bump
7
Creating a 3DIC Design
In a 3DIC design, two or more die are directly stacked vertically to create a complete
design or system that contains multiple dies. In a 2.5D IC design, one or more die are
mounted on an interposer; the interposer also connects the die to each other and to the
package. The interposer can be manufactured from various materials including silicon or
glass.
The IC Compiler II tool supports a 3DIC flow and commands to create designs that contain
multiple dies. The die can be placed separately on a silicon interposer or stacked upon
each other and connected with through-silicon vias (TSV). The tool supports commands
to place the die, create the connections between the different die, and validate the 3DIC
design.
The topics in this section describe a flow used to create a 2.5D design. The term “active
die” is used to describe the logic, memory, RF, or other die that contain active devices. The
interposer is the silicon die which mounts and connects the active die and is not required
to contain active components or logic.
The flow for creating a 2.5D design with active die placed separately on a passive silicon
interposer is shown in the following figure.
The tool also supports half-node scaling of libraries in a 3DIC design. The half-node scale
factor of a library is specified by the half_node_scale_factor attribute on the library.
If the design.is_3dic_mode application option is set to true on the top design, the
coordinates in the library are scaled by the half_node_scale_factor setting when the
library is read.
3. Instantiate and place the bump cells with the create_bump_array command.
icc2_shell> create_bump_array -lib_cell BUMP -name BUMP_RING \
-delta {225 225} -bbox {{100 100} {4000 4000}}
2. Create an empty netlist for the interposer and read it with the read_verilog command.
icc2_shell> sh cat interposer.v
module interposer (dummypin);
input dummypin;
endmodule
icc2_shell> read_verilog interposer.v
The following example uses an empty interposer netlist. The top-level netlist contains
the connections. The IC Compiler II tool automatically updates the interposer netlist
with ports and all connections and creates feedthroughs as needed.
3. Initialize the floorplan for the interposer.
icc2_shell> initialize_floorplan -control_type die \
-boundary {{0 0} {15000 10000}}
4. Create the bump arrays to connect the signal and power pads of the package to the
interposer with the create_bump_array command.
icc2_shell> create_bump_array -lib_cell C4_BUMP \
-name C4_logic_SIGNAL_B -origin {500 500} -delta {190 190} \
-repeat {74 3}
...
5. Create through-silicon vias (TSVs) for each of the bump cells added in the previous
step with the derive_3d_interface command.
icc2_shell> derive_3d_interface -from [get_cells C4_logic_SIGNAL_B*] \
-to_object_ref [get_via_defs -tech [get_techs *] VIAB1] \
-name_prefix VIAB1_C4_logic_SIGNAL_B
...
6. Create matching types for signals, power, and ground nets for RDL routing.
icc2_shell> create_matching_type \
-name Signal [all_connected [get_nets *SIGNAL*]]
After performing these steps, the tool creates the interposer floorplan as shown in the
following figure. The bump cells around the periphery connect to signal bumps on the
active dies. The two bump arrays in the center connect to power and ground for the two
active dies.
Reading and Writing Bump Cell and TSV Locations Using CSV
Files
Instead of setting placement constraints and matching types to place and connect bump
cells and through-silicon vias (TSVs), you can specify location and connection information
by using one or more comma-separated values (CSV) files. Use the read_design_io
command to read the placement and connection information from the CSV file and place
the cells on the interposer. Use the write_design_io command to write out the location
information to a CSV file.
The following example writes out the locations of the bump cells and TSVs in the current
design.
icc2_shell> write_design_io -file_name bump_tsv_locations.csv
icc2_shell> sh cat bump_tsv_locations.csv
Reference_name,C4_inst,Ubump_inst,TSV_inst,X_origin,Y_origin,
Orientation,Port_name,Net_name,Comments
C4_BUMP,C4_logic_SIGNAL_B_0_0,,,500,500,R0,,C4_logic_SIGNAL_B_0_0_net,
C4_BUMP,C4_logic_SIGNAL_B_0_1,,,690,500,R0,,C4_logic_SIGNAL_B_0_1_net,
C4_BUMP,C4_logic_SIGNAL_B_0_2,,,880,500,R0,,C4_logic_SIGNAL_B_0_2_net,
...
VIAB1,,,VIAB1_C4_mem_VSS_4_0,11165,5725,R0,,,
VIAB1,,,VIAB1_C4_mem_VSS_4_1,11465,5725,R0,,,
VIAB1,,,VIAB1_C4_mem_VSS_4_2,11765,5725,R0,,,
...
The CSV file contains a header row and a row of data for each cell instance. The following
list shows a description for each field and the default name for the field in the column
header:
• Cell reference name (Reference_name)
• C4-bump instance name (C4_inst)
• U-bump instance name (Ubump_inst)
• TSV instance name (TSV_inst)
• X-origin (X_origin)
• Y-origin (Y_origin)
• Cell orientation (Orientation)
• Port name (Port_name)
• Net name (Net_name)
• Comments (Comments)
You can specify multiple input files and provide different fields in each file. Not all fields are
required for each cell instance or connection. The header row is required and describes
the keyword for each column. After the header row, each row describes a cell instance
or a connection. Cell rows specify the cell instance name, reference name, location, and
orientation of the cell. Connection rows specify connections between terminals, and port
rows are used to create a port.
If a cell instance does not exist, the tool creates the specified cell instance. By default, the
tool performs the following checks when creating new cell instances:
• Cells of the same type cannot overlap.
• A C4-bump cell can overlap an existing u-bump cell, TSV, or standard cell.
• A u-bump cell can overlap an existing C4-bump cell, TSV, or standard cell.
• A TSV can overlap an existing C4-bump cell or u-bump cell.
To disable checking, use the -overlap_check none option. To prevent any overlaps, use
the -overlap_check strict option.
If the cell instance already exists, it is moved to the specified location. If the cell instance
overlaps an existing instance, it is skipped. The tool issues warning messages when
reading an invalid row and skips the row.
By default, if a port does not exist, the tool ignores it. To create the port instead, use the
-create_ports option.
By default, if a port or net already exists, it retains the current setting of its port_type or
net_type attribute. To set this attribute to power for specific ports or nets, use the -power
option. To set this attribute to ground for specific ports or nets, use the -ground option. If
the ports or nets specified in these options do not exist, the tool creates them.
If your CSV file contains custom column names, create a map file with a list of custom
column names and standard column names, then specify the map file with the -map_file
option. Each line in the map file contains the comma-separated custom column name and
corresponding standard column name as shown in the following example.
custom_reference_name,Reference_name
custom_C4_instance_name,C4_inst
...
In the following example, the locations_mapped.csv file uses custom column names and
the mapfile.txt file contains the list of custom column names and the standard column
names.
icc2_shell> sh head mapfile.txt
re,Reference_name
c4,C4_inst
ub,Ubump_inst
ts,TSV_inst
...
Use other options with the read_design_io command to control how the CSV file is read.
• Specify a delimiter character with the -delimiter_char option.
icc2_shell> sh head location_splat.csv
Reference_name!C4_inst!Ubump_inst!TSV_inst!X_origin!...
C4_BUMP!C4_logic_SIGNAL_B_0_0!!!500!500!R0!!!
C4_BUMP!C4_logic_SIGNAL_B_0_1!!!690!500!R0!!!
C4_BUMP!C4_logic_SIGNAL_B_0_2!!!880!500!R0!!!
...
◦ -objects: Output only the specified objects. The specified objects must be C4-
bump cells, u-bump cells, or TSVs.
◦ -within: Output only the C4-bump cells, u-bump cells, and TSVs that are within the
specified bounding box.
• Specify the cell origin location.
By default, the command uses the lower-left corner of a cell as its origin. To use the cell
center instead, use the -cell_origin_type center option. When you use this option,
the tool calculates the cell center based on its bounding box.
input pllref ;
...
leon3mp_chip logic_die_inst (.resetn(resetn), ...);
mem mem_die_inst (.sa(sa), .sd(sd), ...);
interposer interposer_inst ();
endmodule
To create a top-level design that contains the active dies and interposer,
1. Create the design library to contain the top-level design.
icc2_shell> create_lib top.ndm -technology top.tf \
-ref_libs {mem.ndm leon3mp.ndm interposer.ndm}
Because the top-level design has references to the active dies and the silicon
interposer, the reference libraries must include the silicon interposer library and the
library for each active die.
2. Read the Verilog netlist for the top-level design.
icc2_shell> read_verilog top.v
5. Place the interposer and active dies with the set_cell_location command. Note
the -z_offset option that specifies the relative z-location for the interposer and active
dies.
icc2_shell> set_cell_location interposer_inst \
-coordinates {0 0} -z_offset 0 -orientation N
icc2_shell> set_cell_location logic_die_inst \
-coordinates {2500 2600} -z_offset 1 -orientation FN
icc2_shell> set_cell_location mem_die_inst \
-coordinates {10300 3000} -z_offset 1 -orientation FN
6. Confirm the placement of the interposer and active dies with the
report_3d_chip_placement command.
icc2_shell> report_3d_chip_placement -all
---------------------------------------------------------------------
chip_name stack_z location orientation scaling_factor
------------------------------------------------------------------
logic_die_inst 1 (2500 2600) FN 1
mem_die_inst 1 (10300 3000) FN 1
interposer_inst 0 (0 0) N 1
---------------------------------------------------------------------
To review the z-ordering of the active dies and interposer, you can also query the
z_order attribute on the die instances. Alternatively, click the Layers tab in the View
Settings panel to view the z-order (Z level) setting associated with each die instance as
shown in the following figure.
7. (Optional) Determine if there are any overlaps between the active dies by using the
check_3d_design command with the -chip_placement option.
icc2_shell> check_3d_design -chip_placement
8. Save the design, save the library, and close the library.
icc2_shell> save_block
icc2_shell> save_lib
icc2_shell> close_lib
10. Ensure the blocks are editable by using the set_editability command.
icc2_shell> set_editability \
-blocks leon3mp_chip.ndm:leon3mp_chip.design
icc2_shell> set_editability -blocks mem.ndm:mem.design
icc2_shell> set_editability -blocks siip.ndm:interposer.design
11. Create bump cells on the interposer by copying the bump cell locations from the two
active dies.
icc2_shell> create_3d_mirror_bumps -from mem_die_inst \
-to si_interposer_inst -ref_cell BUMP -prefix mem
icc2_shell> create_3d_mirror_bumps -from logic_die_inst \
-to si_interposer_inst -ref_cell UBUMP -prefix logic
When the source and target dies are stacked vertically, this command copies and
places bump cells, bump clusters, and bond pads from the source die to the target die.
The tool also supports 3DIC flows that copy the bump locations from the interposer to
the dies.
If you are creating mirror bump cells for the pins of hard macro cells, use the -pins
option with the create_3d_mirror_bumps command to specify the hard macro pins.
12. (Optional) Create logical connections between the bump cells or pseudo bumps on the
interposer added in the previous step and the bump cells on the active dies with the
propagate_3d_connections command.
icc2_shell> propagate_3d_connections
Created 215 new nets after inter-chip nets splitting.
Propagate 67 nets.
15. Copy the matching types of cells, pins, and terminals to other pins with the
propagate_3d_matching_types command.
icc2_shell> propagate_3d_matching_types
==============================================================
After copying the matching types, you can use the report_matching_types command
to display the matching types assigned by the propagate_3d_matching_types
command.
16. Assign connections between the bump cells or pseudo bumps and nearest driver cells
with the assign_3d_interchip_nets command.
icc2_shell> assign_3d_interchip_nets
...
Doing assignment between chip logic_die_inst and
si_interposer_inst.
Successfully assigned 149 nets between chip logic_die_inst and
si_interposer_inst.
...
Doing assignment between chip si_interposer_inst and Package.
Successfully assigned 149 nets between chip si_interposer_inst
and Package.
The virtual interface block contains the ports, nets, shapes, and vias at the
interfaces between two stacked dies and between a die and the interposer. The
create_3d_virtual_blocks command supports options to modify the netlist and connect
the interface information, or only add the interface information without connecting it to the
existing blocks as shown in the following examples.
• Create a virtual interface block between the mem_inst block and the interposer_inst
block and copy four layers from mem_inst and two layers from interposer_inst.
icc2_shell> create_3d_virtual_blocks \
-blocks {{mem_inst:4} {interposer_inst:2}}
• Create a virtual interface block between the mem_inst block and the logic_inst block
and copy four layers from both blocks.
icc2_shell> create_3d_virtual_blocks \
-blocks { logic_inst mem_inst} -layers 4
• Create virtual interface blocks between all dies and the interposer based on the z-
offset attribute setting for the block. The virtual interface blocks are connected to the
top-level netlist.
icc2_shell> create_3d_virtual_blocks -in_netlist
2. Create the PG strategy to associate the pattern with the region of the interposer
beneath the active die.
icc2_shell> set_pg_strategy strat1 \
-pattern {{name: mesh1} {nets: VDD_mem VSS_mem}} \
-polygon {{11060 3800} {12095 6755}}
The tool processes different types of pattern files based on the interposer style you
choose. The pattern file contains the constraints and other data used to create and place
the vias and route guides.
You can specify additional routing guidance by modifying the pattern file. For example, you
can
• Create vias between bump cells and metal layers on the interposer
• Specify via definitions, via locations, a single via or a stacked via, and via spacing rules
• Route wire stubs to other wire stubs and vias (point-to-point routing)
• Route pre-placed landing vias to bumps
The pattern file is an ASCII file containing constraints and directives to drive the
create_interposer_routeplan command. It contains one or more sections, where
each section begins with a keyword followed by a pair of curly brackets. Constraints are
specified inside the curly brackets. The tool uses a default pattern file unless you modify
the file with new constraints and specify the updated file with the -pattern_file option.
To see a single_hbm interposer style pattern file, see Pattern File Example.
The following example creates single vias between the RDL routing layer and the top
metal layer for all bump cells.
icc2_shell> create_interposer_routeplan -pattern_file interposer.pat
The following routing strategy is beneficial for routing high-bandwidth memory designs.
Use this strategy for high-density, high-bandwidth memory designs only.
• Routing bumps to landing vias
You can direct the router to search for the closest via on the same net as
a bump and connect the bump to the via, as shown in the following figure:
Vias that touch a bump are considered connected and do not need to be routed unless
there are DRC violations between the bump and via.
• Point-to-point routing
After routing bumps to landing vias, you can specify point-to-point connections to route
between bumps, landing vias, and wire stubs by providing the following information in a
route plan file before routing:
#netName #layer #point1_x #point1_y #point2_x #point2_y
The route plan file specifies the net to be routed, the connection points, and the target
routing layer for the point-to-point connections.
The connection points must meet the following requirements:
◦ The points must fall inside the same net shapes, such as wire, via, or pin shapes.
◦ For wire shapes, the point must be exactly at the endpoint of the wire. However, the
router does not necessarily connect to pins and vias exactly at the point specified in
the file.
◦ The points must be on the minimum grid.
◦ The points must be on coordinates that do not have DRC violations, meaning
that when routing a wire to the specified point, there are no DRC violations with
neighboring shapes. Routing pairs with DRC violations are left unrouted.
In the following example, the RDL router routes the Net1 net from point (10.5, 15.0) to
point (20.5, 20.0) on the AP layer:
Net1 AP 10.5 15.0 20.5 20.0
The following example routes the interposer for a high-bandwidth memory design:
### Open the floorplanned interposer block
open_lib interposer_floorplan
open_block interposer
### Create the interposer RDL vias and route guides (routeplanning)
### Set the style to HBM and specify the pattern constraint file
set net_all “DQa24 DMa2 DMa3 DQa16 DQa27 DQa26 DQa25 DQa20 \
DQa21 RDQSa0_t DQa28 DQa29 DERRa0 RDQSa0_c DQa18 DQa19 DQa17 \
RDa1 DQa22 DQa23 DBIa3 DQa31 DQa30 DBIa2 DMe2 DQe25 DMe3 \
RDQSe0_t DQe18 DQe19 DQe16 DERRe0 DQe26 DQe27 DQe24 DQe17 \
DQe30 DQe23 DQe21 DQe20 RDQSe0_c DQe31 DQe29 DQe28 RDe1 DBIe2 \
DQe22 DBIe3”
### Set the options for via-to-stub routing on the lower layers
set_app_options \
-name flip_chip.route.point_to_point_connection_file_name \
-value hbm_p2p.txtM2
set_app_options \
-name flip_chip.route.point_to_point_connection_file_name \
-value hbm_p2p.txtM4
2. Create the routing rules. In this example, AP is the RDL metal layer and MB is the
backside metal layer.
icc2_shell> create_routing_rule Wide \
-widths {AP 5 MB 5 M1 2 M2 2 M3 2 M4 2}
{Wide}
icc2_shell> set_routing_rule $nets -rule Wide
4. Route the M1-Mn layer nets on the interposer with the route_group command.
icc2_shell> set_ignored_layers -min_routing_layer M1
-max_routing_layer M4
icc2_shell> route_group -nets $nets
5. Create the routing rule and specify the shield spacing and shield widths.
icc2_shell> create_routing_rule shieldrule -shield_spacings {M9 2} \
-shield_widths {M9 5} -widths {MRDL 6 M9 5}
To speed up routing by routing only within a specific region, use the -coordinates
option and specify a list of rectangles.
3D IC Glossary of Terms
The following terminologies and conventions are used in 3DIC design:
• Interposer: The specialized silicon die that provides connections to the package and
mounts for the dies. The passive interposer typically contains no logic, but does contain
TSVs, C4 bumps, microbumps, and routing.
• Active dies: The dies that contact the interposer, face down, using flip-chip technology.
• Front side: The top side of a silicon die. The front side is opposite the substrate and
device layers where most of the standard cell metal routing is performed.
• Back side: The bottom side of a silicon die. The bottom side contains the substrate and
device layers where the back metal layers are created.
• Through-silicon via (TSV): A via that connects the back-side metal through the
substrate with the device layers to the front-side metal. TSVs are required on the
silicon interposer to propagate the signals from the package substrate through the
interposer to the dies.
• Microbump: A back-side or front-side cell with a single pin. The cell contains the RDL
metal and passivation opening for external contact. The microbump can be used for
signal and power and ground connections to another die.
• C4 bump: A back-side or front-side cell with a single pin used for a connection to the
package. The cell contains the back-side metal and passivation opening for external
contact. C4 bumps are used for signal and power and ground connections to the
package.
C4 stands for Controlled Collapse Chip Connect.
8
Managing Design Blocks
To manage design blocks, the IC Compiler II tool supports operations to easily partition
your design and commit a logical hierarchy cell to a physical hierarchy block early in the
design flow. After committing to blocks, you can create multiple optimized, abstract views
for design blocks that contain only the information needed to perform placement, timing,
and other tasks. This approach enables you to minimize the system requirements needed
to efficiently distribute and process very large designs.
The flow to commit blocks and create abstracts is shown in Figure 56.
Commit blocks
(commit_block)
The Hierarchy Browser shows the cell name, utilization, number of pins, number of hard
macros, number of standard cells in the entire hierarchy, and other information.
approximate block size that is required for a given utilization for a top-level block, and
arrange module boundaries by hand within the floorplan for rough estimation of block
placement. You can also set different parameters to control which top-level blocks are
treated as module boundaries in this view.
To create module boundaries,
1. Use the explore_logic_hierarchy command and specify the cell names for which to
create module boundaries.
icc2_shell> explore_logic_hierarchy -create_module_boundary \
-cell { I_ORCA_TOP/I_BLENDER_1 I_ORCA_TOP/I_BLENDER_2 \
I_ORCA_TOP/I_BLENDER_3 I_ORCA_TOP/I_BLENDER_4 \
I_ORCA_TOP/I_BLENDER_5 I_ORCA_TOP/I_BLENDER_6 \
I_ORCA_TOP/I_BLENDER_7 }
The tool creates module boundaries based on the options you specify. By default,
the tool determines the size of the boundary based on the utilization of the top-level
floorplan. After creating the module boundaries, the tool updates the display in the GUI
as shown in Figure 58. The original floorplan boundary is shown on the left, the I/Os
are located above the floorplan boundary, the module boundaries are placed at the
bottom right, and any unplaced macros are placed above the module boundaries.
You can retain a parent module boundary and create additional module boundaries
from within the parent hierarchy by using the -nested option. When you specify
this option, the tool keeps the parent-level module boundary and creates a new
module boundary for the lower level of hierarchy. The following example creates two
module boundaries: a module boundary for I_ORCA_TOP and a module boundary for
I_ORCA_TOP/I_BLENDER_0.
icc2_shell> explore_logic_hierarchy -create_module_boundary \
-cell {I_ORCA_TOP}
icc2_shell> explore_logic_hierarchy -create_module_boundary \
-cell {I_ORCA_TOP/I_BLENDER_0} -nested
3. Reset the module boundary positions or remove the module boundaries to explore
other hierarchies.
icc2_shell> explore_logic_hierarchy -organize
icc2_shell> explore_logic_hierarchy -remove
The -organize option moves the module boundaries outside the floorplan to the
locations created by the explore_logic_hierarchy -create_module_boundary
command as shown in Figure 58. The -remove option removes all module boundaries.
You can also combine the -remove and -cell options to remove specific module
boundaries.
4. Repeat the flow by creating module boundaries for other cells to explore different
hierarchies.
To create the initial module boundaries with the GUI,
1. Open the Hierarchy Exploration panel in the GUI by choosing View > Assistants >
Hierarchy Exploration, or select Floorplan Preparation > Hierarchy Exploration in the
Task Assistant.
2. Select the blocks for which to create module boundaries.
3. Click Create Module Boundary from the context menu as shown in Figure 60.
The tool creates module boundary for the selected logic hierarchies.
To create a single move bound to group two or more modules, specify the
-virtual_group option as follows:
icc2_shell> explore_logic_hierarchy -name group1 \
-virtual_group {I_ORCA_TOP/I_PCI_TOP I_ORCA_TOP/I_SDRAM_TOP}
Use the get_attribute command as follows to report the individual modules associated
with the grouped move bound:
icc2_shell> get_attribute [get_bounds group1] -name flat_hier_names
2. Commit the block. The block is saved to the specified design library.
icc2_shell> commit_block -library orca ORCA
In this example, the command creates a new physical hierarchy for the block named orca
and writes the block to the orca design library. The GUI updates to show outline views for
the committed blocks.
placement abstracts, you must load the full netlist representation of the top-level design,
without the details for the committed blocks.
To create block placement abstracts,
1. Set the constraint mapping file.
icc2_shell> sh cat split/mapfile
BLENDER_0 CLKNET BLENDER_0/clocknets.tcl
BLENDER_0 SDC BLENDER_0/top.tcl
BLENDER_0 UPF BLENDER_0/top.upf
...
BLENDER_6 CLKNET BLENDER_6/clocknets.tcl
BLENDER_6 SDC BLENDER_6/top.tcl
BLENDER_6 UPF BLENDER_0/top.upf
ORCA CLKNET ORCA/clocknets.tcl
ORCA SDC ORCA/top.tcl
ORCA UPF TOP/top.upf
In this example, the expand_outline command reads the netlist and expands the
top level. Note that the representation reported by the current_design command is
changed from "outline" to "design".
Note:
For the command to function correctly, you must maintain the original
Verilog file in the same location referenced by the read_verilog_outline
command, or make the file available in the search_path.
4. Set the host options for distributed computing.
Note:
You can verify the current host option settings with the
check_host_options command.
5. Create the block placement abstracts for all blocks by using distributed processing.
icc2_shell> create_abstract -placement \
-host_options block_script -all_blocks
Submitting job for block BLENDER_0 ...
Submitting job for block BLENDER_1 ...
...
Running distributed create_abstract ...
...
1
You can create block placement abstracts without using distributed processing by omitting
the -host_options option. To create block placement abstracts for only a subset of
blocks, use the -blocks {blocks} option instead of the -all_blocks option.
To change only the origin for the current top-level block, use the move_block_origin
command. The location you specify is relative to the current origin. For example, to move
the origin of the current top-level block to the center of the block, where the current origin
is at the lower-left corner and the bounding box for the block is {0 0} {1000 1000}, use the
following command:
icc2_shell> move_block_origin -to {500 500}
Pushing Objects Down From the Top Level to the Block Level
To move objects from the top level to the block level, use the
set_push_down_object_options and push_down_objects commands. By
default, objects created by the push_down_objects command have a suffix of
_PUSHDOWN_n. To assign a different suffix for port and net names, use the
plan.pins.new_port_name_tag application option. To assign a different suffix for cell
names, use the plan.pins.new_cell_name_tag application option.
To push objects down from the top level to the block level,
1. Specify the types of objects to move, and how to copy them, with the
set_push_down_object_options command.
icc2_shell> set_push_down_object_options -object_type signal_routing \
-block_action {copy create_pin_shape}
For information about the push down object options, see Push Down Object Options.
2. (Optional) Verify the option settings with the report_push_down_object_options
command.
icc2_shell> report_push_down_object_options \
-object_type signal_routing
****************************************
Report : report_push_down_object_options
****************************************
--- push_down_objects options for signal_routing ---
3. (Optional) Check the nets for potential routing issues before pushing down to the block
level with the check_objects_for_push_down command.
icc2_shell> check_objects_for_push_down \
[get_nets -of_objects [get_cells CLK_BUFFER*]]
0 nets determined to have problems
Overall runtime: 0.008u 0.000s 0:00.01e 100.9%
When you push down routes and other objects from the top level or create
feedthroughs on a block, a shadow netlist is created that contains the objects that were
pushed down or created. Within the block that receives the new objects, the tool inserts
the objects and
• Sets the is_shadow attribute on the objects to true
Feedthroughs that are pushed down from the top level have the is_shadow
attribute set to true on the pins, nets, and buffers of the feedthrough net.
• Sets the shadow_status property to pushed_down
Other possible shadow status property values are copied_down, copied_up,
normal, pulled_up, pushed_down, and virtual_flat.
See Also
• Push Down Object Options
• Pushing Down Feedthrough Nets
• Specify how the object is treated at the top level with the -top_action option. Valid top
actions are keep or remove.
icc2_shell> set_push_down_object_options -object_type blockage \
-top_action keep
• Specify how the object is treated at the block level with the -block_action
option. Valid block actions are center_pin_from_wire, copy, create_blockage,
create_pin_shape, create_route_blockage_from_cell, and
retain_obsolete_ports, depending on the object type specified with the
-object_type option.
icc2_shell> set_push_down_object_options -object_type cells \
-top_action remove -block_action {copy retain_obsolete_ports}
• Check for overlaps with existing routing objects with the -routing_overlap_check
option. This option can be used when specifying the pg_routing and signal_routing
object types with the -object_type option.
icc2_shell> set_push_down_object_options -object_type pg_routing \
-block_action {create_pin_shape copy} \
-routing_overlap_check true
• Issue a warning message when pushing down misaligned PG routing objects into
multiply instantiated blocks with the -ignore_misalignment option.
icc2_shell> set_push_down_object_options -object_type pg_routing \
-block_action {copy create_pin_shape} -ignore_misalignment true
• Treat parallel PG straps outside the block boundary but within the specified distance
setting as collinear routes with the -collinear_margin option. Note that these PG
straps are created in the child block as copies of the original top-level strap and the
original strap is left untouched at the top level.
icc2_shell> set_push_down_object_options -object_type pg_routing \
-block_action {copy create_pin_shape} -ignore_misalignment true \
-collinear_margin 2.1 -pin_meet_fatwire_rule true
In the following example, the push_down_objects command pushes down all nets
associated with routing corridor corridor_a into the blocks that are crossed by the net. Note
that feedthrough creation must be enabled. Figure 61 shows the design block diagram
before and after pushing down the route. The tool creates a pure feedthrough in Block2
and creates physical pins for detailed routed nets at the intersection of the net and the
block boundaries.
icc2_shell> push_down_objects [get_nets \
-of_objects [get_routing_corridors corridor_a]]
See Also
• Creating Individual Pin Constraints
2. Push down the via into the block specified by the -cells option.
icc2_shell> push_down_objects [get_vias VIA_S_5] -cells u1/u2
...
Examined 1 nets for push-down
Pushed down routing for 1 nets
...
To write out shadow information in the form of an ECO script instead of a shadow netlist,
use the write_shadow_eco command. The ECO script can be used by a physical design
tool like the IC Compiler II tool; the script can also provide useful information to a front-
end tool such as the Design Compiler tool. Note that the Design Compiler tool consumes
the ECO script differently than the IC Compiler II tool. Use the -command_style icc2
option when targeting the IC Compiler II tool and use the -command_style dc option
when targeting the Design Compiler tool.
Use the following steps to query the pushed-down objects in the lower-level block,
1. Open the block that contains the pushed-down objects.
icc2_shell> open_block lib/myblock:myblock.design
See Also
• Pushing Objects Down From the Top Level to the Block Level
For information about the pop-up object options, see Pop Up Object Options.
2. (Optional) Verify the option settings with the report_pop_up_object_options
command.
icc2_shell> report_pop_up_object_options -object_type blockage
****************************************
Report : report_pop_up_object_options
****************************************
--- pop_up_objects options for blockage ---
Block action: keep
3. Pop up the placement blockage in a specific cell to the top level with the
pop_up_objects command.
In the following example, the placement blockage from cell34 is popped up to the top.
icc2_shell> pop_up_objects [get_placement_blockages cell34/*]
After objects are pulled up, the tool sets the shadow_status property to pulled_up.
Other possible shadow status property values are copied_down, copied_up, normal,
pulled_up, pushed_down, and virtual_flat.
• Specify how the object is treated at the block level with the -block_action option.
Valid block actions are keep or remove.
icc2_shell> set_pop_up_object_options -object_type cells \
-top_action remove -block_action {keep}
• Check for overlaps with existing routing objects with the -routing_overlap_check
option. This option can be used when specifying the pg_routing and signal_routing
object types with the -object_type option.
icc2_shell> set_pop_up_object_options -object_type pg_routing \
-block_action {keep} \
-routing_overlap_check true
By default, the command writes the ECO script to the console. To write the script to a
Tcl file, specify the file name with the -filename option. Source the script by using the
source command.
The following figures show the branching of a physical multiple-fanout net before and after
being pushed up to the top level.
In the following figure, all three or2 gates overlap with block_0 in the physical floorplan:
After sourcing the ECO script, the cells are pushed down into the block_0 block:
The write_push_down_eco command generates an ECO file for each block. By default,
the ECO files are written to a directory named push_down_eco_scripts. You can specify
the directory name by using the -dir option. To run the ECO scripts for all the blocks,
source the top-level block Tcl script with the source command.
Create Spare Ports and Nets on a Child Block
To generate an ECO script to create spare (dummy) ports and nets on a child block, use
the write_spare_ports_eco command and specify
• A list of cells by using the cell_list argument.
• The name of the ports by using the -name option. By default, the command uses
dummyFT.
• The direction of the ports by using the -direction option and specifying in, out, or
inout. The default is in.
The write_spare_ports_eco command generates an ECO file for each block. By default,
the ECO files are written to a directory named create_spare_ports. You can specify the
directory name by using the -dir option. To run the ECO scripts for all the blocks, source
the top-level block Tcl script with the source command.
The following example writes out a script for the U* cell instances and specifies new ports
named spareFT:
icc2_shell> write_spare_ports_eco [get_cells U*] -direction in \
-dir test_path -bits {0 4} -name spareFT
9
Performing Block Shaping and Macro Placement
The block shaping flow refines the boundary for the block based on the rough rectangular
or rectilinear shape defined during hierarchy exploration. When creating the block shape,
the tool considers design constraints such as target utilization for the block, channel width
and keepout settings, while minimizing feedthroughs and interface wire lengths. You can
create an optional block grid for your design; the tool aligns block shapes to the grid.
The flow to shape blocks is shown in Figure 63.
Shape blocks
(shape_blocks)
****************************************
macro allowed legal
name orientations orientations
------------------------------------------
I_ORCA_TOP/I_RISC_CORE/I_REG_FILE/REG_FILE_D_RAM
R0,R180 all
I_ORCA_TOP/I_RISC_CORE/I_REG_FILE/REG_FILE_C_RAM
R0,R180 all
...
Use the following options with the set_macro_constraints command to constrain the
placement of hard macros and I/O cells in the design:
Table 4 Specifying Macro Constraint Options
Specify the style used to place each macro when -style on_edge | freeform | auto
the plan.macro.style application option is set to
hybrid.
The valid values are auto, on_edge, and freeform.
The default is auto, which means that the tool
decides whether to place the macros along the
edges or in freeform style. The automatic selection
is based on the size of the macros and the number
of routing layers that are blocked. The tool limits the
on-edge selection to only those macros that should
not be in the standard cell area.
For more information about the plan.macro.style
application option, see the man page.
2. (Optional) Verify that the constraint was set correctly with the
report_macro_relative_location command.
icc2_shell> report_macro_relative_location
****************************************
Report : report_macro_relative_location
Design : ORCA
****************************************
Macro relative location constraints in block ORCA/dp:
--------------------------------------------------------------
target target target anchor anchor anchor offset...
name orientation corner name type corner X ...
--------------------------------------------------------------
.../I_RISC_CORE/I_REG_FILE/REG_FILE_D_RAM
R0 bl .../I_RISC_CORE/I_REG_FILE/REG_FILE_B_RAM
macro tl 0.0000 ...
You can change the relative location constraints with the following
set_macro_relative_location command options:
• Specify which corner of the anchor object to use when creating the offset between
the anchor object and target object; valid corner values are bl (bottom left), br (bottom
right), tl (top left), and tr (top right).
icc2_shell> set_macro_relative_location -anchor_corner bl ...
• Specify the instance name of the object to use as the reference location for the target
object.
icc2_shell> set_macro_relative_location -anchor_object {u1/u2} ...
• Specify the x- and y-offset for the target object with respect to the anchor object.
icc2_shell> set_macro_relative_location -offset {200 200} ...
• Specify the corner of the target macro to apply the constraint; valid corner values are
the same as for the -anchor_corner option.
icc2_shell> set_macro_relative_location -target_corner tr ...
• Specify the orientation of the target macro; valid orientations are R0, R90, R180, R270,
MX, MXR90, MY, and MYR90. The orientation that you specify must be an allowed
orientation for the macro.
icc2_shell> set_macro_relative_location -target_orientation R0 ...
• Specify a scalable offset ratio, positive or negative, from the anchor object.
icc2_shell> set_macro_relative_location -offset_type scalable \
-offset {0.5 0.5} ...
hard (default) Prevents standard cells from being placed within the keepout margin.
soft Prevents standard cells from being placed within the keepout margin. However,
the placer can move cells into the keepout during optimization.
hard_macro Prevents the placement of hard macros or other hard macro keepout margins
within the keepout margin. This type affects only hard macro placement and
ensures a minimum channel between hard macros. The entire macro and
keepout are kept within the site array. You can use this keepout type to allocate
space for routing to the pins of the macro.
routing_blockage Prevents the power and ground (PG) router from inserting via arrays that
block access to macro pins. This type requires a list of layers to include in the
blockage.
The following example creates a hard constraint on block BLK1 to enable cross block
connectivity planning.
icc2_shell> set_app_options -block BLK1 \
-name plan.macro.cross_block_connectivity_planning -value hard
You can perform similar connectivity planning on move bounds and voltage areas by
setting the interface_connectivity_planning attribute on the object. The attribute
accepts the same values as the plan.macro.cross_block_connectivity_planning
application option. The following example sets a hard interface connectivity planning
constraint on voltage area VA1.
icc2_shell> set_attribute -name interface_connectivity_planning \
-value hard [get_voltage_areas VA1]
After creating a macro array, you can use the macro array tool in the GUI to rotate and
swap macros. You can also rotate the entire macro array with the macro array tool. To
start the macro array tool, select two or more macros in the macro array and choose Edit >
Macro Array from the menu. The macro array editor is shown in the following figure.
To remove a macro array, use the remove_edit_groups command to remove the edit
group associated with the macro array.
icc2_shell> remove_edit_groups {MACRO_ARRAY_0}
See Also
• Creating the Initial Macro Placement
Shaping Blocks
After committing the logical hierarchy cells to physical hierarchy blocks, you can create a
rough placement of the physical hierarchy blocks. The tool shapes and places the physical
blocks, including power domains and voltage areas, based on the specified utilization,
channel size and constraints.
Any options set with the set_shaping_options command remain active during the
session. You can use the report_shaping_options command to validate the current
shaping settings.
2. Shape and place the blocks with the shape_blocks command.
icc2_shell> shape_blocks -channels true
In this example, the -channels true option directs the command to insert channels
between blocks. Note that shape_blocks command options are not persistent.
Figure 66 shows the floorplan before and after block shaping.
During block shaping, the tool minimizes the number of feedthroughs and minimizes
interface wire lengths. The command uses macro packing to place the top-level
macros. The tool also aligns the block shape to the block grid, if specified. If you
created block placement abstracts as described in Creating Block Placement
Abstracts, you can use the abstracts to reduce the runtime required for placement.
3. Report any violations that occurred during block placement with the
report_block_shaping command.
icc2_shell> report_block_shaping -core_area_violations -overlaps \
-flyline_crossing
****************************************
Report : report_block_shaping
Design : ORCA
****************************************
Block core area violation report
================================
Core area violations in design ORCA: 0
# TOP constraints
# block constraints cannot be nested
block TOP {
# Define channel constraints for TOP
# and blocks within TOP
# Channel constraints can be defined for
# block_inst, voltage_area, group, or current_block
channel_size {
# Define constraint for TOP/U1
block_inst U1;
# Default channel is 20 micron
# You can also specify "min = 20, max = 20"
size = 20;
# Left and right channels are between 30 and 50 microns
left, right: min = 30, max = 50;
}
# Create a guard band constraint for voltage area VA1
# of 50 microns, and set the voltage area boundary
# to {{0 0} {300 600}}
voltage_area VA1 {
contents: voltage_area VA2, block_inst U3;
# Define spacing around voltage area VA2
guard_band {
width: 50; height: 50;
}
boundary {
type: rigid;
shape: {{0 0} {300 600}};
}
}
# Define spacing around any other voltage area
# beneath TOP
guard_band {
width: 40;
height: 40;
}
# Define a group that contains a set of blocks or
# voltage areas within TOP
define_group GROUP1 {
# Organize blocks and voltage areas in a row or column
# Legal directions are:
# east (from left to right)
# west (from right to left)
# north (from bottom to top)
# south (from top to bottom)
arrange_in_array {
# BLOCK2 constraints
block BLOCK2 {
# Reserve a space between the current block
# boundary and any regions shaped inside the block
boundary_channel_size {
current_block;
left: min = 3, max = 5;
right, bottom: min = 5, max = 10;
}
# Specify a 50% target utilization
# and a maximum of 70%
utilization {
target: 0.5;
max: 0.7;
}
}
The following example uses the shaping constraints file to organize blocks in the design.
The shaping constraints file specifies two groups that contain five blocks each. The five
blocks are stacked horizontally, and the two groups are stacked vertically. A guard band of
100 is applied between the blocks.
icc2_shell> sh cat shaping.con
# Shaping constraint file
channel_size { size=100; }
block top {
define_group UPPER {
arrange_in_array {
contents: block_inst u0, block_inst u1, block_inst u2,
block_inst u3, block_inst u4;
direction: east;
}
}
define_group LOWER {
arrange_in_array {
contents: block_inst u5, block_inst u6, block_inst u7,
block_inst u8, block_inst u9;
direction: east;
}
}
define_group TOP {
arrange_in_array {
contents: group UPPER, group LOWER;
direction: south;
}
}
}
The following example specifies a fixed boundary for a block in the design. The boundary
is specified with the shape: and type: rigid constraints. The coordinates are relative
and the tool can move the shape to a new location in the parent block. The location of the
block within the design is specified by arrange_in_array or arrange_in_box constraints.
icc2_shell> sh cat fixedblock.con
# Shaping constraints with fixed block
channel_size { size=50; }
block block100a {
boundary {
type: rigid;
shape: {{350 500} {350 1360} {550 1360}
{550 900} {850 900} {850 500}};
}
}
block top {
define_group UPPER {
arrange_in_array {
contents: block_inst u0, block_inst u1, block_inst u2,
block_inst u3, block_inst u4;
direction: east;
}
}
define_group LOWER {
arrange_in_array {
contents: block_inst u5, block_inst u6, block_inst u7,
block_inst u8, block_inst u9;
direction: east;
}
}
define_group TOP {
arrange_in_array {
contents: group UPPER, group LOWER;
direction: south;
}
}
}
Figure 68 shows the layout after running the shape_blocks command. Note the shape of
the block100a block, instantiated in the design as instance u0.
Note:
You can modify the order of the objects within a shaping group by using the
set_shaping_group_order command. The command allows you to move
specific objects or specify a new order for the entire group.
5. Create one shaping constraint for the TOP_ROW group and another shaping constraint
for the BOTTOM_ROW group to specify the type of layout for each group. The “east”
array layout orders the objects from left-to-right in the order they were specified by the
-shaping option of the create_group command.
icc2_shell> create_shaping_constraint [get_groups \
-shaping TOP_ROW] -type array_layout -array_layout east
{TOP_ROW/SHAPING_CONSTRAINT_0_array_layout}
icc2_shell> create_shaping_constraint [get_groups \
-shaping BOTTOM_ROW] -type array_layout -array_layout east
{BOTTOM_ROW/SHAPING_CONSTRAINT_1_array_layout}
6. Create a shaping constraint that specifies that the BOTTOM_ROW group is placed
below the TOP_ROW group.
icc2_shell> create_shaping_constraint [get_groups \
-shaping TOP_AND_BOTTOM] -type array_layout -array_layout south
{TOP_AND_BOTTOM/SHAPING_CONSTRAINT_2_array_layout}
BOTTOM_ROW
TOP_AND_BOTTOM
To report the shaping constraints for the current block or a specific block, use the
report_shaping_constraints command. The following example reports all the shaping
constraints for the current block and all its hierarchically nested blocks that are visible to
the shape_blocks command:
icc2_shell> report_shaping_constraints
The Design Assistant in the GUI displays the Tcl-based shaping constraints applied to the
design. Open the Design Assistant by choosing View > Assistants > Design Assistant from
the menu. In the Design Assistant, choose View > Shapeable Objects to view the objects
and constraints. Use this tool to create shaping constraints, rearrange objects in shaping
groups, remove objects from shaping groups, and delete shaping groups. The following
figure shows the shapeable objects tab in the Design Assistant for the previous example.
The following example applies Tcl-based shaping constraints to two blocks and a voltage
area. The create_shaping_constraint command is used to create a 50 micron
channel around each shaped object. Note that the Tcl list command is used to gather
heterogeneous objects for the -shaping option with the create_group command.
set_app_options \
-name plan.shaping.import_tcl_shaping_constraints -value true
create_group -name G1 \
-shaping [list [get_cells u0_1] \
[get_voltage_areas u_m/PD_LEON3_misc] \
[get_cells U2]]
create_shaping_constraint \
[get_blocks leon3mp.nlib:leon3mp/shaping.design] \
-type boundary_channels \
-object_channel [create_shaping_channel -left_min 50 \
-left_max 50 -bottom_min 50 -bottom_max 50 -right_min 50 \
-right_max 50 -top_min 50 -top_max 50]
shape_blocks
layout. After creating the shaping channel, assign the channel to an object by using the
create_shaping_constraint command.
You can assign three types of channels by using the -type option with the
create_shaping_constraint command:
$boundary_channel_100
$neighbor_channel
The block grid can be derived from power plan strategies or derived from existing site rows
in the floorplan. You can also define the grid manually by specifying the origin and grid
spacing. After creating the grid, you must associate the block references with a block grid
to ensure that the tool aligns all instances with the grid in the same way.
To create the block grid from existing site rows and power ground strategy settings,
1. Use the create_pg_mesh_pattern and set_pg_strategy commands to define the
power grid (it is not necessary to instantiate the grid with the compile_pg command).
icc2_shell> create_pg_mesh_pattern pat_mesh \
-layers { \
{{vertical_layer: ME8} {width: 3} \
{spacing: 3} {pitch: 20} {offset: 2}} \
{{horizontal_layer: ME7} {width: 3} \
{spacing: 3} {pitch: 20} {offset: 2}}}
icc2_shell> set_pg_strategy s_mesh -core \
-pattern {{name: pat_mesh} {nets: VDD90 VSS}}
2. Create the grid by using the create_grid command with the -site_rows and
-pg_strategy options.
icc2_shell> create_grid grid1 -type block \
-site_rows [get_site_rows] -pg_strategy s_mesh1
Calculating block grid:
...
{grid1}
If your design contains a site array instead of site rows, use the following command to
create the grid:
icc2_shell> create_grid grid1 -type block \
-site_arrays [get_site_array] -pg_strategy s_mesh1
Calculating block grid:
...
{grid1}
3. (Optional) Verify that the grid was created correctly by using the report_grids
command.
icc2_shell> report_grids
****************************************
Report : report block grid
Design : ORCA
****************************************
Auto Block grid grid1:
Step in X direction: 20.0000 micron
Step in Y direction: 20.0000 micron
X offset: 0.0000 micron
Y offset: 0.0000 micron
Allowed orientations: R0
Derived from PG strategies.
Strategies Used Layers:
s_mesh1 \
4. Associate the block grid with the MIB references by using the
set_block_grid_references command.
icc2_shell> set_block_grid_references -designs {ORCA} \
-grid grid1
Alternatively, you can manually create the block grid by specifying the x- and y- offsets
and step sizes for the grid. Use the report_grids and set_block_grid_references
commands to verify the grid and associate the grid with the MIB references. Create the
grid manually as follows:
icc2_shell> create_grid -type block grid2 -x_step 20.0 \
-y_step 20.0 -x_offset 19.0 -y_offset 13.0
{grid2}
Note that you do not need to specify the power planning patterns or strategy if you create
the grid manually.
Setting the Snap Point for a Multiply Instantiated Block
To ensure that multiply instantiated blocks (MIBs) can be flipped and rotated correctly
while keeping the MIBs on-grid, you can change the snap point for the block. The
tool aligns the snap point of the block to the nearest grid point. By default, the snap
point for the design is (0,0). To set the snap point and verify the setting, use the
2. (Optional) Verify the settings by examining the attributes on the multiply instantiated
block instances.
icc2_shell> get_attribute [get_cells I_BLENDER_1] snap_point
100.0000 100.0000
icc2_shell> get_attribute [get_cells I_BLENDER_1] block_grid
grid1
3. (Optional) Snap the multiply instantiated blocks to the grid using one of the following
commands.
icc2_shell> snap_cells_to_block_grid -grid grid1
icc2_shell> snap_cells_to_block_grid -designs BLENDER_2
icc2_shell> snap_cells_to_block_grid
-cells [get_cells I_BLENDER_1]
The snap point can be set to any location on the block. In the following figure, the small
plus symbols represent points on the grid and the large plus symbols (circled in red)
represent the snap point defined for the design.
Use the set_host_options command to create the setting for distributed processing.
2. (Optional) Enable macro-only placement by setting the
plan.macro.macro_place_only application option to true.
icc2_shell> set_app_options -name plan.macro.macro_place_only \
-value true
3. (Optional) Review the settings for the application options for the placer and make any
necessary changes.
You can use the report_app_options plan.place* commands to report the current
placer-related settings. Use the set_app_options command to change a setting.
4. (Optional) Limit placement to specific levels of design hierarchy with the
set_editability command. The following example prevents placement at lower
levels of the design hierarchy and specifies placement at the top level only.
icc2_shell> set_editability -from_level 1 -value false
Optionally,
• If you set host options in step 1, enable distributed processing by using the
-host_options option
• Specify the level of effort to apply to the placement by using the -effort low |
medium | high option
As you increase the effort level, the tool increases the number of internal loops
to create a placement with the best possible quality of results. To provide better
convergence, the tool decreases the average distance the cells are allowed to
move in successive placement passes.
• Update the placement after changing the boundaries of macro blocks by using the
-incremental option
When you use this option, the command tries to create legal macro placement close
to the current one. If the current macro placement is legal, it is retained; otherwise,
macros are moved to other legal positions. Examples of illegal positions include
macro overlapping, sticking out of core, or not being on grid.
• Reduce congestion by using the -congestion option
When you use this option, the tool tries to reduce congestion by moving macros and
creating wider channels.
6. Validate the placement with the report_placement command.
icc2_shell> report_placement -physical_hierarchy_violations all \
-wirelength all -hard_macro_overlap
****************************************
Report : report_placement
Design : ORCA
****************************************
Wire length report (all)
==================
wire len in design ORCA/dp: 828662.662 microns.
wire len in design ORCA/dp (see through blk pins): 950442.075 microns.
You can examine the report that is created by the report_placement command and
investigate the overlaps.
8. (Optional) To remove the placement created with the create_placement command,
use the reset_placement command.
icc2_shell> reset_placement
2. Run the identify_channels command to write out a file that contains the coordinates
of the channels between the specified objects.
icc2_shell> identify_channels -cross_area $macros
Creating channel file channels.txt
The tool writes the channels to the channels.txt file. The file lists the type of channel
(horizontal, vertical, or crossed_area) and the coordinates of the channel as follows:
icc2_shell> sh cat channels.txt
horizontal (848.17 1632.765) (970.3 1669.995)
horizontal (1009.175 1632.765) (1131.305 1669.995)
vertical (970.3 1669.995) (1009.175 1774.075)
vertical (970.3 1528.685) (1009.175 1632.765)
crossed_area (970.3 1632.765) (1009.175 1669.995)
In the following layout, the channels are outlined and numbered corresponding to the line
number of the channel in the channels.txt file.
Use options with the identify_channels command to control how the channels are
reported.
• Report channels less than a specified height by using the -horizontal_threshold
option.
• Report channels less than a specified width by using the -vertical_threshold
option.
• Specify the output file name with the -output_filename option.
• Report cross areas by using the -cross_area option. Cross areas occur between
the lower-left edge of one object and the upper right edge of another object, and vice
versa.
• Report cross channels less than a specified height by using the -cross_area_height
option.
• Report cross channels less than a specified width by using the -cross_area_width
option.
Specify the height of the macro stack after which the plan.macro.max_buffer_stack_heig
tool creates a channel for buffer placement. ht
Specify the width of the macro stack after which the tool plan.macro.max_buffer_stack_widt
creates a channel for buffer placement. h
macro placement style. Freeform macro placement provides the following benefits as
compared to on-edge macro placement:
• Considers congestion driven channel sizing
• Adds partial blockages to macro channels
• Considers PG resources when calculating channel congestion
• Provides automatic pin protection blockages
• Provides support for hard inclusive bounds with standard cells
• Honors any functional safety-related Dual Core Lock Step (DCLS) or nCLS (core lock
step with n cores) constraints
To use the freeform style of macro placement, set the following application option:
icc2_shell> set_app_options -name plan.macro.style -value freeform
Use the following application options for finer control of the freeform macro placement:
• plan.macro.create_auto_pin_blockages: Specifies whether to create blockages
around pins when running freeform macro placement. These blockages are of
hard_macro type and they protect the design pins from having macros too close to
them.
• plan.macro.remove_auto_pin_blockages: Specifies whether to remove the
temporary blockages that were placed around the pins during freeform macro
placement, to allow easy access to the pins.
• plan.macro.auto_pin_blockages_width: Specifies the width (if the pins are on the
vertical block edges) or height (if pins are on horizontal block edges) of pin blockages
created during freeform macro placement.
To enable timing driven placement using the buffering aware timing model, use the
create_placement -buffering_aware_timing_driven command. This approach
estimates the effects of buffering long nets and high-fanout nets later in the design
planning flow. It provides a better starting point for later timing optimizations.
icc2_shell> create_placement -floorplan -congestion \
-buffering_aware_timing_driven
To perform incremental freeform macro placement after changes due to one or more of the
following reasons, use the create_placement -from command.
• Netlist changes (during optimization due to timing or area changes)
• Constraint changes (for example, hard macro keepouts)
• Congestion reduction
The -from option enables you to choose the level of macro movement from the most
aggressive and time consuming (combined_placement) to the least aggressive
(channel_sizing). A value of combined_placement results in the tool running the full
freeform flow. The default is macro_legalization. Ensure that you use the -from option
with the -floorplan and -incremental options.
For incremental congestion-driven freeform macro placement, use the following options in
the create_placement command:
• -floorplan
• -incremental
• -congestion
For example,
icc2_shell> create_placement -floorplan -incremental -congestion
-from combined_placement
Note:
When setting the plan.macro.integrated to true,
• If place_opt.initial_place.two_pass is false, the tool enables the
single pass flow.
• If place_opt.initial_place.two_pass is true, the tool enables the
two pass flow.
When running the manual two pass flow, set the plan.macro.integrated
application option to two_pass.
5. Run the place_opt command to start the place_opt flow with iFFMP.
6. Ensure all macros are fixed after the place_opt flow by using the set_fixed_objects
command. For example,
icc2_shell> set_fixed_objects [get_flat_cells -filter is_hard_macro]
4. Set the following application options to enable iFFMP flow and PG grid insertion:
icc2_shell> set_app_options -name plan.macro.style -value freeform
5. Run the place_opt command to start the place_opt flow with iFFMP.
6. Ensure that all macro cells are fixed after the place_opt flow by using the
set_fixed_objects command. For example,
icc2_shell> set_fixed_objects [get_flat_cells -filter is_hard_macro]
It is important that these cells are modeled during the iFFMP flow as the
placement of these cells has a significant impact on the placeable area of the
design. To improve the accuracy of the iFFMP place_opt flow, the tool uses the
plan.macro.floorplan_finishing application option while enabling the iFFMP flow.
You can use this application option to specify a script file or Tcl code that inserts boundary
cells, tap cells, and switch cells.
To perform iFFMP with floorplan finishing,
1. Open a design.
2. Make sure all the macro cells to be placed are unfixed. For example,
icc2_shell> set_attribute [get_flat_cells -filter is_hard_macro]
unplaced
4. Set the following application options to enable iFFMP flow, PG grid insertion, and
floorplan finishing:
icc2_shell> set_app_options -name plan.macro.style -value freeform
5. Run the place_opt command to start the place_opt flow with iFFMP.
6. Ensure that all macro cells are fixed after the place_opt flow by using the
set_fixed_objects command. For example,
icc2_shell> set_fixed_objects [get_flat_cells -filter is_hard_macro]
To place macros using the machine learning techniques, use the place_macro_ml
command. This command places macros in such a way that would improve congestion,
total negative slack, and power.
Machine learning macro placement predicts the best floorplan from possible macro
placement results. You can place macros on edge or in freeform placement by using the
-style option. Use a combination of the following options to achieve the required results.
-mode To optimize the macro placement for congestion, total negative slack,
and power.
• both - To optimize for congestion and total negative slack
This is the default setting.
• all - To optimize for congestion, total negative slack, and power
-effort To specify the effort - whether low, medium (the default), or high
When the effort is high, the tool strives to get more accurate machine
learning data, which makes for better machine learning model and
results in better floorplans.
-style To place the macros only on edge (the default) or in hybrid placement.
-work_directory To specify where the machine learning internal data should be stored.
The default is mlmp_dir.
The generated machine learning data is stored in the
mlmp_dir/design_local_data/hm_local.csv file.
• Perform machine learning-based hybrid macro placement with medium effort to reduce
congestion, total negative slack, and power.
icc2_shell> set_host_options -name mlmp \
-submit_command "qsub -P batch -l mem_free=30G" -max_cores 8
2. (Optional) Create a group bound for the collection of island macros with the
create_bound command.
icc2_shell> create_bound -effort high \
-name bound1 { I_ORCA_TOP/I_PCI_TOP/I_PCI_WRITE_FIFO/PCI_FIFO_RAM_7
I_ORCA_TOP/I_PCI_TOP/I_PCI_WRITE_FIFO/PCI_FIFO_RAM_6
I_ORCA_TOP/I_PCI_TOP/I_PCI_WRITE_FIFO/PCI_FIFO_RAM_5 }
3. (Optional) If you created a bound to specify the macros to group together, set the
is_off_edge attribute on the group bound to true.
icc2_shell> set_attribute -objects [get_bounds bound1] \
-name is_off_edge -value true
In the following figure, the default on-edge macro placement is shown on the left. On the
right, three group bounds are created and the preceding flow is used to create island-style
macro placement for the design.
The following figure shows the layout results with no placement blockage, a hard_macro
type placement blockage, and a hard_macro type placement blockage with the
is_pin_protect attribute set to true.
Default
hard_macro placement
blockage
hard_macro placement
blockage with
is_pin_protect==true
You can use the following flow to create the initial macro placement and refine the macro
placement with the Macro Placement Assistant.
By connectivity
Creates one or more groups based on the connections between the macros and flip-flops
in the layout. In the GUI, click “By connectivity” and then click OK. To specify names for
the new macro groups, enter the names in the “Group name” box separated by spaces.
Alternatively, use the following Tcl command to create the macro groups:
create_macro_groups -method by_connectivity -names {M1 M2 M3}
By hierarchy
Creates one group for each level of hierarchy that contains macros. In the GUI, click
“By hierarchy” and then click OK. To specify names for the new macro groups, enter the
names in the “Group name” box separated by spaces. Alternatively, use the following Tcl
command to create the macro groups:
create_macro_groups -method by_hierarchy -names {M1 M2 M3}
By name pattern
Creates a macro group based on a regular expression. In the GUI, select a macro in the
layout, click “By name pattern” and adjust the regular expression pattern as needed. The
tool derives a regular expression based on the instance name of the selected macro.
To specify names for the new macro groups, enter the names in the “Group name”
box separated by spaces. Alternatively, enter a pattern string in the regular expression
box; the pattern should contain the full path name and use “?” or “.” characters to allow
matching of more than one macro. Click “Show Macros” to populate the macro list based
on the pattern. Click OK to create the macro groups. Alternatively, use the following Tcl
command:
create_macro_groups -method by_pattern \
-pattern {I_ORCA_TOP/I_RISC_CORE/I_REG_FILE/REG_FILE_?_RAM}
By name index
Creates one or more macro groups based on a regular expression for the macro indexes.
In the GUI, select a macro in the layout and click “By name index”. The tool tries to derive
an index pattern based on the indexes at the end of the instance name of the selected
macro. Alternatively, enter a pattern string in the index pattern box; the pattern should
contain the full path name and use “?” or “.” characters to allow matching of more than one
macro. Click “Show Macros” to populate the macro list based on the pattern. Alternatively,
use the following Tcl command to create the macro groups:
create_macro_groups -method by_index_pattern \
-index_pattern {I_ORCA_TOP/I_CONTEXT_MEM/I_CONTEXT_RAM_?_*}
By selection set
Creates a single group that contains the currently selected macros. In the GUI, select the
macros, click “By selection set”, and click OK. Add a new macro to the list by selecting it in
the layout and clicking the [+] button. If the macro already belongs to a group, it is moved
to a new group. Remove one or more macros from the list by selecting them in the list and
clicking the [-] button. Alternatively, use the following Tcl command to create the macro
groups:
create_macro_groups -method by_macros -macros [get_selection]
List
Click the List button to show a list of the current macro groups. You can select macro
groups, collections of macros, or individual macros in the layout by clicking their instance
name in the list.
Net Connections
Click the Net Connections button to open the Net Connections panel.
Split
Create a new group and move some macros from the currently selected group into the
new group based on connectivity.
Macro Array
Select two or more macros in the layout and click the Macro Array button to start the
Macro Array tool. Alternatively, choose Edit > Macro Array from the menu to open the
Macro Configuration dialog box.
• both: Reduces congestion both between macros and between standard cells
The following example applies congestion reduction only between hard macros, and
performs coarse placement with high effort:
icc2_shell> set_app_options -name plan.place.congestion_driven_mode \
-value macro
icc2_shell> create_placement -floorplan -congestion \
-congestion_effort high
Timing-Driven Placement
To create a timing-driven placement, use the -timing_driven and -floorplan options
with the create_placement command. You can specify both timing-driven placement and
congestion-driven placement within the same create_placement command.
Timing-driven placement can perform three types of placement, based on the setting of the
plan.place.timing_driven_mode application option:
• both : Performs timing-driven placement for both macros and standard cells
The following example applies timing-driven placement only to standard cells; macros are
placed normally.
icc2_shell> set_app_options -name plan.place.timing_driven_mode \
-value std_cell
icc2_shell> create_placement -floorplan -timing_driven
10
Performing Power Planning
Power planning, which includes power network routing 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 command option settings and regenerating the power plan.
The flow to create a power plan for your design is shown in Figure 85.
The pattern-based power planning flow separates the physical implementation details
(layer, width, spacing) of the power ring and mesh from the regions of the design where
the structures are inserted. In a typical design, you run the flow multiple times. The first
pass defines and creates the power rings, the second pass defines and creates the power
mesh, and so on.
The create_pg_ring_pattern, create_pg_mesh_pattern,
create_pg_macro_conn_pattern, and create_pg_std_cell_conn_pattern commands
create pattern specifications that define the physical implementation details of the power
plan and associate a width, spacing, offset, and via rule specification with the metal layers
in your design. After defining the patterns, they can be easily reused among different
power regions in the design.
The set_pg_strategy command assigns a pattern specification to specific power nets
and regions in the design. You can also define the offset for the start of the pattern, the
power strap extension specification, and the blockage specification with this command.
You can create and implement complex via rules during pattern-based power planning.
The set_pg_via_master_rule command defines the contact code, offset for the
contact code within the via structure, cut spacing, and other parameters for the custom
via structure. Power via masters are associated with a specific power plan strategy by
specifying the -via_rule option with the appropriate create_pg_*_pattern command.
The create_pg_*_pattern and set_pg_strategy commands specify the power plan,
but they do not modify the design. After creating the pattern and strategy definitions, use
the compile_pg command to instantiate the power structures into the design. To make
changes to the power plan after creating the power rings and meshes, remove the rings
and meshes with the compile_pg -undo command and make changes to the via rules,
pattern specifications, or power plan strategies.
After instantiating the power plan, you can validate the integrity of the power
plan by checking for DRC and connectivity violations. Use the check_pg_drc
command to report any power structures that violate the routing design rules. Use the
check_pg_connectivity command to check the physical connectivity of the power
network.
These topics are described in the following sections:
• Creating and Connecting Power Nets
• Defining PG Via Masters
• Creating Power and Ground Ring Patterns
• Creating Power and Ground Mesh Patterns
• Creating Power and Ground Macro Connections
• Creating Power and Ground Standard Cell Rails
• Creating Channel and Alignment Power Straps
• Creating Complex Composite Patterns
• Defining Power Plan Regions
• Setting the Power Plan Strategy
• Creating Via Rules Between Different Strategies
• Instantiating the Power Plan
2. Connect the power and ground nets to power and ground pins with the
connect_pg_net command.
If your design has a UPF description of the power network, you can specify
connect_pg_net -automatic to derive the power and ground nets directly from the
power domain specification and perform the connection.
To create a new via master for the power network, use the set_pg_via_master_rule
command as shown in the following example.
icc2_shell> set_pg_via_master_rule VIA78_2x2 -contact_code VIA78 \
-via_array_dimension {2 2} -offset {3 1}
To create an offset from the origin of the via bounding box, use the -offset {x y}
option. To specify a via master or contact code to use for this via, use the -contact_code
code_name option. To specify the dimensions of the via array for this rule, use the
-via_array_dimension {column row} option. To specify the horizontal and vertical
pitch to use when filling a via rule with multiple repetitions of the contact code or via
array, use the -allow_multiple {x_pitch y_pitch} option. To specify the horizontal
and vertical spacing values between cuts in a simple array via, use the -cut_spacing
{horizontal_spacing vertical_spacing} option.
To use the new rule in your design, specify the via rule name after the via_master
keyword for the create_pg_composite_pattern, create_pg_macro_conn_pattern,
create_pg_mesh_pattern, and create_pg_ring_pattern commands. For example, the
following command uses the VIA78_2x2 via rule defined by the previous command.
icc2_shell> create_pg_mesh_pattern mesh_pat \
-layers {layer_spec} \
-via_rule { \
{{layers: M6} {layers: M7} {via_master: default}} \
{{layers: M7} {layers: M8} {via_master: VIA78_2x2}}}
Using the Via Master With the Maximum Total Cut Area
To use the via master or ContactCode with the maximum total cut
area based on the bounding box for the route intersection, set the
The following example uses parameters to define the metal layer, width, spacing, and
corner bridge settings for the ring pattern.
icc2_shell> create_pg_ring_pattern ring_pat -horizontal_layer @hlayer \
-horizontal_width {@hwidth} -horizontal_spacing {@hspace} \
-vertical_layer @vlayer -vertical_width {@vwidth} \
-vertical_spacing {@vspace} -corner_bridge @cbridge \
-parameters {hlayer hwidth hspace
vlayer vwidth vspace cbridge}
You can also define the settings for the power mesh by using parameters as described
in Creating Power and Ground Ring Patterns. The following example uses parameters to
define the metal width values for the create_pg_mesh_pattern command.
icc2_shell> create_pg_mesh_pattern mesh_pat -layers {
{{vertical_layer: M8} {width: @width8}
{spacing: interleaving} {pitch: 32}}
{{vertical_layer: M6} {width: @width6}
{spacing: interleaving} {pitch: 32}}
{{horizontal_layer: M7} {width: @width7}
{spacing: interleaving} {pitch: 28.8}}} \
-via_rule {
{{layers: M6} {layers: M7} {via_master: default}}
{{layers: M8} {layers: M7} {via_master: VIA78_3x3}}} \
-parameters {width6 width7 width8}
Alternatively, use the Task Assistant to define the standard cell rail pattern.
1. Select Task > Task Assistant in the GUI.
2. Select PG Planning > Ring/Hard Macro/Std Cell Pattern.
3. Click the HM scattered pin, HM long pin, or HM ring pin tab depending on the type of
hard macro pin connection.
4. Enter the pattern name, layer, width, and other information in the form.
5. Click Apply to create the pattern.
You can also define the settings for the standard cell rails by using parameters as
described in Creating Power and Ground Ring Patterns. The following example uses
parameters to define the metal width for the standard cell rail pattern, and assigns values
to the parameters with the set_pg_strategy command.
Alternatively, use the Task Assistant to define the standard cell rail pattern.
1. Select Task > Task Assistant in the GUI.
2. Select PG Planning > Ring/Hard Macro/Std Cell Pattern in the Task Assistant.
3. Click the Std cell tab.
4. Enter the pattern name, layer name, rail width, and offset in the Task Assistant.
5. Click Apply to create the pattern.
If you do not define a rail width, the command uses the width of the standard cell power
and ground pins as the width.
You can also define the settings for the standard cell rails by using parameters as
described in Creating Power and Ground Ring Patterns. The following example uses
parameters to define the metal width for the standard cell rail pattern, and assigns values
to the parameters with the set_pg_strategy command.
icc2_shell> create_pg_std_cell_conn_pattern rail_pat -layers {M1} \
-rail_width {@wtop @wbottom} -parameters {wtop wbottom}
This example defines two via master rules: via_5x6_shift_right and via_5x6_shift_left. For
each via, the -offset option is applied to shift the via from center by 0.8 microns.
The -via_rule option of the create_pg_composite_pattern command specifies
which via is placed at each intersection of layers M3 and M8 as shown in Figure 87. In
this example, the -add_patterns option instantiates two create_pg_wire_pattern
definitions: the vertical power strap pattern on layer M8 (pattern_id: 1),
and the horizontal power strap pattern on layer M3: (pattern_id: 2). The
create_pg_composite_pattern also refers to four net ids for the two PG nets: VSS
(net_id: 1 and 4) and VDD (net_id: 2 and 3).
The via_5x6_shift_right via is inserted at the intersections of pattern_id: 1 and net_id:
1 of the first pattern (layer M8 and net VSS), and pattern_id: 2 and net_id: 2 of the
second pattern (layer M3 and net VSS); location (A) in the figure. The via_5x6_shift_right
via is also inserted at pattern_id: 1 and net_id: 3 (layer M8 and net VDD), and
pattern_id: 2 and net_id: 1 (layer M3 and net VDD); location (D) in the figure.
Similarly, the remaining statements define vias at locations (B) and (C).
set_pg_via_master_rule via_5x6_shift_left \
-via_array_dimension {5 6} -offset {-0.8 0}
{via_master: via_5x6_shift_right}} \
{{{pattern_id: 1}{net_id: 4}} \
{{pattern_id: 2}{net_id: 2}} \
{via_master: via_5x6_shift_left}} \
{{intersection: undefined}{via_master: NIL}} \
}
set_pg_strategy core_patterns \
-pattern {{name: center_aligned_vias} \
{nets: VDD VSS } {offset: {5 5}}} -core
The set_pg_via_master_rule command defines the via rules for the 5x1 and 5x3 via
arrays. The create_pg_composite_pattern command defines a power plan that uses
two distinct wire patterns: one pattern called wire_base used to define the VDD and
VSS vertical straps, one pattern called segment_base used to define both the M3 layer
straps that connect VDD and the M5 layer straps that connect VSS. The wire patterns
are referenced using the {pattern: wire_base} and {pattern: segment_base}
statements.
The -via_rule option to create_pg_composite_pattern defines what vias are inserted
at different metal intersections in the power plan. The {{layers: M6} {layers: M5}
{via_master: via65_5x3}} statement inserts a via65_5x3 via master between any
intersection of layers M6 and M5 in the power plan.
The -via_rule statement {{intersection: undefined} {via_master: NIL}}
ensures that only the specified vias are inserted in the power plan. For designs that
contain many wire patterns, this statement ensures that no vias are inserted between
undefined layer pairs; by default, vias are created for undefined layer pairs.
The commands used to implement this power plan are as follows:
set_pg_via_master_rule via63_5x1 \
-contact_code {VIA34 VIA45 VIA56} \
-via_array_dimension {5 1}
set_pg_via_master_rule via65_5x3 \
-contact_code {VIA56} \
-via_array_dimension {5 3}
set_pg_strategy core_patterns \
-pattern {{name: bridging_straps} \
{nets: VDD VSS } {offset: {5 5}}} -core
For the VDD power straps, a 13x13 via array connects the vertical straps on layer M8 with
the short horizontal metal segment on layer M7. On the same M7 segment, a smaller 6x12
stacked via array connects M7 with the horizontal VDD strap on layer M3.
The composite pattern technique allows you to shift the via locations and open
additional vertical routing tracks to reduce routing jogs and improve timing. The
via73_12x6_shift_right via array is typically inserted in the center of intersection between
the M7 layer metal segment and the M3 layer horizontal strap. In this example, the via
is shifted to the right with the -offset {3 0} option of the set_pg_via_master_rule
command. The offset is shown in Figure 92. Vertical routing tracks on layers M6 and M4
that are beneath the M8 layer VDD straps are not used for PG and can be used for signal
routing.
The set_pg_via_master_rule command defines the via rule for the 12x6 stacked via
array. The create_pg_composite_pattern command defines a composite pattern that
uses two distinct wire patterns: wire_base and segment_base. The wire_base pattern
specifies the vertical straps on M8 and the horizontal straps on M3 for VDD and VSS. The
segment_base pattern specifies the short 10 micron wide horizontal segments for net VDD
on layer M7. The wire patterns are referenced using the {pattern: wire_base} and
{pattern: segment_base} statements.
The -via_rule option specifies where vias are inserted for each layer intersection.
Consider the following definition for the right-shifted via73_12x6_shift_right stacked via:
{{{pattern_id: 2}{net_id: 1}}
{{pattern_id: 3}{net_id: 1}}
{via_master: via73_12x6_shift_right} {between_parallel: true}}
In the previous definition, {{pattern_id: 2}{net_id: 1}} refers to the second pattern
specified by the -add_patterns option: {{pattern: wire_base} ... {parameters:
{M3 horizontal ...}}}, and the first net specified by the -nets option: VDD. Likewise,
{{pattern_id: 3}{net_id: 1}} refers to the third pattern definition: {{pattern:
segment_base} ... {parameters: {M7 horizontal ...}}}, and the first net: VDD.
Based on this definition, the tool inserts a via73_12x6_shift_right stacked via at the
intersection of the M3 and M7 straps. The {between_parallel: true} statement allows
the tool to insert the vias between parallel straps.
The commands to create this power plan, including the via master rules, are as follows:
set_pg_via_master_rule via73_12x6_shift_right \
-contact_code {VIA34 VIA45 VIA56 VIA67} \
-via_array_dimension {12 6} -offset {3 0}
set_pg_strategy core_patterns \
-pattern {{name: via_bridging} \
{nets: VDD VSS } {offset: {5 5}}} -core
create_pg_composite_pattern tapering_base \
-parameters {layer dir side_w center_w side_s center_s pt1 pt2} \
-add_patterns { \
{{pattern: first_wire} \
{parameters: {@layer @dir @side_w @side_s @pt1}}} \
{{pattern: center_wire} \
{parameters: {@layer @dir @center_w @center_s @pt1 @pt2}}} \
{{pattern: last_wire} \
{parameters: {@layer @dir @side_w @side_s @pt2}}} \
}
create_pg_composite_pattern tapering_straps \
-parameters {h_pt1 h_pt2 v_pt1 v_pt2} \
-add_patterns { \
{{pattern: tapering_base}
{parameters: {M7 horizontal 10 5 2 7.5 @h_pt1 @h_pt2}} \
{pitch: {0 30}}} \
{{pattern: tapering_base}
{parameters: {M6 vertical 8 4 2 6 @v_pt1 @v_pt2}} \
{pitch: {25 0}}} \
}
The -via_rule option specifies which via is placed at each intersection of layers M4
and M5. The following figure is annotated with the pattern_id and net_id numbering
for this power plan. In this example, {pattern_id: 1} refers to the first pattern in the
-add_patterns option: the vertical power straps on layer M4. {pattern_id: 2} refers
to the second pattern: the horizontal power straps on layer M5. {pattern_id: 1}
{net_id: 1} refers to the first net following the nets: keyword listed for the first pattern
specification.
Based on this specification, vias are placed at the intersections of {pattern_id:
1} {net_id: 1} and {pattern_id: 2} {net_id: 1}. Vias are also placed at the
{offset: 4}}} \
-via_rule { \
{{{pattern_id: 1} {net_id: 1}} \
{{pattern_id: 2} {net_id: 1}} {via_master: default}} \
{{{pattern_id: 1} {net_id: 2}} \
{{pattern_id: 2} {net_id: 2}} {via_master: default}} \
{{{pattern_id: 1} {net_id: 2}} \
{{pattern_id: 2} {net_id: 1}} {via_master: NIL}} \
{{{pattern_id: 1} {net_id: 1}} \
{{pattern_id: 2} {net_id: 2}} {via_master: NIL}} \
{{intersection: undefined} {via_master: NIL}}}
Alternatively, use the Task Assistant to define the power plan region.
1. Select Task > Task Assistant in the GUI.
2. Select PG Planning > PG Region in the Task Assistant.
3. Enter the region name, region area, expansion parameters, and other information in
the Task Assistant.
4. Click Preview to display the Tcl command you specified.
5. Click Apply to create the power plan region.
To create a power plan region that is bounded by a polygon, specify the -polygon option
followed by the coordinates of the polygon. The following example creates a power plan
region named region_polygon bounded by the coordinates (2000,2000), (4000,2000),
(4000,4000), and (2000,4000).
To create a power plan region that excludes specified macros, use the -exclude_macros
option and specify the list of macros to exclude. You can create an offset around the
macro by including the -macro_offset option. In the following example, the tool creates
an indentation in the region to exclude the specified macro.
icc2_shell> create_pg_region region_exclude -core \
-exclude_macros {u_l/u_m/ahbram0/aram_1/x0_t0} -macro_offset 50
{region_exclude}
To create a PG region that surrounds macros in the design, use the -group_of_macros
option. You can create an offset by including the -expand option. In the following example,
the tool creates a region around the specified macros and expands the region by 50
microns.
icc2_shell> set macros {u_l/u_m/ahbram0/aram_0/x0_t0
u_l/u_m/dsu0/x0/mem0_ram0_0_x0_x0_t0
u_l/u_m/ahbram0/aram_2/x0_t0
u_l/u_m/dsu0/x0/mem0_ram0_0_x1_x0_t0}
-expand 50
{region_surround}
If you run the create_pg_region command and specify an existing region name, the
command deletes the existing region, reuses the region name, and creates the new region
definition. You can also create a copy of an existing region and make modifications to the
region copy by using the -update option. The next example copies the region_surround
power plan region from the previous example, expands the region, and removes the jogs.
icc2_shell> create_pg_region region_copy -update region_surround \
-expand 75 -remove_jog {expand: 50}
To list all the power plan regions in the design, use the report_pg_regions command.
To list only a single region, specify the region name after the command. The following
example reports the currently defined power plan regions in the design.
icc2_shell> report_pg_regions
Region: region_surround
Points: {{2202.360 3092.270} {2202.360 3575.890} ... }
Region: region_copy
Points: {{2127.360 3017.270} {2127.360 4647.760} ... }
To delete a power plan region, use the remove_pg_regions command followed by the
region name. To remove all regions, use the remove_pg_regions -all command. The
following example removes the power plan region named region_copy.
icc2_shell> remove_pg_regions region_copy
PG region region_copy is removed.
To define the power plan strategy, use the set_pg_strategy command as in the following
example.
icc2_shell> set_pg_strategy ring_strat -core \
-pattern {{name: ring_pattern} {nets: {VDD VSS}} \
{offset: {3 3}} {parameters: {M7 10 2 M8 10 2 true}}} \
-extension {{stop: design_boundary}}
Alternatively, use the Task Assistant to define the standard cell rail pattern.
1. Select Task > Task Assistant in the GUI.
2. Select PG Planning > Strategy in the Task Assistant.
3. Enter the strategy name, PG nets, pattern name, routing area, and other settings in the
Task Assistant.
4. Click Apply to apply the strategy.
In the previous example, the set_pg_strategy command defined a strategy that
associated the ring_pattern pattern with the ring_strat strategy. The following example
defines a strategy that associates the mesh_pattern pattern for the power mesh defined in
Creating Power and Ground Mesh Patterns with the mesh_strat strategy. The -extension
option extends the power mesh to the outermost ring.
icc2_shell> set_pg_strategy mesh_strat -core \
-extension {{stop: outermost_ring}} \
-pattern {{pattern: mesh_pattern} {nets: {VDD VSS}}}
The following example defines a strategy that associates the macro_pattern macro
connection pattern defined in Creating Power and Ground Macro Connections with the
macro_strat strategy.
icc2_shell> set_pg_strategy macro_strat -core \
-pattern {{pattern: hm_pattern} {nets: {VDD VSS}}}
The following example defines a strategy that associates the rail_pattern standard cell
connection pattern defined in Creating Power and Ground Standard Cell Rails with the
rail_strat strategy.
icc2_shell> set_pg_strategy rail_strat -core \
-pattern {{pattern: std_cell_rail} {nets: VDD VSS}}
The following sections summarize the specification keywords and their function for the
-pattern, -blockage and -extension options.
• The {nets: {net1 net2 ...}} argument specifies the power and ground net names
for the strategy. You can also define placeholder names in the create_pg_*_pattern
command and set the actual net names using this argument.
To specify a null or empty slot for a net, replace the net name with the dash (-)
character. For example, {nets: {VDD - VSS -}}.
• The {offset: {x_offset y_offset}} argument specifies the x- and y-offset to
apply when creating the first pattern. This argument is not used for scattered pin macro
connection patterns or standard cell rail patterns.
• The {offset_start: boundary | {x y}} argument specifies the starting point
for the pattern offset. This argument is not used for scattered pin macro connection
patterns or standard cell rail patterns.
• The {parameters: value1 value2 ...} argument specifies the ordered
list of values for the parameters defined with the -parameters option of the
create_pg_*_pattern command.
• The {skip_sides: {side1 side2 ...}} argument defines the sides to omit when
creating the power ring. This argument is valid only for ring patterns.
• The {side_offset: {side: number} {offset: offset}} argument defines the
offset for each specified side in the ring pattern. This argument is valid only for ring
patterns.
describes the available arguments. Note that not all arguments are valid for all pattern
types.
• The {layers: {layer1 layer2 ...}} argument specifies the layers to avoid routing
over the blockage.
• The {nets: {net1 net2 ...}} argument specifies the power and ground net names
to avoid routing over the blockage. This list of nets is a subset of the nets specified by
the -pattern option.
• The area is defined by the pg_regions, blocks, macros, pg_regions, polygon, or
voltage_areas argument, followed by a list of elements or points.
The preceding example creates a via rule that inserts the VIA23_FAT via between shapes
on layer M2 defined by strategy strat1 and shapes on layer M3 defined by strategy strat2.
New vias are omitted between other metal layer intersections.
Alternatively, use the Task Assistant to define the via rule.
1. Select Task > Task Assistant in the GUI.
2. Select PG Planning > Create PG in the Task Assistant.
3. Click the Via rule tab.
4. Enter the rule name.
5. Select Advanced, click Define and define the details of the via rule.
6. Click Apply to create the via strategy.
The command instantiates the power plan defined by the specified strategy and checks
for any DRC violations created by the power plan. In a typical flow, you create the ring,
mesh, rail, or macro pattern, associate the pattern with a power plan strategy by using the
set_pg_strategy command, instantiate the pattern with the compile_pg command, and
then repeat the flow for the next pattern type in the power plan.
If you specified the power plan incorrectly, or if the power plan contains an error, you can
remove the power plan with the compile_pg -undo command as shown in the following
example. The compile_pg -undo command removes only the power and ground network
created by the most recent compile_pg command.
To ignore DRC violations while creating the power network, include the -ignore_drc and
-ignore_via_drc options. The compile_pg -ignore_drc -ignore_via_drc command
creates the power network and reports DRC violations created by the power plan, but
does not remove power straps or vias that create DRC violations.
In the following examples, the reports show what check was performed, what action was
taken, and what object is causing the issue.
• Check – The check that is performed
• Policy
◦ tolerate – The tool makes predictable and explainable assumptions to mitigate
the violation. No changes are made to the design or setup.
◦ error – The tool does not mitigate the violation, but issues an error message.
-------------------------------------------------------------------------
-------
1
Ignore DRC repair for stapling vias and do not create plan.pgroute.disable_stapling_vi
the via. Use this application option to improve runtime a_fixing
at the expense of additional DRC errors. By default, the
command tries to repair the DRC violation.
Load the frame view of macro, block, and standard cell plan.pgroute.load_frame_view
instances when performing DRC checking. By default,
the frame views are not loaded.
Enable the tool to derive net information for cut without plan.pgroute.derive_cut_net_from
net information. _pin
PG Script Generator
Creating a pattern-based PG network can be time-consuming due to the complex Tcl
syntax. To simplify the process, you can convert the configuration file that contains the
pattern specifications in PG syntax to a Tcl script that includes all the commands you need
to create the PG structure.
To generate the PG Tcl script,
1. Open or create the configuration file that contains your pattern-based power network
specifications.
If you do not have a configuration file, use the following command to create a default
configuration file that includes the syntax for all the functionality available in pattern-
based PG creation, including power strap and via configurations:
icc2_shell> generate_pg_script -template
2. Modify the keyword syntax and values in the configuration file to meet your power
network requirements.
3. Run the generate_pg_script command, specifying the configuration file as your input
file:
icc2_shell> generate_pg_script -input dp_pgConfig.txt \
-output pg_script.tcl
If you do not specify the -output option, the tool creates a script file named
ppns_script.tcl. You can edit and reuse the Tcl script as needed.
4. Source the Tcl script in the IC Compiler II tool:
icc2_shell> source pg_script.tcl
The keywords in the configuration file correspond to the keywords in the Tcl syntax. See
the command man pages for detailed usage.
The following example shows an excerpt of the PG syntax in a configuration file:
StrapConfig: PG_TOP_MESH1 {
# required
target_area: core
category: mesh
nets: "VDD VSS"
# optional
tag: M2_M3_MESH
blockage: macros:{ u_macro/mem1 u_macro/mem2}
extension: {{stop: 10}{layers: M1}}
layer: M2 {
# required
widths: 0.4
direction: horizontal
spacings: interleaving
pitch: 7
# optional
offset: 0
alignTrack: track
trim: false
}
layer: M3 {
# required
widths: 0.8
direction: vertical
spacings: 1.2
pitch: 8
# optional
offset: 0
alignTrack: track
trim: false
}
}
The following example shows the corresponding Tcl commands written out by the
generate_pg_script command:
set_pg_strategy_via_rule NO_VIA \
-via_rule { {{intersection: undefined}{via_master: NIL}} }
create_pg_mesh_pattern PG_TOP_MESH1_PTRN \
-layers { \
{{horizontal_layer:M2}{width:0.4 }\
{spacing:interleaving}{pitch:7}\
{track_alignment: track}{trim: false}{offset:0}} \
{{vertical_layer:M3}{width:0.8 }\
{spacing:1.2}{pitch:8}{track_alignment: track}\
{trim: false}{offset:0}} \
}\
set_pg_strategy PG_TOP_MESH1_STR \
-extension {{{stop: 10}{layers: M1}}} \
-blockage {macros:{ u_macro/mem1 u_macro/mem2}} \
-pattern { {name: PG_TOP_MESH1_PTRN}{nets: VDD VSS}} \
-core
PG Vias
The create_pg_vias command inserts vias at metal intersections on adjacent layers. The
following examples show different applications of the create_pg_vias command:
• Create vias at all intersections.
icc2_shell> create_pg_vias -nets VDD
Committed 288 vias.
• Insert vias on the VDD net to connect layers M3 to M4, set the shape_use attribute for
the via as stripe, and do not perform a DRC when inserting the via.
icc2_shell> create_pg_vias -nets {VDD} -from_layers M3 \
-to_layers M4 -drc no_check -mark_as stripe
Committed 288 vias.
• Insert vias within the specified bounding box for layers from M6 to M8 and connect
macro pins to the PG straps.
icc2_shell> create_pg_vias -nets VDD -drc no_check \
-within_bbox [get_attribute [current_block] bbox] \
• Create a via matrix for VDD and VSS net shapes with a shape_use attribute set
of stripe. Use the VIA34f via master and set the tag attribute on the via matrix to
pg_via_matrix.
icc2_shell> set bbox [get_attribute [get_core_area] bbox]
icc2_shell> create_pg_vias -nets {VDD VSS} -from_types stripe \
-to_types stripe -via_masters {VIA34f} -within_bbox $bbox \
-start {{741 735} {708 720}} -pitch {{66 30} {66 30}} \
-create_via_matrix -tag pg_via_matrix
The general flow is as follows in which the secondary PG placement constraints can be
specified as part of this flow,
1. Use the split_constraints and commit_block commands to create the subblocks.
2. Create voltage area shapes by using the shape_blocks command.
3. Create PG straps at the top level, then use the characterize_block_pg command to
create the PG strategies for the subblocks.
4. Create power network as follows:
a. Read the UPF power intent by using the load_upf command.
b. Create the PG straps at the block level by using the compile_pg command.
Note:
After power planning and secondary PG placement constraints are
committed at the blocks and at the top level, then a second placement is
necessary. This places the dual-rail cells based on the secondary PG strap
locations.
5. Create a new corner, estimated_corner, and optimize the top-level interface logic by
using the estimate_timing command.
When you commit the constraints at the top level of the design, use the
commit_secondary_pg_placement_constraints -commit_subblocks command.
The -commit_subblocks option checks all block-level secondary PG constraints and
commits any uncommitted constraints. The command commits the secondary PG
placement constraints at both top and linked subblocks.
To display the associated block for each constraint, use the
report_secondary_pg_placement_constraints -all_blocks command.
To check for consistency and error conditions in specific blocks, use the
check_secondary_pg_placement_constraints -blocks command with a list of
blocks.
To define secondary PG constraints manually, use the
create_secondary_pg_placement_constraints command and to define secondary
PG constraints automatically, use the derive_secondary_pg_placement_constraints
command.
The flow to implement a design plan iteration after the initial design netlist is generated in
the tool topographical mode is shown in the following figure:
Note:
The load_block_constraints command that loads constraints for child
and top blocks is not supported by the tool. However, you can use the
run_block_script command to run the specified Tcl script on a set of blocks.
In the following example, the load_secpg_constraints.tcl script runs the
create_secondary_pg_placement_constraints command, which then
creates the relevant constraints.
The flow to implement a design plan iteration after the partial floorplan is generated in the
tool topographical mode is shown in the following figure:
Power strap to
routing blockage
within macro
Command Description
Command Description
To automatically detect shapes that can be converted to PG pattern shapes, use the
-layers, -region, or -shapes option with the convert_shapes_to_shape_pattern
command instead of listing the shapes with the shape_list argument. When you enable
this feature, the tool creates PG pattern shapes based on the layers, regions, or shapes
you specify.
Optimizing PG Pattern Shapes
To optimize PG pattern shapes to more efficient PG pattern shapes, use the
decompose_shape_patterns command. If the specified PG pattern shapes are
suboptimal, the tool replaces them with more efficient, nearby PG pattern shapes.
icc2_shell> decompose_shape_patterns [get_shape_patterns]
{RECT_PATTERN_0 RECT_PATTERN_1}
resulting in a reduction in database size and faster processing by the tool. The commands
in the following table perform operations on via matrixes as described in the following
topics.
Command Description
To automatically detect vias that can be converted to efficient via matrixes, use the
-via_defs, -region, or -vias option with the convert_vias_to_via_matrix command
instead of listing the vias. When you enable this feature, the tool creates via matrixes
based on the via definitions, regions, or vias you specify. The command can convert vias
into multiple via matrixes with different dimensions.
Converting Via Matrixes into Vias
In some cases you might need to convert a via matrix to individual vias to manage
specific via locations. To convert one or more via matrixes into individual vias, use the
convert_via_matrixes_to_vias command.
icc2_shell> convert_via_matrixes_to_vias \
[get_via_matrixes {VIA_MATRIX_0 VIA_MATRIX_1 }]
{VIA_SA_0 VIA_SA_1 ...}
For PG straps, only DRC violations that are repaired by cutting part of the wire shape are
listed. Abutted phantom PG straps are merged and reported as part of the same error.
When a phantom via is created, information about the via and the DRC violation caused
by the via are saved. The information includes data about the top and bottom wire shapes,
via def, and net name. The error information shows the initial violation before fixing.
The following figure shows a missing via error displayed in the Error Browser.
The following figure shows a portion of the design before and after running the
merge_pg_mesh command.
Use options with the merge_pg_mesh command to control how the shapes are merged:
• Limit the merge to specific shape types. The allowed shape types are: stripe,
ring, macro_pin_connect, lib_cell_pin_connect, follow_pin, core_wire, and
user_route.
icc2_shell> merge_pg_mesh -types {core_wire stripe}
• Limit the merge to only the specified nets with the -nets option as shown in the
previous example.
• Undo the previous merge_pg_mesh command with the -undo option.
The following figure shows the stapling vias created by the create_pg_stapling_vias
command.
Specify options with the create_pg_stapling_vias command to control how the stapling
vias are inserted.
• Specify a region in which to insert vias with the -regions option
icc2_shell> set core [get_attribute [get_core_area] bbox]
icc2_shell> create_pg_stapling_vias -regions $core -nets {VDD VSS} ...
• Create a via matrix of stapling vias instead of individual vias by specifying the
-create_via_matrix option. Other settings are the same as the previous example.
Note that this example creates 136 via matrixes, one for each horizontal row of
overlapping metal shapes on layers ME1 and ME2.
icc2_shell> create_pg_stapling_vias \
-nets {VDD VSS} -from_layer ME2 -to_layer ME1 \
-from_shapes [get_shapes -filter "layer_name == ME2"] \
-to_shapes [get_shapes -filter "layer_name == ME1"] \
-create_via_matrix -tag pg1
• Specify the offset in both the x- and y-directions with the -offset {x_offset
y_offset} option. The x_offset value specifies the amount to shrink the layer
intersection in the x-direction. The y_offset value specifies the amount of vertical
displacement to apply.
• Limit the number of vias in an inserted via array with the -max_array_size option.
• Specify contact codes to use when inserting vias with the -contact_code option.
• Specify custom PG via masters to form a stacked via by using the
set_pg_via_master_rule command and the -via_masters option with the
create_pg_stapling_vias command. In this case, via pitch is defined within
the set_pg_via_master_rule command; the -pitch option is not used with the
create_pg_stapling_vias command.
icc2_shell> set_pg_via_master_rule via1_staple \
-contact_code via1 -via_array_dimension {2 1} \
-allow_multiple {5 0} -snap_reference_point {0 0}
Figure 104 shows a via inserted by the previous command. The via1_staple and
via2_staple via masters are shown below the inserted via for reference.
switch ring or array. Use the -driver option to assign a driver cell for the pattern. Use
the -direction horizontal | vertical option to specify the placement direction.
Use the -connect_mode hfn | daisy option to specify whether the power switches are
connected in high-fanout mode (hfn) or daisy-chain mode. Use the -pattern option to
specify the actual placement pattern. Use the -port_net_name option to set the net name
prefix for the nets in the connection pattern.
After inserting the power switch ring or array, you can connect the control pins of the
power switches with the connect_power_switch command as follows:
icc2_shell> connect_power_switch \
-source [get_pins u0_2/pd_switchable/sw_ctl] -mode hfn \
-port_name p2_sd -object_list [get_cells u0_2/.* -regexp \
-filter "ref_name == HEAD2X16_HVT"]
Options to the connect_power_switch command control how the power switches are
connected. Use the -source option to specify the control signal within the power domain
for the power switch. Use the -mode hfn | daisy | fishbone option to specify the
connection strategy for the power switches as shown in Figure 105. Use the -port_name
option to specify the base name of the switch ports when a new port is created. Use
the -object_list option to specify the switch cells to connect. See the man page for
additional options.
• Specify the name of the power switch library cell with the -lib_cell option.
icc2_shell> create_power_switch_ring -lib_cell HEAD16DM \
-voltage_area G/PD
• Specify an instance name prefix for the switch cells with the -prefix option.
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-prefix POWERSWITCH_"
icc2_shell> get_cells {*/POWERSWITCH_*}
{G/POWERSWITCH__snps____snps_HEAD16DM_H0_1477 ...}
• Define the shape or bound to place the switch cells with the -voltage_area,
-voltage_area_shape, or -boundary option.
icc2_shell> create_power_switch_ring -lib_cell HEAD16DM \
-voltage_area G/PD
icc2_shell> create_power_switch_ring -lib_cell HEAD16DM \
-voltage_area_shape {VOLTAGE_AREA_SHAPE_2}
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-boundary {{100 100} {200 200}}
• Specify the initial offset and spacing between each power switch with the -x_pitch,
-y_pitch, -x_offset, and -y_offset options.
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-x_pitch 10 -y_pitch 10 -x_offset 20 -y_offset 20
• Specify the placement pattern and orientation of the switch cells with the -pattern and
-orient options. In a power switch array, the same orientation is applied throughout
the array. In a power switch ring, switch cells placed on the top and right edges are
rotated accordingly.
icc2_shell> set_power_switch_placement_pattern -placement_type ring \
-name pattern1 -pattern {HEAD32DM {HEAD16DM 2} {HEAD8DM 3}}
icc2_shell> create_power_switch_ring -power_switch mult_sw \
-pattern pattern1 -orient r180
• Specify the starting and ending points of a partial ring with the -start_point and
-end_point options.
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-start_point {100 70} -end_point {388 175} -x_pitch 20 \
-y_pitch 30 -orient R180
• Specify the list of filler cells to be placed into gaps in the power switch ring with the
-filler_cells option. The tool inserts the largest possible filler cell into the gap
between power switch cells.
icc2_shell> create_power_switch_ring -power_switch mult_sw \
-filler_cells {FILL8 FILL4 FILL2} -snap_to_site_row false
• Specify the corner library cell name and orientation to use when placing
cells at the inner (concave) and outer (convex) corners of the ring with the
-inner_corner_cell, -inner_corner_cell_orient, -outer_corner_cell, and
-outer_corner_cell_orient options.
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-inner_corner_cell {*/HEAD16DM} -outer_corner_cell {*/HEAD16DM}
• Specify the library cell to be inserted along vertical edges with the
-vertical_lib_cell, -vertical_lib_cell_orient, and -vertical_filler_cells
options.
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-vertical_lib_cell HEAD16DM -vertical_filler_cells FILL8 \
-vertical_lib_cell_orient R0
• Specify a boundary along which to insert power switch cells with the -through_points
option.
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-through_points {{100 100} {500 100} {500 300}}
• Specify the total number of power switches to be inserted and evenly distributed with
the -switch_number option.
icc2_shell> create_power_switch_ring -power_switch inst_sw \
-switch_number 5
• Specify the vertical power and ground wires with which to align the power switches with
either the -pg_straps or -pg_strategy option.
icc2_shell> create_power_switch_array -power_switch mult_sw \
-pg_straps [get_shapes -of VDD -filter "layer_name==M8"] \
-y_pitch 10
Alternatively, you can set the resistance attribute directly on cell instances. The following
example sets the power_switch_resistance attribute to specify a resistance value of
10 ohms on instances of switch cell SWITCH_1 and a resistance value of 20 ohms on
instances of switch cell SWITCH_2.
icc2_shell> set_attribute {$switch_cell_1} \
-name power_switch_resistance -value 10
icc2_shell> set_attribute {$switch_cell_2} \
-name power_switch_resistance -value 20
Note that the attribute has a higher priority than the application option.
Use options with the trim_pg_mesh command to control how the mesh is trimmed.
• Trim only the specified net names or layers with the -nets and -layers options. You
can also use the -shapes option and specify a collection of net shapes. The following
two commands are equivalent.
icc2_shell> trim_pg_mesh -nets {VDD} -layers {M5}
icc2_shell> trim_pg_mesh \
-shapes [get_shapes -filter "layer_name==M5 && owner.name==VDD"]
• Trim only nets of the specified type, including ring, stripe, lib_cell_pin_connect,
macro_pin_connect, and macro_conn.
icc2_shell> trim_pg_mesh -types {ring stripe}
• Trim the net to the wire boundary (default) or the via boundary with the -trim_to
target_wire | via option.
An example via rule file is as follows. Note that the (#) character and comments
following the character are for reference only and are not allowed in the file.
viaRule1 {
bottom_layer: METAL # Bottom metal layer to check
top_layer: METAL6 # Top metal layer to check
stack_via: true # Enable/disable stacked via check
parallel: false # (Optional) Enable/disable via check
# between parallel wires
macro_pin: true # (Optional) Enable/disable via check
# to macro and power switch pins
pitch: 10 # (Optional) Specifies the via pitch
# for parallel wires
}
• Write a report that contains the layer and location of each missing via with the
-output_file option.
icc2_shell> check_pg_missing_vias -nets VDD -output_file viacheck.rpt
Check net VDD vias...
Number of missing vias on VIA5 layer: 72
Total number of missing vias: 72
...
icc2_shell> sh cat viacheck.rpt
Total number of missing vias: 72
1: Missing via of net VDD on layer VIA5
bbox: {1773.06, 1573.06}, {1778.06, 1578.06}
2: Missing via of net VDD on layer VIA5
bbox: {1773.06, 364.565}, {1778.06, 374.565}
...
• Write out the default via rules file to defaultViaRule.txt with the
-write_default_via_rule_file option.
icc2_shell> check_pg_missing_vias -nets VDD \
-write_default_via_rule_file
Successfully write default via rule to defaultViaRule.txt
After writing the defaultViaRule.txt file, you can modify it and load the file with the
-via_rule_file option to create a custom via check rule file.
• Avoid reporting an error if the via site is smaller than the minimum contact code for the
layer with the -ignore_small_intersections option.
• Avoid reporting an error if the error location is covered by a routing blockage with the
-honor_routing_blockage option.
Use options with the check_pg_connectivity command to control how the check is
performed.
• Use the -nets option to limit the check to a specific collection of power and ground
nets.
icc2_shell> check_pg_connectivity -nets {VDD VSS}
• Use the -write_connectivity_file option to write out the results of the connectivity
check to a text file.
icc2_shell> check_pg_connectivity -write_connectivity_file conn.txt
• Use the -check_macro_pins one | all | none option to check the power ground
connections to macro cells. The one argument checks for at least one connection, the
all argument specifies that all power ground pins must be connected, and the none
argument disables this check.
icc2_shell> check_pg_connectivity -check_macro_pins none
...
Number of Macro Cells: 0
• Use the -check_block_pins one | all | none option to check the power ground
connection for block pins. The one, all, and none arguments have the same meaning
as the arguments of the -check_macro_pins option.
icc2_shell> check_pg_connectivity -check_block_pins all
• Use the -check_pad_pins one | all | none option to check the power ground
connection for pad pins. The one, all, and none arguments have the same meaning
as the arguments of the -check_macro_pins option.
icc2_shell> check_pg_connectivity -check_pad_pins all
To create a collection of floating objects in the power network, save the value returned
by the check_pg_connectivity command to a variable. The following example runs
the check_pg_connectivity command, saves the collection of floating objects to the
floating_objects variable, and selects the floating objects in the GUI.
icc2_shell> set floating_objects [check_pg_connectivity]
Loading cell instances...
Number of Standard Cells: 9392
...
icc2_shell> change_selection $floating_objects
You can use multiple threads to shorten the runtime for the check_pg_drc command.
Use the set_host_options -max_cores n command to set the maximum number of
processing cores to use when checking power ground DRC.
The check_pg_drc command supports options to control which PG nets and which area
of the design the tool checks for DRC violations. This command does not check objects of
non-PG nets.
• Use the -nets option to limit the checking to a specified collection of power and ground
nets.
• Use the -ignore_clock_nets true option to skip checking of routing objects for clock
nets.
• Use the -coordinates option to limit the check to a specified bounding box.
• Use the -bottom_layer and -top_layer options to limit the check to a specified
range of layers.
• Use the -no_gui option to skip writing the error browser database for the GUI.
• Use the -output option to write out a text version of the DRC check result to a file.
• Use the -load_routing_of_all_nets option to check the existing routing shapes and
vias of all PG nets.
For example, if spacing between a PG-net-routing-shape and a routing-shape
of signal net is less than it is required by a rule, an error is reported only if the
-load_routing_of_all_nets option is true. But a similar error is never reported if the
two shapes are assigned to signal nets.
• Use the -check_detail_route_shapes option to check the routing shapes and vias of
PG nets that have the detail_route usage attribute set; if this option is not specified,
the check_pg_drc command ignores such shapes.
A short example of the DRC text file is as follows:
=================
Error type: insufficient space between two same-net via-cuts
Violated rule: Cut-Min_Spacing-Rule
Layer: VIA5
Minimal spacing: 0.07
Actual spacing: 0.05(south - north)
Spacing box: {3408.42 1571.75} {3408.46 1571.8}
Via #1: box = {3408.41 1571.7} {3408.46 1571.75}
net = VDD
Via #2: box = {3408.42 1571.8} {3408.47 1571.85}
net = VDD
=================
Error type: illegal overlap of net-shapes
...
You can review the errors reported by the check_pg_drc command in the GUI. Select
Error > Error Browser in the GUI, and select DRC_report_by_check_pg_drc as the Data
Name. The tool loads the DRC data in the Error Browser.
By default, power network routing ignores signal routes during DRC checking to maximize
performance. To enable the compile_pg, create_pg_strap and create_pg_vias
commands to validate the DRC correctness of power straps and vias with respect to signal
routes, set the plan.pgroute.honor_signal_route_drc application option to true as
follows:
icc2_shell> set_app_options -name plan.pgroute.honor_signal_route_drc \
-value true
plan.pgroute.honor_signal_route_drc true
Alternatively, read a file that contains the virtual pad locations by using the
read_virtual_pad_file command as described in Using Virtual Pad Files. You can
also use the existing power pads in the design as pad locations by referencing them
with the -pad_references option to the analyze_power_plan command as shown in
the following step.
If your design contains existing power pads, specify the references to the power pads
with the -pad_references option as follows. This option accepts a list of power net
name and cell reference pairs with the format net_name:pad_reference_name.
icc2_shell> analyze_power_plan -nets {VDD VSS} -power_budget 1000 \
-voltage 1.5 -pad_references {VDD:VDD_NS VSS:VSS_NS}
The command generates detailed report files containing instance power values for
each cell instance together with resistance and voltage drop values for wires in the
power plan.
icc2_shell> ls pna_output
leon3mp.VDD.icc2.pna leon3mp.VSS.icc2.pna
leon3mp.VDD.power leon3mp.VSS.power
leon3mp.VDD.pw_hl.pna leon3mp.VSS.pw_hl.pna
...
Maximum IR Drop for Net VDD: 115.480 mV at (2372.000 2763.830)
on layer M6
...
Maximum IR Drop for Net VSS: 69.161 mV at (1805.500 1183.448)
on layer M6
The tool reports the amount of current supplied by each virtual pad, the total current in
the power grid, the total current for each metal layer, the point of maximum IR drop, and
the percentage of routing tracks used by PG nets. The PNA Voltage Drop map panel is
populated and the map is displayed on the layout as shown in the following figure. Move
the pointer over the map overlay to view the voltage drop, resistance, and current values
at that point in the layout.
The file contains the PG net name followed by the pad locations for the net as shown
in the following example. The auto keyword specifies that the layer is assigned
automatically.
icc2_shell> sh cat pads.txt
VDD
1033.275 1860.740 auto
352.915 1116.020 auto
VSS
1033.275 1860.740 auto
352.915 1116.020 auto
In this example, power network analysis analyzes only metal layers M5 and higher. By
default, this application option is set to "" and power network analysis considers all metal
layers.
If the design contains custom via defs created with the create_via_def command, the
characterize_block_pg command writes out the create_via_def commands into each
block PG creation script to re-create the custom via defs at the block level.
If you specified the -compile_pg_script pg_script option, the tool writes out a map
file that associates the power planning scripts with the reference blocks. The pg_script
file can contain setup commands and application options for creating the power ground
routing, but it should not contain via master rules, patterns, strategies, or strategy via rule
commands. During distributed power network creation, the map file is associated with the
2. Set the host options for distributed processing with the set_host_options command.
icc2_shell> set_host_options -name block_script host_settings
11
Performing Global Planning
To improve global routing between design blocks during the design planning phase, the IC
Compiler II tool supports operations to group similar nets, create global routing corridors,
and push global route objects into blocks. Global planning enables you to better manage
routing resources between blocks. You typically use global bus planning after running
block shaping and macro placement.
For more details, see the following topics:
• Topology Interconnect Planning
• Creating Routing Corridors
• Creating Global Routes Within Routing Corridors
• Adding Repeater Cells
• Pushing Down Repeater Cells
verify the top-level interconnections more efficiently. Topology plans are visible in the GUI,
where you can use the Design Assistant to create and modify the constraints in the layout.
Figure 109 shows the topology interconnect planning flow.
• Bundles are used to group supernets together into a bundle object. Signals within
a bundle can be rearranged and sorted to create custom pin ordering. To create a
bundle, use the create_bundle command and specify the bundle name and the
supernets in the bundle as shown in the following example.
icc2_shell> create_bundle \
-name Bundle_z163261 [get_supernets z163261]
For more information about creating bundles, see Creating Bundles and Bundle
Constraints.
To create a topology plan for specific supernet bundles, specify the bundles with the
get_bundles command. The following command creates a topology plan for the supernet
bundle named B_z161756 and assigns the M3 net estimation rule to the plan:
icc2_shell> create_default_topology_plans \
-net_estimation_rule M3 [get_bundles B_z161756]
{TOPOLOGY_PLAN_B_z161756}
To specify layer specific repeater distance, you can create a net estimation rule (NER)
for each metal layer and assign these multiple NERs to a topology plan. This approach
ensures that the tool applies the relevant NER to the relevant metal layer. If two or more
NERs apply to the same layer, the tool assigns the most recent NER. For example, if
NER1 is associated with M3, NER2 with M5, and NER3 with M5, then the tool applies
NER3 for the M5 layer.
To associate multiple NERs to a topology plan or a topology edge, use the following
commands. In the following example, topology plan A is associated with the net estimation
rules, NER1, NER2, and NER3.
icc2_shell> create_topology_plan -name A \
-net_estimation_rule {NER1 NER2 NER3}
(or)
icc2_shell> set_attribute [get_topology_plans A] \
-name net_estimation_rule – value {NER1 NER2 NER3}
(or)
icc2_shell> set_attribute [get_topology_edges A/edge1] \
-name net_estimation_rule – value {NER1 NER2}
If an edge segment has multiple NERs associated with it, then the tool applies the
following logic:
• If the segment has no layer shape, then the tool applies the first rule from the NERs list
• If the segment has a layer share, then the tool applies the most recent NER that
matches the layer; if no NER matches this criterion, then the first rule from the NERs
list is applied
You can also use the current_topology_plan command to set the current topology plan.
icc2_shell> current_topology_plan my_topology_plan
In the GUI, you can set the current topology plan by choosing Set Current Topology Plan
from the context menu.
With a topology plan selected, click the Constraints Editor tab at the right of the
Topologies panel to view the list of nodes and edges in the topology plan, as shown in
Figure 112. To perform different operations on the nodes and edges, right-click a node
or an edge and select an item from the menu.
• Use the report_topology_plans command to write out information for one or more
topology plans. The command reports the net estimation rule, topology nodes, topology
edges, and other information about the topology plan.
icc2_shell> report_topology_plans TOPOLOGY_PLAN_Bndl_150
...
Topology Plan Description
------------------------------
TOPOLOGY_PLAN_Bndl_150
comment:
stats: 5 nodes, 4 edges, 0 repeaters
net_estimation_rule: M3
objects: 1 bundles
nodes:
TOPOLOGY_PLAN_Bndl_150/TOPOLOGY_NODE4
is_reference: false
num_edges: 1
num_driving_edges: 1
objects: 1 ports
...
edges:
TOPOLOGY_PLAN_Bndl_150/TOPOLOGY_EDGE3
start_node: TOPOLOGY_PLAN_Bndl_150/TOPOLOGY_NODE3
end_node: TOPOLOGY_PLAN_Bndl_150/TOPOLOGY_NODE4
net_estimation_rule:
objects:
repeaters:
...
Error/Warning/Information Message
This command creates new nodes and edges for topology edges that have the
shape_layers attribute defined with Manhattan-style edge segments. If a topology edge
does not meet these criteria, no new nodes or edges are created for that topology edge.
One of the use cases where you can use this command is shown in Figure 113. As
illustrated, when you create a topology plan for a bundle that has a long route, you need
not manually create the feedthrough topology nodes for each and every block in the
bundle. Instead, run the refine_topology_plans command that automatically creates
the necessary feedthrough nodes on these blocks.
The following command refines all the topology plans within the current design:
icc2_shell> refine_topology_plans
The tool performs global routing to create a manhattan route and adds repeaters and
sequential elements to the route. Repeater type and spacing is specified by the net
estimation rule assigned to the topology plan - while defining the spacing, note that a
single spacing rule may be insufficient in constraining all repeaters. If the endpoint for
the topology plan is a block or if the block contains feedthroughs, the tool command also
creates pins on the block.
The repeater optimization takes place in two passes:
1. The tool places all the repeater (sequential and electrical) along the route and fixes all
the spacing violation.
2. The tool performs the legalization operation and inserts additional repeaters where
necessary.
Figure 114 shows repeater optimization in two passes for a straight route by the
optimize_topology_plans command:
Table 12 Examples Where the Command Honors the Physical Location of Existing
Repeaters
Tool honors the preexisting repeaters that are at the top (as shown below)
Tool honors the preexisting repeaters that are inside the block (as shown below)
Block A Block C
Block A Block C
Supernet
Supernet
Tool honors the preexisting repeaters that are at the top and within the block
(as shown below) Tool honors the preexisting repeaters in a branch bus (as shown below)
Supernet
Supernet
Table 13 Example Where the Command Honors the Logical Location of Existing
Repeaters
While optimizing, the tool adds repeaters, as appropriate (as shown below)
Path 1
Path 1
Path 2 Repeater
Repeater
Optimization Path 2
Repeater
The following figure shows a topology plan before and after optimization. In the figure, the
yellow squares represent the block pins, the red triangles represent suggested repeater
locations, and the red rectangles represent suggested sequential element locations.
In the initial stages of your design, where the netlist is not yet finalized, during the
optimization phase you might want to ignore pin or feedthroughs (that is, the netlist
connectivity) below a certain hierarchy. This approach is useful when you want to look at
the implementation results for the parts of the netlist that are complete or finalized, and
ignoring the rest of the design. You can achieve this result by using the stop_hierarchy
user attribute. The flow is as follows:
1. Specify which part of the hierarchy of a bundle you want the tool to ignore.
set_attribute bundle_name \
stop_hierarchy hierarchy_name
For example, the following command ensures that the tool ignores the netlist
connectivity in block C.
icc2_shell> set_attribute [get_bundles Bundle_0] stop_hierarchy {C}
A B
Example where stop_hierarchy is defined for the start node Example where stop_hierarchy is defined for the middle node
c c
Sub block A/a Sub block B/b Sub block C/c Sub block A/a Sub block B/b Sub block C/c
Block D Block D
Supernet Supernet
Block E Block E
Example where stop_hierarchy is defined for the end node Example where stop_hierarchy setting works for
multiply instantiated blocks and multiple levels of physical hierarchy
Block A Block B Block C
Block A Block B Block D_0
c NODE_0
Block D
Block D_1
Supernet
Block E
Connectivity for E is ignored
After optimizing the topology plan, you can perform a sanity check by using the
check_topology_plans -mode post_optimization command.
To specify whether to report all the registers (-type all) or -type unimplemented | all
only those that are not yet bound to the physician registers
(-type unimplemented) for the specified topology plans
In the following example, there are totally eight registers of which four are yet to be bound
to physical registers.
Design
Report
fc_shell> report_topology_plan_registers -type all
#<topology_plan>,<block_pins_before_PRP_registers>,<block_pins_after_PRP_regist
ers>,<number_of_total_PRP_registers>,<number_of_open_PRP_registers>
================================================================================
=============================================================
TOPOLOGY_PLAN_bundle_A_to_B_16,{A/A_to_B_bit_0_0...A/A_to_B_bit_0_15},{B/A_to_B
_bit_0_0...B/A_to_B_bit_0_15},8,4
--------------------------------------------------------------------------------
----------------------------------
1
After running the optimize_topology_plans command, the GUI updates the layout view
and displays the topology plan with new buffering.
Figure 116 Optimizing Topology Plans for Different Net Estimation Rules
You can also use the current_topology_plan command to set the current topology plan.
icc2_shell> current_topology_plan my_topology_plan
In the GUI, you can set the current topology plan by choosing Set Current Topology Plan
from the context menu.
The following command propagates the current topology plan across multiple MIB
instances that are in the current design:
icc2_shell> propagate_topology_plans [current_topology_plan]
The following command propagates the specified topology plan, A2B, across multiple MIB
instances that are in the current design:
icc2_shell> propagate_topology_plans [get_topology_plans A2B]
The following command ensures that if the current topology plan is already assigned to
the destination MIB instance, then it is not overwritten. If the -no_overwrite option is not
specified, then the topology plan in the destination MIB instance is overwritten.
icc2_shell> propagate_topology_plans [current_topology_plan]
-no_overwrite
# design: ORCA
current_block ORCA
current_block ORCA
current_block ORCA
current_block $_curr_
The following example creates a topology group that includes topology plans for clock
signals.
icc2_shell> create_topology_group -name TOPOLOGY_GROUP_CLK -plans
sys_clk-pclk \
-comment {For clocks}
One topology plan can belong to only one topology group. Topology plans
cannot be shared across multiple topology groups.
◦ Enter information in the create_topology_group dialog box, if required, and
click OK.
If you provide a name to the topology group and if it previously exists within the
current block, an error is thrown. However, you can have topology groups with
the same name within different blocks of the design.
The created topology groups are displayed in the block window.
You can also use the current_topology_group command to set the current topology
group.
icc2_shell> current_topology_group TOPOLOGY_GROUP_CLK
In the GUI, you can set the current topology group by choosing Set Current Topology
Group from the context menu in Design Assistant.
(or)
icc2_shell> current_block A
icc2_shell> current_block B
In the GUI, you can remove topology groups by choosing Remove Topology Group from
the context menu in Design Assistant.
Figure 117 Branching Bundle Example Figure 118 Ripping Bundle Example 1
A B
• Ensure that all the nets within the bundle connect to the same two ending blocks (the
leaf driving block and the leaf load block)
• If there are additional blocks between the leaf driver and leaf load block, ensure that
the nets follow the same order from the leaf driver block to the leaf load block, or from
the leaf load block to the leaf driver block
To create a bidirectional bundle,
1. Create a supernet by using the set_supernet_exceptions and create_supernet
commands.
2. Create a bundle with supernets (from step 1) of opposite signal directions by using the
create_bundle command.
The tool supports two types of routing corridors: complete and partial. A complete corridor
is a corridor which encloses all the pins of the nets assigned to that corridor. A partial
corridor is a corridor that has pins (of nets assigned to the corridor) that are physically
placed outside of the corridor area. Figure 121 shows a complete corridor and a partial
corridor.
Complete Partial
Corridor Corridor
Alternatively, you can use the Create Routing Corridor tool in the GUI to create the
corridor.
1. Select the nets to associate with the new routing corridor.
2. Select Create > Routing Corridor in the GUI.
3. Change any additional settings as needed, such as the minimum or maximum layer,
the allowed drawing angles, snap settings, and so on.
4. Draw the routing corridor by clicking the mouse at the vertices of the corridor.
The IC Compiler II tool supports several commands to create, modify,
and remove routing corridors. To add nets to a routing corridor, use the
add_to_routing_corridor command. To extend the shape of the routing corridor,
use the create_routing_corridor_shape command. To return a collection of routing
corridors, use the get_routing_corridors command. To return a list of shapes that are
contained in the routing corridor, use the get_routing_corridor_shapes command.
To remove nets from a routing corridor, use the remove_from_routing_corridor
command. To modify a routing corridor by removing a portion of the shape, use the
remove_routing_corridor_shapes command.
3. Globally route the net that is associated with the corridor by using the route_group
command with the -global_planning option set to true.
icc2_shell> route_group -global_planning true -nets [get_nets \
-of_object [get_routing_corridors corridor_a]]
2. (Optional) If your design contains multiply instantiated blocks, check that they are
correctly aligned with cell rows and wire tracks before pushing down objects.
icc2_shell> check_mib_alignment -cell_row -wire_tracks
------ Start Of Cell Row Misalignment Check -------
Misaligned cell_rows: 0, misaligned cell_sites: 0
------ End Of Cell Row Misalignment Check -------
------ Start Of Wire Track Misalignment Check -------
Warning: Misalignment at track TRACK_14 on layer METAL6 between
MIB instances I_ORCA_TOP/I_BLENDER_1 and
I_ORCA_TOP/I_BLENDER_6. Track offset of I_ORCA_TOP/I_BLENDER_1
is 0.205, and track offset of I_ORCA_TOP/I_BLENDER_6 is 0.41.
(MIB-203)
...
Misaligned wire_tracks: 6
------ End Of Wire Track Misalignment Check -------
To push down the repeater cells and the nets connected to those cells, use the
push_down_objects command and specify the repeater cell instances.
icc2_shell> push_down_objects [get_cells eco_*]
4. Push down the repeater cells and the nets connected to those cells.
To do this, use the push_down_objects command and specify the repeater cell
instances.
icc2_shell> push_down_objects [get_cells eco_*]
12
Performing Clock Trunk Planning
To manage clock trunks during design planning, the tool supports clock trunk planning.
A clock trunk is a coarse-grain physical distribution of the clock, which starts at the clock
source and ends at the clock trunk endpoint. This capability allows you to
• Manage clock trunks earlier in the design cycle
• Provide physical guidance for clock tree implementation during clock tree synthesis
• Perform clock pin placement by using information about the clock tree
• Mitigate timing issues on the clock trunk
The result is a more robust clock topology for your design. This capability also enables
you to reuse or repeat the clock topology even when there are minor modifications to the
netlists.
Figure 122 shows where the clock trunk planning fits in the overall design planning flow.
Figure 122 Clock Trunk Planning in the Overall Design Planning Flow
Split Constraints
Initialize Design
Create Abstracts
Shape Blocks Physical planning without datapath
timing:
Place Macros and Standard Cells - Anchor and topology synthesis
Create Power Network - Clock pin placement
Perform Global Planning
Place Pins
Estimate Timing QoR refinement considering inter-block
Budget Timing timing:
Perform Block-Level Implementation - On-chip variation impact on virtual
in-place optimization slack values
Perform Top-Level Closure
- What-if analysis
Figure 123 shows the clock trunk planning terminologies that you need to be familiar with.
Feedthrough pin
Top-level clock
trunk arc
Block-level clock
trunk arc
Clock port
For more information about constraints for clock tree synthesis, see the Clock Tree
Synthesis topic in the IC Compiler II Implementation User Guide.
2. Load the constraint mapping file into the tool with the set_constraint_mapping_file
command.
-host_options host_option_name
The following example generates clock trunk endpoints for the misc, leon3s, leon3s_1,
leon3s_2, and leon3s_3 blocks:
icc2_shell> synthesize_clock_trunk_endpoints \
-blocks {misc leon3s leon3s_1 leon3s_2 leon3s_3} \
-clocks list_of_clocks \
-host_options block_script
...
Running Block misc ...
...
1
Figure 125 shows the results after performing block-level clock trunk planning.
Clock port
The following figures show examples of clock trunk endpoints in various situations.
Figure 128 Clock to Multiple Flip-Flops With Buffers Only on Branch Path
Figure 130 Clock to Flip-Flop With Buffers and Buffered Feedthrough With Balance Point
DESIGN_VIEW_CHECK Error: Design view for the Abstract '%s' does not exist.
(TL-101)
CLOCK_LOOP_CHECK Error: Output pin '%s' is driving input pin '%s' of the
same physical hierarchy instance '%s'. (TL-140)
Note: Only for clock path.
2. Prepare the hierarchical design for clock trunk planning by using the following
command:
icc2_shell> synthesize_clock_trunk_setup_hier_context -init \
-host_options host_option_name
4. Update the hierarchical design after clock trunk planning by using the following
command:
icc2_shell> synthesize_clock_trunk_setup_hier_context -commit \
-host_options host_option_name
To enable or disable the constraints that were set using the set_ctp_constraints
command on specific blocks, use the set_editability command. The clock trunk
planning engine ignores the blocks that were disabled and does not enforce the
constraints on these blocks.
To place pins on specific sides of the blocks, use the -sides option. To disallow placing
of pins on specific sides, use the -exclude_sides option. Both of these options accept a
positive integer that represent the sides of a block. For a block, the left-most lowest edge
takes the value of 1 and as you move in a clockwise direction, increment this number
by one. For example, -sides {1 2 4} allows pins to be placed on edges 1, 2, and 4.
However, -exclude_sides {2 3 5} disables pins being placed on edges 2, 3, and 5.
These two options are mutually exclusive. 0 is not a valid value.
To place pins on a specific portion of an edge or edges, use the -offset option along with
the -sides option. To exclude a specific portion, use the -offset option along with the
-exclude_sides option.
To specify the metal layers on which you want to allow pin placement, use the
-allowed_layers option.
b c
10 Side 2
Length = 14 units
Side 1 Side 3
5 Length = 10 units Length = 10 units
Side 4
0 Length = 10 units
a d
Example 2: Use the following command to disallow pin placement on side 1 within the
offset 4 to 8.
icc2_shell> set_ctp_constraints ABC_cell_name -exclude_sides 1
-offset {4 8}
b c
10 Side 2
Length = 14 units
8
Side 1 Side 3
Length = 10 units Length = 10 units
Side 4
0 Length = 10 units
a d
Example 3: Use the following commands to allow pin placement on sides 1 and 2 within
the offset 0 to 5.
icc2_shell> set_editability
(or)
0 5 14
b c
10 Side 2
Length = 14 units
Side 1 Side 3
5 Length = 10 units Length = 10 units
Side 4
0 Length = 10 units
a d
This command removes the constraint set by the set_ctp_constraints command. All
other pin constraints set using block/individual pin constraint remain as is.
The remove_ctp_constraints command has no effect on the blocks that are disabled
using the set_editability command.
The following command removes the clock tree planning pin constraints from all the blocks
in your current design.
icc2_shell> remove_ctp_constraints
3. For multiple levels of physical hierarchy designs, enable generation of top-level pin
constraints, by using the following command:
icc2_shell> set_app_options -name
plan.clock_trunk.enable_mph_constraints \
-value true
4. Enable feedthrough cells on clock nets by using the following application option
settings:
icc2_shell> set_app_options \
-name plan.pins.exclude_clocks_from_feedthroughs -value false
If this application option is set to true, the tool does not create feedthroughs on clock
nets.
5. Remove the following pin constraints already defined on the clock nets:
• Topological pin feedthrough constraints, which are defined with the
create_topological_constraint command, by using the following command:
icc2_shell> remove_topological_constraints -all
During clock trunk planning, the tool honors the following constraints when determining
the location of block pins and feedthrough pins:
• Feedthroughs allowed in physical block by using the set_block_pin_constraints
-allow_feedthroughs true -blocks command
• Routing blockages
• Clock metal layer assignments
6. (Optional) Set the cts.common.user_instance_name_prefix application option to
identify the buffers or inverters added by the top-level clock trunk planning.
icc2_shell> set_app_options \
-name cts.common.user_instance_name_prefix -value ICC2_TOP_CTP_
7. Check the feasibility of performing clock trunk planning as described in Checking the
Feasibility of Performing Clock Trunk Planning.
5. Push down the top-level clock trunk into the blocks with the push_down_clock_trunks
command.
icc2_shell> push_down_clock_trunks
This command also runs the place_pins command on the top-level clock nets while
honoring pin constraints. The final clock pin placement is guided by the clock trunk cell
placement, and pushed down cells are removed.
Analyze the QoR as described in Performing QoR Analysis.
To consider clock trunk planning during budgeting and analyze the clock reconvergence
pessimism (CRP) effects,
1. Enable budgeting to use the clock trunk planning results by using the
compute_budget_constraints command.
icc2_shell> compute_budget_constraints -latency_targets estimated \
-balance true
2. Write out the tool-derived budgeting constraints by using the write_script command.
icc2_shell> write_script -include budget -output budget_constraints
3. Check for the -crp option in the output file, as shown in the following example output:
set_latency_budget_constraints -default -crp 0.00205341 -from_clock
clk:nw/clk -to_clock clk:cc/clk
set_latency_budget_constraints -corner default -crp 0.00205341
-from_clock clk:nw/clk -to_clock clk:cc/clk
set_latency_budget_constraints -default -crp 0.00252273 -from_clock
clk:sw/clk -to_clock clk:cc/clk
3. icc2_shell> split_constraints
The preceding steps add the clock information for each newly created clock input port. For
more information about the split_constraints command, see the Splitting Constraints
topic.
Example 2
In the following example, incremental clock trunk planning keeps the pin constraints
for clk2 same as step 1, whereas for clk1, it overwrites the pin constraints based on
constraints set at step2.
1. icc2_shell> synthesize_clock_trunks -from pin_constr_generation \
-to pin_constr_generation -clock [get_clocks {clk1 clk2}]
Example 3
In the following example, incremental clock trunk planning writes the pin constraints
file and pin placement only for clk1 (that is, for the nets specified by using the -to
read_pin_constr_and_place_pins option.
Example 4
In the following example, in step 4, the tool places the pins based on constraints from step
3 for clk1 and from step 1 for clk2.
1. icc2_shell> synthesize_clock_trunks -from pin_constr_generation \
-to pin_constr_generation -clock [get_clocks {clk1 clk2}]
4. icc2_shell> synthesize_clock_trunks \
-from read_pin_constr_and_place_pins \
-to read_pin_constr_and_place_pins -clock [get_clocks {clk1 clk2}]
13
Performing Pin Assignment
The IC Compiler II tool provides extensive control over pin placement and feedthrough
creation during floorplanning. Pin placement is based on global routing and can be guided
by user-defined constraints. You can make minimal changes to an existing pin placement
by changing constraints and running pin assignment in incremental mode.
Pin placement considers all multiply instantiated block (MIB) instances during global
routing and pin assignment. Comprehensive pin placement validation and reporting
commands are available to qualify pin placement results. The GUI supports pin editing,
moving, shaping to adjust placement, as well as pin-based net connectivity analysis and
topological constraint visualization. During the ECO process, you can re-create existing
pin locations and feedthroughs.
The flow to generate pin constraints, place pins, incrementally modify pin placement, and
validate placement results is shown in Figure 135.
Place pins
place_pins
The following example creates a pin blockage with a rectilinear boundary that applies to
the M1 and M2 layers only:
icc2_shell> create_pin_blockage -boundary {{0 0} {2000 0} \
{2000 2000} {1000 2000} {1000 1000} {0 1000}} -layers {M1 M2}
The following example creates a pin blockage with a rectangular boundary that is
associated with physical pins:
icc2_shell> set pins [get_pins -physical_context cell1/pin*]
icc2_shell> create_pin_blockage -boundary {{100 100} {200 200}} $pins
• When individual net (or pin) side, offset, layer, or order constraints conflict with bundle
constraints, the place_pins command ignores bundle pin constraints for those nets (or
pins) and places other bundle pins together.
• When individual net (or pin) width, length or spacing constraints conflict with bundle
width, length, or spacing constraints, the place_pins command honors both individual
and bundle constraints.
• If there are pins in a bus with a different spacing or width from other pins in the bus,
all bus pins are placed on the same layer in the order defined in the bundle pin
constraints.
Pin width is determined by the pin constraints applied to the block and by the following
precedence rules:
1. If the pin is placed on a wire track with nonzero track width, the pin width is the same
as track width and any other width-related pin constraints are ignored. In this case, the
minimum width rule defined in the technology file is ignored.
2. If the pin has no width-related pin constraints, but its net has a nondefault routing rule
that requires a specific width on the pin layer, the pin width is the width specified by the
nondefault rule.
3. If the pin does not have width-related pin constraints or a nondefault routing rule, the
pin width is the same as the minimum width rule defined in the technology file.
corner_keepout_num_tracks: 5
pin_spacing: 1
allowed_layers: M2 M3 M4 M5 M6 M7 M8 M9
hard_constraints: off
• Create additional offset from the corner of a block to the closest pin by specifying a
number of tracks or a distance in microns
icc2_shell> set_block_pin_constraints -corner_keepout_num_tracks 5
icc2_shell> set_block_pin_constraints -corner_keepout_distance 10
• Set the spacing between adjacent pins by specifying a number of tracks or a distance
in microns
icc2_shell> set_block_pin_constraints -pin_spacing 5
icc2_shell> set_block_pin_constraints -pin_spacing_distance 10
• Specify the allowed block sides where pins can be placed or the sides where pins
cannot be placed
icc2_shell> set_block_pin_constraints -sides {1 2}
icc2_shell> set_block_pin_constraints -exclude_sides {3 4}
• Enable feedthroughs for a block; disable feedthroughs by setting the option to false
icc2_shell> set_block_pin_constraints -allow_feedthroughs true
• Specify which constraints must be met, even if the tool creates a DRC violation
icc2_shell> set_block_pin_constraints \
-hard_constraints {spacing location layer length}
Alternatively, use the Task Assistant to define the individual pin constraint.
1. Select Task > Task Assistant in the GUI.
2. Select Pin Assignment > Pin-based Constraints.
3. Click the Pin-based Constraint Table.
4. Enter the constraints in the table and click Apply.
Note that if you specify multiple conflicting pin constraints for the same pin, the last
constraint takes precedence.
• Specify the sides of the block that can be used to place the pin
icc2_shell> create_pin_constraint -type individual \
-sides {1 2 3}
• Specify the sides of the block that cannot be used to place the pin
icc2_shell> create_pin_constraint -type individual \
-exclude_sides {4}
• Create a specified distance between the starting point for the block edge and the first
pin on that edge
icc2_shell> create_pin_constraint -type individual \
-sides 1 -offset 10
Alternatively, specify a range of locations in which the pins can be placed by specifying
a minimum and maximum offset as follows:
icc2_shell> create_pin_constraint -type individual \
-sides 1 -offset {5 15}
• Set the x- and y-location in the top-level design to place the pin
You can also create bundles of supernets with the create_bundle command.
icc2_shell> create_bundle -name supernet_bundle1 \
[get_supernets {supernet_0 supernet_1}]
2. (Optional) Verify the net contents of the bundle with the report_bundles command.
icc2_shell> report_bundles [get_bundles Bundle1]
Begin bundle report ..
Bundle NAME: `Bundle1'
Number of objects in bundle 4
Bundle Type 'net'
Objects in bundle
Position = 0, net sd[0]
...
2. (Optional) Verify the contents of the bundle with the report_bundles command.
icc2_shell> report_bundles [get_bundles {B_ahbmi}]
Begin bundle report ..
Bundle NAME: `B_ahbmi'
Number of objects in bundle 24
...
To modify an existing bundle by adding or removing nets, use the add_to_bundle and
remove_from_bundle commands.
You can also use the Design Assistant dialog box in the GUI to create or modify bundles of
nets as follows:
1. Select View > Assistants > Design Assistant in the GUI.
2. Enter the net selection command in the command box.
3. Select the nets to add to the bundle from the list.
4. Choose Bundles > Create Bundle from the menu.
5. Enter the bundle name.
6. Sort the list by selecting the sort options and clicking the Sort button, or by dragging
and dropping the signals to reorder the list.
7. Click OK to create the bundle.
Figure 136 shows the Design Assistant and Create Bundle dialog boxes.
• To control the ordering of the pin placement for signals in the bundle, use the
-bundle_order option.
• To specify the minimum distance between adjacent pins in microns, use the
-pin_spacing_distance option.
separately. The commands to create this routing are as follows and the simplified layout
result is shown in Figure 137.
icc2_shell> create_bundle -name bundle1 [get_nets \
{Bus_0 Bus_1 ... Bus_127}]
icc2_shell> create_pin_constraint ... -bundles bundle1 \
-layers {M3 M5} -cells B
icc2_shell> create_bundle -name bundle2 [get_nets \
{Bus_128 Bus_129 ... Bus_255}]
icc2_shell> create_pin_constraint ... -bundles bundle2 \
-layers {M3 M5} -cells C
Bus[127:0]
Bus[255:128]
A C D
After reading the constraints, use the report_pin_constraints command to view the
constraints.
The pin constraints file is divided into sections, and each section of the file begins with a
section header and ends with a footer. Within each section, constraints are surrounded
by curly brackets and each record description ends with a semicolon (;). Empty lines are
ignored, and comments begin with a pound sign (#).
Topological Map
The topological map section specifies how a net or group of nets should be routed through
blocks during pin placement. Pin constraints specified in the topological map section take
precedence over block-level pin constraints.
The topological map section of the constraints file is specified as follows:
• Each record begins with the Nets or Bundles keyword, contains the names of one or
more nets or bundles, and is followed by pairs of objects on the net or bundle.
• Each cell, pin, or port specification should be grouped together by a pair of curly
braces.
• Each keyword and its value should be enclosed by a pair of curly braces.
• For clarity, the description of the whole net or bundle constraint should be enclosed
by curly braces; however, this is not strictly required and is not shown in the following
example.
• Use an asterisk (*) as a wildcard character to specify nets with similar names. An
asterisk is not supported as a wildcard character for bundle names.
• The net or bundle constraint is terminated with a semicolon (;).
start topological map;
{Nets net_names}
{{Port port_name_1} {Cell cell_name_1}}
{{Cell cell_name_1} {Cell cell_name_2}}
{{Cell cell_name_2} {Pins pin_name_1}};
{Bundles bundle_names}
{{Cell cell_name_1} {Cell cell_name_2}};
end topological map;
For block objects specified by the Cell keyword, you can include side, offset, and layer
constraints for the block pins by using the side, offset and layer keywords. The side
constraint specifies the side number for the block where the pins are inserted. The side
number is a positive integer that starts from 1. Given any block with a rectangular or
rectilinear shape, the lowest leftmost edge is side number 1. The sides are numbered
consecutively as you proceeded clockwise around the shape.
The offset specifies the distance in microns from the starting point of a given edge to the
routing cross-point on that edge in clockwise direction. The starting point for edge number
1 is the lower vertex, the starting point for edge number 2 is the left vertex, and so on. You
must specify the side number when you specify an offset. The layer constraint specifies
the metal layers to use for the pins.
The general syntax for a block object constraint is as follows:
{{Cell cell_name_1} {sides side_number}
{offset offset_1} {layers {layer_1 layer_2 ...}}}
TOP
UA
UB0 UB1
tA
ne
inA out
TOP
Cell_A Cell_B Cell_C
Cell_E
Net_A
The following example connects top-level port A to pin Cell_C/a. If Net_A does not
connect to Cell_B, the tool forces the connection to pass through Cell_B.
# Example 3
start topological map;
{Nets Net_A}
{{Port A} {Cell Cell_B}}
{{Cell Cell_B} {Pins Cell_C/a}};
end topological map;
TOP
Cell_B Cell_C
Net_A
A a
TOP
Cell_A Cell_B Cell_C
Net_A
Net_B
Data_In*
The following example routes the Bundle1 and Bundle2 net bundles through the Cell_A
and Cell_B blocks.
# Example 5
start topological map;
{Bundles Bundle1 Bundle2}
{{Cell Cell_A} {Cell Cell_B}};
end topological map;
TOP
2 30 2 2
40
Net_A
Cell_C
Cell_A
Cell_B
1 1 3 1 3
4 10 4 20 4
Note that you can create the same topology for a group of nets by specifying net names
separated by white space within the curly brackets. You can also use the asterisk
character (*) as a wildcard.
The following figure shows three layout results. The figure on the left is the default
behavior when feedthroughs are disallowed on abutted blocks. The middle and right
figures show possible layout results when the plan.pins.allow_mixed_feedthroughs
application option is true.
A A A
C C C
D B D B D B
Feedthroughs allowed
Feedthroughs not allowed
Net1In
A
A B C
X Y Z
Note that Net1 has pins in blocks B, X, and Z, and the global router routes the net by
creating a feedthrough in block B. Any feedthroughs created by the tool are labeled with
the “_FEEDTHRU_n” suffix. The NoFeedthrough statement in the constraints file prevents
the tool from creating a feedthrough in blocks X or Y, and the global router creates a
feedthrough in block C instead.
TOP
MIB_A MIB_B MIB_C
Block_A
Feedthrough Control
The feedthrough control section specifies the blocks that allow or disallow feedthroughs.
Pin constraints specified in the feedthrough control section take precedence over block-
level pin constraints. Each record contains one or more net or bundle names within a pair
of curly brackets, followed by a Feedthrough or NoFeedthrough keyword, followed by
block cell names within curly brackets.
Any feedthrough nets created by the tool contain the “_FEEDTHRU_n” suffix. To modify
this suffix, set the plan.pins.new_port_name_tag application option. Block feedthrough
pins created by the tool have the is_feedthrough_port attribute set to true. Inside the
block, all feedthrough nets, ports, and corresponding routing objects created by the tool
have the is_shadow attribute set to true.
Note that you can route signals over blocks without creating feedthroughs.
Disable feedthroughs for the block and net by specifying the NoFeedthrough
keyword in the feedthrough control section, and create a routing corridor with the
create_routing_corridor command. When you create pins with the place_pins
command, the signal is routed over the block and feedthroughs are not created for the
specified signal.
The general syntax is as follows. Note that this is only a syntax example; you typically do
not specify both the Feedthrough and NoFeedthrough keywords for the same net.
start feedthrough control;
{Nets net_name}
# Specify either Feedthrough or NoFeedthrough
# but not both for a given net
{Feedthrough cell_name_1 cell_name_2 cell_name_3}
{NoFeedthrough cell_name_4 cell_name_5 cell_name_6};
{Bundles bundle_name}
• Topological map constraints can take priority over feedthrough control statements.
For example, A->B and B->C forces a feedthrough on B, regardless of whether
feedthroughs are allowed on B.
A single Feedthrough or NoFeedthrough statement completely specifies the allowed
feedthrough modules for the net. Feedthrough statements are not cumulative. If multiple
feedthrough statements exist for the same net, the last feedthrough statement overrides
the earlier statements and a warning message is issued.
Feedthrough and NoFeedthrough statements override the default feedthrough permission
set by the set_block_pin_constraints -allow_feedthroughs true | false
command for the specified nets.
The statement { Feedthrough A B } does not force the creation of feedthroughs on A
and B. Instead, the statement allows feedthroughs on blocks A and B, while restricting
feedthroughs on all other blocks. To force a specific feedthrough path, you must use
topological constraints.
If there are feedthrough constraint conflicts between topological map constraints and
previous feedthrough constraints, the feedthrough constraints from the constraint file
take priority. If there are conflicts between feedthrough constraints and topological map
constraints, topological map constraints take priority.
The following example enables feedthroughs for net Xecutng_Instrn[0] on blocks I_ALU,
I_REG_FILE, and I_STACK_TOP.
start feedthrough control;
{Nets Xecutng_Instrn[0]}
{Feedthrough {I_ALU I_REG_FILE I_STACK_TOP}};
end feedthrough control;
The following example prevents feedthroughs for net Xecutng_Instrn[0] on blocks I_ALU,
I_REG_FILE, and I_STACK_TOP.
Supported keywords are: net, pins, reference, sides, layers, offset, order, start,
end, off_edge, location, width, and length. The side constraint specifies on which
side number the pin should be inserted for the specified block cell. The side number is a
positive integer that starts from 1. Given any rectangular or rectilinear shape, the lower
leftmost edge is side number 1. The sides are numbered consecutively as you proceeded
clockwise around the shape. The shape refers to the reference boundary shape for the
block.
The offset constraint specifies the distance in microns from the starting point of a specific
edge to the routing cross-point on that edge in the clockwise direction. The starting point
for side 1 is the lowest vertex, the starting point for side 2 is the left vertex, and so on.
Since the offset is specific for each edge, you must specify the side information with the
offset.
Each record in the physical pin constraints section is contained within curly brackets.
The first element in the record can be a top-level net or a port for a reference block. If the
record is a port object, the next record should be the reference block name associated
with the port.
In the following example, ports C and D on reference block REFA are constrained. This
provides flexibility to use the constraint both inside the block design and at the top level.
start physical pin constraints;
{Net E} {cell A} {layers M2} {sides 2};
{Net E} {cell B} {layers M4} {sides 4};
{Pins C} {reference REFA} {layers M2} {sides 2};
{Pins D} {reference REFA} {layers M2} {sides 2}
{width 0.8} {length 0.8};
If the top-level block cells are instances of multiply instantiated blocks (MIBs), and there is
more than one record for each port on the MIB's reference block, the last constraint record
takes priority over previous constraint records.
10
C A C
1 RISC_CORE 3
A B D
B C A
D D B
4 40
The reference keyword specifies the block reference that this constraint applies to. For a
block cell, this constraint refers to the reference cell name, not the cell instance name, if it
constrains the top level.
The sides keyword specifies one or more sides of the block. If there is more than one
side, specify the side number within curly brackets separated by white space. Use an
asterisk (*) as a wildcard character to specify that all sides are allowed.
The layer and spacing constraints are specified as pairs. You can specify multiple
layer-spacing pairs. The layer value is the metal layer name and the spacing value is the
minimum number of wire tracks between adjacent pins for the specified layer. Only the
specified layers are used for pin placement; unspecified layers are not used by the pin
placer. In addition, only layers that are allowed in the corresponding reference blocks are
allowed for pin placement.
Keywords are case-insensitive. The reference name and the layer name are case-
sensitive. If a line contains a syntax error, the line is ignored. The command issues
warnings or errors for any lines that are ignored.
If the pin spacing control section contains conflicting constraints for the same edge, same
layer and the same block, the last constraint takes priority and the command issues an
error or warning message.
In the following example, the CPU block cell is constrained to a minimum pin spacing
of 2 wire tracks on layer M2, a minimum pin spacing of 3 wire tracks on layer M4, and a
minimum pin spacing of 3 wire tracks on layer M6 for sides 2 and 4 of the block. If the pins
are placed on sides 2 or 4, the pins must be placed on layer M2, M4, or M6. Note than
when reference, sides, and layer-spacing pairs are given, unspecified layers are strictly
not used by the tool for pin placement on the specified block sides. If the pins are placed
on sides other than 2 or 4, the pins must honor the block pin constraints applied to the
CPU block. Note that individual or bundle pin constraints can override these constraints.
start pin spacing control;
{reference CPU} {sides {2 4}} {M2 2} {M4 3} {M6 3};
end pin spacing control;
The following example sets pin constraints on references DATA_PATH and ALU:
start block pin constraints;
{reference DATA_PATH}
{layers {METAL3 METAL4 METAL5}}
{feedthrough true}
{corner_keepout_num_tracks 1}
{spacing 5}
{exclude_sides {2 3}};
{reference ALU}
{layers {METAL3 METAL4 METAL5}}
{feedthrough true}
{hard_constraints {spacing location layer}}
{sides {2 3}};
end block pin constraints;
To view the congestion map, select View > Map > Channel Congestion in the GUI. The
IC Compiler II tool also provides the What-if Channel Congestion panel for interactive
analysis of congested channels. Figure 148 shows a channel congestion map and the
What-if Channel Congestion panel.
• The routing direction of a given layer is not consistent with the block edge constraints
In this example, the routing direction for layer M3 is horizontal, but the pin access is set
to the top and bottom sides of the block.
icc2_shell> set_attribute \
-quiet [get_layers M3] routing_direction horizontal
icc2_shell> set_block_pin_constraints -cells B2 \
-allowed_layers [get_layers M3] -sides {2 4}
icc2_shell> check_pre_pin_placement
...
------ Start Of Constraint Conflict Check ------
Warning: Conflicting block pin constraints
detected. Routing direction of allowed layers M3
incompatible with allowed sides 2, 4 of block
block2. (DPPA-441)
------ End Of Constraint Conflict Check -------
icc2_shell> check_pre_pin_placement
...
------ Start Of Bad Constraint Check ------
Warning: Conflicting block pin constraints detected. Routing direction
of allowed layers METAL1 incompatible with excluded sides 1, 3 of
block block2. (DPPA-441)
• Infeasible connection between cells that are separated by a block that has
feedthroughs disabled. Feedthroughs must be enabled on blocks that separate two
cells to allow a net connection through the block.
• Possible overlaps with existing internal block objects (route blockage, pin blockage,
fixed pin, preroute, and so on) during pin creation
icc2_shell> check_pre_pin_placement
...
------ Start Of Pin Blockage Check ------
Warning: Fixed pin iu/clk_cts_3_10 might cause newly-placed abutted
pin in cell dcram_shell to overlap with blockage SNPS_PB_0 that is
close to the abutted edge 7 of cell iu. (DPPA-442)
------ End Of Pin Blockage Check ------
icc2_shell> check_pre_pin_placement
------ Start Of Bad Constraint Check ------
Error: Loop back topological constraints start from and end at cell
BLK3 detected without indicating pin names. (DPPA-453)
------ End Of Bad Constraint Check ------
Placing Pins
After defining pin placement constraints, use the place_pins command to perform global
routing and place pins on the blocks in the current block.
You can limit pin placement to specific layers, cells, nets, pins, and ports, and perform
incremental pin placement. The following command places pins on all blocks within the
current block.
icc2_shell> place_pins
icc2_shell> remove_feedthroughs
4. Use the place_pins command to place pins on all blocks within the current block.
icc2_shell> place_pins
For designs that contain multiply instantiated blocks (MIBs), use the -cells option to
specify the instance to use when placing pins. Pin placement honors all user-specified
blockages on all MIB instances and ignores congestion around MIB instances not
specified with the -cells option.
• Place pins only on the current block by using the -self option.
icc2_shell> place_pins -self
• Avoid placing pins that connect to specific nets by using the -exclude_nets option.
icc2_shell> place_pins -exclude_nets [get_nets Oprnd_B*]
The tool determines pin locations for excluded nets based on net connectivity and
user-specified constraints. This option honors all pin constraints but does not honor
feedthrough constraints or create feedthroughs; feedthrough creation requires route
information from the global router. You should use the global router for pin placement
whenever possible.
• Legalize pin placement by using the -legalize option.
icc2_shell> place_pins -legalize
Specify whether the tool treats the block as a black box. plan.pins.black_box_design_style
Specify how new feedthrough nets for buses are named plan.pins.retain_bus_name
if they are not marked as bus ports or nets in the
database.
Specify whether pins are placed such that all connected plan.pins.strict_alignment
pins are aligned. When this option is true, pin
placement ignores routing tracks and places pins to
strictly align with other placed and connected pins on
the same layer.
Block 1 Block 2
X gap
Y gap
Block 3
Block 1 Block 2
Block 3
Avoid using the remove_pins command unless absolutely necessary, because this
command alters the netlist by disconnecting nets from the pin.
==========--------------------------------------
U2/u0_0 | 6345 | 1
==========--------------------------------------
U1/u0_2 | 6344 | 0
==========--------------------------------------
U1/u0_3 | 6348 | 0
--- End Of Check Feedthrough Net Constraints Summary ---
3. If your design contains multiply instantiated block instances, verify pin placement with
the check_mib_for_pin_placement command.
icc2_shell> check_mib_for_pin_placement -swapped_connections \
-top_level_terminal_locations
4. Use the report_pin_placement command to save the block name, layer, side, and
offset for the current pin placement for each block.
icc2_shell> report_pin_placement > pin_placement.rpt
Alternatively, use the Task Assistant to verify the pin placement and create the pin and
feedthrough reports.
1. Select Task > Task Assistant in the GUI.
2. Select Pin Assignment > QoR Analysis and click the Check tab.
3. Select the checking options as needed to limit the pin verification.
4. Click Apply to check pin placement.
5. Select Pin Assignment > QoR Analysis and click the Report tab.
6. Select reporting options as needed to limit the report to specific nets or blocks.
• Check pin alignment within a specified tolerance, or identify aligned pins that have a
physical block or hard macro between the pins; the default alignment tolerance is zero.
icc2_shell> check_pin_placement -alignment true \
-alignment_tolerance_distance 5
• Report nets that are aligned, but the pins are placed on different layers
icc2_shell> check_pin_placement -alignment true \
-layer_mismatch_only true
• Print out additional information about the nets connected to the violating pins and
report detailed net information about pins with alignment violations; include the
-alignment_report_file filename option to write the output to a file
icc2_shell> check_pin_placement -alignment true \
-report_net_details true
...
********** total unaligned nets **********
...
********** unaligned alignable unblocked nets **********
• Skip checking for nets that have unplaced connections when checking pin alignment;
by default, the -alignment true option includes unplaced pins when checking
alignment
icc2_shell> check_pin_placement -alignment true \
-exclude_unplaced_objects true
• Limit the alignment check to two-pin nets that are aligned but have a physical block or
hard macro placed between the two pins
icc2_shell> check_pin_placement -alignment true \
-blocked_only true
• Write a table of misalignment offsets and the number of pins in each offset range
icc2_shell> check_pin_placement -alignment true \
-alignment_histogram true
...
Total of 17 alignment violations
------Start Of Alignment Histogram-----------
Total Two-Pin Nets: 65
Total Misaligned Nets: 17
Average Misalignment Distance: 24.3668um
Standard Deviation: 48.3um
Maximum: 151.048um
---------------------------------------------
Low Violation (um) High Violation (um) Number
---------------------------------------------
0 50 14
50 100 1
100 150 1
150 200 1
--------End Of Alignment Histogram-----------
• Specify the name of a report file in which to write the console output from the
check_pin_placement command; be default, the tool writes output only to the console
icc2_shell> check_pin_placement -filename pinchecks.txt
• Check the pins only of the specified cell type: BLOCK, HARD_MACRO,
EXTRACTED_TIMING_MODEL, or ALL. The default is BLOCK.
icc2_shell> check_pin_placement -cell_type HARD_MACRO
• Check the pins only of the specified type: PG_PINS, SIGNAL_PINS, or ALL. The
default is SIGNAL_PINS.
icc2_shell> check_pin_placement -pin_type ALL
• Skip checking for block pins without a pin shape; by default, this check is performed
icc2_shell> check_pin_placement -missing false
• Restrict the check to the specified nets; by default, the tool checks all block pins
icc2_shell> check_pin_placement -nets {clk}
• Check if the center of the pin is inside an associated pin blockage and if the pin shape
is on the layer associated with the blockage
icc2_shell> check_pin_placement -pin_blockage true
• Create an ordered list of pins that might have nonoptimal placement and create a
longer routing path than necessary
The -pin_detour check reports nets that have a bounding-box greater than the
bounding box of the standard-cell pins and the top-level terminals or ports that it
connects.
When the -detour_consider_pin_constraints option is set to true, the tool takes
the individual and block pin constraints into account while checking for any pin detours.
icc2_shell> check_pin_placement -pin_detour true \
-detour_tolerance 1.5 -detour_consider_pin_constraints true
• Create an ordered list of pins that might have nonoptimal placement and create a
longer routing path than necessary
The -path_detour check reports nets that have a bounding-box greater than the
bounding box of the driver and load registers and the top-level terminals or ports that it
connects.
When the -detour_consider_pin_constraints option is set to true, the tool takes
the individual and block pin constraints into account while checking for any path
detours.
icc2_shell> check_pin_placement -path_detour true \
-detour_tolerance 1.5 -detour_consider_pin_constraints true
• Check if the center of the pin is within its associated pin guide and whether the pin is
placed on a layer allowed by the pin guide
icc2_shell> check_pin_placement -pin_guide true
To modify the spacing check and treat PG pins as a stop or shield, set the
plan.pins.treat_pg_as_shield application option to true.
icc2_shell> set_app_options -name plan.pins.treat_pg_as_shield \
-value true
• Check for pins that fail to honor their length constraints, width constraints, or double
patterning pin length requirements
icc2_shell> check_pin_placement -pin_size true
• Check for pins shorted with PG or signal preroutes; the -shorts check does not check
for these shorts
icc2_shell> check_pin_placement -pre_route true
• Check for pins that are outside the routing corridor; this option also check for pins that
are on a different layer than specified by the routing corridor
icc2_shell> check_pin_placement -routing_corridor true
• Check only top-level terminals and ignore block pins; by default, the command checks
all block pins
icc2_shell> check_pin_placement -self
• Disable checking for shorted or overlapping pins; by default, the shorts check is
enabled
icc2_shell> check_pin_placement -shorts false
• Check for single, unroutable pins under different conditions; valid values are
connected, unconnected, and all
icc2_shell> check_pin_placement -single_pin all
• Report all the pins that were inserted by the tool to avoid single pins in an abutted
design
icc2_shell> check_pin_placement -synthesized_pins true
• Disable checking for violations of technology-related minimum layer spacing and fat
metal spacing between signal pins, signal and PG pins, and signal and preroute pins
icc2_shell> check_pin_placement -technology_spacing_rules false
• Check MIB instances for two-pin nets that do not connect to the same pin across
all instances of the reference MIB block. Swapped connections are a subset of
asymmetric connections.
icc2_shell> check_mib_for_pin_placement -swapped_connections
---------- Start Of Swapped Connection Check ----------
Error: Port pin_a on MIB Reference Module CPU
is a potentially swapped port. (DPPA-203)
• Check for top-level terminals that connect to the same MIB pin, but at different
locations on the MIB instances.
icc2_shell> check_mib_for_pin_placement -top_level_terminal_locations
---------- Start Of Top Level Terminal Check ----------
Error: Port A[0] on MIB Reference Module dlm_test2 connects to
• Check only pins on specific cells, or pins only connected to specific nets.
icc2_shell> check_mib_for_pin_placement -asymmetric_connections \
-cells {U_MIB2_2/U_DLM_TEST2}
icc2_shell> check_mib_for_pin_placement -asymmetric_connections \
-nets {U_MIB1_2/A}
Checking Feedthroughs
Use options with the check_feedthroughs command to specify how feedthroughs are
checked and what information is reported:
• Specify a collection of blocks for feedthrough analysis
icc2_shell> check_feedthroughs -cells {u0_1}
• Write out a list of feedthroughs that are reused across MIB instances
icc2_shell> check_feedthroughs -reused_feedthroughs
• Check for feedthrough violations on each feedthrough net on each block and for net
bundles
icc2_shell> check_feedthroughs -net_constraints
• Check feedthrough nets that connect top-level ports in the current block
icc2_shell> check_feedthroughs -self
• Include repeater and buffer cells in feedthrough tracing when timing libraries are loaded
icc2_shell> check_feedthroughs -include_buffered
Pure feedthroughs are feedthroughs that have no physical pins or connections other
than buffers or inverters within the block that the net passes through.
• Check intra-block feedthrough alignment for two-pin nets
icc2_shell> check_feedthroughs -alignment
-alignment_tolerance_distance 1
Block A OUT
check_feedthroughs -alignment
check_feedthroughs -alignment \
Block A OUT
-alignment_tolerance_distance x
Use the write_pin_constraints command to write out the current set of pin constraints
for a specific pins, ports, nets, or bundles. Use options to the command to specify the type
of information written for topological and physical pin constraints.
Use the write_pin_constraints command to write out topological and physical pin
constraints for the current block. To limit the output to a specified set of pins, nets, ports,
cells, or bundles, use the -pins pins, -nets nets, -ports ports, -cells cells, or
-bundles bundles option. Use the -exclude_nets option to exclude specified nets from
the list of pins constraints written by this command. Use the -self option to write out
pin constraints for the top-level ports. Specify the output file name with the -file_name
option.
Use the -topological_map {side layer offset offset_range offset_range
layer_range layer_range} option to write out only the specified fields to the topological
map section of the constraint file. If you specify the offset_range argument, the command
adds the offset_range value to, and subtracts the offset_range value from, the current
offset position. This provides additional flexibility for the pin placer during incremental pin
placement. For example, if the current offset is 20 and you specify -topological_map
{offset offset_range 5}, the command writes the offset portion of the constraint as
{offset {15 25}}. If you specify the layer_range argument, the command adds layers
above and below the current layer to the output constraint. For example, if the current
layer is M4 and you specify -topological_map {layer layer_range 2}, the command
adds two layers above and two layers below the current pin layer and writes the layers
portion of the constraint as {layers {M2 M3 M4 M5 M6}}.
In the following example, the command writes out the topological map section of the
constraints file, including net name, pin name, cell name, side, layer range, and offset
range for each constraint. The constraints are based on the existing pin placement. The
pin_constraints.map generated by this command is also shown.
icc2_shell> write_pin_constraints -from_existing_pins \
-file_name pin_constraints.map \
-topological_map {side offset offset_range 5 layer layer_range 1}
1
icc2_shell> sh head pin_constraints.map
START TOPOLOGICAL MAP;
{n832}
{{{pin u_m/U1192/Y}} {{cell u0_0}
{layers {M5 M6 M7}} {sides 4}
{offset {756.280 766.280}}}};
{n1319}
{{{pin U45/Y}} {{cell u0_0}
{layers {M5 M6 M7}} {sides 4}
{offset {1013.464 1023.464}}}};
...
icc2_shell> write_pin_constraints \
-file_name physical_constraints.map -from_existing_pins \
-physical_pin_constraint {side offset offset_range 5 layer}
1
icc2_shell> sh cat physical_constraints.map
START PHYSICAL PIN CONSTRAINTS;
{pins clk} {reference block1}
{layers M5} {sides 3} {offset {694.720 704.720}};
{pins rstn} {reference block1}
{layers M6} {sides 4} {offset {756.280 766.280}};
{pins ahbi[0]} {reference block1}
{layers M2} {sides 4} {offset {171.536 181.536}};
{pins ahbi[1]} {reference block1}
{layers M4} {sides 4} {offset {171.384 181.384}};
...
For example, to write out Tcl commands to re-create the feedthroughs from the two
most place_pins commands and ignore earlier place_pins commands, specify the
-latest_rounds {1 2} option as follows. Note that the feedthroughs created by the first
place_pins command are not included in the feedthroughs.tcl file.
icc2_shell> set_app_options \
-name plan.pins.enable_feedthrough_timestamps -value true
icc2_shell> place_pins -nets A # latest round 3
icc2_shell> place_pins -nets B # latest round 2
icc2_shell> place_pins -nets C # latest round 1
icc2_shell> write_shadow_eco -output feedthroughs.tcl \
-latest_rounds {1 2}
4. Draw a rectangle to define the topological constraint for the start block as shown in
step (2) in the following figure.
5. Draw a rectangle to define the topological constraint for the end block as shown in step
(3).
This completes the constraint as shown in step (4) in the following figure.
After defining the constraint, use the place_pins command to place the pins. The
following figure shows the layout after running the place_pins command with the
topological pin constraint.
After defining a topological constraint, you can perform the following operations:
• Retrieve the currently defined topological constraints with the
get_topological_constraints command.
• Write a report that describes the currently defined constraints with the
report_topological_constraints command.
icc2_shell> report_topological_constraints -all
TPF Constraint Description
------------------------------------------------------
TPF_CONSTRAINT_0 Owner Type blk_net
Owner Name Op_Result[0]
Start Type blk_inst
Start Name I_DATA_PATH
End Type blk_inst
End Name I_ALU
...
• Edit the allowed sides, offset, range, and layer specification for the constraint by
clicking on the cell in the constraint table and modifying the contents of the cell.
• Remove a constraint by clicking the right mouse key over the constraint in the table
and choosing Delete from the context menu.
• Remove a constraint by specifying the remove_topological_constraints command
with the constraint name.
The following example reports the estimated wire length for the entire design and for only
the din[0] and dout[1] nets.
icc2_shell> get_estimated_wirelength
Total wirelength of net is: 4117.640
1
14
Performing Timing Budgeting
To support a hierarchical design flow, the IC Compiler II tool provides timing budgeting
to allocate timing among the blocks in the design. The budgeting process begins by
partitioning the chip-level timing constraints into top-level and block-level constraints.
To speed the budget creation process, the tool creates lightweight timing abstract
representations for the blocks in the design. Each block is virtually optimized to negate
the effects of high-fanout nets and provide more accurate timing estimations. The timing
budgeter uses the optimized timing for each block to derive new budgets. In the final step,
top-level and block-level timing budgets are written out in preparation for further block-
level optimization. The timing budgeter is fully multimode and multicorner aware, and
handles designs with multiply instantiated blocks.
The flow to perform timing budgeting is shown in Figure 152.
Figure 152
To generate timing budgets, chip-level Synopsys Design Constraints (SDC) and UPF files
must be partitioned into top-level and block-level files. The IC Compiler II tool uses the top-
level constraints to constrain the top-level logic when abstract representations of blocks
are used. See Split Constraints Flow for more information about partitioning chip-level
constraint and UPF files.
You typically perform timing budgeting on a design with module pins that are already
placed. Note that timing budgeting step requires separate constraints for the top-level and
block-level logic. See Split Constraints Flow for more information about splitting chip-level
constraints into top-level and block-level constraints.
To efficiently run the same task on several blocks in your design, you can use the
run_block_script command to enable distributed processing and perform the tasks
in parallel. The run_block_script command accepts a Tcl script and applies the
commands in the script to the blocks you specify. For more information about running and
monitoring parallel tasks, see Running Tasks in Parallel and Monitoring Distributed Tasks.
For more information, see the following topics on budgeting:
• Creating Block Timing Abstracts
• Performing Virtual In-Place Optimization
• Performing Incremental Virtual In-Place Optimization
• Applying Manual Budget Constraints
• Constraining Layers, Delays, and Partial Routes for Timing Estimation
• Updating Budget Information
• Writing Out Budget Information
2. Merge any changes that were made to the abstract view into the full design view with
the merge_abstract command.
icc2_shell> merge_abstract
If you placed the pins on your block by using an abstract representation, you must use
the merge_abstract command to copy the pin information into the full design view.
3. Source the constraints for the block.
icc2_shell> source split/ORCA/top.tcl
Note that this step applies internal constraints for the block and is run only one time.
You must apply either manually generated constraints or constraints generated by the
split_constraints command before applying timing budgets. If the constraints were
generated by using the split_constraints command, the top.tcl constraints file is
stored in the split/block_name directory.
4. Insert feedthrough buffers with the add_feedthrough_buffers command.
icc2_shell> add_feedthrough_buffers
5. Create the block timing abstract with the create_abstract command and include the
-estimate_timing option.
icc2_shell> create_abstract -estimate_timing
Note:
If your design contains multiple levels of physical hierarchy, the
create_abstract command converts only blocks at the lowest level of
hierarchy into abstract views; intermediate levels of hierarchy are kept as
design views.
6. Save the changes to the design.
icc2_shell> save_lib
Create separate abstracts for the black box blocks in your design by using the following
steps:
1. Open the design representation for the block with the open_block command.
open_block lib:cpu.design
2. Define the blocks that do not use black boxes and create a list of block references.
set non_bb_blocks $DP_BLOCK_REFS
foreach bb $DP_BB_BLOCK_REFS {
set idx [lsearch -exact $non_bb_blocks $bb]
5. Create abstracts for all non black boxes at the lowest hierarchy levels.
create_abstract -estimate_timing -blocks [list $non_bb_for_abs]
You can use the report_abstracts command to report information about the abstract
representations, including leaf cell count, compression percentage, and available modes
and corners as shown in the following example.
icc2_shell> report_abstracts
****************************************
Report : report_abstracts
Design : ORCA
****************************************
######## Block Instances ########
I_ORCA_TOP/I_BLENDER_2: ref=BLENDER_6:BLENDER_6/dp.abstract,
level=1, design_view_only=false, ok_to_abstract=true
...
--------------------
Total 7 instances of 7 abstract view designs found in current design.
command. Repeat this process until you get the required results. For more information
about unified topology constraints, see Topology Interconnect Planning. Defining unified
topology constraints helps you in routing top-level signals in a complex SoC design
where there are space constraints. If unified topology constraints are not defined, the tool
uses the normal buffering technique to estimate the delay. To determine whether unified
topology constraints have been used by the estimate_timing command, query the
estimated_analysis attribute of a pin as follows:
icc2_shell> get_attribute -name estimated_analysis \
-objects [get_pins PIN2]
To perform virtual in-place optimization on the top-level design and interface logic,
1. Open the top-level design.
icc2_shell> open_block orca:ORCA
The constraint mapping file specifies a list of blocks and their associated constraint files
as follows:
icc2_shell> sh cat split/mapfile
BLENDER_0 CLKNET BLENDER_0/clocknets.tcl
BLENDER_0 SDC BLENDER_0/top.tcl
BLENDER_1 CLKNET BLENDER_1/clocknets.tcl
BLENDER_1 SDC BLENDER_1/top.tcl
BLENDER_2 BTM BLENDER_2/blender.btm
...
ORCA CLKNET ORCA/clocknets.tcl
ORCA SDC ORCA/top.tcl
You can create the constraint mapping file in a text editor or by running the
split_constraints command. See Split Constraints Output Files for more
information about the constraint files generated by the split_constraints command.
3. Source the top-level constraints created by the split_constraints command.
icc2_shell> source ./split/ORCA/top.tcl
The top-level constraints, such as clock definitions and exceptions, are necessary
to constrain the virtual in-place optimization. Note that the top-level constraints were
previously saved to the split/design_name/top.tcl file by the split_constraints
command. If you are using the full netlist flow, source the full-chip SDC file instead of
the top-level SDC file.
4. Run virtual in-place optimization to optimize the top-level and interface logic.
icc2_shell> estimate_timing
In the following example, the estimate_timing command takes into account the delay
in all the buffers for the topology interconnect planning-defined net, N1.
In the following example, the timing path information for multiple fanout nets is shown.
The estimate_timing command should be run before the budgeting step, as the
timing annotations in these new scenarios are used for budgeting. For a multicorner-
multimode design, budgets are generated for all corners, modes, and scenarios (both
corner A and B in the previous example).
To run the virtual in-place optimization task more efficiently on large designs, you can
use the -host_options option_name option to enable distributed processing. To
achieve good quality-of-results, the timing constraints must be reasonable.
After running the estimate_timing and report_timing commands, the timing report
now contains timing information for the new corner named estimated_corner.
The paths reported for estimated_corner are annotated with additional information that
indicate how the tool calculated the timing values:
• "E" or “e” indicate that the timing value is generated based on the
estimate_timing command.
• "A" indicates that the timing value is generated based on the create_abstract
-estimate_timing command.
• "a" indicates that the timing value is generated based on static timing analysis from
the create_abstract -estimate_timing command.
• "S" indicates that the timing value originates from an SPEF or SDF file.
The “Delta Incr” column shows the difference in delay for each output on the path
between the current corner and the estimated_corner corner. The “Analysis” column
reports any changes made to the net during estimated timing optimization. The
following examples are possible changes made by the estimate_timing command.
• Size: None no changes were made
• Size: BUF1 The buffer was resized; the new buffer is BUF1
• Buff: Short net The net is too short and buffering cannot improve timing
• Buff: 3 BUF1 added Three BUf1 cells were added to the net
Scenario: s1.mode::estimated_corner
Path Group: CLK
Path Type: max
I_DATA_PATH/I_0_/CP (senrq1)
0.00 0.00 r 0.00
I_DATA_PATH/I_0_/Q (senrq1)
0.36 0.36 f 0.02 Size: None
I_ALU/U56/Z (bufbd4) 0.14 e 0.50 f -0.01 Size: bufbd7
I_ALU/U34/ZN (inv0d4) 0.05 e 0.56 r -0.00 Size: invbdf
I_ALU/U36/ZN (invbd2) 0.06 e 0.62 f -0.03 Size: invbda
6. (Optional) Override the estimated delay on a specific timing arc with the
set_annotated_delay command. Use this feature to fine-tune the timing values from
virtual in-place optimization.
icc2_shell> set_annotated_delay -from b3/I -to b3/Z 4.321 -cell \
-corners estimated_corner
For delay values annotated with the set_annotated_delay command, the tool labels
the values for the estimated_corner by replacing the “e” annotation with an asterisk
(*). The following example shows the original estimated timing value in the timing
report for the b3 inverter and the result after running the set_annotated_delay and
report_timing commands.
# before
b3/I (BUFFHVTD0) 0.0000 e 0.1584 r 0.0000 Buff: Short net
b3/Z (BUFFHVTD0) 0.0327 e 0.1911 r ~ -0.0064 Size: CKBXHVTD3
b4/I (BUFFHVTD0) 0.0000 e 0.1911 r 0.0000 Buff: Short net
# after
b3/I (BUFFHVTD0) 0.0000 e 0.1584 r 0.0000 Buff: Short net
b3/Z (BUFFHVTD0) 4.3210 * 4.4794 r ~ 4.2819 Size: CKBXHVTD3
b4/I (BUFFHVTD0) 0.0000 4.4794 r 0.0000 Buff: Short net
8. (Optional) Rerun timing estimation with the estimate_timing command and report the
updated timing with the report_timing command
If the design contains user-specified delays set with the set_annotated_delay
command, the estimate_timing command uses them and the report_timing
command reports the affected delay values with an asterisk (*) as shown in the
previous step.
9. (Optional) Remove user-annotated delays with the remove_annotated_delay
command.
icc2_shell> remove_annotated_delay -from b3/I -to b3/Z \
-corners estimated_corner
2. Run virtual in-place optimization on the entire design with the estimate_timing
command.
icc2_shell> estimate_timing
...
Virtually optimized 903 out of 13637 cells
Virtually buffered 903 cell outputs
...
5. (Optional) If the design contains abstracts, re-create the block-level abstracts for the
modified design with the create_abstract command.
icc2_shell> create_abstract -estimate_timing -force_recreate \
-blocks U1
Note the difference in the number optimized cells between the full-chip virtual in-place
optimization run and the incremental run.
After running the estimate_timing command, determine which cells and nets were
affected by these maximum settings by querying the is_et_delay_clipped attribute on
the pins and ports of the design. The attribute is true for any pins where the estimated
delay for the net or cell was replaced by the application option value. The following
example returns the pins of the design where the is_et_delay_clipped attribute is true.
icc2_shell> get_pins -of_objects [get_cells *] \
-filter is_et_delay_clipped==true
{U0/Z U1/Z U2/Z U3/Z U4/Z ...}
The budget report contains a comprehensive summary of timing budgets for each block
specified by the set_budget_options -add_blocks command. The HTML-format
report contains a list of timing path segments and summary sections for block timing,
clock timing, timing to block boundary pins, and path segments. Figure 153 shows
the first few lines of the HTML-format budget report generated by the report_budget
command.
To further investigate timing budgets for individual paths, you can use the -through
pin_name and -warning_pins options with the report_budget command. The
report_budget -through pin_name command reports the budget of the worst-slack
path through the specified budget pin and shows the proportion of the delay consumed
by each segment.
The following example reports the worst-slack path through the I_ORCA_TOP/
I_BLENDER_1/result[16] pin.
icc2_shell> report_budget -through I_ORCA_TOP/I_BLENDER_1/result[16]
Information: Budget for this design will be based
on estimated_corner delays. (ABS-240)
****************************************
Report : report_budget -through I_ORCA_TOP/I_BLENDER_1/result[16]
Module : ORCA
Mode : s1.mode
****************************************
Path: (S= 6.387 / D= 1.413( 0.54) / B= 7.800)
SYS_CLK.1_r->SYS_CLK.top_r
From startpoint inside of block
Segment (S= 2.747 / D= 0.317( 0.00) / B= 3.064) 39%
Through output pin I_ORCA_TOP/I_BLENDER_1/result[16]
Segment (S= 3.640 / D= 1.096( 0.54) / B= 4.736) 61%
To endpoint outside of block
impossible constraints, pins with missing budget constraints, and pins with no timing
paths. The following example uses the -warning_pins option to create a report and
saves the report to the warning_pins.txt file in the local directory.
icc2_shell> report_budget -warning_pins > warning_pins.txt
icc2_shell> sh head warning_pins.txt
****************************************
Report : Budgeted pins with no timing paths
Module : cpu
Mode : func
****************************************
u0_0/ahbi[31]
u0_0/ahbi[30]
u0_0/ahbi[29]
...
To view the reason why there is no timing path for a pin, use the -verbose option.
Ensure to use this option with the -warning_pins option in the report_budget
command.
Here is an example report built using the -warning_pins -verbose options that
includes reasons as to why some of the pins do not have timing paths. For information
about other possible reasons that cause missing timing paths, see the report_budget
man page.
false_path Indicates that all paths through the specific block pin are
covered by set_false_path exceptions
In the report, the Pin column indicates the pin that is causing the lack of timing path
through a specific block pin. You can use the information in this column to identify the
next steps to fix the issue. For example,
Note:
If a pin is bidirectional, it is expected to have at least one input and one
output delay. If one of them is missing and there are no timing paths going
through the pin in the corresponding direction, then that pin appears in the
report.
icc2_shell> report_budget -warning_pins -verbose
****************************************
Report : Pins with no timing paths
Design : TOP_DG
Mode : m2
Version: T-2022.03-BETA
Date : Thu Jan 13 13:26:14 2022
****************************************
Block Pin Dir. Reason
Reason Pin
----------------------------------------------------------------------
----------
M/clk1_in (input) clock_pin
NA
M/clk2_in (input) clock_pin
NA
B/clk1_in (input) clock_pin
NA
B/clk2_in (input) clock_pin
NA
M/A/Pin_0 (input) false_path
NA
M/A/Pout_0 (output) false_path
NA
M/A/clk1_in (input) clock_pin
NA
M/B/clk1_in (input) clock_pin
NA
M/B/clk2_in (input) clock_pin
NA
...
To generate a report of the feedthroughs that are in the design, use the
-feedthroughs option with the report_budget command. The report includes
information about the feedthrough pins and their location as well as the timing and
budget for this segment.
The FROM_FROZEN and TO_FROZEN columns in the feedthrough report indicate whether
the budget for the feedthrough is automatically generated by the tool or is defined by
a user constraint, set_pin_budget_constraints -frozen <pin>. The IS_FIXED
column indicates whether the budget for a segment is calculated by the tool or is
marked fixed by the user.
In the following example, the feedthrough report is generated for the specified pins.
icc2_shell> report_budget -feedthroughs -pins B/Pin_0
****************************************
Report : report_budget -feedthroughs
Design : TOP_DG
Version: T-2022.03-BETA
Date : Thu Jan 13 19:04:26 2022
****************************************
FROM_PIN FROM_PIN_LAYER FROM_PIN_LOCATION LAUNCH_CLOCK FROM_FROZEN
TO_PIN TO_PIN_LAYER TO_PIN_LOCATION CAPTURE_CLOCK TO_FROZEN
IS_FIXED MANHATTAN_DISTANCE ESTIMATION_RULE BUDGET DELAY SLACK
INTENT BUDGET_MINUS_INTENT
To capture the feedthrough report information in a CSV format, use the -csv option
with the report_budget -feedthroughs command. Ensure that you add the .csv
extension in the command as shown in the following example, where the feedthrough
information is saved in the feedthrough_list.csv file.
icc2_shell> report_budget -feedthroughs -csv feedthrough_list.csv
The write_budgets command writes out the constraints for the block references specified
by the set_budget_options -add_blocks command. The write_budgets command
creates a directory for each block reference name, writes a constraint file for each corner
and mode, and writes a top.tcl file that sources the other constraint files for the block. The
corner constraint files are named corner_cornername.tcl and the mode constraint files are
named mode_modename.tcl.
Budgets apply only to the boundary paths of the blocks, not to the internal segments.
Whenever you generate a new budget with the write_budgets command, you must
source the top.tcl budget file in the block. You can apply budget files multiple times,
whenever the budgets are changed or updated. When you source a new budget file, the
tool overwrites any existing boundary constraints from any previously sourced budget file.
To write I/O constraints for all blocks, use the -all_blocks option of the write_budgets
command. To write constraints for only a specified set of blocks, use the -blocks
{block_list} option. To write the output constraint files to a specific directory, use the
-output directory_name option. To overwrite an existing output directory, use the
-force option.
Figure 154 shows the contents of the budgets directory created by the write_budgets
command.
During block development later in the flow, apply the constraints written by the
write_budgets command by sourcing the top.tcl file in the budgets directory.
Note that the constraints generated by the write_budgets command should be sourced
after you source the constraints created by the split_constraints command. For
example, to apply constraints to the ORCA block, open the block and use the following
steps.
1. Read in the constraint mapping file for the SDC and UPF files.
icc2_shell> sh cat split/mapfile
BLENDER_0 SDC BLENDER_0/top.tcl
BLENDER_0 UPF BLENDER_0/top.upf
...
icc2_shell> set_constraint_mapping_file split/mapfile
1
2. (Optional) Remove specific constraint types or specific blocks from the constraint
mapping file with the update_constraint_mapping_file command.
icc2_shell> update_constraint_mapping_file -remove_blocks {BLENDER_6}
3. Source the constraints for the block generated by the split_constraints command.
icc2_shell> source split/BLENDER_0/top.tcl
Budget Shells
A budget shell is a macro-like representation of the I/O timing and physical interface of a
block. You can use budget shells for top-level design exploration before lower-level blocks
are implemented
In a design hierarchy, a budget shell can replace a lower-level block. The boundary ports
of a budget shell are budgeted: paths that originally went from the parent hierarchy into
a child hierarchy are replaced with new budgeted paths from the parent hierarchy to the
ports of the budget shell. The timing of the new path is adjusted to match the budget
constraints for the replaced block.
To create a budget shell, use the write_budgets command with the -shell_subblocks
option. The command saves scripts in the directory specified with the -output option.
Note:
For final chip production to generate a tapeout database, do not use the budget
shell flow. Use the traditional hierarchical flow based on implemented blocks,
starting from the RTL.
For example, consider a top-level design (Top) that contains block B, which in turn
contains block C. As shown in Figure 155, a traditional bottom-up design flow requires
that the synthesis and implementation steps for block C be completed to serve as input for
block B, which must itself be completed to provide input to the top level.
Alternatively, you can use budget shells to represent blocks to allow top-level design
exploration until the implemented versions of block B and block C become available, as
shown in Figure 156. This method can provide early information about the quality of the
top-level floorplan and improve overall turnaround time.
By default, the budget shell contains information about PG pins, related power or ground
pins, and other multivoltage Liberty attributes. Including this information improves the top-
level implementation for multivoltage designs. You can disable saving the multivoltage
information by setting the mv.hierarchical.include_pg_in_budget_shell application
option to false.
• pg_pin group
• related_power_pin
• related_ground_pin
When you use budget shells for a multivoltage design, you must reload the UPF files for
the budget shells, as shown in Figure 157.
For a fixed percentage budget constraints flow (40 per cent in this example), add the
following command after the compute_budget_constraints command:
set_pin_budget_constraints -internal_percent 40 -all