理解UPF功率域和域边界

                            理解UPF功率域和域边界

 

一、介绍

        在先进工艺技术的低功耗之争中，统一功率格式(UPF)在降低动态和静态功率方面起着核心作用。较高的流程节点绝对具有吸引力，因为在较小的die区域中可以以较低的成本集成更多的功能。然而，在现实中，这是以成倍增加的泄漏功率为代价的。这是因为CMOS器件在源极和漏极端子之间创建传导通路所需要的最小电压差(称为阈值电压)已经被推到了极限。泄漏功率是阈值电压的函数，在较小的器件几何形状，它对总能量耗散的贡献变得重要。器件电源电压和漏电流直接影响漏功率；而电容负载对电源电压的开关活动及其开关频率对动态功率有影响。

       由此可见，降低电源电压可以同时控制漏电和动态功耗。在过去的几年里，这成为了一个主要的电源管理趋势，很大程度上是因为芯片设计和验证社区有更多的控制电压作为设计参数，而不是集成电路制造工艺技术，后者更受铸造厂的影响。因此，主流的电源管理和降低技术仅仅是基于直接操纵电压，在芯片上的电源连接和电压区域或电网分布。

       然而，这些都不足以理解和反映功率感知验证计划或功率意图，而功率意图对于在寄存器传输级别(RTL)启动功率或电压感知验证(甚至在gate-level综合之后)是必要的。

 

二、UPF的基本构造

       UPF是一种电源管理方法，它有助于采用不同的电源耗散减少技术，并允许对电源规范的建模和映射进行形式化。设计的UPF文件通常是根据UPF规范创建的。UPF规范定义了作为最低要求的功率域的名称和数量，它们在HDL实例中的组成元素，系统的功率分配网络，以及相应的功率状态。根据一些条件和考虑因素，为不同的战略增加了进一步的要求。实际上，UPF的建模主要是由目标设计目标和适用的电源管理和减少技术控制的。

       UPF结构的基本组成部分大致基于以下类别：

UPF设计范围为电源域、

电源域接口和电源域边界、

电源和电源网络、

主电源和主地面电源的状态和运行方式、

电源策略

       这些基本组成部分进一步增强设计或HDL构造参数。具体来说，设计范围可能包括分层的顶层设计模块名或实例名和power域，其边界由分层实例路径定义。例如，电源策略，隔离(ISO)，电平移位(LS)，电源开关(PSW)，和保留flops (RFF)也参考设计或HDL实例，端口，和网络推断或插入相应的细胞，连接电源和控制信号。UPF组成部分的语法和语义在语言参考手册(LRM)中严格定义。语法确保了准确的定义和语义指南，以遵守所定义构造的内在逻辑和词汇意义。

       重要的是，UPF是所有PA设计验证和实现自动化工具的驱动力。这些工具根据域间或域内通信的源和汇聚通信模型、策略关联、特殊的power感知单元(ISO、LS等)推断或插入、损坏模型的部署、调试便利、结果报告等来解释和分析UPF基本构造。

       随后的章节将重点讨论UPF的基本构造以及定义和区分权力域和域边界的方法。这主要基于LRM，其次是基于不同的设计实现选择。目前采用的主流技术，如下所示，主要是基于SoC、ASIC、MCU或处理器核心设计实现的设计类型和复杂性要求。

 

 2.1、主流功耗降低技术的样本列表

电源控制或电源关闭
功率门控与状态/数据保留
低功耗待机，状态/数据保留
多电压设计，性能随需应变
动态电压(和频率)缩放
自适应电压(和频率)缩放

 

        UPF随着时间的推移而发展，每个版本并不一定是向后兼容的。新版本通常是其前身的语义和语法表达式的超集。因此，本文中的power域定义、语法和语义将根据UPF 2.1和UPF 3.0进行解释。

 

三、例设计

       图1和图2解释了在简单处理器核心设计上采用多电压功率门控和其他功率策略(如ISO、LS和片内PSW)的UPF开发的基本概念。图1显示了一个HDL设计框图，其中只有部分设计由具有特定设计实例的power域覆盖。

 3.1、图1所示。基于HDL参考的设计框图

        

 

 3.2、图2显示了图1特定设计的典型UPF布局

• 其中PD_top表示包含cpu_top设计块作为元素的默认UPF top power域。PD_sub1、PD_sub2和PD_sub3 power域和PD_sub3.1 (PD_sub3的子域)将特定的层次设计实例作为它们的元素(分别为udecode_top、ufetch_top、umem_top和umem_top/umem_sub)。因此实例ualu_top自然会转到默认的PD_top power域。异能域也显示它们各自的开或关状态。UPF战略(即、PSW、ISO、LS、enable level shifter (ELS)和RFF)也用符号表示。在图1中显示的几个设计块或设计实例中，只有部分设计分布在图2中的四个不同的power域上。图2。UPF电力域、域边界、电网的基本构建模块及相关策略

        

 

 3.3、POWER DOMAIN AND POWER DOMAIN BOUNDARY

       如图1和图2所示，可以在UPF中定义顶层设计模块cpu_top的电源域，如下所示。

 

 3.4、示例1电源域定义

set_scope cpu_top
create_power_domain PD_top

 

