power,’heat&’energy’in’ electronic’systems’ · 2019. 3. 5. ·...

Power, Heat & Energy in Electronic Systems

Bharadwaj Amrutur ECE Department

A Typical Electronic System

Compu@ng Storage Physical Interfaces Communica@on

+

V

I IP IS IU IX

The currents are a func@on of @me. The voltage is supposed to be independent of @me.

Defini@on: Instantaneous power


+

V

I IP IS IU IX

P(t) =V *I(t)

P =1/T* P(t)dt0

T

∫

E = P(t)dt0

T

∫

(WaNs)

(WaNs)

(Joules)

Typical (Power) Numbers Item Power(W)

LED Light Bulb 10

Desktop Computer 50

Laptop 20

Mobile Phone (Suspend/Idle/Talk)

0.07/0.27/1

Smart Watch (Pebble) 0.003

Human Brain 20

Human 100

Average vs. Instantaneous Power

Item Power (mW)

Smart Watch(Avg) 3

Smart Watch with BLE Radio on 60

Power supply should be designed to supply burst power requirements Average power is reduced via duty-‐cycling (keeping high powered components off Most of the @me).

Where does power go?


+

V

I IP IS IU IX

Heat, Light, Sound Radia@on

Hea@ng and temperature

V * I

+

-‐

I

V

q: Power loss due to radia@on, convec@on, conduc@on

dTdt

=1/CH *(V * I − q)T: Temperature t: @me CH: Heat Capacity

Energy Item Energy (J)

Lithium Polymer for Smart Watch (3.7V, 130mAH) 1732

BuNon cell CR2032 (3.0V, 225mAH) 2430

AA NiMH Camera BaNery (1.2V, 2850mAH) 12312

Smart Phone baNery (Li, 3.7V, 1500mAH) 20000

A Smart Phone power break down 2 Methodology

Our approach to profiling energy consumption is to takephysical power measurements at the component level ona piece of real hardware. In this section, we describethe hardware and software used in the experiments, andexplain our benchmarking methodology.

There are three elements to the experimental setup:the device-under-test (DuT), a hardware data acquisition(DAQ) system, and a host computer.

2.1 Device under testThe DuT was the Openmoko Neo Freerunner (revisionA6) mobile phone. It is a 2.5G smartphone featuring alarge, high-resolution touchscreen display, and many ofthe peripherals typical of modern devices. Table 1 listsits key components. The notable differences between ourdevice and a modern smartphone are the lack of a cameraand 3G modem.

Component SpecificationSoC Samsung S3C2442CPU ARM 920T @ 400 MHzRAM 128 MiB SDRAMFlash 256 MiB NANDCellular radio TI Calypso GSM+GPRSGPS u-blox ANTARIS 4Graphics Smedia Glamo 3362LCD Topploy 480⇥ 640SD Card SanDisk 2 GBBluetooth Delta DFBM-CS320WiFi Accton 3236AQAudio codec Wolfson WM8753Audio amplifier National Semiconductor LM4853Power controller NXP PCF50633Battery 1200 mAh, 3.7 V Li-Ion

Table 1: Freerunner hardware specifications.

This device was selected because the design files, par-ticularly the circuit schematics [7], are freely available.This is critical for our approach to power measurement,which relies on understanding the power distribution net-work at the circuit level. For this reason, few other de-vices would be suitable.

The high-level architecture of the Freerunner is shownin Figure 1. The total system memory is split equally be-tween two banks, one external RAM package, and oneon-chip. All peripherals except the graphics chip com-municate with the application processor (CPU) by pro-grammed I/O over various serial buses.

The other devices studied, the HTC Dream (G1) andGoogle Nexus One (N1), are described in Section 4.

ApplicationsProcessor

NAND

SDRAM

GSM

GPS

Codec

Amp

WiFi

Bluetooth

Graphics SDRAMLCD

SD Card

Host bus

I2C

SDIO

USB

serial

serial

Figure 1: Architecture of the Freerunner device, showingthe important components and their interconnects.

2.2 Experimental setup

To calculate the power consumed by any component,both the supply voltage and current must be determined.

