Digital IP Cores
and Subsystems

Our family of microcontroller and microprocessor related cores includes capable and competitive 32-bit BA22s and the best-available set of proven 8051s.

32-bit Processors
BA2x Family Overview

Application Processors
BA25 Adv. App. Processor
BA22 Basic App. Processor

Cache-Enabled Embedded
BA22 Cache-Embedded

Embedded Processors
BA22 Deeply Embedded
BA21 Low Power
BA20 PipelineZero

Processor-Based AMBA® Subsystems
Family Overview
AHB Low-Power
AHB Performance/Low-Power
AXI Custom Performance

AMBA Bus Infrastructure Cores
See Peripherals Cores >

Efficiently compress media or data with these high-performance hardware codecs.
• See the video and image compression Family Page

JPEG Still & Motion
Encoders
Baseline
Extended
Ultra-Fast
Decoders
Baseline
Extended
Ultra-fast

Easily integrate memories, peripherals, and hardware networking stacks into SoCs.

Display Controllers
TFT LCD

Device Controllers
smart card reader

NOR Flash Controllers
Parallel Flash for AHB
SPI Flash
Octal, XIP for AHB
Quad, XIP for AHB
Quad, XIP for AXI

Legacy Peripherals
DMA Controllers
8237, 82380
UARTs
16450S, 16550S, 16750S
Timer/Counter
8254

Quickly complete the standard parts of your SoC with these memory and peripheral controllers, interfaces, and interconnect cores.

Ethernet MAC
• 1G eMAC Controller

Network Stacks
1G/10G UDP/IP stack
• Hardware RTP Stack
  – for H.264
  – for JPEG
• MPEG Transport Stream
  Encapsulator

SPI
Octal SPI
XIP for AHB
Quad SPI
XIP for AHB
XIP for AXI
Master/Slave
Single SPI
Master/Slave
Bridges
SPI to AHB-Lite

Data Link Controllers
• SDLC & HDLC
UARTs
16450S, 16550S, 16750S

PCI Express
Family Overview
x1/x4, x8
application interface

PCI — Target
32-bit, 32-bit multi, 64-bit
PCI — Master
32-bit, 32-bit multi, 64-bit
PCI — Host Bridge
32 bit, 32 bit - AHB
32 bit & device - AHB

These encryption cores make it easy to build security into a variety of systems.

AES
AES, programmable
  CCM, GCM
Key Expander

DES
DES single
DES triple

Hash Functions
SHA-3 (Keccak)
SHA-256
SHA-1
MD5

Other Posts & News

Recent Blog Posts

Recent News

See all the blog posts or news items

by CAST, Inc.

White Paper — Data Compression for Low Energy IoT Connectivity

White Paper

Dr. Nikos Zervas, CAST, Inc. •  November 2015

The trendy phrase “IoT” for Internet of Things has gotten applied to a wide range of different applications and diverse devices, but two characteristics are common: connectivity and low energy requirements.

Regardless of the specific network topology, bit rates, and communication standards, a significant amount of the energy budget of IoT nodes is consumed for communicating data. This is especially true for devices that use wireless communication links. In these,  the radio frequency (RF) subsystem is the dominant energy consumer, and putting this power-hungry communication link to sleep for longer periods is essential for lowering overall power consumption.

The RF subsystem’s active time—and therefore the energy consumed for data exchange—is more or less proportional to the amount of data that must be transmitted or received. So, using compression to reduce the size of that data can be an effective way to reduce the overall energy consumption of wirelessly connected IoT nodes.

Here we will describe an IoT device architecture that exploits lossless data compression, then try to quantify the energy savings this approach makes possible. 

The Architectural Template

Block diagram of system incorporating a GZIP IP coreFigure 1:  IoT architecture with integrated hardware data compression.

Most IoT nodes are controlled by a microcontroller consisting of a typically low-power embedded processor (e.g. 8051, ARM Cortex, or BA2x); peripherals for communicating with some sensor (e.g., for thermal, image, chemical, or mechanical readings or analog-digital conversion) or actuator (e.g., a step motor or electric valve); and possibly some accelerators for the computational intensive tasks (e.g., DSP functions such as filtering, or baseband modulation demodulation).

The typical IoT node stores firmware in an NVM memory, and communicate via an RF subsystem (e.g., an RF transceiver for Zigbee or 802.11ah).

How can introducing a compression accelerator to this generic architecture reduce its energy consumption? 

Here we are considering a hardware accelerator for compression. Compression algorithms are typically computationally complex, so implementing them in software requires a significant amount of code and may actually exhaust the processing bandwidth of a typical low-power IoT embedded processor. Moreover, a hardware compression engine can perform compression faster and at a much lower energy cost.

An example hardware compression engine is the GZIP IP Core for deflate based compression offered by CAST [1].

Analyzing the Potential Energy Savings

Achieving worthwhile levels of compression—and therefore, significant energy savings—depends on the type of data a system must transmit.

IoT devices that exchange large volumes of image, video, or audio data, are poor candidates for further savings since these typically already use compressed data.

