Design Compiler and Physical Compiler Multivoltage

Design Compiler® and
Physical Compiler®
Multivoltage User Guide
Version Y-2006.06, June 2006
Comments?
Send comments on the documentation by going
to http://solvnet.synopsys.com, then clicking
“Enter a Call to the Support Center.”
Copyright Notice and Proprietary Information
Copyright © 2006 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.”
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.
Registered Trademarks (®)
Synopsys, AMPS, Cadabra, CATS, CRITIC, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSIM,
HSPICE, iN-Phase, in-Sync, Leda, MAST, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler,
PrimeTime, Saber, SiVL, SNUG, SolvNet, System Compiler, TetraMAX, VCS, and Vera are registered trademarks of
Synopsys, Inc.
Trademarks (™)
Active Parasitics, AFGen, Apollo, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BOA, BRT,
ChipPlanner, Circuit Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE,
CosmosScope, CosmosSE, Cyclelink, DC Expert, DC Professional, DC Ultra, Design Advisor, Design Analyzer, Design
Vision, DesignerHDL, DesignTime, Direct RTL, Direct Silicon Access, Discovery, Dynamic Model Switcher,
Dynamic-Macromodeling, EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Formal Model Checker,
FoundryModel, Frame Compiler, Galaxy, Gatran, HANEX, HDL Advisor, HDL Compiler, Hercules, Hercules-II,
plus
Hierarchical Optimization Technology, High Performance Option, HotPlace, HSIM , HSPICE-Link, i-Virtual Stepper,
iN-Tandem, Integrator, Interactive Waveform Viewer, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme, Liberty,
Libra-Passport, Libra-Visa, Library Compiler, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture, Milkyway,
ModelSource, Module Compiler, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Orion_ec, Parasitic View, Passport,
Planet, Planet-PL, Planet-RTL, Polaris, Power Compiler, PowerCODE, PowerGate, ProFPGA, ProGen, Prospector,
Raphael, Raphael-NES, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon
Blueprint, Silicon Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, Softwire, Source-Level Design, Star,
Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP,
Taurus, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice,
TSUPREM-4, TymeWare, VCS Express, VCSi, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator,
VirSim, and VMC are trademarks of Synopsys, Inc.
Service Marks (SM)

MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
All other product or company names may be trademarks of their respective owners.
Design Compiler and Physical Compiler Multivoltage User Guide, version Y-2006.06
ii
Contents
What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

About This User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1. Multivoltage/Multisupply Designs and Design Flow

Multivoltage and Multisupply Designs . . . . . . . . . . . . . . . . . . . . . . . 1-2
Library Requirements for Multivoltage Designs . . . . . . . . . . . . . 1-4
Voltage Area Requirements for Multivoltage Designs . . . . . . . . 1-5
Level-Shifter and Isolation Cell Requirements and
Recommendations for Multivoltage Designs . . . . . . . . . . . . 1-5
Limitations in the Design Compiler/Physical Compiler
Multivoltage Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Reports in the Multivoltage Mode . . . . . . . . . . . . . . . . . . . . . . . 1-8
Multivoltage Design Compiler/Physical Compiler Flow . . . . . . . . . . 1-10
Multivoltage Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Interacting With Other Synopsys Tools . . . . . . . . . . . . . . . . . . . . . . 1-13
iii
2. Logic Synthesis Phase
Invoking Design Compiler With Multivoltage
Capabilities Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Target Library Subsetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Inserting Buffer-Type Level Shifters. . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Inserting Isolation Cells and Enable-Type Level Shifters. . . . . . . . . 2-6
Using Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Inferring Power Domains From an RTL Design . . . . . . . . . . . . . 2-9
Creating Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Reporting Errors in Multivoltage Designs . . . . . . . . . . . . . . . . . 2-16
Voltage Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Design Compiler Top-Down Compile Flow . . . . . . . . . . . . . . . . . . . 2-17
Handling Designs That Use Isolation Cells and
Level Shifters, Including Enable-Type Level Shifters . . . . . . 2-20
Inserting Level Shifters When Enable-Type
Level Shifter Library Cells Are Available . . . . . . . . . . . . 2-21
Inserting Level Shifters When Enable-Type Level
Shifter Library Cells Are Not Available . . . . . . . . . . . . . . 2-23
Top-Down Compile Example Script . . . . . . . . . . . . . . . . . . . . . . 2-24
Design Compiler Bottom-Up Compile Flow . . . . . . . . . . . . . . . . . . . 2-27
Bottom-up Compile Script for Designs That Reference
Multiple Multivoltage NLDM Libraries. . . . . . . . . . . . . . . . . . 2-30
Automated Chip Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Automated Chip Synthesis Flow Using Multiple
Multivoltage NLDM Libraries . . . . . . . . . . . . . . . . . . . . . . . . 2-34
iv
Automated Chip Synthesis Script for Designs
That Reference Multiple Multivoltage NLDM Libraries . . . . . 2-35
3. Physical Synthesis Phase

Invoking Physical Compiler With Multivoltage
Capabilities Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Creating Voltage Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Creating Voltage Areas Manually. . . . . . . . . . . . . . . . . . . . . . . . 3-7
Deriving Voltage Areas Automatically . . . . . . . . . . . . . . . . . . . . 3-8
Updating Voltage Areas in a Design . . . . . . . . . . . . . . . . . . . . . 3-10
Including Guard Bands With the Voltage Areas. . . . . . . . . . . . . 3-10
Handling Logically Nested Voltage Areas . . . . . . . . . . . . . . . . . 3-13
Removing Voltage Areas From a Design . . . . . . . . . . . . . . . . . . 3-15
Reporting on the Voltage Areas of a Design . . . . . . . . . . . . . . . 3-15
Checking Isolation Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Voltage Area-Aware Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Automatic High-Fanout Synthesis . . . . . . . . . . . . . . . . . . . . . . . 3-16
Virtual Hierarchy Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Interface Logic Model Hierarchical Flow
With Voltage Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Multivoltage Relative Placement Capability . . . . . . . . . . . . . . . . 3-19
Maximum Net Length Optimization . . . . . . . . . . . . . . . . . . . . . . 3-20
Voltage Area-Based Optimization . . . . . . . . . . . . . . . . . . . . . . . 3-20
Placing and Optimizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
v
Appendix A. Using Buffer-Type Level Shifters
General Properties of Buffer-Type Level Shifters . . . . . . . . . . . . . . A-2
Buffer-Type Level-Shifter Insertion Flow . . . . . . . . . . . . . . . . . . . . . A-4
Optionally Setting Buffer-Type Level-Shifter Strategy . . . . . . . . . . . A-5
Level-Shifter Threshold (Automatic and User-Specified). . . . . . . . . A-5
Checking the Design for Level Shifters and
Level-Shifter Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Removing Level Shifters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Inserting Buffer-Type Level Shifters. . . . . . . . . . . . . . . . . . . . . . . . . A-9
Placing Level Shifters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
Appendix B. Multivoltage Reports

report_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3
delete_operating_condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-4
report_target_library_subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5
check_mv_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5
check_target_library_subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7
check_level_shifters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7
check_isolation_cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9
report_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12
check_design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12
report_voltage_area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12
vi
report_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13
report_delay_calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15
report_hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15
Appendix C. Logic and Physical Library Models

Logic Library Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
Defining a Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
Defining an Enable-Type Level Shifter . . . . . . . . . . . . . . . . . . . . C-4
Defining a Buffer-Type Level Shifter. . . . . . . . . . . . . . . . . . . . . . C-4
Physical Library Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
Defining Core Sites in the Library . . . . . . . . . . . . . . . . . . . . . . . C-5
Defining a Level-Shifter Physical Cell . . . . . . . . . . . . . . . . . . . . C-6
Index
vii
viii
Preface FIX ME!
This preface includes the following sections:
• What’s New in This Release

• About This User Guide
• Customer Support
ix
What’s New in This Release
The following new features, enhancements, and changes to the
multivoltage capabilities are supported by Design Compiler and
Physical Compiler, version Y-2006.06:
• Multivoltage mode is on by default. Design Compiler and Physical

Compiler can recognize a multivoltage design and automatically
use the appropriate multivoltage algorithms. Therefore, the
-mv_mode switch is no longer required.
• Power domains are supported in Design Compiler. You can
define power domains in the RTL design by using the Verilog
system task $power or the VHDL power procedure. Design
Compiler can infer the power domains from the RTL code.
Also, you can directly create power domains in Design Compiler.
Several new commands are introduced to allow you to define
specific power domain properties and to manage power
domains, including:
- Specifying relative always-on power domains (that is,

always-on with respect to some other power domain)
- Specifying always-on library cells, library cell pins, and leaf cell
pins
- Connecting the power pins of a power domain
- Reporting on power domains, power nets, and power pins
• Top-down compile of multivoltage designs with power domains is
supported in Design Compiler.
Preface
x
• Design Compiler supports the use of both isolation cells and
enable-type level shifters in the same multivoltage design.
However, you use slightly modified compile flows, depending on
whether enable-type level shifter library cells are available and on
whether a power domain’s isolation cell is located outside or
inside the domain. If enable-type level shifter cells are available,
Design Compiler can map the GTECH isolation cells to the
appropriate enable-type level shifter library cell.
• The command check_mv_design is introduced in this release.
It can invoke various checking algorithms under-the-hood, based
on the switches you specify. The current set of switches include
- -isolation – To report on electrical isolation errors between
power domains
- -connection_rules – To report on always-on and
pass-gate violations
- -opcond_mismatches – To report on incompatible operating
conditions between instantiated technology cells and the cell’s
parent design
- -target_library_subset – To report on inconsistent
settings among target libraries, target library subsets, and
operation conditions
In future releases, new switches will be provided so that more
checking algorithms can be invoked through this command.
• Logically nested voltage areas are supported in Design Compiler

and Physical Compiler. Note, however, that voltage areas cannot
be physically nested.
What’s New in This Release

xi
Therefore, in Physical Compiler, you must use the appropriate
commands to resolve the logically nested voltage areas into flat
voltage areas consisting of disjoint rectangles and rectilinear
shapes. None of these shapes may intersect, overlap, or be
embedded within any other voltage area shape.
• Physical Compiler supports the use of interface logic models

(ILMs) in multivoltage designs. A voltage area can contains ILMs,
and an ILM can contain voltage areas.
• Physical Compiler supports relative placement within the voltage
areas of a multivoltage design.
About This User Guide

This Design Compiler and Physical Compiler Multivoltage User
Guide describes the combined Design Compiler/Physical Compiler
multivoltage design flow from RTL synthesis, through level-shifter
insertion and voltage area creation, to physical placement and
optimization. The flow assumes that a floorplan is available (created
in JupiterXT or in a third-party tool).
This flow is part of the larger multivoltage design flow of the Galaxy
Design Platform. Currently, the flow applies only to designs with fixed
power domains, each operating at a single voltage; that is, designs
that employ dynamic or adaptive voltage scaling are not supported
in this release.
The complete Galaxy Design Platform multivoltage design flow uses

the following tools:
• Design Compiler
• JupiterXT
Preface
xii
• Physical Compiler
• Astro
• Star-RCXT
• PrimeTime
• Formality
To understand how to use the tools in the Galaxy flow, see the
appropriate user guides. This user guide documents the Design
Compiler/Physical Compiler part of the flow.
The Design Compiler/Physical Compile multivoltage flow and related

topics are described in these chapters:
• Chapter 1: Multivoltage/Multisupply Designs and Design Flow

• Chapter 2: Logic Synthesis Phase
• Chapter 3: Physical Synthesis Phase
A number of appendixes covering specialized topics are included.
Audience
This user guide is for design engineers who use Design Compiler
and Physical Compiler to implement designs.
To use these Synopsys tools, you need to be skilled in logic design

and the use of PrimeTime and Formality, have general knowledge of
a hardware description language (HDL), and be familiar with the
following:
• Logic design and timing principles

xiii
• Physical design principles
• The UNIX operating system
• The tool command language (Tcl)
Preface
xiv
Related Publications
For additional information about Design Compiler and Physical
Compiler, as well as the other tools of the Galaxy Design Platform,
see
• Synopsys Online Documentation (SOLD), which is included with

the software for CD users or is available to download through the
Synopsys Electronic Software Transfer (EST) system
• Documentation on the Web, which is available through SolvNet
at http://solvnet.synopsys.com/DocsOnWeb
• The Synopsys MediaDocs Shop, from which you can order
printed copies of some Synopsys documents, at
http://mediadocs.synopsys.com

xv
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier Indicates command syntax.
Courier italic Indicates a user-defined value in Synopsys

syntax, such as object_name. (A user-defined
value that is not Synopsys syntax, such as a
user-defined value in a Verilog or VHDL
statement, is indicated by regular text font
italic.)
Courier bold Indicates user input—text you type verbatim—

in Synopsys syntax and examples. (User input
that is not Synopsys syntax, such as a user
name or password you enter in a GUI, is
indicated by regular text font bold.)
[] Denotes optional parameters, such as

pin1 [pin2 ... pinN]
| Indicates a choice among alternatives, such as

low | medium | high
(This example indicates that you can enter one
of three possible values for an option:
low, medium, or high.)
_ Connects terms that are read as a single term

by the system, such as
set_annotated_delay
Control-c Indicates a keyboard combination, such as

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

opening the Edit menu and choosing Copy.
Preface
xvi
Customer Support
Customer support is available through SolvNet online customer
support and through contacting the Synopsys Technical Support
Center.
Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles
and answers to frequently asked questions about Synopsys tools.
SolvNet also gives you access to a wide range of Synopsys online
services including software downloads, documentation on the Web,
and “Enter a Call to the Support Center.”
To access SolvNet,
1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

2. If prompted, enter your user name and password. (If you do not
have a Synopsys user name and password, follow the
instructions to register with SolvNet.)
If you need help using SolvNet, click HELP in the top-right menu bar
or in the footer.
Customer Support
xvii
Contacting the Synopsys Technical Support Center
If you have problems, questions, or suggestions, you can contact the
Synopsys Technical Support Center in the following ways:
• Open a call to your local support center from the Web by going to
http://solvnet.synopsys.com (Synopsys user name and
password required), then clicking “Enter a Call to the Support
Center.”
• Send an e-mail message to your local support center.
- E-mail support_center@synopsys.com from within North
America.
- Find other local support center e-mail addresses at
http://www.synopsys.com/support/support_ctr.
• Telephone your local support center.
- Call (800) 245-8005 from within the continental United States.
- Call (650) 584-4200 from Canada.
- Find other local support center telephone numbers at
http://www.synopsys.com/support/support_ctr.
Preface
xviii
1
Multivoltage/Multisupply Designs and
Design Flow 1
This chapter includes the following sections:
• Multivoltage and Multisupply Designs

• Multivoltage Design Compiler/Physical Compiler Flow
• Multivoltage Design Example
• Interacting With Other Synopsys Tools
1-1
Multivoltage and Multisupply Designs
In XG mode, Design Compiler and Physical Compiler support the
following types of designs:
• Multivoltage
• Multisupply
• Mixed multivoltage and multisupply
In multivoltage designs, the subdesign instances (blocks) operate at
different voltages. In multisupply designs, the block voltages are the
same. In the mixed design case, some blocks operate at different
voltages and other blocks operate at a common voltage.
To reduce power consumption, multivoltage designs typically make

use of power domains. The blocks of a power domain can be
powered up and down, independent of the power state of other
power domains (except where an always-on relationship exists
between two power domains).
Specifically, a power domain is defined as a logical grouping of one

or more hierarchical blocks in a design that share the following:
• Primary voltage states or voltage range (that is, the same

operating voltage)
• Power net hookup requirements
• Power-down control and acknowledge signals (if any)
• Power switching style
• Same process, voltage, and temperature (PVT) operating
condition (all cells of the power domain except level shifters)
Chapter 1: Multivoltage/Multisupply Designs and Design Flow

