Energy-Aware Software Development for Embedded

Systems in HW/SW Co-Design

Paul Ehrlich, Stephan Radke
Fraunhofer IIS, Design Automation Division EAS
Dresden, Germany
{paul.ehrlich, stephan.radke}@eas.iis.fraunhofer.de
tions such as mobile under water sensor networks or forest fire
detection systems are supposed to autonomously operate for
years. Hence, the specified power requirements are very challenging, and every little bit of energy has to be used advisedly.
During the implementation phase of ESD, such systems have to
pass the time-consuming partitioning cycle repeatedly.

AbstractPower constrains are becoming increasingly important

for embedded systems, especially when considering mobile applications. These systems are characterized by the presence of a
dedicated processor running application-specific software. Current approaches only focus on power optimization in one design
domain, such as the hardware or the software one. However, to
meet the tight power constrains, both have to be investigated in
relation. This paper proposes a novel approach to support the
software developing process which takes this relation into account. Based on hardware/software co-simulation, the power
consumption of the hardware is annotated to the corresponding
source code. Hence, the consumption of the system is directly
visible during software refinements of the microcontroller. After
each refinement cycle, an overall power optimization can be
accomplished. The approach is applied to an example system
which comprises the embedded software of a MSP430 microcontroller and its controlled external peripherals. Using the example,
the potential of the approach is discussed. Moreover, the power
annotation process is defined and the data exchange formats are
specified. Therefore, the approach is also applicable to any other
controller type.

This paper proposes a novel method to support the power

evaluation process. From software development perspective,
we enable the visualization of the systems overall power consumption and hence we close the missing link between the
hardware and the software domain. Technically, Extensible
Markup Language (XML) formats are defined to standardize
the data exchange between power consumption of the hardware. Without loss of generality, we focus on SystemC [2] to
describe the behavior of the hardware in the system simulation.
The main advantage is that the overall simulation time for
SystemC models is in orders of magnitudes faster compared to
Register Transfer Level (RTL). Also, the hardware exists virtually, which allows a simple component exchange.
The rest of the paper is organized as follows: The second
section describes the current state of the art in the field of power aware design. The third section describes the workflow of
the presented approach. Then in section four, the potential of
the power optimization is illustrated. Finally, section five concludes the paper.

KeywordsPower-Analysis; Embedded Systems Design;

Hardware/Software Co-Design; Power System Simulation

I.

INTRODUCTION

Embedded systems can be defined as information processing systems embedded into enclosing products such as
cars, telecommunication or fabrication equipment. [1]. Because of its multifaceted applications and complex designs,
they are only developable based on standardized design flows.
In the academic field, Embedded System Design (ESD) [1] has
become a very important research area. It comprises the design
flow itself and scientific achievements in the particular steps.
During the implementation phase of ESD, the right partitioning
of hardware and software components has to be determined.
This so-called hardware/software co-design is an iterative task.
After each partitioning cycle, a system simulation run reveals
whether the specification is met or possible specification violations are determined. Open issues must be reduced and eliminated in each cycle, in order to meet all requirements of the
system specification.

II.

One domain addresses the overall power analysis of the

system, or more precisely the hardware. There are numerous
approaches to analyze and reduce the power consumption in
each design level of the Gajski-Diagram [3]. As introduction,
we focus on SystemC as a description language of hardware. It
may cover multiple design levels, such as system, algorithmic,
or register-transfer level. The approaches presented in [4][5][6]
address power analyses of hardware described in SystemC. The
work in [7] regards especially the RTL. In general, the approaches abstract the power consumption to power-states. Each
module virtually switches the power consumption according to
the predefined power-states. A post simulation analysis reveals
the overall power consumption of the hardware which can be
analyzed manually for optimization. In our approach we reuse

Besides the validation of functional correctness, nonfunctional requirements are equally important in ESD. Especially power consumption constraints are essential in mobile
embedded systems. Battery driven ultra-low power applica-

c
978-1-4673-6136-1/13/$31.00 2013
IEEE

RELATED WORK

Regarding power analysis and optimization, todays approaches and innovations concentrate on two distinct domains
in ESD.

232

generalized interfaces between the flow steps using XML

Schema according to the World Wide Web Consortium (W3C)
standard [11]. For illustration purposes, examples provide
guidance to the general flow.

the Power Framework [6] which provides a power library to

enable power-state tracing features in SystemC. Especially, we
reuse the timestamps of the power-state switches and their
power consumption. Without loss of generality, the state
switches may be generated by any simulation approach besides
SystemC.

Simulation

