White Paper

IC Compiler II Multi-Level Physical

Hierarchy Floorplanning
January 2016

Author Executive Summary

Steve Kister, Large, complex SoC designs require hierarchical layout methodologies that span multiple levels of
Technical Marketing physical hierarchy. Many EDA tools only handle two levels of physical hierarchy at a given time resulting
Manager, Synopsys in longer layout schedules that are risky at best. Synopsys’ IC Compiler II provides automation for
designs with multiple levels of hierarchy that minimizes time to results, provides best QoR, and maximizes
productivity of physical design teams.

This paper presents the need for multi-level physical hierarchy floorplanning, the challenges inherent with
this style when using tools limited to two levels of hierarchy, and discusses how IC Compiler II addresses
these challenges.

Introduction
Market demands affecting chip designs intensify continuously. High definition graphics, streaming HD
video, computer vision-based image processing, and real-time navigation are a small subset of the
high performance demands requiring teams to package more compute and processing power into their
designs. As shown in Figure 1, the ever shrinking transistor and wiring sizes available at new process
nodes enables them to pack more and more functionality within a chip.

12000
Used gates (K) per mm2

10000

8000

6000

4000

2000

0
90 65 45/40 28 20 16/14 10
Process Node (nm)
Source: International Business Strategies, Inc. (IBS), Process Technology and Ecosystems, May 2015

Figure 1. Gates Used per Square Millimeter at Various Process Nodes

Design teams are rallying to the challenge. The operating speeds and capabilities of modern SoC designs
are striking. They are incredibly powerful systems on chips as shown in Figure 2.
 Graphics Processor Networking Switch
256-core GPU 880 GB to 3.2 TB per second
8 cores (4x Cortex A57 + 4x Cortex A53) Flexible configurations, including:
60 fps 4K video (H.265, H.264, VP9) ∙ 32 ports of 100G
1.3 Gigapixels of camera throughput ∙ 64 ports of 40G or 50G

Smart Phone Processor

Tri-Cluster, 10-core CPU
Improved UI and gaming performance
Premium camera
4Kx2K video playback

Figure 2. Recent SoC Releases

The task of physically implementing these designs is daunting. Teams are dealing with 100s of millions of
gates, or 10s of millions of placeable instances. To manage this complexity, physical design teams use
hierarchical implementation methodologies to divide a single chip into sub-chips. Often the sub-chips are so
big and complex, they too must be divided into even smaller sub-chips as shown in Figure 3. Using three, four,
or even five levels of physical hierarchy to implement a design is becoming more of the norm.

Logic hierarchy assigned to three Potential floorplan for multi-levels of

levels of physical hierarchy sub-chips within the full chip

A
B E

B C D E L
G

L
F G H I J K L M L

C
N O P Q R S R S

Figure 3. Physical Floorplan Divided Into Three Levels of Sub-chips

Many design teams face the critical limitations of traditional place and route tools. Several of the physical
planning, place, and route tools are limited to two levels of physical hierarchy — top and block. Because of
this, designers are forced to use and manage a recursive, two-level-at-a-time physical implementation flow.
The added flow complexity and data management impacts the productivity of design teams and delays
design schedules.

Truly supporting multi-level physical hierarchal planning and layout is an opportunity for planning, place, and
route tools to improve designer productivity, efficiency, and minimize design schedules.

Pitfalls of Recursive, Two-Level-At-A-Time Hierarchical Methodologies

Physical planning, place, and route tools support hierarchical design, but most are limited to two levels of
hierarchy — the top and the block. Teams are forced to set block shapes, block pin placements, and budget
block timing constraints one level at a time. Planning of lower levels cannot be completed while at the same
time considering the context of the full chip design. Planning of lower levels is completed in the context of
constraints defined on their parent as shown in Figure 4.

2
 Top level full chip floorplan Sub-chip floorplans

B E B C E

L
G

Figure 4. Multi-Level Physical Floorplan Divided Into Several Two Level (Top and Block) Floorplans

The shapes, pin placements, and budgets set at a given parent level become hard constraints for the
child level of the design. Any changes to lower levels that impact parent levels — like increasing a sub-chip
size — can ripple back to the top level. To address such a change, teams negotiate to decide how to make
the change and minimize re-work on other levels of the design. The negotiations take time and are difficult to
account for when defining schedules. Often, this is a root cause of schedule slip.

Design teams incur significant data management and tracking tasks. For example, to manage complexity
and minimize memory use, teams will convert the children of a given level into black boxes — even if they
have access to the netlist data. Area requirements are boiled down to an educated engineering estimate. Any
constraints on shapes or sizes to accommodate hard macros within the child block must be accounted for
manually. Teams take ownership of creating black box models and the subsequent tasks of replacing black
box models with real netlist data at later points in the flow.

There is the potential for designers working at the child level to create and compound problems unknowingly.
Consider two designers each working on a sub-chip that is connected through logic at a parent level. Each
designer may choose to move content within their sub-chip to improve routability and timing. However, when
they put these into the context of the full chip, the designers may have created timing paths that cannot be
closed easily as shown in Figure 5.

Changes to sub-chip floorplans

B B E E

L L
G
G
L

Sub-chip floorplans in full chip. Time of flight from G to L increased.

B E

L
G

Figure 5. Example of Sub-chip Changes That Can Make Top Level Closure More Difficult

3
Another level of complexity is introduced when teams use multiply instantiated blocks (MIB). A MIB is a physical
block that is used multiple times in a given design. MIBs save time and engineering effort as one designer
can own and implement the block. A MIB functions in multiple environments that must be considered during
implementation of the MIB. When MIBs are used within lower level sub-chips, design teams need to consider
each unique environment when defining the shape, size, pin placements, and timing constraints needed to drive
implementation of the MIB. Adding to the complexity of multi-level physical hierarchy planning, MIBs may be
instantiated at any hierarchical level. Again, this is likely to result in significant negotiations between designers to
ensure that each MIB instance performs as needed within multiple sub-chips.

Desired Characteristics of a Multi-Level Physical Hierarchy

Methodology
These pitfalls and others are the source of wasted time and lost QoR in our designs. Now let’s explore what
would be a better way of dealing with the hierarchical complexities of today’s designs. Planning can be done
at all levels, concurrently, while considering the impact of choices in the full chip context. The tool should
shape sub-chips, place macros and standard cells, route power, place pins, and generate timing budgets at
all levels automatically. Design teams should not be burdened with providing assumptions, pushing them to
lower levels, and then facing an iterative negotiation process to refine the design.

With respect to TAT, automated planning runs need to finish overnight. Design teams can let the computer run
overnight and then spend their day time analyzing results and setting up subsequent runs to further improve
the plan. This type of work cycle maximizes team productivity.

The planning flow should take advantage of netlist data for as much of the design as possible. Understanding
area requirements, macro content, interface connectivity, and interface logic path structures leads to better
decision making than using a limited set of assumptions. That said, black boxes must be supported to
account for new design elements where netlist data is not available. Using all data that is available to measure
the quality of a floorplan choice maximizes efficiency.

A single planning flow should support any design style. Design style diversity spans channeled or abutted,
multiple voltage areas, and designs containing MIBs, just to name a few. Teams should be able to define
requirements, such as target utilizations of sub-chips and voltage areas or let the tools determine these based
on target die size requirements. For abutted styles, feedthrough creation must be supported. Teams can
control desired feedthrough paths for specific nets and busses or allow these to be determined algorithmically.

MIBs require special handling. The engines need to consider the context of each instance at each level
and intelligently determine characteristics of the reference that work best for all instance contexts. This
includes shapes, pin placements, and budgeted timing constraints. For abutted designs, feedthroughs are
required. Feedthroughs for MIBs present a special case. The same nets are not likely to cross all instances,
let alone in the same place as shown in Figure 6. Feedthrough creation for MIBs needs to create generic
feedthroughs that can be assigned to different nets for different instances. Similarly, it is likely that the number
of feedthroughs per instance will vary yet, by definition, the MIB reference must have a fixed number of
feedthroughs. Some instances will not need to use all feedthroughs, and unused feedthroughs must be tied
off to power or ground on an instance specific basis.

Counts of feedthroughs crossing instances of MIB “L”

E Simplistic way to handle is to create 18,595

