JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Fault Tolerant Embedded System Co-design
Anil Kumar, Shampa Chakraverty
Abstract: In this paper we develop a Co-design methodology for generating gracefully degrading multiprocessor architectures
that fulfill the dual objectives of achieving real-time performance as well as ensuring high levels of system availability at
acceptable cost.
Index Terms— Reliability and Availability, Design exploration, Multiprocessor Architecture.
——————————  ——————————
1 INTRODUCTION
M ODERN embedded systems are endowed with
highly complex functionality and exhibit unique
qualitative characteristics such as high speed, low
power and high reliability. As large numbers of these
systems are being deployed in varied and often harsh
environments, one of the biggest challenges faced by de-
signers is to ensure fault-tolerant operation.
All parts of these systems, viz hardware components,
software tasks and communication links are susceptible
to failure. Hardware faults may be induced by several
factors beyond our control such as the inherent failure
rate of components, aging and environmental stresses [1].
In addition to hardware faults, software faults may creep
in due to poor software design, mismatch between soft-
ware and hardware interfaces and due to logical condi-
tions such as deadlocks and live locks.
Faults may be permanent, intermittent or transient in
nature. A permanent fault is continuous and stable in
nature and usually causes the system to malfunction.
Most common permanent faults are stuck-at faults, bridg-
ing faults and delay faults. Intermittent faults recur spo-
radically due to unstable hardware or varying software
states. A transient fault appears for a brief period after
which the system apparently comes back to its normal
state.
Whatever the cause of a fault, it invariably impacts the
system operation adversely. If the impact is immediately
visible, the system may have to be either shut down com-
pletely or the affected parts may need to be isolated for
fault diagnosis and repairs. The system remains fully or
partially unavailable during this period. Even more dan-
gerous is the situation where the fault is hidden or
masked and there is no apparent indication that it has
occurred. Transient and intermittent faults present a far
greater hazard because if they are not detected during
system operation, they may simply go unnoticed. The
————————————————
 Anil Kumar is a PHD candidate at Delhi University, India; he is with the
Patni Americas Inc. 1626 9th st apt 102, white Bear Lake, MN, 55110,
USA.
 Dr. SHAMPA CHAKRAVERTY is with the Division of Computer Engi-
neering NSIT, Sector - 3, Dwarka, New Delhi, India
132
system enters an unsafe state and may produce erroneous
results in which case it is unavailable for all practical
purposes. Even if correct results are produced, an unde-
tected fault is liable to spread to larger parts of the sys-
tem, ultimately rendering it inoperable.
In order to divide the work among specialized proces-
sors and to fulfill the requisite qualitative requirements,
these systems are often knit into a distributed system of
multiple heterogeneous processors. For example, perfor-
mance-critical tasks can be implemented on high-speed,
high-reliability hardware platforms such as Application
Specific Integrated Circuits (ASICs). The dynamically
changing functions can be implemented on flexible, re-
configurable platforms provided by reconfigurable Field
Programmable Gate Arrays (rFPGAs). Non-critical tasks are
implemented cheaply in software using General Purpose
Processors (GPPs).
An added advantage of using multiple heterogeneous
processors is that the overall system availability can be
boosted by graceful degradability: as any individual
components fails, the system is not rendered totally use-
less but continues to provide reduced levels of services till
it is repaired.
Co-design is a methodology that explores the state
space of architectural solutions to determine how best the
workload of an application can be divided among various
resources to optimize multiple quality objectives. In terms
of reliability and availability, the key is to optimally allo-
cate the available resources so that the system continues
to provide those services that the user perceives as most
important under different functional states.
We develop a fault tolerant Co-design framework that
provides following capabilities to the designer:
1) Collection of reliability and availability require-
ments as early as possible so that the design process
can be tailored accordingly.
2) Perform as late as possible technology dependent
choices so that the fault tolerance options can be ex-
plored.
3) Explore different design alternatives in the architec-
tural design space to identify a solution suitable to
maximize system reliability and to reduce costs
while maintaining the system performance;
4) Reduce the system design time by avoiding expen-
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 133

sive rework. cated on otherwise idle resources to achieve high availa-

5) Incorporate user interaction to exploit the user and
designer experience at system level, so that the user
can directly specify the level of service availability
importance at different functional states.
The rest of the paper is organized as follows. Section 2
outlines prior work in the area. Section 3 describes the
Co-design flow for fault-tolerance. Section 4 presents the
implementation and results of proposed approach. We
conclude the paper in Sect. 7.
2 BACKGROUND
Redundancy is the foundation of fault tolerance.
Hardware systems employ hardware redundancy at mul-
tiple levels, such as the processing unit, circuit, communi-
cation and memory [2] and fault-tolerant software sys-
bility.
Recently Israr et al [9]suggested Permanent/Transient
error Decision Diagrams and algorithms for the genera-
tion of system implementation sets which feature maxi-
mum reliability at minimal costs in terms of redundant
resources. This approach is built on the assumption that
hard error will occur only if the system is offline.
In this paper we develop users’ perceived availability expec-
tations driven design exploration approaches.
System Specifications / formal

Specification Refinement
tems employ redundancy at multiple levels such as Task, Resource
Library of
instruction and data replication [3]. These hardware only
and software only fault tolerance approaches have their

Architecture Refinement
own advantages and disadvantages. Fault tolerant Co-
design is employed to get optimum benefit from both.
Some recent works have shown the viability of this hybr-
id strategy. The work in [4] called Co-synthesis of Fault- Library based Design space exploration
Tolerant Architectures (COFTA) employs cluster based
fault tolerance approach to maximize reliability and
availability. Tasks are clustered on the basis of error Comp. - Module Alloca- Comm.
transparency and fault detection latency. The co- architec- tion architecture
synthesis algorithm uses assertion and duplicate-and- ture explo- - Task Scheduling exploration
compare tasks for architecture construction while mak- ration - Cost estimation
ing sure that processing elements capacity is not ex-
ceeded. Their system specification in the form of a task
graph considers only data dependencies. The average Co-Simulation
cost increase due to their fault-tolerant synthesis is al-
most 60% compared to a system without fault-tolerant Hardware Interfaces Software
features. The addition of duplicate tasks and resources
leads to increased system cost.
Bolchini et al. [5][6] proposed a two step a Co-design Co-verification and Testing
framework for fault tolerance. The fault tolerance con-
straints are introduced in the specification at systems lev-
el so that whole Co-design process may also be driven by
the fault tolerance requirements. During first step of de-
sign algorithm constraints like area, power, cost, etc are
addressed. In the second step, reliability of critical tasks is
increased and the factors like Fault coverage, area over-
head, detect latency and performance degradation is Figure 1 : Co-design Flow
looked. However, this design approach does not support
time masking of transient errors.
3 FAULT TOLERANT CO-DESIGN FRAMEWORK
A reliability-centric co-design framework discussed in
[7][8] tries to maximize reliability while meeting area and Detailed Hardware Software Co-design is the synergetic
performance constraints. The most reliable design is se- design of both software and hardware of a computing
lected among several available alternatives; it involves system targeting a specific application. HW/SW Co-
binding conditional data flow graph tasks onto the re- design addresses the problem of the increased complexity
sources and performs a scheduling task. And then it of embedded systems by raising the level of abstraction.
gradually lowers the reliability of the design until the It is different from behavior synthesis; behavior synthesis
specified performance and area bounds are met, which maps an algorithm into ASICs, while Co-design maps a
involves resource exchange with a smaller or faster, but high-level abstract specification model of an entire system
less reliable resource. This approach allows only one ob- onto target architecture [12]. The Co-design framework is
jective (reliability) to be optimized while area and per- the ideal place where the designer validates the system
formance remains constraint. The critical tasks are dupli- functionality and evaluates different trade off alternatives
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
before proceeding with the low-level phase of the design
where automated tools perform the synthesis and the
integration between the parts is performed before the
final low-level Co-verification. The Figure 1 illustrates the
Co-design flow. We develop a four phase Top-down Co-
design methodology for fault tolerant system design.
1. Requirement Specification and Analysis
2. Library Based Design Exploration
3. Co-Simulation
4. Co-Verification.
3.1 Co-Specification and Analysis
The system requirements and specification phase in-
volves multiple iterations of acquiring the user’s require-
ments, converting them to formal specifications and scru-
tinizing these specifications with formal verification me-
thods. It requires repeated interaction between user and
designer so as to finalize a set of desired qualitative me-
trics along side functional specifications for the given ap-
plication.
There are no formal languages currently available that
can fully describe system functionality and requirements.
So, initially a natural-language requirements document is
written to capture this information.
System specification is a formal description of the
functional as well as the global qualitative (sometimes
referred to as non-functional) requirements of the target
application. Functional specifications describe the com-
plete behavior of the system that is expected by the user.
Non-functional specifications are the restrictions or con-
straints like deadlines, area, power, reliability, availabili-
ty, maintainability, costs, risks, etc. Even though the im-
plementation platform (via hardware or software) should
not be considered at this stage, adequate attention to the
qualitative requirements is paramount to the success of
the Co-design process. Traditionally, software develop-
ment followed the deployment of the hardware platform.
Due to this, qualitative requirements were somewhat ig-
nored in comparison with the conceptual functional re-
quirements. However, in the Co-design methodology, the
software and hardware development takes place concur-
rently and in a mutually synergetic manner. The qualita-
tive requirements primarily guide the decision process of
choosing from the plethora of implementation alterna-
tives that are available. Therefore, the application-specific
quality-metrics must be unambiguously specified at this
early stage to avoid costly errors uncovered at a later
stage.
For high availability applications, the end user and the
system designer must concur on factors such as:
1. Fault types: The different types of faults that can the
system must be protected against. Given the huge
combination of possible faults as well as the complex-
ity of VLSI circuits, it is virtually impossible to pro-
tect a system against all of them. Therefore, one must
cull out the set of most probable hardware and soft-
ware faults that can affect the system and clearly spell
out realistic fault assumptions.
2. Fault sequences: The maximum number and se-
134
quences of different types of faults that can be tole-
rated. The designer must fix a limit to the maximum
length of a fault sequence. It is reasonable to assume
that faults occur one at a time and unless a faulty unit
is repaired, the new fault will not manifest itself.
This assumption is based on the fact that failure rates
of components are far lower than repair rates. For ex-
ample, a processor may fail typically once in a year
whereas it can be repaired or replaced within hours.
3. Transparency requirements: in order to provide for
debug ability and testability of the system, errors
must be visible at the primary outputs. Co-design of-
ten entails Systems-on-a-Chip design wherein IP
cores from different vendors are integrated. It is a
challenge to test the entire system in an integrated
manner. Therefore the interoperability and testability
standards should be clearly specified at the outset.
One can then justify procurement of cores that have
built-in self-testability features allowing offline test-
ing with a fault-coverage of nearly 100%.
4. Criticality specifications: The availability require-
ments of critical tasks as well as non-critical tasks
must be specified. This would be useful in identifying
tasks in the critical path that should be equipped with
online fault detection and recovery.
5. User’s preferences: Availability is a highly user-
sensitive requirement. We underline the need for al-
lowing the user to specify his/her own perspective
on what is important and what is not during the co-
specification stage. In [14], the authors propose a us-
er-driven co-synthesis mechanism that assigns user-
specified Importance-of-Availability weights to the
range of possible functional states in a gracefully de-
grading system.
The functional specifications can be obtained in the
form of a Task Flow Graph of the application or through a
behavioral description language such as VHDL. We use
Conditional Task Precedence Graph (CTFG) to model the
system specification [13].
A typical real-time application repeatedly executes a
set of tasks in a periodic or aperiodic fashion, and is time-
bound for execution of the entire set of tasks. There is a
specific order in which tasks need to be executed. We
model the application by means of an acyclic, partially
ordered CTPG. A CTPG is a pair (V, E); where V is a set
of vertices, and E is a set of edges between the vertices E
{( ni, ni) | {( ni, ni V}. The set of nodes V represent the
computation sub-tasks and the set of edges E represent
the communication sub-tasks that carry data from source
to sink tasks and also indicate the precedence constraints
between the computational tasks. Each computational
task has a granularity that embodies a tightly coupled
major sub-function of an application that can be imple-
mented on a single processing unit. The set T= V  E con-
tains all the sub-tasks. A set element is denoted in small
case {{( ni, ni…..}. . All edges have data volume weights
with Beta distribution parameters = {a,b,c,d}. The sets PI
and PO represent the set of primary input tasks and pri-
mary output tasks, respectively. A representative CTPG
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
is shown in Figure 2 (data volumes are omitted from the
graph to make the graph clearer).
Each computational task has a granularity that embo-
dies a tightly coupled major sub-function of an applica-
tion that can be implemented on a single processing unit.
The graph shows some AND, OR and MIXED nodes.
AND node computational task is activated only if all the
inputs are available. An AND node is depicted in the task
graph with all the fan-in paths braced by a single arc. OR
node tasks are activated by one or more inputs. An OR-
node is shown in the task graph in the normal way (with-
out any arc encircling the fan-in paths). MIXED nodes
are activated on the basis of some pre-sepcified condi-
tions. A MIXED node is depicted in the task graph with
all the fan-in paths braced by a double arc. The edge
weights represent random inter-task data transfer vo-
lumes for clarity edge weights omitted from the figure)
TA0=0 TA1=2 TA2=1 TA3=0
V0 V1 V2 V3
V4 V5 V6 V7
V9 V10
V11
DL3=35
Figure 2 : CTFG11
We adopt a stochastic timing model whereby the task
execution times, data volumes transferred between two
interacting tasks and the input data arrival times are tak-
en to be bounded random variables described by Beta
distributions. They are obtained beforehand by task pro-
filing and parameter estimation techniques such as chi-
squared estimation. Edge weights represent the parame-
ters of the data transfer volume distributions; lower limit
ll, upper limit ul and shape parameters  and  (omitted
in the figures for clarity). Inputs have random data arrival
times and outputs have fixed deadlines. The task graph is
characterized by a period T, within which the entire set of
tasks are invoked and completed.
3.2 Platform based Design space exploration
Design space exploration (also referred to as hardware
software co-synthesis in literature) makes use of the spe-
cifications obtained in the previous stage to initiate a sys-
tematic exploration of the state space of hardware-
software architectural solutions. The main motivation is
135
to utilize heterogeneous platforms such as general pur-
pose processors, ASICs and rFPGAs to implement the
functional as well as qualitative specifications [10] .
This approach provides the most time-economical co-
design process. A library of processing elements and
communication links is assumed to present. The library
contains a plethora of soft, firm or hard cores for hard-
ware platforms as well as a variety of software functions.
It also contains the technical specifications for each mod-
ule such as power dissipation, speed, tesestability fea-
tures, failure / repair rates, cost, self-error detecting ca-
pabilities and other relevant technical parameters of these
platforms.
Besides this technology library, there is a database of
alternative implementation details of each sub-task of the
application to be developed. This database includes task
execution times on each platform.
Platform based design exploration refers to these libra-
ries and the application specifications to conduct the fol-
lowing activities: hardware-software partitioning and
task graph modifications for fault tolerance, task alloca-
tion, and task scheduling and architecture optimization.
Let us see how the design exploration process can usher-
in availability considerations.
3.2.1 Partitioning and task graph modifications
Partitioning is a process of selecting appropriate
hardware and software platforms as well as communica-
tion links to support the full task set of the given applica-
tion. Since task feasibility is the first criterion for choosing
resources, the Co-design system first decides which tasks
need a fault tolerant implementation.
First, the time-criticality and availability-levels along
each path in the task graph (or task-flow) is evaluated
based on the deadline and availability specifications de-
termined for the primary outputs. The designer is now
involved in modifying existing tasks, adding new tasks
and creating additional data flows in order to provide for
fault tolerant operation.
If a particular path is not time critical, its tasks can be
assigned to recover through time redundant techniques.
In this case, multiple sequentially arranged iterations of a
task are added to the task graph. Paths having more re-
laxed deadlines but high availability requirements em-
ploy the certification trail method. In this case the second
audit tasks are added in series with an original task.
For paths with stringent deadlines and high availabili-
ty specifications, the contributing tasks have inherent self
error detection. Alternatively, an additional duplicate
task and a compare task are used to detect erroneous data
in the duplicate-and-compare strategy. For paths requir-
ing fault tolerant operation at all times with minimum
time overhead, passive or active replicate tasks need to be
added. N Modular Redundancy sub-units also require
special tasks such as a voter.
Besides tasks and data-flows, the application’s task
graph will also need nodes with special branching logic in
order to implement the semantics of fault-tolerant
processing. Note that recovery tasks execute conditionally
only when the system needs to reconfigure after failure.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
These conditional tasks are bypassed during normal op-
eration. Such If-then-else control flow or EXOR semantics
are incorporated within the task flow representation. In
combined passive-active replica, any of the available rep-
licate tasks may be invoked, implying ORed inputs. As
another example, the active replicate tasks in a Triple
Modular Redundancy system must be available simulta-
neously at the input of a voter task, expressing an AND-
logic.
Once the task flow is modified to include tasks and da-
ta flows that add fault tolerance levels, the process of se-
lecting suitable processors and links to support them can
be initiated.
3.2.2 Task allocation and binding constraints
This is the process of mapping the tasks onto computa-
tion and communication elements. This step determines
the hardware implementation platforms, the software
processors and the communication links that are actually
utilized for the target system. For fault-tolerant and high-
ly available architectures, components with sufficient le-
vels of redundancy and high-reliability components need
to be chosen.
It may be noted that the mappings of replicate tasks
are not independent of each other since they must be
mapped to different computation nodes. This introduces
an exclusive constraint. Other tasks may require an inclu-
sive constraint so that they are mapped to the same pro-
cessor. For example, an audit task in certification trail
must execute on the same processor as the main task.
Thus binding constraints must be satisfied while tasks are
allocated to processors.
3.2.3 Task scheduling
Task scheduling assigns start and completion times to
the tasks on their allocated processing units. The Co-
design system must employ fault-tolerant scheduling al-
gorithms. For example, the scheduler can optimally as-
sign recovery tasks such as roll-back during slacks pe-
riods. Active replicates must be scheduled so that their
outputs are available simultaneously to a voter task.
Tasks that share the same resource must execute sequen-
tially according to well-formulated priority criteria. Real
time applications primarily use soft firm or hard deadline
based scheduling policies. Secondary considerations such
as load balancing and power optimization also play a
role.
3.2.4 Cost estimation and architecture optimization
The crux of the design exploration process is to optimize
a multi-objective function. The multi-objective function
incorporates application-specific costs such as deadline-
miss-ratio, system availability and reliability, accuracy of
results and cost of realization. Since task allocation and
scheduling are NP-complete problems, probabilistic meta-
heuristics multi-objective algorithms such as genetic algo-
rithms, and Ant-colony-optimization can be employed to
traverse the state space with a view to optimizing all the
costs. It is desirable to finally obtain a range of architec-
tural solutions that offer a tradeoff between various quali-
ty factors. These alternative solutions can be further eva-
136
luated and can help the designer/user to refine the sys-
tem specifications. The cycle of specifications-design ex-
ploration can be repeated till the most desirable architec-
tural solution is generated.
3.3 Co-simulation
In this step, the hardware and software parts are imple-
mented. Hardware is synthesized in the form of layout
specifications in case of ASICs and as a bit-map stream
for FPGAs. Software functions are compiled into an ex-
ecutable code for their allocated processors. In the case of
ASIP-centric applications, a retargettable compiler must
be used since hardware and software development takes
place simultaneously. [11] Presents embedded architec-
ture description language for platform based co-design.
3.4 Co-Verification and Testing
After synthesis, all parasitics become known, allowing
a finer estimation of all timing parameters, power dissipa-
tion and silicon area consumed. Co-verification allows the
software executable to run on its designated platform
along with the remaining synthesized hardware. This
step requires the simultaneous verification of the synthe-
sized hardware and software components at different
levels of abstraction. In fact Co-verification includes vali-
dations that are performed at each step of the Co-design
process. The simulation environment usually supports
several bus encoding protocols so that designers can easi-
ly evaluate different design alternatives. Simulation or
emulation techniques can be employed to verify both
functionality and quality parameters.
If all performance specifications are met, the Co-design
of the target application is finalized. Otherwise, the
process loops back to the design exploration step in order
to refine the architecture or even to the system specifica-
tions stage to refine the specifications once again.
4. Results
The above Co-design methodology is implemented in
C++. We used a flexible fuzzy logic interface that allows
the user to specify rules that effectively capture the users’
perceived availability expectations under different work-
ing conditions. The design exploration is guided by these
users’ perceived availability expectations and deadline
meeting probabilities off the primary output tasks. A
multi-objective genetic algorithm is employed to explore
the design space with following objectives and con-
straints:
1. Maximize number of deadline.
2. The system remains available at steady-state and
users’ perceived availability expectations
3. The cost remains within the prescribed budget
and its realization is feasible.
The resultant architecture demonstrates that the tasks
and communication channels involved in producing us-
ers’ perceived critical services are allocated to most relia-
ble resources and replicated using space and time redun-
dancy.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 137

5. Conclusion
Earlier approaches to design fault tolerant systems
analyze the reliability and availability of a pre-existing
system and introduce redundancy geared towards fault
tolerance in critical parts of the system. Unfortunately,
this leads to suboptimal design as other qualitative objec-
tives are invariably compromised. In this article, we pre-
sented a Co-design flow that systematically incorporates
fault tolerance and availability considerations at par with
other objectives during each step of the Co-design flow,
from specifications to synthesis. This ensures that costly
design errors are detected and obviated at the very early
stages of system design.

REFERENCES
[1] R. Edwards, C. Dyer, and E. Normand, “Technical standard for atmos-
pheric radiation single event effects (SEE) on avionics electronics“, IEEE
Radiation Effects Data Workshop (REDW) , 2004.
[2] M. Gomaa, C. Scarbrough, T. Vjaykumar, and I. Pomeranz, “Transient-
fault recovery for chip multiprocessors”, IEEE MICRO, 23(6) Nov-Dec
2003.
[3] Goutam Kumar Saha, "Software based Fault Tolerance: a Survey",
ACM Ubiquity, Vol.7, No. 25, pp. 1-15, July 2006, ACM Press, USA.
[4] B. P. Dave, N. K. Jha, “COFTA: Hardware-Software Co-Synthesis of
Heterogeneous Distributed Embedded System for Low Overhead
Fault Tolerance”, IEEE Trans. on Computers, 1999, vol 48, no. 4, pp. 417-
441.
[5] C. Bolchini, L. Pomante, F. Salice, and D. Sciuto, “Reliability properties
assessment at system level: a co-design framework”, Proceedings of the
Seventh International On-Line Testing Workshop, pages 165–171, 2001.
[6] C. Bolchini, L. Pomante, F. Salice, and D. Sciuto, “A system level ap-
proach in designing dual-duplex fault tolerant embedded systems”,
Proceedings of the Eighth International On-Line Testing Workshop, pages 32–
36, 2002.
[7] Y. Xie, L. Li L et al., “Reliability aware cosynthesis for embedded sys-
tems, Proc. 15th conf. on application specific systems, architectures and proces-
sors (ASAP ’04), 2004.
[8] S. Tosun, N. Mansouri, E. Arvas, M. Kandemir, Y. Xie, “ Reliability-
Centric High-Level Synthesis”, Proceedings of Design Automation and Test
in Europe (DATE’05), IEEE, Munich, Germany, pp. 1258–1263, 2005.
[9] Adeel Israr and Sorin A. Huss, “ Specification and Design Considera-
tions for Reliable Embedded Systems”, Proceedings of the conference on
Design, automation and test in Europe, Pages: 1111-1116 ,2008
[10] Marcio F. da S. Oliveira, Eduardo W. Brião, Francisco A. Nascimento,
Flávio R. Wagner“, Model Driven Engineering for MPSoC Design
Space Exploration,” Proceedings of the 20th annual conference on Integrated
circuits and systems design, pp 81-86, 2007
[11] Juncao Li, Nicholas T. Pilkington, Fei Xie, Qiang Liu b., “ Embedded
architecture description language”, The Journal of Systems and Software 83
pp 235–252, 2010
[12] A. D. Pimentel, C. Erbas and S. Polstra. “A systematic approach to
exploring embedded system architectures at multiple abstraction le-
vels“, IEEE Trans. on comput. , vol. 55, no. 2, pp. 99-112, Feb. 2006.
[13] Michele Lombardi, Michela Milano, “Allocation and scheduling of Condi-
tional Task Graphs”, Artificial Intelligence, Volume 174 , Issue 7-8 , pp
500-529 , 2010.
[14] Shampa Chakraverty and Anil Kumar, “A rule-based availabili-
ty-driven cosynthesis scheme”, Design Automation for Embedded
Systems, Volume 11, Numbers 2-3, 193-222, 2007.