Mode Selection andMode Dependency Modeling for

Power-Aware Embedded Systems

Mode Selection andMode Dependency Modeling for

Power-Aware Embedded Systems

Dexin Li, Pai H. Chou, Nader Bagherzadeh

University of California, Irvine5th International Conference on VLSI Design and

7th Asia and South Pacific Design Automation Conference

Bangalore, India, January 11, 2002

2

OutlineOutline

Introduction

Related work

Mode dependency modeling

Mode selection

Experimental results

Conclusions

3

IntroductionIntroduction

Power-aware systems Low power High performance as required

Use components with multiple power modes Power modes: full-on, doze, nap, sleep, deep sleep,

shutdown, … voltage and frequency settings Peripheral devices with diff. bus transfer rate, encodings

Mode selection Choose combinations of power modes over time Satisfy power performance constraints

4

Mode SelectionMode Selection

Choosing mode combinations Many power modes are available Few modes are considered

Current limitations OS/API limitations Difficult to track the details

Select modes in isolation e.g., processor only Lack of system-level view

Satisfying constraints Power Timing

5

Related WorkRelated Work

Dynamic Power Management (DPM) Low power, low-latency as a design goal

(rather than a constraint) [Benini99], [Hwang97], [Qiu00], … Lack of real time guarantees Not considering inter-component dependency

Dynamic voltage scaling (DVS) Slow down processor greedily [Yao95], [Hong98], [Shin99], [Quan01] Limited to single processor Can have counter-intuitive effects at system-level

6

Example: tasks on multiple componentsExample: tasks on

multiple components Component R1 is voltage scalable

R2, R3 are NOT voltage scalable

R3 co-active with R1 (R1 on => R3 on)

original schedule

original power profile

R1

R2R3

Pmax

AB

C

C

A B

Tim

e vi

ewP

ower

vie

w

deadline

7

Example -- applying DVSExample -- applying DVS

Greedily slow down R1, stretch A all the way to deadline

Co-activation => stretch C by same amount as A

Problems: Max violation (overlap B), plus higher energy!

DVSschedule

DVSpower profile

R1

R2R3

Pmax

C'

A'

B

B

Tim

e vi

ewP

ower

vie

w

deadline

C'A'

8

Example: optimal solutionExample: optimal solution

Slow down R1 partially to eliminate power spike

Reduces co-active energy due to task C

No overlap with B => eliminates max power violation

Feasibletime schedule

Optimalpower profile

R1

R2R3

Pmax

A''

A''

B

B

C''

C''

Tim

e vi

ewP

ower

vie

w

deadline

9

Our approachOur approach

Constraint-driven Power, performance as hard constraints

Mode change overhead Timing, power Will not change mode if overhead cannot be amortized

System-level modeling Co-activation Selection dependency across components

Exponential search space Pruning required

10

OutlineOutline

Introduction

Related work

Mode dependency modeling Mode dependency graph (MDG) Legal configurations

Mode selection

Experimental results

Conclusions

11

System modelingSystem modeling

Resource R M = {m1, m2, … } mutually exclusive modes

notation: R.m1, R.m2, … H = subset of M x M set of overhead functions

(power, time) on changing mode

Component = container of one or more resources

System Set of resources { R1, R2, R3, …} Set of dependencies between modes Configuration = member of MR1 x MR2 x MR3 x … Workload Constraints

12

Mode dependency across resourcesMode dependency across resources

Necessary condition: m1 is necessary for m2 !m2 is sufficient for !m1

Operators AND, OR, XOR

Mode dependency graph Vertices: set of modes

set of operators Edges: direction of dependency

Purpose: generate set of “legal” configurations Assignments that satisfy all mode dependencies Independent of workload and timing/power constraints

m1 m2

m1

AND OR

m2

R1 R2

13

Example: Sensor Node (MIT)Example: Sensor Node (MIT)

Components:Modes processor A active, idle, sleep memory M on, off radio R rx_tx, rx, tx, off sensor S on, off

# of possible configurations 3 x 2 x 4 x 2 = 48

(grows multiplicatively)

# of legal configurations 5 as given by MIT group

(closer to linearly) Manually generated Want to automate this

14

Mode dependencies in sensor nodeMode dependencies in sensor node

Betw. CPU and {sensor, radio} CPU may sleep if

both radio and sensor are off

CPU may sleep or idle if either sensor or radio is “working”

Betw. Memory and CPU CPU co-activation with memory

(asymmetric)

Betw. sensor and radio Radio ON only if sensor ON

S.off

R.offAND A.sleep

S.on

R.rx_txR.rx

XORA.sleepA.idle

A.active M.on

A.idleA.sleep

M.off

R.on S.on

15

Generating legal configurationsGenerating legal configurations

Idea: one “counter” per resource Binary encoding for modes in a resource

Interresource dependency graph Dependency between counters An edge (R1.m1, R2.m2) in MDG

=> add edge (R1, R2)

Linearize the counters Topological sort break cycle if necessary

Run the counters Count next digit only if there

is an edge in original MDG

radiosensor CPU mem

memCPUradio

sensor

off off sleep off

on off sleep off

idle off

on idle off

active on

16

OutlineOutline

Introduction

Related work

Mode dependency modeling

Mode selection Legal vs. feasible configurations Mode schedule

Experimental results

Conclusions

17

Mode Selection: inputMode Selection: input

Mode dependency graph

A schedule of workload Independent of power/energy, timing

Component library Maps workload into power, timing Maps mode change into power/timing overhead

Constraints Timing: min/max separation Power: min/max power levels

18

Output: feasible mode scheduleOutput: feasible mode schedule

Feasibility All configurations are “legal” (satisfy MDG) All timing & power constraints are satisfied

Mode schedule Original workload mapped to configuration

(selected modes) over time Overhead tasks inserted between changed modes Idle power also considered

Solutions Dynamic programming Backtracking

19

Example – Mars Pathfinder RoverExample – Mars Pathfinder Rover

Component-based system Power sources: solar panel, non-rechargeable batteries Power consumers

Digital: computer, wireless, camera, hazard detector Mechanical: driving motors, steering motors Thermal: heaters

Design constraints: Power consumption

Max/min power constraints Timing

Hard real-time Pair-wise precedence

Mode dependency Co-activation Enabling/disabling

20

Application Example: Mars RoverApplication Example: Mars Rover

Behaviors and tasks Moving around on Mars surface Communicating with the Lander Taking pictures (IMP) Performing scientific experiments (APXS, ASI/MET)

Components in the entire system Hazard detector (HAZ), Driving motor (DRV) Steer motor (STR) Radio frequency modem (RF) Camera (CAM) Microprocessor (PPC), Micro-controller (MC)

21

Example: Mars RoverExample: Mars Rover

Components: hazard detector, driving

motor, steering motor

Constraints: hazard detector and

motors should not be working at the same time

Legal configurations

str.on

drv.on

OR str.off

str: steering motor

drv: driving motor

haz: hazard detector

hazard detector driving motor steering motoroff off offoff on offoff off onoff on onon off off

m0m1m2m3m4

22

ResultsResults

Base line Only: on/off modes Relaxed constraints Mode change overhead No max power constraint

Mode selection Energy saving:

3.7% to 11.9%8.7% average

Meets max power More general timing 1300

1350

1400

1450

1500

1550

1600

1650

1700

1750

5 6 7 8 9 10

Mode SelectionOn&Off

Pmin(W)

Energy(J)

23

Results: Min powerResults: Min power

Free energy source e.g., solar panel Thermal battery

Cost: above min power

Saving: From 6.9% to 49.3% average 26.5%

0

100

200

300

400

500

600

700

800

900

1000

5 6 7 8 9 10

Mode Selection

On&Off

Pmin (W)

Energy (J)

24

Exploring Different Working ScenariosExploring Different Working Scenarios

Explore different working scenarios and compare results Three mission tasks

Moving around (MOV) Taking picture (CAM) Scientific experiment

(SCI) Three scenarios

A: MOV, CAM, SCI B: CAM, MOV, SCI C: CAM, SCI, MOV

25

Result IIIResult III

Different working scenarios have different energy consumption Scenario C consumes

12% more energy than scenario A (by mode selection)

Mode selection always does better than simply on/off modes

0

5000

10000

15000

20000

25000

A B C

