Understanding the fundamental parts of UPF constructions.
The Universal Power Format (UPF) plays a central role in mitigating dynamic and static power in the battle for low-power in advanced process technology. A higher process node is definitely attractive as more functionality integration is possible in a smaller die area at a lower cost. However, in reality, this comes at the cost of exponentially increasing leakage power. This is because the minimum gate-to-source voltage differential that is needed in CMOS devices to create a conducting path between the source and the drain terminals (known as threshold voltage) has been pushed to its limit. Leakage power is a function of the threshold voltage, and at smaller device geometries, its contribution to total energy dissipation becomes significant. Device supply voltage and leakage current directly contribute to leakage power; while switching activity of the capacitive load on supply voltage and its switching frequency contribute to dynamic power.
Reducing supply voltage can be used to control both leakage and dynamic power dissipation. This became a major power management trend in the last few years, largely because the chip design and verification community has more control over voltage as a design parameter than it does over integrated circuit fabrication process technologies that are more affected by the foundries. Thus, mainstream power management and reduction techniques are solely based on direct manipulation of voltage, in terms of supply power connectivity and voltage area or power network distributions on the chip.
As we will explore in this article, power domains are the fundamental parts of UPF constructions. All other predominant factors that are used to completely define the UPF are established around the power domain boundaries. Hence, the UPF power domain is a collection of instances that are treated as a group for power-management purposes. The interface of a power domain is the union of the upper boundary and the lower boundary of the power domain. And the scopes and extents of power domains are strictly defined by the elements list and upper or lower boundary interface relations.
Fundamental constructs of UPF
UPF is the power management methodology that facilitates the adoption of different power dissipation reduction techniques and allows the formalization of modeling and mapping of the power specification onto a design. UPF files for a design are generally created from the UPF specification. The UPF specification defines, as minimum requirements, the names and number of power domains, their constituent elements in terms of HDL instances, the power distribution network for the system, and the corresponding power states. Further requirements are added for different strategies depending on a number of conditions and considerations. In fact, modeling of UPF is mostly governed by target design objectives and applicable power management and reduction techniques.
The fundamental constituent parts for UPF constructions are broadly based on the following categories.
These rudimentary constituent parts are further augmented with design or HDL construct parameters. Specifically, the design scope may include hierarchical top-design-module or instance names and power domains whose boundaries are defined by the hierarchical instance paths. The power strategies — for example, isolations (ISO), level-shifters (LS), power switches (PSW), and retention flops (RFF) — also refer to design or HDL instances, ports, and nets for inferring or inserting corresponding cells and connecting power supplies and control signals. The syntax and semantics of UPF constituent parts are strictly defined in the Language Reference Manual (LRM). The syntax ensures accurate definition and semantic guides to abide with the inherent logical and lexical meaning of the defined constructs.
Importantly, UPF is the driving force for all PA design verification and implementation automation tools. These tools interpret and analyze the UPF fundamental constructs according to source and sink communication models for inter or intra domain communications, strategy association, special power aware cell (ISO, LS etc.) inferring or insertions, deployment of corruption models, debug facilitation, results reporting, and so on.
The succeeding sections focus on the fundamental construct of UPF and its methodologies for defining and distinguishing a power domain and domain boundary. This is primarily based on the LRM and secondarily on different design implementation choices. The mainstream techniques adopted today, as shown below, are mostly based on design type and the complexity demands for system-on-chip (SoC), ASIC, microcontroller unit (MCU), or processor core design implementations.
Sample list of mainstream power dissipation reduction techniques
The UPF is evolving with time and each release is not necessarily backward compatible. New releases are usually a superset of semantic and syntactic expressions from its predecessors. Hence power domain definition, syntax, and semantics in this article are explained in light of UPF 2.1 and UPF 3.0.
Example design
The fundamental concepts of UPF development for adopting multi-voltage power gating with retention and other power strategies (such as ISO, LS, and on-chip PSW) on a simple processor core design is explained through Figure 1 and 2. Figure 1 shows an HDL design block diagram with only a portion of the design overlaid by power domains with specific design instances.
Figure 1. HDL reference based design block diagram.
Figure 2 shows a typical UPF layout for the specific design of Figure 1, where the PD_top represents the default UPF top power domain that contains the cpu_top design blocks as element. The PD_sub1, PD_sub2, and PD_sub3 power domains and PD_sub3.1 (the sub domain of PD_sub3) represent specific hierarchical design instances as their elements (udecode_top, ufetch_top, umem_top, and umem_top/umem_sub, respectively). Hence the instance ualu_top naturally goes to the default PD_top power domain. The power domains also show their respective On or On-Off status. The UPF strategies (i.e., PSW, ISO, LS, enable level shifter (ELS), and RFF) are also symbolically represented. Among the several design blocks or design instances shown in Figure 1, only part of the design is distributed over four different power domains in Figure 2.
Figure 2. Fundamental building block of UPF power domains, domain boundary, power network, and relevant strategies.
Power domain and power domain boundary
As shown in Figure 1 and 2, a power domain of a top design module named cpu_top can be defined in UPF as follows.
Example 1 — Power Domain Definition
set_scope cpu_top
create_power_domain PD_top
In this definition, set_scope specifies the current scope of the power domain in the HDL hierarchical instantiation perspective, and create_power_domain defines the set of instances that are in the extent of that power domain.
Even though the power domain definition in Example 1 can be used in the UPF 2.0 LRM specification, the syntax limits backward compatibility from UPF 2.1 onward, where the power domain definition mandates including an explicit list of design instances in the UPF –elements {} option.
Example 2 — Power Domain Definition Syntax
create_power_domain domain_name
[-atomic]
[-elements element_list]
[-exclude_elements exclude_list]
[-supply {supply_set_handle [supply_set_ref]}]*
[-available_supplies supply_set_ref_list]
[-define_func_type {supply_ function pg_type_list}]*
[-update]
Through the create_power_domain command, the power domain definition defines a power domain and the set of instances through the -elements <elements_list> options that are within the extent of the current power domain. The -atomic specifies the minimum extent of the power domain. And -exclude_elements is used to filter or exclude instances from the effective <elements_list>.
Hence UPF also imperatively defines an effective list of elements often termed as <effective_element_list>, which is the result of the application of -elements and -exclude_elements. However, the effective list and the term <effective_element_list> is not a UPF command or option itself.
The create_power_domain command also defines the supply sets that are used to provide power to the instances within the extent of the power domain. The –supply option defines a supply set handle for the supply set specified for a particular power domain. A domain <supply_set_handle> may be defined without an association to a <supply_set_ref>. The <supply_set_ref> may be any supply set visible in the current scope. If <supply_set_ref> is also specified, the domain <supply_set_handle> is associated with the specified <supply_set_ref>, as shown in Example 3 below.
Example 3 — Supply Set Association of Power Domain
associate_supply_set supply_set_ref
–handle supply_set_handle
The –handle may also reference a power domain as follows.
–handle domain_name.supply_set_handle
The –available_supplies option of create_power_domain provides a list of additional supply sets that are available for the domain. The list is usually used to help implementation tools provide power connectivity to the cells inserted in this domain.
–define_func_type specifies the mapping from functions of the power domain primary supply set to pg_type attribute values in the <pg_type_list>. Note, pg_type defines the UPF_pg_type or Liberty pg_type attributes of a supply port (e.g., primary_power, primary_ground, nwell). This mapping determines the automatic connection semantics used to connect the domain’s primary supply to HDL or design instances within the extent of the domain.
–update is relevant to incremental refinement of different parameters of a power domain, and it may be used to add elements and supplies to a previously created domain later in the design implementation phase.
The common power domain definition, syntax, and semantics are also changed in the later UPF LRM (2.1 and 3.0), because the following options are deprecated.
List 1 — Deprecated Options of create_power_domain
Hence, apart from the common syntactical explanation for power domain definition through create_power_domain, it is required to know the bindings of the definition that are semantically enforced. Since the listed options of List 1 are deprecated from UPF 2.1, the new semantics impose that the -elements option must be used at least once in the specification of a power domain, using create_power_domain through one of the following procedures.
List 2 — Mandatory Usage of –elements for Power Domain Definition
It is also imperative that if the container of the <effective_element_list> is an empty list, a domain with the name <domain_name> will be created, but with an empty extent. Hence, a list of effective elements are required even for the default top-power-domain, or it is recommended to define as follows.
Example 4 — Power Domain Definition based on UPF 2.1 and UPF 3.0
set_scope cpu_top
create_power_domain PD_top -elements {.}
Where -elements {.} will include the current scope (cpu_top) and all of its descendant HDL instances in the power domain PD_top.
In contrast, power domains can also be defined as follows.
Example 5 — Variation of Power Domain Definition
create_power_domain PD_top -elements {udecode_top ualau_top … uN_top}
Here the extent of the PD_top will not include cpu_top in the power domain but would only include its descendant instances; namely udecode_top, ualu_top….until the uNth_top, if or when available. Hence, when an instance is specified in the <elements_list> of the create_power_domain command, that instance and all its children are added transitively to the power domain.
In addition, it is also important to mention here that the UPF LRM specifies that –elements {} is implicitly followed by “transitive TRUE” options, although “–transitive” is not an explicitly defined option in the create_power_domain command. The transitive nature impacts the resultant design elements or the <effective_element_list> of a power domain through the –elements {} and –exclude_elements {} options, as explained in Example 6 and Figure 3 below.
Considering a design with current scope A contains child elements B, C, and D; the child element B further branches to elements E and F, C branches to G and H, and D branches to I and J.
Figure 3. Example of power domain definition and elements processing (Courtesy: IEEE 1801-2015 LRM).
Example 6 — Transitive Nature of Design Elements in Defining a Power Domain
create_power_domain PD_test \
–elements {A A/C/H} \
–exclude_elements {A/C A/D}
Since –transitive TRUE is implicitly present in Example 6, the elements processing can be represented by Figure 4. The specified elements in create_power_domain commands that are confined in boxes and excluded are shown with strike-out lines.
Figure 4. Example of elements processing based on Example 6 (Courtesy: IEEE 1801-2015 LRM).
Finally, the transitive nature of the UPF elements specification prevails the <effective_ element_list> as {A A/B A/B/E A/B/F A/C/H} and is illustrated in Figure 5.
Figure 5. Resultant elements processed based on Example 6 (Courtesy: IEEE 1801-2015 LRM).
Hence design elements {A/C A/C/G A/D A/D/I A/D/J} are excluded from forming the resultant power domain PD_test.
It is evident from the discussion that the fundamental concepts of power domains that specify and confine certain portions of a design or element, defined through UPF create_power_domain –elements {} and –exclude_elements {}, play significant roles in establishing extents and scopes for connectivity of inter-domain and intra-domain communications.
It is critical to understand that the formation of power domains inherently defines its domain boundary and domain interface through the UPF create_power_domain command and options. All other UPF parameters are usually relevant to power domains and are developed around the power domain boundary and domain interface. Specifically, the power supply, UPF strategies, logic or supply ports and nets, corresponding connectivity, and subdomain hierarchical connections—all are established through the domain boundary and domain interface; in other words, the extents and scopes of the power domains.
The formation of a power domain boundary can be further explained through exploiting the common and formal port definitions for actual signal connections in terms of hierarchical design instances. Any port on the domain boundary possesses connectivity semantics in the higher side of the design hierarchy for inter-domain communication; also known as the “HighConn” side of ports. On the other hand, the lower side of design hierarchy connectivity semantics for intra-domain communication are known as the “LowConn” side of ports.
Obviously the context of HighConn and LowConn are always dependent on the extent of the current power domain and its relation with higher or lower hierarchical power domains. Figure 6 shows the concepts of HighConn and LowConn side of ports for a sub hierarchical power domain PD_sub1 on the domain interface with the default top power domain PD_top.
Figure 6. Concepts of HighConn and LowConn side of ports.
It is critical to understand the context between PD_top and PD_sub1 to realize the boundary interface of these two power domain. As shown in Figure 6, PD_top is the parent power domain in the context of PD_sub1; hence the UPF LRM further defines two additional terminologies to establish the context of the “interface of a power domain.”
When considering the HighConn side of each port of each boundary instance within the extent of PD_top as parent of PD_sub1, the side of the interface is known as the “lower boundary” of PD_top power domain. Conversely, when considering the LowConn side of each port of each boundary in the context of PD_sub1 as child of PD_top, the side of the interface is known as the “upper boundary” of the PD_sub1 power domain.
Obviously the union or blending of “lower” and “upper” power domains are the interface between the PD_top and PD_sub1 power domains. It is essential to understand that the concepts of the HighConn and LowConn side of ports on a power domain boundary and power domain interface will govern most of the PA verification methodologies. It is also important to know that a logic port can become a source, a sink, or both, based on the following criterion.
List 3 — Criterion for Logic Ports to become a Source or Sink
A primary input port is assumed to have an external driver and therefore is a source; such a port has a default driver supply if it does not have an explicitly defined UPF_driver_supply attribute. An internal port that is not connected to a driver is not a source, and therefore does not have a driver supply in the design. To model this in verification, an anonymous default driver is created for such an undriven port. This driver always drives the otherwise undriven port in a manner that results in a corrupted value on the port.
For a logic port that is connected to one or more receivers, the supplies of the connected receivers are all receiver supplies of the port. A primary output port is assumed to have an external receiver and therefore is a sink; such a port has a default receiver supply if it does not have an explicitly defined UPF_receiver_supply attribute. An internal port that is not connected to a receiver is not a sink, and therefore does not have any receiver supplies.
The UPF_driver_supply and UPF_receiver_supply are supply set attributes used to specify the driver supply of a macro cell output port or the receiver supply of a macro cell input port. They can also be used to specify the assumed driver supply of external logic driving a primary input or to specify the assumed receiver supply of external logic receiving a primary output, when the macro is implemented separately from the context in which it will be instantiated. These attributes are ignored if applied to a port that is not on a macro boundary.
Apart from the regular power domain, there is also a simple container for power domains defined through the UPF create_composite_domain command. The composite domains are usually composed of at least one or more domains, identified as subdomains. The syntax and semantic explanation are given below.
Example 7 — Composite Power Domain Definition Syntax
create_composite_domain composite_domain_name
[-subdomains subdomain_list]
[-supply {supply_set_handle [supply_set_ref]}]
[-update]
Unlike a regular power domain, a composite domain has no corresponding physical region on the abstraction space or real silicon. The –subdomains <subdomain_list> is the container of subdomains, and ‑supply functionality is exactly the same as –supply for create_power_domain.
Though attributes like power states and the primary <supply_set_handle> can be specified on a composite domain, these attributes have no effect on its subdomains. However, there are specific UPF commands and strategies that can be imposed on the composite domain and will be applied to each of the subdomains in the <subdomain_list>. The list of applicable UPF commands and strategies on composite domains is shown below. These commands will be applied to all subdomains in the <subdomain_list> only if they are appropriate.
List 4 — Applicable UPF Commands on Composite Domains
Hopefully this discussion about the formation of regular and composite power domains makes it evident that the following UPF attributes are established within the extent of power domains.
List 5 — UPF Attributes Established Around Power Domains
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply