Considerations for writing UPF for a

hierarchical flow
Jeffrey Lee and Mary Ann White - April 06, 2012

Introduction
Writing power intent for a design using the IEEE 1801 Unified Power Format (UPF) is generally an
easy and straight-forward task. If the design will be optimized in a flat fashion (e.g. the entire
design is optimized top-down in a single session), then writing the power intent is fairly simple.

Situations such as being too rigid in where your power management cells need to be implemented
and writing power intent for hierarchical designs can make writing UPF a much more difficult task.
This article details the considerations that you need to take into account when writing UPF for a
hierarchical design methodology.

Background
Scope vs. hierarchy
We are all familiar with the term hierarchy; however, the term scope is less familiar. A scope is
where you are creating the necessary identifiers to define your power intent from UPF. Consider
this command,

create_power_domain PD1 –elements {block1} –scope {block1}

This creates an identifier, PD1, at the scope (or logical hierarchy) of block1. Thus, you have a power
domain named PD1 defined at the hierarchy of block1 whose element is block1. Any references to
that power domain will be using the full hierarchical name of that power domain: block1/PD1. If you
had not used –scope when you created your power domain using create_power_domain PD1
–elements {block1}, you will create a power domain named PD1 at the current scope, the design
root, and its full hierarchical name would be PD1.

Remember, you can always look down the hierarchy tree and use any identifiers below your current
scope, but you cannot look up the hierarchy for identifiers above your current scope. This will be
very important when you have power domains at different scopes and want to rely on UPF to pull
signals across a design hierarchy instead of manually pulling the signal yourself.
For example, if you have to define a retention strategy for a child power domain and the control
signals only exist at the top level, there are two different ways that you can do this:

1. Manually create the ports in your RTL on the power domain boundary to serve as control ports for
the retention registers and then define the retention strategy at the scope of the power domain.

set_scope block1
set_retention PD1 …
set_retention_control PD1 –save_signal {my_save_port high}
–restore_signal {my_restore_port high}

2. Define the retention strategy from the top level scope and allow UPF semantics to
pull the signals from the top level into the power domain whose sequential elements are
to be retained.

set_retention block1/PD1 …
set_retention_control block1/PD1 –save_signal {retention_save high} \
–restore_signal {retention_restore high}

Hierarchical design/IP reuse methodology

When designing a block to be integrated into a larger design, it is important to make sure that you
have agreement regarding your design’s interface. With the addition of power intent, you will also
need agreement of the supply ports for your design’s interface. This is important from the
perspective of how your design communicates with the larger design it will be integrated into. Any
supplies you need to bring into your design needs to be connected from the outside world. If you
passed the block as a macro, the supply ports would already be defined as PG (power and ground)
pins and the integrator would need to connect the supplies in the top level to the PG pins of your
block.

Whether or not you want to include power management cells inside your design’s interface is your
choice. There are pros and cons to doing it yourself vs. having the integrator do it. If you want to be
absolutely certain your design is protected, you should consider the worst case and include the
necessary power management cells. However, this may result in an area penalty if the power
management cells are not necessary. If you are comfortable with letting the integrator take care of
the protection for your design, then have the integrator write the UPF to implement them as needed.

When integrating designs, you should make sure you know the supply ports of the design being
integrated as well as its operating states. This is important since any supplies that are not
generated within the design need to be brought in from the top level during integration. Having two
supplies connected through a supply port is a very clean connection semantic. It also allows tools to
know that the two supplies are really the same supply without having to guess whether or not that is
true.

Also, when referring to the power domains of any design(s) being integrated, remember that the
power domain and other power intent identifiers are defined at the scope of the design. This means
that if you need to reference the power domain of the design being integrated, you need to reference
it by instance_name/power_domain_name.

Supply sets and supply nets

One other consideration that needs to be taken into account for the overall low power design
methodology is the actual style of specification of the supplies in the UPF power intent itself – will
you be following a supply set or supply net based methodology during the front-end verification and
synthesis process.

The original UPF specification introduced the capability of defining supply nets and ports as part of
the power intent, which represent the power and ground rails in a design. The advantage of a
supply net flow is that all of the supplies are defined up front and the UPF used for verification at
RTL is similar to the UPF used post-route.

An addition to the IEEE 1801-2009 standard introduced the concept of a ‘supply set’ which
represents nets that can be used in pairs, such as power and ground (much like an electrical plug)
which helps in development and integration of soft-IP.

Supply sets enable an ASIC-Style or IP reuse methodology where front- and back-end
implementation can be performed independently. With supply sets, front-end (or soft-IP) developers
are no longer required to supply physical information such as supply nets or ports. The physical
information is then refined as the design moves to the back-end implementation process.

Use of supply sets and nets must be interoperable. UPF usage of supply nets existed long before
supply sets were introduced so legacy designs defined with supply nets are able to be integrated
with designs specified with supply sets.

Power intent for hierarchical designs

Traversing scopes
One of the most important items to decide upon, when writing UPF for your design, is whether or
not you need to define power domains somewhere other than the top-level of your design. You can
make your specification easier by placing all your power domains in the top level scope itself.

If you are writing UPF for the entire design, it might be beneficial to utilize a single scope approach
and place the scope of all the power domains in the top level scope. This will save you the effort of
creating multiple supply ports and connecting your power supply network since all of the supplies
you will need to manipulate are defined at the top-level scope.

Otherwise, if you are integrating multiple designs into a larger context or re-using IP(s) that have
their own power management cells, it may be better to use a multiple scope approach. In such a
case, supply ports have already been defined so it would be more convenient to connect your power
supply network to the supply ports than to try and re-write the UPF for these blocks that reside in
the top level scope of your design.

Writing power intent for a design utilizing multiple scopes requires you to keep the power intent of
each design self-contained. This means that each RTL design plus its corresponding UPF intent can
be simulated separately and does not require a full chip context for simulation. Designs of this
nature are naturally pre-disposed to using a bottom-up hierarchically flow. Power domain
definitions
The power domain for each hierarchical block should be in the design itself. For example, the
following is an example for creating the power domain PDblock1 in the scope of block1.

create_power_domain PDblock1 –elements {block1} –scope {block1}

The name of the power domain, when referenced from the top level is “block1/PDblock1”.
It is important to remember to use the hierarchical name of the power domain since the power
domain’s identifier is defined in the namespace of the design -- not the top-level. Thus, when setting
a level shifter strategy for the ports of the power domain, you would use “block1/PDblock1” instead
of “PDblock1” as the identifier exists in block1.

Using –scope in create_power_domain is the same as changing to the scope specified and creating a
power domain for the elements specified. Therefore,

create_power_domain PDblock1 –elements {block1} –scope {block1}

does the same thing as the following:

set_scope block1
create_power_domain PDblock1 –include_scope

Both methods of creating the power domain are valid and can be used. However, it is usually easier
to just define everything from the top level scope and only change scopes as necessary.

Boundary constraints
It is important to know the boundary constraints for the design during optimization. In the absence
of any information regarding the boundary, it is left up to the individual tools to decide how to
handle the primary input and output ports. For example, Design Compiler and IC Compiler will
assume the top level power domain’s primary supplies are related to the primary input and output
ports.

By defining the supply related to the primary input and output ports, you are telling the tool what
voltage the input ports can be driven and what voltage the output ports can drive. This can
influence level shifter insertion by telling the optimization engine that there is a voltage violation at
the top level boundary. If you are using the –source | -sink | -diff_supply_only options for setting
isolation strategies, the related supply tells the tool what supply is powering the cell on the other
side of the domain boundary which can then be used to determine whether or not isolation is
necessary based upon your constraints.

Supply net related to the primary inputs/outputs

If you want a different supply to power the port, you will need to relate that supply to the port. You
can do this in one of 2 ways:

1. Use the IEEE 1801 set_port_attribute command

2. Use the Synopsys set_related_supply_net command

set_port_attributes
You can specify the driving supply set and the receiving supply set for all of your hierarchical ports
with the set_port_attributes command. This is the preferred method of applying boundary
constraints if your design is using supply sets. However, the IEEE 1801 standard states it is an
error if the actual supply set of the cell driving or being driven by port is not the same as what is
listed in the command. This means that the true/actual driver of the port needs to match the supply
listed in the command.

● To define the supply set powering the cell driving a hierarchical port (input port)
set_port_attributes –driver_supply supply_set
● To define the supply set powering the cell driven by hierarchical port (output port)

set_port_attributes –receiver_supply supply_set

You will need to make sure that the supply set used to define your port boundaries matches the
actual driving/receiving cells in your integrated design. If it does not match, then the
set_port_attributes command for the port should be rejected. If the supply set is rejected, the
boundary constraints for the hierarchical block should be revisited so that it is correct relative to the
integrated context.

set_related_supply_net
The set_related_supply_net command is a Synopsys proprietary command used for boundary
constraints or to override the related supply net of a leaf cell’s signal pin. Synopsys originally
introduced this command because the original UPF specification did not support this concept.
Set_port_attributes was introduced in IEEE 1801 to work with supply sets but the ability to override
the related supply net was not covered in the 2009 version. Although this command is not included
in the IEEE 1801 standard, there are third party vendors that do support set_related_supply_net.

This command is the preferred method of applying boundary constraints if your design uses only
supply nets. The command will relate the specified power and/or ground net to the port or pin
specified. It is an error if you try to relate a supply net that is not available in the power domain
which the port/pin resides in.

When set_related_supply_net is used on a primary port, an input port assumes the supply net
specified is the driver of the input port and an output port assumes the supply net specified is the
receiver of the output port. When set_related_supply_net is used on a leaf cell’s signal pin, it
overrides the related_power_pin attribute specified in Liberty. This allows you to relate a supply net
that is not connected to the leaf cell to the leaf cell’s signal pin.

Off-chip supply considerations

Appropriate supply set(s) or supply net(s) need to exist in the designs that are implemented -- this is
true even if the supply is not used in the design at all such as off-chip supplies.

Supply sets
You will need to create a supply set to represent the off-chip supply that will be related to your
primary ports and used as the driver or receiver of your ports. If you need to use the off-chip supply
set to power any cells in the design, you should create a power port and connect the power function
of the supply set to the power port. This way, when you integrate the design into the larger design,
you will be able to connect the correct supply to the supply port of the design to power the cells
using the off-chip supply.

Supply nets
You will need to create a supply port for the supply net used as your off-chip supply. Without a
supply port, the proper port states of the off-chip supply net cannot be annotated. While this may
not be a large concern, it may impact the ability to insert level shifters that can shift all possible
states of the design.

Power management cell insertion

If the tool can detect a voltage violation between the port and the core logic of the design, the
appropriate level shifter cell will be inserted.

Having a discreet voltage difference between the off-chip and the core logic supplies is enough to
trigger level shifter insertion on the primary ports. Having the power state table include other
voltage states of the off-chip supply will enable level shifter insertion to be performed on a wider
range of voltages and help ensure a level shifter that can shift to all possible states is inserted.
Defining an off-state of the off-chip supply will enable electrical rule checkers to report any isolation
violation between the primary ports and the core logic of the design. This can be useful if you have
input or output isolators for your design as you may get false redundant isolation warning messages
without the off-state defined. If you do not intend to insert isolation cells in the design to protect it
from off-chip logic, then you may want to consider not defining any off-states for the off-chip supply.
Power management cell considerations

Level shifter constraints

UPF allows for level shifters to be added at any power domain boundary where the tool can detect a
voltage violation. All power domains intrinsically have a level shifter strategy that applies to both
inputs and outputs where the tool should be able to determine its location automatically.

For example, Synopsys implementation tools will use both the intrinsic level shifter strategies and
the user defined level shifter strategies to determine an optimal solution to minimize the number of
level shifters in the design and resolve all voltage violations. To this end, the location specified in a
level shifter strategy should be seen as reducing the overall solution space for level shifter insertion
rather than directives to only insert level shifters in a particular location.

Self and parent locations

The location self directive inserts the level shifter cell inside the power domain with a direct
connection to the power domain boundary. The level shifter in location self is connected to the low-
conn side of the port in question.

The location parent directive inserts the level shifter outside the power domain with a direct
connection to the power domain boundary. The level shifter in location parent is connected to the
high-conn side of the port in question.

Ambiguity in location
When you have a net that traverses the top level to go from the source power domain to the sink
power domain, a level shifter in location parent can be ambiguous since there can be two ‘parent’
locations for the net (see Figure 1). Each power domain has a location parent; therefore, if the
source power domain allows for insertion only in self and the sink power domain has no limitation
for inserting level shifters, there are now three valid locations for the level shifter to be inserted: self
in the source domain, parent of the sink domain and self in the sink domain. If the level shifter is
inserted in the parent of the sink domain, this is still respecting the level shifter locations specified.

Figure 1: Valid Locations for Level Shifters

Isolation constraints
Isolation cells can be inserted based on the driver and/or receiver of a hierarchical port on a power
domain boundary. When isolation strategies use –source <supply set name>, the supply set
powering the cells driving the port is compared against the supply set specified with –source to
determine whether or not an isolation cell is to be inserted relative to that port. When using –sink
<supply set name> with an isolation strategy, the supply set powering the cells being driven by the
port are compared to the supply set specified with –sink to determine whether or not an isolation
cell is to be inserted relative to that port.

When using –source/-sink/-diff_supply_only, it is important to make sure the primary ports are
properly annotated with the supply set related to the driver/receiver of the port to ensure the proper
isolation cells are inserted by their isolation strategies. Since isolation cell insertion may traverse
power management cells, there may be cases where the true source or the true sink of the port is
different than the cell that is directly driving the port or being driven by the port.