feedthroughs across the MIB L reference.
L 8763 9832 are unused and tied off in the upper
instance of L. 8763 are unused and tied off
in the lower instance of L. This uses a huge
9832 amount of routing resource.
L
Ideally, can create only 9832 across the
reference. All are used in the lower instance.
1069 are unused and tied off in the
upper instance.

Figure 6. Feedthroughs Crossing MIBs

4
As designs mature and logic design teams provide new netlist drops and timing constraints, the flow should
get easier as new data replaces old data while maintaining as much of the previous floorplan as possible.

Finally, but importantly, teams need the ability to interactively explore, analyze, and modify results at any
physical hierarchy level while seeing the impact within the context of the full chip. These capabilities are key
to team productivity. These capabilities enable teams to quickly validate results and maximize the QoR of the
plan. Additionally, teams can identify issues, test fixes, and provide valuable feedback to logic designers when
there is still time to consider and create architectural changes.

IC Compiler II Provides Multi-Level Physical Hierarchy Planning Today

IC Compiler II’s new data model has physical hierarchy built in today. Many tools continue to use flat
databases where physical hierarchy was added as a quick fix. Native physical hierarchy provides significant
advantages for multi-level physical hierarchy planning and implementation. All engines — shaping, placement,
routing, and timing to name a few — quickly access the specific data relative to physical hierarchy that they
need to perform their function.

For example, consider shaping. In Figure 7, the shaper needs to know the target area for each sub-chip,
aspect ratio constraints dictated by hard macro children, and interconnect that exists at sibling-to-sibling,
parent-to-child, and child-to parent interfaces. If the design is a multi-voltage design, the shaper needs target
areas for voltage areas. These needs add more constraints for the shaper to deal with in the design. For
multi-level physical hierarchy planning, shaping constraints that exist for lower level sub-chips translate up the
hierarchy in the form of shaping constraints on parent sub-chips. The shaper does not need to know about
the full netlist content that exists within each sub-chip or block. IC Compiler II’s database is constructed with
this idea in mind to provide engines with the specific data required for their particular function. For multi-
voltage designs, IC Compiler II reads UPF and stores appropriate data within sub-chip levels. The engines pull
data from the database to calculate targets based on natural design utilization or pull user defined attributes
specifying targets.

Top
op level
e e Top and Second level Top, Second, and Leaf level

Sub-chip outlines

Voltage area outlines

Figure 7. IC Compiler II Multi-Level Shaping Results

The new data model is built to support distributed processing architectures. IC Compiler II engines split their
jobs, or parts of their jobs, into multiple processes. As shown in Figure 8, cell placement is a good example of
this synergy.

After shaping, the placement engine sees a global view of data flow interconnect paths at physical hierarchy
boundaries and connectivity to macro cells. With this information, macros are placed for each sub-chip at
each level. Understanding relative location requirements of interconnect paths at boundaries ensures there
are resources available at the adjacent sub-chip edges to accommodate interconnect paths; the placer
anticipates the needs of hierarchical pin placement and places macros where interconnect paths do not
require significant buffering to drive signals across macros.

Using sub-chip shapes, locations, and the global macro placements, the placer engine models the external
environment seen at the boundaries of child and parent sub-chips. Using the model, the placer creates cell
placement jobs for each sub-chip at each level of hierarchy. Each job creates placement for standard cells of
each sub-chip. By splitting this into multiple processes for sub-chips, IC Compiler II minimizes turn-time while
maximizing the use of compute resources.

5
 Top
p level Top and 2nd level Top, 2nd, 3rd level Top, 2nd, 3rd and leaf

Sub-chip outlines

Figure 8. IC Compiler II Multi-Level Global Macro Placement Results

For power routing, IC Compiler II provides an innovative object based methodology. Patterns describing
construction rules such as widths, layers, and pitches required to form rings and meshes are applied to areas
based on floorplan objects, such as voltage areas and groups of macros. Strategies associate patterns or
multiple patterns with areas. A complete set of strategies can be set up for the full-chip. Given these strategy
definitions, IC Compiler II characterizes the power plan and automatically generates definitions of strategies
for sub-chips at all levels and a complete power plan is generated in a distributed manner. It is worthwhile to
note that sub-chip design teams can use these strategies as needed. Because the characterized strategies
are written in terms of objects at each sub-chip level, power plans can be easily re-created to accommodate
floorplan changes at any level.

