Power Analysis

in Hierarchical Implementation Flow

with Synopsys Astro Rail

by Vincent GRENET
STMicroelectronics Digital TV division
with contributions from Emmanuel PLUCHART
Synopsys France

Abstract
This paper describes a general design methodology, developed by STMicroelectronics
Digital TV group, for integrating voltage drop analysis in a hierarchical digital
implementation flow, using Synopsys’ Astro-Rail tool. The paper consists of two main
sections. The first part details the portion of the flow that is used to prepare, input the data
and describes the creation of macro models for hard blocks. The second part specifies the
steps that must be taken to fully analyze the data. The paper demonstrates how the usage of
the macro-modeling methodology for soft blocks can improve the performance and reduce
the turnaround time and hardware requirements during the hierarchical analysis flow.

STMicroelectronics Digital TV group has already applied the flow described herein to
a number of successfully taped-out designs. In some cases, Astro-Rail has helped to highlight
certain failures due to unconnected power rails or missing vias.
 Table of Contents

1.0 Astro-Rail integration context.........................................................................................3

1.1. Design flow requirements ..................................................................................................3
1.2. Design vehicle presentation ...............................................................................................4
2.0 Astro-Rail flow integration..............................................................................................5
2.1. Physical implementation flow overview ............................................................................5
2.2. Macro-modeling concepts ..................................................................................................6
2.3. Hard block(s) power analysis data preparation ..................................................................6
2.4. Soft block(s) level power analysis and modeling...............................................................9
2.5. Top level power analysis..................................................................................................11
3.0 Conclusions .....................................................................................................................12
4.0 Design and design flow future .......................................................................................12

Table of Figures
Fig 1: Design vehicle floorplan ...............................................................................................4
Fig 2: Physical implementation flow chart ............................................................................5
Fig 3: mkLibGen usage ...........................................................................................................7
Fig 4: Power analysis flow chart.............................................................................................9

SNUG Europe 2005 2 Power analysis

in
hierarchical implementation flow
1.0 Astro-Rail integration context
1.1. Design flow requirements
For a long time design teams have been looking for a complete set of signoff tools to
ensure their design success story on silicon. Today, static timing analysis, formal proof,
DRC, LVS, and other tools are used and continually refined to reflect the growth of
technology and design complexity. Regarding LVS, huge numbers of design failures have
shown that a pure connectivity check is not enough to fully validate the tape-out database and
that power issues have to be checked as well. As we can’t consider carrying hundreds of mA
currents through a single via or using a minimum technology width metal line, power
analysis tools have been added to the signoff toolset.

Initially, power analysis using mainly voltage drop and electromigration analysis tools
was included to fulfill LVS checks, however as power constraints become more and more
critical in our designs, it has become apparent that we need new approaches for tackling the
power issues. Today main power analysis tools applications are power grid validation,
relative power consumption estimation, power pads count and placement optimization.
There are some EDA tools available on the market to address the above needs, dealing
with some major issues, such as capacity, runtime, and data preparation complexity, which
are key for this type of tool/methodology. Some of these tools are more accuracy-driven, with
important hardware needs, but they generally come too late in the flow as the tape-out
database has to be used. In other tools, modeling is quite complex, but they solve
performance issues with no certified quality of results.
STMicroelectronics’ Digital TV division CAD team has deployed Synopsys’ power-
analysis solution based mainly on the Astro-Rail tool, taking into account the following
characteristics of the main platform:
• .lef/.def as worldwide open standard or based on Milkyway database
• Support for various sets of modeling from black box through grey box to accurate
white box model
• Support for various methodologies from full top down to a full flat implementation
style
• Scalable accuracy from cell-based to transistor-level simulation to allow everything
from prototyping to signoff analysis

Since our current Digital TV mainstream flow is JupiterXT/Astro-based, we can fully