1-2
• Same set or subset of nonlinear delay model (NLDM)
target libraries
• A physical voltage area (defined in Physical Compiler, Jupiter XT,
or IC Compiler, but not in Design Compiler) into which the cells of
these logic hierarchies are to be placed
Note:
Design Compiler and Physical Compiler do not automatically
align the logic hierarchies with the power domains and voltage
areas. You are responsible for ensuring that the logic hierarchies
are correctly aligned with their power domains and voltage areas,
as well as being correctly associated with the appropriate
operating condition. In Physical Compiler, you align the logic
hierarchies as part of defining the voltage areas.
As noted, a voltage area is the physical placement area of a logic

block (comprising one or more logic hierarchies) operating under a
single voltage level. Voltage areas are based on the floorplan. They
can be created at the floorplanning stage by using the JupiterXT or
Astro tool, or they can be created in Physical Compiler by using the
create_voltage_area command before running the physopt
command.
Level shifters connect drive and load pins operating at different

voltages across the power domains.
In Design Compiler and Physical Compiler, level-shifter cells are

modeled either as simple buffers or as buffer cells with an enable pin.
Enable-type level shifters are used when the power domains of a
design must be powered on and off independently.
You can use commands that automatically insert buffer-type level

shifters into an unmapped or mapped netlist at any point in the flow
before using Physical Compiler to place the cells of a design. It is

1-3
recommended that you insert level shifters as early in the flow as
possible. In some cases, however, early level-shifter insertion is not
advisable. With certain designs, you have to insert level shifters late
in the design flow.
Note that enable-type level shifters should be instantiated at the RTL

level before compiling the design with Design Compiler or Automated
Chip Synthesis. A design can contain both types of level shifters.
For multisupply designs, you use isolation cells to isolate the input
and output signals of the power domains. These cells should be
instantiated at the RTL level of the design description.
Level-shifter and isolation cells are placed near the voltage area
boundaries, usually at the top level of the design. However, by
appropriately specifying the port voltages, these cells can be placed
inside the voltage areas. A default voltage area is derived for
top-level leaf cells and the buffer-type level shifters that do not belong
to any block.
Library Requirements for Multivoltage Designs

The libraries must conform to the Liberty open library rules. Design
Compiler, Automated Chip Synthesis, and Physical Compiler, as well
as Astro and JupiterXT, support multivoltage, multiple nonlinear
delay model (NLDM) libraries characterized at different voltages.
Target library cells are selected on the basis of matching operating

conditions between library cells and voltage areas. The selection of
these cells can be further restricted with the
set_target_library_subset command.
For multivoltage designs, library limitations include the following:

1-4
• k-factors are not supported, so libraries must be characterized at
specific voltages.
• Modeling of power supplies, enable-type level shifters, and
buffer-type level shifters must follow the model rules given in
Appendix C, “Logic and Physical Library Models.”
In general, the operating condition associated with a voltage area is
sufficient to determine the eligible target library cells for the voltage
area. However, certain designs may require a further restriction of
candidate target library cells. This can be achieved by using the
set_target_library_subset command to specify a target
library list and a list of eligible hierarchical cells. The combination of
these command specifications and the operating condition for a
voltage area is sufficient to restrict cell selection to the desired
subset of cells.
Voltage Area Requirements for Multivoltage Designs

The following voltage area requirements must be observed:
• The floorplan must contain at least one voltage area (and a

default voltage area).
• The logic hierarchy must align with its voltage area.
Level-Shifter and Isolation Cell Requirements and

Recommendations for Multivoltage Designs
The following level-shifter and isolation cell requirements must be
observed:
• Two power supplies are sometimes required.

1-5
• Level-shifter library cells can be buffer-type or enable-type.
These are the only level shifters currently supported by Design
Compiler and Physical Compiler. (Isolation cells always have an
enable pin.)
• Buffer-type and enable-type level-shifter library cells must have
the is_level_shifter library attribute set to true.
• Isolation library cells must have the is_isolation_cell
library attribute set to true.
• Enable-type level shifters must have the
level_shifter_enable_pin library attribute on the enable
pin.
• Isolation cells must have the isolation_cell_enable_pin
library attribute on the enable pin.
• Level shifters and isolation cells are selected by Design Compiler
and Physical Compiler from the target libraries. Therefore, at
least one of the libraries must contain the required cells.
• You can define special sites where Physical Compiler places the
level shifters and isolation cells when you run the physopt
command. Note that Physical Compiler supports only aligned
rows. The tool attempts to place the level shifters and isolation
cells near the voltage area boundaries.

1-6
Limitations in the Design Compiler/Physical Compiler
Multivoltage Design Flow
You should take the following limitations into account when
optimizing (Design Compiler or Automated Chip Synthesis) and
placing a multivoltage design (Physical Compiler):
• Automated Chip Synthesis automatically inserts buffer-type level

shifters as needed and sets the dont_touch attribute on them.
For level shifters that were instantiated at the RTL level, the tool
uses the -preserve option of the insert_level_shifters
command to set the dont_touch attribute on these cells; the
other options of this command are not used by Automated Chip
Synthesis.
• The tools do not support a voltage area physically nested within
another voltage area. In Physical Compiler; use hard bounds
inside a voltage area instead.
• Automatic insertion of isolation cells and enable-type level
shifters is not supported. Instantiate these cells in the RTL design
description.
• Voltage areas consisting of abutted rectangles or rectilinear
shapes are supported and are used to physically resolve logically
nested voltage areas. Voltage areas consisting of disjoint
rectangles or rectilinear shapes are not supported.
• The minimum physical constraints (MPC) feature is not
supported in multivoltage mode.

1-7
Reports in the Multivoltage Mode
For multivoltage designs, reporting functions are expanded or
enhanced to provide additional information so that you can carry out
basic checks to verify your input specifications. In particular, with the
enhanced report commands in multivoltage mode, you can
• List all available operating conditions

• Check for different operating conditions set on different blocks
• Determine whether each block operates at its specified operating
condition
• Determine whether each physical voltage area corresponding to
a specific power domain has the same operating condition
• Check for any target library subsetting used in the multivoltage
design flow
The following reporting and checking commands are used for
multivoltage designs:
• report_operating_conditions
• report_target_library_subset
• check_mv_design
• check_level_shifters
• check_isolation_cells
In multivoltage mode, the following existing commands are
enhanced:
• report_cell

1-8
• check_design
• report_voltage_area
• report_timing
• report_delay_calculation
• report_hierarchy
For information on these report commands and how to use them,
see Appendix B, “Multivoltage Reports.”

1-9
Multivoltage Design Compiler/Physical Compiler Flow
The multivoltage Design Compiler/Physical Compiler design flow
consists of two major phases:
• Logic synthesis phase
You can use either a top-down or bottom-up compile method in

Design Compiler, or you can use Automated Chip Synthesis.
• Physical synthesis phase
You use Physical Compiler to place the cells and optimize the
design. You must define the placement voltage areas and insert
level shifters and isolation cells before running physopt.
Note:
Before running the physopt command, a floorplan must be
available. See the Physical Compiler User Guide, the
JupiterXT Top-Down Hierarchical Flow User Guide, and the
JupiterXT Virtual Flat Flow User Guide for further information.
Figure 1-1 shows a high-level multivoltage design flow example.
Note that other flows, using additional tools, are possible.

1-10
Figure 1-1 High-Level Design Compiler/Physical Compiler Multivoltage
Design Flow Example
Buffer-type level-shifter insertion
Logic synthesis
(top-down compile)
Physical Compiler
Voltage area creation (or IC Compiler) tool
assumes floorplan
(in Physical Compiler or IC Compiler input available
unless created in JupiterXT) from Jupiter XT
or third-party tool
Physical synthesis
(placement and optimization)
Multivoltage Design Compiler/Physical Compiler Flow

1-11
Multivoltage Design Example
Figure 1-2 shows a simple multivoltage design. This example is used
along with various scripts in the following chapters to illustrate the
multivoltage Design Compiler/Physical Compiler flow. That is, the
example and its accompanying scripts show you how to take a
multivoltage design from RTL input through logical and physical
synthesis.
The multivoltage design consists of a top level that operates at 1 volt

in the VDD1 power domain and two blocks that operate at different
voltage levels. Block1 operates at 2 volts in the VDD2 power domain,
and Block3 operates at 3 volts in the VDD3 power domain. The
assigned operating conditions are NOM_V1 for the top level,
NOM_V2 for Block1, and NOM_3 for Block3. The design uses
multiple NLDM target libraries, Nom1.db, Nom2.db, Nom3.db, and a
separate level-shifter library, level_shifter.db.

1-12
Figure 1-2 A Simple Multivoltage Design With a Top Level and Two Blocks
Top: VDD1
1 volt
op_cond NOM_1V
Block1: Block2:
VDD2 VDD3
2 volts 3 volts
op_cond NOM_2V op_cond NOM_3V
Multiple NLDM Libraries:
1 V target library 2 V target library 3 V target library
Nom1.db:Nom1 Nom2.db:Nom2 Nom3.db:Nom3
Interacting With Other Synopsys Tools

The Design Compiler/Physical Compiler multivoltage design flow is
part of a larger design flow involving several other Synopsys tools.
As shown in Figure 1-3, these additional tools of the Galaxy Design
Platform flow include JupiterXT, Astro, Star-RCXT, PrimeTime, and
Formality. This is a complete RTL-to-sign-off design flow. To
Interacting With Other Synopsys Tools

1-13
understand how to use the individual tools of the design flow, consult
the appropriate user guides. Also, for an overview of the complete
multivoltage design flow, see the Multivoltage Design Flow
Methodology Application Note (version 0.5, May 4, 2005).
Figure 1-3 Galaxy Design Platform High-Level Multivoltage Flow
Apply operating conditions

Logic synthesis
Insert level shifters
(DC or ACS) Compile
Create physical partition

Hierarchical planning
Voltage area location based on virtual flat
(JupiterXT) Power routing
Create voltage areas as needed

Multiple NLDM Libraries
Physical synthesis Run physopt

(PC) Run report_timing -volt
Create voltage areas as needed
Multivoltage Run clock tree synthesis
implementation (Astro) Post-clock tree optimization
Auto-route
Place and route optimization
Parasitic extraction
Parasitic extraction
(Star-RCXT)
Sign-off static timing Signal integrity timing sign-off

analysis (PrimeTime) Run check_timing -inc signal_level
Formal verification RTL versus gates matching

(Formality)

1-14
2
Logic Synthesis Phase 2
You can compile a multivoltage design by using any one of
these methods:
• Top-down compile, using Design Compiler

• Explicit bottom-up compile flow, using Design Compiler
• Automated bottom-up compile, using Automated Chip Synthesis
These methods can directly handle designs with power domains,
multiple operating conditions, and multivoltage, multiple nonlinear
delay model (NLDM) libraries.
• Invoking Design Compiler With Multivoltage Capabilities Enabled

• Target Library Subsetting
• Inserting Buffer-Type Level Shifters
2-1
• Inserting Isolation Cells and Enable-Type Level Shifters
• Using Power Domains
• Design Compiler Top-Down Compile Flow
• Design Compiler Bottom-Up Compile Flow
• Automated Chip Synthesis Flow
Chapter 2: Logic Synthesis Phase

2-2
Invoking Design Compiler With Multivoltage
Capabilities Enabled
The default mode for Design Compiler is XG mode with all
multivoltage features automatically enabled. At the system prompt,
enter
%: dc_shell-t
The tool recognizes a design as a multivoltage design and utilizes

the multivoltage capabilities if any of the following conditions are
true:
• Instance-based operating conditions are specified

• Target library subsetting is used
• If the -mv_mode switch is specified with dc_shell-t (switch is
needed only when you want to force the tool to treat a design that
does not meet either previous condition as a multivoltage design)
If none of these conditions hold, the tool assumes the design is not
a multivoltage design.
Recall that k-factors are not supported for multivoltage designs and
are ignored if present in the libraries.
Target Library Subsetting

You can use the set_target_library_subset command to
restrict the target library cells eligible for mapping the hierarchical
cells of a block.
Invoking Design Compiler With Multivoltage Capabilities Enabled

2-3
The command syntax is
set_target_library_subset {library_list} -object_list

{cell_list} [-top]
where
• library_list is a list of target library file names, all of which

must also be listed in the main library variable
• cell_list is a list of hierarchical cells (blocks or top level) for
which the target library subset is used
• -top is included if you want to apply this command to the
top-level design
Using this command on a hierarchical cell or at the top level applies
the library subset constraint on all lower cells in the hierarchy, except
for those cells that have a different library subset constraint explicitly
set on them.
Note:
The set_target_library_subset command does not
require a uniquified design before using the command. However,
if you use the insert_level_shifters command in the
Design Compiler flow, you must first run uniquify.
To remove a target library subset constraint, use the

remove_target_library_subset command with the
appropriate library list and cell list.
You can check for errors and conflicts introduced by target library
subsetting by using the check_mv_design command with the
-target_library_subset option. This command checks for

2-4
• Conflicts between target library subsets and the global
target_library variable
• Conflicts between operating condition and target library subset
• Conflicts between the library cell of a mapped cell and target
library subset
Use the report_target_library_subset command with the
appropriate library list and cell list to find out what target library
subsets have been defined for which hierarchical cells and/or top
level.
Inserting Buffer-Type Level Shifters

Buffer-type level shifters can be inserted at any stage of the flow
before placement by running the insert_level_shifters
command.
It is strongly recommended that you insert them early in the flow,

preferably before you compile the design in dc_shell. However, you
can insert them after the final compile of the design or in psyn_shell
before placement.
The is_level_shifter library attribute should be set to true for

both types of level shifters. Enable-type level shifters should have the
level_shifter_enable_pin attribute set on the appropriate
input pin. The PVT operating condition must refer to the output side
of a level shifter; otherwise, the tool creates new operating conditions
under-the-hood that are not written out and passed to the rest of the
flow.

2-5
You must explicitly issue the insert_level_shifters command
to insert buffer-type level shifters. However, if you run Automated
Chip Synthesis for the logic synthesis phase, the buffer-type level
shifters are automatically inserted because the tool writes the
command into the script before compiling.
Level shifters are inserted as part of the top-level design, but you can
insert a level shifter within a block by specifying a block port voltage
that is different from the block voltage. Note that there is no direct
relationship between power domains and level-shifter insertion.
Level-shifter insertion is basically governed by voltage differences
defined by different operating condition settings.
You can use the check_level_shifters command to check level

shifters for design violations. Also, there are commands to remove
level shifters and report level-shifter data. For more information
about inserting and handling buffer-type level shifters,
see Appendix A, “Using Buffer-Type Level Shifters.”
Inserting Isolation Cells and Enable-Type Level Shifters

Isolation cells and enable-type level shifters are used to selectively
shut off the input side of the voltage interface of a power domain (see
“Creating Power Domains” on page 2-10). Isolation cells do not shift
the voltage. Enable-type level shifters step the voltage up or down.
These cells should be instantiated at the RTL level; otherwise formal

verification of the logic is likely to fail. For isolation cells, you can
either manually instantiate an isolation cell from the technology
library, or you can use the $isolate Verilog system task or the VHDL
isolate procedure to instantiate a GTECH isolation cell (see the

2-6
HDL Compiler (Presto Verilog) Reference Manual or the
HDL Compiler (Presto VHDL) Reference Manual). The following
GTECH cells are available from the GTECH library:
• GTECH_ISO1_EN1
• GTECH_ISO1_EN0
• GTECH_ISO0_EN1
• GTECH_ISO0_EN0
• GTECH_ISOLATCH_EN1
• GTECH_ISOLATCH_EN0
If you use the GTECH isolation cells, they can be mapped,
retargeted, and sized during compile. Note, however, that power
domains are used to constrain the GTECH isolation cells.
In the target libraries, the is_isolation_cell library attribute

