OS Support for Adaptive Components
in Self-aware Systems
João Gabriel Reis
Software/Hardware Integration Lab
Federal University of Santa Catarina
Florianópolis, Brazil
jgreis@lisha.ufsc.br
ABSTRACT
The current pace of innovation in computing makes it difficult
to assume a fixed set of requirements for the whole life span
of a system. Aggressive technology scaling also imposes addi-
tional constraints to modern hardware platforms. An answer
to this question are self-aware systems, which are capable
of autonomously sensing and actuating upon themselves to
cope with varying requirements. In this paper, we discuss
the design and implementation of adaptive components in
this scenario from the perspective of the OS. Components
can exist in multiple flavors that can by dynamically chosen
according to current demands. The proposed framework
supports this variability for components while preserving
their interface contracts, even if flavors exist in different do-
mains (software, hardware, remote). The synthesis process
delivers tailored wrapper for components according to their
flavors. Besides reconfiguration, we also support adaptations
through dynamic power management and task remapping.
The framework also supports component designers in terms
of sensing via an event-based mechanism. The framework is
validated through a case with three adaptive components in a
telecommunication switch (AES, ADPCM, and DTMF) with little
overhead both in terms of execution time and memory/silicon
consumption.
Categories and Subject Descriptors
D.4.7 [Operating Systems]: Organization and Design;
D.2.11 [Software Engineering]: Software Architecture
Keywords
Embedded operating systems, real-time systems, adaptive
computing, system-level design
1. INTRODUCTION
Many modern computing application scenarios, including
smartphones, autonomous vehicles, and IoT devices, evolve
so quickly that it is no longer viable to define a fixed set
Permission for classroom and personal use is granted, providing this notice
appears on all copies.
SBESC 2016 João Pessoa, Brazil
Copyright 2016 by the Authors. This work is based on an earlier work:
Mutant Components: Efficiently Managing Multiple Implementations, in
Proceedings of the 6th Brazilian Symposium on Computing System Engi-
neering. ©IEEE, 2016. http://dx.doi.org/10.1109/SBESC.2016.NNN.
Antônio Augusto Fröhlich
Software/Hardware Integration Lab
Federal University of Santa Catarina
Florianópolis, Brazil
guto@lisha.ufsc.br
of requirements for the whole design process. Increasingly,
systems are having to adapt themselves on-the-fly in order
to cope with varying (and sometimes conflicting) require-
ments. Additionally, these scenarios are being enabled by
aggressive technology scaling, which, besides producing low-
cost, high-performance systems, also brings about a series
of new issues such as process variation, failure of Dennard’s
law, and emergence of dark silicon [28, 35]. These systems
must constantly monitor and adapt themselves in order to
be energy-efficient and to wear out evenly, being often called
self-aware [8,9,27,28,31,37]. In this context, rigidly partition-
ing components between software and hardware inevitably
leads to sub-optimal results, once the design space for each
component becomes constrained by other component’s re-
quirements, by system-wide requirements, and by the overall
availability of resources, even if those components are not
meant to be used simultaneously.
Adapting components at run-time is an alternative to
cope with dynamically changing requirements, specially non-
functional ones, such as performance and power [18]. Adapt-
ability also improves tolerance to hardware faults, particu-
larly those arising from Negative-Bias Temperature Instabil-
ity (NBTI) and Process, Voltage and Temperature (PVT)
variations [22]. An adaptive component architecture enables
each individual component to exist in multiple flavors, each
encompassing a specific compromise between the quality of
the functionality being provided and the resources needed to
provide it [30]. For instance, a component may coexist as a
sequential software to be run in a single CPU, as a parallel
software to be run on a multicore CPU or on a GPU, as hard-
ware to be instantiated on an FPGA, or as a remote (web)
service. With proper run-time support, different flavors of
a component can be activated along the time, enabling the
system as a whole to cope with the demands presented at
each moment. Multimedia, vision, and physical simulations
are good example of subsystems that make use of components
that can be adapted in this sense.
In this article, we discuss the design and implementa-
tion of adaptive components in self-aware systems from the
perspective of the operating system. We understand that
components must be intentionally designed for adaptability
in order to reach the desired goals and therefore we propose a
framework to support such designs. An adaptive component
within the devised framework performs computations whose
quality and timeliness depend on the resources currently
available (e.g. processor cycles, energy, and hardware area),
on the global system status (e.g. throughput, power con-
sumption, and temperature), and on explicit choices made
by programmers (e.g. list of component flavors that match is used to adapt the work of background tasks according to
the application requirements). With components designed a desired rate of energy consumption. Adaptable software
following a common set of adaptability principles and imple- parameters can be used to maximally leverage the underlying
menting a common set of management functions (i.e. sensing, hardware platform in presence of variations, for example in
communicating, and adapting), global system adaptability multimedia applications [27]. Finally, self-awareness can be
can be pursuit more efficiently in a holistic approach [31, 37]. extended to System-on-a-Chips (SoCs) platforms coupled
In summary, the main contributions of this article are: with cross-layer sensing and actuation [31]. The general mech-
anism of observe-and-adapt from parametric control can be
• we comprehensively analyze the current scenario for used in our approach to add a dimension of choice of soft-
adaptive components from the perspective of run-time ware and hardware for components that can be dynamically
support systems. chosen to implement a given functionality.
• we present framework in the form of a set of principles Field-Programmable Gate Array (FPGA) reconfiguration
and C++ techniques to design and implement adaptive adds a new level of adaptation in which the application par-
components. titioning between hardware and software components can
change during runtime to cope with system state. Several
• we evaluated the proposed framework through a real efforts focus on developing computing environments that
case study based on an adaptive telecommunications can help developers to leverage heterogeneous computing
switch. resources such as FPGAs and simplify its development flow.
Such computing environments provide abstractions and in-
2. RELATED WORK terfaces to application programmers familiar with concurrent
and parallel systems. ReconOS [19] provides a common ab-
One broad approach for coping with unpredictable run-
straction layer for software and hardware threads as well
time variations in performance, energy, and hardware defects
as a set of communication and synchronisation primitives
is to have multiple paths available to perform a set of opera-
for them. Low-level synchronisation and communication of
tions. Each of these paths may be better suited for a given
hardware threads are managed by theirs Operating System
system state or user input. Petabricks [2] and Eon [33], for ex-
Interface, an artifact embedded in hardware threads. It fo-
ample, feature language extensions that allow programmers
cuses on real-time applications and multithreading providing
to provide alternate code paths. In Green [3], a combination
to the user an API based on the eCos operating system as
of a calibration phase and run-time accuracy sampling are
well as on Linux. Despite providing the infrastructure for
used by the application to define which function to execute
deploying hardware and software threads, they are not in-
from a set of possible candidates. In Eon and Levels [17]
terchangeable. Programmers must explicitly chose between
the run-time system dynamically chooses paths based on en-
hardware and software on design time, sacrificing the us-
ergy availability. Compared to traditional algorithmic choice
age of hardware reconfiguration as an adaptive mechanism
research, and in particular to the ViRUS framework [37]
transparent for the application.
that shares our motivations for dynamic handling of sensing
A higher-level approach to using FPGAs is proposed by
data and variability events, our work adds a dimension of
Abel [1] that advocates describing reconfigurable modules in a
hardware reconfiguration, whereby one of the code paths
Java-like language called Parallel Object Language. Though
may be offloaded to specialized hardware.
partial reconfiguration techniques, reconfigurable modules
The code used to implement a given Application Program
can be created and destroyed at run-time just like regular
Interface (API) function may also be changed at the binary or
software objects. The modules can be tested in verified
bytecode level during. Dynamic recompilation techniques [36]
using a Java Emulator and then translated to VHDL for
test different optimization techniques at run-time, so that
synthesis. Communication architecture is centered around
code is matched to the capabilities of the hardware which
FIFOs and multiplexers for parallel data exchange controlled
is running it. Dynamic recompilation may be performed in
by a software scheduler. The scheduler also that orchestrates
a system-driven manner, with minimal support from appli-
reconfigurable modules loading into partially reconfigurable
cations, providing the same adaptation knobs as in compile
regions. Such work excels on providing high level mechanisms
time optimization, e.g., loop unrolling, memory optimization,
for dynamically reconfiguring FPGAs but focus only on
and automatic parallelization. Our work resembles dynamic
hardware components, leaving no space for components with
recompilation as multiple code paths (or component flavors)
multiple flavors in different domains (e.g. software).
are explored automatically by the run-time system without
Moreover, Cemin et al. propose a framework for multi-
application intervention, but it is closer to algorithmic choice
agent systems that supports hardware/software migration
in that the alternative flavors are defined at design time.
among different nodes of a distributed system [5]. Their
Application and hardware parameters can also be dynam-
framework allows the dynamic reconfiguration of distributed
ically adapted to explore energy, quality, and performance
application to cope with variable system requirements. The
trade-offs [16]. Dynamic Voltage and Frequency Scaling
communication between agents is handled transparently by
(DVFS) is the canonical example for hardware tuning. In
proxies that handle all the low-level intricacies of hardware
software, Green [3] provides an adaptation modality where
communication. Their approach is implemented on top of
the programmer provides “breakable” loops and a function to
the Jade framework, a Java-based multi-agent systems frame-
evaluate quality of service for a given number of iterations.
work. Compared to them, we propose a leaner approach on
The system uses a calibration phase to make approximation
top of bare metal C++ employing metaprogramming tech-
decisions based on the quality of service requirements speci-
niques.
fied by the programmer. At run-time, the system periodically
In systems where tasks can execute in different cores
monitors quality of service and adapts the approximation
due to architectural choices (e.g. heterogeneity in ARM
decisions as needed. In the mobile context, Powerleash [9]
big.LITTLE), variability issues, and availability of dedicated
resources (e.g. FPGA, GPU), the dynamic mapping of a task
to a specific computational resource can be used to adapt
the system to its environment. Heterogeneous many-core
architectures are being used to cope with varying workloads
on modern embedded systems platforms as mobile devices.
In this scenario, dynamically mapping tasks to different cores
with different performance/power characteristics can increase
the core throughput while minimizing the energy to execute
the task [8]. Not only to improve power and performance,
scheduling tasks to different cores dynamically also helps
to mitigate hardware variability effects on critical paths de-
lay [28]. The usage of heterogeneous computing substrates as
FPGAs allows tasks to be mapped into them reconfigurable
partitions during run-time to exploit its inherent parallelism.
Moreover, the reconfigurable resources can also be used to
exploit power characteristics when compared to the multi
purpose machines [18]. Compared to such works, we propose
a similar approach in which not only tasks can migrate but
also other components in the system.
Compared to dynamic recompilation and algorithmic choice
we propose another level of actuation by also deploying recon-
figurable hardware as a substrate for components. We go one
step beyond traditional reconfigurable computing solutions
and provide also sensing mechanisms tightly integrated with
the rest of the adaptive components infrastructure. Sensing
can be leveraged to better exploit FPGA reconfiguration ca-
pabilities by predicting when parts of the application should
be reconfigured based on system level metrics. Moreover,
as opposed to ours, in others solutions it is the applications
programmer’s role to juggle with multiple flavors using dif-
ferent interfaces specially when they are deployed in different
substrates, e.g. FPGAs and CPUs. Our work transparently
profits from heterogeneous substrates and provides a unified
interface for components with multiple flavors. Thus, recon-
figuration happens can be delegated to lower system layers
with a holistic view of system operation.
3. ADAPTIVE COMPONENTS
System adaptation is tightly bound with three aspects:
sensing the current embedded system state, predicting actions
that can optimize one or multiple constraints, and performing
them. Reconfiguration can fit in an adaptive system as an
actuation mechanism to cope with unpredictable conditions
faced by the application. The adaptation system is aware
of the system behavior by means of models of system and
components behavior (e.g. performance, temperature, aging).
By feeding those models with data from sensors captured
during run-time, it is possible to predict if by reconfiguring a
component, the system can improve a system-level metric (e.g.
throughput, energy, temperature) and delegate the action
to a manager. Multiple flavors can be available through
a flavor pool from which the adaptation system can chose
based their inherent characteristics. Reconfiguration must
be transparent without breaking the interface between the
application and components core functionality. According to
such principles, in Figure 1 we illustrate components initially
deploying flavor A which is latter reconfigured into flavor B
for some of them.
In this section, we introduce the guidelines used to design
adaptive components initially recalling the main concepts
behind Unified Design (UD). Next we present the design
guidelines that must be followed for deploying adaptive com-
Application
Flavor A A A
A A A Interface
Power
Model Temperature
PMU
Decision
...
B Manager
B B Sensors
Reconfigure
Flavor pool
B A B
A A B
Figure 1: Adaptive components reconfiguration. Multiple
flavors are available in a pool and can be deployed according
decisions based on models inferring system behavior from on
sensor data.
ponents in different substrates. Finally sensing mechanism
are introduced followed by additional actuation methods that
can be explored.
3.1 Designing Adaptive Components
Each component and its interface is adaptive in terms of
its flavor as well as its resulting Quality of Service (QoS).
Adaptive components allow for dynamic change between
multiple software and hardware flavors choices, as well as
adjustments in operation parameters for each of the choices.
The resulting QoS and cost for each component depends on
the specific choice of flavor as well as the physical state of
the system at any point in time.
We divided flavors in three groups: software, hardware,
and remote. Software flavors run in soft and hard core proces-
sors where the operating system is also being executed. Such
flavors might use not only the CPU ALU but also tightly-
coupled coprocessors such as floating-point units and Single
Instruction, Multiple Data (SIMD) engines through special
instruction sets. Hardware flavors can vary in microarchitec-
ture details that result in different balances between power
consumption, performance, and resource usage. They can
be implemented as dedicated circuits in Application-Specific
Integrated Circuits (ASICs) or as reconfigurable modules in
FPGAs. In both cases, the CPU executing the operating
system interacts with them through I/O mechanisms such
as Network on Chip (NoC) communication, Direct Memory
Access (DMA), or memory-mapped I/O. The last group,
remote flavors, comprises software and hardware flavors that
are not being deployed on the same machine as the appli-
cation. The flavor is accessed through a network device,
which will forward the call to a remote machine and fetch
the results.
For implementing hardware and software flavors of compo-
nents seamlessly, we rely on the UD extension of Application-
Driven Embedded System Design (ADESD). ADESD is a
multi-paradigm domain engineering methodology that guides
a domain decomposition into reusable, scenario-independent
components while capturing scenario-specific variability as a
set of aspect programs [11]. UD provides guidelines to capture
the differences between software and hardware as separate
aspect programs that can be subsequently used to produce
multiple flavors of each component during synthesis [24].
This is possible through the isolation of specific hardware
and software characteristics (resource allocation and commu-
nication interface) into aspect programs which are weaved
with the unified descriptions only during the synthesis pro-
cess. Therefore, the extraction of hardware/software flavor
from the unified design happens directly through language-
level transformations, thus facilitating compatibility with
different C++-based High-Level Synthesis (HLS) tools and
design flows. By using UD concepts we provide an approach
for deploying adaptive components employing static metapro-
gramming techniques and a transparent interface from the
application developer point of view.
3.2 Interfacing Adaptive Components
Multiple flavors of an adaptive component are exposed to
applications through a single, unified interface which in our
approach is called inflated interface [11]. Metaprogrammed
software artifacts are used to handle differing function sig-
natures, communication with hardware IP cores, and state
migration between flavors. While all software flavors and
IP cores bitstreams are included in the system image (typ-
ically kept in volatile memory), hardware accelerators are
instantiated and freed on-demand, and therefore do not take
up system resources (particularly FPGA area) when not in
use. From the application’s standpoint, a call to a double
precision exponential function is therefore identical to a call
activating a hardware IP to calculate it or a remote call to a
cloud resource.
Our approach assumes that applications dynamically in-
stantiate (and destroy) the components they need, and the
operating system automatically uses the flavor that best suits
its current needs. Multiple component flavors are available to
applications through a single interface. For the application,
a call to a software function is, hence, identical to employing
a hardware IP core or a remote call to a cloud resource.
The application programmer selects its preferred flavor of
a given component for each application but, to cope with
system load as well as environmental and manufacturing-
related variations, the deployed flavor might change during
run-time. To infer which flavor best suits the current system
needs, the operating system opportunistically and specu-
latively senses system load, hardware resource usage, and
hardware performance parameters.
The C++ programming language is used to illustrate the
usage of adaptive components, the same concepts could be
applied to any programming language supporting object-
orientation and static metaprogramming techniques. C++
classes abstract components, each component has a parame/-
trized class whose static constant members describe the prop-
erties (traits) of a certain type. Per-application constraints
can be used to guide the reconfiguration process and dictate
which version of a component should be used under different
circumstances. The only additional information the user
must provide to the operating system is which flavor of a
component better suits each application by listing the accept-
able flavors in order of preference in the applications’ traits
(programmers can also delegate the choice to the system by
omitting the declaration).
In Figure 2, the parameterized class Traits<Component>
denotes the traits of Component for a given application in
which the flavor order of preference is Flavor_2, Flavor_0,
Flavor_1. With this information, the system can adapt
to process and environmental variations during run-time
by using flavors that best suit system’s requirements while
trying to utilize the user’s preferred flavors.
template<> struct Traits<Component>
{
typedef LIST<Flavor 2, Flavor 0 , Flavor 1> FLAVORS;
};
Figure 2: Example of the parametrized traits class for a
generic component.
Template metaprogramming techniques enable the user
to assign a priority to each component flavor in each appli-
cation without inferring run-time overhead using the traits
mechanism. LIST type is a metaprogrammed list of types
populated by the user containing the preferred flavors of
Component. Through C++ template metaprogramming, it is
possible to obtain the number of types in the list and also a
type stored under a given index during compilation without
inferring run-time overhead. Notice that if the programmer
prefers to fully delegate the choice to an automated tool or
to other system layers with a holistic understanding of the
systems at run-time, he can simply skip declaring the static
list of choices.
3.3 Decoupling Interface and Implementation
Independent of the flavor deployed in a given moment in
time, the component must provide a uniform interface to its
clients. Also, changing the flavor behind a given component
must be a transparent operation and a clean interface must
be provided to the entity in charge of performing compo-
nent reconfiguration. To comply with such requirements,
this work proposes an indirection between the component
interface and the flavor being currently deployed. More-
over, any infrastructure deployed for this purpose must not
incur any overhead when the component has a single fla-
vor. Polymorphism was employed to guarantee that the
infrastructure remains scalable independent of the number of
flavors and static metaprogramming techniques assure that
polymorphism is deployed only when strictly necessary.
Figure 3a presents the building blocks of the infrastructure
proposed for adaptive components. A parametrized class
named Handle is introduced between the adaptive component
interface provided to its clients and its flavors. It defines a
first component wrapper whose main purpose is to ensure the
usage of a proper allocator for components, independently of
how they are statically or dynamically declared by the client.
Handle realizes the interface of the component passed as a
parameter and forwards invocations of its methods to the
flavor deployed in a given moment. It can point to any of its
 polymorphic