benefit from the Milkyway database using specific plugged tools, such as StarRCXT,
Hercules, Enterprise, and Astro-Rail, which help to improve physical implementation
predictability and convergence. As we are working on big SoCs combining various
technologies, it is fundamental for us to use IPs from providers. Tools capacity, and inter-
operability with worldwide standards is essential. In order to use Astro-Rail in this type of
design, three main critical points have been addressed:
• Capacity and runtime, by performing a full hierarchical implementation flow
• Full custom and external IPs as core supported, by building an automatic modeling
flow
• Deployment to design community, by a strong power flow integration in the physical
implementation solution

SNUG Europe 2005 3 Power analysis

in
hierarchical implementation flow
 1.2. Design vehicle presentation
For the past year TV division design teams have exercised Astro-Rail on more than four
production designs, using full hierarchical methodology in 0.18µm, 0.13µm and 90nm
technologies. Design sizes have ranged from 10 million to 65 million of transistors. The
characteristics of the latest successfully taped out 90nm design were 700 IOs, 2.5 million
instances, 250 memory cuts, and 8 analog IPs. Power analysis has been performed using
Astro-Rail in a hierarchical way.
For confidentiality reasons, the following numbers and figures refer to a 0.18µm mixed
design:
• 10 million transistors
• ~500K instances
• 34 memory cuts
• 3 analog IPs (synthesizer, pll, ad/da)
• ~300 IOs
• 4 digital partitions have been build for this design
• ~60mm2
• digital core is single voltage

Digital soft blocks

Analog IPs
Fig 1: Design
vehicle floorplan

SNUG Europe 2005 4 Power analysis

in
hierarchical implementation flow
 2.0 Astro-Rail flow integration
2.1. Physical implementation flow overview
The following diagram describes the hierarchical design flow used in a big SoC
implementation in Digital TV division, as well as the power flow integration inside.
Core, IOs, std cells, analog IPs
World wide standard format

Top level integration database Per soft block implementation database

mkJupiterXT mkAstro
reference libraries

(JupiterXT + Astro+ StarRCXT + Astrorail) (Astro + StarRCXT + Hercules + Astrorail)

.gds, .lef, .lib

Padring assembly Database import

Top down
Soft blocks definition Placement &IPO

Floorplan generation Clocktree synthesis

Power grid creation IPO

Clocktree synthesis Routing

mkLibGen

Timing Budgeting Design Closure (SI fixing & IPO)

Top down handoff Handoff (world wide standard)

Bottom up
Routing Power analysis

Design Closure (SI fixing & IPO) Block modeling

Bottom up integration Signoff

Reference libraries + Working library

(milkyway based)
MILKYWAY database

mkLibGen

Top down

Full chip signoff

(StarRCXT, Primetime, …)

External sub contractor

(Astro or third party tools)

Place & Route

Power flow
Handoff (world wide standard) integration

Fig 2: Physical implementation flow chart

SNUG Europe 2005 5 Power analysis

in
hierarchical implementation flow
 2.2. Macro-modeling concepts

Today’s complex designs must employ hierarchy in order to better meet both time-to-
market and design constraint concerns. The use of hierarchy in the design, when combined
with the hierarchical nature of an analysis tool, such as Astro-Rail, can improve flows to
reduce turn-around time and hardware requirements during the analysis stages.

The solution is to enable a macro-modeling flow that provides both the accuracy of a
flattened solution and the capacity of a hierarchical analysis mode.

When the blocks, which will possibly be used and re-used in multiple projects, are stored
in the reference libraries, the macro-models created from these blocks will be stored in the
reference libraries, too. Thus when the top-level library is linked to the reference libraries, the
tool will detect the existing models and utilize that data instead of re-extracting it from the
block details. The reference library thus represents a complete collection of data for the block
in question, which can be ported to any new designs.

In the Astro-Rail tool, both the white-box and the gray-box macro-models are stored in
the .PARA view directory of the database. As such, they do not contain directly viewable
data. This is in contrast with the .CEL (layout view) and .CONN views of soft and hard
macros we will be dealing with on the way to generating the macro-models. These visual
collections of information are utilized in the complete hierarchical analysis of a design, and
represent the most costly method, in terms of memory and runtime, of performing rail
analysis. One of the benefits of the macro-modeling technique is the improved performance.
Another benefit of the macro-modeling methodology is that each single macro only needs to
be processed once, no matter how many times it is placed in the top-level design.

The difference between a gray-box model and a white-box model is in the level of
abstraction. Using a white box macro in analyzing a hierarchical design during the top-level
analysis runs longer and requires more memory usage because you can see the power and
ground nets inside the macro — but no cell placement or signal-net routing information — of
a white-box when displaying top-level analysis results on the voltage drop or electro-
migration maps. A white box macro is not directly viewable, compared with a .CEL or
.CONN view, but it can be seen in the resulting rail analysis output.

2.3. Hard block(s) power analysis data preparation

ST’s large digital TV SoCs always call specific hot cells, such as cores, full custom
analog cells, advanced IOs as USB, etc. Some of these cells are developed by external IP
providers or internal analog teams, which are not aware of the SoC’s physical integration or
do not use the same EDA solution. To clarify all exchanges, worldwide standard formats
need to be used as references for all project libraries. As we are using a full Synopsys
physical implementation platform, all libraries have to be translated to Milkyway database.

A fully integrated and push-button in-house tool, mkLibGen, has been developed, using
Library Compiler, Hercules, and Astro, to perform data preparation. From the worldwide
standards, such as .lef, .gds, and .lib, all Milkyway views are generated as a layout view
(.CEL), an abstract view (.FRAM), timing views (.TIM and .LM), and power views (.CONN
and .PWR if described in .lib). Based on a perl template module, mkLibGen delivers a
SNUG Europe 2005 6 Power analysis
in
hierarchical implementation flow
custom scheme script per library and technology. mklibGen is fully incremental, which
means that the existing Milkyway views are stored and others can be generated, when the
required data are available.

Usage : mkLibGen -name <library name> -lib <library path> [-lef <.lef file>] [-stf_bc <best pvt .lib file>] [-
stf_wc <worst pvt .lib file>] [-gds <.gds file>] -pvt_bc <best case opcond> -pvt_wc <worst case opcond> [-tf
<.tf technology file>] [-mapIn <stream-in mapping file>] [-mapOut <stream-out mapping file>] -tech
<technology name> [-io|core|macro] [-simplify] [-nouniquify] [-suffix <suffix string>] [-power] [-top <top
cell(s)>] [-dbModel] [-pdbModel] [-nbti] [-tileLib <milkyway unit tile library>] [-d] [-h|-help]

- <library name> : Set library name

- <library path> : Set library path
- <.lef file> : Set .lef file path
- <best pvt .lib file> : Set best operating conditions .lib file path
- <worst pvt .lib file> : Set worst operating conditions .lib file path
- <.gds file> : Set .gds file path
- <best case opcond> : Set best operating conditions
- <worst case opcond> : Set worst operating conditions
- <.tf technology file> : Set Astro technology file path
- <stream-in mapping file> : Set Astro stream-in mapping file path
- <stream-out mapping file> : Set Astro stream-out mapping file path
- <technology name> : Set technology name (hcmos8d/hcmos9gp/cmos090gp)
- [-io] : Set iolib generation mode
- [-core] : Set corelib generation mode
- [-macro] : Set macrolib generation mode
- [-simplify] : Set simplified abstract mode
- [-nouniquify] : Set if you want to get a NON uniquified .gds database
- <suffix string> : Set suffix string to perform .gds uniquify process
- [-power] : Set power view generation mode
- <top cell(s)> : Define top cell(s) (explicit or file) to proceed
- [-dbModel] : Set logic model(s) (LM views) generation mode
- [-nbti] : Set NBTI timing view(s) generation
- [-pdbModel] : Set physical db model(s) (PDB views) generation mode
- <milkyway unit tile library> : Set Astro unit tile reference library path
- [-d] : Allow to delete existing views if any
- [-h|-help] : Write this info.