Mode SelectionOn&off

26

ConclusionsConclusions

Mode selection problem Choosing modes of component Minimize energy at system level, satisfy timing constraints Handles mode-change overhead

Mode dependency modeling Enabling relationship between modes of diff resources Helps prune out illegal configurations

Mode selection algorithm Iterate over legal config’s to find feasible mode schedule Satisfies power & timing constraints Improve existing solution by 8-25% in energy cost Give designers confidence in power-aware systems

Tool available from http://www.ece.uci.edu/~impacct/

27

Mode Selection Algorithm (sketch)Mode Selection Algorithm (sketch)

Exploration techniques Backtracking Cutting exploration space with multi-dimensional

constraints

Two steps in design exploration: Find feasible mode selection for operating tasks

Timing constraints Dependency between tasks

Find feasible mode selections for idle intervals System power/energy constraints: min, max, or power profile Mode change overhead, both time and power overheads

Speedup techniques Sorting component modes with power numbers

28

Legal configurationsLegal configurations

Sensor Node example Mode combinations given

by MIT group: 5 combinations

Mode combination generated from dependency graph

Add constraint When sensor is off, all

other component should be off (proactive)

Automatically obtain same results as MIT group

conf S R A Ms0 on tx_rx on ons1 on rx idle offs2 on rx sleep offs3 on off sleep offs4 off tx_rx on ons5 off rx idle offs6 off rx sleep offs7 off off sleep off

Not given by MIT group

29

BibliographyBibliography [Benini99] L. Benini, G. Paleologo, A. Bogliolo, and G. De Micheli. Policy

optimization for dynamic power management. IEEE Trans. Computer-Aided Design, 18:813–833, June 1999.

[Hwang97] C.-H. Hwang and A. Wu. A predictive system shutdown method for energy saving of event-driven computation. In Proc. of DAC, November 1997.

[Qiu00] Q. Qiu, Q.Wu, and M. Pedram. Dynamic power management of complex systems using Generalized Stochastic Petri Nets. In Proc. of DAC, pages 352–356, 2000.

[Hong98] I. Hong, D. Kirovski, G. Qi, M. Potkonjak, and M. B. Srivastava. Power optimization of variable voltage core-based systems. In Proc. of DAC, pages 176–181, 1998.

[Quan01] G. Quan and X. S. Hu. Energy efficient fixed-priority scheduling for real-time systems on variable voltage processors. In Proc. of DAC, pages 828–833, 2001.

[Shin99], Y. Shin and K. Choi. Power conscious fixed priority scheduling for hard real-time systems. In Proc. of DAC, pages 134–139, 1999.

[Yao95] F. Yao, A. Demers, and S. Shenker. A scheduling model for reduced CPU energy. IEEE Annual Foundation of Computer Science, pages 374–382, 1995.

30

AcknowledgementsAcknowledgements

DARPA PACC F33615-00-1-1719

NASA/Cal-Tech/JPL: N. Aranki M. Mojarradi J. U. Patel N. Toomarian

31

Tool PrototypeTool Prototype

Language Python, Tkinter

Graphical User Interface Time window and power window View tasks, overheads, power profile Interactive command line Incorporate with the scheduler (to be completed) On-line help (to be completed)

32

Scenario AScenario A

33

Scenario BScenario B

34

Scenario CScenario C

35

System Power RepresentationSystem Power Representation

Schedule Gantt Chart

Time view Power view

Mode selection Gantt chart

Tasks marked with mode settings

Added non-operating tasks

Idle intervals mode change

overheads Power profile view

36

Mode Selection: Problem StatementMode Selection: Problem Statement

Input A schedule MDG Constraints (power, timing)

Output a mode schedule

Problem statement Find feasible mode selection

for the tasks/idle intervals for the components that meets system power and timing constraints

Mode selector

scheduleComponent library

System constraints

Mode selections

37

Comparison of three scenariosComparison of three scenarios

Original DVS Optimal

No No NoTiming Violations

No Yes NoPower Violations

300 320 288Energy Cost

Original Does not apply dynamic voltage scaling technique

DVS Ignores mode dependency between R1 and R3

Optimal solution Must consider mode dependency Energy saving due to dynamic voltage scaling