template<typename Component>
«Mutant» class Handle
Component N {
private :
operation() typedef typename Traits<Component>::FLAVORS FLAVORS;
typedef typename IF<FLAVORS::Polymorphic, typename Component::
template Base<true>, typename FLAVORS::template Get<0>::
Result>::Result Base;
Flavor_0 Flavor_N
... static const unsigned int UNITS = FLAVORS::Length;
operation() operation()
public :
void operation () { current −>operation(); }
Component

Handle void reconfigure ( int i ) {

Client if ( i < UNITS)
reconfigure() current = flavors [ i ];
}
(a) Component binding to a Handle with N flavors. private :
false Base ∗ current ;
«Mutant» Base ∗ flavors [UNITS];
Component };

Figure 4: Handle implementing method forwarding and re-

configuration.
Flavor_0

operation() polymorphic, we can have a polymorphic base class with

pure virtual methods or an empty class. Each Component
flavor will choose from which to inherit based on the number
Component
of flavors.
Client Handle

(b) Component binding to a Handle with a single flavor. class Component

Figure 3: adaptive component framework.
N flavors while still maintaining references to the other flavors // Polymorphic Base
for later usage. It also provides the reconfigure() method
as means of changing its component current flavor during run-
time. Hence, adaptive components are manipulated through
their Handles.
Handle keeps a reference to each deployed flavor by means
of a Base pointers array, _flavors, as presented in Figure 4.
_current is a pointer to the current flavor and is used by the
Handle to dispatch invocations to the component’s methods.
The type Base is defined using the IF metaprogram according
to the value of Polymorphic which is also a metaprogram
that defines a boolean after searching the list of flavors for
any flavor of a type different then that at the list’s head. IF
returns its second parameter, the Component::Base<true>
class, if its first parameter evaluates as true else, it returns
the third one, the Component single flavor.
Notice that Component::Base<true> is the base class in-
herited by each of the component’s flavors. Component::Base<true> A minimal implementation of Handle’s constructor is
methods are pure virtual to comply with the fact that _cur-
rent might point to multiple flavors. This allows _current
to point to any flavor and invoke their methods. The recon-
figure() method can be easily implemented by changing
the element to which _current points to.
If Polymorphic is false, Base will be the flavor itself re-
sulting in the architecture presented in Figure 3b. In this
case, the methods will only be defined and implemented in
the component’s sole flavor with the Base inheriting from
the flavor itself. The differentiation is necessary to remove
the virtual function call overhead for a single flavor. The
Component::Base behavior can be achieved with template
specialization techniques depicted in Figure 5. By special-
izing the template Component::Base according to value of
{
public :
template<bool polymorphic>
class Base;
};
template<bool polymorphic = true>
class Component::Base: public Component
{
public :
Base() {}
virtual ˜Base() {}
virtual void m() = 0;
};
// Monomorphic Base
template<>
class Component::Base<false>: public Component
{
public :
Base() {}
};
Figure 5: Possible Component::Base implementation.
shown in Figure 6. The template parameter polymorphic
is set to true if the number of flavors is bigger than 1 by
checking the list’s Length. Handle’s constructor initializes
each flavor and insert them in _flavors by employing tem-
plate recursion as a looping construct [6]. The first invoca-
tion of helper() initializes the first metaprogrammed list
element defined in the component’s traits as previously ex-
emplified in Figure 2 and keeps a reference for it in the Base
pointers array. helper() initializes each element until it
reaches the last element in the list, with an index given by
Traits<Component>::FLAVORS::Length.
C++ namespaces are used to separate flavors and the de-
coupling artifacts from its interface exported to the appli-
cation. The former is defined in the System namespace
// Type ENNUMERATOR
template<unsigned int N>
struct Index { enum { Result = N }; };
template<typename Component>
class Handle
{
private :
typedef typename Traits<Component>::IMPS IMPS;
typedef typename IF<IMPS::Polymorphic, typename Component::
template Base<true>, typename IMPS::template Get<0>::
Result>::Result Base;
static const unsigned int UNITS = IMPS::Length;
public :
Handle() {
helper (Index<0>());
current = flavors [0];
} Software
private :
template <unsigned int UNIT>
void helper (const Index<UNIT> &) {
flavors [UNIT] = new typename IMPS::template Get<UNIT>::
Result;
helper (Index<UNIT + 1>());
} communication architecture. It can be used with different
void helper (Index<UNITS>) {};
private :
Base ∗ current ;
Base ∗ flavors [UNITS];
};
Figure 6: A minimal implementation of Handle’s construc-
tor.
while the latter goes on the Application namespace. The
client interacts directly with a Handle as in the applica-
tion namespace the component is bind to its Handle al-
ready specialized with namespace Application { typedef
System::Handle<System::Component> Component }.
3.4 Cross Domain Interaction
Each flavor encapsulates the communication mechanisms
necessary to exchange data and perform the computations
on its substrate. In the software domain, components are
objects which communicate using method invocation, while
in the hardware domain, components communicate using
I/O signals and specific handshaking protocols. For commu-
nication across different domains, the operating system must
provide appropriate abstractions for hardware components
and mechanisms for interrupt handling while the hardware
must be aware that it is requesting a software operation. For
instance, if given flavor uses a hardware IP to perform a
calculation it is responsible for all mechanisms that must be
deployed to exchange data between itself and the IP. The
same applies for an flavor that depends on resources from
different nodes of a network; it must operate the network
stack to communicate with it.
To abstract communication patterns between components
in different substrates, we employ an approach based on
Remote Method Invocation (RMI) concepts from distributed
object platforms [26]. Figure 7 illustrates an interaction
between a component in the software domain with another
in the hardware domain. Callee components are represented
in the domain of callers by proxies. Channels deploy serializ-
ers and deserializers to marshal data structures exchanged
by different domains. When an operation is invoked on a
component’s proxy, the arguments supplied are marshaled
into a request message and sent through a communication
channel to the corresponding component’s agent. An agent
receives requests, unpacks the arguments and performs local
method invocations. The whole process is then repeated in
the opposite direction, producing reply messages that carry
eventual return arguments back to the caller
request request
call call
Component Proxy agent Component
Channel
A B
return return
reply reply
Hardware
Figure 7: Cross-domain communication using proxies and
agents as proposed by Mück [24].
The approach based on channels, proxies and agents that
we have adopted for communication does not impose a single
networking technologies, such as a shared bus, a NoC, or a
DMA engine. For instance, when a bus-based communication
channel is used, a proxy in hardware may be implemented
as a memory-mapped slave device that notifies the CPU
through interrupt requests when it has a message ready to
be read. Alternatively, on a NoC based implementation, a
packet-oriented interface would be used to transmit request
messages. Such variability is related to choices regarding the
hardware/software architecture of the chosen implementa-
tion platform and should not affect the system components.
Finally, the resulting communication bandwidth is limited
mostly by the chosen underlying communication technology.
3.5 Component State Handling
Not all related works that propose reconfiguring compo-
nents from software to hardware and vice versa consider
component’s with an internal state [5]. Stateless components
simplify reconfiguration as there is no need to deal with the
state representation in different domains (i.e. software and
hardware) with different syntaxes for representing a state.
We overcome this issue with a unified description of both
hardware and software components which allows the designer
to express the component state uniformly among domains.
To keep the system sane when changing a component, the
old flavor must provide a snapshot of its state so that it can
be restored into the new one. For simplicity, we consider
that each component (hardware or software) provides a data
structure that captures its current state as a set of variables
and each of its flavors provides methods to save and to
restore its state using such data structure. The methods,
save_state() and restore_state(), are invoked by the
entity performing the reconfiguration which is responsible
for transferring the state from one flavor to another as one
atomic operation. Figure 8 shows both methods used to
manage the flavors’ state for a component whose current
state comprises two variables, _a and _b. When synthesized
into hardware, the state machine controlling its operation
will be able to interpret its registers as the variables in the
higher level description and return them when save_state()
is invoked by RMI. The same holds for restore_state()
that will map the data received by RMI into state machine
registers.
class Flavor 0
{ ing a set of operations at initialization-time to obtain average,
public :
struct State {
int a;
float b;
};
public :
Flavor 0 () {}
State save state () {
State state ;
state .a = a;
state .b = b;
return state ;
}
void restore state (State &state) {
a = state.a;
b = state.b;
} stracted in the framework using the observer design pattern,
private :
int a ;
float b;
};
Figure 8: Example of helper functions for saving and restoring
a component’s state.
By employing UD techniques for developing hardware and
software flavors from a unified description, which in our case
is written in C++, the state representation and the interface
for handling it are uniform avoiding complex state migration
issues. Techniques for migrating and changing the numerical
representation of the current state from one flavor to another
are a complex matter and are outside this paper’s scope.
For instance, there is no common convention for conversion
between most numerical data types (e.g. how to convert a
IEEE 754 binary64 number to a fixed point representation).
Moreover, it is also not trivial to infer the type of each
data value that constitutes the component state without
embedding meta data in each value. Finally, the conversion
must be performed only once (in the previous or in the next
flavor) and a synchronization mechanism or convention must
be employed to avoid multiple conversions.
3.6 Sensing
Adaptive components leverage sensors available across
multiple layers in the platform to make control decisions.
At platform-level, they can employ per-core Performance
Monitoring Units (PMUs) available in most commercial plat-
forms today to assess workload properties at run-time, such
as number of instructions executed, cache misses, branch
mispredictions, etc [34]. Most modern platforms are also
instrumented with a wide range of physical sensors, includ-
ing power, temperature, and aging. Virtual sensors can be
deployed to replace unavailable physical ones, for instance
by using models and predictors (e.g. power and tempera-
ture) and encapsulating system-level metrics such as core
utilization and core throughput [32].
Most modern peripheral devices also feature event counters
that can be monitored to track their performance, energy
consumption, and several other operational parameters. Nev-
ertheless, even with no hardware performance monitoring at
all, the operating system can implement event counters in
software to keep track of the many aspects of the system [10].
Another mechanism used in our framework consists in profil-
interference-free estimates for the most relevant ones, such as
network package injection and retrieval or disk sector reading
and writing. At run-time, the variation in the time observed
for such operations renders information that can be used by
predictors to derive the current status of the system [8].
In our framework, sensing data is exported to components
as events. An event models a condition derived from sensing
data independently of whether that data originates from
from a Hardware Performance Counters (HPCs), from a sen-
sor (physical or virtual), from a software counter, or from
a predictor. An interrupt driven by a hardware counter is
directly mapped into an event [20], while software-triggered
ones either arise passively from the system’s execution flow
whenever a condition matches, or actively through the use
of periodic monitoring threads. In any case, events are ab-
so entities producing events notify those observing those
events.
Events are used in the framework in a two-stage scheme,
with components observing low-level events and managers
observing components. This scheme is depicted through the
sequence diagram of Figure 9. The Manager registers its
interest on a component’s sensing capabilities by invoking
the attach() method. In turn, Component registers for re-
ceiving notifications about Events. Different events can be
associated to a same sensor, thus accounting for the model-
ing of distinct thresholds and different reasoning about the
captured data. An event can also be associated to multiple
sensors. This flexibility enables a finer tuning between man-
agers and components, improves information quality (since
noise can be more easily filtered closer to where signals are
captured), and reduces sensing overhead (since a properly
configured system will propagate less useless events).
Manager Component Event
attach()
attach()
alt [threshold reached]
notify()
alt [threshold reached]
notify()
Figure 9: Sequence diagram of Component and Manager sub-
scription to receive sensing notifications from an Event fol-
lowed by the notification propagation.
3.7 Actuation
Similarly to sensing, actuation also takes place in two levels
within the framework, with components autonomously react-
ing to events as they are triggered and managers reacting
to both native and component-generated events. Immediate
reaction to events by components are restrict to local actua-
tion, such as disabling a peripheral when it is no longer being
used. System-wide actuation is meant to be carried out by
managers. Besides supporting component flavor reconfigu-
ration at run-time, the framework provides two additional
main classes of actuation mechanisms for managers to adapt
the system: task scheduling and remapping, and power mode
transitioning.
3.7.1 Through the Scheduler
The subject of multicore, real-time, energy-efficient schedul-
ing and mapping of UD components has been thoroughly
discussed in previous works [12–14, 21], so a discussion about
its design will not be replicated here. However, there is
one important aspect that must be recapped: its support
to opportunistic managers. Adaptation managers can regis-
ter themselves within the scheduler to perform speculative,
opportunistic actions whenever a CPU becomes idle. Regis-
tered actions can be either interruptible and atomic. Atomic
actions are registered along with a Worst Case-Execution
Time (WCET) and are only performed if the interval until
the next job dispatching or timed event is big enough to
accommodate it in full. Interruptible actions are scheduled
as First-Come, First-Served (FCFS). Managers can interact
with the scheduler to request the migration of a task to
another core, to temporarily suspend a task, or to change a
core’s voltage and frequency.
3.7.2 Through the Power Manager
Power management is a major mechanism for components
to adapt their own behavior and for managers to adapt the
behavior of the system as a whole aiming at optimizing the
overall energy efficiency. The framework proposed here sup-
ports managers in the implementation of their policies as
it defines a common structure for the power management
aspects of components. Each component that directly en-
capsulates a physical device capable of operating in different
power modes, even if only on and off, defines the _power()
method. This method is not meant to be explicitly called
by the component clients and therefore is not part of the
component’s interface. It is used by the Energy_Aware aspect
as will be explained shortly. Four modes are globally defined
as shown in Figure 10. Mode FULL designates the component
high-performance operation, while LIGHT designates a mode
in which the whole functionality of the component is still
available, but its performance is being traded for energy. The
exact trade-off is not defined by the framework and additional
modes can be supported. For a component supporting DVFS,
LIGHT defines a throttled operation, but does not dictates
how much (the exact value is defined by the component or
by a manager using the sensing features described earlier in
this section). A component in SLEEP mode is suspended, but
its state is preserved, while a component in OFF is completely
powered off. Components not supporting a given mode can
simply ignore it.
A component implementing the _power() method can be
made energy-aware by the Energy_Aware aspect program,
which decorates the component with an Energized object as
depicted in Figure 11. An energy-aware component is there-
fore energized. After incorporating the features of Energized
through inheritance, Energy_Aware forwards power() invo-
cations to Energized, delegating it the final decision about
class Component
{
friend class Energy Aware<Component>;
private :
static void power(const Power Mode & mode) {
switch(mode) {
case FULL:
// Fully functional operation
break;
case LIGHT:
// Throttle operation
break;
case SLEEP:
// Go to sleep
break;
case OFF:
// Power off
break;
default :
// Do not for SAME, ENROLL, and DISMISS
break;
}
}
};
Figure 10: Method for _power() to be implemented by all
components that encapsulate a hardware device.
an eventual power mode change. The idea encapsulated in
this scheme is that changes might not always be possible.
For instance, if a low priority task demands a device that
is also being used by a higher priority task to be powered
off, then this request must certainly be ignored. It is up to
Energized to evaluate the requests (via the contest(mode)
method) and decide whether they can be accepted, thus the
insertion of Energized::mode(mode) in the path between
Energy_Aware::power() and Component::_power(). The
constant SAME is used to reject a power mode transition
request.
Besides keeping track of the current operating mode of
each energized component in the system, Energized also
maintains a list of the threads (tasks in real-time language)
using each component. At construction-time, the energized
component is registered by being inserted in the _devices
static hash table. The constructor of components not di-
rectly related to physical devices (i.e. non-energized com-
ponents), such as a communication socket or a file, invoke
the power(ENROLL) method for all aggregated components,
signalizing a dependency that propagates down to the en-
ergized components. A communication socket, for instance,
will propagate through the whole communication stack until
it reaches a network interface abstracted as an energized
component [15]. A file will propagate, whose power(ENROLL)
through the file system down to a disk energized component.
These energized components get a power(ENROLL) implemen-
tation from the framework, which registers the currently
running thread (Thread::self()), which created the top-
level component, as a client of those energized components
by inserting it into the component’s _threads list.
The information gathered by Energized can be used by
managers to implement predictors and other forms of decision
support algorithms.
4. RESULTS
We performed an evaluation of the adaptive components
infrastructure initially measuring the overhead of method
invocations and its impact on memory consumption. Next,
template<typename Component>
class Energy Aware: public Energized
{
protected:
Energy Aware() {}
public :
const Power Mode & power() { return Energized::mode(); }
void power(const Power Mode & mode) {
return Component:: power(Energized::mode(mode));
}
};
class Energized
{
public :
Energized(const Type Id & id) : id ( id ) , mode(OFF) {
devices . insert ( this ) ;
}
˜Energized() { devices .remove(this) ; }
const Power Mode & mode() { return mode; }
Power Mode mode(const Power Mode & mode) {
Power Mode old = mode;
switch(mode) {
case ENROLL: threads.insert(Thread:: self ()) ; break;
case DISMISS: threads.remove(Thread:: self ()) ; break;
default : mode = contest(mode); // Agree on a final mode
} component with two implements the overhead can reach
return ( mode == old) ? SAME : mode;
} which only the components explicitly used are linked to the
private :
Power Mode contest(Power Mode mode);
private :
Type Id id ;
Power Mode mode;
List <Thread> threads;
static Hash<Energized, COMPONENTS, Type Id> devices;
};
Figure 11: The Energy_Aware aspect responsible for export-
ing the component’s power mode switch methods and the
Energized that controls power mode switch.
we performed a case study using components commonly
found on Private Automatic Branch Exchange (PABX) tele-
phony systems. The adaptive components infrastructure was
prototyped on the Epos operating system communication
framework [11] which already implemented a large part of the
necessary building blocks. In all experiments, the hardware
platform was prototyped in ZedBoard, a development kit
based on Xilinx’s Zynq-7000, a SoC couples a reconfigurable
fabric with an ARM Cortex-A9 dual core CPU with several
peripherals integrated in a single die. The software was com-
piled with GCC 4.4.4 targeting the ARMv7 ISA using level 2
optimization enabled by GCC’s -O2 flag while the hardware
was prototyped using Xilinx’s Vivado 14.2 for RTL hard-
ware synthesis. Xilinx’s Vivado HLS 14.2 was used to obtain
RTL descriptions of the hardware flavors described using UD.
Synthesis constraints were adjusted on Vivado to minimize
circuit area considering a maximum frequency of operation
of 100 MHz. The CPU clock frequency is 666.666 MHz while
hardware flavors’ clock frequency is 100 MHz.
4.1 Adaptive Component Infrastructure
The execution time overhead due to the adaptive com-
ponents infrastructure was profiled for component with a
single method. The overhead is calculated as the difference
between the method execution time in a monomorphic com-
ponent and the execution on an adaptive component with
two flavors. The methods were invoked 10 000 times and the
total execution time was divided by 10 000 to calculate the
average. The time measurements were made using an oscillo-
scope and a GPIO pin to signal when the operation started
and ended. For an adaptive component, the overhead of two
flavors was 91.9 ns. It was also observed by inspecting the
assembly code for the same test program using an adaptive
component with one flavor and a monomorphic component
that the instructions generated for the method invocation
were equivalent.
Table 1 shows the infrastructure overhead in terms of
memory footprint. We measured the memory consumption
of the same application in the Epos operating system which
instantiated a component with a single method with one
integer parameter in three scenarios: 1) monomorphic; 2)
adaptive with a single flavor; 3) adaptive with two flavors.
The footprint corresponds to the total memory usage of the
application in each scenario while the overhead accounts for
the extra memory necessary for the adaptive components
infrastructure. Finally, impact is the relation between the
ratio between the overhead and the footprint. For an adaptive
14.93 %. Notice that Epos is a lean operating system in
application thus, the impact value is moderate as our test
application is quite simple.
4.2 Case Study: Adaptive PABX
Three components that integrate a digital PABX system
were implemented using the adaptive components infrastruc-
ture to evaluate our approach in an industrial application:
AES, ADPCM, and DTMF. The PABX consists of a commutation
matrix that switches connections among different input and
output data channels connected tone generators, tone de-
tectors, and to phone lines. AES implements the Advanced
Encryption Standard (AES) ciphering and inverse ciphering
used for secure communications. ADPCM is an Adaptive Dif-
ferential Pulse-Code Modulation (ADPCM) codec commonly
used in telephony networks that compresses 16 bit audio sam-
ples into 4 bit. Finally, DTMF is a Dual-Tone Multi-Frequency
(DTMF) detector that uses the Goertzel algorithm to verify if
a set of audio samples contains the set of frequencies that de-
fine to a tone. The ADPCM is a stateless component while the
AES, and the DTMF comprise the encryption key and the tone
samples buffer as their state respectively. Despite the sim-
plicity of the studied components, complex algorithms with
multiple flavors can encapsulated as adaptive components
as long as each flavor has the same interface and implement
the state handling functions. The reconfiguration process of
the studied components including when it is deployed, its
overhead, and latency were explored in a previous work [29].
Following UD techniques, a software and a hardware flavor
for each component were generated from the same unified C++
description [25]. In the software domain, the hardware flavor
is represented by its proxy that dispatches method invoca-
tions to the agent deployed in hardware which is responsible
for invoking the component functionality. Trade-offs regard-
ing execution time and hardware resources usage of the three
components were previously explored [23, 25]. Despite being
generally faster and consuming less energy than software
Table 1: Memory footprint comparison of an application using adaptive components in the Epos operating system with a
monomorphic component.
Footprint (byte) Overhead (byte) Impact (%)
Mutant Mutant Mutant Mutant Mutant Mutant
Section Monomorphic (one flavor) (two flavors) (one flavor) (two flavors) (one flavor) (two flavors)
Text 12 212 12 504 14 464 292 2252 2.34 15.57
Data 52 52 52 0 0 0 0
BSS 564 564 564 0 0 0 0
Total 12 828 13 120 15 080 292 2252 2.23 14.93

flavors, hardware flavors depend on finite FPGA resources Rec Rec

which might be already allocated for other components. In node node
Rec Rec Rec Rec
such cases cases the policy for reconfiguration can be to use node node node node
hardware flavors whenever there are available resources.
For the experimental analysis and evaluation we used a Rec RTSNoC RTSNoC Rec
platform called EPOSSoC which presented in Figure 12. node Router Router node
The CPU nodes execute software flavors of components and
Rec Rec Rec Rec
the operating system that orchestrates hardware flavors de- node node node node
ployment. Software flavors run on the CPU node: a dual-core Rec
node
Cortex-A9 processor coupled with several peripherals execut-
ing the Epos operating system. Rec nodes are reconfigurable
partitions that might contain hardware flavors of compo- Bridge Debug and Trace
nents interconnected using a Real-Time Star Network-on-
I2C FPU DSP FPU DSP
Chip (RTSNoC) [4] based scheme. A bus-based interconnect
was discarded as it is not the most suitable choice for more PCAP ARM Cortex-A9 ARM Cortex-A9
heterogeneous designs in which hardware flavors play active GPIO L1 Cache L1 Cache
roles [7]. The RTSNoC consists of routers with a star topol- SPI L2 Cache
ogy that can be arranged to form a two dimensions mesh.
USB SMP Timers
Each router has eight bi-directional channels that can be Scratch Pad
connected to cores or channels of other routers. Moreover, UART DMA IC
the rec nodes are connected to RTSNoC routers ports and
one of the RTSNoC routers ports is connected to the CPU AXI interconnect
node through an AXI bridge.
Table 2 gathers the FPGA resources used by each ele-
ment in the EPOSSoC. The resource utilization of each Flash DRAM
component’s hardware flavors comprises the component func- Figure 12: EPOSSoC block diagram. CPU, and rec nodes
tionality and the infrastructure necessary to communicate are interconnected by RTSNoC routers.
with software comprised in its agent. The area is estimated
as the arithmetic mean of the amount of each particular re-
source, weighted by its total amount available on the target
detect(), the method responsible for analyzing if a tone is
device.
found in a buffer with 700 samples and returning it, was
Table 2: Hardware resources utilisation for the EPOSSoC profiled. The methods were repeated 10 000 times and the
in the XC7Z020 SoC. total execution time was divided by 10 000 to calculate the
average execution time. The time measurements were made
Flip-flop LUT Memory Area (%) using an oscilloscope and a GPIO pin to signal when the
operation started and ended. The results are presented in
RTSNoC 562 855 0 0.70
Figure 13 and account for the method execution time for
AES 1576 1595 6 2.92 an adaptive component with two, and one flavors and the
ADPCM 519 642 1 0.80 component with a monomorphic flavor.
DTMF 646 368 1 0.66 Despite the virtual method call in adaptive components
Available 106 400 53 200 140 100.00 with two flavors, the total execution in some cases does not
suffer a noticeable increase as the monomorphic method ex-
ecution time is much bigger that the virtual function call
The execution time of both hardware and software flavors overhead. Nevertheless, for methods with smaller execution
of the AES performing the encrypt() and decrypt() methods times, the overhead of being used by an adaptive component
were profiled. encrypt() performs the direct AES cipher with two flavors translates in an relatively large increase in
on a 128 bit block stored on 16 B while decrypt() performs the total execution time. For instance, the software flavor
the inverse operation. As for the ADPCM, both encode() and of ADPCM::decode() which is a fast compared to others eval-
decode() methods used to compress and decompress a 16 bit uated (0.86 µs) suffers an increase of 22 % on its execution
audio sample respectively were profiled. Finally, DTMF’s time compared to the method execution on a monomorphic
 1.22