Fig 3: mkLibGen usage

A connectivity view (.CONN) is build from the .gds layout description file using
Hercules and Astro. As all .gds extractors, Hercules needs to find certain labels in the layout
description in order to identify design ports. In our case, especially the power ports have to be
described. Unfortunately, IP layouts do not share strict development guidelines and are, in
most cases, hierarchically build. . They are a collection of small parts, which have been
developed and validated separately, so that for power ports a deep AVSS label can be called
VSS at top level and vice versa. In the same way, some global node or virtual connectivities
syntax can exist. This is a big issue for the layout analysis, as many shorts or opens are found
when the flat extraction is performed.

SNUG Europe 2005 7 Power analysis

in
hierarchical implementation flow
 To guarantee a quality extraction of power geometries prior to run modeling, mkLibGen
performs several .gds clean-up steps:
• Automated top cell(s) detection (scheme scripting):
First, a list of all library cells is build, and then all cells are opened one by one. If per
one or more child cells are found per cell, these calling cells are removed from the
library list. At the end of the process, only top cells remain and are extracted.
• Lower metal attached label removal:
Using Astro auConvertLayerDatatype native function, all deep-pin text labels are
remapped to standard label layer.
• Virtual and global label renaming:
For all remaining pin labels, all virtual connect and global special characters are
removed by selecting and modifying one by one. For example, VSS! or VSS: is moved
to VSS.
• Setting of power port attributes :
Using Astro dbSetCellPortTypes native function, power port attributes are set:
dbSetCellPortTypes "myMemoryLib_CEL" _cellTopName '( ("vdd" "Power") ("gnd" "Ground")) #t
As soon as GDSII data are ready, a Milkyway .CEL view is generated. needed to trigger off
Hercules..

The connectivity (.CONN) views represent the power and ground network of the hard
macro. The method we have chosen to generate these views is based on the Hercules
connectivity engine and the poCreateConnViewByHerc command, called under the hood by
mkLibGen. Astro-Rail automatically generates a Hercules runset, based on the values
provided in the command window. The Hercules run extracts connectivity from the .CEL
view and generates in the specified database a flat view of the power/ground network
material only, called .SMASH view. Subsequently, Astro-Rail automatically uses this
.SMASH view to create the CONN view of the cell in the same library. In the working
directory, a file called ‘runset.ev’ is generated, used by the tool to create the .SMASH view. If
multiple runs are performed, the runset file will be overwritten each time with the new
information. The normal output files from a Hercules run will also be created in the working
directory.

The second portion of the macro-model of a hard macro describes where the current (and
hence the power) is drawn off of the power/ground network. mkLibGen uses the
poGenCurrSource form to create a draw on the power/ground network at the locations of
intersecting metals. The cell in question must already have its .CONN view created. The
current source locations are intersections in the power/ground network for the individual nets.
Hence if a metal1 vdd rail intersects with a metal2 gnd rail, this location will not be used for a
current source inside either net. After the command has finished, the current source file (csf)
will be appended to the .CONN view in the Milkyway library.

Once the Current Source File is attached to the .CONN view, the white-box model of the
hard macro is created, using the poPGExtraction command. It extracts the power and ground
nets and saves the white-box model in the PARA directory.

The Astro-Rail extraction engine supports the Table-Look-Up Plus (TLUPlus) models
from Star-RCXT for resistance and capacitance effects on power and ground nets. This
allows Astro-Rail to accurately handle advanced process rules.

SNUG Europe 2005 8 Power analysis

in
hierarchical implementation flow
 2.4. Soft block(s) level power analysis and modeling

A soft macro is any top-level component that has to be placed and routed. It can contain
standard cells, hard macros, or other soft macros. The .CEL view of a soft macro is used to
create the white-box. Before creating the white box model, it is necessary to proceed through
several stages. In particular, the power analysis stage needs to be performed (which requires
the loading of power supply voltages, net switching information, and possibly 3rd-party
transition times) and the power/ground nets need to be extracted.