With shapes formed, macros placed, and power routed, IC Compiler II’s pin placement engine pulls interface
data at all levels and invokes a specialized global router to determine where to place hierarchical pins. The
specialized global router is set up to recognize physical boundaries at all levels to ensure efficient use of
resource at hierarchical pin interfaces. Pins are aligned across multiple levels when possible. The specialized
global router is MIB aware - like all IC Compiler II engines to guarantee it intersects edges of MIBs identically.
To place pins for MIBs, the pin placement algorithm determines the best pin placement that works for
all instances, ensuring that the pin placement on each instance is identical. Additionally, pin placement
creates feedthroughs for all sub-chips, including MIBs, throughout the hierarchy as shown in Figure 9. The
global router engine plans feedthroughs across MIBs and determines feedthrough re-use and tie-offs of
unused feedthroughs.

F
A F
B F
CF D
A B C D
F F F F
A B C D
F F F F

A B C D
F F F F

F
A F
B F
CF D
A B C D
F F F F

A B C D
F F F F

A B C D

Array of MIBs Pins aligned Feedthroughs

across channels aligned through MIBs

Figure 9. IC Compiler II Pin Assignment and Feedthrough Creation Results

6
Once hierarchical pins are placed, IC Compiler II estimates the optimized timing at hierarchical interfaces
and creates timing budgets for sub-chips. Most EDA tools’ budgeters create timing constraints that are
applied to primary hierarchical input and output pins of sub-chips. The input and output delays of the
budgeted constraints represent timing path segments that exist in the parent of sub-chips. This enables
sub-chip designers to perform placement and optimization of “flat” sub-chips by modeling the external timing
environment seen at their primary input and output pins. However, this does nothing to model the internal
timing environments of sub-chip pins as seen at their parent levels. There are no constraints to represent
timing path segments that exist in the child sub-chips. IC Compiler II’s advanced budgeter creates timing
constraints for 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.

As the design matures and various sub-chips are closed, teams are able to specify sets of sub-chips that can
and cannot be physically modified. This helps when design teams are required to update current netlist data
with new netlist drops. Consider a case where the new netlist data requires an increase in a sub-chip size
to accommodate growth in logic produced by synthesis. IC Compiler II incrementally updates the floorplan
considering the full-chip context and the sets of sub-chips that can and cannot be modified. This minimizes
the amount of wasted design team time required to negotiate changes that ripple through to different levels of
the design hierarchy.

At any point in the planning or implementation flow, design teams can interactively view, analyze, and manually
edit any level of the design in a full-chip context. For example, a team may choose to hand route a timing
critical signal that passes through multiple levels of the hierarchy. In IC Compiler II, they can open the full
design in a layout editing window. Users 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. When completed, routes
are pushed into children and hierarchical pins are automatically added as shown in Figure 10.

Macro at
child level
Start of
bus routing

Macro at
parent level

Routing
complete
and pushed
down

Figure 10. Interactive Multi-Level Route Editing

7
Summary
Today’s designs are huge and extremely complex. The continuing advances in process technology enable
design teams to pack more and more functionality into designs, continually increasing the complexity of the
designs. Today’s designs require multi-level physical hierarchy planning and implementation methodologies.

EDA tools that are limited to two-levels of physical hierarchy make the multi-level hierarchical planning task
difficult to implement, often causing teams to compromise design area, functionality, and QoR in order to
adhere to tight tape-out schedules.

IC Compiler II is built on a new data model that provides the infrastructure required to automate multi-level
physical hierarchy floorplanning. Multi-level physical hierarchy automation ensures the best QoR and time to
results. IC Compiler II’s planning engines intelligently consider all the data available at each stage of the flow
and then utilize the specific data needed to ensure quality results for each task. This enables design teams to
squeeze the most QoR out of their designs and meet their demanding tape-out schedules.

Synopsys, Inc. • 690 East Middlefield Road • Mountain View, CA 94043 • www.synopsys.com
©2016 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks is
available at http://www.synopsys.com/copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners.
01/26/16.CE_CS6876_ICCII_WP.