IOs interface memory secutity

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访问来唤醒系统,但现在我们增加了解压的额外步骤,有其自身的延迟和能耗。这是否是一个好方案取决于:

  1. 我们能把程序代码的大小减少多少,也就是可实现的压缩率是多少

  2. 当我们调整压缩算法以达到一个合理的压缩比时,对解压缩硬件的硅面积、功耗和延迟的要求是什么?

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

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

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

  • 在我们的第一个示例中,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.


1602307910127801.png

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

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

1602308130808555.png

Table 2:  NVM Size Savings achieved using Code Compression.


1602308218360327.png

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

资源节省平均约为50%,而且显然是可观的,但是代价是什么呢?

分析压缩开销

以所述方式使用压缩会在两个方面引入开销:时间和能源。

我们在示例系统[1]中使用的ZipAccel-D解压核引入了25到2000个时钟周期的延迟(具体取决于静态还是动态Huffman表用进行压缩)。

即使在2000个周期的延迟下,并且假设解压缩内核将以NVM的50MHz时钟运行,解压缩内核所增加的额外延迟仅为0.04msec。因此,由于压缩而导致的额外延迟实际上可以忽略不计,因为从NVM读取代码的时间要高两个数量级。

在功耗方面,当系统处于活动状态时,解压内核的功耗可以忽略不计,但当系统处于空闲状态时,它也会消耗能源。这种空闲状态下功率消耗的意义取决于系统的占空比。

在我们的示例系统中,解压内核的空闲功耗相比系统所能节省的功耗低3到6个数量级。然而,由于能量是随时间变化的功率,较长的系统睡眠时间使得这种额外的功率消耗更为重要。 

由于我们实现了巨大的功率节省,很明显,存储压缩代码并在需要的时候解压,对于大多数物联网系统来说,即使是那些占空比低至每天几毫秒的系统,也能产生净系统能量节省。

结论

高效的硬件解压缩引擎(例如可从CAST获得的IP核)可以对代码进行行内解压缩(因为从NVM中读取了代码),而代价是几乎可以忽略不计的额外延迟或能耗。

采用代码映射的IoT设备可以通过使用代码压缩获得到显著的能耗节约。

压缩后的应用代码需要一个较小的NVM设备进行长期存储,系统将压缩后的代码从NVM读入片上SRAM所消耗的时间和能量也大大减少。

一个高效的硬件解压引擎,如CAST提供的IP核,可以在线解压代码(当代码从NVM中读出时),其代价是几乎可以忽略不计的额外延迟或能耗。



ZipAccel-D GUNZIP/ZLIB/Inflate Data Decompression Core: 

https://cast-inc.com/compression/gzip-lossless-data-compression/zipaccel-d/

R8051XC2 High-Performance, Configurable, 8051-Compatible, 8-bit Microcontroller: 

https://cast-inc.com/processors/8051s/r8051xc2/

FreeRTOS Cygnal (Silicon Labs) 8051 Port: 

http://www.freertos.org/portcygn.html

BA22-DE 32-bit Deeply Embedded Processor: 

https://cast-inc.com/processors/32-bit/ba22-de/

ARM® Cortex ®-M3 Processor:  http://www.arm.com/products/processors/cortex-m/cortex-m3.php

InterNiche Technologies embedded TCP/IP stacks demo: http://www.iniche.com/source-code/networking-stack/nichestack.php


赞助企业