Voltage Area Feedthrough

and Always-on Synthesis

Application Note
Ver 1.0
December 2008

i
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, 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-Macromodeling,
Dynamic Model Switcher, 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, iN-Tandem,
Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme,
Liberty, Libra-Passport, Library Compiler, Libra-Visa, 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-RCXT, Star-SimXT, 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.
Saber is a registered trademark of SabreMark Limited Partnership and is used under license.
All other product or company names may be trademarks of their respective owners.

ii
Design Challenges for Multi-voltage Design
In the current implementation of multi-voltage design, nets are not permitted to cross the
voltage areas to which they do not belong. This can lead to excessive wire length or
congestion, and consequent timing violations.
Figure 1 illustrated a design style of this kind.

Figure1 Multi-voltage Floorplan Contributed to Design Difficulty

This document describes a methodology in which such a net is broken to be

feedthrough with extra ports created on the voltage area boundary, so-called voltage
area feedthrough, then followed by always-on synthesis to resolve the timing or
congestion problem for your design.

1
 Figure 2 Solution to Resolve Design Issues

The logic change on the voltage area boundary is necessary due to the fact that logical
and physical must be consistent to each other, which is the foundation of ICC low power
mechanism. Even though you may guide the router to route through the voltage area,
the new buffers inserted during the optimization logically belongs to its native domain,
and will be eventually legalized out of its non-native feedthrough area.

The major advantages of applying this methodology is

1. Easier routing to avoid the narrow channels
2. Less buffers used with reduced area and net length

Introduction of the Methodology

The following is the diagram for voltage area feedthrough and always-on synthesis
methodology. The prerequisite of applying voltage area feedthrough is that the design
has to be placed well before applying voltage area. The realistic usage could be you
have a quick round of placement and optimization, analyze your design and identify the
timing paths or area where feedthrough may help.

2
 Figure3 Methodology Diagram

High-level introduction for the methodology UPF and nonUPF design:

• Voltage area feedthrough flow is uniform for UPF and nonUPF design
• Always-on synthesis flow varies for UPF and nonUPF design

The detailed flow will be described in the subsequent chapters.

Voltage Area Feedthrough

Extended from an existing design planning feature “plangroup feedthrough”, ICC has
implemented the “voltage area feedthrough” in 2008.09.

Figure 4 is the diagram for the voltage area feedthrough flow. By enabling the
feedthrough on voltage area, it guides the subsequent global route to route through the
voltage area. Pure feedthrough ports and net will be created based on crossings
between a global route and voltage area boundaries. For a more realistic usage, one
may generate a list of nets which will have feedthroughs on the voltage area, analyze
the candidate nets, and then pass the selective nets to finalize the feedthroughs. In the
3
end, disable the voltage area feedthrough such that the generic routing rule for the low
power design is honored.

Figure4 Voltage Area Feedthrough Flow Diagram

Figure 5 and Figure 6 show a feedthrough net before and after analyze routing
respectively. The new ports and net logically belongs to the top hierarchical level within
the voltage area. Feedthrough for nested voltage area is also supported.

4
 Figure5 A Net Before Analyze Routing

PD

Net A

Figure6 A Net After Analyze Routing

PD

PD/A_pft0 PD/A_pft1

Net A Net A__sn0

The usage of voltage area feedthrough is as follows:

5
Figure 7 Command Usages for Voltage Area Feedthrough

Note:
*** This finalizing step automatically writes out a text file “VA_Feedthroughs.port” with
names of all feedthrough ports created on voltage areas.

Always on Synthesis
Always-on synthesis is the key technology in low power design methodology. The
designs, aiming for overall low power consumption, typically have a mix of always-on
and shut-down regions. Certain signals inside a power down domain need to stay
active- the enable signal of isolation cells and enabled level shifters, sleep control signal
of switch cells and retention registers. Those paths are termed as always-on
(henceforth, will be referred as AO) paths. Cells inserted by synthesis tool on those AO
paths have to be always powered up.

6
AO Marking
The AO synthesis has to mark the AO paths before selecting the right buffer for AO
paths. It depends on the anchor pin identification and marks the AO nets by fan-in cone
tracing.
The control net to the power management cells described above is implicitly derived as
AO and doesn’t need user’s intervention. There are chances that user want to define
AO to in favor of the design for various reasons—one of which is to synthesis the
feedthrough nets in a shutdown domain with AO cell which is the theme of this
document. In this situation, user needs to guide the tool for AO path identification.

AO Cell Selection
There are two approaches to synthesis the AO paths, which is mapped to two
strategies: dual_power or single_power. The so-called AO buffers or inverters are more
often referred to the dual_power cell that has a secondary power pin in addition to the
primary power pin. Both approaches have pros and cons as summarized in Table1:

Table 1 Advantages and Disadvantages for Two Types of Always-on Cell

Always-on Cell
+ Easier power planning
+ Free AO cell placement
- Library preparation for AO cell
- More routing congestion – extra -
power routing to manage)
Regular Cell as Always-on Cell
+ Simpler library preparation
+ Less routing congestion
(secondary power pin routing can
be skipped)
- Additional power planning
Hard to tune QoR as AO cells
are restricted to certain area,
which is hard to predict the
size and the utilization

AO Attribute Summary
You CAN specify always-on attribute on
• Library cells
• Library pins
• Cell instance input pins
• Top design output ports
• Hierarchical output port

7
You CANNOT specify always-on attribute on
• Cell instances
• Cell instance output pins
• Top design input ports
• Top design output port
When you specify “always_on” attribute on a library cell, you are marking cell as a
special cell that can be used for optimizing always on paths. When you specify always-
on attribute on pin or a lib pin, you are instructing tool to synthesize fan-in cone of the
pin using always on logic.

AO Checking
check_mv_design reports the following AO violations:
Normal cell drives AO net in PD domain
AO cell drives normal net
AO net drives gate with input transmission in power-down domain
Gate with output transmission driving gate with input transmission

After voltage area feedthrough ports and nets are created based on a pre-analyzed
design, AO synthesis flow needs to be applied. The following sections describe the flow
details in each major step. The difference of UPF and nonUPF approach is also
addressed.

Always-on Synthesis Setup

Always-on synthesis is enabled by default in the 2008.09 release and beyond. If you
use IC Compiler releases prior to B-2008.09, you need to enable the feature by
set enable_ao_synthesis true
Next, explicitly set the AO attribute on the output of the new feedthrough port created
from which the backward AO tracing is triggered.
set_attribute [get_pins <feedthrough_output_port>] always_on
true
Remember the final feedthrough ports are captured in a tool-generated text file
“VA_Feedthroughs.port”. For ease-of-use purpose, simply passing all the feedthrough
ports--input and output type—for attribute setting doesn’t hurt. AO tracing stops at a
multi-input cell, the driver outside the shut-down region.
Use get_always_on_logic to report the AO nets derived from the AO pin.

8
Physical Synthesis
Power Hookup
Power hookup mechanism determines the different methodology of AO synthesis for
UPF and nonUPF design.

Typically user manages the power hookup by themselves for designs without UPF
constraints. In this situation, one can follow the regular flow for optimization and apply
user-driven power hookup for AO cells inserted.
derive_pg_connection –power_net –power_pin [get_cells <leaf cell
collection>]
derive_pg_connection –ground_net –ground_pin [get_cells <leaf
cell collection>]

With UPF constraints, the backup power or ground hookup of AO buffers is determined
via tracing to the fanout of the net in the domain. Since feedthrough nets do not have
any load in the shut-down domain, power connections required for the AO buffer
cannot be derived. As a result, tool marks don’t_touch on the AO net . The solution to it
is manually insert an AO buffer on the feedthrough nets and physically placed it next to
the AO anchor pin, set the buffer input pin as AO pin, then connects its backup power
pin to the proper power supply. With these steps, get_always_on_logic is able to report
the net driving the new buffer to be AO net and AO synthesis can be applied.
The following are the sample scripts for UPF feedthrough nets handling before the
optimization. The netlist editing command insert_buffer is used for AO buffer
insertion.

! "##
!$% & '()** +,'

$ ! -

! .# & /

!
!! / , ( ! , (

% !

Note:
The manually inserted AO buffer has to be logically pushed down into the shutdown
domain to make the AO marking mechanism work. To achieve it, you must pass the
hierarchical net to the command insert_buffer. Specifying the hierarchical output port
9
always results in the AO buffer assigning to the outside of the hierarchical module,
which is top level for this case.

AO Synthesis

For dual_rail AO cell approach, tool will use the AO cells by detecting the AO attribute
set at the cell level in the library:

library (<library_name>) {
...
cell (<cell_name>) {
always_on : true;
…
}

When regular cells are used for AO synthesis, user may set “always_on” attribute on the
library cell to guide the tool for selective buffer usage.

Notes:
As opposed to pure feedthrough, it is likely that there are logics in the shut-down
domain. Feedthrough ports are generated at the output domain boundaries, resulting in
AO buffers drive the inner logic as well. This could be a waste as AO logic is not
required per the power requirement. Regular buffers can be used without causing any
electrical violations and relieve the design difficulties it brings such as area overhead
and routing to the secondary power pin. Figure 8-10 illustrate the scenario and tool
behavior:

Figure 8 Regular Feedthrough with Logic Inside the Shut-down Domain

10
Figure 9 Port-Punching on Output of Voltage Area

Figure 10 AO Buffers Driving Normal Logic

AO buffers

Although adding additional Voltage area Feedthrough port to split the port at input
boundary maybe beneficial, this is not what the tool is implemented. Because creating
such extra pure feedthrough net upfront during finalize routing may turn out to be
completely unnecessary in cases where the net has no timing issue and no need to
insert buffers. Generating extra unneeded feedthroughs is typically undesirable for the
customers.

Clock Tree Synthesis

Although the netlist modification via voltage area feedthrough is more likely to be
applies to signal paths, it is possible to be applied for clock paths as well for some
design style. Figure 11 has two power domains that may be always-on or shutdown for
different power state. Buffers are not allowed to be inserted in the default voltage area
because of the complex floorplan.

Figure 11 Clock Paths at Pre-CTS

11
The solution is to run voltage area feedthrough so that the net to sinks at module B
goes through module A and connects to the sinks in module B. Note that Voltage area
feedthrough reuses the existing input hierarchical port and creates a new output port as
a regular feedthrough(with other logic in the feedthrough module).

In the subsequent CTS, user needs to explicitly set always-on attribute on all the sinks
in module B for AO path identification. Then a guide buffer is inserted in module A close
to the feedthrough output port to isolate the branch in domain B. CTS inserts only AO
buffers in domain A whereas only regular buffers in domain B to ensure no off-state
buffer driving on-state logic. Another guide buffer is inserted in domain A driving a buffer
tree with regular CTS buffers for clock sinks in the feedthrough domain.

Figure 12 Clock Network Built by CTS

12
Always-on Secondary Power Pin Routing
In general, the recommendation to routing the secondary power pin is as such: Use
power router for static cells with secondary power pin such as level shifters, isolation
cell and switch cells. Specifically, use “net mode” of preroute_standard_cell. For the
optimization cell secondary power pin routing, use signal router with ECO capability is
more appropriate as those cells won’t be finalized until later in the flow.

The secondary power pin in physical library is usually set as “primary” type but not
“backup”. Router recognizes only one primary power pins and ignores the secondary
power pin of AO cell for routing. The solution is to copy secondary PG pin information
from logical library to physical library during Milkyway library preparation.

Apply the tcl command in Milkyway environment:

update_mw_port_by_db
-db_file {db_file_name_list}
-mw_lib <mw_library_name>
This command will map the secondary power pin information in logical db to physical
FRAM view and update the port_type in the Milkyway database. You may dump out the
GPortTable to verify the FRAM view update on the AO cell backup pin. Then signal
router is able to tap the power pin to the nearest power source.

Ensure the power pins of AO buffers are logically hooked up properly. Use
route_group for optimization AO buffer power routings. This is supported by classic
router and Zroute.
route_group –search_repair_loop 5 –nets {VDD_B}
route_group –search_repair_loop 5 –nets {VDD_P}

Verilog Write-out & Formality

Use write_verilog –pg to write out all the feedthrough ports created in the end.
The formality should pass even with logic change on voltage area as the functionality
shouldn’t be changed.

13