You are on page 1of 4

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}

AbstractPower constrains are becoming increasingly important for embedded systems, especially when considering mobile appli- cations. These systems are characterized by the presence of a dedicated processor running application-specific software. Cur- rent 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 ac- count. 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 microcon- troller 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.





Hardware/Software Co-Design; Power System Simulation



“Embedded systems can be defined as information pro- cessing systems embedded into enclosing products such as cars, telecommunication or fabrication equipment.” [1]. Be- cause 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 viola- tions are determined. Open issues must be reduced and elimi- nated in each cycle, in order to meet all requirements of the system specification.

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

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

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 chal- lenging, 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.

This paper proposes a novel method to support the power evaluation process. From software development perspective, we enable the visualization of the system’s overall power con- sumption 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 hard- ware. 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 virtu- ally, 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 pow- er 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 con- cludes the paper.


Regarding power analysis and optimization, today’s ap- proaches and innovations concentrate on two distinct domains in ESD.

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 ap- proaches 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


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.

The second domain addresses the power optimization po- tential in the embedded software of the microcontroller. In the approaches [8][9][10], the executed code is analyzed to mini- mize the power of the microcontroller. In our work, we reuse the power profiler developed in [9] which provides an analyz- ing mechanism to estimate the power consumption according to each source code line. In these approaches the external pe- ripherals are not regarded.

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 sys- tem during the software design process.


The power characteristics available from hardware simula- tion are used to aid the software development. First, an exam- ple platform is specified for illustration, followed by the proce- dure of the proposed co-design. We denote internal and exter- nal peripherals to distinguish between hardware components within the microcontroller e.g. timers and externally connected components e.g. sensors.

A. Example Platform

The methodology is discussed using the example platform illustrated in Fig. 1. The example basically consists of a Mixed- Signal Microcontroller (MSP430F1611) running the embedded software along with the following external peripherals de- scribed 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 (I²C), which is a serial bus interface provided by the processors internal peripherals.





the processors internal peripherals. LED MSP430 Button SHT I²C Bus Fig . 1 Example platform including

I²C Bus

Fig. 1 Example platform including a MSP430, a button, a LED and a SHT connected via I²C bus

The software continuously samples the temperature. By pressing the button, the example software stores one tempera- ture 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 pre- sented in Fig. 2: The code compilation, simulation, processing and annotation. They are described in detail below. We define


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.

Code Compilation






file.elfSimulation Controller model Peripheral models file_eprof.c & system.xml Processing Annotation

Controller model Peripheral models file.elf file_eprof.c & system.xml Processing Annotation
Controller model Peripheral models file.elf file_eprof.c & system.xml Processing Annotation
Controller model Peripheral models file.elf file_eprof.c & system.xml Processing Annotation

file_eprof.c & system.xml



annotation.xmlfile.elf file_eprof.c & system.xml Processing Annotation Fig. 2. General overview of the workflow 1) Code Compilation

Fig. 2. General overview of the workflow


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 com- piler. These are used to aid the annotation process. The assem- bled instructions (ASM) of the program and the debug infor- mation 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].



The actual simulation is investigated under different as- pects. The software and the hardware domain influence each other and are highly related. They are discussed separately to distinct the information’s origin.

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 controller’s 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 access- es is stored. The example implementation uses the concept of the eprof profiler [9].

The external hardware influences the execution of the source code e.g. by requesting interrupts. This behavior, mod- eled in SystemC, is considered in the ISS. Both together pro- vide the interaction between the controller and the external peripherals. According to the power framework [6] certain power-states of hardware components are abstracted. To con- nect 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 I²C. This transi-

tion is denoted as active, because the communication is trig- gered directly by the source of the microcontroller. The meas- urement 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 soft- ware.

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 attrib- utes are the name and powerscale. The former is used for iden- tification 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 discern- ibility 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 coun- ter, a memory value, or a certain bit used in a state machine.

In case of passive or semi-active changes, defining a mark- er 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 I²C communication. To mark a peripheral controlled by a state machine, the state vari- able itself is used as marker.

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 cur- rent active state along with the attribute time which denotes the timestamp of the change. Moreover, the timeline has a time- scale 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">


<timeline timescale="ms">

<!-- init start! -->

<signal time="0" peripheral="LED" state="off"/>


init end! -->

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



Fig. 3. Example of the system.xml



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 anno- tation 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.

In addition to the power annotation to the source code, sta- tistical information of the hardware is generated from the re- sults of the system simulation. Therefore, the timeline is ana- lyzed to determine the duty cycles of each peripheral power- states 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 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 mark- er of the state transition.

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 du- tycycle 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.


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

<line nr='54' membytes='3' power='3.8pJ' exe='1305' memread='2' memwrite='0' > <marker peripheral='SHT' /> </line>


<file name='include.c'>

</file> <system timescale="ms"> <peripheral name="LED" powerscale="mW"> <state name="on" power="66.0" dutycycle="0.102"


<state name="off" power="0.01" dutycycle="0.898"





Fig. 4. Simple instance of the Annotation.xml


Different visualization concepts of the XML format pre- sented 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 con- cepts offer power optimization in software. They help to identi- fy the variable implementation in terms of memory or register use. They can be used to optimize functions calls with mini- mum 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 simula- tion, providing a way of optimization or manual driven design explorations.

For optimization purpose, the peripherals have to be recon- sidered. Referring to the manual driven design exploration along with our strict specification, the LED cannot be ex- changed, since it has to have a minimum brightness to catch attention. Also the SHT21 sensor is already very energy sav- ing, 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 ex- ample by using better data structures. All of it makes a differ- ence, 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.

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 LED’s duty cycle. Another ex- ample is the lowering of the used temperature resolution from

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 exam- ples only need little changes to the source code, but are vital for lowering the overall power consumption of the peripherals.


In order to meet tight power constrains, a lot of develop- ment time has to be spent in ESD. To ease this process, a work- flow 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 illus- trated 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 soft- ware/hardware co-simulation and allows power optimizations as well as manual driven design space explorations. The meth- odology has been investigated for systems with single micro- controller applications and different types of external periph- erals. Since our contribution seems to open a promising path, in future work we will investigate multi master systems.



[2] Automation, Design and Committee, Standards. IEEE Standard

SystemC Language Reference Manual. IEEE Computer Society, 1666,

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


[3] 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. Streubühr, 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.

[6] 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.


[8] 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),



R. Hildebrand, „Softwaremethoden zur Senkung der Verlustleistung in Microcontrollersystemen“, VDI-Verlag, 2007.


profiler, accessed January 2013. [11] World Wide Web Consortium (W3C), Extensible Markup Language (XML)., accessed January 2013. [12] W. Mauerer, Linux Kernelarchitektur, Carl Hanser Verlag GmbH & CO. KG, 2003. [13] J. Menapace, J. Kingdon, D. MacKenzie, The “stabs” debug format,, accessed January 2013.