• 在这个定义中，set_scope在HDL分层实例化透视图中指定权力域的当前范围，create_power_domain定义在该权力域范围内的一组实例。
• 尽管示例1中的power域定义可以在UPF 2.0 LRM规范中使用，但语法限制了从UPF 2.1开始的向后兼容性，其中power域定义要求在UPF elements{}选项中包含一个显式的设计实例列表。

 

 3.5、示例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]

 

       通过create_power_domain命令，power域定义通过-elements <elements_list>定义一个power域和一组实例。当前电源域范围内的选项。-atomic指定了电源域的最小范围。-exclude_elements用于从有效的elements_list>中过滤或排除实例。

       因此UPF还命定地定义了一个有效的元素列表，通常称为effective_element_list>，它是应用-elements和-exclude_elements的结果。然而，有效列表和术语effective_element_list>本身不是UPF命令或选项。

       create_power_domain命令还定义了用于向power域范围内的实例提供电源的电源集。电源选项为为特定电源域指定的电源集定义电源集句柄。一个域& lt; supply_set_handle>可以在不与supply_set_ref关联的情况下定义。& lt; supply_set_ref>可以是当前范围内可见的任何供应集。如果& lt; supply_set_ref>还指定了域supply_set_handle>与指定的supply_set_ref>关联，如下面的示例3所示。

 

 3.6、例3 电源域的供电集关联

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

 

• create_power_domain 的-available_supplies选项提供了该域可用的其他供应集的列表。该列表通常用于帮助实现工具提供到插入到此域的单元格的电源连接。
• -define_func_type 指定从电源域主电源集的函数到pg_type_list>中的pg_type属性值的映射。注意，pg_type定义了供应端口的UPF_pg_type或Liberty pg_type属性(例如primary_power、primary_ground、nwell)。该映射确定了用于将域的主要供应连接到该域范围内的HDL或设计实例的自动连接语义。
• -update 是相关的一个电源领域的不同参数的增量细化，它可能被用来添加元素和供应到之前在设计实现阶段后期创建的领域。在以后的UPF LRM(2.1和3.0)中，还更改了常用的power域定义、语法和语义，因为不赞成使用以下选项。

 

• List 1 Deprecated Options of create_power_domain

[-include_scope] [-scope instance_name]

       因此，除了通过create_power_domain对power域定义的常见语法解释外，还需要知道在语义上执行的定义的绑定。由于列表1中列出的选项不支持UPF 2.1，所以新的语义要求-elements选项必须在power域规范中至少使用一次，通过以下过程之一使用create_power_domain。

    List 2 Mandatory Usage of -elements for Power Domain Definition

• -elements may be present during definition of the power domain in the first place, or...
• It may be added later during the subsequent updates of the power domain using the -update option.

       It is also imperative that if the container of the is an empty list, a domain with the 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.

 

 3.7、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

       Example 4 Power Domain Definition based on UPF 2.1 and UPF 3.0

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 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 of a power domain through the –elements {} and -exclude_elements {} options, as explained in Example 6 and Figure 3 below.

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 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 on the following page 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.

       It is critical to understand the context between PD_top and PD_sub1 to realize the boundary interface of these two power domains. 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."

Figure 6. Concepts of HighConn and LowConn side of ports

        

       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:

• The LowConn of an input or inout logic port whose HighConn is connected to an external driver is a source.
• The HighConn of an output or inout logic port whose LowConn is connected to an internal driver is a source.
• The LowConn of an output or inout logic port whose HighConn is connected to an external receiver is a sink.
• The HighConn of an input or inout logic port whose LowConn is connected to an internal receiver is a sink.
• For a logic port that is connected to a driver, the supply of the connected driver is also the driver supply of the port.

       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  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 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 . The list of applicable UPF commands and strategies on composite domains is shown below. These commands will be applied to all subdomains in the only if they are appropriate.

List 4 Applicable UPF Commands on Composite Domains:

connect_supply_net map_power_switch map_retention_cell set_isolation set_level_shifter set_repeater set_retention use_interface_cell (UPF 3.0 syntax for map_level_shifter_cell and map_isolation_cell)

       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:

• The power supply
• UPF strategies
• UPF logic or supply ports and nets
• Corresponding connectivity
• Subdomain hierarchical connections
• Extents and scope of power domains

 

四、CONCLUSIONS

        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.

 

五、REFERENCES

1. P. Khondkar, P. Yeung, et al., "Free Yourself from the Tyranny of Power State Tables with Incrementally Refinable UPF", DVCon, February-March, 2017.
2. Design Automation Standards Committee of the IEEE Computer Society, "IEEE Standard for Design and Verification of Low-Power, Energy-Aware Electronic Systems", IEEE Std 1801-2015, 5 December 2015.
3. P. Khondkar, "Power Aware Libraries: Standardization and Requirements for Questa® Power Aware", Verification Horizons Journal, pp. 28-34, Vol. 12, Issue 3, November 2016.
4. P. Khondkar, P. Yeung, D. Prasad, G. Chidolue, M. Bhargava, "Crafting Power Aware Coverage: Verification Closure with UPF IEEE 1801", Journal of VLSI Design and Verification, pp.6-17, Vol. 1, November 2016.
5. P. Khondkar and M. Bhargava, "The Fundamental Power States: The Core of UPF Modeling and Power Aware Verification", Whitepaper at Mentor.com, December 2016.
6. P. Khondkar. The Concepts and Fundamentals of Power Aware Verification, first edition, New York, Springer, communicated, 2017.

Back to Top