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 designs interface. With the addition of power intent, you will also
need agreement of the supply ports for your designs 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 designs 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