>> Go straight to download <<
Related site: EMSIM
We consider software architectural transformations in the context of the multi-process software style driven by an operating system (OS), which is very commonly employed in energy-sensitive embedded systems. We propose a systematic methodology for applying these transformations to derive an energy-optimized architecture for any given embedded software. It consists of: (i) constructing a software architecture graph representation, (ii) deriving initial energy and performance statistics using a detailed energy simulation framework, (iii) constructing sequences of atomic software architectural transformations, guided by energy change estimates derived from high-level energy macro-models, that result in maximal energy reduction, and (iv) generation of program source code to reflect the optimized software architecture. We employ a wide suite of software architectural transformations whose effects span the application-OS boundary, including how the program functionality is structured into architectural components (e.g., application processes, signal handlers, and device drivers) and connectors between them (inter-component synchronization and communication mechanisms).
The effects of the software transformations we consider cross the application-OS boundary (by changing the way in which the application interacts with the OS). Hence, we use an OS-aware energy simulation framework to perform an initial energy profiling, and OS energy macro-models to provide energy change estimates that guide the application of our transformations.
1. A hardware device can be either active or passive. An active device initiates data transfer spontaneously. A timer is a special active device that spontaneously initiates data (signal) transfer at regular intervals. A passive device, on the other hand, waits for the processor to initiate data transfer. There are two types of passive devices. Fast devices respond to the request from the processor immediately, slow devices require some time (typically more than 1ms) to respond to the processor. To efficiently use the processor, data transfer with a slow passive device is always blocking, so that the process requesting the data transfer can be suspended and the OS can bring in other processes for execution. On the other hand, data transfer with a fast passive device is naturally non-blocking since the device will respond to the processor request immediately.
2. Instead of responding to the processor's request, an active device can initiate a data transfer. Therefore, data transfer with an active device has to be blocking, waiting for the active device to take the initiative. Moreover, to avoid data loss, no process in the SAG should be blocked by more than one active device, either directly, or indirectly through other processes. On the other hand, to efficiently use the processor (no busy waiting), every process in the SAG should be blocked (directly or indirectly) by at least one active device. Therefore, the natural consequence of these requirements restricts the number of ``active'' blocking points for each process to be exactly one. In other words, two processes driven by two different active devices can only communicate through a non-blocking IPC.
3. An SAG, as given, assumes implicitly a schedule of the processes. The validity of this schedule has to be checked separately. A valid schedule has to meet several requirements. A necessary requirement is to have no deadlock. A stronger requirement is to have all the processes meet the deadline. That is, all the processes interfacing with the active devices should not miss any request initiated by these devices. An even stronger, but optional, requirement, is to allow efficient utilization of the CPU. That is, no busy waiting should be employed by any process.
The methodology to minimize the energy consumption of embedded software through software architectural transformations is illustrated in Fig. 1.
Figure 1.
The software architecture level energy minimization methodology
In the figure, the cylinders represent the entities to be operated upon, and the rectangles represent the steps in the algorithm. The methodology starts with an initial software architecture, represented as a software architecture graph or SAG (as described in [1]). The energy consumption E0 of the initial software architecture is obtained by compiling the corresponding program source code into an optimized binary for the target embedded system, and by profiling this implementation using a detailed energy simulation framework. The execution and energy statistics collected from this step are subsequently used to guide the application of software architectural transformations. Our methodology optimizes the software architecture by applying a sequence of atomic software architectural transformations, or moves, that lead to maximum energy savings. These transformations are formulated as transformations of the SAG, and are described in detail in [1] . We use an iterative improvement strategy to explore sequences of transformations. Selection of a transformation at each iteration is done in a greedy fashion. That is, at each iteration, we choose from all the possible transformations the one that yields maximum energy reduction. The iterative process ends when no more transformation is possible.
During the iterative process, for each architectural transformation considered, we need to estimate the resulting change in energy consumption. Since this estimation is iterated a large number of times, it needs to be much more efficient than hardware or instruction-level simulation. We utilize high-level energy macro-models to provide energy change estimates, as described in [1] .
After an energy-efficient software architecture is obtained (as an SAG), the program source code is generated to reflect the optimized software architecture. The optimized program code can be executed in the low-level energy simulation framework to obtain accurate energy estimates for the optimized software architecture.
[1] T. K. Tan, A. Raghunathan, N. Jha, ¡°Software Architectural Transformations: A New Approach to Low Energy Embedded Software,¡± in Proc. Design Automation & Test in Europe, Mar. 2003, pp. 1046--1051.
As a proof of concept, we have implemented our software architectural optimization methodology in an automated framework called SATA. It is written in C++ in the Linux environment. As the software evolves, various versions will be available. However, the software is still not yet available for public download. Please send email to tktan@alumni.princeton.edu to request a download password if you think you can contribute in some ways.
1) 2003/3/14: Initial alpha version - helen-0.1.tar.gz
2) 2003/5/15: Initial alpha version - helen-0.2.tar.gz
3) 2003/6/13: Initial beta version - helen-1.0.tar.gz
1) In a working directory, unpack the helen-x.x.tar.gz by
>$ tar xvfz helen-x.x.tar.gz
a directory helen/ will be created and all the source files will be stored in it.
2) >$ cd helen/
3) >$ make clean
4) >$ make debug
This creates a debug version of the software (Since the software is still in alpha testing).
5) Run the software by typing
>$ dhelen
As mentioned, the input to SATA is an SAG file. An example of an SAG file is given in audio_ctrl.pg. Use the following command to invoke SATA for this example:
>$ dhelen -p audio_ctrl.pg -l work/linux.lib -c audio_ctrl
linux.lib is an OS energy macro-model file. A default linux.lib has been provided in the sub-directory work/.
The SATA framework analyzes and optimizes this .pg file. It then generates
prototype C code for both the initial and optimized SAG. For the above example,
the generated prototype C code includes:
1) audio_ctrl_0.c and
audio_ctrl_1.c
2) audio_ctrl_0.h and
audio_ctrl_1.h
3) audio_ctrl_sdevmodel.c
(Simulation models for the peripheral devices)
4) linux_lib.c and
linux_lib.h (Library interface to the
underlying OS system calls)
You need to define all the computation functions used by the software processes. Some examples of the computation functions used in this example are provided in function_lib.c
To link everything together, you can tailor the following makefile: Makefile
Last updated: 2006/07/11