The second domain addresses the power optimization potential in the embedded software of the microcontroller. In the
approaches [8][9][10], the executed code is analyzed to minimize the power of the microcontroller. In our work, we reuse
the power profiler developed in [9] which provides an analyzing mechanism to estimate the power consumption according
to each source code line. In these approaches the external peripherals are not regarded.

Code Compilation

Processing

2) Simulation
The actual simulation is investigated under different aspects. The software and the hardware domain influence each
other and are highly related. They are discussed separately to
distinct the informations origin.

A. Example Platform
The methodology is discussed using the example platform
illustrated in Fig. 1. The example basically consists of a MixedSignal Microcontroller (MSP430F1611) running the embedded
software along with the following external peripherals described in SystemC: a Light-Emitting Diode (LED), a button
and a Sensor for Humidity and Temperature (SHT). The LED
and the button are connected directly to the processors pins,
while the SHT sensor is connected via Inter-Integrated Circuit
(IC), which is a serial bus interface provided by the processors
internal peripherals.
Button

Annotation

1) Code Compilation
The embedded software in form of C-code represents the
input which is compiled during the first step. The program is
assembled and debugging information is created by the compiler. These are used to aid the annotation process. The assembled instructions (ASM) of the program and the debug information are stored together in an elf file [12], which represents
the input for the subsequent simulation step. The compiler used
here exemplarily is msp430-gcc version 4.4.5. It provides the
needed debugging information in the stabs+ format specified
in the GNU debugger documentation [13].

PROPOSED METHODOLOGY

MSP430

annotation.xml

Fig. 2. General overview of the workflow

The power characteristics available from hardware simulation are used to aid the software development. First, an example platform is specified for illustration, followed by the procedure of the proposed co-design. We denote internal and external peripherals to distinguish between hardware components
within the microcontroller e.g. timers and externally connected
components e.g. sensors.

LED

Peripheral
models

file_eprof.c & system.xml

To the best of the authors knowledge, this paper proposes

the first approach combining these two domains in order to
estimate the power consumption of the overall embedded system during the software design process.
III.

file.elf

Controller
model

The software is executed in an Instruction Set Simulator

(ISS) representing the model of the controller. The ISS thereby
provides the controller internal peripherals, such as the core,
registers, internal memories, pins, timers and the interrupt
handler. The ISS provides the controllers functionality as well
as its timing. The simulation itself is a step by step execution of
the assembled code. The profiler connected to the ISS analyses
the run time behavior. Precisely, the execution flow of the
ASM is recorded, and the number and kind of memory accesses is stored. The example implementation uses the concept of
the eprof profiler [9].

SHT

The external hardware influences the execution of the

source code e.g. by requesting interrupts. This behavior, modeled in SystemC, is considered in the ISS. Both together provide the interaction between the controller and the external
peripherals. According to the power framework [6] certain
power-states of hardware components are abstracted. To connect power state changes to the source code, three different
types of power-state transitions are defined: active, semi-active
and passive types. Active changes are directly caused by the
program running on the controller, like the switching of a LED,
whereas passive types are caused by external events, such as a
pressed button. Semi-actives are a mixture of both. The SHT,
for example, switches into the measurement state after the
controller requests a temperature value via the IC. This transi-

IC Bus
Fig. 1 Example platform including a MSP430, a button, a LED and a SHT
connected via IC bus

The software continuously samples the temperature. By

pressing the button, the example software stores one temperature value as reference. Afterwards, the system alerts in case of
an under- or overflow of it by switching on the LED.
B. Workflow
The approach consists of four major steps which are presented in Fig. 2: The code compilation, simulation, processing
and annotation. They are described in detail below. We define

233

tion is denoted as active, because the communication is triggered directly by the source of the microcontroller. The measurement is finished after a certain time, which is unrelated to
the executed code. This circumstance is denoted as a passive.
The distinction between active and passive is needed to explain
the marker position used for annotation. Markers thereby are
links between power state transitions and the embedded software.

3) Processing
After the simulation, the file_eprof.c and system.xml have
to be processed to extract and combine all relevant information
needed for the visualization in the IDE. During this process, a
combination of the information from the program run with the
debugging output from the compiler is done, and post statistical
information is calculated. The first step is to map the ASM
instructions back to their corresponding C-code lines, which is
done with the stabs+ debugging information. The power values
and memory accesses of each ASM instruction belonging to
this line have to be accumulated. The results are fine grained
profiles about each source code line containing the number of
executions and their power value. Also memory reads and
writes are presented to allow code optimization without the
need of a disassembly. Important to note is that the back annotation strongly depends on the debug information. Concerning
our approach, the stabs+ format of the msp430-gcc provides
the necessary information, even for higher optimization levels.

Independent of our used SystemC hardware description, the