Database clean up
poPurgePowerInfo + poCleanupExtraction

Load power supply informations

poLoadPowerSupply

Load current limit technology file

auAlfToDB

Load switching activity

poLoadNetSwitchingInfo

Load macros’ power consumption file

Check power information

poCheckPowerInfo

Check P/G rails

poRailChecking

Run power analysis

poPowerAnalysis

Run P/G rails extraction

poPGExtraction

Run rail analysis

poRailAnalysis

Output voltage drop and electromigration maps

poDisplayVoltageDropMap + poDisplayElectromigrationMap
poQueryPowerInfo + poDisplayPo

Fig 4: Power analysis flow chart

In STMicroelectronics’ digital TV flow, the switching activity is defined incrementally

in the Scheme format. First, a maximum activity is assigned to each net (1). It means that
each net toggles at each rising edge of the max clock frequency. Then, an activity of 33% is
defined for each clock domain (2). Finally, a 100% activity is defined on the clock nets (3). If
a net is neither assigned in the step (2) nor the step (3), it will inherit an activity from the step
(1).
SNUG Europe 2005 9 Power analysis
in
hierarchical implementation flow
 An ALF technology file is loaded to define current limits for the electro-migration
analysis, as well as a file containing the macros’ power consumption. Several sanity checks
are performed (poPowerCheckInfo).

Once the power analysis and PG extraction stages have been completed, the white-box
model for a soft macro is generated using the poGenWhiteBox command. A rail analysis is
also performed for the designer to get an early check on the voltage drop of the soft blocks
and a .CONN view of the block is generated.

The soft macro modeling takes approximately 4% of the total netlist to gdsii runtime.
Here is an example:
o ~350k instances + 62 memory cuts
o Cmos090
o 166Mhz clock frequency
o 25 hours runtime to execute full P&R single pass flow (Opteron 2Ghz hardware)
o 40 minutes to run full power analysis using 2.5Go memory:
ƒ activity propagation
ƒ voltage drop analysis for power and ground nets
ƒ electromigration analysis for power and ground nets
ƒ design power consumption reporting
ƒ design power modeling

To ease the top level integration, soft block packaging as the latest mkAstro step is
implemented. All worldwide standard formats have been written out before for signoff
purposes. But to use the advantage of working on an integrated framework through the
Milkyway link, a binary library is generated per soft block. The main characteristics of this
library are:
• Without a detailed implementation context, which means no absolute nor relative
paths are kept any longer and thus no reference libraries are linked.
• Self-contained, but as light from the disk usage point of view as possible.
• Allowing full accurate top level integration and refinement
Five major steps are performed to build this library:
• Using geMakeMacro abstract, .FRAM view is created.
• From the Astro timing analysis, timing modeling is performed using
astTimingModel native command. All timing arcs are described in a .TIM view as
all clock pins properties.
• From a previous Astro-Rail power analysis, the white and grey box modeling
.CONN and .PARA views are kept.
• From Astro or StarRCXT RC extraction, a parasitic modeling is generated and RC
.PARA view stored.
• Using Astro axComputeHierAntennaProp, the native command antenna modeling
is done.
• Finally, an Astro stream in process is done to get a full layout .CEL view. To
secure final .gds generation on the fly, a scheme-based uniquify process is
performed on all child cells.
This Milkyway library allows the top-level integrator to perform design timing analysis, SI
fixing, power analysis, and full stream out in the integrator’s JupiterXT environment.
SNUG Europe 2005 10 Power analysis
in
hierarchical implementation flow
 2.5. Top level power analysis