Normalized execution time

1.2
1.13

1.13

1.12

1.05
1.03

1.03
1.2

1.02

1.02
1.01

1.01
1
1
1

1
1

1
1

1
1

1
1

1
1
1

1
1
0.8
0.6
0.4
0.2
0
DTMF DTMF ADPCM ADPCM ADPCM ADPCM AES AES AES AES
detect() detect() decode() decode() encode() encode() decrypt() decrypt() encrypt() encrypt()
(hardware) (software) (hardware) (software) (software) (hardware) (hardware) (software) (hardware) (software)

Monomorphic Mutant with one flavor Mutant with two flavors

Figure 13: Normalized execution time for methods member of components with a hardware and a software flavor.

component. On the other hand, a slower method as the sensors specially PMUs.
hardware flavor of AES::decrypt() (4008.00 µs) has a barely
noticeable increase when deployed on a component with two 6. REFERENCES
flavors. [1] N. Abel. Design and implementation of an
Notice that the software flavor of AES::decrypt() when object-oriented framework for dynamic partial
deployed on an adaptive component with a single flavor reconfiguration. In Proc. International Conference on
is slower than on an adaptive component with two flavors. Field Programmable Logic and Applications, pages
Despite being visible in the assembly code generated by the 240–243, Aug. 2010.
compiler that a virtual function call is performed on the [2] J. Ansel, C. Chan, Y. L. Wong, M. Olszewski, Q. Zhao,
latter case implying that a larger number of instructions is A. Edelman, and S. Amarasinghe. PetaBricks: A
executed, we attribute the anomaly to a possible latency language and compiler for algorithmic choice.
hiding mechanism in the Cortex-A9 CPU which employs an SIGPLAN Notices, 44:38–49, 2009.
out-of-order speculative issue superscalar execution 8-stage
[3] W. Baek and T. M. Chilimbi. Green: a framework for
pipeline.
supporting energy-conscious programming using
controlled approximation. SIGPLAN Notices,
5. CONCLUSION 45:198–209, June 2010.
[4] M. D. Berejuck and A. A. Fröhlich. Evaluation of
In this work we proposed a framework for adaptive compo- silicon consumption for a connectionless
nents that can be reconfigured during run-time while keeping network-on-chip. International Journal of Advanced
the same interface. While the syntax and semantics of the in-
Studies in Computer Science and Engineering,
terface are preserved across the different versions, the system 3(11):1–11, 2014.
may at any time pick any of the versions that is better suited
[5] D. Cemin, M. Götz, and C. E. Pereira. Dynamically
for the current execution context. Moreover, task remapping
reconfigurable hardware/software mobile agents. Design
and power mode transition were presented as adaptation
Automation for Embedded Systems, 18(1-2):39–60, 2014.
mechanisms. The framework also supports sensing using
event based notification in which components can leverage [6] K. Czarnecki and U. W. Eisenecker. Generative
sensor data for decision making. Programming: Methods, Tools, and Applications. ACM
Three adaptive components that integrate a PABX were Press/Addison-Wesley Publishing Co., 2000.
evaluated: AES, ADPCM, and DTMF. The execution time of mul- [7] G. De Micheli, C. Seiculescu, S. Murali, L. Benini,
tiple methods of the adaptive components were profiled and F. Angiolini, and A. Pullini. Networks on chips: from
the application size of an application with adaptive compo- research to products. In Proc. Design Automation
nents were measured. Results show that when compared Conference, pages 300–305, 2010.
with their equivalent monomorphic versions, for most cases [8] B. Donyanavard, T. Mück, S. Sarma, and N. Dutt.
the adaptive component presents a small relative memory SPARTA: Runtime task allocation for energy efficient
usage footprint and time overhead on method invocation. heterogeneous many-cores. In Proc. International
This work focus on providing the infrastructure neces- Conference on Hardware/Software Codesign and System
sary for transparently deploying run-time reconfiguration Synthesis, pages 27:1–27:10, 2016.
for computing systems willing to exploit the variations in [9] H. Falaki. Automating Personalized Battery
their environment and adapt to unpredictable application Management on Smartphones. PhD thesis, UCLA,
requirements. We are currently working on general guidelines 2012.
to define when to reconfigure the system or even which is [10] P. Fonseca, R. Rodrigues, and B. B. Brandenburg. SKI:
the best reaction for a particular set of conditions based Exposing kernel concurrency bugs through systematic
on machine learning techniques exploring multiple types of schedule exploration. In Proc. USENIX Symposium on
 Operating Systems Design and Implementation, pages
415–431, 2014.
[11] A. A. Fröhlich. Application-Oriented Operating Systems.
Number 17 in GMD Research Series. GMD -
Forschungszentrum Informationstechnik, Aug. 2001.
[12] G. Gracioli. Real-Time Operating System Support for
Multicore Applications. PhD thesis, Federal University
of Santa Catarina, 2014.
[13] G. Gracioli and A. A. Fröhlich. On the design and
evaluation of a real-time operating system for
cache-coherent multicore architectures. SIGOPS Oper.
Syst. Rev., 49(2):2–16, Jan. 2016.
[14] G. Gracioli, A. Fröhlich, R. Pellizzoni, and
S. Fischmeister. Implementation and evaluation of
global and partitioned scheduling in a real-time OS.
Real-Time Systems, 49(6), 2013.
[15] A. J. Hoeller, L. F. Wanner, and A. A. Fröhlich. A
hierarchical approach for power management on mobile
embedded systems. In Proc. Conference on Distributed
and Parallel Embedded Systems, pages 265–274, Oct.
2006.
[16] H. Hoffmann, S. Sidiroglou, M. Carbin, S. Misailovic,
A. Agarwal, and M. Rinard. Dynamic knobs for
responsive power-aware computing. SIGARCH
Computer Architecture News, 39:199–212, 2011.
[17] A. Lachenmann, P. J. Marrón, D. Minder, and
K. Rothermel. Meeting lifetime goals with energy levels.
In Proc. International Conference on Embedded
Networked Sensor Systems, 2007.
[18] Y. Li, Z. Jia, S. Xie, and F. Liu. Dynamically
reconfigurable hardware with a novel scheduling
strategy in energy-harvesting sensor networks. IEEE
Sensors Journal, 13(5):2032–2038, May 2013.
[19] E. Lubbers and M. Platzner. ReconOS: Multithreaded
programming for reconfigurable computers. ACM
Transactions on Embedded Computing Systems,
9(1):8:1–8:33, Oct. 2009.
[20] M. K. Ludwich and A. A. Frohlich. Proper handling of
interrupts in cyber-physical systems. In Proc.
International Symposium on Rapid System Prototyping,
pages 83–89, Oct. 2015.
[21] H. Marcondes and A. A. Fröhlich. Analysis,
Architectures and Modelling of Embedded Systems:
Proc. IFIP International Embedded Systems
Symposium, chapter A Hybrid Hardware and Software
Component Architecture for Embedded System Design,
pages 259–270. 2009.
[22] V. M. G. Martins, P. R. C. Villa, H. C. C. Neto, and
E. A. Bezerra. A TMR strategy with enhanced
dependability features based on a partial
reconfiguration flow. In Proc. IEEE Computer Society
Annual Symposium on VLSI, pages 161–166, July 2015.
[23] R. S. Meurer, T. R. Mück, and A. A. Fröhlich. An
implementation of the AES cipher using HLS. In Proc.
Brazilian Symposium on Computing Systems
Engineering, pages 113–118, Dec. 2013.
[24] T. Mück and A. Fröhlich. Towards unified design of
hardware and software components using C++. IEEE
Transactions on Computers, 63(11):2880–2893, Nov.
2013.
[25] T. R. Mück and A. A. Fröhlich. Towards unified design
of hardware and software components using C++.
IEEE Transactions on Computers, (11):2880–2893, Nov.
2014.
[26] K. Ostrowski, K. Birman, D. Dolev, and J. H. Ahnn.
Programming with live distributed objects. In Proc.
European Conference on Object-Oriented Programming,
pages 463–489, 2008.
[27] A. Pant, P. Gupta, and M. van der Schaar. AppAdapt:
Opportunistic application adaptation in presence of
hardware variation. IEEE Transactions on Very Large
Scale Integration Systems, 20(11):1986–1996, Nov. 2012.
[28] A. Rahimi, D. Cesarini, A. Marongiu, R. K. Gupta,
and L. Benini. Task scheduling strategies to mitigate
hardware variability in embedded shared memory
clusters. In Proc. Design Automation Conference, pages
152:1–152:6, 2015.
[29] J. G. Reis, A. A. Fröhlich, and L. Wanner. A
framework for dynamic real-time reconfiguration. In
Proc. Euromicro Conference on Digital System Design
(DSD’15), pages 255–258, Aug. 2015.
[30] J. G. Reis, L. F. Wanner, and A. A. Fröhlich. X-ware:
Mutant computing substrates. In Proc. International
Symposium on Rapid System Prototyping, Oct. 2015.
[31] S. Sarma and N. Dutt. FPGA emulation and
prototyping of a cyberphysical-system-on-chip
(CPSoC). In Proc. International Symposium on Rapid
System Prototyping, pages 121–127, Oct. 2014.
[32] S. Sarma, N. Dutt, P. Gupta, N. Venkatasubramanian,
and A. Nicolau. Cyberphysical-system-on-chip
(CPSoC): A self-aware MPSoC paradigm with
cross-layer virtual sensing and actuation. In Proc. of
Design Automation and Test in Europe, 2015.
[33] J. Sorber, A. Kostadinov, M. Garber, M. Brennan,
M. D. Corner, and E. D. Berger. Eon: a language and
runtime system for perpetual systems. In Proc.
International Conference on Embedded Networked
Sensor Systems, 2007.
[34] B. Sprunt. The basics of performance-monitoring
hardware. IEEE Micro, 22(4):64–71, July 2002.
[35] M. B. Taylor. Is dark silicon useful? harnessing the
four horsemen of the coming dark silicon apocalypse. In
Proc. Design Automation Conference, pages 1131–1136,
2012.
[36] M. J. Voss and R. Eigemann. High-level adaptive
program optimization with ADAPT. SIGPLAN
Notices, 36(7):93–102, June 2001.
[37] L. Wanner and M. Srivastava. ViRUS: Virtual function
replacement under stress. In Proc. Workshop on
Power-Aware Computing and Systems. USENIX, 2014.