A Low-Power Architecture for Sensor Nodes DEUS EX MACHINA: Octav Chipara Paul Gross Harri Thorvaldsson

2 Wireless Sensor Networks  Wireless sensor motes sense temperature, humidity etc., transmit and route data  Very limited: e.g. 4KB RAM, 64KB Flash, Kbps radios, 8/16 bit microcontrollers (MCUs)  Need to run for long time (month, years!) on batteries, i.e. two AA batteries. Mica2 Telos

3 Monitoring application characteristics  Workload = multiple periodic queries running concurrently, e.g.  Data flows from leaves to wired base station at top  Alternating low (waiting) and high- activity (working) periods  Data aggregation and processing can be MCU-intensive SELECT AVG(humidity) AVG(temp) FROM sensors SAMPLE PERIOD 1s

4 Problem: MCU and radio waste power Time Power Activity 1: Non-power aware system

5 General solution: powersaving modes Time Power 2: Power-aware: sleep while idling Sleep periods

6 Further chipping away at power Time Power 3: Sleep Deeper: gating, voltage scaling …

7 Our enhancements, part A Time Power 4: Sleep Longer, exploiting periodicity

8 Our enhancements, part B Time Power 5: Work while sleeping, via specilized chip

9 Design Approach

10 Background: Essence of ESSAT Expected time of first child packet Actual time Send to parent Read sensor Time Delay Time Shift Period n Period n+1

11 Saving power via periodic scheduling  Old: MCU is boss, waits for interrupts, controls the power level of other devices  Interrupt-ready sleeping MCU quite power-hungry (5-600  A)  Assume nothing  devices turned on longer than needed MCU

12 Saving power via periodic, cont.  New: Power Management Unit (PMU) is boss, runs a periodic task schedule  Sets device powerstates, including MCU (to deepest sleep)  Maximizes sleep times and minimizes transition penalties  PMU: extremely small, simple and power-efficient PMU MCU

13 Deployment target: on-board CPLDs!  CPLDs are very energy efficient  CPLDs can be reprogrammed in-circuit  A modular PMU allows per application customization and selection of features, yielding a smaller circuit.  Plug in aggregation functions, filters  Interface with different devices, memories and buses.  Adjust ISA to application needs

14 Software/hardware co-design SELECT AVG(humidity) AVG(temp) FROM sensors SAMPLE PERIOD 1s Hardware: 1.New sensor node architecture With specialized chip for power management, query processing, I/O 2.Uses periodic ESSAT-style scheduling: Sleep long and deep without transition penalties Dynamically adapt to changing workloads 3.Supports energy-hungry MCUs Software: 1.Integration with TinyOS (mote OS kit) 2.Design a library for taking advantage of the new hardware architecture 3.Dynamic PMU code generation from query definition

15 Evaluation Approach: Micro and macro benchmarks Hardware: VHDL / XST Chip-level simulation Show it fits on a CPLD Show it works Estimate power (using XPower) Software: TinyOS / AVRORA Mote system-level simulation Estimate energy savings Investigate trade-offs between different PMU feature sets SELECT AVG(humidity) AVG(temp) FROM sensors SAMPLE PERIOD 1s

16 First design: PMU-1  PMU is simple, potential for energy savings over MCU  Schedule loaded into SRAM by MCU  Tiny programs (e.g. 32 instructions) in SRAM  PC increments through instructions in memory  Instructions turn on/off devices, with delay following  Counter counts down cycles of delay, returns control to PC  Comparator used in waiting for interrupt on return instructions

17 PMU-1 ISA  PMU-1 has three 16-bit instructions (8 bits instruction, 8 bits delay after instruction)  Set device power state (SWITCH)  Jump to instruction (GOSUB)  Return from last jump (RETI)  Delay encoded as 2 exp + add*2 (exp-3) StateDeviceDelay AddDelay Exp Address / 4Delay AddDelay Exp WaitInterrupt IDDelay AddDelay Exp

18 Example Waveform  Sample Program  Switches 3 devices on with delays  Jumps  Switches 3 devices off with delays  Returns, jumps back to beginning

19 PMU Power estimation  Simulate PMU-1 on purely cyclical schedules  Analyze simulation with XPower assuming:  Coolrunner XPLA3 CPLD  Lowest voltage supported I (mA)P (mW) Function Blocks: Output Loads: Global Resources: Zia: Clocks:00 Inputs:00 Signals:00 Quiescent: Total at 1.80V:

20 PMU-1 Implementation  Implemented PMU-1 on Spartan-3 test board  LEDs “represent” devices turning on/off  Special thanks to David Zar Program: SWITCH SWITCH SWITCH SWITCH GOSUB 0 0 2

21 Second design: PMU-2  Assume contemporary and near-future hardware  More autonomous devices (radios, sensors etc.), communicating over common buses (SPI, I2C etc.)  Design goal: handle routine tasks while MCU sleeps.  Runs ESSAT periodic scheduling of communication.  Move data between devices (serve as DMA engine)  Receive and send packets, sense and aggregate data.  Needs to access buses, RAM, acquire packet header and payload data, aggregate, assemble and transmit packet, adjust query scheduling …

22 PMU-2 Design  Task table, co-operative task-switching  Device table: dynamic powerstate conflict resolution  Main ISA instructions:  PEEK / POKE: read / write a byte from / to a bus.  LOAD / STORE: load a variable into the accumulator  ADD / SUB: add or subtract from the accumulator  JMP(C) / GOSUB(C) / RET: (conditionally) jump, jump and store return address and jump to return address  S{L/G}E: compare to accumulator and set condition  WAIT: wait for a timeout or interrupt  “System software” Too Complex

23 PMU-3  New design goal: run a PMU-1 like MCU “precooked” schedule but be able to receive, aggregate and transmit packets by itself (as long as no problems)  Simpler, less general, more focused design  Has PMU-1-like schedule programs (8-bit ISA)  SLEEP, GOSUB, RET : wait, subroutine jumps and returns  WRITE : write immediate to bus, to set powerstate or give command to sensor or radio.  RDADDn : read data value from sensor n via bus  Precooked schedule  no tasks, no need for dynamic powerstate conflict resolution, no tables

24 PMU-3  Has packet handler subroutines, invoked on arrival of a packet  Dispatched on a query ID byte in packet header  Instructions to read bytes from radio and add to aggregate data values in a per-query memory buffer  Buffer has exact same layout as data in packet  RDADD, RDMAX, RDMIN PacketMem: RDADD

25 PMU-3  Has packet handler subroutines, invoked on arrival of a packet  Dispatched on a query ID byte in packet header  Instructions to read bytes from radio and add to aggregate data values in a per-query memory buffer  Buffer has exact same layout as data in packet  RDADD, RDMAX, RDMIN PacketMem: RDADD

26 PMU-3  Has packet handler subroutines, invoked on arrival of a packet  Dispatched on a query ID byte in packet header  Instructions to read bytes from radio and add to aggregate data values in a per-query memory buffer  Buffer has exact same layout as data in packet  RDADD, RDMAX, RDMIN PacketMem: RDADD

27 PMU-3  Dynamic state per query:  Pointer in memory  Number of child packets received  Static state (from program text) per query:  Query ID  Memory buffer address  Packet handler address  Global static state  Mote ID  Number of queries  Number of children  Timeout for waiting for child packets

28 Experiments

29 System Integration Query Definition: SELECT AVG(humidity) AVG(temp) FROM sensors SAMPLE PERIOD 1s PMU Code: … SWITCH HumiditySensor ON GoSub ReadHumiditySenor SWITCH TempSensor ON GoSub ReadTempSenor SWITCH Radio ON GoSub AggregateQ1 SWITCH Radio OFF … PMU MCU CC1000 Spi/PortDSpi/Conf ADC Sensors

30 System Integration (2)  TinyOS:  Implement the PMU code generator in TinyOS  Modify the drivers for the CC1000 radio  Write drivers for reading/writing from PMU  AVRORA:  Hardware platform simulator: Atmel MCU (cycle accurate) SPI buses Analog/Digital converters  AVRORA estimates energy consumption on the platform  Use XPower numbers for power-consumption of PMU

31 System Level Experiments  Goal: Track the improvement in energy savings for different PMU architectures in single and multi-hop environments.  Baseline 1: TinyOS interrupt-driven power management  Baseline 2: Periodic power management  Experiment 1: Periodic power management + PMU1  Experiment 2: Periodic power management + PMU3  Status:  Experiment 1: May be run