现代微控制器系统的能耗

现代微控制器系统的能耗

是否有一种策略可以同时应用于基于 IP 的半导体产品和标准半导体产品，允许设备用户以简单可靠的方式控制能耗，让用户全面了解 *** 作，并保持安全和安全的条件？改进的结果可能伴随着对 *** 作模式的控制程度的提高。

无论应用在哪个领域，当今电子系统取得市场成功的一个关键因素是最大限度地减少其能源需求。以电流或稳态功率表示组件效率的传统方法——每 MHz 微安 （µA） 或微瓦 （µW） 似乎不再适用。能量存储系统既不存储 µA 也不存储 µW，它们存储“焦耳”——换句话说，就是能量。最新一代的超低能效 MCU 遵循与高性能处理器类似的电源管理策略；他们将 DC/DC 转换器与线性稳压器结合使用。

一个有趣的问题是，相同的供电方法是否可以在不通过软件功能增加能耗的情况下用于各种应用？用户能否从应用层面细化设计，实现系统能耗最优？能源配置优化的应用程序是否可行，是否可以在开发过程中和现场进行适当的维护、扩展和调整？

一旦明确定义了应用程序，能耗就可以与系统目标保持一致。有一些众所周知的方法可以在设计中实现所需的控制水平。假设只有室温下的静态环境，这非常简单。已发布的 MCU 数据表提供了适用于各种不同情况的数据。MCU 供应商针对许多不同的场景和条件提供了 150 多种不同的电流参数。

对增加程序代码和数据的内存需求的快速增长是转向更小的工艺几何形状的驱动因素之一。这在活动模式（RUN 模式）下提供了更低的能耗。然而，由于不需要的泄漏电流，在睡眠模式下继续运行的设备的能源需求显着增加。这种影响在室温下很显着，在较高温度下可能会很严重。

消费电子产品的早期开发使用内置在较小工艺几何形状中的硅，揭示了电压和温度对能量预算的影响。已经开发了电源门控、电压和频率缩放来应对这些因素。此类技术已成为 MCU/SoC 的低功耗标准。但是对于系统设计者来说，问题仍然存在：

供应商使用了哪些方法和指南，哪些指南在我的应用程序环境中很重要？他们匹配吗？

哪种运行模式对能耗的影响最大？

第一个因素是特定能量模式的持续时间（花费的时间），考虑到每种模式对总能量消耗的贡献 - 以及动态切换条件：

运行模式 （1） 对能耗有直接影响——正在执行的功能和代码。

睡眠模式 （2） 具有其自身的特征级能耗 - 功能和代码暂停，需要外部事件才能重新启动。

两种模式（1 和 2）都会增加能源消耗——运行模式和睡眠模式都会增加能源消耗。

非开/关可切换功能的切换条件

【图1 | EEMBC 能源基准有两个阶段。］

在广泛使用的 EEMBC 能源基准（基本序列如图 1 所示）中， *** 作模式（1 - 活动/运行）执行定义的代码。用户选择工作模式，例如 LDO 或 DC/DC 电压调节、工作频率等。他们可以为自己的应用选择最低能耗的模式。具有 32 kHz 石英或振荡器的实时时钟功能 （RTC/RTCC） 处于活动状态，代表能量消耗的第二部分。周期为一秒。该基准衡量的是能源消耗而不是电流消耗。该基准的未来几代还将增加一个考虑开关损耗的因素。工作模式主导当前MCU/SoC的能耗；在大多数情况下，较高的工作电流由较短的执行时间来补偿。在一秒钟内，开关损耗不起主要作用。然而，开关损耗的这一方面——图 1 中的红色阴影区域——正变得越来越重要。

【图2 | 基本电源门控］

基本电源门控

图 2 描述了电源门控的基本原理。关闭部分电路应该可以减少漏电流损失。那些不需要的电流使电路中的电容放电：温度越高，它们放电的速度越快。这些电容具有寄生和集成特性。它们将电流峰值导致的电压降限制在安全水平。当实施电源门控时，动态能量消耗会恶化，并且开关条件会进一步增加非生产性能量损失。在许多 *** 作情况下，电源的开启和关闭与电源门控并行。这进一步增加了非生产性动态和开关损耗。

哪种运行条件对能耗的影响最大？第二个必须考虑的因素是系统环境，例如能源、温度或温度曲线。

能源提供对工作电压的调节，例如通过线性调节器或DC/DC转换器。在小型 MCU 中，通常一次只使用一个稳压器，但在高性能系统（多核 SoC）中，多个电源同时运行。

