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.

BackgroundScope vs. hierarchyWe 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 block1set_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 methodologyWhen 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 netsOne 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 designsTraversing scopesOne 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