Power Manager Chenyang Lu CSE 467S 1 HW vs. SW? Software - - PDF document

▶
power manager
SMART_READER_LITE
LIVE PREVIEW

Power Manager Chenyang Lu CSE 467S 1 HW vs. SW? Software - - PDF document

Sep 29, 2022 293 likes •525 views

Power Manager Chenyang Lu CSE 467S 1 HW vs. SW? Software (OS-based) power manager dominates due to flexibility Hardware and software co-design Software implements policy Hardware implements power change mechanisms Need

slide-1
SLIDE 1

Chenyang Lu CSE 467S 1

Power Manager

Chenyang Lu CSE 467S 2

HW vs. SW?

  • Software (OS-based) power manager

dominates due to flexibility

  • Hardware and software co-design
  • Software implements policy
  • Hardware implements power change mechanisms
  • Need standard interfaces to deal with

hardware diversity

  • Different vendors
  • Different devices: processor, sensor, controller …
slide-2
SLIDE 2

Chenyang Lu CSE 467S 3

Advanced Configuration and Power Interface (ACPI)

Open standard for power management services.

Hardware platform

devices, processor, chipset

device drivers ACPI BIOS OS kernel applications power management

Chenyang Lu CSE 467S 4

System States

slide-3
SLIDE 3

Chenyang Lu CSE 467S 5

ACPI Global Power States

  • Used as contracts between hw and OS vendors
  • G3: mechanical off – no power consumption
  • G2: soft off – restore requires full OS reboot
  • G1: sleeping state
  • S1: low wake-up latency with no loss of context
  • S2: low latency with loss of CPU/cache state
  • S3: low latency with loss of all state except memory
  • S4: lowest-power state with all devices off
  • G0: working state

Chenyang Lu CSE 467S 6

Device Power States

  • Device power state is invisible to the

user

  • Some device may be inactive when the

system is in working state

  • Each device may be controlled by a

separate PM policy

slide-4
SLIDE 4

Chenyang Lu CSE 467S 7

Reduce power in working state

Chenyang Lu CSE 467S 8

Holistic View of Power Consumption

  • Instruction execution (CPU)
  • Cache (instruction, data)
  • Main memory
  • Other: non-volatile memory, display,

network interface, I/O devices

slide-5
SLIDE 5

Chenyang Lu CSE 467S 9

Sources of energy consumption

  • Relative energy per operation (Catthoor

et al):

  • memory transfer: 33
  • external I/O: 10
  • SRAM write: 9
  • SRAM read: 4.4
  • multiply: 3.6
  • add: 1

Chenyang Lu CSE 467S 10

Optimize Memory System

  • Different instructions Different energy

consumption

  • Energy drain: register << cache (SRAM) <<

memory (DRAM) →Most energy reduction comes from

  • ptimizing memory system
slide-6
SLIDE 6

Chenyang Lu CSE 467S 11

Cache behavior is important

  • Energy consumption has a sweet spot as

cache size changes:

  • cache too small: burning energy on external

memory accesses;

  • cache too large: cache itself burns too much

power.

Chenyang Lu CSE 467S 12

Impacts of Cache Size

slide-7
SLIDE 7

Chenyang Lu CSE 467S 13

Optimizations

  • Reduce memory footprint
  • Reduce code size
  • Analyze footprint to find right size
  • Stack, heap…
  • Find correct cache size
  • Analyze cache behavior (size of working set)
  • Minimize memory and cache access
  • Use registers efficiently less cache access
  • Identify and eliminate cache conflicts less

memory access

  • Better performance More idle time!

Chenyang Lu CSE 467S 14

Wireless Sensor Networks

A Quick Overview

  • sensors + microprocessor + wireless

Berkeley Smart Dust

slide-8
SLIDE 8

Chenyang Lu CSE 467S 15

Hardware Technology

Chenyang Lu CSE 467S 16

The Hardware Challenge

  • Miniature hardware devices must be

manufactured economically in large numbers

  • Microprocessors
  • MEMS sensors/actuators
  • Wireless communication

5’’X3’’ 1’’X1’’ 1 mm2 1 nm2

slide-9
SLIDE 9

Chenyang Lu CSE 467S 17

MICA Motes

  • Radio Communication: 40 Kbps max
  • Commercial-off-the-shelf components

1’’X1’’

Chenyang Lu CSE 467S 18

Smart Dust

  • Current: 5 mm; in ten years: 1 mm float in

the air!

  • Radio?
  • Nowhere to put antenna!
  • Require complex circuits energy-inefficient
slide-10
SLIDE 10

Chenyang Lu CSE 467S 19

Passive Optical Communication