This leaves a large group of IoT devices with lower data rates that:

  1. Exchange a set of measurements (e.g. vehicle location coordinates, air pollution or meteoroidal measurements, liquids or chemical levels or level variations in a tank, a building’s alarm system status, or a person’s health monitoring data),
  2. Are able to receive commands (e.g. “turn on heating in apartment number 5 – start in 10 minutes and keep max temperature below 70oF), and
  3. May allow remote access via an HTML page.

From a compression point of view, this type of data resembles the characteristics of the simple text files, spreadsheets, and web files that office workers and engineers compress every day. It is typically highly compressible, with compression ratios in the range of 3:1 from lossless compression algorithms such as GZIP being common (see several examples in [2]).

With less data to transmit after compression, the active time of the RF subsystem in our IoT device will be shorter. How much energy can this save? Consider:

  • Typical low-power RF subsystems consume 10-30mA while active, and a few uA while asleep [3].
  • A typical low-power IoT device microcontroller managing the RF subsystem will consume a few hundreds of uA when active and less than 1 uA while asleep.
  • A GZIP accelerator configured to operate at 1Mbps consumes a few tens of uW while active and practically nothing in sleep mode (assuming the supply voltage is off). 
 

LPRF Examples

MCU Examples

Compressor

TI CC2500
(2.5GHz)

SemTech SX1272
(860MHz-1GHz)

TI MPS430
(MSP430F22374)

ST  STM32L051C6
(@32MHz)

ZipAccel-C
(65nm, 1Mbps)

Voltage (V)

2

2

3

2

1.2

Acrtive Power (mW)

42

32

1.17

8.90

0.18

Active Current (mA)

21

16

0.39

4.45

0.15

Sleep Power (uW)*

1.8

2

0.30

0.54

0.00

Sleep Current (uA)**

0.9

1

0.10

0.27

0.00

* WOR for CC2500, Sleep mode for SX1272
** Assuming Voltage cut-off and 25oC: LMP4 mode at 25oC for MSP430, stanby mode ar 25oC for STM32. 25oC for ZipAccel-C

 

Table 1: Power Consumption of Low Power RF Transceivers (LPRFs), MCUs, and a GZIP Compression Accelerator

We can apply this sample power data to our architectural template to estimate the potential energy savings compression makes possible. For this, we will assume an RF transceiver with 30mW active and 2 mW idle power, an MCU with 2mW active and 0.3uW Idle power, and a GZIP accelerator with the characteristics of Table 1. 

The consumed energy (power over time) will depend on the device duty cycle (i.e., the percentage of time the device is active) and obviously on the compression ratio. Table 2 shows the power usage for our example IoT device with and without compression, under the quite conservative assumption of a 2:1 compression ratio.

 

Example IoT node without compression

Duty Cycle (Active sec per hour)

10

1

0.1

0.01

RF Active (Tx) Energy (mJ/hour)

300.00

30.00

3.00

0.3

RF Idle Energy (mJ/hour)

7.18

7.20

7.20

7.20

MCU Active Energy (mJ/hour)

20.00

2.00

0.20

0.02

MCU Idle Energy (mJ/hour)

1.08

1.08

1.08

1.08

Total Energy (mJ/hour)

328.257

40.278

11.480

8.600

Example IoT node with compression (Compression Ratio: 2:1)

Duty Cycle (sec per hour)

5.000

0.500

0.050

0.005

RF Active (Tx) Energy (mJ/hour)

150.00

15.00

1.50

0.15

RF Idle Energy (mJ/hour)

7.19

7.20

7.20

7.20

MCU Active Energy (mJ/hour)

10.00

1.00

0.10

0.01

MCU Idel Energy

1.08

1.08

1.08

1.08

GZIP Active Energy (mJ/hour)

0.91

0.09

0.01

0.00

GZIP Idle Energy (mJ/hour)

0.00

0.00

0.00

0.00

Total (mJ/hour)

169.175

24.370

9.889

8.441

Net Savings (mJ/hour)

159.082

15.908

1.591

0.159

% Energy Saved

48.5%

39.5%

13.9%

1.8%

Table 2: Energy savings from Compression on a sample IoT node.

 

From this we can see that significant energy savings can be gained by compressing the data to be transmitted even in cases where the IoT device duty cycle is as low as 1 sec/hour (which means the device is active 0.028% of the time). 

Conclusions

In this paper we have considered the case of adding a compression accelerator to the typical IoT node architecture, in order to minimize the energy consumed for data exchange over a wireless network. Compression clearly helps reduce the active time of the RF transceiver, which typically consumes relatively large amounts of energy while active.

The energy savings will depend on the compression levels achieved (which in turn depend on compression algorithm), the exact power consumption characteristics of the device, and its duty cycle.

However, using typical characterization data and rather pessimistic compression levels, we have seen that adding a compression accelerator can result to significant energy savings, even for devices with duty cycles bellow 0.1% (or 1 sec per hour).

 


[1] ZipAccel-C GZIP/ZLIB/Deflate Data Compression Core
http://www.cast-inc.com/ip-cores/data/zipaccel-c/index.html

[2] The Canterbury Corpus Web page (http://corpus.canterbury.ac.nz/)

[3] Designer’s Guide to LPRG, Texas Instruments (http://www.ti.com/lit/sg/slya020a/slya020a.pdf)

 

tw    fbk    li    li    li
Top of Page