Considerations for writing UPF for a hierarchical 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.