should be set to true for isolation cells. With enable-type level
shifters, the is_level_shifter library attribute must be set to
true for the library cell, and the level_shifter_enable_pin
library attribute must be set on the appropriate input pin of the library
cell.
Note:
When you run the compile command, the tool attempts to
replace isolation cells with enable-type level shifters. However,
the insert_level_shifters command does not attempt this
kind of replacement.
There are a number of ways in which isolation cells and enable-type

level shifters might be connected to the input and output nets of the
voltage areas (power domains). It is possible to accidentally
Inserting Isolation Cells and Enable-Type Level Shifters

2-7
introduce redundant isolation cells in the RTL description of the
design or to fail to specify necessary cells. You can use the
check_isolation_cells command to check for these
conditions. For information on how to use this command, see
Appendix B, “Multivoltage Reports,” and the
check_isolation_cells man page.
Using Power Domains

A power domain is defined as a logic grouping of one or more
hierarchical blocks in a design that share the following:
• Primary voltage states or voltage range

• Power net hookup requirements
• Power-down control and acknowledge signals (if any)
• Power switching style
• Voltage area (physical information defined in Physical Compiler,
Jupiter XT, or IC Compiler, but not in Design Compiler)
Designs are implemented with power domains to control the
powering down and powering up of blocks or groups of blocks of a
design. Domains can be independently switched or sequenced.
Shutting down blocks when they are not in use reduces power
consumption.
A design will contain one or more power domains that are never shut
down. By default, such power domains (absolutely always-on
domains) are mapped with normal cells.

2-8
In addition, however, designs with power domains usually contain
“relative always-on” domains (defined by the
set_relative_always_on command). Such a power domain is
required to be on when some other, specified power domain is on;
that is, it is on relative to the second power domain. In this way, power
can be sequenced through a series of power domains. A relative
always-on power domain can be powered down as long as the other
domain is off.
Power domains are defined hierarchically. When a block is assigned

to a power domain, all the subhierarchies are assigned to the power
domain, unless a lower-level block is assigned to a different power
domain. In this case, all subhierarchies of the lower-level block
belong to the newly assigned power domain.
Control signal paths must remain powered up even when a block is

powered down. To do this, use the get_always_on_logic
command with the -nets option to identify the appropriate net and
net segments, and then mark them as dont_touch.
Note that you also have the capability to define and connect multiple
power and ground nets for each power domain.
Inferring Power Domains From an RTL Design

Power domains can be defined in the RTL design. In Verilog, the
$power system task is used, and in VHDL, a power procedure is
used (see the HDL Compiler (Presto Verilog) Reference Manual or
the HDL Compiler (Presto VHDL) Reference Manual). An RTL power
domain is essentially defined by the following:
• Power domain name

• Power-down and acknowledge signals (if any)
Using Power Domains

2-9
• Sense information on the power-down and acknowledge signals
• List of modules comprising the power domain
Use the infer_power_domain command to translate RTL power
domain constructs to power domain objects of the design read by
Design Compiler. If you use the -verbose option, the equivalent
dc_shell create_power_domain commands are printed as the
power domains are inferred. (See “Creating Power Domains” on
page 2-10 for the dc_shell commands.)
Note:
The infer_power_domain command ignores any sense
information specified on the power-down and acknowledge
signals of the RTL power domain construct.
Creating Power Domains

In Design Compiler, power domains are created with the
create_power_domain command. The
create_power_net_info command is used to identify both
power and ground nets, independent of the power domains.
Note:
The top-level power domain must be created first.
You connect specific power and ground nets to the power pins of the
cells of a power domain by using the connect_power_domain
command.
All cells of the power domain inherit these power and ground
connections, unless you specify an exceptional connection. Use the
connect_power_net_info command to explicitly connect power

2-10
and ground nets to the power pins of one or more leaf cells.
Exceptional power and ground connections supersede the
domain-wise power and ground connections.
Note:
You can use the report_power_pin_info command to obtain
power pin information on the technology library cells or the leaf
cells of the design.
Using the create_power_domain Command

The create_power_domain command is used to create power
domains; it includes the following arguments:
Argument Description
domain_name Name of the power domain to be created.
-power_down Optional. Indicates whether this is a power-down

domain. If not used, this domain is always-on.
-power_down_ctrl Optional. Used to specify the power-down control

net. Requires the -power_down option.
-power_down_ack Optional. Used to specify the acknowledge control

net. Requires the -power_down option.
-object_list Optional. Used to list the hierarchical cells

associated with the power domain. If not used, this
power domain is the top-level domain.
There can be only one top-level domain. Also, each

listed hierarchical cell can belong to only one power
domain.
Using Power Domains

2-11
Note:
The create_power_domain command does not require a
uniquified design before using the command. However, if you use
the insert_level_shifters command in the Design
Compiler flow, you must first run uniquify.
Other commands directly relating to power domains include
• get_power_domains – Use this command to obtain a

collection of the power domains defined in the design.
• report_power_domain – Use this command to obtain a report
on specified power domains.
• remove_power_domain – Use this command to delete one or
more power domains from the design. You must remove all power
domains of the hierarchies before you remove the top-level power
domain.
For more information, see the appropriate man pages.
Using the create_power_net_info Command

The create_power_net_info command is used to specify a
power or ground net object; it includes the following arguments:
power_net_name Name of the power net information object to

be created.
-power Used to specify the power net. Cannot use with the
-gnd option.
-gnd Used to specify the ground net. Cannot use with the
-power option.

2-12
Other commands directly relating to power domains include
• get_power_domains – Use this command to see

already-defined power domains.
• report_power_net_info – Use this command to obtain a
report on all the power net information objects of the design.
• remove_power_net_info – Use this command to delete one
or more power net information objects from the design.
Connecting Power Domains

The connect_power_domain command is used to connect power
and ground nets to power domains; it includes the following
arguments:
object_list List of power domains to be connected.
-primary_power_net Optional. Name of the primary power net.
-primary_ground_net Optional. Name of the primary ground net.
-backup_power_net Optional. Name of the backup power net.
-backup_ground_net Optional. Name of the backup ground net.
-internal_power_net Optional. Name of the internal power net.
-internal_ground_net Optional. Name of the internal ground net.
This command makes domain-wise power and ground net

connections. All cells of the power domain inherit these connections,
unless an exceptional power connection is specified for a cell or
Using Power Domains

2-13
cells. See the previous section on the connect_power_net_info
command for exception connections and the appropriate
man pages.
Specifying Exceptional Power Net Connections

The connect_power_net_info command is used to specify
exceptional power net hookups to the power pins of certain leaf cells
of a power domain; it includes the following arguments:
object_list List of leaf cells for which exceptional power net

connections are made.
-power_pin_name Name of the leaf cell power pin.
-power_net_name Name of the power net.
Run the disconnect_power_net_info command when you

want to remove the exceptional power net connections from a set of
leaf cells. After the exceptional connections are removed, the leaf
cells inherit the domain-wise power net hookups.
Reporting Power Pin Information

Use the report_power_pin_information command to report
the power pin information for the technology library cells or the leaf
cells of the current design. This command takes only an object list
argument of technology library cells or leaf cells.
When you specify a list of library cells, the name, type (power or
ground), and voltage specification of the power pin are reported.
When you specify a list of leaf cells, in addition to this information,
the power net connections are also reported.

2-14
For more information, see the appropriate man page.
Defining Relative Always-On Power Domains

If a power domain cannot be shut down when another power domain
is on, the former power domain is said to be always on relative to the
latter power domain. You establish these relative always-on
relationships between power domains by using the
set_relative_always_on command; it includes the following
arguments:
domain_name Name of the power domain that remains on relative

to other power domains.
-relative_to List of power domains relative to which a specified

power domain is an always-on domain.
The tool uses these relative always-on relationships to determine if

isolation cells are required or not for nets that cross power domains.
Nets with redundant isolation cells are flagged with a warning, and
nets with missing isolation cells are flagged as errors.
Using Power Domains

2-15
Finding Always-On Paths
After you have marked the appropriate library and leaf cell pins with
the always-on attribute, the tool determines the always-on paths
as part of the compile process. You can use the
get_always_on_logic command to find the cells and nets of the
always-on paths. This command includes the following arguments:
-cells Optional. Use this argument to list the cells of the

always-on paths.
-nets Optional. Use this argument to list the nets of the

always-on paths.
-all Optional. Use this argument to list both cells and

nets of the always-on paths. Specifying no
argument is the same as specifying -all.
Reporting Errors in Multivoltage Designs

You can use the check_mv_design command to check for design
errors. Various switches let you specify the level of information detail
and limit the number of messages printed to the log file, as well as
select among the available checking reports. Checking report
switches include
• -isolation – Reports electrical isolation errors between power

domains
• -connection_rules – Reports violations in always-on
synthesis and pass-gate connections

2-16
• -opcond_mismatches – Reports incompatible operating
conditions
• -target_library_subset – Reports inconsistent settings
between target library subsets and operating condition settings
If you do not specify any checkers, violations are reported from all
supported checkers. If you use the -verbose switch, the checkers
provide detailed reports. If you omit this switch, summary reports are
provided.
Note that the check_level_shifters and

check_isolation_cells checking commands are also
available.
Voltage Areas
Voltage areas are physical objects that consist of elementary
physical information, including simple floorplan date. They are not
defined in Design Compiler. (They are defined in Physical Compiler,
Jupiter XT, or IC Compiler.) However, there must be an exact
one-to-one relationship between logical power domains and physical
voltage areas. You are responsible for achieving this consistency,
because the tools do not automatically generate voltage areas from
power domains.
Design Compiler Top-Down Compile Flow

You can run a top-down compile on a multivoltage design, using
multiple nonlinear delay model (NLDM) libraries. The basic,
high-level synthesis flow is shown in Figure 2-1.

2-17
Figure 2-1 Design Compiler Top-Up Down Flow
Read design, link libraries,

and uniquify
Apply constraints
Define power domains
Set operating conditions
Insert buffer-type level shifters
Top-down compile
Physical Compiler flow

2-18
All dc_shell commands support multivoltage designs, including:
• compile
• compile_ultra
• balance_registers
• optimize_registers
• pipeline_design
• simplify_constants
• balance_buffers
• clean_buffer_tree
Restrictions and Limitations
Note the following restrictions and limitations:
• The ungroup command and the compile command’s

automatic ungroup do not perform ungrouping on a subblock if
the operating condition of the subblock is different from the
operating condition of the parent block of the hierarchy.
• Retiming is supported only on blocks with uniform operating
conditions. This restriction applies to retiming within the
compile command and to the stand alone retiming commands,
balance_registers, optimize_registers, and
pipeline_design.
• The simplify_constants command does not simplify across
a level shifter because the nets connected to a level shifter are
dont_touch.
• The translate command is not supported for multivoltage
designs.

2-19
• Upsizing and downsizing of level-shifter cells and isolation cells
is not supported in Design Compiler (supported in Physical
Compiler and IC Compiler).
• The insert_level_shifters command requires
uniquified designs.
• There is currently no way to specify that two power domains turn
on or off simultaneously.
• If power domains are not specified when using isolation cells and
enable-type level shifters, an error condition occurs and the run
stops.
Handling Designs That Use Isolation Cells and Level

Shifters, Including Enable-Type Level Shifters
Additional complexities in the multivoltage design flow arise when
the design utilizes both isolation cells and level-shifter cells.
When an isolation cell is instantiated in a design, the tool marks the

net that connects the isolation cell to the edge of its power domain
as dont_touch. If a voltage difference exists on this path and a
level shifter cell is needed, the dont_touch net can prevent the
insertion of the level shifter. However, such isolation cells can be
mapped to enable-type level shifter cells, as discussed in the
following paragraph.
The design flow is slightly modified to handle this situation. The flow
is further altered if enable-type level shifters are available from the
technology library, because the tool can map generic technology
(GTECH) isolation cells to these enable-type level-shifter cells.
(Enable-type level-shifter cells combine the isolating and
voltage-shifting functions.) The modified flows are outlined in the
following sections.

2-20
However, before running any of these flows, make sure to:
• Set the compile_delete_unloaded_sequential_cells

variable to false. By default, the insert_level_shifters
command removes unloaded logic. This variable protects only
sequential cells, so if you need to protect other unloaded cells,
mark them with the dont_touch attribute.
• Run the uniquify command after elaboration. The
insert_level_shifters command requires a uniquified
design.
Note:
If you have instantiated both the isolation cells and the
level-shifter cells in the RTL design, you do not need to use these
modified flows. But you should run the check_mv_design
command to verify the presence of isolation and level-shifter cells
in the RTL design.
Inserting Level Shifters When Enable-Type Level Shifter

Library Cells Are Available
If you want to map the GTECH isolation cells to the available
enable-type level shifter library cells, you must ensure that
• The design is constrained to require a level shifter on the same

net as the isolation path
• Any previously inserted level shifter is not on the same path
The following flows use the dont_touch attribute of the isolation
cell nets to prevent the insert_level_shifters command from
inserting buffer-type level shifters on those paths. The compile
command then maps the isolation GTECH cells to an enable-type
level-shifter library cell.

2-21
If the Isolation Cell Is Inside the Power Domain
To insert buffer-type level shifter cells inside the power domain
hierarchy when the isolation cell is inside,
1. Put $isolate call in the RTL code where you want these cells
in the netlist.
2. Use the create_power_domain command to create the
power domains.
3. Run set_operating_conditions on the design.
4. Run set_operating_conditions on the power-down
hierarchy pins to ensure that the buffer-type level shifters are
inserted inside the block.
5. Run insert_level_shifters to put buffer-type level shifters
on the nonisolated paths inside the power domain.
6. Run any supported compile flow.
The GTECH isolation cells are mapped to the proper enable-type
level-shifter cell.
If the Isolation Cell Is Outside the Power Domain

To insert buffer-type level shifter cells on non-isolated paths outside
the power domain when the isolation cells are outside,
in the netlist.
power domains.

2-22
on the nonisolated paths outside the power domain.
The GTECH isolation cells are mapped to the proper enable-type
level-shifter cell.
Inserting Level Shifters When Enable-Type Level Shifter

Library Cells Are Not Available
The tool cannot insert level shifters on a net that is dont_touch due
to the presence of an isolation cell. To fix a voltage violation on such
a path, you must constrain the design such that the level shifter is
inserted in a different power domain. The following flows show you
how to set up the operating conditions to accomplish that.
If the Isolation Cell Is Outside the Power Domain

To insert buffer-type level shifter cells inside the power domain
hierarchy when the isolation cell is outside,
in the netlist.
power domains.
4. Run set_operating_conditions on the ports of the
power-down hierarchy pins to ensure that the buffer-type level
shifters are inserted inside the block.
5. Run insert_level_shifters.

2-23
If the Isolation Cell Is Inside the Power Domain
To insert buffer-type level shifter cells outside a power domain when
the isolation cell is inside,
in the netlist.
power domains.
on the nonisolated paths outside the power domain.
Top-Down Compile Example Script

Example 2-1 shows a working top-down compile script for a
multivoltage design that uses power domains.
Example 2-1 Top-Down Compile Script
## script for Design Compiler,version Y-2006.06

## 1) top down compile
## 2) use variable to enable ISO cell usage w/o power domain
## 3) add power domain
##########
########## Set the target library including 0.9/0.7V as well
########## as LS/Isolation library
##########
set target_library
" abcd90efghijwc.db abcd90efghijwc07.db
abcd90efghijwc07iso.db abcd90efghijwc0709+.db
abcd90efghijwc0907+.db "
#########################