To measure current, we inserted sense resistors on thepower supply rails of the relevant components—this isrelatively simple on the DuT selected, since most of themhave been designed with placeholders for sense resistors,factory-populated with 0 ⌦. Where this was not the case,choke inductors could be reused in the same way. In bothcases, we replaced the part with a current-sense resistorselected such that the peak voltage drop did not exceed10 mV, which in all cases is less than 1 % of the supplyvoltage and therefore presents an acceptably small per-turbation. With a known resistance and measured voltagedrop, current can be determined by Ohm’s law.

To measure the voltages, we used a National Instru-ments PCI-6229 DAQ, to which the sense resistors wereconnected via twisted-pair wiring. The key characteris-tics of this hardware are summarised in Table 2.

Characteristic ValueMax. sample rate 250 kS/sInput ranges ±0.2 V, ±1 V, ±5 V and ±10 VResolution 16 bAccuracy 112 µV @ ±0.2 V range

1.62 mV @ ±5 V rangeSensitivity 5.2 µV @ ±0.2 V range

48.8 µV @ ±5 V rangeInput impedance 10 G⌦

Table 2: National Instruments PCI-6229 DAQ specifica-tions [6].

2

[Carroll, et. al., USENIX 2010]

Hardware Specs

2 Methodology

Our approach to profiling energy consumption is to takephysical power measurements at the component level ona piece of real hardware. In this section, we describethe hardware and software used in the experiments, andexplain our benchmarking methodology.

There are three elements to the experimental setup:the device-under-test (DuT), a hardware data acquisition(DAQ) system, and a host computer.

2.1 Device under testThe DuT was the Openmoko Neo Freerunner (revisionA6) mobile phone. It is a 2.5G smartphone featuring alarge, high-resolution touchscreen display, and many ofthe peripherals typical of modern devices. Table 1 listsits key components. The notable differences between ourdevice and a modern smartphone are the lack of a cameraand 3G modem.

Component SpecificationSoC Samsung S3C2442CPU ARM 920T @ 400 MHzRAM 128 MiB SDRAMFlash 256 MiB NANDCellular radio TI Calypso GSM+GPRSGPS u-blox ANTARIS 4Graphics Smedia Glamo 3362LCD Topploy 480⇥ 640SD Card SanDisk 2 GBBluetooth Delta DFBM-CS320WiFi Accton 3236AQAudio codec Wolfson WM8753Audio amplifier National Semiconductor LM4853Power controller NXP PCF50633Battery 1200 mAh, 3.7 V Li-Ion

Table 1: Freerunner hardware specifications.

This device was selected because the design files, par-ticularly the circuit schematics [7], are freely available.This is critical for our approach to power measurement,which relies on understanding the power distribution net-work at the circuit level. For this reason, few other de-vices would be suitable.

The high-level architecture of the Freerunner is shownin Figure 1. The total system memory is split equally be-tween two banks, one external RAM package, and oneon-chip. All peripherals except the graphics chip com-municate with the application processor (CPU) by pro-grammed I/O over various serial buses.

The other devices studied, the HTC Dream (G1) andGoogle Nexus One (N1), are described in Section 4.

ApplicationsProcessor

NAND

SDRAM

GSM

GPS

Codec

Amp

WiFi

Bluetooth

Graphics SDRAMLCD

SD Card

Host bus

I2C

SDIO

USB

serial

serial

Figure 1: Architecture of the Freerunner device, showingthe important components and their interconnects.

2.2 Experimental setup

To calculate the power consumed by any component,both the supply voltage and current must be determined.

To measure current, we inserted sense resistors on thepower supply rails of the relevant components—this isrelatively simple on the DuT selected, since most of themhave been designed with placeholders for sense resistors,factory-populated with 0 ⌦. Where this was not the case,choke inductors could be reused in the same way. In bothcases, we replaced the part with a current-sense resistorselected such that the peak voltage drop did not exceed10 mV, which in all cases is less than 1 % of the supplyvoltage and therefore presents an acceptably small per-turbation. With a known resistance and measured voltagedrop, current can be determined by Ohm’s law.

To measure the voltages, we used a National Instru-ments PCI-6229 DAQ, to which the sense resistors wereconnected via twisted-pair wiring. The key characteris-tics of this hardware are summarised in Table 2.

Characteristic ValueMax. sample rate 250 kS/sInput ranges ±0.2 V, ±1 V, ±5 V and ±10 VResolution 16 bAccuracy 112 µV @ ±0.2 V range

1.62 mV @ ±5 V rangeSensitivity 5.2 µV @ ±0.2 V range

48.8 µV @ ±5 V rangeInput impedance 10 G⌦

Table 2: National Instruments PCI-6229 DAQ specifica-tions [6].

2


Experimental Methodology

•  Zero ohms sense resistor in series to power for each module. – Ensure voltage drop is no more than 10mV (< 1%) – Measure voltage across resistor to get current value. Calculate current by dividing resistance of “Zero ohm” resistor

•  Voltage measured using NI’s PCI 6229 DAQ – 16b ADC, 250ks/s


Power in Suspend State

0

5

10

15

20

25

30

35

GSM CPU

RAM WiF

i

Gra

phic

s

Audi

o

Res

t

Pow

er (m

W)

Figure 2: Power breakdown in the suspended state. Theaggregate power consumed is 68.6 mW.

3 Results

3.1 Baseline casesPrior to running any benchmarks, we established thebaseline power state of the device, when no applicationsare running. There are two different cases to consider:suspended and idle. For the idle case, there is also theapplication-independent power consumption of the back-light to consider.

3.1.1 Suspended device

A mobile phone will typically spend a large amount oftime in a state where it is not actively used. This meansthat the application processor is idle, while the commu-nications processor performs a low level of activity, asit must remain connected to the network be able to re-ceive calls, SMS messages, etc. As this state tends todominate the time during which the phone is switchedon, the power consumed in this state is critical to batterylifetime.

The Android OS running on the application proces-sor aggressively suspends to RAM during idle periods,whereby all necessary state is written to RAM and thedevices are put into low-power sleep modes (where ap-propriate). To quantify power use while suspended, weforced the device into Android’s suspended state andmeasured the power over a 120 second period. Figure 2shows the results, averaged over 10 iterations. The av-erage aggregate power is 68.6 mW, with a relative stan-dard deviation (RSD) of 8.2 %. The large fluctuationsare largely due to the GSM (14.4 % RSD) and graphics(13.0 %) subsystems.

The GSM subsystem power clearly dominates whilesuspended, consuming approximately 45 % of the overallpower. Despite maintaining full state, RAM consumesnegligible power—less than 3 mW. Note that the GSM

0 10 20 30 40 50 60 70 80 90

GSM CPU

RAM WiF

i

Gra

phic

s

LCD

Audi

o

Res

t

Pow

er (m

W)

Figure 3: Average power consumption while in the idlestate with backlight off. Aggregate power is 268.8 mW.

subsystem in our device does not use system memory—ithas its own bank of RAM which we include in the GSMpower measurements.

3.1.2 Idle device

The device is in the idle state if it is fully awake (not sus-pended) but no applications are active. This case consti-tutes the static contribution to power of an active system.We run this case with the backlight turned off, but therest of the display subsystem enabled.

Figure 3 shows the power consumed in the idle state.As with the suspend benchmark, we ran 10 iterations,each of 120 seconds in the idle state. Power consumedin this state was very stable, with an RSD of 2.6 %, in-fluenced largely by GSM, which varied with an RSD of30 %. All other components showed an RSD below 1 %.

Figure 3 shows that the display-related subsystemsconsume the largest proportion of power in the idlestate—approximately 50 % due to the graphics chip andLCD alone, and up to 80 % with backlight at peak bright-ness. GSM is also a large consumer, at 22 % of aggregatepower.

3.1.3 Display

Figure 4 shows the power consumed by the displaybacklight over the range of available brightness levels.That level is an integer value between 1 and 255, pro-grammed into the power-management module, used tocontrol backlight current. Android’s brightness-controluser-interface provides linear control of this value be-tween 30 and 255.

The minimum backlight power is approximately7.8 mW, the maximum 414 mW, and a centred slider cor-responds to a brightness level of 143, consuming 75 mW.The backlight consumes negligible power when disabled(as in the above idle benchmarks).

4


Power in IDLE State

0

5

10

15

20

25

30

35

GSM CPU

RAM WiF

i

Gra

phic

s

Audi

o

Res

t

Pow

er (m

W)

Figure 2: Power breakdown in the suspended state. Theaggregate power consumed is 68.6 mW.

3 Results

3.1 Baseline casesPrior to running any benchmarks, we established thebaseline power state of the device, when no applicationsare running. There are two different cases to consider:suspended and idle. For the idle case, there is also theapplication-independent power consumption of the back-light to consider.

3.1.1 Suspended device

A mobile phone will typically spend a large amount oftime in a state where it is not actively used. This meansthat the application processor is idle, while the commu-nications processor performs a low level of activity, asit must remain connected to the network be able to re-ceive calls, SMS messages, etc. As this state tends todominate the time during which the phone is switchedon, the power consumed in this state is critical to batterylifetime.

The Android OS running on the application proces-sor aggressively suspends to RAM during idle periods,whereby all necessary state is written to RAM and thedevices are put into low-power sleep modes (where ap-propriate). To quantify power use while suspended, weforced the device into Android’s suspended state andmeasured the power over a 120 second period. Figure 2shows the results, averaged over 10 iterations. The av-erage aggregate power is 68.6 mW, with a relative stan-dard deviation (RSD) of 8.2 %. The large fluctuationsare largely due to the GSM (14.4 % RSD) and graphics(13.0 %) subsystems.

The GSM subsystem power clearly dominates whilesuspended, consuming approximately 45 % of the overallpower. Despite maintaining full state, RAM consumesnegligible power—less than 3 mW. Note that the GSM

0 10 20 30 40 50 60 70 80 90

GSM CPU

RAM WiF

i

Gra

phic

s

LCD

Audi

o

Res

t

Pow

er (m

W)

Figure 3: Average power consumption while in the idlestate with backlight off. Aggregate power is 268.8 mW.

subsystem in our device does not use system memory—ithas its own bank of RAM which we include in the GSMpower measurements.

3.1.2 Idle device

The device is in the idle state if it is fully awake (not sus-pended) but no applications are active. This case consti-tutes the static contribution to power of an active system.We run this case with the backlight turned off, but therest of the display subsystem enabled.

Figure 3 shows the power consumed in the idle state.As with the suspend benchmark, we ran 10 iterations,each of 120 seconds in the idle state. Power consumedin this state was very stable, with an RSD of 2.6 %, in-fluenced largely by GSM, which varied with an RSD of30 %. All other components showed an RSD below 1 %.

Figure 3 shows that the display-related subsystemsconsume the largest proportion of power in the idlestate—approximately 50 % due to the graphics chip andLCD alone, and up to 80 % with backlight at peak bright-ness. GSM is also a large consumer, at 22 % of aggregatepower.

3.1.3 Display

Figure 4 shows the power consumed by the displaybacklight over the range of available brightness levels.That level is an integer value between 1 and 255, pro-grammed into the power-management module, used tocontrol backlight current. Android’s brightness-controluser-interface provides linear control of this value be-tween 30 and 255.

The minimum backlight power is approximately7.8 mW, the maximum 414 mW, and a centred slider cor-responds to a brightness level of 143, consuming 75 mW.The backlight consumes negligible power when disabled(as in the above idle benchmarks).

4

Back light off


Backlight Power

0 50

100 150 200 250 300 350 400 450

0 50 100 150 200 250

Pow

er (m

W)

Brightness level

Figure 4: Display backlight power for varying brightnesslevels.

We also measured how the content displayed on theLCD affected its power consumption: 33.1 mW for acompletely white screen, and 74.2 mW for a a blackscreen. Display content can therefore affect overallpower consumption by up to 43 mW.

3.2 Micro-benchmarksAs mentioned in Section 2.4, we used micro-benchmarksto determine the contribution to overall power from var-ious system components. Specifically we used bench-marks to exercise the application processor (CPU andmemory), the flash storage devices, and the network in-terfaces.

3.2.1 CPU and RAM

To measure CPU and RAM power, we ran a subset of theSPEC CPU2000 suite. There are several reasons for notrunning all benchmarks of the suite. Firstly, we couldonly use benchmarks which we could build and run onthe Android OS, which rules out those written in C++or Fortran, due to Android’s lack of run-time support forthese languages. They also needed to fit into the phone’slimited memory and their execution times needed to beshort enough to give reasonable turn-around. Finally,we were only interested in establishing the power con-sumption of CPU and memory, rather than making com-parisons between different platforms’ algorithms, hencecompleteness of the suite was not a relevant considera-tion.

From the candidates remaining according to the abovecriteria, we selected a set representing a good spectrumof CPU and memory utilisation, from highly CPU-boundto highly memory-bound. We determined memory-boundedness by running the entire suite on a serverLinux system and comparing the slowdown due to fre-quency scaling. Snowdon et al. [9] show that this slow-down is primarily due to memory-boundedness. While

0 20 40 60 80

100 120 140 160 180 200

equa

ke vpr

gzip

craf

ty

mcf

idle

Pow

er (m

W)

CPU(100MHz)RAM(100MHz)CPU(400MHz)RAM(400MHz)

Figure 5: CPU and RAM power when running SPECCPU2000 micro-benchmarks, sorted by CPU power.

we do not expect the benchmarks to behave similarly onthe different platforms, our aim is only to select bench-marks with different characteristics.

The SPEC CPU2000 benchmarks ultimately selectedare equake, vpr, gzip, crafty and mcf.

For each of the benchmarks, we measured the aver-age CPU and RAM power at fixed core frequencies of100 MHz and 400 MHz. We also measured power forthe system in the idle state. Figure 5 shows these results,averaged over 10 runs. The RSD is less than 3 % in allcases.

For the idle, equake, vpr and gzip workloads,CPU power dominates RAM power considerably at bothfrequencies. However, crafty and mcf show thatRAM power can exceed CPU power, albeit by a smallmargin.

Table 3 shows the effect of frequency scaling on theperformance, as well as combined CPU and RAM powerand energy of the benchmarks. The wide range of slow-down factors across the different benchmarks validatesour selection of workloads as representing a range ofCPU/memory utilisations.

Benchmark Performance Power Energyequake 26 % 36 % 135 %vpr 31 % 40 % 125 %gzip 38 % 43 % 112 %crafty 63 % 62 % 100 %mcf 74 % 69 % 93 %idle - 71 % -

Table 3: SPEC CPU2000 performance, power and en-ergy of 100 MHz relative to 400 MHz. Both CPU andRAM power/energy are included.

5


Power for some bench marks

0 50

100 150 200 250 300 350 400 450

0 50 100 150 200 250

Pow

er (m

W)

Brightness level

Figure 4: Display backlight power for varying brightnesslevels.

We also measured how the content displayed on theLCD affected its power consumption: 33.1 mW for acompletely white screen, and 74.2 mW for a a blackscreen. Display content can therefore affect overallpower consumption by up to 43 mW.

3.2 Micro-benchmarksAs mentioned in Section 2.4, we used micro-benchmarksto determine the contribution to overall power from var-ious system components. Specifically we used bench-marks to exercise the application processor (CPU andmemory), the flash storage devices, and the network in-terfaces.

3.2.1 CPU and RAM

To measure CPU and RAM power, we ran a subset of theSPEC CPU2000 suite. There are several reasons for notrunning all benchmarks of the suite. Firstly, we couldonly use benchmarks which we could build and run onthe Android OS, which rules out those written in C++or Fortran, due to Android’s lack of run-time support forthese languages. They also needed to fit into the phone’slimited memory and their execution times needed to beshort enough to give reasonable turn-around. Finally,we were only interested in establishing the power con-sumption of CPU and memory, rather than making com-parisons between different platforms’ algorithms, hencecompleteness of the suite was not a relevant considera-tion.

From the candidates remaining according to the abovecriteria, we selected a set representing a good spectrumof CPU and memory utilisation, from highly CPU-boundto highly memory-bound. We determined memory-boundedness by running the entire suite on a serverLinux system and comparing the slowdown due to fre-quency scaling. Snowdon et al. [9] show that this slow-down is primarily due to memory-boundedness. While

0 20 40 60 80

100 120 140 160 180 200

equa

ke vpr

gzip

craf

ty

mcf

idle

Pow

er (m

W)

CPU(100MHz)RAM(100MHz)CPU(400MHz)RAM(400MHz)

Figure 5: CPU and RAM power when running SPECCPU2000 micro-benchmarks, sorted by CPU power.

we do not expect the benchmarks to behave similarly onthe different platforms, our aim is only to select bench-marks with different characteristics.

The SPEC CPU2000 benchmarks ultimately selectedare equake, vpr, gzip, crafty and mcf.

For each of the benchmarks, we measured the aver-age CPU and RAM power at fixed core frequencies of100 MHz and 400 MHz. We also measured power forthe system in the idle state. Figure 5 shows these results,averaged over 10 runs. The RSD is less than 3 % in allcases.

For the idle, equake, vpr and gzip workloads,CPU power dominates RAM power considerably at bothfrequencies. However, crafty and mcf show thatRAM power can exceed CPU power, albeit by a smallmargin.

Table 3 shows the effect of frequency scaling on theperformance, as well as combined CPU and RAM powerand energy of the benchmarks. The wide range of slow-down factors across the different benchmarks validatesour selection of workloads as representing a range ofCPU/memory utilisations.

Benchmark Performance Power Energyequake 26 % 36 % 135 %vpr 31 % 40 % 125 %gzip 38 % 43 % 112 %crafty 63 % 62 % 100 %mcf 74 % 69 % 93 %idle - 71 % -

Table 3: SPEC CPU2000 performance, power and en-ergy of 100 MHz relative to 400 MHz. Both CPU andRAM power/energy are included.

5


Storage Power

0

20

40

60

80

100

NAND CPU RAM SD CPU RAM

Pow

er (m

W)

ReadsWrites

SD CardInternal NAND Flash

Figure 6: SD, NAND, CPU and RAM power for flashstorage read and write benchmarks.

3.2.2 Flash storage

Bulk storage on the Freerunner device is provided by256 MiB of internal NAND flash, and an external microSecure Digital (SD) card slot. To measure their max-imum power consumption, we used the Linux dd pro-gram to perform streaming reads and writes. For readswe copied a 64 MiB file, filled with random data, to/dev/null in 4 KiB blocks. For writes, 8 MiB of ran-dom data was written, with an fsync between succes-sive 4 KiB blocks to ensure predictability of writes. Be-tween each iteration we forced a flush of the page cache.

Figure 6 shows the power consumed by the NANDflash and SD card, as well as the CPU and RAM, aver-aged over 10 iterations of each workload. Table 4 showsthe corresponding data throughput, efficiency (includingNAND/SD power and the CPU and RAM power to sup-port it), and idle power consumption. The power andthroughput RSD is less than 5 % in all cases.

The graphics module, which contains the physicalSD card interface, showed a power increase of 2.2 mW(2.6 % above static) for writes, and a 21.1 mW increase(26 %) for reads.

Metric NAND SDIdle (mW) 0.4 1.4Read

throughput (MiB/s) 4.85 2.36efficiency (MiB/J) 65.0 31.0

Writethroughput (KiB/s) 927.1 298.1efficiency (MiB/J) 10.0 5.2

Table 4: Flash storage power and performance.

0

100

200

300

400

500

600

700

800

WiFi GSM CPU RAM

Pow

er (m

W)

WiFiGPRS

Figure 7: Power consumption of WiFi and GSMmodems, CPU, and RAM for the network micro-benchmark.

3.2.3 Network

In this benchmark we stressed the two main networkingcomponents of the device: WiFi and GPRS (provided bythe GSM subsystem). The test consisted of downloadinga file via HTTP using wget. The files contained randomdata, and were 15 MiB for WiFi, and 50 KiB for GPRS.The results of 10 iterations of the benchmark are shownin Figure 7.

WiFi showed a throughput of 660.1± 36.8 KiB/s, andGPRS 3.8±1.0 KiB/s. However, they both show compa-rable power consumption far exceeding the contributionof the RAM and CPU. The increased CPU and RAMpower for WiFi reflects the cost of processing data witha higher throughput. Despite highly-variable throughput,GSM showed a relatively consistent power consumptionwith an RSD of approximately 2 %.

To test the effect of signal strength on power andthroughput, we re-ran the network benchmarks with thedevice shielded within a metal box of 2 mm thickness.Over GPRS, this resulted in an increase of GSM power of30 %, but no effect on throughput. The shielding resultedin a reported signal strength drop of 10 dBm. Over WiFi,the signal strength dropped by only 2 dBm, and no effecton throughput or power consumption was observed.

3.2.4 GPS

To measure power consumption of the GPS subsystem,we enabled the module and ran the GPSStatus2 An-droid application. Table 5 shows the power consumedby the GPS module in three situations; using only the in-ternal antenna, with an external active antenna attached,and when idle (i.e. powered down).

We noticed that the energy consumption of the mod-ule is largely independent of the received signal—neitherthe number of satellites, nor the signal strength, had anyappreciable effect.

This observation is contrary to the part’s data sheet

6


Networking power

0

20

40

60

80

100

NAND CPU RAM SD CPU RAM

Pow

er (m

W)

ReadsWrites

SD CardInternal NAND Flash

Figure 6: SD, NAND, CPU and RAM power for flashstorage read and write benchmarks.

3.2.2 Flash storage

Bulk storage on the Freerunner device is provided by256 MiB of internal NAND flash, and an external microSecure Digital (SD) card slot. To measure their max-imum power consumption, we used the Linux dd pro-gram to perform streaming reads and writes. For readswe copied a 64 MiB file, filled with random data, to/dev/null in 4 KiB blocks. For writes, 8 MiB of ran-dom data was written, with an fsync between succes-sive 4 KiB blocks to ensure predictability of writes. Be-tween each iteration we forced a flush of the page cache.

Figure 6 shows the power consumed by the NANDflash and SD card, as well as the CPU and RAM, aver-aged over 10 iterations of each workload. Table 4 showsthe corresponding data throughput, efficiency (includingNAND/SD power and the CPU and RAM power to sup-port it), and idle power consumption. The power andthroughput RSD is less than 5 % in all cases.

The graphics module, which contains the physicalSD card interface, showed a power increase of 2.2 mW(2.6 % above static) for writes, and a 21.1 mW increase(26 %) for reads.

Metric NAND SDIdle (mW) 0.4 1.4Read

throughput (MiB/s) 4.85 2.36efficiency (MiB/J) 65.0 31.0

Writethroughput (KiB/s) 927.1 298.1efficiency (MiB/J) 10.0 5.2

Table 4: Flash storage power and performance.

0

100

200

300

400

500

600

700

800

WiFi GSM CPU RAM

Pow

er (m

W)

WiFiGPRS

Figure 7: Power consumption of WiFi and GSMmodems, CPU, and RAM for the network micro-benchmark.

3.2.3 Network

In this benchmark we stressed the two main networkingcomponents of the device: WiFi and GPRS (provided bythe GSM subsystem). The test consisted of downloadinga file via HTTP using wget. The files contained randomdata, and were 15 MiB for WiFi, and 50 KiB for GPRS.The results of 10 iterations of the benchmark are shownin Figure 7.

WiFi showed a throughput of 660.1± 36.8 KiB/s, andGPRS 3.8±1.0 KiB/s. However, they both show compa-rable power consumption far exceeding the contributionof the RAM and CPU. The increased CPU and RAMpower for WiFi reflects the cost of processing data witha higher throughput. Despite highly-variable throughput,GSM showed a relatively consistent power consumptionwith an RSD of approximately 2 %.

To test the effect of signal strength on power andthroughput, we re-ran the network benchmarks with thedevice shielded within a metal box of 2 mm thickness.Over GPRS, this resulted in an increase of GSM power of30 %, but no effect on throughput. The shielding resultedin a reported signal strength drop of 10 dBm. Over WiFi,the signal strength dropped by only 2 dBm, and no effecton throughput or power consumption was observed.

