soc中的电源管理和ip集成:第2部分

大多数IP可以作为软宏或硬宏使用。但两者都构成了巨大的挑战。当将它们集成到低功耗设计中并进行功率感知(PA)验证时尤其如此，因为大多数IP都是自包含的，并在块级进行预先验证，并且在SoC级集成或验证时必须完整地保留它们。

第一部分本文介绍了UPF标准、宏、终端边界和相关PA验证挑战的一般背景，然后讨论了低功耗范例中的软宏IP集成和验证技术。本文将介绍硬宏IP的IP集成和验证技术。

任何设计的电源管理和电源意图都是通过UPF实现的。最新版本UPF 3.1定义了在硬宏位于所有其他权力域之外时，围绕硬宏的匿名权力域的形成。这种新的语义对于IP集成到soc和PA模拟至关重要。具体来说，直到UPF 3.1才明确定义了硬宏(以及软宏)的边界条件。因此，低功耗的硬和软宏验证解决方案并不总是直观、可移植或标准化的。

任何硬宏的电源意图(或UPF)包含各种重要信息:内部-外部或驱动-接收器电源、IP边界IO端口的相关电源、隔离单元、电平移位器、中继器单元以及电源状态和/或电压值的模式。UPF应该已经在宏(或块)级别上进行了验证。然而，就像软宏一样，一旦集成了硬宏，在整个系统中验证附带的UPF也同样重要。

SoC集成商确保这些宏被正确地连接到适当的系统级电源，并且相对于宏所在的整个系统，边界得到了适当的保护。这将确保验证工具能够验证SoC环境中的电源管理，并在设计流程的早期捕获与宏相关的问题。图1和图2显示了为硬宏构建电源管理方案的不同方法。

图1:为硬宏建模UPF

硬宏可以作为HDL行为模型进行验证，也可以作为Liberty单元进行实现。在这里，我们展示了在行为HDL中设计的硬宏的用例，但是硬宏也可以实例化为合成的门级块。在验证过程中，重要的是要记住，硬宏对于其余的设计来说只是一个黑盒。在父上下文中只有模型的接口是可见的。因此，硬宏的PA验证有几种验证用例或使用模型基于一组宏HDL模型、Liberty单元格和UPF对象在任何特定验证环境中的可用性。

图2:硬宏建模及其UPF

对于任何PA验证使用模型，这些组件的可能和可接受的组合是:

• HDL宏行为模型或门级网表，自由单元库和自成体系的UPF与宏自己的顶级权力域使用create_power_domain -elements{.}定义。
• HDL宏行为模型或门级网表，Liberty单元库和UPF没有宏自己定义的顶级权力域
• HDL宏行为模型或门级网表和Liberty单元库

所有的Liberty属性都可以很容易地从HDL和UPF属性和命令的组合中派生出来。因此，对于(a)和(b)， Liberty单元库并不是强制性的。尽管上述使用模型的每一组似乎都不同，但所有的集合都倾向于提取精确或相似的信息用于PA验证。

案例(a)最初是一个软宏，后来在实现过程中得到了强化。这里使用相同的具有自己顶级权力域的自包含UPF进行验证和实现。需要注意的是，软宏和硬宏的UPF文件都包含create_power_domain -elements{.}。因此，与软宏类似，硬宏实例的行为HDL或门级网列表属于它自己的父权力域的范围。由于宏对于其余的设计来说是一个黑盒，所以硬宏中的每个IO端口都被认为是一个终端边界。对于(b)，附带的UPF没有定义自己的顶级功率域，因此期望UPF至少为宏端口指定驱动器和接收器电源属性。在这里，硬宏实例或其任何IO端口都不属于任何父电源域的范围。这种关系同样适用于(c)。硬宏的物理解释和黑盒概念使(b)和(c)清楚地表明，无论这些IO端口的相关电源是否不同，一个硬宏的所有IO端口都将被视为终端边界。同样，就像软宏一样，在begin/end_power_model中定义但在设计中使用{UPF_is_hard_macro TRUE}实例化的功率模型也可以表示硬宏。 The UPF intent within this power model describes the intent in such a way that the macro has already been hardened through the implementation process.

对于硬宏实例，在(b)情况下(父或祖先范围未定义)和(c)情况下(UPF本身不存在)，一个大问题仍然是关于权力域的范围。对于这种情况，如果我们查询宏实例的权力域的范围，它将包括在它的祖先权力域范围。因此，宏的任何未连接的pg -pin都将关联到祖先实例电源域主电源。

然而，从硬宏观物理解释的角度来看，将这种情况下的硬宏视为属于一个独立的电源域是合适的，该电源域将由祖先域的主要电源供电。这个独立的权力域，被定义为“一个新的匿名权力域(另PD)”，在UPF 3.1中，确保宏的所有端口相对于祖先实例的功率域将被视为功率域边界端口。

由于现在很清楚，我们在这里解释的方法解决方案以终端边界概念为中心，我们需要进一步解释的模拟语义set_simstate_behavior而且UPF_simstate_behavior特别是对于没有明确定义为受任何权力域限制的硬宏，涉及“新匿名权力域”的情况。当两个{UPF_is_hard_macro为TRUE}和{set_simstate_behaviour启用}，那么port和simstate腐败语义都将应用于这样的匿名权力域宏实例。

这与以前的lrm不向后兼容;然而，它可以实现更准确和悲观的模拟。方法来覆盖损坏set_simstate_behaviour命令在特定模型或模型的特定实例上执行。此外，UPF 3.1标准还通过如下命令定义了基于端口或Liberty的损坏语义UPF_related_power / ground_端口，related_power / ground_pin,power_down_function．看起来似乎另PD、基于端口的和simstate损坏结合在一起会带走用户控制，例如另PD但是，用户仍然有显式设置宏模型或宏实例的自由simstate_behaviour来PORT_CORR_ONLY，或者他们可以把宏实例放在一个权力域，就像上面的情况(a)。

关于这些硬宏内部UPF策略的损坏语义也可能出现问题。虽然终端边界使宏的内部成为一个黑盒，例如，如果用户的UPF指定了保留，而宏内容指定了功能保留flops/锁存，验证可以在宏内建模保留行为。不幸的是，在最新的UPF 3.1 LRM中没有很好地讨论或澄清这一点。当涉及到硬宏验证时，这样的边界条件和约束允许您在不同的项目中重用验证过的硬宏。

图3显示了硬宏验证环境。硬宏命名为Hmacro实例化在tb.top_inst.Hmacroinst在左上方的层级窗口中。UPF 3.1功率模型代码显示在中上方。对应的功率域PD显示在右上方。在验证中出现的自由档案显示在最右上方。来自仿真结果的报告显示在左下角(其中仿真将功率模型视为硬宏单元格)，功率域状态和变量显示在右下角窗口中。

图3:硬宏观功率模型验证环境

在这个由两部分组成的系列文章中，我们从功耗感知设计和验证的角度确定并解决了在大型系统中集成、强化和验证软宏和硬宏的基本问题。对于硬宏和软宏，一个自包含的UPF都是必不可少的。对于硬宏，必须提供边界端口的相关电源规格，外部和内部电源及其特性，电网和交换机的内部电源状态，以及具有电源信息的内部和外部边界策略和系统级电源状态。