UPTEC F 18050
Examensarbete 30 hp September 2018
A state-based method to model
and analyze the power consumption of embedded systems
Lars Haulin
Teknisk- naturvetenskaplig fakultet UTH-enheten
Besöksadress:
Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress:
Box 536 751 21 Uppsala Telefon:
018 – 471 30 03 Telefax:
018 – 471 30 00 Hemsida:
http://www.teknat.uu.se/student
Abstract
A state-based method to model and analyze the power consumption of embedded systems
Lars Haulin
In this work I have evaluated a method to model, measure and analyze the power consumption of embedded systems.
The method combines current measurement with debug trace data telling which parts of the systems that are enabled. This makes it possible to compute the individual current consumption of the parts in the system from a single measurement point.
The method allows an embedded systems engineer to determine the power
consumption of individual parts in a system to either get an overview or to compare several revisions of hardware and/or software with each other.
The method also captures the system dynamics of the power delivery route. This makes the model consumption behave more like the actual system around state transitions.
The case study is focused on the Arm-based microcontroller CC2650 from Texas Instruments and uses the I-scope/I-jet probe from IAR Systems to measure current consumption and collect trace data.
Populärvetenskaplig sammanfattning
Den kanske största förändringen i vårt dagliga liv de senaste fyrtio åren är inte vilka apparater vi har, utan hur de är uppbyggda. Det fanns bilar, telefoner och musikspelare även då, men dagens system är till mycket hög grad datorstyrda.
Dessa små datorer som sitter inuti andra apparater med syfte att styra dem kallas inbyggda system. Många av de inbyggda systemen är batteridrivna och det är viktigt att hålla deras strömförbrukning så låg som möjligt.
Strömförbrukningen hos ett system varierar beroende på vad dess styrprogram gör. När till exempel en lampa tänds eller en motor startar så ökar ström- förbrukningen. Det krävs bra styrning och kontroll för att inte slösa energi i onödan.
För att bygga ett effektivt system krävs noggrannt utvecklingsarbete. Varje ändring som görs kan påverka strömförbrukningen. Många delar samverkar och det är inte alltid uppenbart hur mycket ström varje enskild del av systemet drar.
Det måste i så fall mätas, och om det arbetet kan underlättas sparar det tid.
I detta arbete har jag utvärderat en metod för att mäta strömförbrukningen i inbyggda system. Jag har kombinerat strömmätningar med information från systemet om vilka delar som är igång. Utifrån det har jag skapat en modell för systemets strömförbrukning. Den stora styrkan med denna metod är att strömförbrukningen hos enskilda delar kan mätas utifrån en enda mätpunkt.
En förändring i strömförbrukning sker inte direkt. Det är samma princip som att det tar tid för en bil att komma upp i hastighet efter ett gaspådrag och att ett kallt rum inte blir varmt direkt när man sätter igång ett värmeelement.
Denna tröghet till förändring kallas formellt för systemdynamik.
Mätmetoden i detta arbete fångar även systemdynamiken i strömförbrukningen.
Det gör att man kan förutspå vilken strömförbrukning systemet borde ha, och jämföra hur väl denna stämmer med den strömförbrukning som faktiskt mätts upp.
Arbetet har utförts på IAR Systems, ett företag som skapar verktyg för utveck- ling av inbyggda system.
Acknowledgments
I am very thankful for all the help, input and support that I have received during my work. There are many people that have helped me both directly and indirectly.
I would like to thank my supervisor Jaan Reio for answering any obscure and detailed question I have had about debug probes and for generally supporting me through the project.
Many thanks to my evaluator Professor Christian Rohner for advice on priorities and how to set my project goals.
Finally, thanks to all the people at IAR Systems for making this thesis possible by providing hardware and software tools to work with. I have really enjoyed the welcoming atmosphere, interesting discussions and narrow but entertaining compiler-development-team-humor.
Contents
1 Introduction 7
1.1 IAR Systems . . . 8
1.2 Problem description . . . 8
1.3 Goal and purpose . . . 8
1.4 Limitation of the study . . . 9
2 Background 10 2.1 Energy, power and current consumption . . . 10
2.1.1 Causes of power consumption . . . 11
2.1.2 Measuring power consumption . . . 11
2.1.3 Reducing power consumption . . . 11
2.2 Microcontrollers . . . 12
2.2.1 Peripherals . . . 13
2.2.2 Debugging and programming . . . 13
2.2.3 Tracing . . . 13
2.3 Arm Cortex-M microcontrollers . . . 14
2.3.1 CMSIS . . . 14
2.3.2 The Coresight debug interface . . . 14
2.3.3 ITM messages . . . 14
2.4 Debug probes with power measuring . . . 15
2.5 How to measure power consumption with the I-scope probe . . . 16
3 Method 18 3.1 Comparing power consumption . . . 18
3.2 Measuring several power consumers from a single measurement point . . . 18
3.3 Measurement residual . . . 19
3.4 A current model with automatic calibration . . . 20
3.5 Computing a system impulse response . . . 21
3.6 Hardware platforms . . . 22
3.6.1 SimpleLink SensorTag . . . 22
3.6.2 CC2650 LaunchPad . . . 23
3.7 Application software for CC2650 . . . 23
3.8 Adding instrumentation to the application . . . 24
3.9 Acquiring and exporting measurement data . . . 25
3.10 Data processing . . . 26
4 Results and analysis 27
4.1 Prestudy with manual analysis . . . 27
4.2 Automated analysis . . . 29
4.3 Parameter visualization . . . 29
4.3.1 Pie chart . . . 29
4.3.2 Log-log diagram . . . 31
4.3.3 Comparison . . . 31
4.4 Time-based visualization . . . 31
4.4.1 The raw model . . . 32
4.4.2 Model extended with system dynamics . . . 33
4.5 Residual analysis . . . 36
4.5.1 Current consumption depends on counter value . . . 36
4.5.2 Periodic peaks . . . 37
4.6 Failures and dead ends . . . 40
4.6.1 State modeling . . . 40
4.6.2 Dynamics modeling . . . 40
4.6.3 Other hardware platforms . . . 40
5 Discussion 41 6 Conclusions 43 7 Future work 44 7.1 Automatic placement of instrumentation . . . 44
7.2 Extending the model with transient events . . . 44
7.3 Extending the model with variance . . . 45
7.4 Other architectures . . . 45
7.5 Driving the model to new states from power measurements only . 45 Appendix 46 A Abbreviations 46 B Bibliography 47 C Computation example 49 C.1 Acquiring data from a simulated circuit . . . 49
C.2 Implementation of parameter computation . . . 50
C.3 Simulation data from LTspice model . . . 53
1 Introduction
The perhaps biggest change in everyday life over the last forty years is not what things we have, but how they are built. There were cars, telephones and music players in the seventies, but they are no longer based on mechanical carburetors, relays and vinyl records. They are instead embedded systems.
The definition of an embedded system can be worded in many ways, but I like this short and elegant description:
An embedded system is a small computer with a specific purpose.[1]
Embedded systems are everywhere, they occur in industrial applications such as automatic control, measurement and communication systems, but also as previously mentioned in in modern cars, media systems and house appliances.
All these systems run on electricity and the total energy consumption of these systems add up to a considerable amount. Energy consumption is most often re- lated to operating cost, but for battery driven systems a low power consumption might be a functional requirement.
The power consumption of a system varies depending on what the system pro- gram does. When a lamp or motor is turned on, the power consumption will increase. Keeping a part of a system on when not needed wastes energy. Good control is needed to avoid this.
It takes careful development to build an effective system. This can be a tedious work, as a system can consist of many parts and it is not always obvious how much every part of the system contributes to the total power consumption. If this work can be eased, it will save development time.
In this work I have evaluated a method to measure the power consumption of the different parts of an embedded system. The method can measure the consumption of several different parts using only a single measurement point.
This is achieved by combining the measurement with debug information from the system about which parts of the system that are currently enabled.
I hope this method will help embedded system developers to get a picture of where the most power is consumed in their systems and make it easier to com- pare two different revisions of a system with each other from a power consump- tion perspective.
1.1 IAR Systems
This work has been done at IAR Systems, a company that supplies tools for em- bedded software development. Their main product IAR Embedded Workbench is an integrated development environment. It features a source code editor, compiler and debugger.
Another product from IAR Systems is the I-jet/I-scope debug probe. It can be used to program and debug an embedded system and can also measure the power consumption of the system.
1.2 Problem description
Embedded system development is often an iterative work done in several small steps, whether the goal is to reduce the power consumption or improve any other system characteristic such as code size or execution time. It is not always obvious if a program change has had the desired impact, or even if the change has had any effect at all. The developers rely on code metrics to evaluate changes.
Some code metrics are simple to set up, measure and interpret. Some examples are code size, code coverage and passing tests.
One metric that is hard to automatize is power consumption. Measurement, modeling and parameter extraction are not straightforward to automatize, and typically requires manual testing or a custom built test bench.
IAR Embedded Workbench already contains some power profiling tools that can measure how much time the program spends in different functions and how much power the system consumes. However, the profiling does not take peripheral devices into account. The same part of a program can consume different amounts of power depending on the state of the peripherals.
1.3 Goal and purpose
This thesis investigates the power consumption of embedded systems, and how the existing development tools can be improved to measure the power consump- tion of a system with multiple states.
I have investigated a method that makes it possible to compute the individual consumption of several internal system parts from a single current measurement point by combining the current consumption measurements with debug data added to the device drivers of the system software.
The questions I try to answer in this work are:
• How well does this method work?
• How precise can the energy consumption be modeled?
1.4 Limitation of the study
This study has focused on technology available for microcontrollers based on the Arm Cortex-M architecture. I have only performed measurements on systems based on the CC2650 chip and only used the I-jet/I-scope debug probe for the measurements in my case study.
The study has been held from a software perspective. Full system energy reduc- tion is a multi-dimensional optimization problem where not only software but also hardware must be considered. The software-only perspective is relevant for existing products where the hardware is fix.
2 Background
This chapter presents the theoretical background for this thesis, the fundamental concepts of energy consumption, the available technology and equipment, and previous research in the area of power reduction.
2.1 Energy, power and current consumption
It is important to know the distinction between the consumption of energy, power and current. They can sometimes be used interchangeably, but only when certain conditions hold.
The power consumption of a device is the amount of energy that it consumes in a given moment. The energy consumption of a device is the sum of the power consumption over time.
For example, a camera flash has a very high power consumption when it is on, but as that time is very short the total energy consumption is moderate.
In electrical devices the power consumption P depends on the current con- sumption I and the voltage U through Joule’s law P = U·I. For systems with constant supply voltage the power depends only on the current, and minimizing the power consumption is equivalent to minimizing the current consumption.
Mathematically, the total energy consumption of an electric circuit can be ex- pressed as
E= Z T
0
P(t)dt = Z T
0
U(t)I(t)dt
so lowering the energy consumption E can be done by lowering either:
• the voltage U the system is using,
• the current I the system consumes, or
• the time T that the system is running.
An embedded system application is often running endlessly, so both energy and time would increase without limit. Because of this, it is more practical to use
2.1.1 Causes of power consumption
Some causes of power consumption can not be avoided, as some energy must be used to fulfill the functional requirements of the system. A radio transmitter must have enough power to broadcast, and a LED might appear dim if does not get enough power.
There are two types of loads that can consume power: resistive and reactive.
A resistive load behaves according to Ohms law. The current depends only on the voltage that is applied to the load and the resistance of the load. Resistive loads are simple to compute with, as they can be turned on and off without any thought of consumption impact.
Reactive loads are frequency dependent. A reactive load might consume a litte more power when it starts, but less power once on. If such a load is switched on and off more frequently, it will consume more power. An example of this is CMOS-circuitry. Every change in polarity on the gate of a transistor will consume an amount of charge. There are also other reactive loads that consume more power after being on for a while, then higher frequencies consume less power.
2.1.2 Measuring power consumption
The actual measurement of power consumption can be done in several different ways. The paper [2] summarizes some different methods that apply to embedded systems.
The most common way to measure the power consumption of a device is to use a shunt resistor. The shunt resistor is connected in series with the device to convert the current into a voltage. There are also other ways, but using a shunt resistor is a proven method that most engineers are familiar with and does not require advanced circuitry.
It is important to measure close to the current sink to catch rapid variations in the consumption. The capacitance on the power delivery route will dampen the high frequency content of the measured signal.
2.1.3 Reducing power consumption
Over the last 20 years, there has been a lot of research about how to reduce the energy consumption of embedded systems. The works are well summarized in the two surveys [3] and [4]. This section lists some of the most important results from those surveys.
The perhaps easiest way to reduce the power consumption of a system is to turn it off. This is often not a useful solution as it disables the system, but it makes a point: Without functional requirements, it is impossible to know if a system change is acceptable or not.
Power reduction efforts are most effective when they are introduced early in the design process. Before the design is fully determined, there is freedom to choose a system architecture based on power efficient communication protocols and freedom to pick the most power efficient circuits for the hardware.
Thorough power reduction requires efforts on every level of the system, and affects both hardware, software and system architecture. This is not always possible, for example when trying to make existing hardware perform better.
There are three general ways to reduce energy consumption:
• reduce the voltage and/or frequency of the system - DV(F)S, Dynamic Voltage (and Frequency) Scaling,
• turn off parts of the systems that consume power - DPM, Dynamic Power Management, or
• change the system (write more efficient code, make algorithm approxima- tions, change components).
The advantages of DV(F)S and DPM are that they can be performed at runtime if the system supports it, but system changes require hardware or software updates.
In an embedded system, it is not always possible to change the system voltage at runtime. But, it can be done in the hardware design phase. A lower supply voltage will decrease the power consumption of resistive parts.
The system frequency can also affect the power consumption. Lowering the clock frequency will decrease the power consumption of the CMOS-circuits. However, this might mean that the processor does not meet performance requirements in a real-time computation, or that it stays awake doing computations when it could have been put to sleep.
2.2 Microcontrollers
Microcontrollers are small computers contained in a single IC-chip. Like ordi- nary personal computers, they run programs and perform computations. But opposed to a personal computer, there is often no direct user interaction.
Microcontrollers are often used in systems that are manufactured in large series, and it is therefore important to match their specification with the requirements to keep the cost down. Microcontrollers can have internal memory ranging from less than a kilobyte to several hundred megabytes.
There are many different types of microcontrollers, because they are very spe- cialized to their application. The requirements on the microcontroller in a TV remote control are very different from the microcontrollers in a cellphone.
2.2.1 Peripherals
The main difference between a regular computer and microcontroller, besides performance, is how they interact with their surroundings. A microcontroller interacts with its surroundings using electrical signals, which the microcontroller can send and listen for on its pins. The pins are then connected to other components in the system.
The pins on a microcontroller can have slightly different capabilities, some can measure voltage levels while others have hardware support to act as serial com- munication interfaces. The availability of these peripheral units is also some- thing that distinguishes different microcontrollers from each other and affects their price. Most pins on a microcontroller have the capability to detect or send a high or low signal, this is called general purpose input and output, GPIO.
2.2.2 Debugging and programming
A personal computer interacts directly with the user through screen, keyboard and mouse, and the programs on a computer are created on the computer itself.
A microcontroller is not programmed directly. The programs for it are written and compiled into binaries on an ordinary personal computer. The binaries are then written to the microcontroller with special debug probes that connect to both the computer and the microcontroller. This programming procedure is often called flashing, as the program is written to flash memory.
The debug probes are also used to test and debug the microcontroller program using debug software running on the computer. This makes it possible to pause, resume and set breakpoints in the program. It is also possible to look at and/or change program data much like in a debugger for ordinary computer programs.
2.2.3 Tracing
Microcontroller programs often have real-time requirements, and this means that they can not be halted without restrictions. The control system for a quadcopter can not be halted when it is flying without causing damage to the system. In such situations it is not possible to extract data about the program execution by halting the processor and examining its internal memory.
Tracing is a way to extract runtime data without halting the program. It pro- vides an interface that can export information about the state of the program to the debug probe.
Tracing requires special hardware support, both inside the microcontroller and in the debug probe. Debug probes with tracing support typically have a lot of internal memory that can buffer data before sending it to the computer. This makes probes with tracing capabilities more expensive. Even if the microcon- troller does not support direct tracing, instrumentation can be implemented in software. [5]
2.3 Arm Cortex-M microcontrollers
The Cortex-M is a processor core from Arm. It is not manufactured by Arm themselves, but instead licensed to other manufacturers. This is attractive for silicon vendors, as they can use a proven design for new chips, and benefit from already existing compilers and that customers are familiar with the architecture.
2.3.1 CMSIS
The Arm Cortex Microcontroller Software Interface Standard (CMSIS) is a vendor-independent hardware abstraction layer for Cortex-M microcontrollers.
This standard enables a consistent software interface to the processor and the peripheral devices. This means that device drivers written using this interface can be used on any chip with peripherals that adhere to the standard. [6]
2.3.2 The Coresight debug interface
The CMSIS also specifies a debug and trace interface, called Coresight. It is used in Cortex-M and some of the other processors from Arm. This interface pro- vides both normal debugging with start/stop/step/breakpoints and non-invasive tracing. [7]
2.3.3 ITM messages
The Instrumentation and Trace Macrocell (ITM) is a Coresight component that allows the microcontroller application to send arbitrary data to the debugger in real time. Data is sent in chunks of 8, 16 or 32 bits over 32 channels. The division of data into channels allows the debugger to filter out the data that is relevant.
An ITM message is sent by writing data to a stimulus register. A write to this register will put the data in a queue to be sent. The application must check that there is room in the queue before writing to the register by reading from it.
The value is 1 if there is room and 0 if the queue is full. An example written in C using the CMSIS standard headers is shown in listing 1. The CMSIS-CORE standard reserves stimulus channels 0 and 31. Channel 0 is used as a UART and channel 31 is reserved for kernel use. [6, 8]
Listing 1: Example code to send an ITM-message.
1 void sendMessage ( uint8_t portNumber , uint8_t v a l u e ) { 2 while (ITM−>PORT[ portNumber ] . u32 == 0)
3 ; /∗ s p i n w a i t ∗/
4 ITM−>PORT[ portNumber ] . u8 = v a l u e ; 5 }
Table 1: Side-by side comparison of a few different debug probes with power measurement capabilities.
Manufacturer Name Resolution Range Channels Rate
Atmel [9] Power Debugger ±3 µA 0.5-100 mA A 62.5 kHz
±30 nA 1 mA-1 µA A
±500 µA 1 mA-1 µA B
IAR [10] I-jet + I-scope 12 bits (shunt) up to 4 200 kHz Keil + Hitex Ulink + PowerScale <3% 1 A-1 mA up to 4 100 kHz [11] (with ACM probe) <2.5% 0.5 A-0.2 µA
Lauterbach TRACE32 [12] 12 bits (shunt) up to 7 625 kHz
Segger [13] J-link Ultra+ ± 1 mA 0-300 mA 1 50 kHz
SiLabs [14] Built-in AEM 500 µA 0.25-50 mA 1 6250 Hz
probes 1 µA 0.1-250 µA
TI [15] XDS110 ±0.5 µA/2% 1 µA-25 mA 1 2 kHz
±0.5 µA/5% 25-100 mA
2.4 Debug probes with power measuring
There are many tools to measure the energy consumption with, such as am- meters or oscilloscopes. For microcontrollers, there are debug probes that can measure power and synchronize this with trace data from the program. The latter is an important feature, as this makes it possible to correlate program behaviour with power consumption. With this info, a developer can identify the parts of the program that could be reworked for energy efficiency.
A few probes are listed in table 1. All these probes can measure energy over time and not just the average consumption. The probes measure current in different ways.
The J-Link Ultra+ and XDS110 probes measure current when they provide power to the device. The I-jet also has this feature when used without the I-scope.
The Power Debugger and PowerScale probes have internal shunt resistances that the supply current is routed through. The ACM probe for the PowerScale has a measurement range of six orders of magnitude. It achieves this with several shunt resistances that it switches between automatically. [11]
The XDS110 probe from Texas Instruments does not use a shunt resistance. It instead uses a patented technique called EnergyTrace that computes the power consumption from the frequency of a DC-DC converter. [16] This is an appli- cation of the charge transfer method described in [2]. The circuit integrates the power consumption to energy consumption without any numerical errors, as the pulse count is an integer. This is good for very low currents. The drawback is that the update interval is not fixed and it is not possible to sample power consumption at a higher rate than the DC-DC converter frequency.
Usupply
- +
Rshunt Ushunt
I Device I-scope
I-scope I-jetI-jet
Debug
Debug and measurements
USB
I+ I-/V1
Figure 1: Schematic for current measurement with the I-scope.
2.5 How to measure power consumption with the I-scope probe
The I-scope probe can measure four simultaneous voltages: V1, V2, V3 and I+.
The voltage I+ is measured relative to V1, the others are measured relative to ground. This configuration allows the I-scope probe to measure both the current consumption and the supply voltage for the device at the same time.
Figure 1 shows how the I-scope is typically connected to a device when measur- ing current and voltage. The probe needs an external shunt resistor to measure current. The current is computed from the voltage I+ and the shunt resistance using Ohm’s law. The I-scope can measure voltage drops in the range 0-110 mV over the shunt resistance. Figure 2 shows a photo of the I-scope connected to a CC2650 SensorTag.
The quality of the measurement will depend on the value of the shunt resistance.
The resistance should be large enough to give an acceptable resolution for the measurements, but at the same time small enough to keep the shunt voltage in the measurable range.
The measurements of current and voltage are not done exactly at the same time, they are interleaved. As I need simultaneous current and voltage to compute power consumption, I assigned the previous measured voltage to every current measurement. This is zero order hold interpolation.
Figure 2: A current measurement setup with an I-jet and I-scope connected to a CC2650 SensorTag. Test clips hold the shunt resistor and connect the power cables to the device. A voltmeter is connected in parallel with the power supply to show the voltage.
3 Method
This chapter describes the algorithms I used in my work and how I performed my measurements.
3.1 Comparing power consumption
IAR Embedded Workbench already has the time line interface that allows for visual analysis of the power consumption. This is good for analysis of a single run of measurement data.
A developer might sometimes want to compare measurements with each other.
Either to prove consistency by comparing two measurements from the same system, or to see what effect system changes have on the power consumption by comparing measurements from different revisions of software/hardware.
A time-based approach might not be the best when comparing two measure- ments. The program flow of an embedded system often depends on external stimuli, and a small change in the stimuli can cause the program to behave very different. Two measurements might be impossible to compare due to synchro- nization problems.
A time based approach does not summarize the consumption, as the information about consumption is spread out in time. Summaries are good both when comparing measurements and when communicating results through reports or presentations. It is desirable to have a measurement method that summarizes the results.
3.2 Measuring several power consumers from a single measurement point
Traditionally, several measurement points are needed to measure several power consumers. This is straightforward and needs no extra computations, but the method does not scale well. There must be hardware added for every part of the system that needs to be measured.
Probe
Analysis Verification
Output Device under test Current
measurement
Trace capture Model parameter computation
+ Σ Consumption
model
Model parameters
−
Measurement residual
Figure 3: The data flow when computing the model parameters and the mea- surement residual.
The method in this work combines measurement data with debug information from the system to determine the individual contribution to the power consump- tion from every part in the system. This makes it sufficient to only measure the current in a single point.
The approach is to create a model for the power consumption and then compute the consumption parameters that fit the model to the measured data.
The trade-off when reducing the number of measurement points is that the result does not come out directly. The data must be analyzed, and the parameters computed. But this process can be automated.
3.3 Measurement residual
When doing a power analysis on an embedded system, some information is already known to the developer. Turning a LED on will increase the power consumption, that information is not new. This knowledge can be made explicit by creating a model. The model is driven by the state changes in the system.
The model parameters need to be calibrated with measurement data.
By removing the part of the measurement that the model predicted, only the part that contains new information remains. This is known as the measurement residual or innovation, and is often used in statistics and control theory. The residual is defined as the measurement minus the prediction. The data flow of the computation process is shown in figure 3. The residual can be both positive and negative, depending on what kind of information the predictor model missed. With perfect model and prediction, the residual is zero. This means that the measurements do not contain any information about the system that is not already covered by the model.
Note that the measured power consumption can be a vector if several currents or voltages are measured. With enough (and wisely chosen) measurements, it might be possible to determine what state the system is in. This is an analogy to the observability concept from control theory on dynamic systems. [17]
3.4 A current model with automatic calibration
A method for automatically calibrating model parameters using least squares regression was first presented in [18], but is expanded and better described in [19]. The model presented there describes the total power consumption of integrated circuits as the sum of the consumption from every part. Each part has an estimated power consumption that depends linearly on the system frequency.
I have adapted this model to describe current instead of power and applied it to embedded systems. From my preliminary current measurements I found out that I had to take the voltage in account. Current is directly proportional to voltage (Ohms law) and power is proportional to voltage squared (Joules law).
The model makes a few assumptions. In this model, every part i of the system is either on or off at any given time. This is modeled using indicator variables si, when the part i is on then si= 1, otherwise it is zero. The model also assumes that the estimated current ˆIi that part i contributes to the total estimated current consumption has a constant part aiand a voltage dependent part with coefficient bi. It also assumes that the total current is the sum of all the parts, without any non-linearities.
The model estimate of the total current consumption ˆI(t) at time t for a system with N parts is
I(t) =ˆ
N
X
i=0
si(t) ˆIi(t) =
N
X
i=0
si(t) (ai+ U(t)bi) (3.1)
where the special state 0 models the constant current consumption, combining leak currents, non-modeled parts and the consumption that all system parts have when they are off. The indicator variable s0 is always set to one.
Equation (3.1) can be rewritten with a scalar product (s0 is eliminated) as I(t) = 1 sˆ 1(t) . . . sN(t) U(t) s1(t)U(t) . . . sN(t)U(t)~a
~b
and the full system of equations for all measurements can be written on matrix form. The current measurements become a vector ˆI and the state information with voltage measurements becomes a matrix S. The resulting equation system is ˆI= S~a
~b
which has the model parameters as its solution.
The measured current I will have some level of measurement noise and model error ǫ. This can be written as I = ˆI+ ǫ. The model parameters ~a and ~b can be computed using linear least mean squares so that ǫ is minimized.
For an overdetermined linear equation system Ax = y, the least squares solution is given by ATAx= ATy, or x = ATA−1
ATy.
A more verbose example of how to construct S and how to compute the model parameters is presented in appendix C.
3.5 Computing a system impulse response
The dynamics of a system can be computed from measurement data with a Wiener filter. The Wiener filter is a filter that minimizes the mean square sum of the difference between two signals.
System dynamics in a power measurement comes from capacitance and induc- tance on the power delivery route - the circuitry between the power sink and the point where the consumption is measured.
The problem of finding the system dynamics can be formulated as finding a filter f that minimizes the difference between the filtered estimated current f∗ ˆIand measured current I. There are several ways to define “difference”, but the L2-norm is used to compute the Wiener filter.
The residual V (f) to be minimized is
V(f) = ||I − f ∗ ˆI||2
where ∗ denotes convolution. The residual depends only on f, as I and ˆI are given. In discrete time, both I and ˆIare vectors with values Inand ˆInat sample n. Let fj be the j:th tap in a causal FIR filter, then V (f) can be written as
V(f) =X
n
In−X
j
fjIˆn−j
2
=X
n
In2− 2In
X
j
fjIˆn−j+
X
j
fjIˆn−j
2
. The minimum of V (f) is found by taking the derivative for each FIR-tap fk
dV(f) dfk
=X
n
−2InIˆn−k+ 2 ˆIn−k
X
j
fjIˆn−j
and solving the equation for when the derivative is equal to zero. With the notation Rab[i] = Pnanbn−ifor correlation, the equation from the filter tap fk
derivative is
X
j
fjRI ˆˆI[j − k] = RI ˆI[k] .
The equations from all filter tap derivatives are together called the Wiener-Hopf equations (in discrete time). They can be written on matrix form as
RI ˆˆI[0] RI ˆˆI[−1] . . . RI ˆˆI[1] RI ˆˆI[0] . . . . . . . . . . . .
f0
f1
. . .
=
RI ˆI[0]
RI ˆI[1]
. . .
(3.2)
thus the FIR Wiener filter f is the solution to a linear equation system defined by the correlation between the measured current I and the estimate ˆI. [20]
The number of taps in f can be chosen arbitrarily. The solution will be different depending on the number of taps used.
3.6 Hardware platforms
I had to choose hardware platforms for my case study. The various platforms and chipsets all have different characteristics and give different possibilities, so the choice was non-trivial.
My requirements were to have a readily available development platform with an Arm Cortex-M microcontroller. The board should have a power efficient design, as a metric for this I looked at battery driven boards. It would also be good if the board existed in several different variants, so that the same software could be compared on several boards.
3.6.1 SimpleLink SensorTag
The SimpleLink SensorTag from Texas Instruments is a small battery driven sensor platform, pictured in figure 4. It is based on the Arm chip CC2650 which has a built in radio module. It has been used in several student projects at Uppsala university.[21, 22, 23] The SensorTag has sensors for humidity, pressure, light, motion and temperature. For user interaction it also has buttons, LEDs and a speaker.
Figure 4: The SensorTag, with and without its protective case.
Figure 5: The CC2650 LaunchPad development board.
3.6.2 CC2650 LaunchPad
The CC2650 LaunchPad is a development kit from Texas Instruments. It is also based on the CC2650 chip. This board is shown in figure 5. It has no sensors on its own, but breaks out most of the pins to headers. The board has a built in antenna and debugger, but it is also possible to use an external debugger. It also has two LEDs and buttons.
The built in XDS110 debugger does not support EnergyTrace, at least not in board revision 1.2. The debugger in the CC2650 LaunchPad uses a linear regulator instead of a DC-DC converter. Other versions of the XDS110 debugger support EnergyTrace.
3.7 Application software for CC2650
I wrote a small test program for my measurements. The only thing it did was to blink two LEDs so that there were four distinctive states of power consumption.
The blinking was shifted in phase so that two diodes never changed state at the same time.
Figure 6: The timeline in IAR Embedded Workbench, showing an instrumented power log. The current consumption and ITM messages are shown over time.
0 1 2 3 4 5 6 7
EventID State
Figure 7: The event message structure. An event consists of the event ID and the new state it enters.
3.8 Adding instrumentation to the application
I added instrumentation code to the CC2650 program and recorded instru- mented power logs with IAR Embedded Workbench. The SWO instrumentation allowed the microcontroller to send integers to the debugger. Figure 6 shows a screenshot of the timeline in IAR Embedded Workbench.
I designed a structure to send event messages as integers over the SWO channel.
The structure is shown in figure 7. To have a low latency, the ITM-packages should be as small as possible, so I used a width of 8 bits. The state information uses one bit, so there are 7 bits left to indicate the part number. This allows 128 parts in the system to be instrumented, with numbers from 0 to 127.
A snippet from the instrumented program is shown in listing 2. The code that controls the LEDs has been broken out into separate driver functions.
The application must control the LEDs using the instrumented drivers. The instrumentation will fail if the LEDs are controlled directly at GPIO-level.
Listing 2: The instrumentation from a source code perspective. The program sends an event message when it takes an action that affects power consumption.
The EVENT macro is a wrapper to sendMessage in listing 1.
1 #d e f i n e EVENT( e , s ) sendMessage (ITM_CHANNEL, ( ( e)<<1) | ( ( s )&1)) 2 v o i d greenLEDon ( v o i d ) {
3 EVENT(GREEN_LED, 1 ) ; 4 GPIO_setDio (GREEN_PIN ) ; 5 }
6 v o i d redLEDoff ( v o i d ) { 7 EVENT(RED_LED, 0 ) ; 8 GPIO_clearDio (RED_PIN ) ;
3.9 Acquiring and exporting measurement data
I collected measurement data from the two platforms with IAR Embedded Workbench. I saved the logs for post-processing. The logs contain time-stamped SWO data and the voltages that the probe has measured. There are also PC- samples. They tell what part of the program that runs at that very moment.
I did two kinds of measurements with the I-scope. I measured both voltage and current with varying supply voltage. I also measured only current with a fix supply voltage. For the measurements that were current only, I measured the supply voltage with a multimeter and added it manually. The supply voltage to the device is affected by the shunt resistor voltage, as a higher current will lower the voltage that reaches the device. But, as the shunt voltage is measured by the probe, it is possible to compute the supply voltage to the chip in the current only measurements.
I performed my measurements around 3 V. I did not go below 2.8 V for the automated measurements, because I ran into problems with the internal DC- DC converter in the CC2650. I kept the supply voltage to the SensorTag under 3 V because I was not sure if all the sensors on the board could handle higher voltages. I tested the LaunchPad up to 3.6 V as there are only two ICs on that board and they can both handle 3.6 V according to their data sheets.
The SWO-log format is tab-separated text, a small snippet is shown in listing 1.
The measurements are reported in microvolts, channel 0x280 is the shunt voltage and 0x290 is the supply voltage. The probe resends the previous voltage and current when a PC-sample is sent. This repeated data was removed in the actual analysis.
The SWO trace buffer in IAR Embedded Workbench is normally limited to 1 million items. This means less than five seconds at a sampling rate of 200 kHz.
With help from the staff at IAR, I could increase this limit to allow longer measurements.
A2D: 0x290 15482670 0x2bc0e0 2867424 A2D: 0x280 15482910 0x11e6 4582 A2D: 0x290 15483150 0x2bc0e0 2867424 A2D: 0x280 15483390 0x12db 4827
ITM 15483526 0x1
A2D: 0x290 15483594 0x2bc0e0 2867424 A2D: 0x280 15483594 0x12db 4827
PCSample 15483594 0xc34 CMP R0, R1
A2D: 0x290 15483630 0x2bc0e0 2867424 A2D: 0x280 15483870 0x143c 5180 A2D: 0x290 15484110 0x2bb542 2864450 A2D: 0x280 15484350 0x1b06 6918
Listing 1: A small snippet from an IAR Embedded Workbench SWO-trace log.
The log contains message type, timestamp and data. The timestamp is the processor cycle counter, running at 75 MHz.
3.10 Data processing
I computed the model parameters with linear least square regression. I con- structed an overdetermined linear system with a state matrix and a vector with current measurements.
The model parameters summarize the consumption of the system. From the model parameters and the instrumentation data, I computed the raw estimate of the current consumption. The raw estimate is the product of the state matrix and the model parameters.
To compute the dynamics of the system, I computed the FIR Wiener filter that minimizes the residual between the raw estimate and measured current as described in 3.5. This filter is the impulse response of the power delivery route circuitry between the measurement point and the power sink.
I increased the number of filter taps until the response got accurate enough.
The sum of the filter taps, the constant gain, should be very close to 1 if the filter is reasonable. I truncated the filter when the last tap in the filter was less than 0.01. This means that the truncation error in the step response is 1%. The figures 17 and 18 in section 4.4.2 illustrate what this looks like.
The data processing and visualization was done with Python 2.7 and the mod- ules numpy, scipy and matplotlib.
4 Results and analysis
This chapter presents the results from my measurements.
4.1 Prestudy with manual analysis
I first did some manual analysis on the SensorTag and LaunchPad by varying the supply voltage and measuring the current consumption. The results are shown in the figures 8 and 9.
The current consumptions of the LEDs are independent and additive; the cur- rent increase from one LED is the same regardless of if the other LED is on or off.
The dashed line in figures 8 and 9 is the sum of the two single LED consumption increases relative to the base consumption: Base + (Red-Base) + (Green-Base).
It corresponds very well to the measurement with both LEDs on.
The base consumption is the same in both the SensorTag and the Launchpad.
This is the “Active Mode (MCU Running, No Peripherals) Current Consumption vs Supply Voltage (VDDS)” graph in the data sheet for this processor. [24]
The largest difference between the boards in the manual measurement was the red LED. The red LED in the SensorTag consumed much less current than the red LED in the LaunchPad.
The change in supply voltage has different effect on different system parts. The diodes consume more current for higher voltages, and the MCU consumes less current for higher voltages.
The current consumption has several discontinuities occurring at the same sup- ply voltages for both the SensorTag and LaunchPad. The discontinuities are only present in the LED-dependent part of the current consumption. The base consumption is not affected. The discontinuities are located on approximately {5, 6, 7}·390 mV. I am not sure what causes this phenomenon, but it might be related to the DC-DC converter, as a lower voltage gives a lower efficiency.
The current consumption is a linear function of voltage as long as the supply voltage does not vary too much and does not cross any of the discontinuities.
The automated measurements were performed at voltages above 2.8 V.
1800 2000 2200 2400 2600 2800 3000 Supply voltage [mV]
5 6 7 8
Current [mA]
Varying voltage for SensorTag
Both LEDs on Red on Green on No LED on Linear estimate
Figure 8: The average current consumption of the SensorTag for different supply voltages and states. The higher currents have a slightly lower supply voltage due to the voltage drop over the shunt resistor. The higher current data points are shifted slightly to the left.
1750 2000 2250 2500 2750 3000 3250 3500 Supply voltage [mV]
4 5 6 7 8 9 10 11
Current [mA]
Varying voltage for CC2650 LaunchPad
Both LEDs on Red on Green on No LED on Linear estimate
Figure 9: The average current consumption of the LaunchPad for different supply voltages and states. The discontinuities are located at the same voltages
Table 2: The current consumption for the different parts of the system when running at 3 V, computed with automated analysis.
LaunchPad Base Red Green
Active current consumption [mA] 4.150 2.318 2.158
Duty cycle 100.0% 50.00% 50.03%
Average current consumption [mA] 4.150 1.159 1.079
SensorTag Base Red Green
Active current consumption [mA] 4.436 1.272 2.481
Duty cycle 100.0% 50.02% 50.46%
Average current consumption [mA] 4.436 0.6363 1.252
4.2 Automated analysis
I used the I-scope probe to perform automatic current measurements. From the measurements, I computed the parameters for the different states. As the current consumption is voltage dependent, I chose to evaluate it at 3 volts.
The consumption for the different states are listed in table 2. The average current consumption is the product of the active current consumption and the duty cycle. As expected, the duty cycles of the diodes are approximately 50%.
The duty cycles of the green LEDs deviate a bit more from this than the ones of the red LEDs, but that is also expected, as their cycle time was longer. The SensorTag has a slightly higher base power consumption, probably because that board has more components on it that consumes power through leakage.
4.3 Parameter visualization
Although a table with parameters is an exact representation of the parameter data, it is helpful to visualize it to get an overview of how the power consumption is distributed in the system.
There are several ways to visualize the data, and different visualizations suits different needs. I present two ways here.
4.3.1 Pie chart
A pie chart is an easy way to present the power distribution. It gives an overview of where the power goes, but does not tell if a system part has a high consump- tion because it has a high active consumption or a high duty cycle.
Red LED 18.2%
Base 64.9%
Green LED 16.9%
LaunchPad
Red LED 10.1%
Base 70.1%
Green LED 19.8%
SensorTag
Figure 10: The average current consumers in the LaunchPad and SensorTag.
The base consumption is the largest consumer on both systems. The red LED in the SensorTag consumes less power than the LED in the Launchpad.
10% 20% 30% 50% 100%
Duty cycle 1
10
2 3 45 67 89
Active current consumption [mA]
LaunchPad
BaseRed LED Green LED
10% 20% 30% 50% 100%
Duty cycle 1
10
2 3 45 67 89
Active current consumption [mA]
SensorTag
BaseRed LED Green LED
Figure 11: The current consumers in the LaunchPad and SensorTag. The dashed lines indicate points with equal average current consumption. The red LED consumes less power in the SensorTag because it is more efficient. If it had consumed less because of a lower duty cycle, it had been moved to the left in the diagram.
4.3.2 Log-log diagram
A more advanced way to visualize the summarized consumption is to use a log- log diagram. Although more refined, it might need some more explanation than the pie-chart.
As the average current consumption is the product of the duty cycle and the active current consumption, the logarithm of the average current consumption is the sum of the logarithms of the duty cycle and the active current.
A log-log diagram is formed by plotting the logarithm of the active current consumption against the logarithm of the duty cycle. Data points with the same average current consumption will form diagonal lines in the log-log diagram.
4.3.3 Comparison
The data from table 2 is visualized in figures 10 and 11. The largest current con- sumer for both systems is the base consumption, both regarding active current consumption and duty cycle.
Both the pie-chart and the log-log diagram say that the red LED consumes less power than the green LED. But it is only from the log-log diagram that we can see that the reason to this is that the red LED has a lower active current consumption.
A pie-chart does not need much explanation but does not show as much infor- mation as the log-log diagram. It is not clear what actions to take to reduce the consumption by only looking at the pie-chart. Note that the information in the pie-chart is one-dimensional whereas the log-log diagram is two-dimensional.
From a power reduction perspective, it would be best to try to reduce the largest consumer, the base consumption. The base consumption catches everything that is not modeled, the largest non-modeled consumer is the MCU itself. It would be wise to try to add the MCU to the model and then reduce the duty cycle of the MCU by making it go to sleep, or change it to one that consumes less power.
4.4 Time-based visualization
I previously mentioned that time-based visualizations can be hard to compare due to synchronization problems, but there is an exception to this.
An instrumented measurement can be compared with a modeled consumption if the model is driven from the instrumentation data, as this guarantees syn- chronization. This makes it possible to validate a set of model parameters to see how well they fit and where they deviate.
Figure 12: The measured and raw model current for the SensorTag. There are spikes in the residual on every state transition.
Figure 13: A zoomed in view on one of the residual peaks in the LaunchPad.
4.4.1 The raw model
To verify that the model is reasonable, the model errors should be small. The measurement residual is used to verify how big the model errors are. Figure 12 shows the measured and modeled currents and their difference, the residual.
Figure 14: The measured current and filtered model current for the SensorTag.
The spikes that were present in figure 12 are now suppressed.
match in the state transitions. Figure 13 shows a more zoomed in view of a transition. The actual measurement takes some time to react to a system change, but the model changes immediately.
4.4.2 Model extended with system dynamics
To account for the rise/fall times in the measurement, I computed Wiener filters to filter the modeled current. The filtered results are shown in figures 14, 15 and 16. The filtering has removed the spikes that were previously present at the state transitions. As a side result, the computed Wiener filters are the impulse responses of the power delivery route. The impulse and step responses are shown in figures 17, 18 and 19.
The impulse response for the SensorTag is twice as long as for the LaunchPad.
This is probably because the LaunchPad has 1510 nF of decoupling capacitance and the SensorTag has 3122 nF. If we see the power delivery circuitry as an RC low-pass filter, the rise/fall-time will double if we double the capacitance. It would probably be possible to compute the bandwidth of the measurements by Fourier analysis of the impulse response.
The measurement with combined current/voltage in figure 16 is much noisier than the current-only measurements. The impulse response from the combined current/voltage measurement, shown in figure 19, was also not as smooth as the ones where only current was measured. The channel switching in the I-scope introduces noise. It is however much easier to perform the measurement this way, as there is no need to measure the supply voltage separately.
Figure 15: The measured current and filtered model current for the LaunchPad.
Figure 16: The filtered current for the LaunchPad with varying supply voltage.
The modeled current follows the measured current when the voltage varies. The measured current is more noisy, as the I-scope measures both current and voltage in this setup and has to switch between the two channels.
0 2000 4000 6000 8000 Samples [1]
0.00 0.02 0.04 0.06 0.08
Impulse
Step response Impulse response
0.0 0.2 0.4 0.6 0.8 1.0
Step
Step and impulse responses for the LaunchPad
Figure 17: The impulse and step responses for the LaunchPad. The last tap in the impulse response holds the truncation for the filter. Its value is 0.01, so the last jump in the step response is 1% of the total step.
0 5000 10000 15000 20000
Samples [1]
0.00 0.01 0.02 0.03 0.04
Impulse
Step response Impulse response
0.0 0.2 0.4 0.6 0.8 1.0
Step
Step and impulse responses for the SensorTag
Figure 18: The impulse and step responses for the SensorTag. The last tap has the same height as in the LaunchPad, but its height relative to the rest of the filter is larger as this impulse response is distributed over more taps with lower intensities.
0 1000 2000 3000 4000 5000 Samples [1]
0.0 0.2 0.4 0.6
Impulse
Step response Impulse response
0.0 0.2 0.4 0.6 0.8 1.0
Step
Step and impulse responses for the LaunchPad with varying voltage
Figure 19: The impulse and step responses for the LaunchPad when both current and voltage are measured with the I-scope.
4.5 Residual analysis
With a filtered model, the residual stays around zero. Any non-modeled phe- nomenon would be seen as a peak in the residual. This makes it possible to locate new sources of power consumption in the system, and add them to the model.
I connected a third LED to the LaunchPad, and told it to blink. But, I did not add any instrumentation to this diode. The results are shown in figure 20.
When the non-instrumented LED blinks there is a spike in the residual, so it is possible to see that the model does not cover all of the system behaviour.
4.5.1 Current consumption depends on counter value
There is some information left in the signal after matching it to the model. The residual should be spectrally white if the prediction model is perfect.
I integrated the residual over time to see if there was a static error. The inte- grated residual is shown in figure 21.
There was no big static error, as the integral stayed around zero over time. For a specific run, it it drifted at most 10 µJ from the estimate. The total energy consumption for the system over 2.2 seconds was 49.5 mJ for the same run. The drift was about 0.02% of the total consumption.
There was a periodic variation in the integrated residual. The period of this
Figure 20: The measured current and filtered model current for the LaunchPad with an extra non-instrumented LED connected. There is a peak in the residual when this new LED is turned on.
I suspected that the regular variation was due to the value of the counter variable in the program. I computed the Hamming-weight, the number of set bits, in an up-counting 16-bit counter. The expected Hamming-weight is the mean value 8, so the residual is the Hamming weight minus 8. I computed the cumulative sum, this plot is shown in figure 22. The pattern is very similar to figure 21.
To verify this hypothesis, I did a measurement with a decrementing counter.
The resulting shape, shown in figure 23, is flipped compared to figure 21.
The difference in current consumption between a 1-bit and 0-bit was in the order of 10 µA. The consumption is more likely due to memory read/write operations than leakage, as the consumption of the CC2650 itself is only 1 µA in standby mode.[24] The difference between the model and measurement is visible in figure 13 as the counter changes from many to few bits set at the transition.
4.5.2 Periodic peaks
There are still some small periodic spikes in the residual. They can be seen in figures 14 and 15. I’m not sure what causes these peaks, but it is out of scope for this work to investigate that further. The peaks might come from the Cortex-M0 coprocessor in the CC2650 or the DC-DC converter.
The integral of the small peaks can be seen in figure 24. The consumption of these peaks are included in the static consumption, as the curve does not drift
Figure 21: The cumulative sum of the residual. There is no constant error in the residual, as the integrated signal stays around zero. There is a periodic pattern, so there is still information in the residual that the model has not taken in account.
Figure 22: A computer-generated plot of the cumulative sum of the Hamming weight minus its mean for a counter over two periods. Note the resemblance with figure 21.
Figure 23: The cumulative sum of the residual with a downwards counter. The important part is the shape of the curve, which is flipped compared to figure 21.
Figure 24: A close-up of figure 21, showing the cumulative sum of the residual.
The steps are caused by the small periodic peaks that can be seen in figures 14 and 15. Every peak consumes about 50-100 nJ.
4.6 Failures and dead ends
This work has not been without failures. Some of my work has not lead to fruitful results. I list some of my mistakes here and hope that they are not repeated by others.
4.6.1 State modeling
Before I found the work in [19], I simply used the mean value for each state.
This was not good enough, as it did not take the varying voltage into account.
4.6.2 Dynamics modeling
I tried a few different filtering methods before I decided on the Wiener filter to model the system dynamics. My first approach was a single pole low pass IIR-filter, on the form
y(n) = k · y(n − 1) + (k − 1) · x(n)
where 0 < k < 1. This filter worked to some degree, but required manual tuning of the constant k.
My second approach was to normalize all step responses to go from 0 to 1 and then compute their mean value. This approach was more complicated to do, but did not require manual tuning. However, it did not have the same solid theoretical foundation as the Wiener filter and the results were noisy. The Wiener filter also reliably gives the impulse response of the system. The noisy mean step response can not be differentiated with good result.
4.6.3 Other hardware platforms
I had planned to compare more platforms in this work. I had four development boards with different Gecko processors from Silicon Labs. However, I could not get reliable measurements from these boards as the SWO-channel was not synchronized with the current measurement data in IAR Embedded Workbench.
I also tried to use Silicon Labs own IDE, Simplicity Studio, to perform mea- surements, but I could not get timestamped ITM messages.
5 Discussion
The measurement method is slightly intrusive to the software, as the program must have instrumentation code added. But getting the same measurement using only hardware is even more intrusive, so this is a reasonable trade-off.
Every part of the system that consumes power must be instrumented to be included in the model. However, this is typically only done once at the driver level. The instrumentation should be resilient to changes in the application logic.
As of now, the model can not learn these new consumers automatically, as it needs to have instrumentation in place. However, if the method can be inte- grated with a debugger it would be possible to make the instrumentation process easier. IAR Embedded Workbench already has a feature to halt the program execution when the power consumption exceeds certain limits. It would be pos- sible to halt the system when the power consumption deviates too much from the expected consumption and from there backtrack to the code that caused the increase.
Adding instrumentation might increase power consumption, as more parts of the MCU are used. But the instrumentation is only used during development.
It should be used to look at how a change affects the system. The effect of a system change will probably be the same both with and without enabled instrumentation.
The model generalizes to other forms of embedded systems. The state modeling and power prediction are not restricted to the Arm architecture, or even to microcontrollers. It would be possible to add similar instrumentation to an FPGA-based embedded system.
The model is scalable, adding more states only requires a larger state matrix.
The measurement method itself has been my focus in this study, but the method can be applied to a more complex system than I have studied. This requires that the application software has a well-defined hardware abstraction layer.
Much like it is easier to add automated tests to software that is broken up into logical functions, it would be easier to add instrumentation to software that does not touch hardware registers from the application logic. The instrumentation would be added step by step for every system part until the model captures the consumption behaviour well enough. The non-modeled consumption would be a part of the base consumption until it has been instrumented.
It can be hard to prove that a system has optimal power consumption, as there are many ways to reduce the power consumption of a system. Optimality most often requires some kind of limits, and limiting factors come as requirements.
Formal requirements make it easy to accept or dismiss suggested improvements in a system. With requirements such as “The radio transmission power must be at least 10 dBm”, “The display rate must be at least 5 Hz” or perhaps most common “The project must be finished within six months” the number of choices are limited and everything within these limits can be tried. Data from measure- ments form a base to make well informed decisions that allow efficient allocation of development efforts. Good tools are essential when time is a limiting factor.
6 Conclusions
The method can measure and present the individual power consumptions and duty-cycles of instrumented parts in an embedded system. As a side result, the method also computes the impulse response of the power delivery route. The model can verify itself by computing the measurement residual and showing where there are model errors, and how big they are.
The method has not been limited by the resolution of the measurement equip- ment, the I-jet/I-scope. It was possible to observe power consumption variations depending on the values of variables in the program. It would not be practi- cal to extend the model to capture these variations. There is a trade-off when measuring both current and voltage, the measurement setup is easier but the results contain more noise.
The method requires the code to be instrumented. As of now, this must be done manually but only needs to be done once for every system part. The method relies on that the I-jet/I-scope can synchronize debug data with power measurements.
