AON Buffer
AON Buffer
Innovus system
Product Version Innovus 17.1
February, 2018
Copyright Statement
© 2018 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property of their respective
holders.
Contents
Purpose ....................................................................................................................... 4
Audience...................................................................................................................... 4
Overview...................................................................................................................... 4
Definition and Schematic ............................................................................................. 5
Always-On ≠ “always-on”! ............................................................................................ 6
Scenarios Where Always-On Buffer Insertion is Required........................................... 7
Definition in CPF .......................................................................................................... 8
AON Insertion .............................................................................................................. 9
Using OptDesign ...................................................................................................... 9
Inference of AON buffers by tools in different MSV scenarios ............................... 10
Regular Vs. Always-On Cell Choices......................................................................... 13
Regular or Always-On buffer? ................................................................................ 14
QoR Issues/Design Issues ........................................................................................ 18
For Manual ECO ........................................................................................................ 20
Disable Always-On Buffering in a Power Domain ...................................................... 20
How to disable Always-On buffering in a power domain: ....................................... 20
Secondary Power Pin Routing ................................................................................... 21
Recommendations ..................................................................................................... 22
References ................................................................................................................ 24
Support ...................................................................................................................... 24
Feedback ................................................................................................................... 24
Purpose
This document provides details about Always-On (AON) buffers and how to utilize them
in Innovus.
Audience
This document is meant for users / designers interested in gaining knowledge about the
Always-On buffer and its insertion using Innovus version 16.1/17.1.
Overview
This document talks about Always-On buffers:
As long as the power supply to the secondary power or ground pins is ON, the cell is
considered ON. So, the Always-On buffer can be OFF even in an Always-On domain if
the supply to secondary PG pins is OFF. As low-power designs have started using the
power-shutoff technique to reduce leakage power, the need of using Always-On buffers
arises.
Always-On ≠ “always-on”!
This merely means that the i/o power is supplied from the second power pin, and not
from the power rail. For Always-On buffers, the second power pin is actually significant
for its operation; the primary rail does not have much significance. If the supply net
connected to the second power pin is made OFF, the Always-On buffer will also be
switched OFF.
In the above diagram, vdd is the secondary power net (connected to the second power
pin). This is external power supply to the switched power domain having the primary
power net as Vsw (switched rail power supply). The Vsw net is not shown in the above
diagram. If Vdd is switched OFF, the AON buffer will also be OFF.
So, AON buffers are not really always ON. These can be switched OFF if the power
supply connected to the second power pin is made OFF. This feature can be utilized to
save power, which is discussed in the later sections.
Switchable PD
Always-On PD
2. Scenario 2 – Always-On buffers are used to buffer Always-On nets, which are
nets that need to be ON even if the domain is shut OFF.
Isolation cell
TDSPCore
(switchable)
Always-on net
Definition in CPF
An Always-On buffer is a special cell; so it needs to be defined in the Common Power
Format (CPF) file as shown below:
The following CPF constructs are used in the CPF file to define Always-On buffer
usage:
• define_always_on_cell
• identify_secondary_domain
• identify_always_on_driver
• identify_power_logic (optional)
AON Insertion
This section explains how Always-On buffers are inserted using OptDesign
(place_opt_design) and ECO commands.
Using OptDesign
The tool (optDesign -preCTS or place_opt_design) will optimize the Always-On
nets using Always-On buffers in switchable power domains.
III. IPO can automatically connect the secondary power pin for Always-On
buffer
a) Connect the secondary power pin to the primary power net of the secondary
domain if an Always-On buffer is inserted in a switchable domain to buffer the
Always-On LP nets (like ISO enable, power switch enables, SRPG enable) in this
domain.
b) Connect the secondary power pin to the available power nets (like drivers,
receivers, or other available powers) for feedthrough buffering without violating
the low-power rules.
The figure below has four power domains, namely PDD, PDC, PDA, and PDB. There is a
requirement of a buffer. Optimization will check to which power pin should this buffer be
hooked to. Optimization considers that power mode PDC is ON when PDA/PDB is ON;
however, PDD is always ON. Optimization keeps power mode in consideration and
places an Always-On buffer. The Always-On buffer’s (buf_inst1) Always-On power
pin is connected to the PDD power net, and the switchable power pin is connected to the
PDC power net.
When a signal travels through multiple domains (switched and AON), domain
relationships are considered for inference of AOB or regular buffer.
– If no rule is required from PD1 to PD2 with respect to all power modes, PD1
covers PD2 ( PD1 >= PD2 )
• PD1 off => PD2 off (At a given moment, if PD1 is OFF, PD2 must be OFF.)
• PD2 on => PD1 on (At a given moment, if PD2 is ON, PD1 must be ON.)
• Vdd1(t) >= Vdd2(t) && Vss1(t) =< Vss2(t), ∀ t (t=time) (ON time of supply of
PD1 is either greater than or equal to the ON time of supply of PD2. OFF time
of PD1 is less than or equal to the OFF time of PD2.)
So, “PD1 covers PD2” basically means that PD1 is more ON or equal time ON, as
compared to PD2. There is no moment when PD1 is OFF but PD2 is ON.
– If (PD1 >= PD2) && ( PD2 >= PD1 ), PD1 is equivalent to PD2 (PD1 == PD2).
– Implication:
• No low-power interface logic is required from PD1 to PD2, and vice versa.
• Regular buffer can be used from PD1 to PD2, and vice versa.
• All domain-crossing rules pertaining to PD1 apply to PD2 as well, and vice
versa.
• Power net can be used from the equivalent domain, if necessary (for
example, in case of feedthrough).
Independent Domains
– Domains that do not cover each other, that is, (PD1 ⊄ PD2) && (PD2 ⊄ PD1)
Typical feedthrough situation where driver, receiver is in AON domain. AOB is added in
the switched domain.
In the above diagram, the situation is like below. The signal is flowing from left to right,
from driver to receiver.
Both driver and sink are in the ON domain, and you need to add the buffer in the OFF
domain. You use this principal to add an Always-On buffer. To make sure that its
effective power domain is the same as its driver, the tool will add an Always-On buffer in
the OFF domain and connect its secondary PG pin to the ON domain. All the drivers
and receivers along with the AOB are at the same state. Keeping this is mind, you will
look at various cases in the following sections, where you will use the same principle
and the principle of domain coverage discussed earlier to understand the inference of
AOB versus regular buffer by the tool.
The tool must guarantee that MSV rules are not violated. It cannot drop buffers in
arbitrary domain area. Domains may have funny shapes (rings, channels, disjoint).
– Top-left signal flow (reg buf) on-off: Driver PD is covering receiver; hence, regular
buffer is okay.
– Bottom left (AON buf) off-on-off: The tool will see the effective power domain of
the driver and add buffer to maintain all driver-receiver at the same state. In this
case, the AON buffer will be chosen and its secondary supply pin will be
connected to the switchable power domain’s primary supply. The tool could have
chosen a regular buffer also but in that case, there will be wastage of power
because all the regular buffers will be always ON in the AON domain. The AON
buffer will be OFF when the switchable supply is OFF. In this way, the effective
power domain will be considered and the driver and receiver will be at the same
state. AOBs will be maintaining their driver’s effective power state also.
– Right top: All regular buffers are used because the driver and receiver are in the
same AON domain.
In the above diagram, the driver is placed in the PDdrv domain and there are receivers
placed in multiple (n number) power domains like PDrcv_1, PDrcv_2, …. PDrcv_n.
Buffers need to be added in the intermediate power domain PDbuf.
Assume: The PDdrv domain covers all n number of receiver domains PDrcv_1,
PDrcv_2 …..PDrcv_n.
PDdrv ⊇ PDrcv_i , ∀ i=1..n (In other words, PDdrv is more ON than all receiver
power domains PDrcv_*.)
The tool will insert a regular buffer if the PDdrv domain covers the PDbuf domain; that
is, the domain where the buffer will be added by the tool. The PDbuf domain should
cover all the n number of receiver domains from PDrcv_1 to PDrcv_n.
PDdrv ⊇ PDbuf (In other words, the PDdrv power domain is more ON than
PDbuf.)
&&
PDbuf ⊇ PDrcv_i ∀ , i, i=1..n (In other words, the PDbuf power domain is more
ON than all receiver power domains.)
In CPF, the power mode definitions will be such that PDdrv will be more ON than
PDbuf and PDbuf will be more ON than PDrcv_1, PDrcv_2, …. PDrcv_n.
For UPF, the state-tables-related data will show the same relationship among the power
domains. In the later sections, relevant constructs of CPF and UPF are discussed.
Again, considering the domain coverage or “more ON” characteristics of the power
domains, the following conditions need to be satisfied to add a regular buffer in all the
respective power domains:
– If the driver power domain PDDrv here covers (more ON than) the next power
domain Pdbuf_1 (the first power domain, where buffer needs to be added),
– And Pdbuf_1 covers (more ON than) the next power domain Pdbuf_2 and so
on … and finally, the last power domain, where buffers need to be added, is
covered by just the previous power domain Pdbuf_m-1,
– And Pdbuf_m covers (more ON than) all the n number of receiver power
domains PDrcv_1 … to PDrcv_n.
The diagrams and simple equation, which generalizes the facts, are self-explanatory.
Consider the above four power domains where buffers are added, that is, PDbuf_1 to
PDbuf_4. The first driver (PDbuf_1) cannot cover the next adjacent receiver (second
power domain PDbuf_2). The third power domain is getting covered by the second, but
the third power domain (PDbuf_3) is unable to cover the fourth power domain
(PDbuf_4). PDdrv is the driver power domain and is more ON than the just-adjacent
first power domain where a buffer needs to be added.
Off =< more ON >= less ON than 2nd but more ON than 4th pd >= receiver less ON
Power domain 2 may have an AOB with secondary PG pins of the buffer connecting to
the PD1 primary supply.
The third power domain then may have a regular buffer because it gets covered by PD
2. Mixing AOB and regular buffers are permissible as long as coverage rules are
satisfied.
Here, the signal is travelling through PD2 and the tool needs to add an AOB in the least
ON domain PD2; and the signal will flow through the least ON domain PD2 to PD1. The
coverage rule will not be satisfied if a regular buffer is used. So, an AOB is a must
choice.
The number of regular buffers will be considerably higher than the AOBs placed in PD2
when signals pass through PD2. Hence, power consumption will be less in case of
AOBS. AOBs in PD2 will remain OFF when PD1 (RED color here) will go OFF because
AOBs’ secondary power pins will be connected with the primary supply of PD1. PD1
goes off, and the AOB goes off together. As per coverage rule also, in feedthrough
situation, when the signal travels from PD2 to PD1 (less to more ON), you will be
needing an AOB in PD2.
– No binding lib with PD. You need to check the viewDefinition.tcl file to see
if there are properly defined library sets and update_delay_corner command
used to bind delay corner with PD. The reportPowerDomain command can
also be used for debug.
• No available supply in PD
• Cost issue
optDesign -preCTS -drv inserts a regular buffer in the OFF domain for the
Always-On net.
• reportPowerDomain –verbose
• write_power_intent
To debug AOB-related issues, you need to query the driver and receiver instances and
the corresponding pins/ports. Some cases related to PG PIN net also come into picture.
The related PG PIN net will determine the corresponding driver/receiver’s pin power
domain.
In the following section, the relevant UPF portions are also given.
This is must for a MSV design because unless power domains are correctly
bound with the right library, the individual instance will not get the right
library cell for delay calculation. Timer, Optimizer, and all other relevant
engines will not produce accurate result.
update_delay_corner -name AV_PM_on_dc -power_domain PDdefault\
-library_set wc_0v81_1\
-opcond_library tcbn45gsbwpwc\
-opcond PM_wc_virtual
update_delay_corner -name AV_PM_on_dc -power_domain PD1\
-library_set wc_0v81\
-opcond_library tcbn45gsbwpwc\
-opcond PM_wc_virtual
update_delay_corner -name AV_PM_on_dc -power_domain PD2\
-library_set wc_0v81\
-opcond_library tcbn45gsbwpwc\
-opcond PM_wc_virtual
update_delay_corner -name AV_PM_on_dc -power_domain PD3\
-library_set wc_0v81_1\
-opcond_library tcbn45gsbwpwc\
-opcond PM_wc_virtual
1) Innovus will not insert Always-On buffers if the power net is not available
to connect the Always-On secondary power pin.
2) If you do not specify anything, by default, Innovus assumes that all power
domains’ primary power nets are available for use.
• For example, whenever IPO inserts an Always-On buffer in PD0, it will check if
the Always-On buffer’s secondary pin needs to connect to PD1’s or PD2’s
primary powers. If yes, no Always-On buffer will be inserted. If not, the Always-
On buffers can be used for buffering.
2) This command can be used after Always-On cells are inserted and placed.
For example, to control the route layer, you can use the following
command:
setNanoRouteMode -routeStripeLayerRange
• routePGPinUseSignalRoute limitations:
Recommendations
Below are the recommendations when utilizing Always-On buffers:
• reportDontUseCells
This command will give a report of all dontuse cells in the library.
• dbIsCellDontUse <always-on-buffer-cells>
Using ‘-verbose’ will give detailed messaging. The following messages say that
zero AON buffers are there in the design.
-------------------------------------------------
Always on buffers found for each power domain:
PowerDomain "PD_CORE" (pd tag = "1") has 0 always on buffer(s) to use
PowerDomain "PD_SIM_IO" (pd tag = "2") has 0 always on buffer(s) to use
PowerDomain "PD_NFC_IO" (pd tag = "3") has 0 always on buffer(s) to use
PowerDomain "PD_LCD_IO" (pd tag = "4") has 0 always on buffer(s) to use
PowerDomain "PD_EMP_IO" (pd tag = "5") has 0 always on buffer(s) to use
PowerDomain "PD_SDHC_IO" (pd tag = "6") has 0 always on buffer(s) to use
PowerDomain "PD_DV_IO" (pd tag = "7") has 0 always on buffer(s) to use
PowerDomain "PD_AO" (pd tag = "8") has 0 always on buffer(s) to use
---------------------------------------------------
This command checks if the net is being ignored in optimization for any reasons.
g) Define the power nets available per domain. The tool assumes that all the
powers are available if you do not specify the available power nets per domain.
h) Route the secondary power pin to the power net before the signal route step.
References
Innovus System Text Command Reference: This can be found on
https://support.cadence.com.
Support
Cadence Support Portal provides access to support resources, including an extensive
knowledge base, access to software updates for Cadence products, and the ability to
interact with Cadence Customer Support. Visit https://support.cadence.com.
Feedback
Email comments, questions, and suggestions to [email protected].