output of the simulation is depicted exemplarily as system.xml
(Fig. 3). Therein, the format first describes the system structure
followed by the behavior over time. The structure is assembled
by a number of different peripherals (peripheral), whose attributes are the name and powerscale. The former is used for identification and the latter is added to allow a high dynamic range
of power values. Each peripheral is denoted by different power
states (state), which include the attributes name, power and
color. The first is used again as an identifier, the second stores
the power value which is abstracted for the given operation
mode. The latter allows a color specification for better discernibility in the IDE visualization. Additionally each state defines
at least one marker used as interface for the annotation process.
The node markerdef contains two attributes, which are type and
value, to describe the marker. This general definition allows
adjustments to different circumstances, e.g. the program counter, a memory value, or a certain bit used in a state machine.

In addition to the power annotation to the source code, statistical information of the hardware is generated from the results of the system simulation. Therefore, the timeline is analyzed to determine the duty cycles of each peripheral powerstates by accumulation the time, in which the state is active.
The power consumption and the accumulated time are used to
calculate the total energy of each state. Together with the
source annotation, they can be used for extensive program
analyses.

In case of passive or semi-active changes, defining a marker is a manual process. Passive types therefore refer to the
program lines where the execution is altered, e.g. an interrupt
starting point in case of a pressed button. For semi-active types
such as the entering of the measurement state, the program line
is considered which initially caused the IC communication. To
mark a peripheral controlled by a state machine, the state variable itself is used as marker.

4) Annotation
In order to provide power information to an IDE, a second
XML is proposed. It stores information about each source code
line and the peripherals of the system (see Annotation.xml in
Fig. 4.)
The part regarding the software of the microcontroller
combines the annotation of several files in different file nodes.
Each of them has a name attribute which includes an absolute
or relative path to the source code file for identification. Each
file node consists of at least one line node which again can
possess one or more marker nodes. Attributes of the line node
are the line number (nr), bytes of it in ASM (membytes), power
consumed (power), the times executed (exe), the number of
memory reads and writes (memread, memwrite). As depicted,
the marker node contains the attributes peripheral and state.
The line number is identified by nr, while the other attributes
store profiler information. The marker attribute peripheral is
needed for identification, while state is an optional attribute
used if the line can be mapped to a certain power state change.
In that case a specified color can be used to highlight the marker of the state transition.

The second part of the XML includes the timeline, where

every change in a power-state is stored as signal. Each signal
includes the attributes peripheral and state to identify the current active state along with the attribute time which denotes the
timestamp of the change. Moreover, the timeline has a timescale attribute to ensure short and well defined timestamps.
<system>
<peripheral name="LED" powerscale="mW">
<state name="on" power="66.0" color="007D31">
<markerdef type="pc" value="0x2131" />
<markerdef type="var" value="alarm_activated" />
</state>
<state name="off" power="0.01" color="FF2A55">
<markerdef type="pc" value="0x2145" />
<markerdef type="var" value="!alarm_activated" />
</state>
</peripheral>
<peripheral name="SHT21" powerscale="uW">

</peripheral>
<timeline timescale="ms">
<!-- init start! -->
<signal time="0" peripheral="LED" state="off"/>

<!-- init end! -->

<signal time="80" peripheral="Button" state="on"/>

</timline>
</system>

Each peripheral node stores information about its power

consumption. The peripheral part is modified regarding the
used parameters of the state node, which contains the processed
post statistical information. Two attributes are added: dutycycle
and time. They have the same scale as the timeline attribute,
which is defined as a parameter of the system node. The dutycycle and time are sufficient to represent the total energy
spent in each state. This can be calculated by a multiplication
of the state power and time.

Fig. 3. Example of the system.xml

234

<annotation>
<file name='test.c' >

<line nr='54' membytes='3' power='3.8pJ' exe='1305'

memread='2' memwrite='0' >
<marker peripheral='SHT' />
</line>

</file>
<file name='include.c'>

</file>
<system timescale="ms">
<peripheral name="LED" powerscale="mW">
<state name="on" power="66.0" dutycycle="0.102"
time="1224"/>
<state name="off" power="0.01" dutycycle="0.898"
time="10776"/>
</peripheral>

</system>
</annotation>

12bit to 11bit, shortening the measurement time of a single

measurement from 17ms to 9ms. This lowers the duty cycle of
the measurement mode from 42.5% to 22.5%. All two examples only need little changes to the source code, but are vital for
lowering the overall power consumption of the peripherals.
V.

