Download presentation
Presentation is loading. Please wait.
Published byJoanna Powell Modified over 9 years ago
1
A Low-Power Architecture for Sensor Nodes DEUS EX MACHINA: Octav Chipara Paul Gross Harri Thorvaldsson
2
2 Wireless Sensor Networks Wireless sensor motes sense temperature, humidity etc., transmit and route data Very limited: e.g. 4KB RAM, 64KB Flash, 40-250Kbps radios, 8/16 bit microcontrollers (MCUs) Need to run for long time (month, years!) on batteries, i.e. two AA batteries. Mica2 Telos
3
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
4 Problem: MCU and radio waste power Time Power Activity 1: Non-power aware system
5
5 General solution: powersaving modes Time Power 2: Power-aware: sleep while idling Sleep periods
6
6 Further chipping away at power Time Power 3: Sleep Deeper: gating, voltage scaling …
7
7 Our enhancements, part A Time Power 4: Sleep Longer, exploiting periodicity
8
8 Our enhancements, part B Time Power 5: Work while sleeping, via specilized chip
9
9 Design Approach
10
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
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
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
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
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
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
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
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) 1514 - 1211 - 87 - 54 - 0 1StateDeviceDelay AddDelay Exp 15 - 1413 - 87 - 54 - 0 00Address / 4Delay AddDelay Exp 15 - 141312 - 87 - 54 - 0 01WaitInterrupt IDDelay AddDelay Exp
18
18 Example Waveform Sample Program Switches 3 devices on with delays Jumps Switches 3 devices off with delays Returns, jumps back to beginning
19
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:0.2160.390 Output Loads:0.0490.087 Global Resources:0.0280.050 Zia:0.0110.019 Clocks:00 Inputs:00 Signals:00 Quiescent:0.0270.049 Total at 1.80V:0.3300.595
20
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 1 0 0 1 SWITCH 1 3 0 1 SWITCH 0 0 0 0 SWITCH 0 3 0 0 GOSUB 0 0 2
21
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
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
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
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 4 12 21 3 1 4 5 1PacketMem: RDADD
25
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 4 12 21 3 5 4 5 1PacketMem: RDADD
26
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 4 12 21 3 5 4 5 1PacketMem: RDADD
27
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
28 Experiments
29
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
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
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.