当能量损失（例如泄漏电流）占能量消耗的主要部分时，需要考虑温度曲线。这可能发生在所有三种 *** 作模式中。

向 MCU/SoC 用户开放的选项

*** 作模式的不同功能通常由某种形式的电源管理器管理。初始设置和不同能量模式之间的转换都是如此。 *** 作模式是根据内部系统分区和设计以及 MCU/SoC 硬件的最终行为建立的。

目前存在的几代低功耗模块中提供的最终 *** 作模式基本上是通过指令和能量模式位和数据调用的；以及用户设置的控制位和控制数据。此外，可以提供软件库元素，例如 API。这些特性导致了面向应用的节能系统和产品，但范围可能有限。

梦想与现实

在一家公司的许多应用和产品线中，采用来自不同 MCU/SoC 供应商的多个组件以及一系列能源来实现最大性能和应用寿命。这些设备的能量模式和功能由指令和控制位/数据直接激活。是否可以通过嵌入在软件代码中的功能实现对功能和能量模式的直接控制？对不同模式的访问也可以通过仅由监督模式通过中央程序（例如 *** 作系统或电源管理器）访问来确保安全。受限访问通过将系统带入关键 *** 作条件的模式更改来提供安全 *** 作。软件定义的能源情况是灵活的；但从能源的角度来看，经常改变 *** 作模式的软件解决方案不是最佳的。每个代码执行都使用（激活）MCU/SoC 硬件的主要部分，并具有相应的能量需求。

在 MCU/SoC 中防止不必要的访问仍然是一个主要目标，但尚未完全实现。它仍然需要软件。不涉及具有不涉及代码执行的中断或事件驱动情况的应用程序。每个软件执行都需要能量，因为它们会激活主要的硬件模块，例如主存储器、总线系统、内核中的代码执行等。

【图3 | 能源概况；能量模式之间的频繁变化让开关电流成为主要的能量损失（红色区域）。简而言之，它消耗能量而对应用程序没有好处。此外，如果使用软件来切换模式（场景 1c），则会增加能源浪费。］

在现实生活中，用户想要决定他/她的 *** 作模式。硬件提供商定义基本模式，然后用户设计他/她自己的 *** 作模式并使用它们（如何、何时、何地等）。此外，这些 *** 作模式存储在定义的位置，可以编辑或不可编辑，甚至可以添加新的客户定义的 *** 作模式。 *** 作模式可以是专用的、受保护的，并分配给定义的硬件和软件部分。此外，在没有任何软件支持的情况下可以在中断期间使用相同的模式（从而减少能源需求）。

通常，定义的 *** 作模式描述静态、稳定的模式，例如运行、空闲等。这里提出的方法额外管理模式变化的过程，尊重各种动态行为，并包括从源模式到目标模式的安全转换。如果无法执行或仅部分执行此类转换，则安全转换需要包括安全响应（例如，对错误处理程序）——此时安全状态也是必不可少的。

包括电源管理在内的 *** 作模式依赖于数据，而不是固定于仅供应商定义的行为或仅供应商定义的控制数据和位。取决于应用程序的参数可以存储为数据。如果外部条件发生变化，只有数据内容会发生变化，用户代码不会发生变化。

【图4 | 应用受控 *** 作模式策略对能量分布的影响。］

必要的 *** 作模式可以以尽可能低的能量消耗执行，如在睡眠模式中。不同之处在于避免了主要的开关损耗！无需软件参与即可更改模式；例如，将 *** 作模式的频率调整为可用的能源（例如低功耗 LDO）。

结论

*** 作模式可以组织给定系统架构的 *** 作，而不仅仅是功率或能量模式。系统架构控制不同功能块的协作，包括 *** 作模式的动态方面（例如，它们对电源变化、稳定条件等的响应）以及从一种模式到另一种模式的变化。模式之间的转换由参数决定，并且可以在不更改 *** 作模式管理器的情况下安全地适应新要求。

安全 *** 作参数可以是 *** 作模式数据的一部分。分配所有或部分 *** 作模式数据的所有权的参数也是数据的一部分。此外，由于 *** 作模式数据可能位于存储器中，因此可以使用例如众所周知的 MMU 方法来保护它们。一个示例是，属于应用程序或其一部分的此类数据可以与程序代码和数据位于相同的封装内存中。支持运行模式数据集的生成，包括安全运行的验证，可支持高级工具集。

审核编辑：郭婷