Isolation cells are only inserted where an isolation strategy specifies the isolation cell should be
inserted. The map_isolation_cell command is not mandatory for isolation cell mapping since the tool
can select the appropriate cell from all available isolation cells in the library. If you wish to restrict
the isolation cells available for mapping, you can use the map_isolation_cell to tell the tool which
library cells to use explicitly.

Design Compiler is also able to add an always-on inverter cell to the control of a technology isolator
to build the proper technology isolator if the specified enable is not found. The technology isolator
plus the always-on inverter is considered the isolation cell that satisfies the isolation strategy.

Location parent
It is important to remember that UPF commands can access any netlist objects that are at the
current scope and below. This means that if you set the scope to a lower level, you will not be able
to reference anything above that scope. Thus, when setting isolation cells in location parent, you
may need to use the full hierarchical name of the power domain in order to properly define your
isolation strategy. The same applies to any control nets and supplies that you need for your isolation
strategy.

It is perfectly legal UPF to specify location parent isolation for a domain two levels of hierarchy
down from the current scope, and use a port in the current scope as the control signal as long as you
are referring to the power domain with its full hierarchical name. Otherwise, you will be trying to
refer to a power domain of the same name in the current scope which would be incorrect.

If your design needs an isolation cell in location parent relative to the top level of the design, you
should not be attempting to add the location parent isolation strategy as the tool should warn, and in
some cases error out, that you are trying to implement isolation cells that are outside of the current
design. Inference of enable level shifters
Enable type level shifters are inserted where there is a voltage violation and an isolation constraint.
Thus, you will need an isolation strategy on the domain boundary where you want the enable level
shifter. The power pin of type primary power related to the output of the enable level shifter will
come from the isolation supply set, or isolation power and isolation ground, of your isolation
strategy. The control net will also be connected per the isolation strategy. The supply net related to
the input of the enable level shifter should be derived by the level shifter insertion algorithm and
connected to the enable level shifter.

Retention constraints
When defining a retention constraint, it is important to remember that only sequential elements will
be converted to retention registers. If you are using a macro with sequential elements, there is no
need to specify a retention strategy for the macro. You will need to connect the retention control
nets of the macro just as you would for the other signal nets of the macro.

When defining a retention strategy for an entire power domain or a logical hierarchy, all sequential
elements of that power domain or logical hierarchy will be retained. When defining retention
strategy, sequential elements will need to be maintained in the design to ensure the retention
strategy is not changed.

Unlike level shifters and isolation cells that can be inferred from constraints, retention register
mapping requires the usage of the map_retention_cell command. The map_retention_cell command
is the only way for tools to know what retention registers should be used. If you want to specify the
exact technology library cell to use instead of giving the tool a type to select from, you may also
specify the individual library cell name in the –lib_cells argument to map_retention_cell.
UPF allows for retention registers to change states when the clock is high, the clock is low, or
asynchronous to the clock (clock free). The type of retention register is only known when the
map_retention_cell command is used.

To specify a type of retention cell, use the –lib_cell_type argument of the map_retention_cell
command. This instructs the tool to select retention registers only of the specified type. Ensure the
type specified is the same as the type shown in the Liberty model of your retention register (Liberty
attribute retention_cell_type).

Summary
Almost every device available on the market today has low power requirements, regardless of
whether it’s a mobile application or not. Given the complexities of today’s products driven by
consumer demand for more and more functional consolidation, a hierarchical design methodology is
essential to be able to handle large designs and IP reuse.

UPF can be used for hierarchical designs today and this article outlined the considerations that you
need to keep in mind for development of your power intent. Many of the tools that support UPF
available on the market today should be able to handle the guidelines provided in this article. The
Synopsys Galaxy Implementation Platform (Figure 2) is ready to help you with your low power
hierarchical designs today from verification through implementation.
Figure 2: Low power support is available throughout the Galaxy Implementation Platform

About the authors

Jeffrey Lee is a staff corporate application engineer for Power Compiler specializing in low power.
He has been with Synopsys for 10 years working on products including Design Compiler, (V)HDL
Compiler and SystemC Compiler. Lee has a BS EE degree from the University of Texas at Austin.

Mary Ann White is the product marketing director for Galaxy low power implementation products at
Synopsys. She has more than 25 years of experience working in the EDA and semiconductor
industries. White has a BS EECS degree from UC Berkeley.

This posting is part of the EDA Designline power series and is archived and updated. The root is
accessible here. Please send me any updates, additions, references, white papers or other materials
that should be associated with this posting. Thank you for making this a success - Brian Bailey.