Top View of the Interrogator CCD Camera Lens Frequency-Doubled Beam 45o mirror Polarizing Beamsplitter Quarter-wave Plate Filter 0.25% reflectance

  • n each surface

YAG Green Laser Expander

  • K. Pister et. al., http://robotics.eecs.berkeley.edu/~pister/SmartDust/presentations/MEMSPIJan00.ppt

Chenyang Lu CSE 467S 20

Optical Communication

  • Pros
  • Space multiplexing
  • Passive optical communication: energy-free
  • n dusts!
  • Cons
  • Require line of sight
  • Much more challenging for active multi-hop

communication

  • aiming control
slide-11
SLIDE 11

Chenyang Lu CSE 467S 21

Amorphous Computing

  • Computers produced by bio engineering
  • Cells as logic gates
  • Basic inverter: Concentration of protein Z

is inversely proportional to concentration

  • f protein A.
  • NAND gate: Production of protein Z is

inhibited by presence of proteins A and B.

Chenyang Lu CSE 467S 22

Nano-scale Computing

  • DNA manipulation can organize cells into

engineered patterns

  • The foundation for construction of

complex sub-nano-scale extra-cellular circuits:

  • Biological system – machine shop
  • Proteins – machine tools
  • DNA – control tapes
  • Circuits are fabricated in large numbers by

cheap biological processes

  • Truly ubiquitous! Smart paint, fabric …
slide-12
SLIDE 12

Chenyang Lu CSE 467S 23

Great Duck Island

Habitat Monitoring

  • Usage patterns of burrows
  • Burrow and environmental

changes

  • Differences between

nesting areas and others

Chenyang Lu CSE 467S 24

slide-13
SLIDE 13

Chenyang Lu CSE 467S 25

Great Duck Island

Requirements

  • Longevity: 9-month season
  • Super-low Power budget
  • Need extreme power management!
  • Non-intrusive
  • Management from remote
  • System health monitoring
  • Retasking/reconfiguration through wireless
  • Maté, Agilla (from MobiLab)
  • Timing requirements (non-real-time)
  • 5-10 min: entry/leave
  • 2-4 hr: environmental differential

Chenyang Lu CSE 467S 26

Great Duck Island

Tiered Architecture

http://www.greatduckisland.net

slide-14
SLIDE 14

Chenyang Lu CSE 467S 27

Mote and TinyOS

Chenyang Lu CSE 467S 28

Hardware Constraints

  • Severe constraints in power, size, and cost

translated to:

  • Slow CPU
  • Short-distance, low-bandwidth radio
  • Small memory
  • Limited hardware parallelisms
  • CPU hit by many interrupts!
  • Support sleep mode in hw components
slide-15
SLIDE 15

Chenyang Lu CSE 467S 29

Mote

  • CPU: 4 MHz, 8 bit, ATMEL
  • NO kernel/user protection
  • Raw peripherals a lot work for CPU:
  • Collect data from sensors
  • Process every bit to/from radio
  • Arbitrate bus
  • Radio: 900 Hz
  • Rene: 19.2 kbps
  • Mica: 40 kbps (max), up to 1,000 feet (power adjustable)
  • No byte level processing
  • Memory: Harvard Architecture
  • Rene: 512 B data; 8K code
  • Mica: 4 KB data; 128 KB code
  • Two AA battery
  • 3 days of continuous active operation
  • Sleep modes: idle/power-down/power-save

Chenyang Lu CSE 467S 30

Software Challenges

  • Small memory footprint
  • Efficient in power and computation
  • Lack hardware parallelism OS provides

concurrency-intensive operation

  • Real-time
  • Diversity in applications and design
  • Efficient modularity
  • Reconfigurable hardware
  • Software & hardware codesign
slide-16
SLIDE 16

Chenyang Lu CSE 467S 31

How about a traditional embedded OS?

  • Big!
  • Multi-threaded architecture
  • Large number of threads large memory
  • Context switch overhead
  • I/O model
  • Blocking I/O (stop and go): waste memory on blocked threads
  • Polling (busy-wait): waste CPU cycles and power
  • Protection between applications and kernel
  • Overhead for crossing kernel/user boundary & interrupt

handling

  • Pros
  • Clean & simple programming model
  • Priority-based scheduling support
  • Robust (protect kernel)

Chenyang Lu CSE 467S 32

Real time operating systems

  • QNX context switch = 2400 cycles on x86
  • pOSEK context switch > 40 µs
  • Creem -> no preemption

