Dr. Nikos Zervas, CAST

代表物联网的“IoT”一词已经爆炸式增长，涵盖了范围广泛的不同应用和具有非常不同要求的各种设备。然而，大多数观察者都同意低能耗是物联网的关键要素，因为其中许多设备必须依靠电池运行或从环境中获取能量。

从物联网设备实际使用能源的方式来看，很明显大多数：

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

2.定期唤醒或对某一事件作出反应。

3.执行某种处理。

4.传输结果。 

5.回到睡眠状态。  

第 2 步（启动或唤醒）可能会消耗大量功率，而此处的节省可以降低总体能源预算。在本文中，我们就来探讨这个问题。

具体来说，在这里我们将展示GZIP数据压缩如何帮助降低使用代码阴影的嵌入式系统的能量消耗，这是物联网设备中采用的一种常见技术。

其基本思想很简单：对以前压缩过的固件进行动态解压，可以减少数据负载，并在启动或唤醒期间最大限度地减少对长期存储的访问次数，从而减少这一关键操作阶段的能量（和延迟）。

可能节省的能量和启动时间与数据压缩水平成正比，而这又取决于压缩算法和代码本身。我们将在这里探讨的实例表明，使用用于硬件 Deflate/GUNZIP 解压缩的商用 IP 内核可以将代码大小（因此功耗和启动时间）减少多达 50%。

此外，我们将看到，节省的成本远远超过通过在系统中构建正确的减压核心所使用的额外资源。

当它们处于睡眠模式时，低功耗嵌入式系统通常将其应用程序代码（在某些情况下还包括应用程序数据）存储在闪存、EPROM 或 OTP 等非易失性存储器 (NVM) 设备中。

当此类系统被唤醒执行其任务时，它们通过两种方法中的任何一种运行应用代码：

·它们直接从NVM中获取并执行代码，称为XIP（eXecute In Place），或者

·它们首先将代码复制到一个片上SRAM单元，称为影子存储器，然后从那里执行。

哪种方法最好，取决于NVM存储器的访问速度和访问能量。一般来说，NVM存储器要比片上SRAM慢得多，从NVM存储器中读取数据的能量成本要比从片上SRAM中读取相同的数据高得多（尤其是在以随机顺序访问数据时）。

虽然在考虑系统的活动模式时，使用影子存储器似乎是最好的，但当我们想起物联网设备通常在其大部分寿命中处于休眠状态时，情况就会发生变化。不幸的是，大型片上SRAM会受到泄漏电流的影响，因此即使在睡眠模式下也会消耗功率，而大多数NVM则不会。

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

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

Figure 1:System architecture for Code Shadowing with Decompression

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

存储压缩代码意味着在系统唤醒时所需的耗能 NVM 访问更少，但现在我们增加了额外的解压缩步骤，它有自己的延迟和能耗。这是否是一个整体的好主意取决于：

A.我们能在多大程度上减少应用程序代码的大小，即可以实现的压缩比是多少，以及

B.当我们调整压缩算法设置以达到有价值的压缩比时，解压缩硬件的芯片面积、功率和延迟要求是多少？

接下来，让我们通过计算这些数字来探讨这些因素，看看使用压缩技术的代码阴影是否真的能提供净节能。

让我们考虑三个类似物联网的系统。

·在我们的第一个例子中，R8051XC2 8051微控制器运行Cygnal FreeRTOS端口。

·在我们的第二个例子中，BA22-DE 处理器运行一个传感器控制应用程序，该应用程序具有由 FreeRTOS 端口管理的多个线程。

·在我们的第三个例子中，Cortex-M3处理器正在运行I InterNiche Technologies 的嵌入式 TCP/IP 和 HTTP 堆栈演示。

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

在所有情况下，我们使用ZipAccel-D GUNZIP IP核来解压固件，因为它是从低功耗串行闪存 NVM 存储器中读取的。

节能取决于压缩级别，而压缩级别又取决于代码本身的可压缩性（ISA和应用程序的函数）和所选择的GZIP参数。对压缩影响最大的GZIP参数是Huffman引擎的类型和History的大小。这些参数也影响到我们的GZIP引擎的芯片要求和延迟。

我们的应用程序的未压缩代码大小为：8051系统为25.5KB，BA2系统为161KB，Cortex-M3系统为985 KB。图3显示了我们每个实例二进制文件的压缩比，表1显示了我们的解压核心在不同的GZIP参数集下的面积和延迟。

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

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

为了保持GZIP处理延迟和硅开销的低水平，我们将使用静态Huffman表和 2048 History。这使得我们的压缩代码约为未压缩代码的一半，同样也减少了用于代码存储的NVM大小，以及在启动或唤醒期间读出代码所需的时间和能量。表2和表3总结了这些节省，假设现代低功耗串行闪存NVM具有5mA的读取电流和50MHZ的读取时钟。

Table 2:NVM Size Savings achieved using Code Compression.

Table 3:Boot Time and Energy Savings achieved using Code Compression.