2-24
########## read rtl and insert clock gating
##########
########## global clock gating is used to
##########
########## enable power reduction on CT
##########
########## bypass/ctrl are supposed to operate at
##########
########## 0.9V and will be shut-down after sensing
##########
########## 50 idle clock cycles. dma_fifo_row_top is designed
##########
########## to operate at 0.9V. top level logic will be operating
##########
########## at 0.7V
#########################
analyze -format verilog [ glob rtl/*.v]
set_clock_gating_style
-sequential_cell latch\
-minimum_bitwidth 2\
-num_stage 2\
-positive_edge_logic integrated:CKLNQHVTD1\
-neg integrated:CKLHQHVTD1\
-control_point before\
-control_signal scan_enable
elaborate dma_fifo
insert_clock_gating -global
report_clock_gating
hookup_testports -verbose
propagate_constraints -gate_clock
current_design dma_fifo
########## uniquify design is required only for MV design

##########
########## by default this is not required
##########
uniquify
link
########## Source the SDC constraints ##########

################################################
source -echo ./sdc/dma_fifo.sdc

2-25
###############################################################
########## Creating Power Domains
##########
create_power_domain TOP
create_power_domain BYPASS_PD \
-object_list bypass_row \
-power_down \
-power_down_ctrl sleep_out
create_power_domain CTRL_PD \
-object_list ctrl \
-power_down \
-power_down_ctrl sleep_out
create_power_domain ROW_TOP \
-object_list dma_fifo_row_top
########## Set The Operating Conditions

##########
########## dma_fifo_row_top @ 0.9V
##########
########## ctrl/bypass_row @ 0.9V Shut-Down
##########
########## top level logic @ 0.7V
##########
set_operating_conditions -max WC07COM\

-min BCCOM
set_operating_conditions -max WCCOM\

-min BCCOM\
-object_list [list bypass_row ctrl]
set_operating_conditions -max WCCOM\

-min BCCOM\
-object_list dma_fifo_row_top

-min BCCOM\
-object_list $bypass_row

-min BCCOM\
-object_list $dma_fifo_row_top

-min BCCOM\
-object_list $ctrl_outport

2-26
set_level_shifter_strategy -rule all
insert_level_shifter -verb -all_clock
check_mv_design -verbose -isolation -opcond_mismatches

-target_library_subset -connection_rules >
./$ReportDirpre_compile.check_mv.rpt
check_level_shifter -verbose >
./$ReportDir/pre_compile.check_ls.rpt
###########################
########## Top-down compile
##########
compile -scan
check_mv_design -verbose
check_mv_design -verbose -isolation -opcond_mismatches
-target_library_subset -connection_rules >
./$ReportDir/post_compile.check_mv.rpt
check_level_shifter -verbose > ./$ReportDir/post_compile.check_ls.rpt
exit
Design Compiler Bottom-Up Compile Flow

You can carry out the logic synthesis of a design using a bottom-up
compile strategy that employs multiple NLDM libraries. That is, you
can separately compile the blocks at different voltage levels, with
each block referencing the libraries appropriate to that block’s
voltage level. Within each block, the dc_allocate_budgets
command is used for RTL-level budgeting. To obtain accurate
top-level constraints, budgeting should be performed on unmapped
blocks with level shifters inserted. Figure 2-2 shows the logic
synthesis flow.

2-27
Note:
For a multivoltage design, if you are compiling a subblock that
has only one operating condition, use the -mv_mode switch in
dc_shell to ensure that the tool correctly handles multiple NLDM
libraries with same cell names.

2-28
Figure 2-2 Design Compiler Bottom-Up Flow
Read entire design

and uniquify the top level
Apply operating conditions

and constraints
Automatic insertion of
buffer-type level shifters
Allocate RTL budgets

(dc_allocate_budgets)
Compile individual blocks

using constraints
from previous step
Compile the top level
Physical Compiler flow

2-29
The steps for the flow shown in Figure 2-2 are
1. Read the entire design, link, and uniquify the top-level design.
2. Apply top-level constraints, including operating conditions and
target library subsetting.
3. Insert buffer-type level shifters to get accurate budgets.
4. Generate block-level RTL budgets by using the
dc_allocate_budgets -mode rtl command.
5. Compile individual blocks, using the constraints generated in
step 4.
6. Compile the top level.
Bottom-up Compile Script for Designs That Reference

Multiple Multivoltage NLDM Libraries
Based on the bottom-up compile flow outlined in the previous
sections, the script shown in Example 2-2 illustrates how to compile
the simple multivoltage design described in Chapter 1. This design
uses multiple NLDM libraries with level shifters in a separate library.
Note that the top level can include glue logic as well as Block1,
Block2, and level shifters.
The example script consists of an the initial mapping phase, in which

each block and the top level are mapped separately. This is followed
by an RTL-level budgeting phase, which is used to generate accurate
block-level constraints. Finally, the blocks are compiled using these
more accurate constraints, and then a top-down compile is done.

2-30
Example 2-2 Bottom-Up Compile Script for Designs That Reference
# Initial compile script for a multiple NLDM libraries.

#
# Invoke dc_shell-t or dc_shell -t -mv_mode
# Use -mv_mode switch to force MV design handling if any
# subblock has only one operating condition
#Setting Variables
set search_path ". ./lib ./src ./scripts $search_path "
##Library settings for a multiple NLDM library
set target_library "Nom1.db Nom2.db Nom3.db level_shifter.db"
set synthetic_library dw_foundation.sldb
set link_library "* Nom1.db Nom2.db Nom3.db \
level_shifter.db dw_foundation.sldb"
##Use these commands for a multiple NLDM library

set_target_library_subset -top "Nom1.db"
set_target_library_subset -object_list [get_cells {block1}] "Nom2.db"
##Reading entire design

read_verilog ./rtl/block1.v
read_verilog ./rtl/top.v
current_design top
link
uniquify
##Applying the constraints

source -echo -verbose top.constraint.tcl
##Setting Operating conditions

set_operating_conditions NOM_1V -library Nom1.db:Nom1
set_operating_conditions -object_list \
[get_cells block1] NOM_2V -library Nom2.db:Nom2
##inserting buffer-type level shifters.

check_level_shifter -verbose
insert_level_shifter
check_level_shifter -verbose
check_mv_design

2-31
# Performing RTL Budgeting on lower blocks
dc_allocate_budgets -mode rtl -write_script -file_format_spec \
./scripts/%C.dctcl -format dctcl [get_cells {block1 block2}]
##Block1 compile
current_design block1
link
## applying rtl budgets on block1
source -echo -verbose ./scripts/block1.dctcl
compile
##Block2 compile
current_design block2
link
## applying rtl budgets on block2
source -echo -verbose ./scripts/block2.dctcl
compile
# top-level compile
current_design top
link
compile
check_mv_design
quit
Automated Chip Synthesis Flow

You can run Automated Chip Synthesis with multiple NLDM libraries
to carry out an automated bottom-up compile of a multivoltage
hierarchical design. To support multivoltage designs, a number of
enhancements were implemented in Automated Chip Synthesis.
Principal changes include the following:
• The tool uses enhanced partitioning functionality to recognize

blocks with different voltages.
Based on user-defined operating conditions, the tool checks for
different voltages, automatically partitioning the design for
bottom-up compile using the Automated Chip Synthesis scripts.

2-32
• The tool starts up all partitions in their respective dc_shells in
multivoltage mode.
• The tool propagates operating conditions through the hierarchy.
All operating conditions generated by the
set_operating_conditions command are propagated to
the constraint file for each partition.
• The tool ensures that the target libraries are properly passed
down to the partitions. Each partition is compiled separately in a
bottom-up manner. The tool marks all subpartitions as
dont_touch before compiling any partition so that no actual
multivoltage compiles are necessary. This mimics the current
bottom-up compile behavior in Design Compiler.
• The tool ensures that if the operating condition for a block is
different from its parent, the block becomes a partition and is
compiled separately. This means that partitioning implicitly
supports multivoltage hierarchical definitions.
Note:
Use the set_target_library_subset command to
specify particular target libraries for individual blocks.
• Level-shifter insertion is on by default, but you can turn it off. To
do this, set the acs_insert_level_shifter to false.
• Automatic insertion of buffer-type level shifters when necessary.
The insert_level_shifters commands are automatically
added to the Automated Chip Synthesis scripts. For subblocks
operating at different voltages, buffer-type level shifters are
inserted in the netlist before compile. Operating condition rules
determine whether level shifters are placed inside or outside the
block netlist. The tool automatically accounts for level shifters in
the target library during insertion.

2-33
The default values of the level_shifter_strategy and
level_shifter_threshold variables are used. However,
you can change the values of these variables by using the
set_level_shifter_strategy and
set_level_shifter_threshold commands to change the
values of these variables. The tool propagates the values to the
individual partition constraint files.
Automated Chip Synthesis Flow Using Multiple

Multivoltage NLDM Libraries
At the top-level design, you must carry out the following steps in
dc_shell-t:
1. Start dc_shell-t.
2. Specify the multiple multivoltage NLDM libraries and the
level-shifter and isolation cell libraries in the link_library
variable.
3. Set operating conditions on the appropriate instances or designs.
You can set operating conditions on a design by changing the
current design to that design and setting it there.
4. Run the uniquify command if you have different instances of
the same block in various designs or instances with different
operating conditions.
5. (Optional) Set user-defined partitions by using the
set_compile_partitions command. You can use the
-level or -auto partitioning option, or you can specify the list
of designs to be partitioned. Example commands:
set_compile_partitions -level 1 -force
set_compile_partitions -auto -force
set_compile_partitions -design design_list -force

2-34
6. Set the target library for each partition that has its own operating
condition and must be mapped to a separate library from its
parent by using the set_target_library_subset
command. Example command:
set_target_library_subset -object_list [get_cells
{block1}] "Nom2.db"
set_target_library_subset -object_list [get_cells
{block2}] "Nom3.db"
7. Run the acs_compile_design command. This step is

equivalent to steps 1 and 2 in the preceding Design Compiler
bottom-up flow (see “Design Compiler Bottom-Up Compile Flow”
on page 2-27).
8. (Optional) For possible quality-of-results (QoR) improvement,
run the acs_refine_design command at the top level.
Note:
Module Compiler is not supported. Disable the Module Compiler
related features by setting the variable dw_prefer_mc_inside
to false in your .synopsys_dc.setup file.
Automated Chip Synthesis Script for Designs That

Reference Multiple Multivoltage NLDM Libraries
The script presented in Example 2-3 illustrates how to use
Automated Chip Synthesis to synthesize the multivoltage design
described in Chapter 1. This design uses multiple multivoltage
NLDM libraries.

2-35
Example 2-3 Automated Chip Synthesis Script for Designs That Reference
#Setting variables
set search_path " . $search_path ./lib ./rtl ./ddc "
##Library settings for a multiple NLDM library
set target_library "Nom1.db Nom2.db Nom3.db level_shifter.db"
set synthetic_library dw_foundation.sldb
set link_library "* Nom1.db Nom2.ddb Nom3.db \
level_shifter.db dw_foundation.sldb"
set clk_name "CLK"

set clk_period 10
##Read design
read_verilog ./rtl/top.v
current_design top
link
uniquify
##Constraints
source -echo -verbose top_constraints.tcl
##Setting Operating conditions

set_operating_conditions NOM_1V -library Nom1.db:Nom1
##Use these three commands for a NLDM library

acs_compile_design top
#optional step
#acs_refine_design top
quit

2-36
3
Physical Synthesis Phase 3
You use Physical Compiler to carry out the physical synthesis phase.
During this phase, the gate-level designs are read into memory
along with the floorplan. The multivoltage design steps are
• Insert buffer-type level shifters (if you did not insert them during
the logic synthesis phase in dc_shell)
• Create voltage areas and associate or align the logic hierarchies
(if you did not already do this in JupiterXT) and write the
information into the Milkyway database
• Perform placement in the voltage areas
• Optimize the design
The following sections show how to insert buffer-type level shifters
and create voltage areas, as well as optimize the design. (It is
assumed that you know how to use the physopt,
create_placement, and legalize_placement commands.)
3-1
• Invoking Physical Compiler With Multivoltage Capabilities

Enabled
• Creating Voltage Areas
• Voltage Area-Aware Capabilities
• Placing and Optimizing the Design
Chapter 3: Physical Synthesis Phase

3-2
Invoking Physical Compiler With Multivoltage
Capabilities Enabled
The default mode for Physical Compiler is XG mode with all
multivoltage features automatically enabled. At the system prompt,
enter
%: psyn_shell
The tool recognizes a design as a multivoltage design and utilizes

the multivoltage capabilities if any of the following conditions are
true:
• Instance-based operating conditions are specified

• Target library subsetting is used
• If the -mv_mode switch is specified with dc_shell-t (switch is
needed only when you want to force the tool to treat a design that
does not meet either previous condition as a multivoltage design)
If none of these conditions hold, the tool assumes the design is not
a multivoltage design.
Recall that k-factors are not supported for multivoltage designs and
are ignored if present in the libraries.
Creating Voltage Areas

A voltage area is a placement area for one or more logic partitions
operating at the same voltage. The cells of the logic partition are
associated with the partition’s voltage area and are constrained to
placement within that area.
Invoking Physical Compiler With Multivoltage Capabilities Enabled

3-3
Voltage areas can be created and the hierarchies aligned in
JupiterXT (or Astro) and stored in the Milkyway database, or they can
be created in Physical Compiler.
In Physical Compiler, you can define voltage areas at any level of a

logic hierarchy, including logically nested voltage areas; that is, you
can define a voltage area on any logic subhierarchy of a hierarchy
belonging to a different voltage area.
Note:
A nested voltage area is a logical construct. The physical
floorplan does not support physically nested voltage areas.
Therefore, for logically nested voltage areas, you must define the
physical voltage areas using disjoint rectangular and rectilinear
shapes in such a way that no physical shape is embedded within
or overlapping another physical shape (Handling Logically
Nested Voltage Areas).
In addition, Physical Compiler checks the operating condition voltage

of each module against the voltage area specification to ensure that
all modules inside the voltage area operate at the correct voltage.
Voltage areas are specified manually or derived automatically by

Physical Compiler on the basis of row types and site types. Both
rectangular and rectilinear voltage areas are allowed. Voltage areas
can consist of disjoint rectilinear and rectangular shapes, but it is
recommended that you avoid using disjoint structures – except in the
case of logically nested voltage areas – because of possible QoR
impact.
The logic hierarchies are assigned to specific voltage areas when

you create or update these voltage areas. Care must be taken to
align the hierarchies correctly.

3-4
Physical Compiler derives a default voltage area for placement of
cells not assigned to other voltage areas. The default voltage area
can contain top-level leaf cells and buffer-type level shifters, as well
as the blocks.
Level shifters and isolation cells can have site heights that differ from
the standard cell site height by either integer multiples or noninteger
multiples. Physical Compiler supports the placement of both types.
To enable noninteger multiheight sites, you must set the variable
physopt_heterogeneous_site_array to true. (The default is
false.)
Note that you need to define appropriate site arrays for these
nonstandard cell heights. For more information on defining site
arrays, see the Physical Compiler User Guide, Volume 1.
Figure 3-1 shows a multivoltage design divided into several voltage

areas.
Figure 3-1 Multivoltage Design With Several Voltage Areas
Rb
Ra
BB
Rd
Rc

3-5
In this design, the floorplan has four voltage areas: Ra, Rb, Rc, and
Rd. The default voltage area is Rd. Each voltage area has a
corresponding logic partition, A, B, C, or D, that aligns with its
respective voltage areas. A hard bound can be defined inside a
voltage area, but not across voltage areas. In this example, a hard
bound, BB, is defined inside voltage area Ra.
Optionally, guard bands can be specified for some or all voltage

areas to prevent shorts. Guard bands define hard keepout margins
surrounding the voltage areas in which no cells, including level
shifters and isolation cells, can be placed. Guard bands can be
defined when creating voltage areas automatically or when updating
the voltage areas.
Figure 3-2 shows a floorplan similar to Figure 3-1 but with guard
bands protecting voltage areas Ra and Rc.
Figure 3-2 Multivoltage Design With Several Voltage Areas and Guard
Bands
Rb
Ra
BB
Rd
RcRc

3-6
Creating Voltage Areas Manually
Voltage areas can be manually created by using the
create_voltage_area command. With this command you
specify the exact coordinates of the voltage area. You also specify
the list of cells to be associated with a given voltage area. For more
information on how to use this command, see the man pages and the
scripts provided in Example 3-1 on page 3-8 and Example 3-3 on
page 3-21.
Note:
You can specify guard bands when manually creating voltage
areas by using the -guard_band_x and -guard_band_y
options with the create_voltage_area command. See
“Including Guard Bands With the Voltage Areas” on page 3-10.
After you have defined a voltage area and associated cells, you can
add or remove cells from the voltage area by using the
update_voltage_area command.
Note the following limitations:
• Overlapping voltage areas are not supported.

• All voltage area geometries must be mutually exclusive.
• An error occurs if the voltage area defined when you use the
-coordinate option is too small for all the cells to fit into it.

3-7
The script in Example 3-1 shows you how to create voltage
areas manually.
Example 3-1 Manual Voltage Area Specification

# Block1 is VoltageArea1 and Block2 is VoltageArea2 #
##
create_voltage_area -coordinate {...} -name VoltageArea1
update_voltage_area -name VoltageArea1 Block1
create_voltage_area -coordinate {...} -name VoltageArea2
update_voltage_area -add -name VoltageArea2 Block2
report_voltage_area -all
##
Deriving Voltage Areas Automatically

Voltage areas can be automatically derived from site-type or
row-type specifications. First, you use the set_row_type
command to set a row-type attribute and assign it either to all the
rows of a site (-site option) or to the rows you name in a list. Then
you use the set_cell_row_type command to bind a list of cells
to the specified row-type attribute. (The cells must be logic
hierarchies with no row-type attribute already set on them.)
After the row-type attribute and cell-row-type (site or list of row

names) are set, you enter the derive_voltage_area command
to derive rectilinear or rectangular voltage areas. The derived voltage
areas comprise rows of cells with a given row-type attribute. It is
recommended that each derived voltage area not be disjoint. The
size of a voltage area must be greater than the sum of the areas of
all the placed cells in the hierarchy.

3-8
Note:
You can specify guard bands when automatically deriving voltage
areas by using the -guard_band_x and -guard_band_y
options with the derive_voltage_area command. See
“Including Guard Bands With the Voltage Areas” on page 3-10.
After you have defined a voltage area and associated cells, you can
add or remove cells from the voltage area by using the
update_voltage_area command.
The script in Example 3-2 shows you how to derive voltage areas
automatically.
Example 3-2 Automatic Voltage Area Specification

# Create a row type for each row #
# ROW0 to ROW9 is type 1 and ROW10 to ROW20 is type 2 #
##
for {set i 0} {$i < 10} {inc i 1} {
set_row_type -type 1 ROW$i
for {set i 10} {$i < 20} {inc i 1} {
set_row_type -type 2 ROW$i
# Bind Logic hierarchy to different ROWs #

##
set_cell_row_type -type 1 Block1
set_cell_row_type -type 2 Block2
derive_voltage_area
Note:
The default names for the voltage areas derived with the
derive_voltage_area command are formed by using the first
hierarchical cell name found in the set_cell_row_type
command and appending _region to it. Thus, in the preceding
Example 3-2, the derived voltage area names are
Block1_region and Block2_region.

3-9
Updating Voltage Areas in a Design
Once you have created a voltage area and associated hierarchical
cells with the voltage area, you can use the
update_voltage_area command to add or remove cells from a
specified voltage area. You can use the get_voltage_area
command instead of explicitly specifying voltage area names. By
adding or removing cells, you can adjust the utilization of the voltage
area. However, you might prefer to change the size of the voltage
areas and keep the utilization the same.
Note:
You can specify guard bands when updating voltage areas by
using the -guard_band_x and -guard_band_y options with
the update_voltage_area command. See the next section,
“Including Guard Bands With the Voltage Areas.
Including Guard Bands With the Voltage Areas

You can use guard bands to ensure that no shorts occur at the
boundaries of the voltage areas. Guard bands define hard keepout
margins surrounding the voltage areas. No cells, including level
shifters and isolation cells, can be placed within the guard band
margins.
For example, using guard bands is recommended in the case when

the rows are the same for all the voltage areas. The guard bands
guarantee the cells in different voltage areas are separated so that
power planning does not introduce shorts.

3-10
You can include guard bands when you automatically derive or
manually create the voltage areas, or when you update a voltage
area. You generate guard bands by using the -guard_band_x and
-guard_band_y options with any of the following three commands:
• derive_voltage_area -guard_band_x x_width

-guard_band_y y_width
• create_voltage_area -guard_band_x x_width
(user input values defining a voltage area)
• update_voltage_area -guard_band_x x_width
(user input values specifying voltage area
and updating hierarchical cells list)
Figure 3-3 shows two voltage areas with guard bands of different
widths. For both voltage areas, the x-width is 10 and the y-width is
20. Notice the x-width defines the width of the vertical part of the
guard band, and the y-width defines the width of the horizontal part.

3-11
Figure 3-3 Two Voltage Areas With Guard Bands
Guard bands
Net2 Net3
Net1 Net4
Voltage area 1 Voltage area 2
(1.08 v) (1.50 v) Net5
guard_band_x = 10 Level shifter
guard_band_y = 20
In the Physical Compiler graphical user interface (GUI), any voltage

areas are outlined. Spaces or margins between voltage areas
indicate the presence of guard bands.
When generating guard bands by using the

create_voltage_area, derive_voltage_area, or
update_voltage_area commands, you should be aware of the
following conditions:
• If some coordinates of a voltage area are defined outside the

core area, the command does not generate the voltage area and
issues these warning and error messages:
Warning: Given coordinates are out of the core area.
(PSNYN-111)
Error: Failed to create voltage area <voltage_area_name>.
• If a voltage overlaps an existing one, the command does not

generate the voltage area and issues these error messages:

3-12
Error: Overlapping with voltage area <voltage_area_name>
Error: Failed to create voltage area <voltage_area_name>.
• If a guard band of a voltage area overlaps another voltage area,

the command generates the guard band and issues this
warning message:
Warning: Newly created voltage area <voltage_area_name>
with guard band margins x = <x_width> and y = <y_width>
is overlapping with the following voltage areas
<list of existing voltage areas>
• The x (y) guard band width applies to both the left and right (top
and bottom) side of a voltage area.
• The Physical Compiler GUI does not highlight guard bands.
• Overlapping guard bands are allowed and do not generate
warning messages.
• A guard band that lies outside the core area does not generate a
warning message.
Handling Logically Nested Voltage Areas

Voltage areas can be nested with respect to the logic hierarchy, but
they cannot be physically nested. You resolve logically nested
voltage areas into separate physical areas by using the methods
described in the preceding sections to create several voltage areas,
some of which would consist of abutted rectangular or rectilinear
shapes, as needed. Each abutted shape must not overlap, intersect,
or be embedded within any other shape of the voltage area that it
belongs to, nor with the shapes of any other voltage area. A
composite voltage area can appear to violate this rule, when it is, in
fact, a set of properly abutted, separate rectangular or
rectilinear shapes.

3-13
Figure 3-4 shows two examples of logically nested voltage areas and
shows how you might resolve them into physically abutted, separate
areas. In these two examples, the logically nested voltage areas are
labeled VA1 and VA2.
Figure 3-4 Examples of Physically Resolved Nested Voltage Areas
VA1
VA1_t
VA2
VA1_l VA2 VA1_r
VA1_b
VA1 VA2_r
VA1
VA2 VA2_l
In the first example, you create a voltage area VA1 that consists of
the four sequentially abutted rectangles VA1_b, VA1_l, VA1_t, and
VA1_r with a central, rectangular gap. Voltage area VA2 is a simple
rectangle that “fits” into this gap. The following commands would
create the two voltage areas:
create_volatage_area -name VA1 -coord {

10 10 150 30
10 30 70 80
10 80 150 120

3-14
140 30 150 80}
create_voltage_area -name VA2 -coord {

70 30 140 80}
In the second example, you create two voltage areas. VA1 is a single,
eight-sided rectilinear shape, and VA2 consists of two disjoint
rectangles, VA2_l and VA2_r.
These examples do not represent the only way you might resolve the
logically nested voltage areas into unnested physical areas.
Removing Voltage Areas From a Design

Use the remove_voltage_area command to remove all voltage
areas or specified voltage areas from the design. Any move bound
belonging to a removed voltage area is also removed. If you remove
a logically nested voltage area, the subhierarchy logic inherits the
voltage area properties of the parent hierarchy.
Reporting on the Voltage Areas of a Design

Use the report_voltage_area command to obtain information
about existing voltage areas. The report includes voltage area name;
the list of hierarchical cells associated with the voltage area; and the
voltage area geometry, area, utilization, and guard band information
(if guard bands are present). For more information about reports, see
Appendix B, “Multivoltage Reports.”

3-15
Checking Isolation Cells
Use the check_isolation_cells command to check for the
presence of isolation cells in the mapped logic hierarchies (blocks)
or the voltage areas associated with the power domains of the
design. This command provides data about the isolation cells
present in the design. For more information on this command, see
Appendix B, “Multivoltage reports,” and the
check_isolation_cells man page.
Voltage Area-Aware Capabilities

The physopt command is voltage area aware, which means that it
can carry out placement and optimization steps in multivoltage
designs. Important capabilities include
• Automatic high-fanout synthesis

• Virtual hierarchy routing
• Maximum net length optimization
• Voltage area-based optimization
Automatic High-Fanout Synthesis

This capability is part of the physopt command. Buffer trees are
built with dedicated subtrees for the fanouts in each voltage area. In
particular, automatic high-fanout synthesis (AHFS) selects buffers
according to the associated operating condition. Buffers are inserted
and placed correctly.

3-16
For information on automatic high-fanout synthesis, see the Physical
Compiler User Guide, Volume 1.
Virtual Hierarchy Routing

The virtual route estimator takes the presence of voltage areas into
account when invoking the run_router command. You can disable
this feature by setting the variable
physopt_enable_voltage_aware_route_estimation to
false.
When this feature is enabled, the virtual route estimator observes the
following constraints:
• Virtual routes for nets connecting cells within a voltage area do

not go outside the voltage area.
• Virtual routes for nets connecting cells outside a voltage area
detour around the voltage area.
• Virtual routes for nets crossing a voltage area do not zig-zag in
and out of the voltage area (the number of boundary crossings
are minimized).
Also, routing driven synthesis (for example, max_net_length) use
voltage area-aware routing.
Using voltage area-aware virtual routing can greatly improve the

global routing correlation between Physical Compiler and Astro.
For information on the run_router command and virtual route

estimation, see the Physical Compiler User Guide, Volume 1.

3-17
Interface Logic Model Hierarchical Flow With Voltage
Areas
Interface logic models (ILMs) are supported in multivoltage design
optimization flows. ILMs are used to model the interface logic of the
mapped lower-level blocks of a hierarchical design. In general, the
noninterface logic is excluded from the model, although you can
specify options that allow certain noninterface nets and cells to be
included. (For detailed information on ILMs see the Interface Logic
Model User Guide.)
The following relationships between voltage areas and ILMs are

supported:
• A voltage area of the top-level design can contain ILMs. The

combined physical area of the ILMs must be less than or equal to
the area of the voltage area.
• An ILM at the top level can contain voltage areas.
In both cases, the operating conditions applied to the block
(set_operating_conditions command) before you create the
ILM for the block (create_ilm command) are not visible at the top
level. At the top level, use the propagate_constraints
command with the -operating_conditions option to propagate
the operating conditions placed on the ILM design, cells, ports, and
hierarchical pins inside the ILM.
Note that propagation of voltage areas inside an ILM is not

supported. Therefore, you must propagate the operating conditions
of the hierarchical cells within the voltage area by using the
propagate_constraints command or reapply the operating
conditions from the top level.

3-18
The region utilization calculation skips the placeable area or cell area
occupied by any ILM contained in the region. That is, only the cell
area occupied by the top-level cells and the actual placeable area
(region area minus the area occupied by the ILMs) are used in the
calculation. If the entire region is occupied by ILMs, the placeable
area for the top-level cells is zero, and region utilization is reported
as zero.
Level shifters are kept only if they are an actual part of the interface
logic. Those level shifters past the first registers of a block are not
retained. For level shifters that become part of the ILM, the leaf cells
connected to the input and output nets of the level shifter are also
retained, as well as the nets. You can use the
check_level_shifter command to determine if any output nets
of the level shifters are floating.
Multivoltage Relative Placement Capability

You can use relative placement with multivoltage designs.
Relative placement is most often applied to physical datapaths. It

provides a way for you to create structures in which you specify the
relative column and row positions of instances with respect to each
other. During placement and legalization, these structures are
preserved and the cells in each structure are placed as a single
entity. (For detailed information on relative placement see the
Physical Compiler User Guide, Volume 1.)
After you group the relevant cells of a voltage area into an relative
placement grouping, you can place them as a single structure within
the voltage area. The flow is identical to a typical relative placement
flow, and the entire relative placement feature set is available.

3-19
However, you should be aware of these limitations:
• An relative placement group should not span voltage areas. If it

is necessary to span voltage areas, break the relative placement
group into multiple relative placement groups, each contained
within its voltage area.
• In situations where a relative placement group is placed very
close to a voltage area boundary, legalization might place part of
the group outside the multivoltage area. When this happens, the
group is broken in a way that respects the voltage area
constraint.
Maximum Net Length Optimization

The maximum net length optimization carried out by the physopt
command takes into account the presence of voltage areas,
basically routing around them. Routes for nets connecting two cells
within a voltage area stay inside the voltage area, and routes for nets
crossing into a voltage area do not excessively zig-zag in and out of
the voltage area.
Voltage Area-Based Optimization

Cell placement and buffer optimization is one-pass voltage area
aware. When the tool buffers a net that crosses voltage areas, the
net is divided into multiple segments, each of which is confined
within a single voltage area, and buffering is confined to the
segments.
Tie-high and tie-low cells are handled consistently with respect to the
way they are handled in Astro; that is, the connections established in
Astro are preserved in Design Compiler and Physical Compiler.
Constant signals are fed to the correct cells for a given voltage area.

3-20
Placing and Optimizing the Design
The last step in the multivoltage design flow is to place the cells and
optimize the design. The tool places level shifters and isolation cells
near the boundaries of defined voltage areas if the library attribute
is_level_shifter or is_isolation_cell is set to true. No
buffering is done between the placed level shifter and the edge of the
voltage area.
Example 3-3 provides an example script with all the steps required
in the physical synthesis phase of the multivoltage design flow
described in Chapter 1. This design uses multiple nonlinear delay
model (NLDM) libraries.
Example 3-3 Physical Synthesis Example Script for a Multivoltage Design
## Physical compiler script for multi_voltage designs

## Invoke pc_shell
## set physopt_enable_voltage_area_optimization true
set search_path ". ./lib ./src ./db ./scripts $search_path "
set target_library "Nom1.db Nom2.db Nom3.db.db level_shifter.db"
set link_library "* ${target_library}"
set physical_library " "
##Starting 2005.09, PC is FRAM based, hence it always needs

## a milkyway library structure
##If you want to use the old pdb format, set this variable
##to true: "use_pdb_lib_format"
set mw_reference_library "MWRL/Nom MWRL/level_shifter"

set mw_design_library MW_TOP
set mw_logic1_net VDD
set mw_logic0_net VSS
set_mw_design $mw_design_library
read_ddc ./ddc/top.final.ddc
### If you want to read milkyway created by DC
### read_milkyway dc_compile
###
current_design top
Placing and Optimizing the Design

3-21
link
##Read in the Physical pin locations.

read_pdef ./top.pdef
link
link_physical
## Note : No need to re-create voltage areas if they were previously

## created in JuptierXT and you import the milkyway written by JupiterXT
## Creating voltage areas manually

create_voltage_area -name RG_MV_2v -coordinate {300 20 520 560} block1
create_voltage_area -name RG_MV_3v -coordinate {20 20 280 560 } block2
#optional
#create_default_voltage_area
source -e -v ./ddc/top.final.wscr
create_placement -timing
check_legality
physopt -inc
report_change_list
change_names -rules verilog -hierarchy
write -f verilog -hier -o ./ddc/pc_placed_gates.v
write_pdef -output ./ddc/pc_placed_gates.pdef
write_script -h -output ./ddc/pc_placed_gates.wscr
write_milkyway -out pc_placed_gates
quit

3-22
A
Using Buffer-Type Level Shifters A
This appendix provides further information about buffer-type
level-shifter cells and how to use them in the following sections:
• General Properties of Buffer-Type Level Shifters

• Buffer-Type Level-Shifter Insertion Flow
• Optionally Setting Buffer-Type Level-Shifter Strategy
• Level-Shifter Threshold (Automatic and User-Specified)
• Checking the Design for Level Shifters and Level-Shifter
Violations
• Removing Level Shifters
• Inserting Buffer-Type Level Shifters
• Placing Level Shifters
A-1
General Properties of Buffer-Type Level Shifters
A buffer-type level-shifter cell is modeled as a buffer with the
following properties:
• Two power supplies: a master (or primary) supply and a

secondary supply
• Input and output pin voltages that are different
• PVT operating conditions set on the output side of the cell
(otherwise, Design Compiler creates new operating conditions
under-the-hood that are not written out and passed to the rest of
the flow)
Buffer-type level shifters are used to connect drive and load pins
operating at significantly different voltages. The following commands
are used to manage the level shifters in your design:
• check_level_shifters – Checks the design for existing level

shifters, including enable-type level shifters, and reports
violations; you can use this command at any point in the flow.
• insert_level_shifters – Inserts only buffer-type level
shifters to accommodate voltage mismatches on nets, according
to level shifter strategy and threshold settings. This command
can be used anywhere in the flow, but it is usually best to run the
command prior to logic synthesis.
• set_level_shifter_strategy – (Optional) Sets the
strategy used for adjusting voltage levels in the design. Set
before using the insert_level_shifters command unless
you want to use the default strategy (-all).
Appendix A: Using Buffer-Type Level Shifters

A-2
• set_level_shifter_threshold – (Optional) Sets the
minimum allowed voltage difference between a source and sink,
beyond which voltage differences are adjusted by insertion of
level shifters. Set before using the insert_level_shifters
command unless you want to use the default threshold (0
threshold voltage difference and 0 percentage difference).
• remove_level_shifters – Removes all level shifters in a
design except those marked with the dont_touch attribute. Use
this command as needed to correct or redefine the use of level
shifters in the design.
Voltage mismatches requiring buffer-type level shifter insertion are
determined automatically by the tool. You override the default
voltage mismatch condition by using the
set_level_shifter_threshold command.
Note, however, that the required level shifters are inserted only after
you issue the insert_level_shifters command.
Both voltage step-up and voltage step-down buffer-type level shifters

are used. For example, in the case where design blocks are working
on two different voltage rails, at least two types of level shifters are
required: one that shifts the level mismatch from the lower voltage to
the higher voltage (step-up), and one that shifts from the higher
voltage to the lower voltage (step-down). You can specify the kind of
buffer-type level shifter you want by using the
set_level_shifter_strategy -rule command. The default
rule is -all, which allows both types to be used.
General Properties of Buffer-Type Level Shifters

A-3
Buffer-Type Level-Shifter Insertion Flow
The buffer-type level-shifter insertion flow has the following steps:
Note:
Steps 1 through 4 should be performed before optimization
(compile or physopt command), and steps 5 and 6 after.
1. Check design for buffer-type level shifters and level-shifter

violations (check_level_shifters command).
2. Insert buffer-type level shifters (insert_level_shifters
command).
3. Check design again for buffer-type level shifters and level-shifter
violations (check_level_shifters command). Repeat step 2
if necessary.
4. Compile the design in Design Compiler.
5. Import voltage area information from Jupiter XT or create the
voltage areas in Physical Compiler and associate logic modules
with the voltage areas (create_voltage_area or
set_row_type, set_cell_row_type,
derive_voltage_area, and update_voltage_area
commands).
6. Place cells and level shifters (both types), and optimize the
design (physopt command or create_placement and
legalize_placement commands).
These steps are described in greater detail in the following sections.

A-4
Optionally Setting Buffer-Type Level-Shifter Strategy
If you do not explicitly set a level-shifter strategy before inserting or
checking buffer-type level shifters, the default strategy is -all,
which allows the use of both step-up and step-down buffer-type
level shifters.
However, if you want to specify the level-shifter strategy rule, use the
set_level_shifter_strategy -rule command. You can set
the rule to allow only step-up buffer-type level shifters
(low_to_high option), or only step-down buffer-type level shifters
(high_to_low option), or both (-all option). The default option is
-all, which is equivalent to not using the command.
For example, to specify only step-down buffer-type level shifters,

enter
psyn_shell-t> set_level_shifter_strategy -rule high_to_low
This command is optional.
Level-Shifter Threshold (Automatic and User-Specified)

A level-shifter threshold strategy must be in force before inserting or
checking buffer-type level shifters. Two methods for defining the
threshold strategy are available to you:
• Use the tool’s automatic threshold capability to determine voltage

mismatched nets that require buffer-type level-shifter insertion
(does not require user input).
• Specify the threshold conditions for such nets by using the
set_level_shifter_threshold command.
Optionally Setting Buffer-Type Level-Shifter Strategy

A-5
Automatically Determined Level-Shifter Threshold
The tool can automatically determine level-shifter thresholds if the
target library cells have the following attributes (usually described by
equations involving the rail voltages, for example, VDD1+0.5):
• Vih – Lowest input voltage for logic 1
• Vil – Highest input voltage for logic 0
• Vimax – Maximum input voltage for logic 1
• Vimin – Minimum input voltage for logic 0
• Voh – Lowest output voltage for logic 1
• Vol – Highest output voltage for logic 0
• Vomax – Maximum output voltage for logic 1
• Vomin – Minimum output voltage for logic 0
These voltage parameters are used to determine output and input

voltage bands (ranges) for both logic 1 and logic 0. For logic 1, the
input voltage band is (Vimax-Vih) and the output voltage band is
(Vomax-Voh). Similarly, for logic 0, the input voltage band is (Vil-Vimin)
and the output voltage band is (Vol-Vomin).
Therefore, for any pair of driver and load pins, if the output voltage
band of the driver pin is completely overlapped (contained within) the
input voltage band of the load pin, no level shifter is required. This
criteria holds for both logic 1 and logic 0.
Conversely, a sufficient voltage difference between the driver and

load pins exists and buffer-type level-shifter insertion is required if
any of the following conditions hold:

A-6
• Driver pin Vomax > Load pin Vimax
• Driver pin Vomin < Load pin Vimin
• Driver pin Voh < Load pin Vih
• Driver pin Vol > Load pin Vil
For any of these four conditions, the driver voltage band does not fall
completely within the load voltage band, and buffer-type level shifters
are needed.
Note:
You can override this automatic threshold determination by using
the set_level_shifter_threshold command.
User-Specified Level-Shifter Threshold

You use the set_level_shifter_threshold command to
explicitly specify the minimum voltage difference beyond which the
voltage is to be adjusted by use of a buffer-type level shifter. Use the
-voltage option to specify an absolute voltage difference between
source and sink voltages, or use the -percent option to specify the
percentage by which the source and sink voltages must differ.
You can specify both threshold options. In this case, buffer-type level
shifters are inserted when either threshold condition is met. For
example, to specify both a 0.5 voltage threshold and a 5 percent
threshold, enter
psyn_shell-t> set_level_shifter_threshold -voltage 0.5 -percent 5
Note:
The percentage is computed as 100 x (absolute value of the
difference between the driver voltage and the load voltage)/driver
voltage.
Level-Shifter Threshold (Automatic and User-Specified)

A-7
Checking the Design for Level Shifters and
Level-Shifter Violations
You should check the status of any existing level shifters in the
design before attempting to insert level shifters. Use the
check_level_shifters -verbose command to check all level
shifters, including hand-instantiated enable-type level shifters, and
level-shifter nets against any specified level-shifter strategy and
threshold. Note that the command checks only cells for which the
library attribute is_level_shifter is set to true.
If you have not previously issued the

set_level_shifter_threshold command, the tool uses the
automatic threshold capability when checking level-shifter status. If
you have not used the set_level_shifter_strategy -rule
command, the rule defaults to -all during checking.
In addition to listing all the level shifters in the design, the

check_level_shifter command also lists driver/load pins and
their voltages, and flags the following level-shifter cell violations:
• Incorrect operating condition – The level shifter does not have the
correct annotated operating condition.
• Wrong level shifter – The given level shifter cannot be used to
shift the voltage levels as needed.
• Multiple fanin voltages – The fanins of the level shifter are not all
at the same voltage level.
• Multiple fanout voltages – The fanouts of the level shifter are not
all at the same voltage level.
• Not required – The level shifter is not required according to the
defined strategy and/or threshold.

A-8
All nets that cross boundary hierarchies with different operating
conditions are checked for supply voltage, level-shifter strategy, and
level-shifter threshold.
For an example of a check_level_shifters report, see

Appendix B, “Multivoltage Reports.“
Removing Level Shifters

You can use the remove_level_shifters command to remove
buffer-type level shifters only. Note that you cannot selectively
remove level shifters if you manually set a dont_touch attribute on
the level shifters.

You issue the insert_level_shifters command to insert
buffer-type level shifters in the current design. Command options
include -preserve, -all_clock_nets, -clock_net,
and -verbose.
Level shifters are inserted on nets where significant voltage

differences occur between drive pins and load pins. The voltage
differences are determined either automatically by the tool or
according to voltage threshold conditions you define by using the
set_level_shifter_threshold command. Also, you can
accept the default level-shifter strategy, which allows both step-up
and step-down buffer-type level shifters, or you can use the
set_level_shifter_strategy command to control the kind of
Removing Level Shifters

A-9
buffer-type level shifter to be used. This command automatically
assigns dont_touch attributes to the nets connecting ports and
buffer-type level shifters.
Level shifters already present in the design are automatically

preserved. However, if you run the tool in DB mode, use the
-preserve option to keep existing level shifters (both enable-type
and buffer-type) in the netlist. In DB mode, if you do not use this
option, any existing level shifters without a dont_touch attribute
are automatically removed before new level shifters are inserted.
The command insert_level_shifters -preserve does not
add any new level shifters.
Although you can insert buffer-type level shifters at a number of

points in the logic synthesis-physical synthesis flow, it is
recommended that you insert them early in the flow—preferably
before logic synthesis. The latest they should be inserted is before
you run the physopt command.
By default, level shifters are not inserted on clock nets. Use the
-all_clock_nets or -clock_net list_of_clock_nets
option if you want level shifters inserted on clock nets.
To obtain information about all the level shifters available in the target
libraries, use the -verbose option. The information reported
includes library name and type, level-shifter cell name, operating
condition(s), input and output voltages, process ID, temperature, and
tree type. Also, the number of inserted level shifters is reported.

A-10
In general terms, the steps Design Compiler or Physical Compiler
follows to insert buffer-type level shifters into voltage-mismatched
nets are as follows:
• Identifies nets in the design with voltage mismatches that meet

the automatically determined or user-defined threshold.
• Analyzes the target library for available buffer-type level shifters,
given the specified level shifter rule.
Note:
Design Compiler and Physical Compiler access only the target
library buffer-type level-shifter cells that are marked with the
library attributes specified in the Synopsys Liberty library
model.
• Instantiates the proper buffer-type level shifter, and sets a
dont_touch attribute on both the level shifter and the
port-to-level-shifter nets.
• Instantiates buffer-type level shifters in clock nets as needed only
if the -all_clock_nets or the -clock_net option is specified.
In general, the buffer-type level shifters are inserted between the
blocks. This is the case when the operating voltage is set on the
instance and not on any of its ports. However, if an operating voltage
different from the block operating voltage is set on a port of the block,
the buffer-type level shifter for that port is inserted inside the block.
The operating voltages are annotated on the instances or their

hierarchical ports by using the set_operating_conditions
command for blocks. To insert a buffer-type level shifter inside a
block, use the set_operating_conditions -object_list
command to provide a port list and operating voltage setting for
these ports that is different from the block voltage.

A-11
Note:
The -object_list option for these commands is available only
in the psyn_shell multivoltage mode.
Figure A-1 shows an example of buffer-type level-shifter insertion at

both the top level for a block port that has the default block voltage
and within a block for a port that is set at the top-level voltage.
Figure A-1 Buffer-Type Level Shifter Insertion at the Top Level and
Block Level
Port voltage same as block voltage
Buffer-type level shifter
Top: 2V
Block1: 2V Block2: 3V
Port voltage set to top-level voltage
Buffer-type level shifter

A-12
Note:
Buffer-type level shifters are marked with the dont_touch
attribute and therefore are not optimized as part of the physopt
synthesis phase.
The script in Example A-1 shows you how to insert buffer-type level
shifters between blocks at the top level for a design with two
subblocks. Block1 and the top-level design are at 2 volts. Block2 is at
3 volts.

A-13
Example A-1 Example Script for Inserting Buffer-Type Level Shifters
Between Subblocks at the Top Level
set target_library "Nom2.db Nom3.db"
set link_library "* Nom2.db Nom3.db"
read_db top_final.db
current_design top
link
#Setting operating conditions#

set_operating_conditions -object_list [get_cells U1] Nom2 #Related to Block1#
set_operating_conditions -object_list [get_cells U2] Nom3 #Related to Block2#
set_operating_conditions -object_list [get_cells U3_top] Nom2 #Pseudo Top level#
set_operating_conditions Nom2 #Related to Top level#
#Setting level shifter strategy, threshold and#

#Inserting buffer-type level shifter#
set_level_shifter_strategy -rule all #"all" is the default#
set_level_-shifter_threshold -voltage 0.05 #default threshold is 0#
insert_level_shifters
check_level_shifters -verbose
write -format db -hier -output top_final_LS.db top
The script in Example A-2 shows you how to insert buffer-type level
shifters within Block2 for a design with two subblocks. Block1 and the
top-level design are at 2 volts. Block2 is at 3 volts.
Example A-2 Example Script for Inserting Buffer-Type Level Shifters

Inside Block2
set target_library "Nom2.db Nom3.db"
set link_library "* Nom2.db Nom3.db"
set synthetic_library "dw_foundation.sldb"
read_verilog top_final.v
#Setting operating conditions#
set_operating_conditions -object_list [get_cells U1] Nom2 /*Related to Block1*/

set_operating_conditions -object_list [get_cells U2] Nom3 /*Related to Block1*/
set_operating_conditions -object_list [get_cells U3_top] Nom2 #Pseodo Top level#
set_operating_conditions Nom2 /*Related to Top level*/
set_operating_conditions -object_list [get_pins -of_objects U2] Nom2

current_design top
link

A-14
#Setting level shifter strategy, threshold and#
#Inserting buffer-type level shifter#
set_level_shifter_strategy -rule all
set_level_shifter_threshold -voltage 0.05
insert_level_shifters
check_level_shifters -verbose
write -format db -hier -output top_final_LS.db top
Placing Level Shifters

Level shifters (both types) can be placed at regular sites
(single-height cells) or at special sites (multiheight cells) with multiple
power rails. For regular sites, you are responsible for connecting
secondary power to the level shifters.
If special sites are needed for level shifters, these sites must be
instantiated in the floorplan at locations where these level shifters
could be placed. Such sites should usually be defined along the
voltage area boundaries. They can overlap with the base site array.
Level-shifter placement is performed when you run the physopt

command or when you issue the create_placement and
legalize_placement commands. If the is_level_shifter
library attribute is set to true for the level shifters, the tool attempts to
place the level shifter cells at legal sites nearest the voltage area
boundaries. (This same placement process holds for isolation cells
that have their attribute is_isolation_cell set to true.)
Placing Level Shifters

A-15
A-16
B
Multivoltage Reports B
For multivoltage designs, reporting functions are enhanced to
include additional information so that you can carry out basic checks
to verify your input specifications.
The following commands are introduced:
• report_operating_conditions
• delete_operating_condition
• report_target_library_subset
• check_mv_design
• check_target_library_subset
• check_level_shifters
• check_isloation_cells
B-1
These commands are enhanced:
• report_cell
• check_design
• report_voltage_area
• report_timing
• report_delay_calculation
• report_hierarchy
For more information on the following commands, see the
appropriate man pages.
Appendix B: Multivoltage Reports

B-2
report_operating_conditions
This report displays all operating conditions currently defined in the
target and linked libraries as well as any operating conditions you
created using the create_operating_condition command.
Typical output from the report_operating_conditions

-verbose command looks like this:
dc_shell-t> report_operating_conditions -verbose

Operating Condition Name : SLOW (library_definied)
Library : MV_lib_ls
Process : 1.00
Temperature : 125.00
Voltage : 1.00
Interconnect Model : worst_case_tree
Power Rails:
Rail Voltage Value
-------------------------
VDD1_Rail 1.00
VDD2_Rail 0.60
Operating Condition Name : SLOW_60 (user_created)

Library : MV_lib_ls
Process : 1.00
Voltage : 0.60
Power Rails:
Rail Voltage Value
---------------------------
VDD1_Rail 0.60
VDD2_Rail 0.60
Operating Condition Name : SLOW_80 (user_created)

Library : MV_lib_ls
Process : 1.00
Voltage : 0.80
Power Rails:
Rail Voltage Value
---------------------------
VDD1_Rail 0.80
VDD2_Rail 0.80
Operating Condition Name : FAST (library_definied)

Library : core_1.2
Process : 1.00
report_operating_conditions
B-3
Voltage : 1.00
Power Rails:
Rail Voltage Value
---------------------------
VDD1_Rail 1.00
VDD2_Rail 1.00
delete_operating_condition
The syntax for this command is
delete_operating_condition opcond_name
You run this command when you want to remove any operating
condition that you created with the
create_operating_condition command. The user-specified
operating condition with the name opcond_cond is deleted from the
set of operating conditions, and the following warning is issued:
Warning: Operating condition opcon_name has been deleted.
However, if any subdesign uses the opcond_name operating

condition, the command does not remove this operating condition.
Instead the following warning is issued:
Warning: Design design_name is using the operating condition

opcon_name. Please first change the operating condition for
the design design_name before deleting it. opcon_name is not
deleted.
The remove_operating _condition command does not
remove library-specified operating conditions.

B-4
report_target_library_subset
Use this report to find out the target library constraints, that is, to
determine or confirm which target library subsets are assigned to
which design instances.
Typical output from the report_target_library_subset

command looks like this:
****************************************
Report : target library subset
Design : fir_top
Version: X-2005.09
Date : Wed Aug 3 11:44:29 2005
****************************************
Object Reference Type Target Library Subset

------------------------------------------------------------------------------
fir_top fir_top design ss_0v80_125c.db
I_fir_data fir_data cell ss_0v70_125c.db
I_fir_fsm fir_fsm cell ss_0v90_125c_hvt.db
------------------------------------------------------------------------------
1
check_mv_design
Use this command to check for design errors, including multivoltage
constraint violations, electrical isolation violations, connection rules
violations, and operating condition mismatches. Two switches let you
control the level of information detail and limit the number of
messages printed to the log file, Other switches, such as
-isolation, -connection_rules, -opcond_mismatches,
and -target_library_subset, let you select among the
available checking reports.
report_target_library_subset
B-5
If you do not specify any checkers, violations are reported from all
supported checkers. If you use the -verbose switch, the checkers
provide detailed reports. If you omit this switch, summary reports are
provided.
This command includes the following arguments:
-verbose Optional. Provides a detailed report. If you do not

use this option, a summary of any violations is
reported.
-max_messages Optional. Sets a limit, given by message count, on

[message count] the number of messages per checker printed in the
log file. If no checkers are specified, this is the
message limit from all checkers. If you do not use
this option, all messages are printed.
-isolation Optional. Provides a report on electrical isolation

errors with respect to power domains.
-connection_rules Optional. Reports violations in always-on synthesis

and pass-gate connections.
-opcond_mismatches Optional. Reports incompatible operating

conditions between instantiated technology cells
and the cell’s parent design.
-target_library_subset Optional. Reports inconsistent settings among

target libraries, target library subsets, and operating
conditions.

B-6
check_target_library_subset
Use this command to check for inconsistent usage of target libraries
in target library subsetting, as well as for inconsistent settings of
operating conditions. This check reports on the following:
• Conflicts between target library subsets and the global target

library variable.
• Conflicts between the operating condition and the target library
subset for the given instances. (At least one library from the
subset must have the nominal voltage as the operating condition
of the block.)
• Conflicts between the library cell of the mapped cell and the cells
of the target library subset. Note that this type of conflict is not an
error. It generates only a warning because the target subsetting
applies to new cells created during optimization and not to the
existing cells in the block.
check_level_shifters
Use this command to check all level shifters, including
hand-instantiated enable-type level shifters, and level-shifter nets
against any specified level-shifter strategy and threshold. Note that
the command checks only cells for which the library attribute
is_level_shifter is set to true.
Typical output from the check_level_shifters command looks

like this:
check_target_library_subset
B-7
******************************************************************************
Check Level Shifters and Nets Summary
******************************************************************************
Level shifter strategy :all
Level shifter threshold voltage :0 (default)
Level shifter threshold percent :Not defined
No. of violating nets - dont_touch :4
No. of violating nets - multiple driver :0
No. of violating nets - no dont_touch :0
No. of violating level shifters - dont_touch :0
No. of violating level shifters - no dont_touch :0
No. of level shifters in design :98
******************************************************************************
1
To obtain detailed information, use the -verbose option with the

command. Additional information includes:
• Net information
- Net name
- Driver pin
- Input voltage
- Load pin
- Output voltage
• Level-shifter information
- Operating condition
- Level-shifter reference
- Level-shifter reference input voltage
- Level-shifter reference output voltage
- Violation description

B-8
check_isolation_cells
Use the check_isolation_cells command to check for the
presence of isolation cells in the mapped logic hierarchies (blocks)
or the voltage areas associated with the power domains of the
design. This command reports the number of isolation cells, informs
you if any of these cells are redundant, and warns you if isolation
cells that might be needed are missing. Using the command options,
you can restrict the report to check only for isolation cells that are
• On the input nets of the specified logic hierarchies or voltage

areas
• On the output nets of the specified logic hierarchies or voltage
areas
• Inside the specified logic hierarchies or voltage areas
• Outside the specified logic hierarchies or voltage areas
Note:
You can also use this command to check for isolation cells in the
mapped netlist before you run Physical Compiler to place and
optimize the design. In this case, you specify the logic hierarchies
(blocks) associated with the given power domains instead of the
voltage areas.
Typical output from the check_isolation_cells command looks

like this:
Information: Updating design information... (UID-85)

*********************************************
Voltage area : MV_VOL_AREA1

-----------------------------------------
Information: Input MV_VOL_AREA1:I_blk3_state_27to17/state_out[20] has an
B-9
isolation cell I_blk3_state_27to17/I_iso_state_out_20 inside MV_VOL_AREA1
Information : Input MV_VOL_AREA1:I_blk3_state_27to17/state_out[21] has an



Voltage area : MV_VOL_AREA3

-----------------------------------------
Information : Output MV_VOL_AREA3:I_blk3_state_9to2/state_out_iso[7] has an




----------------------------------------------------
Warning : The input net I_blk2_iso_ctrl/clock to MV_VOL_AREA2 may require

isolation cell
Warning : The input net I_blk2_iso_ctrl/reset to MV_VOL_AREA2 may require

isolation cell
Warning : The input net I_blk2_iso_ctrl/in_valid to MV_VOL_AREA2 may require

isolation cell
----------------------------------------------------
Missing Isolation cell(s) at output(s) of MV_VOL_AREA2
----------------------------------------------------
Warning : The output net I_blk2_iso_ctrl/sleep_fsm from MV_VOL_AREA2 may require

isolation cell
----------------------------------------------------
Missing Isolation cell(s) at input(s) of MV_VOL_AREA1
----------------------------------------------------

B-10
Warning : The input net I_blk2/clock to MV_VOL_AREA1 may require isolation cell
Warning : The input net I_blk2/reset to MV_VOL_AREA1 may require isolation cell
Warning : The input net I_blk2/state_out[1] to MV_VOL_AREA1 may require isolation

cell
Warning : The input net I_blk2/state_out[0] to MV_VOL_AREA1 may require isolation

cell
----------------------------------------------------
Missing Isolation cell(s) at input(s) of MV_VOL_AREA3
----------------------------------------------------
Warning : The input net I_blk1/clock to MV_VOL_AREA3 may require isolation cell
Warning : The input net I_blk1/reset to MV_VOL_AREA3 may require isolation cell
Warning : The input net I_blk1/in_valid to MV_VOL_AREA3 may require isolation cell
----------------------------------------------------
Missing Isolation cell(s) at output(s) of MV_VOL_AREA3
----------------------------------------------------
Warning : The output net I_blk1/state_out[1] from MV_VOL_AREA3 may require

isolation cell
Warning : The output net I_blk1/state_out[0] from MV_VOL_AREA3 may require

isolation cell
Total number of isolation cell(s) : 63

*********************************************
1
B-11
report_cell
In multivoltage mode, this report provides additional columns to
display the operating conditions and voltages annotated on the cells
of the design.
Typical output from the report_cell command looks like this:
dc_shell-t> report_cell
Cell Ref. Library Area Attr. Opcond Voltage

---------------------------------------------------------------------
u1 add1 lib1 1065.9 h nom2v 2.0(VDD1:2.00 VDD2:3.00)
u2 add2 lib2 1065.9 h nom1v 1.8(VDD1:1.80 VDD2:2.00)
u3 ls lib_ls 1065.9 - 1.8->3.0(VDD1:1.80 VDD2:3.00)
check_design
In multivoltage mode, this command provides an additional error
message: “Error: cell ‘%’ is not characterized for %fV.”
For example,
Error: cell InstDecode/U3(INVX1) is not characterized for 0.900000V.

(MV-001)
report_voltage_area
In multivoltage mode, this command also reports the operating
conditions that are associated with the various blocks of the voltage
area. For example,

B-12
Voltage Area Name voltage_area_add1
Block(s) :u1
Voltage Area geometry : { 9 18 86 37 }
Voltage Area area: 1417.33
Voltage Area Utilization: 0.75
Voltage Area Operating Conditions: nom1v
Voltage Area Min. Operating Conditions: nom1v
Voltage Area Operating Voltage: volt1
Voltage Area Operating Temperature: Temp1
Voltage Area Guard-band (X,Y): (10, 20)
Additionally, if you specify the -verbose option, the operating

conditions associated with the various blocks of the voltage area are
listed. For example,
********************************
Max Operating Condition:
Opcond nom1v: u1
Min. Operating Condition:
op_cond nom1v: u1
********************************
If more than one operating condition is defined within one physical

voltage area, the report issues the following warning:
Warning: More than one operating condition is defined

Voltage Area Operating Conditions : nom1v, nom2v
Voltage Area Min Operating Conditions : nom1v, nom2v
report_timing
In multivoltage mode, this command reports the library operating
condition, voltage (-voltage option), and temperature
(-temperature option) of the cells in the timing paths instead of
the design operating condition.
The library operating conditions of the cells in the timing path are
displayed under the report column “Lib:OC,” and (if you use the
appropriate options) voltages under a “Voltage” column, and
temperatures under a “Temperature” column.
report_timing
B-13
For example,
dc_shell-t> report_timing -voltage -temperature

Information: Updating design information... (UID-85)
********************************************
Report : timing
-path full
-delay max
-voltage
-temperature
-max_paths 1
Design : add Version
Version:V-2004.06
Date : Mon Apr 26 23:40:02 2004
********************************************
* Some/all delay information is back-annotated.
Startpoint: in2[1] (input port)
Endpoint: out[31] (output port)
Path Group: (none)
Path Type: max
Point Incr
Path
Lib:OC Voltage Temp.
--------------------------------------------------------------------
input external delay 0.00
0.00 f
in2[1] (in)0.000.00 f
-:nom2v 2.00 25.00
U34/Y (T2SHIFTER) 0.06*
0.06 f
typ2:nom2v (VDD1:1.00 VDD2:2. 00 )
25.00
u1/in2[1] (add1) 0.00 0.06 f
-:nom1v 1.00 25.00
u1/add_6/B[1] (add1_DW01_add_32_0) 0.00 0.06 f
-:nom1v 1.00 25.00
u1/add_6/U1_1/S (T1ADDFXL) 0.50 * 0.56 f
typ1:nom1v 1.00 25.00
u1/add_6/SUM[1] (add1_DW01_add_32_0) 0.00 0.56 f
-:nom1v 1.00 25.00
u1/out[1] (add1) 0.00 0.56 f
-:nom1v 1.00 25.00
U2/Y (T1SHIFTER) 0.10 * 0.66 f
typ1:nom2v (VDD1:1.00 VDD2:2. 00 )
...
u2/add_6/SUM[31] (add2_DW01_add_32_0) 0.00 8.73 r

-:nom2v 2.00 25.00
u2/out[31] (add2) 0.00 8.73 r
-:nom2v 2.00 25.00
out[31] (out) 0.00 * 8.73 r
-:nom2v 2.00 25.00
data arrival time 8.73
--------------------------------------------------------------------

B-14
report_delay_calculation
In multivoltage mode, the command also reports operating
conditions and voltages.
Partial output from the report_delay_calculation command

looks like this:
dc_shell-t> report_delay_calculation -from BLK1/Z -to BLK2/A
****************************************
Report : delay_calculation
Design : led
Version: v3.1a
Date : Tue Apr 7 16:28:07 2004
****************************************
From : BLK1/Z
To : BLK2/A
arc type : net
Operating Conditions: BASIC_WORST Library: basic Voltage: 1.2
Wire Load Model Mode: top
Design Wire Loading Model Library
-----------------------------------------------
RDC_GENERIC BASIC_ONE basic
Balanced case tree

equation : (r_wire/load_count) * (c_pins + c_wire/load_count)
*(0.53 / 1) * (1 + 0.53 / 1)
delay rise, fall : 0.608175 , 0.608175
...
report_hierarchy
In multivoltage mode, the command also reports operating
conditions and voltages.
Typical output from the report_hierarchy command looks like

this:
report_delay_calculation
B-15
dc_shell-t> report_hierarchy
****************************************
Report : hierarchy
Design : CONTROL
Version: v2.0
Date : Fri Mar 20 14:09:24 2000
****************************************
CONTROL opcond1 1.2
CTLX opcond2 1.5 (VDD1:1.2,VDD2:1.5)
AO1 tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
EON1 tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
INVA tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
NAND2 tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
NR2 tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
NR3 tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
OR2 tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
OR3 tech_lib opcond2 1.5 (VDD1:1.2,VDD2:1.5)
LSHIFTER ls_lib 1.0->2.0v
JPMP opcond3 2.0
MX1P iiii_lib opcond3 2.0
NAND2 iiii_lib opcond3 2.0
NAND3 iiii_lib opcond3 1.2

B-16
C
Logic and Physical Library Models C
The tool supports multiple nonlinear delay model (NLDM) libraries
with cells characterized at different voltages.
Currently, a buffer-type level-shifter cell is modeled as a buffer with

the following properties:
• Two power supplies: a master (primary) supply and a secondary

supply
• Input and output pin voltages that are different
An enable-type level-shifter cell is modeled as a buffer with an enable
pin and has the two properties described above.
C-1
For Design Compiler and Physical Compiler to recognize either kind
of level shifter, the library cells must have the is_level_shifter
library attribute set to true. Also, the enable pin of the enable-type
level-shifter model must have the level_shifter_enable_pin
attribute set to true.
Appendix C: Logic and Physical Library Models

C-2
Logic Library Models
The logic library must provide sections that define power supplies
(including level-shifter specifications) and level-shifter models.
Defining a Power Supply

This logic library example defines a power supply section that
identifies the different power rails and their voltage levels required by
library cells, including level-shifter cells.
power_supply() {
default_power_rail : VDD1;
power_rail (VDD1, 2.0); /* primary power */
power_rail (VDD2, 3.0); /* secondary power */
power_rail (GND, 0.01);
}
/* operation conditions */
nom_process : 1;
nom_temperature : 25;
nom_voltage : 2.0;
operating_conditions(nom1v) {
process: 1;
temperature: 25;
voltage: 2.0;
tree_type: balanced_tree;
power_rail (VDD1, 2.0);
power_rail (VDD2, 3.0);
power_rail (GND, 0.01);
}
Logic Library Models

C-3
Defining an Enable-Type Level Shifter
This logic library example defines an enable-type level-shifter cell
model.
cell(LSHIFTER12) {
is_level_shifter : true;
cell_footprint : buf;
area : 16.9740;
pin (enable) {
level_shifter_enable_pin : true;
...
}
pin(A) {
direction : input;
capacitance : 0.4;
input_signal_level : VDD1;
}
pin(Y) {
direction : output;
capacitance : 0.0;
output_signal_level : VDD2;
function : "A";
}
}
Defining a Buffer-Type Level Shifter

The logic library model for a buffer-type level shifter is the same as
the preceding description for the enable-type level shifter except the
pin(enable) description is absent.

C-4
Physical Library Specifications
The following examples provide typical specifications for normal and
level-shifter core sites and for a level-shifter physical cell.
Defining Core Sites in the Library

Core sites for normal cells:
SITE core
SYMMETRY y ; /* cells can only be mirrored i.y Y symmetry
*/
CLASS core ; /* class core not IO */
SIZE 0.560 BY 4.480 ; /* width X height */
END core
Core sites for level-shifter cells:
SITE corels
SYMMETRY y ; /* cells can only be mirrored i.y Y symmetry
*/
CLASS core ; /* class core not IO */
SIZE 0.560 BY 8.96; /* width X 2*height */
END corels
Physical Library Specifications

C-5
Defining a Level-Shifter Physical Cell
Level-shifter physical cells:
macro lshifter
size 2.800 by 8.960 ;
site corels ;
symmetry y ;
class core ;
obs
....
end
pin P1
...
end P1
pin P2
....
end P2
pin P3
...
end P3
end lshifter

C-6
Index
A C
acs_compile_design command 2-35 check_design command 1-9, B-12
acs_refine_design command 2-35 check_isolation_cells command 1-8, 2-8, 2-17,
attributes 3-16, B-9
dont_touch 1-7, 2-33, A-3, A-9, A-10, A-11, check_level_shifters command 1-8, 2-6, 2-17,
A-13 3-19, A-2, A-4, A-8, B-7
is_isolation_cell 1-6, 2-7, 3-21, A-15 check_mv_design command 1-8, 2-4, 2-16,
is_level_shifter 1-6, 2-5, 2-7, 3-21, A-8, B-5
A-15, B-7, C-2 commands
isolation_cell_enable_pin 1-6 acs_compile_design 2-35
level_shifter_enable_pin 1-6, 2-5, 2-7, C-2 acs_refine_design 2-35
Automated Chip Synthesis flow 2-32 check_design 1-9, B-12
automatic high-fanout synthesis check_isolation_cells 1-8, 2-8, 2-17, 3-16,
voltage area aware 3-16 B-9
check_level_shifters 1-8, 2-6, 2-17, 3-19,
A-2, A-4, A-8, B-7
B check_mv_design 1-8, 2-4, 2-16, B-5
buffer-type level shifters connect_power_domain 2-13
checking for violations A-8 connect_power_net_info 2-10, 2-14
checking the design A-8 create_ilm 3-18
general properties A-2 create_operating_condition B-3, B-4
inserting A-9 create_placement 3-1, A-4, A-15
insertion flow A-4 create_power_domain 2-10, 2-11
insertion strategy A-5 create_power_net_info 2-10, 2-12
insertion threshold A-5 create_voltage_area 1-3, 3-7, 3-11, A-4
placing A-15 dc_allocate_budgets 2-27
removing A-9 derive_voltage_area 3-8, 3-9, 3-11, A-4
disconnect_power_net_info 2-14
IN-1
get_always_on_logic 2-16 update_voltage_area 3-7, 3-9, 3-10, 3-11,
get_power_domains 2-12, 2-13 A-4
get_voltage_area 3-10 compile_delete_unloaded_sequential_cells
infer_power_domain 2-10 variable 2-21
insert_level_shifters 1-7, 2-5, 2-33, A-2, A-3, connect_power_domain command 2-13
A-4, A-9 connect_power_net_info command 2-10, 2-14
leagalize_placement 3-1, A-4 create_ilm command 3-18
legalize_placement A-15 create_operating_condition command B-3,
physopt 1-3, 1-6, 1-10, 3-16, 3-20, A-4, B-4
A-10, A-13, A-15 create_placement command 3-1, A-4, A-15
propagate_constraints 3-18
create_power_domain command 2-10, 2-11
remove_level_shifters A-3, A-9
create_power_net_info command 2-10, 2-12
remove_power_domain 2-12
remove_power_net_info 2-13 create_voltage_area command 1-3, 3-7, 3-11,
A-4
remove_target_library_subset 2-4
remove_voltage_area 3-15
report_cell 1-8, B-12 D
report_delay_calculation 1-9, B-15
report_hierarchy 1-9, B-15 dc_allocate_budgets command 2-27
report_operating_conditions 1-8, B-3 derive_voltage_area command 3-8, 3-9, 3-11,
report_power_domain 2-12 A-4
report_power_net_info 2-13 Design Compiler/Physical Compiler high-level
flow
report_power_pin_info 2-11
design flow limitations 1-7
report_power_pin_information 2-14
interacting with other Synopsys tools 1-13
report_target_library_subset 1-8, 2-5, B-5,
B-7 logic synthesis phase 1-10
report_timing 1-9, B-13 physical synthesis phase 1-10
report_voltage_area 1-9, 3-15, B-12 disconnect_power_net_info command 2-14
run_router 3-17 dont_touch attribute 1-7, 2-33, A-3, A-9, A-10,
set_cell_row_type 3-8, 3-9, A-4 A-11, A-13
set_compile_partitions 2-34 dw_prefer_mc_inside variable 2-35
set_level_shifter_strategy 2-34, A-2, A-3,
A-5, A-8, A-10
set_level_shifter_threshold 2-34, A-3, A-6, G
A-7, A-8, A-10 get_always_on_logic command 2-16
set_operating_conditions 2-33, 3-18, A-12 get_power_domains command 2-12, 2-13
set_relative_always_on 2-9, 2-15 get_voltage_area command 3-10
set_row_type 3-8, A-4
set_target_library_subset 1-4, 1-5, 2-3,
2-33, 2-35 I
uniquify 2-34
infer_power_domain command 2-10
IN-2
insert_level_shifters command 1-7, 2-5, 2-33, limitations 2-19
A-2, A-3, A-4, A-9 script 2-24
uniquified designs required 2-4, 2-12, 2-20 using isolation cells and level shifters 2-20
interface logic models (ILMs), using in multivoltage designs
multivoltage designs 3-18 identifying characteristics 2-3, 3-3
is_isolation_cell attribute 1-6, 2-7, 3-21, A-15 reporting errors 2-16
is_level_shifter attribute 1-6, 2-5, 2-7, 3-21, simple design example 1-12
A-8, A-15, B-7, C-2 using interface logic models 3-18
isolation cell using relative placement 3-19
checking 3-16 multivoltage features, enabled by default 2-3,
GTECH isolation cells 2-7 3-3
inserting 2-6 multivoltage reports B-1
isolation_cell_enable_pin attribute 1-6 multivoltage/multisupply designs 1-2
definitions 1-2
level shifter and isolation cell requirements
K 1-5
k-factors, unsupported 1-5 library requirements 1-4
power domains 1-2
voltage area requirements 1-5
L
legalize_placement command 3-1, A-4, A-15
level shifter
N
inserting buffer-type 2-5 nonlinear delay model libraries
inserting enable-type 2-6 design example 1-12
requirements 1-4
level_shifter_enable_pin attribute 1-6, 2-5, 2-7,
C-2 using 2-1, 2-17, 2-27, 2-32, 3-21, C-1
library models
logical C-3
physical C-5
P
link_library variable 2-34 physical library specifications C-5
logical library models C-3 physical optimization
voltage area based 3-20
logically nested voltage areas, handling 3-13
physical synthesis
placing and optimizing designs 3-21
M physopt command 1-3, 1-6, 1-10, A-4, A-10,
A-13, A-15
maximum net length optimization
automic high-fanout synthesis capability
voltage area aware 3-20
3-16
multivoltage compile flow maximum net length optimization 3-20
Automated Chip Synthesis, "top-down" 2-32 voltage aware capabilities 3-16
Design Compiler, bottom-up 2-27
physopt_enable_voltage_aware_route_estima
Design Compiler, top-down 2-17 tion variable 3-17
IN-3
physopt_heterogeneous_site_array variable report_timing command 1-9, B-13
3-5 report_voltage_area command 1-9, 3-15, B-12
placing and optimizing designs, physical reporting multivoltage designs B-1
synthesis 3-21
run_router command 3-17
power domains
connecting 2-13
creating 2-10 S
creating power net information 2-12
set_cell_row_type command 3-8, 3-9, A-4
defining relative always-on 2-9, 2-15
definition 1-2, 2-8 set_compile_partitions command 2-34
finding always-on paths 2-16 set_level_shifter_strategy command 2-34,
inferring from the RTL design 2-9 A-2, A-3, A-5, A-8, A-10
relative always-on 2-15 set_level_shifter_threshold command 2-34,
reporting power pin information 2-14 A-3, A-6, A-7, A-8, A-10
specifying exceptional power net set_operating_conditions command 2-33,
connections 2-14 3-18, A-12
using 2-8 set_relative_always_on command 2-9, 2-15
voltage areas 2-17 set_row_type command 3-8, A-4
propagate_constraints command 3-18 set_target_library_subset command 1-4, 1-5,
2-3, 2-33, 2-35
R
relative always-on power domains 2-9 T
relative placement, using in multivoltage target library subsetting 2-3
designs 3-19 target_library variable 2-5
remove_level_shifters command A-3, A-9
remove_power_domain command 2-12
remove_power_net_info command 2-13 U
remove_target_library_subset command 2-4 uniquified designs, insert_level_shifters
remove_voltage_area command 3-15 command 2-4, 2-12, 2-20
report_cell command 1-8, B-12 uniquify command 2-34
report_delay_calculation command 1-9, B-15 update_voltage_area command 3-7, 3-9, 3-10,
3-11, A-4
report_hierarchy command 1-9, B-15
report_operating_conditions command 1-8,
B-3 V
report_power_domain command 2-12
variables
report_power_net_info command 2-13 compile_delete_unloaded_sequential_cells
report_power_pin_info command 2-11 2-21
report_power_pin_information command 2-14 dw_prefer_mc_inside 2-35
report_target_library_subset command 1-8, link_library 2-34
2-5, B-5, B-7
IN-4
physopt_enable_voltage_aware_route_esti creating 3-3
mation 3-17 automatically 3-8
physopt_heterogeneous_site_array 3-5 manually 3-7
target_library 2-5 handling logically nested voltage areas 3-13
virtual hierarchy routing including guard bands 3-10
voltage area aware 3-17 logically nested 3-4
voltage area aware capabilities, physopt removing 3-15
command 3-16 reporting 3-15
voltage areas updating 3-10
composite abutted structures 3-4
IN-5

Design Compiler and Physical Compiler Multivoltage

Uploaded by

Copyright:

Available Formats

You might also like

Design Compiler and Physical Compiler Multivoltage

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design Compiler and Physical Compiler Multivoltage

Uploaded by

Copyright:

Available Formats

Design Compiler® and

Service Marks (SM)

What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1. Multivoltage/Multisupply Designs and Design Flow

3. Physical Synthesis Phase

Appendix B. Multivoltage Reports

Appendix C. Logic and Physical Library Models

This preface includes the following sections:

• What’s New in This Release

• Multivoltage mode is on by default. Design Compiler and Physical

- Specifying relative always-on power domains (that is,

• Logically nested voltage areas are supported in Design Compiler

What’s New in This Release

• Physical Compiler supports the use of interface logic models

About This User Guide

The complete Galaxy Design Platform multivoltage design flow uses

The Design Compiler/Physical Compile multivoltage flow and related

• Chapter 1: Multivoltage/Multisupply Designs and Design Flow

To use these Synopsys tools, you need to be skilled in logic design

• Logic design and timing principles

About This User Guide

• Synopsys Online Documentation (SOLD), which is included with

About This User Guide

Courier Indicates command syntax.

Courier italic Indicates a user-defined value in Synopsys

Courier bold Indicates user input—text you type verbatim—

[] Denotes optional parameters, such as

| Indicates a choice among alternatives, such as

_ Connects terms that are read as a single term

Control-c Indicates a keyboard combination, such as

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

Edit > Copy Indicates a path to a menu command, such as

1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

• Multivoltage and Multisupply Designs

To reduce power consumption, multivoltage designs typically make

Specifically, a power domain is defined as a logical grouping of one

• Primary voltage states or voltage range (that is, the same

Chapter 1: Multivoltage/Multisupply Designs and Design Flow

As noted, a voltage area is the physical placement area of a logic

Level shifters connect drive and load pins operating at different

In Design Compiler and Physical Compiler, level-shifter cells are

You can use commands that automatically insert buffer-type level

Multivoltage and Multisupply Designs

Note that enable-type level shifters should be instantiated at the RTL

Library Requirements for Multivoltage Designs

Target library cells are selected on the basis of matching operating

For multivoltage designs, library limitations include the following:

Chapter 1: Multivoltage/Multisupply Designs and Design Flow

Voltage Area Requirements for Multivoltage Designs

• The floorplan must contain at least one voltage area (and a

Level-Shifter and Isolation Cell Requirements and

• Two power supplies are sometimes required.

Multivoltage and Multisupply Designs

Chapter 1: Multivoltage/Multisupply Designs and Design Flow

• Automated Chip Synthesis automatically inserts buffer-type level

Multivoltage and Multisupply Designs

• List all available operating conditions

Chapter 1: Multivoltage/Multisupply Designs and Design Flow