Name Code Size Target CPU pOSEK 2K Microcontrollers pSOSystem PII->ARM Thumb VxWorks 286K Pentium -> Strong ARM QNX Nutrino >100K Pentium II -> NEC QNX RealTime 100K Pentium II -> SH4 OS-9 Pentium -> SH4 Chorus OS 10K Pentium -> Strong ARM ARIEL 19K SH2, ARM Thumb Creem 560 bytes ATMEL 8051

slide-17
SLIDE 17

Chenyang Lu CSE 467S 33

TinyOS Solutions

  • Support concurrency: event-driven architecture
  • Modularity: application = scheduler + graph of components
  • Compiled into one executable
  • Efficiency: Get done quickly and sleep
  • Event = function calls
  • Less context switch: FIFO/non-preemptable scheduling
  • No kernel/application boundary

Communication Actuating Sensing Communication Application (User Components) Main (includes Scheduler) Hardware Abstractions

Modified from D. Culler et. Al., TinyOS boot camp presentation, Feb 2001

Chenyang Lu CSE 467S 34

TinyOS component model

  • Component has:
  • Frame (memory)
  • Tasks: thread (computation)
  • Interface:
  • Command
  • Event
  • Frame: static storage model – compile-time

allocation

  • Command and events = function calls
  • Clean (hw-like) interface
  • No shared memory or global variables
  • Replace hw with sw and vice versa

Messaging Component

Internal State Internal Tasks

Commands Events

slide-18
SLIDE 18

Chenyang Lu CSE 467S 35

A Complete Application

RFM Radio byte (MAC) Radio Packet i2c Temp photo Messaging Layer clocks bit byte packet Routing Layer sensing application application

HW SW

ADC messaging routing

  • D. Culler et. Al., TinyOS boot camp presentation, Feb 2001

Chenyang Lu CSE 467S 36

TOS Component

//AM.comp// TOS_MODULE AM; ACCEPTS{ char AM_SEND_MSG(char addr, char type, char* data); void AM_POWER(char mode); char AM_INIT(); }; SIGNALS{ char AM_MSG_REC(char type, char* data); char AM_MSG_SEND_DONE(char success); }; HANDLES{ char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet); }; USES{ char AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT(); };

Messaging Component AM_SUB_INIT AM_SUB_POWER AM_SUB_TX_PACKET AM_TX_PACKET _DONE AM_RX_PACKET _DONE

Internal State

AM_INIT AM_POWER AM_SEND_MSG AM_MSG_REC AM_MSG_SEND_DONE

Internal Tasks

Commands Events

slide-19
SLIDE 19

Chenyang Lu CSE 467S 37

TinyOS Two-level Scheduling

  • Tasks do intensive computations
  • Unpreemptable FIFO scheduling
  • Bounded number of pending tasks
  • Events handle interrupts
  • Interrupts trigger lowest level events
  • Events can signal events, call commands, or post tasks
  • Two priorities
  • Event/command
  • Tasks

Hardware Interrupts events commands FIFO Tasks POST Preempt Time commands Chenyang Lu CSE 467S 38

How to handle multiple data flows?

  • Data/interrupt are handled by

interrupt/event

  • Respond to it quickly: A sequence of non-blocking

event/command (function calls) through the component graph

  • e.g., get bit out of radio hw before it gets lost
  • Post tasks for long computations
  • e.g., encoding
  • Assumption: long computation are not emergent
  • Preempting tasks to handle new data
slide-20
SLIDE 20

Chenyang Lu CSE 467S 39

Receiving a message

Timing diagram of event propagation

Chenyang Lu CSE 467S 40

How should network msg be handled?

  • Socket/TCP/IP?
  • Too much memory for buffering and threads
  • Data are buffered in network stack until application threads read it
  • Application threads blocked until data is available
  • Transmit too many bits (sequence #, ack, re-transmission)
  • Tied with multi-threaded architecture
  • TinyOS solution: active messages
slide-21
SLIDE 21

Chenyang Lu CSE 467S 41

Active Message

  • Every message contains the name of an event handler
  • Sender
  • Declaring buffer storage in a frame
  • Naming a handler
  • Requesting Transmission; exit
  • Done completion signal
  • Receiver
  • The event handler is fired automatically in a target node

No blocked or waiting threads on sender or receiver Behaves like any other events Single buffering

Chenyang Lu CSE 467S 42

Send Message

char TOS_COMMAND(INT_TO_RFM_OUTPUT)(int val){ int_to_led_msg* message = (int_to_led_msg*)VAR(msg).data; if (!VAR(pending)) { message->val = val; if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAST, AM_MSG(INT_READING), &VAR(msg))) { VAR(pending) = 1; return 1; } } return 0; } msg buffer access appln msg buffer cast to defined format mark busy application specific ready check build msg request transmission destination identifier get handler identifier