IoT固件压缩-更低的能耗和更快的启动

发布时间：2020-10-10 点击数：

物联网的“ IoT ”一词已经爆炸性地涵盖了各种不同的应用和不同要求的设备。然而大多数观察者会同意低能耗是物联网的关键因素，因为许多此类设备必须依靠电池运行或从环境中获取能量。

看看物联网设备实际上是如何使用能源的，显然大多数为:

1.大部分时间处于闲置状态

2.周期性地唤醒或响应事件，

3.进行一些数据处理，

4.传输结果

5.返回继续休眠。

在第2步中，启动或唤醒可能会消耗大量能量，而在此处节省则可以减少总体能量预算。本文我们就来看看这个问题。

通过数据压缩节省能源

具体来说，在这里我们将展示GZIP数据压缩如何降低使用代码映射（物联网设备中使用的常见技术）的嵌入式系统中的能耗。

基本理念很简单：对先前压缩过的固件进行即时解压，可以减少数据加载，并在引导或唤醒过程中最大程度地减少对长期存储的访问次数，从而降低这一关键操作阶段的能耗（和延迟）。

可能节省的能量和开机时间与数据压缩级别成正比，而压缩级别又取决于压缩算法和代码本身。我们将在此探讨的实际案例表明，使用市售IP核进行硬件Deflate/GUNZIP解压、代码大小（以及因此的功耗和启动时间）可减少多达50%。此外，我们将看到，所节省的成本远远超过了在系统中构建正确的解压内核所使用的额外资源。

代码映射与芯片内执行

低功耗嵌入式系统处于睡眠模式时，通常会将其应用程序代码（在某些情况下还存储应用程序数据）存储在非易失性内存（NVM）设备中，例如Flash，EPROM或OTP。

当此类系统被唤醒执行其任务时，它们通过以下两种方法之一运行应用程序代码：

直接从NVM提取并执行代码，称为芯片内执行XIP （eXecute In Place），或
首先将代码复制到称为映射存储器的片上SRAM单元，然后从那里执行。

哪种方法最好取决于NVM内存的访问速度和访问能耗。通常，NVM存储器要比片上SRAM慢得多，并且从NVM存储器读取数据的能耗成本要比从片上SRAM读取相同的数据高得多（尤其是当数据以随机顺序访问时）。考虑到系统的活动模式，最好使用映射内存，但当我们回想起IoT设备通常在其整个生命周期中都处于睡眠状态时，情况就会发生变化。不幸的是，大型片上SRAM会遭受泄漏电流的影响，因此即使处于睡眠模式也要消耗功率，而大多数NVM则不会。

因此，在映射SRAM可以保持相对较小的情况下，或者严格的实时性要求使得XIP的缓慢访问时间无法接受的情况下，设计者往往选择代码映射。

通过快速数据压缩实现低功耗代码映射

我们可以通过减小存储在NVM中的应用代码的大小来解决这两个问题--并将设计决策引向节能的代码映射方法。

使用GZIP等无损算法压缩代码可以实现这一点，但意味着代码必须在执行前进行解压。图1展示了一个实现这一功能的物联网系统架构示例。在这里，NVM控制器通过解压引擎连接到SoC总线（并从那里连接到片上SRAM），比如CAST提供的GUNZIP IP核。

Figure 1: System architecture for Code Shadowing with Decompression.

存储压缩代码意味着需要能耗更低的NVM访问来唤醒系统，但现在我们增加了解压的额外步骤，有其自身的延迟和能耗。这是否是一个好方案取决于：

我们能把程序代码的大小减少多少，也就是可实现的压缩率是多少
当我们调整压缩算法以达到一个合理的压缩比时，对解压缩硬件的硅面积、功耗和延迟的要求是什么？

接下来让我们通过数字来探究这些因素，看看使用压缩的代码映射是否真的能带来节能。

实例系统:真正节省了多少能耗?

让我们考虑三个相关物联网的系统：

在我们的第一个示例中，R8051XC2 8051 [2]微控制器运行Cygnal FreeRTOS [3]。
在我们的第二个例子中，BA22-DE[4]处理器运行一个由FreeRTOS管理的多线程的传感器控制应用。
在我们的第三个示例中，Cortex-M3处理器[5]正在运行InterNiche Technologies的嵌入式TCP / IP和HTTP堆栈演示[6]。

Figure 2: Hardware lossless data decompression engine; Huffman decoding type and History size are parameterized.

在所有案例中，当从低功耗串行Flash NVM存储器中读取固件时，我们都使用ZipAccel-D GUNZIP IP内核[1]进行解压缩固件。

节能效果取决于压缩水平，而压缩水平又取决于代码本身的可压缩性（指令集架构和应用程序的函数）和所选择的GZIP参数。对压缩影响最大的GZIP参数是Huffman引对于我们的应用程序，未压缩的代码大小在8051系统中为25.5 Kbytes，在BA2系统中为161 Kbytes，在Cortex-M3系统中为985 Kbytes。图3显示了示例二进制文件的压缩率，表1显示了我们的解压核在不同的GZIP参数下的面积和延迟。

Figure 3: Compression Ratio for the image of InterNiche’s demo of embTCP & embHTTP.

Table 1: ZipAccel-D decompression core silicon resources and latency.

为了保持GZIP处理延迟和较低的芯片开销，我们将使用静态Huffman 表和2048 History。这使我们的压缩代码大约是未压缩代码大小的一半，并且同样减少了代码存储的NVM大小以及在启动或唤醒过程中读取代码所需的时间和功耗。表2和表3总结了这些能量节省（假设低功耗串行闪存NVM读取电流为5mA、读取时钟为50MHZ）。