We are running a top-level power analysis under JupiterXT, calling Astro-Rail under the
wood. Astro-Rail’s flexibility allows to perform power analysis (mainly voltage drop and
electromigration analysis) all along the building of the design top-level integration database:
• The full black-box support capability allows to perform a very early power-grid
integrity check, using rough power budgets for each partition. At the same time, this
allows to optimize design padring by trying to get a uniform voltage-drop map in the
early stages.
• Through a smooth bottom-up process, all the detailed soft-block implementation
modeling recurs in the top-level integration database, using mkAstro or mkLibGen
Milkyway libraries. For the top level integrator, this bottom-up process is free thanks
to the Milkyway database. Each soft-block binary library is added as a top-level
reference library and the existing soft block is deleted to allow to link on.
At any time, a preferred macro-modeling style (black box, grey box, or white box)
can be selected, according to the end-user needs.

From the scripting point of view, the top-level power analysis requires the same bundle
of technology files and scripts as the block level analysis. The only difference is in the
description of power pads, which can be handled through an interactive browser by masters
or instances.

As an example, we are listing below the key numbers observed on our 500K-instances
design using 2Ghz Opteron hardware. All these values represent the power and ground
voltage drop and electromigration analysis:
• Library modeling : ~10 hours for all IOs and memory cuts
• Full flat analysis :
o Runtime : 45 minutes
o Memory consumption : 4.8 Go
• Hierarchical analysis :
o Runtime : 1 hour and 50 minutes cumulated
ƒ Top-level analysis, following a full bottom-up process : 24 minutes
ƒ Block-level analysis and power modeling :
• Soft block 1 : 31 minutes
• Soft block 2 : 32 minutes
• Soft block 3 : 4 minutes
• Soft block 4 : 19 minutes
o Memory consumption : 3.5 Go memory peak
ƒ Top-level analysis, following a full bottom up-process : 3.5 Go
ƒ Block-level analysis and power modeling :
• Soft block 1 : 1.7 Go
• Soft block 2 : 2.0 Go
• Soft block 3 : 0.3 Go
• Soft block 4 : 1.1 Go
In short, the hierarchical approach provides:
• 27% memory saving
• 47% top-level analysis runtime saving for each top-level iteration, thanks to
modeling, which outbalances the 50% total runtime increase
SNUG Europe 2005 11 Power analysis
in
hierarchical implementation flow
3.0 Conclusions
STMicroelectronics’ digital TV flow for hierarchical rail analysis has been successfully
used in several designs. It saved one day’s work for a designer who misconnected some IOs
to the power ring. Apart from failure analysis, the flow can somehow be used for quantitative
analysis as well. The flow is easy to use because it is integrated into our place and route
environment and it is based on the Milkyway database, used for the implementation flow. The
analysis can be performed early in the back-end design cycle. The macro-modeling
capabilities allow a bottom-up approach and can reduce turn-around time and hardware
requirement on big SoCs. The flow described herein is open, in the sense that any third-party
soft or hard macros can be modeled and re-used during the top-level analysis.

4.0 Design and design flow future

At this time, the usage of Astro-Rail is fully deployed and it is a mandatory part of our
current design flow. Albeit only a limited spectrum of its capacity is used. As the usage of
Astro-Rail is now established in our design teams, we are looking at how to take the most
benefit of the tool. The near-future improvements in our flow will be:
• To improve PNA (Power Network Analysis), PNS (Power network synthesis) and
PPS (Power pads synthesis) usage, if the Astro-Rail correlation is confirmed. All
these engines are available through JupiterXT to help the top-level integrator to
optimize, in the fastest possible way, the area vs. power ratio.
• To use virtual pads creation capabilities coming from PNA and implemented in
Astro-Rail to factor in the power analysis earlier in the flow up to physical
prototyping.
• To deploy Astro-Rail through worldwide standard formats, such as .lef and .def,
instead of performing it on the Milkyway database to reinforce its signoff positioning.

Beyond static, we are also looking into a vectorless dynamic analysis, using the Synopsys
tool:
• The speed of memory interfaces rises each year and we need to pay close attention to
phenomena like simultaneous IOs switching (IOSS).
• Today, first power failures in our advanced chips are observed on silicon during scan
shifting. These observations are the first alerts of dynamic-power issues that need to
be addressed before a functional failure occurs.

SNUG Europe 2005 12 Power analysis

in
hierarchical implementation flow