3.2.4 GPS

To measure power consumption of the GPS subsystem,we enabled the module and ran the GPSStatus2 An-droid application. Table 5 shows the power consumedby the GPS module in three situations; using only the in-ternal antenna, with an external active antenna attached,and when idle (i.e. powered down).

We noticed that the energy consumption of the mod-ule is largely independent of the received signal—neitherthe number of satellites, nor the signal strength, had anyappreciable effect.

This observation is contrary to the part’s data sheet

6


Processor power

G1 N1SoC Qualcomm MSM7201 Qualcomm QSD 8250CPU ARM 11 @ 528 MHz ARMv7 @ 1 GHzRAM 192 MiB 512 MiBDisplay 3.2” TFT, 320x480 3.7” OLED, 480x800Radio UMTS+HSPA UMTS+HSPAOS Android 1.6 Android 2.1Kernel Linux 2.6.29 Linux 2.6.29

Table 6: G1 and Nexus One specifications.

0 100 200 300 400 500 600 700 800 900

equa

ke vpr

gzip

craf

tym

cfid

le

equa

ke vpr

gzip

craf

tym

cfid

le

Pow

er (m

W)

fminfmax

G1N1

Figure 15: N1 and G1 system power for SPEC CPU2000benchmarks.

Performance (%) Power (%)Benchmark G1 N1 G1 N1equake 67 25 87 26vpr 68 25 87 26gzip 71 25 86 27crafty 76 25 89 28mcf 84 54 91 41

Table 7: SPEC CPU2000 performance and average sys-tem power of 246 MHz relative to 384 MHz on the G1,and 245 MHz relative to 998 MHz on the N1.

4.3 Bluetooth

As noted earlier, we were unable to get Bluetooth work-ing reliably on the Freerunner phone. To get an ideaof Bluetooth power consumption, we re-ran the audiobenchmark on the G1 with the audio output to a Blue-tooth stereo headset. The power difference between thisand the baseline audio benchmark should yield the con-sumption of the Bluetooth module, because (as shown inour Freerunner benchmarks) the power consumed by theaudio subsystem is almost entirely static.

Power (mW)Benchmark Total BluetoothAudio baseline 459.7 -Bluetooth (near) 495.7 36.0Bluetooth (far) 504.7 44.9

Table 8: G1 Bluetooth power under the audio bench-mark.

Table 8 shows the total and estimated Bluetooth powerconsumption for the audio benchmarks. In the ”near”benchmark, the headset was placed approximately 30 cmfrom the phone, and about 10 m in the ”far” benchmark.

4.4 BenchmarksTable 9 shows total system power consumption for theFreerunner, G1, and Nexus One for a selection of ourbenchmarks. The power consumption of the backlight(OLED for the N1) has been subtracted out, since it ishighly dependent on the user’s brightness setting. Ta-ble 10 shows the additional power consumption of theOLED display at minimum and maximum brightnesslevels.

The lower power consumption of the G1 in the idle,web and email benchmarks can be attributed to the ex-cellent low-power state of its SoC and effective use of itby software. This can be seen in the SPEC benchmarks,where the idle system consumes less than 22 mW; theidle CPU power must be lower still.

The power disparity for the phone call benchmark islikely due to power consumed by the non-radio compo-nents of the system. The G1 and Nexus One phones entera suspended state during the call, offloading all function-ality to the UMTS module. In contrast, the Freerunnerremains in a fully-active state throughout. The powerconsumption of the GSM subsystem alone (832.4 mW) iscomparable to the G1 and N1 system consumption. Dueto lack of freely-available documentation, it is not clearwhether the Freerunner’s GSM chipset lacks this feature,or if it is not supported in software.

10


Key observa@ons

•  Sta@c power due GSM, Backlight dominates – Shut off these when not in use

•  Low voltage doesn’t necessarily mean low energy – Longer run @me for the same app – more hit due to sta@c energy consump@on


Focus of this course

•  Ultra low power compu@ng – Low power circuit techniques – Dynamic power and energy op@miza@on – Ultra low voltage design

power,’heat&’energy’in’ electronic’systems’ · 2019. 3. 5. ·...

Documents