29.01.2015 Views

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Software</strong> Architectural Trans<strong>for</strong>mations 475<br />

preserves the required functionality. Given the initial configuration we<br />

can find an energy-optimized configuration by per<strong>for</strong>ming a series of<br />

functionality-invariant trans<strong>for</strong>mations on The effects of these trans<strong>for</strong>mations<br />

can be analyzed in the following manner.<br />

Given a software architecture configuration and a trans<strong>for</strong>mation<br />

a new configuration is created. Trans<strong>for</strong>mation has to be<br />

un<strong>de</strong>rscored by and because its specific moves are <strong>de</strong>fined based on<br />

the knowledge of and The equation relating the energy consumption<br />

of these two configurations is:<br />

where<br />

<strong>de</strong>notes the energy change incurred by per<strong>for</strong>ming trans<strong>for</strong>mation<br />

In the next sub-section, we will show how<br />

can be estimated<br />

<strong>for</strong> the selected set of trans<strong>for</strong>mations we are interested in.<br />

3.4. Energy change estimation <strong>for</strong> the trans<strong>for</strong>mations<br />

In theory, a software architecture trans<strong>for</strong>mation can relate any two<br />

arbitrary software architecture configurations and However, the actual<br />

change we are going to introduce at every trans<strong>for</strong>mation step can be incremental,<br />

by choice. Such a restriction to the use of atomic trans<strong>for</strong>mations at<br />

every step can make the estimation of<br />

easier if the change is<br />

localized. That is, at every trans<strong>for</strong>mation step, only a small subset of all the<br />

components (processes) in configuration is involved. By this restriction,<br />

we can make the following approximation:<br />

where M is the incremental move that carries universal <strong>de</strong>finition, instead of<br />

being tied to or<br />

By <strong>de</strong>coupling move M from the actual configuration, we are able to<br />

estimate using high-level energy macro-mo<strong>de</strong>ls specific to properties of<br />

the architectural style we have chosen. In our case, since the style of choice<br />

is OS-driven, the high-level energy macro-mo<strong>de</strong>ls are actually characteristics<br />

of the OS. An energy macro-mo<strong>de</strong>l is a function (e.g., an equation) expressing<br />

the relationship between the energy consumption of a software function and<br />

some pre<strong>de</strong>fined parameters. In the above-mentioned context, these energy<br />

macro-mo<strong>de</strong>ls are called the OS energy characteristic data [21]. The OS energy<br />

macro-mo<strong>de</strong>ls proposed in [21] show on average 5.9% error with respect to<br />

the energy data used to obtain the macro-mo<strong>de</strong>ls. This level of accuracy is<br />

sufficient <strong>for</strong> relative comparisons of different trans<strong>for</strong>mations.<br />

Basically, the OS energy characteristic data consist of the following:<br />

The explicit set: These inclu<strong>de</strong> the energy macro-mo<strong>de</strong>ls <strong>for</strong> those system<br />

functions that are explicitly invoked by application software, e.g., IPC

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!