In order to meet tight power constrains, a lot of development time has to be spent in ESD. To ease this process, a workflow to annotate power characteristics back into to the source
code of the microcontroller has been developed. The workflow
is based on the embedded software. An example platform has
been presented to illustrate the process. Also, interfaces have
been specified to make the workflow applicable in general.
Precisely as exchange formats, two XML Schemas have been
defined. One describes the output of the system simulation and
the other enables the back annotation into the source. We illustrated the advantages of the novel concept, which eases future
software developments by investigating hardware interaction
during the partition cycle of the ESD. It is based on software/hardware co-simulation and allows power optimizations
as well as manual driven design space explorations. The methodology has been investigated for systems with single microcontroller applications and different types of external peripherals. Since our contribution seems to open a promising path, in
future work we will investigate multi master systems.

Fig. 4. Simple instance of the Annotation.xml

IV.

CONCLUSION AND FUTURE WORK

EXPERIMENTAL RESULTS

Different visualization concepts of the XML format presented above are possible. It can be used to show the consumed
energy or the execution frequency of each source code line.
Tooltips may aid optimization by including memory reads and
writes or internal execution cycles. These visualization concepts offer power optimization in software. They help to identify the variable implementation in terms of memory or register
use. They can be used to optimize functions calls with minimum data transfer or to identify often executed code. The uses
of markers help to identify inefficient use of hardware. They
reflect the interaction with the hardware and fasten the process
of understanding unfamiliar code. These markers are added
hierarchically, which helps to identify the use of the hardware
in nested function calls. Furthermore, a table reviewing the
power states of the peripherals is helpful, showing the duty
cycle between the power states and the consumed energy. All
features together allow direct feedback from the system simulation, providing a way of optimization or manual driven design
explorations.

REFERENCES
[1]
[2]

[3]

[4]

[5]

For optimization purpose, the peripherals have to be reconsidered. Referring to the manual driven design exploration
along with our strict specification, the LED cannot be exchanged, since it has to have a minimum brightness to catch
attention. Also the SHT21 sensor is already very energy saving, making an economical replacement impossible. Only in
the button peripheral, power saving are possible using a higher
pull up resistor. Also, the software may be optimized for example by using better data structures. All of it makes a difference, nevertheless the power saving is small compared to the
one presented below, improving the software and hardware
interaction. Based on the post statistical information about the
peripherals together with the markers, the critical code sections
are easily investigated by the developer. Therefore, the code is
changed and the system is re-simulated again, directly showing
the results of the improvements.

[6]

[7]

[8]

[9]
[10]

[11]

In our example we have investigated two power intensive

code sections. One is to make the LED flash, which at least
saves an additional half of the LEDs duty cycle. Another example is the lowering of the used temperature resolution from

[12]
[13]

235

P. Marwedel, Embedded System Design. Springer, 2006.

Automation, Design and Committee, Standards. IEEE Standard
SystemC Language Reference Manual. IEEE Computer Society, 1666,
2005.
R. Walker and D. Thomas, A model of design representation and
synthesis, Proceedings of the 22nd ACM/IEEE conference on Design
automation (DAC), pp. 453-459, 1985.
H. Lebreton and P. Vivet, Power Modeling in SystemC at Transaction
Level, Application to a DVFS Architecture, IEEE Computer Society
Annual Symposium on VLSI (ISVLSI), pp. 463-466, 2008.
M. Streubhr, R. Rosales, R. Hasholzner, C. Haubelt, and J. Teich, ESL
power and performance estimation for heterogeneous MPSOCS using
SystemC, Forum on Specification and Design Languages (FDL), pp.
202-209, 2011.
D. Greaves and M. Yasin, TLM POWER3: Power Estimation
Methodology for SystemC TLM 2.0, Forum on Specification and
Design Languages (FDL), pp. 106-111, 2012.
R. Damasevicius and V. Stuikys, Estimation of Power Consumption at
Behavioral Modeling Level Using SystemC, EURASIP Journal on
Embedded Systems, 2007.
N. D. Lane and A. T. Campbell, The Influence of Microprocessor
Instructions on the Energy Consumption of Wireless Sensor Networks,
Proc. IEEE Workshop on Embedded Networked Sensors (EmNets),
2006.
R. Hildebrand, Softwaremethoden zur Senkung der Verlustleistung in
Microcontrollersystemen, VDI-Verlag, 2007.
ENERGY
micro,
Online
Help

energyAware
Profiler
http://www.energymicro.com/downloads/online-help-energyawareprofiler, accessed January 2013.
World Wide Web Consortium (W3C), Extensible Markup Language
(XML). http://www.w3.org/XML/, accessed January 2013.
W. Mauerer, Linux Kernelarchitektur, Carl Hanser Verlag GmbH & CO.
KG, 2003.
J. Menapace, J. Kingdon, D. MacKenzie, The stabs debug format,
http://docs.freebsd.org/info/stabs/stabs.pdf, accessed January 2013.