548 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO.
4, NOVEMBER 2010
A Cross-Domain Multiprocessor System-on-a-Chip
for Embedded Real-Time Systems
Roman Obermaisser, Hermann Kopetz, Life Fellow, IEEE, and Christian Paukovits
Abstract—GENESYS Multiprocessor System-on-a-Chip
(MPSoC) is the building block of a generic platform for the
component-based development of embedded real-time systems in
different domains, such as in automotive, aerospace, industrial
control, and consumer-electronic applications. The GENESYS
MPSoC offers a stable set of domain-independent core services
(e.g., common time, message-based communication, and config-
uration). On top of the core services, higher level services can be
implemented by domain-independent and domain-specific system
components that customize the platform to the needs of the specific
application domain. Through its cross-domain applicability, the
GENESYS MPSoC supports the wide reuse of components and
realizes the benefits of the economies of scale of the semiconductor
technology. Furthermore, the GENESYS MPSoC contributes
towards the solution of prevalent technological challenges such as
complexity management, robustness, and technology obsolescence.
This paper presents the GENESYS MPSoC and provides insights
from a prototype implementation, which demonstrates that such
a cross-domain MPSoC can be built with today’s technology.
Index Terms—Computer architecture, computer interfaces,
fault tolerance, multicore processing, real-time systems, robust-
ness, system-on-a-chip.
I. INTRODUCTION
D RIVEN by the dramatically increasing performance/price
ratio of the semiconductor industry, many mechanical,
hydraulic and electronic-analogue control systems have been
replaced by digital microelectronics over the past 20 years.
Embedded technologies are becoming dominant in many in-
dustries such as avionics, automotive, industrial control, the
medical sector and consumer electronics. This trend is likely
to continue due to the continuously increasing possibilities
offered by the advances of the semiconductor industry.
Historically, embedded systems have emerged in a tech-
nology-driven bottom-up fashion in many application domains
(e.g., automotive, industrial control, and consumer electronics)
[1], [2]. This trend has resulted in domain-specific procedures,
protocols (e.g., CAN in the automotive domain, Profibus in the
industrial control domain), standards and certification rules.
The resulting diversity and fragmentation of embedded system
Manuscript received October 30, 2009; revised March 26, 2010, June 08,
2010; accepted August 18, 2010. Date of publication September 13, 2010; date
of current version November 05, 2010. This work was supported in part by the
European research projects INDEXYS under the Grant Agreement ARTEMIS-
2008-1-100021 and ACROSS under the Grant Agreement ARTEMIS-2009-1-
100208. Paper no. TII-09-10-0278.
The authors are with the Vienna University of Technology, Vienna A-1040,
Austria (e-mail: romano@vmars.tuwien.ac.at).
Digital Object Identifier 10.1109/TII.2010.2071388
1551-3203/$26.00 © 2010 IEEE
technologies motivates a consolidation in order to avoid par-
allel developments and multiple “reinventions of the wheel” in
different industrial domains.
In particular, some fundamental challenges have been iden-
tified, which are common to many application domains in the
area of embedded systems [3].
• Cognitive complexity: One major challenge is the man-
agement of the ever-increasing cognitive effort needed
by a human engineer to understand embedded systems.
The increasing functionality in conjunction with the con-
straints that must be satisfied by embedded systems (e.g.,
dependability, timeliness, energy efficiency, and short
time-to-market) lead to an enormous growth in the com-
plexity of the design at the system level. This challenge
has also been identified in the International Roadmap on
Semiconductors 2007, which states that “the silicon and
system complexity challenges imply super-exponentially
increasing complexity of the design process” [4].
• Robustness: Another key challenge is the robustness of em-
bedded systems in the presence of transient and perma-
nent hardware faults, design faults, imprecise specifica-
tions, and accidental operational faults [3]. In particular,
technologies are required to tackle the significant increase
of transient failure rates, which go along with the shrinking
geometries, lower voltages, and higher frequencies of the
semiconductor industry [5].
• Energy efficiency: Energy efficiency of embedded systems
is of utmost concern, e.g., in the mass market of mobile
devices, to limit car-battery load in a car when the engine
is off or to attain a sustainable energy economy.
The GENESYS Multiprocessor System-on-a-Chip (MPSoC),
which is presented in this paper, is the building block of an em-
bedded system platform that addresses these challenges. The
GENESYS MPSoC exhibits cross-domain applicability. It has
been developed in the European research project GENESYS in
collaboration with experts from five embedded system domains
(i.e., automotive, avionics, industrial control, mobile systems,
consumer electronics).
The GENESYS MPSoC addresses the mentioned challenges
and provides a framework for customizing the domain-indepen-
dent chip to individual applications.
The main contributions of this paper are as follows.
• Definition of a domain-independent core in hardware: The
MPSoC provides core architectural services, which are the
result of discussions and convergence among industrial
partners from the five application domains. The core ar-
chitectural services provide a stable baseline for higher ar-
chitectural services and applications in these domains.
• Customization of the domain-independent MPSoC through
system components: In order to customize the MPSoC
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
for specific applications, it can be extended by system
components providing optional services on top of the core
services. The set of optional services is open and can be
extended.
• Architectural services addressing the technological chal-
lenges: Fundamental core and optional services supporting
complexity management and robustness are identified in
this paper.
• Mapping an automotive example application to a proto-
type of the MPSoC: A prototype of the introduced MPSoC
is used to implement an automotive example application
and provide information about performance and resource
requirements.
The GENESYS MPSoC leads to a significant reduction of
fragmentation in the area of embedded systems. By advancing
from domain-specific solutions towards a cross-domain
MPSoC, a significantly larger market for embedded system
technologies (e.g., semiconductor devices, embedded com-
ponents, software, and tools) emerges. A large market and
the resulting ability of exploiting the economies of scale is of
particular importance for the semiconductor industry where
the engineering costs associated with the design and tooling
of chips grows rapidly. According to the International Tech-
nology Roadmap for Semiconductors (ITRS) the production of
masks and exposure systems is becoming a bottleneck for the
development of chips with finer geometries [4]. For example,
consider the design investments in the Cell Broadband Engine
(CellBE) processor, which amount to 400 million USD [6]. The
cross-domain usability helps to amortize such nonrecurring
costs.
The paper is structured as follows. Section II provides an
overview of related work in the area of MPSoCs and system
architectures. An overview of the GENESYS MPSoC is the
topic of Section III. The stable set of core services is detailed
in Section IV. Section V is devoted to the optional services.
Section VI presents the prototype implementation and the
automotive example. This paper ends with a discussion in
Section VIII.
II. RELATED WORK
Several system architectures exist for specific application
domains (e.g., Automotive Open System Architecture (AU-
TOSAR) [7], Integrated Modular Avionics (IMA) [8], and
Network on Terminal Architecture (NoTA) [9]). Also, MP-
SoCs, and NoC architectures (e.g., CellBE [10], AEthereal [11],
Sonics [12], CoMPSoC [13], Nostrum [14], and Spidergon
[15]) have been developed with a focus on specific applications.
The major novelty of the presented GENESYS MPSoC archi-
tecture lies in its cross-domain applicability and, in particular,
its suitability for safety-critical applications. The domain-inde-
pendent core of the GENESYS MPSoC with its core architec-
tural services is the result of discussions among industrial part-
ners of five application domains. Additional capabilities of the
platform are realized by optional services on top of the core ser-
vices, thereby customizing the GENESYS MPSoC to specific
applications. The set of core architectural services is kept min-
imal and includes only those capabilities that cannot be intro-
duced through optional services, but are required as the founda-
tion for the addressed application domains. The small set of core
549
architectural services is kept simple and deterministic in order
to enable certification and the use of the GENESYS MPSoC in
safety-critical applications.
Furthermore, the introduced MPSoC addresses the chal-
lenges identified by the European embedded systems initiative
ARTEMIS [3]. The GENESYS MPSoC provides architectural
services for robustness (e.g., a trusted subsystem that performs
fault isolation, state restoration to enable the recovery from
transient faults). In order to facilitate complexity management,
the GENESYS MPSoC raises the level of abstraction at the
network interface of the Network-on-a-Chip (NoC).
The NoC of GENESYS is controlled by a TDMA scheme,
which can also be found in the AEthereal architecture [11], the
Sonics SiliconBackplane Network [12] and Nostrum [14] to
provide bandwidth and latency guarantees. However, these ar-
chitectures provide a shared memory abstraction to the attached
IP cores via a transaction-based master/slave protocol as used in
OCP [16] or AXI [17]. These protocols define low-level signals
like address signals, data signals, interrupt signals, reset signals
or clock signals which are typically found at the interfaces of
processors, memory subsystems, or bus bridges. In contrast, the
GENESYS MPSoC introduces system and application compo-
nents, which are self contained computational units (e.g., a pro-
cessor core with local memory) that provide their functionality
solely over application-level message-based interfaces.
III. OVERVIEW OF GENESYS MPSOC
The GENESYS MPSoC is designed for the component-based
development of embedded systems. A component is a self-con-
tained hardware/software unit that performs computations, is
aware of the progression of real-time, and interacts with its en-
vironment exclusively by the exchange of messages. A compo-
nent is a self-contained IP core, which is formed by the com-
ponent-hardware and the allocated software, the job. A compo-
nent is a replaceable part of a system that encapsulates design
and implementation and exposes four different message inter-
faces, which are detailed in Section III-E. We call the timed se-
quence of messages that a component exchanges across an in-
terface with its environment (e.g., at the network-on-chip) the
behavior of the component at that interface. The intended be-
havior is called the application service of the component. An
unintended behavior is called a component failure.
The GENESYS MPSoC provides a framework for the imple-
mentation of components and the emergence of global applica-
tion services, which come about by the interaction of the appli-
cation services of the components. An example of an emergence
in the automotive domain would be the Electronic Stability Pro-
gram (ESP), which computes control values for braking actua-
tion based on information from a diversity of sensors. In this
example, the prior application services of the components on
the GENESYS MPSoC can include an acceleration measure-
ment service provided by a sensor component, a braking actu-
ation service provided by an actuator component and a control
service for computing a braking actuation value by a controller
component.
As a foundation for the implementation of components, the
GENESYS MPSoC offers platform services with mature solu-
tions to generic problems (e.g., security) in order to simplify
550 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
Fig. 1. Examples of services in the waistline hierarchy.
the application development. In addition, the platform services
of the GENESYS MPSoC support the interaction and coordina-
tion of the components. Thereby, the platform services provide
the means for the emergence of the global application services
(like ESP) out of the application services of the components.
A. Waistline Structure of Services
In order to support cross-domain useability and an indepen-
dent development of platform services, the platform services of
the GENESYS MPSoC are structured in a waistline as shown in
Fig. 1. This waistline structuring of services is inspired by the
Internet, where the Internet Protocol (IP) provides the waist for
different communication technologies and protocols. Towards
the bottom, a variety of implementation choices is supported.
IP can be implemented on Ethernet networks, ATM networks,
different wireless protocols, etc. Towards the top, different re-
finements to higher protocols depending on the application re-
quirements occur. IP can be refined into UDP or TCP, thereafter
into HTTP, FTP, etc.
In a similar way, the structuring of the services of the
GENESYS MPSoC occurs. The core services represent a stable
waist with those capabilities that are required in all targeted
application domains (e.g., automotive, avionic, and consumer
electronics). Through the ability of being implemented space
and energy efficiently in hardware for a multitude of application
domains, the core services lay the foundation for exploiting
the economies of scale of the semiconductor industry. The
core services offer capabilities (i.e., time, communication,
configuration, and execution control) that are required as the
foundation for the construction of higher platform services and
application services. These core services and an explanation for
the rationale of their inclusion in the waist of the GENESYS
MPSoC will be given in Section IV.
Different underlying implementation options exist for each
of the core services. For example, the core communication
services can be realized using a switched Network-on-a-Chip
or a bus-based implementation. Implementation options for the
global time services include a clock distribution network and
distributed clock synchronization between the different clock
domains. Likewise, different realizations of the configuration
and execution control services exist including a general pur-
pose CPU (as used in the prototype in Section VI) or dedicated
hardware solutions. The possible variants increase towards the
bottom of the waist as indicated by the increasing width of the
trapezoidal shape.
In analogy, variability increases towards the waistline’s top
(formed by the application services). Platform services can be
successively refined and extended in order to construct more
powerful and specialized platform services.
We distinguish two types of platform services.
• Domain-independent optional services provide enhanced
capabilities to the users of the platform, so that function-
alities that are needed in many, but not all application do-
mains, are provided in a ready-to-use form. It is up to the
application developer to decide, which ones of these op-
tional services are to be included in a concrete application
built with the GENESYS MPSoC. The implementation of
these optional services uses the core services. Examples of
these services will be given in Section V.
• Domain-specific optional services are highly specialized
optional services of particular domains.
The reason for distinguishing the domain-independent and
domain-specific optional services lies in the cross-domain reuse.
The domain-independent optional services can be made avail-
able in component libraries in a ready to use form for many
different applications in multiple domains. In contrast, the do-
main-specific services are only of relevance for the respective
domain.
B. Trusted Subsystem and Application-Specific Subsystem
The core services are provided by the so-called trusted sub-
system of the GENESYS MPSoC (cf. Fig. 2). The trusted sub-
system consists of the following three architectural elements:
• Time-Triggered Network-on-a-Chip (TT-NoC): The
TT-NoC supports the exchange of messages with pre-
dictability, determinism and inherent fault isolation. The
transmission of messages occurs at predefined points
in time according to a time-triggered communication
schedule, thereby avoiding collisions and any need for
dynamic arbitration. Thus, the latency of a message on the
TT-NoC is known a priori and independent from all other
messages exchanges. This predictability is essential for
real-time applications, the implementation of fault-toler-
ance through active redundancy and certification. Different
implementations of the TT-NoC are available, such as
a bus-based implementation [18] and implementations
using a routed mesh [19].
• Communication Interfaces: The communication inter-
face acts as a guardian of the respective component. The
communication interface uses the knowledge about the
permitted temporal behavior to prevent temporal interfer-
ence between components. Messages are only sent at the
predefined points in time, which have been written by a
Trusted Resource Manager (TRM). Hence, the temporal
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
Fig. 2. GENESYS MPSoC.
failure of a component (e.g., babbling idiot) cannot affect
the message exchanges of other components.
• Trusted Resource Manager (TRM): The communication
interfaces must be configured to establish knowledge in
the interface about the permitted temporal behavior of the
component. The Trusted Resource Manager (TRM) per-
forms this configuration. A component cannot modify the
parameters of its communication interface, such as the in-
stants when a message is sent and how long a message
transmission may last. It is impossible for a faulty com-
ponent (caused by a hardware or software fault within that
component) to modify the communication schedule set by
the TRM.
The NoC, the communication interfaces and the TRM are
trusted, because all components build on these architectural ele-
ments. A failure of the trusted subsystem would have the poten-
tial of causing a global failure of the entire MPSoC. Therefore,
the trusted subsystem is kept simple (i.e., only inclusion of ab-
solutely required capabilities) in order to enable a rigid devel-
opment and validation. We assume that the trusted subsystem is
free of design faults.
Likewise, a physical fault affecting the trusted subsystem has
the potential to cause a global failure of the entire MPSoC. The
probability of such a fault depends on the chip area consumed
by the trusted subsystem, which is typically a small fraction of
the entire chip. However, from the perspective of safety-criti-
cality, a whole chip is assumed to fail with a probability of
FIT. Today’s technology does not support the manufacturing
of chips with failure rates low enough to meet the reliability
requirements of ultra-dependable systems (i.e., failure rate of
critical failures per hour [20]). Component failure rates
are usually in the order of to (e.g., [21] uses a large
statistical basis and reports 100 to 500 failures out of 1 Million
Electronic Control Units (ECUs) in 10 years) and ultra-depend-
able applications require the system as a whole to be more reli-
able than any one of its components. This can only be achieved
by utilizing fault-tolerant strategies that enable the continued
operation of the system in the presence of chip failures.
551
The optional platform services and the application services
are provided by components in the application-specific sub-
system of the GENESYS. A failure of a component (due to a
design fault or a physical fault) is contained by the trusted sub-
system in order to prevent the propagation to a global chip-wide
failure.
C. Component Types
From the point-of-view of service provision, GENESYS dis-
tinguishes between system components and application compo-
nents. A system component is a self-contained component that
provides some architectural service and can be considered to
form a part of the GENESYS architecture. System components
can be widely reused by different applications.
An application component is a component that implements
the specified application functionality. Application components
use the services of the available system components to reduce
the effort required to implement the application functionality.
An application designer is only concerned with the development
of application components.
It is one of the significant contributions of the GENESYS
MPSoC to eliminate the need for a complex monolithic central
operating system to control all resources of the platform. In the
GENESYS MPSoC many of the global operating system func-
tions are provided by a set of self-contained system components.
These system components map ideally into the IP-cores of the
MPSoC. If they become stable, they can be implemented in
hardware, thus significantly reducing energy consumption and
silicon area. Additionally, each component may have a small
local (possibly heterogeneous) operating system that manages
the local resources of the component and that is not visible at
the architectural level.
While this approach is already successfully used in the field
of distributed systems, the specific technological constraints of
an MPSoCs require new architectural solutions. The proposed
GENESYS MPSoC takes into consideration the unique hard-
ware properties, faults and threats of an MPSoC. In particular,
552 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
Fig. 3. Structure of a component.
the following assumptions are made about the GENESYS
MPSoC.
• The GENESYS MPSoC is internally structured into inde-
pendent fault-containment regions, where the trusted sub-
system forms one fault containment region and each com-
ponent forms its own fault containment region. All tem-
poral message errors of faulty components are contained
by the trusted subsystem.
• Fault containment regions within a chip communicate with
each other exclusively by unencrypted messages. It is as-
sumed that the physical construction of the MPSoC pre-
cludes that an intruder can eavesdrop the internal commu-
nication within the MPSoC.
• All messages that leave (or enter) the chip can be en-
crypted, if so desired. This encryption/decryption is
performed by a special system component, the security
component. If, for example, a secure boot is desired then
a security component must be present in the MPSoC to
encrypt/decrypt the boot messages.
• From the perspective of safety-criticality, a whole
GENESYS MPSoC may fail with a probability of FIT
(as indicated by typical field failure rates [21]). Safety-crit-
ical functions which must achieve a higher reliability (e.g.,
1 FIT, i.e., hours of operation) must be implemented
redundantly by deploying multiple MPSoCs, such that the
failure of any single MPSoC can be tolerated.
• The cost of communication bandwidth on a NoC is sig-
nificantly lower compared to an off-chip network. There-
fore, the exclusive reservation of conflict-free sending slots
for both periodic and sporadic message transmission is
possible.
D. Component Structure
A component is formed by loading a software image (i.e.,
the job) onto a hardware unit. From an architectural point-of-
view, the internal structure of the component is of no avail, pro-
vided the message interfaces of the component are well-speci-
fied. However, in order to make it easier to define these message
interfaces it is expedient to provide a model of the component-
internal structure, in particular of the software elements that
form a job.
We consider a job to be structured into a component-local
operating system, the middleware, and the application software
as outlined in Fig. 3. The middleware can be further partitioned
into the GENESYS Middleware (GEM) and application-spe-
cific middleware. The application-specific middleware is
peculiar to the implementation of a certain component and thus
outside the scope of this paper. The GENESYS Middleware
(GEM), on the other hand, is concerned with the provision
of the GENESYS architectural services to the application
software. The GEM can establish APIs for the application
software in order to use optional architectural services that are
provided in the system components. These APIs can hide the
message-based interaction with the system components.
For example, an external memory (cf. Section V) is an
optional service that is provided by a system component with a
local interface to an off-chip memory. Application components
can exploit this external memory service by interacting with
the respective system component through the core services. An
implementation of the external memory can use the following
interaction pattern: The application component sends a sporadic
message (cf. Section IV-B) with a request for a certain memory
page, which is in turn answered by the system component with
another sporadic message containing the requested memory
page. The GEM can hide this low-level interaction from the
application software. In the above example, the GEM can
provide a memory region to the application code, making the
difference between local memory in the application component
and external memory transparent to the application software.
Furthermore, the GEM can map the core and optional ser-
vices to APIs that are required by existing applications. For
example, avionic applications based on Integrated Modular
Avionics (IMA) can interact with the underlying platform
through the APplication EXecutive (APEX) as standardized in
ARINC 653 [22]. The mapping of the GENESYS architectural
services to APEX has been described in [23] in order to enable
the reuse of existing avionic applications. Likewise, the GEM
can establish the Run-Time Environment (RTE) [24] of the
AUTomotive Open System ARchitecture (AUTOSAR) in order
to support the execution of existing automotive application
software. The mapping of the GENESYS architectural services
to the AUTOSAR RTE is discussed in [25].
In addition to the establishments of APIs, the GEM can serve
for the implementation of optional architectural services. An
optional architectural service can either be implemented in a
system component (with APIs in the GEM of the application
components that exploit the service) or the optional service can
be fully implemented in the GEM. The latter implementation
choice can be advantageous for specific optional services be-
cause of performance constraints or due to the requirement of
physical proximity to the application code (e.g., certain fault-
tolerance or diagnostic services).
For example, the computation of end-to-end checksums for
the detection of communication faults on the TT-NoC should
occur in the GEM. If checksums were checked in a system com-
ponent, then a communication fault could affect the message in
between the application component and the system component
providing the checksum service.
Optional services in the GEM are offered across the com-
ponent LIF (see Section III-E) if they relate to the operational
aspects of a component and across the TII if they relate to
the meta-level aspects of a component, such as component
configuration.
E. Component Interfaces
In GENESYS, four types of message-based component inter-
faces are distinguished as depicted in Figs. 4 and 5. The rational
for distinguishing these four interfaces is a separation of con-
cerns as the users of each interface have a different role (e.g.,
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
Fig. 4. Component interfaces.
Fig. 5. Four component interfaces.
component implementor, system integrator and maintenance en-
gineer). The different roles cause significant differences in oper-
ational characteristics (e.g., uniform interface in the GENESYS
MPSoC versus plurality of communication technologies), and
the handling and visibility for the architectural elements (e.g.,
handled by application software or by the execution environ-
ment, visibility to other components).
1) The Linking Interface (LIF): The services of a compo-
nent are offered to the other components at its Linking Interface
(LIF). The LIF is thus the interface for the integration of compo-
nents. The LIF is message-based and provided through the core
communication services (cf. Section IV).
The LIF abstracts from the internal structure and implemen-
tation technology of a component. For example, the realization
of a component can be changed from a software-based imple-
mentation on a general purpose CPU to a dedicated hardware
implementation without any modification, neither in the value
domain nor in the time domain, of the LIF of the component.
Such an implementation change reduces the silicon area and can
improve the energy efficiency of a component by several orders
of magnitude [26] at the cost of reduced flexibility.
In GENESYS we distinguish between the operational and the
meta-level specification of a LIF [27]. The operational specifi-
cation covers the syntactic and temporal properties of the mes-
sages that are exchanged across this LIF. In addition to the struc-
ture of all input and output messages, the operational LIF speci-
fication should also contain a periodic ground state message that
contains information for the restart of a component at the next
restart instant. The operational specification must be precise and
formal and ensures the interoperability of components.
Information on how interfaces are specified in the presented
MPSoC using SystemC can be found in [28]. The interface spec-
ification starts with a structural model that partitions the overall
553
system into jobs that interact through message-based interfaces.
As part of the structural model, the timing, syntactic properties
and the state are captured. Subsequently, the structural model
is refined into a behavioral model that captures the production
of output messages from input messages, state, and the progres-
sion of time.
SystemC has been selected, because it leaves open specific
implementation decisions that should not be fixed yet in the in-
terface specification. For example, SystemC permits interface
specifications in such a way that jobs can be implemented ei-
ther in hardware or in software. Furthermore, SystemC supports
precise temporal specifications and models can be simulated.
To express the interface specifications, SystemC representations
of the structural elements of the proposed MPSoC architecture
have been devised (e.g., time-triggered communication chan-
nels) in [28].
2) The Technology Independent Interface (TII): The tech-
nology independent interface is used by the trusted subsystem
and by system components in order to perform operations
without involvement of the application software. The messages
that arrive at the TII have a direct effect on the hardware
(e.g., reset), the operating system (e.g., start a task), and the
middleware of the component, but they are not visible for the
application software. The TII is thus orthogonal to the LIF. This
strict separation of the application-specific message interfaces
(i.e., the LIF) from the system control interface of a component
(i.e., the TII) simplifies the application software and reduces
the overall complexity of a component.
For example, the trusted subsystem (cf. basic configuration
and execution control in Section IV) use the TII to configure
and reconfigure a component (e.g., assign the proper names to a
component and its input/output ports), to reset, start and restart
a component and to monitor and control the resource require-
ments (e.g., power, voltage, frequency) of a component during
run time, if so required. The trusted subsystem also assigns a
specific job to the programmable component hardware.
3) The Local Interfaces: The local interfaces establish a con-
nection between a component and its local environment, e.g., the
sensors and actuators in a process control system or the concrete
man-machine interface. In contrast to the LIF and the TII, the
local interfaces are not uniform in a GENESYS MPSoC (e.g.,
different physical layers, protocols). The local interfaces can be
realized via direct connections to sensors and actuators or via
fieldbuses (e.g., Controller Area Network (CAN) bus [29]). The
latter approach simplifies the installation—both from a logical
and a physical point-of-view—at the expense of increased la-
tency of sensory information and actuator control values.
The local interfaces are used by the implementor of a compo-
nent in order to provide the specified services at the LIF. From
554 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
the point-of-view of the LIF, only the timing and the meaning
of the information exchanged across a local interface is of rele-
vance, while the detailed structure, naming, and access mecha-
nisms of the local interface are intentionally left unspecified. A
modification of the local access mechanisms, e.g., the exchange
of direct I/O by a LIN fieldbus [30], will not have any effect on
the LIF specification, and consequently on the users of the LIF
specification, as long as the meaning and the timing of the rele-
vant data at the local interface are the same.
For example, consider a component that provides tempera-
ture measurements in an automotive application. The LIF spec-
ification of the component will cover the semantics of the local
interface (e.g., temperature at a certain location within the car)
and the timing (e.g., delay until a change of temperature is indi-
cated). However, the implementation technology for interacting
with the sensor is unspecified at the LIF (e.g., analogue input
with digital/analogue conversion, LIN fieldbus, ).
4) The Technology Dependent Interface (TDI): The TDI pro-
vides the means to look inside a component and to observe in-
ternal variables of a component (e.g., for debugging). The TDI
is intended for the person who has a deep understanding of the
component internals (e.g., a maintenance engineer or a valida-
tion engineers). The TDI is of no relevance for the user of the
LIF services of the component nor for the system engineer that
configures a component. The precise specification of the TDI
depends on the technology of the component implementation,
and will be different if the same functionality of a component
is realized by software running on a CPU, by an FPGA or by
an ASIC. An example for a realization of the TDI is a boundary
scan [31].
IV. CORE SERVICES OF THE TRUSTED SUBSYSTEM
The four core services are mandatory and thus part of any in-
stantiation of the GENESYS MPSoC. These four services repre-
sent capabilities that are universally important for all considered
application domains and absolutely necessary to build higher
services or to maintain the desired properties of the architecture.
The GENESYS MPSoC supports the construction of mixed
criticality systems, in which safety-critical components and non
safety-critical components coexist on one chip. Due to certifica-
tion requirements [32], [33], safety-critical components are typ-
ically kept simple with static preplanned schedules and no dy-
namic reconfiguration. In contrast, dynamic system capabilities
are effective in non safety-critical components in order to adapt
to varying resource availability and environmental conditions.
In order to support mixed criticality systems, the core services
of the GENESYS MPSoC must ensure fault containment and be
deterministic and simple. The core services ensure that a fault
of a non safety-critical system or application component cannot
affect the correct operation of the safety-critical components.
Hence, only the core service need to be considered in the cer-
tification of the safety-critical components, while the optional
services of the non safety-critical components can be abstracted
from.
In order to make the core services amenable to certification
and keep them deterministic and simple, the implementation of
powerful dynamic system capabilities in the GENESYS MPSoC
is partitioned into a small core service and a more intricate op-
tional service. Consider, for example a dynamic message sched-
uler, which must be part of any dynamic resource management.
Such a dynamic scheduler is not included in the core services.
However a much simpler checker that verifies the properties of
a schedule and ascertains that the constraints of a static safety-
critical schedule have not been violated by the dynamic sched-
uler is part of the core services.
A. Basic Time Services
In the GENESYS MPSoC, each component and the NoC can
reside in their own clock domains. The time-triggered NoC per-
forms clock synchronization in order to provide a common time
for all components despite the existence of multiple clock do-
mains. The common time allows the temporal coordination of
distributed activities (e.g., synchronized messages), as well as
to interrelate timestamps assigned at different components.
1) Common Time: The GENESYS common time service
provides to each component a local clock, which is globally syn-
chronized within the MPSoC. If the clock is read by a compo-
nent at a particular point in time, it is guaranteed that its value
can differ by at most one tick from the value that is read at any
other correct component at the same point in time. This property
is also known as the reasonableness of the common time ([34,
p. 52]), which states that the precision of the local clocks at the
components is lower than the granularity of the common time.
Optionally, the common time can also be synchronized with an
external time source (e.g., GPS). In this case, the accuracy de-
notes the maximum deviation of any local clock of the MPSoC
to the external reference time.
The main rational for the provision of a common time is the
ability for the temporal coordination of activities and the es-
tablishment of a deterministic communication infrastructure. A
system behaves deterministically if and only if, given a full set
of initial conditions (the initial state) at the initial instant, and
a sequence of future timed inputs, the outputs at any future in-
stant are entailed [35]. This determinism is achieved by pro-
viding the predictable time-triggered NoC. The time-triggered
NoC requires a common notion of time among all components
for assigning conflict-free sending slots to the components.
In addition to determinism and predictability, the time-trig-
gered operation of the NoC enabled by the common time base
results in a simpler and more energy efficiency interconnect, be-
cause there is no need for dynamic arbitration. The common
time also allows to minimize end-to-end latencies through tem-
poral alignment of computational of components and commu-
nication activities at the NoC. Furthermore, a relationship can
be established for timestamps assigned at different components
and timestamps can be used to determine the temporal accuracy
([34, p. 102]) of information from another component.
The proposed common time is opposed to Globally Asyn-
chronous Locally Synchronous (GALS) or solutions with a
single clock domain. The provision of a single clock signal for
an entire chip has become prohibitively expensive [36], e.g.,
because of clock skew and the integration of components with
different implementation technologies. GALS, on the other
hand, do not support the presented temporal coordination and
alignment.
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
The disadvantage of the common time base lies in the over-
head for clock distribution or clock synchronization.
2) Time Format: We can distinguish between two different
representations of time, the linear time representation and the
cyclic time representation. The linear time representation fol-
lows the arrow of time, starting at a defined starting point, the
epoch, and counting the number of seconds up to instant now
and beyond.
In the cyclic model of time, the continuum of time is por-
tioned into an infinite set of cycles. A cycle is a period of phys-
ical time between the repetitions of regular (equidistant) events.
A cycle is specified by the duration of its period and the po-
sition of its start, the cycle start phase relative to the common
time. Since many embedded systems exhibit a cyclic behavior
(e.g., control systems, signal processing systems, and multi-
media systems) the cyclic model of time is well suited to desig-
nate progress in these systems. The cyclic model of time is also
most appropriate for the description of the behavior of time-trig-
gered systems. In a time-triggered system, a cycle is associated
with every time-triggered process. Whenever the cycle-start in-
stant occurs, a control-signal is generated to start the time-trig-
gered process.
GENESYS restricts the duration of cycles such that all cycles
are in a harmonic relationship to each other. Every cycle must be
a power-of-two product of a smallest cycle, with the additional
restriction that the duration of one of the cycles must be exactly
the duration of the physical second. Hence, the GENESYS time
format is a binary format that counts full seconds in two arith-
metic and subdivides the second in fractions of two arithmetic.
These restrictions are introduced in order to simplify the inter-
leaving of cycles, the generation of cyclic schedules and the syn-
chronization of the activity of a system with an external time
reference. This time format has also been standardized by the
OMG [37].
The drawback of this restriction is that overhead can be in-
curred by mapping cycles to power-of-two products. A smaller
cycle and more communication and computational resources
might be used than actually required for a given application
(e.g., to ensure the stability of a control loop).
B. Basic Communication Services
The GENESYS MPSoC provides services for the communi-
cation among components: periodic message multicasting, spo-
radic message multicasting and primitive multicast streaming.
These three communication modes support all targeted types of
application. Periodic message multicasting is ideal for the ex-
change of state variables [34] in cyclic applications such as con-
trol loops. Sporadic message multicasting is effective for sig-
naling events (e.g., alarm event, error indication reported to a
diagnostic component). Streaming serves for the realization of
multimedia applications and the transfer of new job images to
components.
The reasons for the choice of message passing as the basic
interaction mechanism in the GENESYS MPSoC are as follows.
• Explicit timing. In contrast to shared memory abstrac-
tions, the timing of message exchanges is explicitly de-
fined and the need for separate synchronization is elimi-
555
nated [38]. In the presented MPSoC, each periodic mes-
sage possesses a period and phase with respect to the global
time base. The timing of sporadic messages and streaming
is characterized by a minimum message interarrival time.
This knowledge is essential in real-time systems in order to
perform a timing analysis of an application, to meet dead-
lines and to detect/contain failures (e.g., violation of min-
imum message interarrival time).
• Fault containment. A unidirectional message, which
is used in the presented MPSoC architecture, has one
sender component and one or more receiver components.
The knowledge about the sender identity is essential for
fault-containment and diagnosis (e.g., masquerading fail-
ures). In the temporal domain, the knowledge concerning
the timing (e.g., period of a message) enables the contain-
ment of temporal faults.
• Universality. Message passing is a universal model. Dif-
ferent interaction patterns, such as a shared memory, can
be realized on top of message passing [39].
Message passing as the basic interaction mechanism is in con-
trast to the shared memory model that is prevalent in today’s
MPSoCs. Shared memories typically result in temporal unpre-
dictability, since the access of components is not preplanned and
concurrent access needs to be resolved dynamically. Message
passing also eliminates the communication overhead and hard-
ware complexity of the coordination protocol needed for cache
coherence [40]. Memory hierarchies and coherence protocols
significantly contribute to temporal unpredictability [41].
As explained in [42] message passing is also superior to
shared memories in case of a high computation/communication
ratio, which is typical for embedded systems.
1) Periodic Exchange of Messages: The periodic message
exchange service, also called the time-triggered message service
sends a message at its period and phase, the start instant, from
one sending component to one or more receiving components,
i.e., this service provides multicast communication. The data
that is disseminated with this service is state information.
Messages are associated with ports. During establishment of
a port by the TRM, the configuration parameters are assigned to
a port, such as the period and phase of a time-triggered message,
the size of the message and the set of receivers of the message.
Before sending a message, the sender updates the state vari-
able associated with the respective port. The multicast of the
message is performed autonomously by the communication in-
frastructure at the previously configured period and phase. At
the receiver side the communication infrastructure overwrites
the state variable associated with the receiving port with the data
contained in the message.
Since the transmission of messages is triggered by the pro-
gression of the common time, this service relies on the avail-
ability of the common time service.
2) Sporadic Exchange of Messages: The sporadic message
exchange service, also called event-triggered message service,
supports the exchange of event-information at arbitrary instants
only constrained by a minimum interarrival time of events.
During normal operation this message service supports an
exactly once semantics, i.e., every message is delivered exactly
once.
556 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
The sending component places the message in the specified
event-triggered output port. An event-triggered output port in-
cludes an outgoing message queue that resides in the memory
space of the sender. As soon as the communication is ready to
accept the next message, it fetches the message from this queue
(consumable read) and transports the message to the receivers
that are associated with the sending port. The message transport
is realized via a time-triggered channel. As soon as the mes-
sage arrives at the receiver(s), it is placed in the input queue(s)
associated with the receiver’s ports. The size of the message
queues—outgoing queues at sending components as well as in-
coming queues at receiving components—is determined by the
respective component itself. If the message queue is already full
and the component tries to place a new message in the queue,
an error is reported via the TII.
Message reception is realized by retrieving a message from
the incoming message queue (consuming read operation). For
handling empty incoming message queues, the sporadic mes-
sage exchange service supports two types of read operations: If
non-blocking read is chosen, the read call returns instantly and
signals the caller that no message has been retrieved. If blocking
read is chosen, the read operation waits until a new message
arrives.
3) Primitive Multicast Streaming: The primitive multicast
streaming service can be utilized for the transmission of a se-
quence of variable-size data elements (e.g., frames in a video
stream) with corresponding temporal properties (e.g., average
data rate with bursts). Similar to the sporadic message exchange
service, this service uses queues at the sender and receiver side.
Queues compensate for irregular data rates that are typical for
streaming applications (e.g., MPEG4). For retrieving a data el-
ement out of the queue, a blocking and a non-blocking mode
of operation is supported. The primitive streaming service does
not exercise any flow-control from the receiver to the sender.
C. Basic Configuration Services
The basic configuration services are provided to load the jobs
to the available hardware units of the MPSoC, thus forming
the components of the MPSoC. In case of a static configura-
tion, the allocation of jobs to the hardware units maybe outside
the scope of architectural considerations—the jobs are already
permanently assigned to the hardware units (e.g., in case of an
ASIC implementation of a component, where the software is
part of the hardware). The basic configuration services are also
needed if a dynamic reconfiguration of an MPSoC is performed
by reassigning a job to a different hardware unit, because the
original hardware unit has failed.
Configuration capabilities are required for the initial config-
uration of programmable hardware and to support different en-
vironmental conditions (e.g., on ground versus airborne in an
avionic system), modifications of the computer system (e.g., ad-
dition of a component) and variable resource availability (e.g.,
low energy resources). Reconfiguration enables better resource
utilization, improved dependability, and the enabling of power/
energy aware system behavior.
The GENESYS MPSoC targets safety-critical applications,
non safety-critical applications, and mixed criticality systems
with both safety-critical and non safety-critical subsystems. Pri-
marily due to safety concerns, reconfiguration of safety-critical
systems is often reduced to selecting system-wide modes out of
statically defined scheduling tables, which impairs the flexibility
resource management, but provides good analyzability and de-
terminism. Certification standards such as DO-178B [32] in the
avionic domain provide recommendations for static resource al-
locations.
In order to support safety-critical applications, the mandatory
basic configuration services encompass only those capabilities,
which are indispensable for configuration and do not preclude
certification in safety-critical applications: a basic boot service,
an identification service and an inter-component channel config-
urator. In non safety-critical applications, configuration services
going beyond these basic capabilities can be realized as part of
the optional services.
• The basic boot service is the primitive configuration ser-
vice that assigns a job to a hardware unit of the MPSoC,
thus creating a component of the MPSoC. Every hardware
unit must have a priori established boot access ports for
the boot messages (i.e., access ports that are physically as-
sociated with the hardware) as part of their TII interface.
The boot protocol links an off-chip repository with the job
images (e.g., the development system) with the physical
runtime systems. By associating the logical names of jobs
with the physical names of hardware units, this service es-
tablishes a logical name-space such that the components of
the platform can be uniquely identified and addressed on
the basis of their role in the given application. The basic
boot service can be extended to a secure boot service by
optional security services.
• The identification service provides a unique identifier of
the chip. This identification is needed to inform the boot
service about the type of available hardware and the at-
tributes of the unit under consideration. In addition, it is
required to distinguish individual manufactured physical
units from each other. The implementation of the hardware
identification within the MPSoC must be tamper resistant,
i.e., it should be impossible to modify the unique chip iden-
tification without physically destroying the chip.
• The intercomponent channel configurator supports the
establishment, modification and removal of communica-
tion channels. The intercomponent channel configurator,
which is part of the TRM of the MPSoC, configures the
chip-local inter-component communication system (i.e.,
the TT-NoC and the communication interfaces of the
trusted subsystem) by establishing, naming, connecting,
and disconnecting the ports and communication channels
of the components of the MPSoC according to a time-trig-
gered communication schedule. Communication links to
the outside of the MPSoC are provided by system compo-
nents providing gateway services. Such a gateway system
component supports two interfaces, an inner interface to
the TT-NoC and an outer interface to the chip environment
(e.g., CAN, FlexRay). Viewed from the MPSoC, the inner
interface is a chip-level LIF, while the outer interface is
an (unspecified) local interface of the gateway system
component. The gateway system component connects
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
Fig. 6. Resource Management: (1) Generation. (2) Verification. (3) Adoption
of resource allocation.
the respective interfaces, performs a name translation
and resolves further property mismatches that may exist
between the MPSoC (inner interface) and the LIF to the
chip environment (outer interface).
In order to support the integration of components with different
criticality, the GENESYS MPSoC provides dedicated architec-
tural elements for the generation of resource allocations and
the verification/adoption of resource allocation. Safety-critical
components require the resource management framework to
support static resource guarantees. On the other hand, flexibility
w.r.t. resource allocation is important in order to be compet-
itive in the realization of non safety-critical applications. An
Untrusted Resource Manager (URM) computes new resource
allocations for the non safety-critical components, such as
an updated time-triggered schedule for the intercomponent
channel configurator or job images for the basic boot service.
The Trusted Resource Manager (TRM) verifies and actually
executes the resource reallocation and ensures that the new
resource allocation has no adverse effect on the behavior
of all hosted components (in particular, the safety-critical
components).
As depicted in Fig. 6, the configuration of the GENESYS
MPSoC is structured into three distinct steps—generation, ver-
ification and adoption of new resource allocations—supported
by the TRM and the URM:
1) Generation of resource allocation. The URM is a system
component that can propose new allocations of the com-
putational and communication resources of the application
and system components. The allocation of the communi-
cation resources defines for every component a time-trig-
gered schedule with the period, phase and duration of each
message transmission and reception. The URM can deter-
mine a resource allocation by selecting a suitable candidate
from a set of predefined configurations or by computing a
resource allocation from scratch given the communication
requirements (e.g., size of messages) and the temporal con-
straints (e.g., latencies) of the applications. In addition, the
URM can propose an allocation of the computational re-
sources by computing a job-component binding and deter-
mining which job image shall be assigned to which compo-
nent. The acquisition of job images can occur via a gateway
system component (e.g., from an external memory).
2) Verification of resource allocation. The TRM verifies
the correctness of the resource allocation computed by
the URM. The GENESYS MPSoC provides communi-
cation channels from the URM to the TRM to transfer
557
the proposed communication schedule and the corre-
sponding job images. The TRM checks the validity of the
supplied time-triggered schedule by evaluating a set of
safety assertions (e.g., safety-relevant messages were not
modified, safety-relevant components are only updated at
startup and not dynamically modified) before setting the
protected communication parameters of the LIFs of the
involved components. These protected communication
parameters designate the cycle and phase of the time-trig-
gered message transmissions, the maximum duration of a
transmission, the types of messages and the address of the
receivers/sender. At any instant, only a single message is
sent/received at a port. If concurrent sending or receiving
of messages is desired, multiple ports must be config-
ured. The allocation and sizing of the message buffers is
performed in the memory space of the component by a
cooperation between the GEM and the TRM. In addition,
the TRM determines whether the job images are suitable
for the components (as indicated by the signatures of the
job images).
3) Adoption of resource allocation. If the resource allocation
is found to be correct, it is written to the components using
the TII. Otherwise, the previous resource allocation re-
mains in place. The TRM possesses communication chan-
nels to all components, which are used to transfer to the
local resource manager (LRM) in each component the new
communication schedule and the job image.
D. Basic Execution Control Services
The basic execution control services are used to control the
execution of a component. Execution control is realized by
sending an appropriate message to the respective TII port of
the component. It is assumed that in every component there is a
local resource manager (LRM) that accepts and executes these
messages. The LRM is part of the GEM of a component.
The basic execution control consists of the following three
commands.
• ExecuteRequests is a message to the respective TII port of
the component requesting a component to start its execu-
tion at the next restart instant with the restart state that is
contained in this message. In case this restart state is empty,
the component will restart with the static restart-data that
is contained in its job.
• TerminateRequest is a message to the respective TII port
of the component requesting a component to terminate its
execution. The execution can be restarted with an Execute
Request.
• ResetRequest is a message that is interpreted directly by
the component hardware without any control by the GEM.
It resets the component hardware and starts the execution
of the GEM until the point where an ExecuteRequest is
awaited.
These three commands must be part of every component im-
plementation. Depending on the sophistication of the available
component hardware and the LRM inside the GEM, more de-
tailed execution control commands may be supported by a given
instantiation. These commands can relate to power management
558 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010

(e.g., power gating, voltage level), time-management, sched- A. Domain-Independent Optional Services
uling, and other execution control issues.
The basic execution control services are essential to facili- The domain-independent services build upon the core ser-
tate two key properties of the GENESYS MPSoC: robustness vices and are generic in the sense that they can be used in mul-
and energy efficiency. A component can recover from transient tiple application domains. These services are optional in the
faults by being reset via the TII. In order to improve energy ef- sense that they are not required in every instantiation of the ar-
ficiency, component can be stopped using the execution control chitecture. If needed, developers can pick them out of compo-
services. When the component services are needed again, the nent libraries with existing, validated architectural services.
component can be started and the state is restored using an ex- At present, the domain-independent optional services are
ecution request. grouped into the following categories (cf. Fig. 7): robustness
services, external memory management services, security
services, resource management services, gateway services,
mobility services, and higher communication services. Within
V. OPTIONAL SERVICES the GENESYS project1 these services were identified with
the support of experts from the automotive, industrial control,
The GENESYS MPSoC is designed for the use in multiple
avionics, consumer electronics and mobile domains. Selected
application domains in order to exploit the economies of scale
optional services were implemented and tested for the case
of the hardware. Using optional services in the waistline archi-
study in Section VI, namely, gateway, diagnosis, untrusted
tecture, the core architectural services can be refined according
resource manager, and input/output services.
to the requirements of specific domains (e.g., automotive) and
An example of a domain-independent optional service, which
applications (e.g., powertrain). This section presents some
has already been introduced in the explanation of the GEM, is
optional services (e.g., external memory management, state
the external memory management service. In many applications
restoration) as examples for this refinement. The external
built with the GENESYS MPSoC there may be the need to pro-
memory management service is essential for components
vide, in addition to the internal local memories of the compo-
requiring more memory than can be provided on-chip within
nents a (large) external memory. While the organization and at-
the components. The state restoration service allows to tolerate
tributes of the component-internal memory is a local issue of
transient faults through the external reset and restart of a
the component and of no relevance at the architecture level,
component. State restoration is important to address increasing
the external memory that is provided in the form of a system
transient failure rates induced by trends in the semiconductor
component and accessed by many application components must
industry.
be properly managed from the point-of-view of inter-compo-
An optional service encapsulates a well-defined supportive
nent data integrity. Access to the external memory is controlled
functionality into a self-contained system component that inter-
by this memory system component which acts as an intelligent
acts with the GEM of the application components by the ex-
memory controller that communicates with the application com-
change of messages. Alternatively, an optional service can be
ponents exclusively by the exchange of messages through the
implemented directly in the GEM of an application component.
LIF.
Optional services are can be useful across many application do-
Another example of a domain-independent optional service
mains and may be needed on many different occasions. They
is the state externalization service. For various reasons, such as
simplify the system development process by providing ready
state validity checking, state exchange, logging purposes, global
building blocks that can be reused on the basis of their LIF speci-
state snapshot, and power gating for energy saving, components
fication without the need to know the internals of the component
should periodically externalize their internal state at predefined
implementation.
cyclic recovery instants. State externalization is very important
The set of optional services is an open set that can be extended
for the fast recovery of components affected by transient faults.
and modified as new services are identified and conceptualized
The externalized information can be used to: 1) allow error de-
into a self-contained entity.
tection and/or 2) enable checkpointing and retry mechanisms.
The partitioning of the software on a GENESYS MPSoC
In a time-triggered system, the state externalization can be
into a set of self-contained system and application components
synchronized with the processing cycle within the component.
that interact with each other solely by the exchange of mes-
After the component has entered its ground state at its ground
sages, takes advantage of the enormous and cheap bandwidth
state instant, i.e., an instant where the internal tasks of the last
of the deterministic NoC that connects the components. It is
component cycle have been completed and all data that is rele-
thus possible to partition the software cleanly according to func-
vant for the next cycle is stored in a ground-state data structure,
tional and fault-containment criteria without causing an undue
the ground state can be sent in a ground-state message to a di-
performance penalty because of the distributed nature of the
agnostic system component.
implementation.
The diagnostic system component will use the component
As any other component, a system component forms its own
restart service to reset and restart a failed component by sending
fault-containment region. If a transient fault affects a system
a restart message to the TII interface of a failed component, with
component without internal state, the component can be reset
an internal state that is expected to be acceptable at the next fu-
immediately. If the component contains internal state, then this
ture restart instant in order to force the component into a restart.
internal state must be repaired before the component can con-
tinue to provide its services. 1www.genesys-platform.eu.
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
Fig. 7. Domain-independent optional services.
Fig. 8. Automotive example: Integration of two domains (control and multimedia).
The component restart service is also used to restart and perform
state restoration in case of power gating.
B. Domain-Specific Optional Services
The domain-specific optional services are services that
are specialized for the considered application domain. The
domain-specific optional services build upon the core services
and a well-defined subset of the domain-independent optional
services. For example, in the automotive domain a gateway
service for interacting with a Media-Oriented Systems Trans-
port (MOST) [43] network can be a domain-specific optional
service. MOST is bus standard used specifically for intercon-
necting multimedia components in automobiles.
VI. PROTOTYPE IMPLEMENTATION AND
AUTOMOTIVE EXAMPLE
This section describes a prototype implementation of the
GENESYS MPSoC and presents an automotive example
application. Like the in-vehicle electronic systems in today’s
559
premium cars, the example encompasses application services of
different domains (i.e., a control subsystem and a multimedia
subsystem). The prototype demonstrates the cross-domain
suitability of the GENESYS MPSoC and the ability for inter-
operability between different application domains.
The example employs one GENESYS MPSoC, which is con-
nected via an Ethernet gateway to a PC running the open-source
racing car simulator TORCS [44]. The GENESYS MPSoC con-
trols the vehicle in the simulator by processing user input from
a USB driving wheel with gas and brake pedals (see Fig. 8).
In the prototype of the GENESYS MPSoC, an implementa-
tion of the trusted subsystem provides the core services, while
system components realize selected optional services. Three
system components offer the following domain-independent
optional services: untrusted resource manager, diagnosis,
and gateway service. In addition, each application subsystem
contains a system component offering domain-specific optional
services (i.e., display in the multimedia subsystem, input/output
in the control subsystem). Finally, two application components
in each subsystem realize the application services.
560
Fig. 9. Messages sent by components in the prototype implementation.
Fig. 9 gives an overview of the messages exchanged between
the components on the TT-NoC.
A. Implementation of Core Services
1) Basic Time Services: Each communication interface
maintains a counter value that is a local representation of the
common time. All counter values are synchronized by means of
a shared clock distribution network, which spans all communi-
cation interfaces and produces the macro ticks of the common
time. The granularity of a macro tick obeys the reasonableness
condition ([34, p. 52]).
2) Basic Communication Services: The time-triggered
communication schedule, which controls the operation of the
TT-NoC, is distributed across the communication interfaces. A
dispatcher in each communication interface uses the schedule
to determine the instants of the common time when a com-
munication activity has to be processed. For this purpose, a
separate control logic for each message period compares the
current value of the common time with the phase of the next
communication activity in that period. On compare match, the
control interface triggers the processing of the communication
activity.
For each sending activity listed in the schedule at a communi-
cation interface, there must be a matching entry in the schedule
of at least one receiving communication interface. According to
this mapping between senders and receivers, communication in-
terfaces implicitly build single-, multi-, and broadcast channels.
The periodic and sporadic messages, which conceptually are
accessible through ports of communication channels, physically
reside in a memory buffer beyond the trusted subsystem within
the component, the port memory. A port is realized as a distinct
address range within the port memory. A port synchronization
protocol [19] defines the physical arrangement of periodic and
sporadic messages in ports and ensures memory consistency.
For periodic messages, the communication interface always
disseminates the messages, which are either fetched from the as-
sociated port and injected into the TT-NoC (for send operations)
or grabbed from the TT-NoC and stored in the corresponding
port (for receive operations). For sporadic messages, a message
transfer only takes place if the message queue at the sender side
is not empty.
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
In the prototype, the messages travel predefined seg-
mented routes, i.e., using source (wormhole) routing [19]. The
TT-NoC consists of switching nodes, which embody the hops
on the segmented route. In fact, this prototype instantiates
six switching nodes in a 2 3 mesh. Each communication
interface is attached to exactly one switching node at the com-
munication interface, which can be organized in any non-bus
topology, preferably a mesh. Generally, the connections be-
tween switching nodes are distinct and unidirectional, but two
lanes in reverse direction are grouped to form an interconnect
between a pair of switching nodes. Consequently, the TT-NoC
supports quasi-bidirectional communication patterns.
The routing information, which characterizes the path from
a sending to the receiving communication interfaces, is a priori
known and is organized in such a way that it avoids any tem-
poral or spatial collisions at switching nodes in the TT-NoC. The
routing information for each communication channel resides in
the sending communication interface. It precedes messages in
a header, which is injected by the sending communication in-
terface before it passes on the payload of the message at the
communication interface.
As a consequence, switching nodes have no knowledge about
the communication schedule or the routes of communication
channels, but they simply forward data based on the routing in-
formation of a message.
3) Basic Configuration Services: The basic configuration
service modifies the communication schedule in the commu-
nication interfaces in order to configure the intercomponent
channels. For this purpose, the TRM maintains a dedicated
communication channel to each communication interface,
which embodies the realization of the component’s TII. From
the point-of-view of the TRM, these dedicated channels are
sporadic communication channels. From the point-of-view of
a given communication interface, they are directly processed
and not visible to the application code. Whenever configuration
data arrives, the communication interface redirects the data into
its internal memories where the local communication schedule
and the routing information reside. This process is under con-
trol of the TRM, while the communication interface is passive.
The TRM does not overwrite the current configuration data of
the communication schedule, but it delivers the new data in an
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
unused area of the internal memory. As a result, the operation
of communication interfaces need not be interrupted. Hence,
during an intercomponent channel configuration there exist two
different configurations in each communication interface: the
active and the shadow configuration. After the TRM has dis-
tributed new configuration data to all communication interfaces
into their shadow areas, they switch to the new setup simultane-
ously at a common instant—the reconfiguration instant—also
present in the communication schedule. In other words, we
leverage the infrastructure of dispatching communication ac-
tivities to create a global synchronization event, namely the
reconfiguration instant.
4) Basic Execution Control Services: Besides configuration
data of the communication schedule and routing information,
the TRM is able to modify the parameters of execution control
in each control interface. Each control interface offers a collec-
tion of special control registers, which are writable for the TRM
and readable for the component. One of these special control
registers is the host mode, which represents the basic execution
control commands introduced in Section IV-D. Using the host
mode, a component can be started, stopped and reset.
B. Implementation of Domain-Independent Optional Services
1) Robustness Service: The prototype offers a domain-inde-
pendent robustness service, which serves for the detection of
transient and permanent faults. Therefore, a diagnostic system
component collects failure indication messages that are sent by
other components via their TII. For example, the GEM in the
application components implements an end-to-end checksum
mechanism [45] that checks the integrity of messages across
different components from the creation at a sender, throughout
transfer and use in a receiver. Also, the communication interface
at a component reports errors to the diagnostic system compo-
nent, e.g., information about a queue overflow at a port.
The diagnostic system component exploits information about
the frequency and location of errors in order to compute a health
state for the components [45]. The health state is an input for
maintenance decisions and for reconfiguration activities (e.g.,
signal the resource manager to suspend a faulty component and
activate a spare component).
2) Global Resource Manager: The Global Resource Man-
ager (GRM) is a system component that leverages the basic con-
figuration core service, particularly the inter-channel configura-
tion service, to adapt the communication schedule and param-
eters of the communication interfaces. The reason for such an
adaption can be changes in the environment of the MPSoC, ad-
ditional functions to be provided due to user requests, or recon-
figuration requests by the robustness service. The GRM either
maintains a set of predefined schedules and configurations or it
calculates them dynamically at run-time according to requests
[46].
The GRM is not permitted to write configuration data to the
communication interfaces directly. It has to submit a proposal
for a new configuration to the TRM to be checked first. If the
TRM approves the new configuration, the TRM employs the in-
terchannel configuration to write the configuration to the com-
munication interfaces.
561
In the prototype, sporadic communication channels exist
from the diagnostic system component and the application
components to the GRM to communicate resource request.
Furthermore, the GRM possesses a communication channel to
the TRM to transfer the proposal of the new configuration.
3) Gateway: The prototype possesses a gateway service for
the redirection of messages between the TT-NoC and a chip-
external Ethernet network. Information from multiple periodic
or sporadic messages is used for the construction of an Ethernet
message.
C. Domain-Specific Optional Services
In addition to the domain-independent services described in
the previous section, the prototype contains domain-specific ser-
vices for the automotive control and multimedia subsystems. An
input/output service serves for the interaction with sensor and
actuator devices (i.e., steering wheel and pedals in the proto-
type). This domain-specific service possesses local interfaces to
the natural environment and provides input to the application
services of the control subsystem. Due to the cyclic operation
of the control subsystem, periodic communication channels are
used for the communication with the application services.
The display service is a domain-specific service in the mul-
timedia subsystem of the prototype. Its purpose is to depict vi-
sual content using a Liquid Crystal Display (LCD). The display
service obtains this data from an application service through a
sporadic communication channel.
D. Programming of Application Components
The component implementation has to ensure that the com-
ponent behavior (i.e., sequence of transmitted messages as re-
sponse to inputs, state and the progression of time) satisfies the
operational and meta-level specifications of the linking interface
(cf. Section III-E).
For this purpose, different implementation choices of a com-
ponent are possible, ranging from a direct implementation of a
state machine in hardware to a flexible software-based imple-
mentation with a general purpose CPU executing an operating
system, middleware and application software. The implemen-
tation choice and the used operating system and programming
languages in case of a realization based on a general purpose
CPU are not visible to the users of a component. Other com-
ponents perceive only the message exchanges on the time-trig-
gered NoC.
The core services, which are offered by the communication
interface, serve as the foundation for the component implemen-
tation. The core services are accessible via a memory-mapped
interface consisting of a port interface and a control interface
(see Fig. 10).
a) Port Interface: The port interface offers access for the
communication interface to the physical memory (so-called
port memory), where all application data of messages that
are sent or received is stored. In the prototype implemen-
tation, the port memory in each component is realized as a
dual-ported memory. This dual-ported memory is accessed by
the communication interface according to the time-triggered
562
Fig. 10. Programming interface for the host processor of a component.
communication schedule. The host processor in a component
can also use the time-triggered communication schedule to
synchronize its read/write operations with the activities of the
communication interface. Alternatively, explicit synchroniza-
tion can be realized using the control interface.
The port interface is realized as a master on the communi-
cation interface side. Symmetrically, at the memory-side it is a
slave interface. Different implementation choices are supported
in the prototype for the slave and master interfaces such as Al-
tera Avalon [47] and AMBA AHB [48].
The port memory contains state ports and event ports. A state
ports consists of the message data and a timestamp denoting the
instant of the most recent message reception (w.r.t. the global
timebase). The queue of an event port is realized as a ring buffer,
which can store a given number of messages each consisting of
message data and a timestamp.
b) Control Interface: The control interface is used for the
configuration of individual ports and the synchronization of the
access to messages in ports between the host processor and the
communication interface.
Using the control interface, the host processor can write a
port configuration memory. This memory permits the enabling/
disabling of ports, the selection of port types (i.e., event or state
port), queue lengths and the definition of addresses in the port
memory for storing messages.
The port synchronization memory serves for ensuring con-
sistency of the read/write operations to the port memory be-
tween communication interface and host. For receiving mes-
sages through state ports, counters for the Non-Blocking Write
(NBW) protocol [49] are provided. For sending messages, the
port synchronization memory can be used to switch between
shadow buffers in the port memory. Thereby, the host is allowed
to update a message in a shadow buffer while another buffer is
active and used for the ongoing communication on the TTNoC.
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
For event ports, read and write positions for the ring buffer are
maintained in the port synchronization memory.
The register file offers the current value of the global time
base, information about error conditions (e.g., queue overflow
of a event port, watchdog miss), and control mechanisms for
the watchdog and the timer services.
E. Application Services of the Case Study
The application services realize the application logic of the
example application. For the control subsystem, the steering
control service takes the sensor inputs from the input/output ser-
vice and calculates the set values for the steering actuation. The
ABS controller service exploits the revolution sensors and initi-
ates the unlocking of a blocked wheel. The outputs of these two
application services are sent to the gateway service to be relayed
to the environmental simulation on the PC.
For the multimedia subsystem, the media source is an ap-
plication service that produces a video stream for the display
service. Furthermore, different quality levels are supported in
the multimedia system in order to control the requirements con-
cerning communication bandwidth at the TT-NoC and compu-
tational requirements at the components. The media control ser-
vice manages the transition to a different quality level. It pos-
sesses sporadic communication channels to the GRM to send
reconfiguration requests, which lead to the switching between
precomputed configurations in the prototype.
In the following, the implementation of one the application
components is explained (i.e., steering application service). This
component is realized as a NiosII soft-core CPU running the
COS-II [50] operating system. A driver library, which is linked
to the application code, supports the access to the port memory
and the control interface and abstracts from the low-level port
synchronization and the memory layout. In the prototype, both
the library and the application code were written in C.
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
Fig. 11. Sequence of activities at the application component realizing the steering control service.
Fig. 12. Resource requirements of prototype on Stratix III.
Fig. 11 depicts the temporal sequence of the activities of the
component within one cycle. The communication interface sig-
nals the arrival of the input message via an interrupt (part of
the control interface) to the host processor at a predefined in-
stant of the global time base. The interrupt causes the execution
of an interrupt service routine in the host processor. The inter-
rupt service routine generates a token in a mailbox of COS-II
serving as an interprocess communication primitive. The token
unblocks the application task so that the dispatcher of the op-
erating system will schedule the application task. Upon execu-
tion, the application task reads the message using the port in-
terface. The task invokes a send operation of the driver, which
writes the computed control values as a message into the port
memory. Finally, the communication interface sends the mes-
sage on the TT-NoC according to the time-triggered communi-
cation schedule.
VII. PERFORMANCE AND RESOURCE REQUIREMENTS
The prototype and the demonstration application are based
on FPGA technology [51], i.e., Stratix III series from Altera.
Most parts of the trusted subsystems (communication inter-
faces, TT-NoC) as well as parts of GEM services (end-to-end
checksum generation of robustness service) are realized as
VHDL code.
The optional services and application services have been real-
ized as software-based implementations. Each optional service
and each application service in the case study is realized with
a dedicated component (i.e., application component or system
component) and a dedicated soft core CPU. The presented case
study performs a strict partitioning using a one-to-one map-
ping between optional services/application services and hard-
ware blocks.
Each system component is built using an Altera Nios II
soft-core CPU with additional peripherals such as memory con-
trollers, I/O controllers etc. The service of a system component
(e.g., health monitoring of the robustness service) is realized
as a software-based implementation on that soft-core CPU.
563
Each application component uses an Aeroflex Gaisler LEON3
soft-core CPU with according peripherals as the computing
element for the realization of the application services.
Fig. 12 summarizes the resource utilization of selected enti-
ties for Stratix III FPGAs [51] in terms of used logic elements,
registers, and memory (RAM) cells of that target technology.
These values are the final resource utilization after placement
and routing (fitting) with Altera Quartus II 9.0sp2.
A. Basic Time Services
The granularity of the common time in the prototype is
s (953.67 ns). This is the granularity of the macro tick of the
local replicated clocks. All communication activities are syn-
chronized to this common time. The granularity of the local
system operation frequency is 3 ns (333 MHz).
B. Basic Communication Services
The communication interface (16 communication channels,
4 periods supported) achieves a maximum stable frequency
of more than 300 MHz on the Stratix III FPGA family, the
switching nodes of the TT-NoC can be driven even faster.
With a unit size of data (flit size in the NoC) of 32 bit, a single
communication channel theoretically can transfer 9.6 Gbit/s on
this target technology. In case of multiple concurrent commu-
nication channels this value scales linearly.
The latency of communication is made up of a constant pro-
cessing time in the communication interface (from dispatching
until the start of the message transfer) plus the (a priori known)
propagation delay in the TT-NoC. A communication interface
requires seven cycles of system operation frequency to start a
send or receive operation. The propagation delay of a commu-
nication channel through the network is given by the number
of hops on the route. For each hop, a switching node takes one
cycle of system operation frequency [19]. So, a message that
travels the longest (multicast) route of six hops in the 2 3 mesh
has a total latency of cycles, thus 39 ns at 333 MHz
system operation frequency.
564 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
TABLE I
RESULTS OF THE SYNTHESIS WITH A 45 NM LIBRARY
C. Basic Configuration Services
As mentioned in Section VI, the distribution of configura-
tion data from the TRM involves a dedicated communication
channel. Moreover, during distribution the operation of the com-
munication interface need not be stalled so that reconfiguration
does not impose any penalty on the availability of a compo-
nent. However, the simultaneous switch from active to shadow
configuration in all communication interfaces requires a short
interval of inactivity to reinitialize the dispatcher circuitry. In
fact, a communication interface takes “8 number of supported
periods” cycles of the system operation frequency until it con-
tinues its operation. In the prototype, where a communication
interface supports four periods, this outage takes 12 cycles at
333 MHz, i.e., 36 ns.
D. Basic Execution Control Services
The modification of the host mode control register takes im-
mediate effect during reconfiguration. As the communication
interface signals a switch between configurations, the compo-
nent can use this event, i.e., a hardware interrupt, to check the
current setting. The latency of an interrupt source routine for the
used soft-core CPUs is about 20 us.
E. Resource Estimation for ASIC
Even though the current implementation of the GENESYS
MPSoC focuses on FPGA technology, we have conducted
experiments to estimate the resources (e.g., area, power) and
timing (i.e., maximum system operation frequency) of the
current implementation for ASIC technology. We investigated
a switching node and a communication interface as described in
the previous sections. We used the Synopsis Design Compiler
(version Y-2006.06) to synthesize both entities with the Okla-
homa Slate University’s FreePDK 45 nm open source standard
cell library2 as target library.
Table I gives information about the maximum frequency,
estimated area (transistor number), and estimated power con-
sumption (dynamic plus static power at the given maximum
frequency) of a switching node and a communication interface.
The switching node uses a configuration with four interconnects
at 32 bit data bus width in lane of the TTNoC, whereas the
communication interface has been synthesized with 16 periods
in the current implementation.
The results of these experiments are rough estimations in
order to draw conclusions about the cost of the GENESYS
MPSoC when brought to silicon. The values for the communi-
cation interface do not incorporate memory cells, but just logic
cells. Furthermore, the value for the area does not denote the
number of transistors, but “cell units” or “gates” based on the
2http://avatar.ecen.okstate.edu/projects/scells/.
smallest cell in this library. If we want to estimate the transistor
number of a switching node and a communication interface, we
have to determine the number of transistors for that smallest,
basic cell and multiply by the numbers given in Table I. Usu-
ally, the basic cell is the NAND and NOR gate, which can be
implemented by 4 transistors in CMOS technology. According
to this estimation, a switching node would take about 25 000
transistors, whereas a communication interface requires about
225 000 to 230 000 transistors in ASIC technology.
VIII. DISCUSSION
This section discusses the properties of the GENESYS
MPSoC architecture and analyzes the insights gained from the
prototype implementation.
A. Economics of Scale
The GENESYS MPSoC establishes the foundation for the
realization of embedded systems in multiple application do-
mains. It provides a domain-independent core and the ability for
customization to individual domains and applications through
the seamless integration of application and system components.
The core services (i.e., time, communication, configuration, ex-
ecution control) are significant for all targeted application do-
mains in order to build higher services and ensure the desired
properties of the architecture. Secondly, the components of the
MPSoC will include general purpose CPUs, which are freely
programmable and can be used to implement the optional ser-
vices required in a specific application. In addition, the MPSoC
can contain special-purpose components (e.g., video decoder in
hardware) that are only useful for specific application domains.
Even if some of these components are not used in every appli-
cation, significant cost benefits can be expected for applications
with small markets (i.e., below millions of units like in indus-
trial control, avionics, or medical devices) due to the economics
of scale of the semiconductor industry. According to the ITRS
2007 [4], the marginal production cost of one million bits of
DRAM (packaged) was about 1 cent in 2007 and is going to
decrease to about .06 cent in 2015. This means that presently
about 10 billion bits can be produced for the cost of one engi-
neering hour. Parallel with this production cost decrease goes a
dramatic increase in the fixed cost of chip manufacturing, such
as cost of equipment, design, mask cost, or testing cost. Hence,
an increasing number of chips of a given design must be pro-
duced to recover the fixed cost. The cross-domain applicability
of the GENESYS MPSoC helps to meet this constraint by cre-
ating a larger market. This is especially important for customers
who demand small volumes and stringent requirements (e.g., in
aerospace applications), because semiconductor manufacturers
typically focus on their large customers in the data processing
and telecommunications industries today [52].
Furthermore, the cross-domain MPSoC platform facilitates
the establishment of a component-market for multiple domains.
For example, a given system component can be deployed in
avionic as well as automotive and industrial control applica-
tions. Thereby, the transition from separate sectoral, vertically
structured markets to a horizontally structured market is
supported.
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS
B. Improved Robustness
The GENESYS MPSoC supports robustness by establishing
a framework for fault and error containment, the selective restart
of components that have failed after a transient fault, and the
masking of transient and permanent errors by the replication of
components. The GENESYS MPSoC offers generic core and
optional services for robustness such as the state externaliza-
tion and component restart services that enable the recovery
from a transient fault with state restoration. In particular, the
trusted subsystem prevents a faulty component from affecting
the timely exchange of messages by other components. This
property ensures that components represent independent fault
containment regions. In conjunction with the determinism of the
GENESYS MPSoC, the fault containment allows to implement
active redundancy with exact voting [53].
C. Improved Complexity Management
The management of the ever-increasing cognitive complexity
of embedded systems is a major concern in all application do-
mains. GENESYS attacks this problem by lifting the design
process to a higher level of abstraction—to the level of self-con-
tained hardware/software components that communicate exclu-
sively by the exchange of messages. Components can be reused
on the basis of their interface specification without having to
know the internals of the component implementation. Based on
the predictable and deterministic NoC with inherent fault isola-
tion, the GENESYS MPSoC supports the classic simplification
strategies of abstraction, partitioning and segmentation [54].
The case study has demonstrated that heterogeneous auto-
motive services (i.e., control service and multimedia services)
with different criticality levels can be integrated. The commu-
nication interfaces, TRM and TTNoC establish strict control on
the component behavior and restrict message transmissions to
the time intervals specified in the time-triggered communica-
tion schedule. Thereby, the latency of a message transmitted
by a component is independent from the behavior of the other
components.
In particular, the local failure of a component does not lead
to a global failure of the entire chip. For example, the control
services in the case study will remain operational despite the
failure of a multimedia component (e.g., due to a design fault in
the implementation of the multimedia services).
D. Performance and Resource Requirements
As indicated by the results, the GENESYS MPSoC exhibits
competitive performance that is suitable for applications with
stringent bandwidth and latency constraints (e.g., high-res-
olution video streams, time-critical control applications). In
addition, the prototype demonstrates the moderate resource
demands imposed by the domain-independent core of the
GENESYS MPSoC. The required logic elements of the trusted
subsystem are fewer than the logic elements of two components
in the prototype. The memory requirements of the trusted
subsystem are configurable and depend on the configuration
such as the size of the communication schedule and the source
routing information in the communication interfaces.
In the GENESYS MPSoC, each service is ideally imple-
mented by a dedicated self-contained component in order to
565
maximize fault isolation. This approach also results in simpler
components, which have the potential for a more efficient use of
the chip area. According to Pollack’s rule [55], the increase in
performance of a sequential computer is only about the square
root of the increase in the number of devices, which implies
that doubling the transistor count will lead to a performance im-
provement of about 40%. Fortunately, the inherent concurrency
in a embedded application (i.e., the different application and
optional services) offers the potential to circumvent Pollack’s
rule. If an application is partitioned into a set of nearly au-
tonomous concurrent services, then a nearly linear performance
improvement could be achieved by assigning a dedicated
processing element to each of these concurrent services.
For a given application and a specific instantiation of the
GENESYS MPSoC with a particular selection of processing
cores, the definition of the jobs is also important for an efficient
use of chip area. The computational requirements of the jobs
should be aligned with the performance of the processing cores.
If the computational requirements of a job exceed the perfor-
mance of a processing core, jobs need to be further subdivided.
Adversely, jobs with low computational requirements can lead
to a low utilization of individual processing cores. Such a lim-
ited utilization of processing cores can also be desired to provide
the opportunity for future extensions or control power dissipa-
tion in a given application (e.g., thermal constraints).
Furthermore, the GENESYS MPSoC unleashes the potential
for more efficient implementation technologies. Due to cross-
domain reuse, implementations can target significantly larger
markets. A larger market justifies the use of different implemen-
tation technologies (e.g., special purpose hardware instead of a
general purpose CPU). The shift to a different implementation
technology can result in improvements of several orders of mag-
nitude w.r.t. performance, consumed die area, and energy effi-
ciency ([26, p.7]). Therefore, a different implementation tech-
nology can significantly outperform the benefits of optimizing
for a single application or domain. In contrast, optimizing for
a single application might reduce the size of potential applica-
tions (and thus the market), thereby preventing the shift to an-
other implementation technology (e.g., ASIC with better energy
efficiency, higher performance) due to the higher fixed cost.
REFERENCES
[1] M. Broy, “Challenges in automotive software engineering,” in Proc.
28th Int. Conf. Software Engineering: ICSE’06, New York, 2006, pp.
33–42, ACM.
[2] J. Hosbond, “Mobile systems development: Challenges, implications
and issues,” in Proc. IFIP Int. Working Conf. Mobile Inform. Syst.,
Leeds, U.K., 2005, pp. 279–286.
[3] “ARTEMIS Final Report on Reference Designs and Architectures—
Constraints and Requirements,” ARTEMIS (Advanced Research &
Technology for Embedded Intelligence and Systems) Strategic Re-
search Agenda, 2006. [Online]. Available: http://www.artemis-sra.eu
[4] “International roadmap of semiconductors,”—2007 Ed., Section De-
sign SIA, Tech. Rep..
[5] C. Constantinescu, “Trends and challenges in VLSI circuit reliability,”
IEEE Micro, vol. 23, no. 4, pp. 14–19, 2003.
[6] M. Day and P. Hofstee, “Hardware and software architectures for
the cell broadband engine processor,” in Proc. CODES + ISSS Conf.,
Austin, TX, 2005.
[7] AUTOSAR GbR, AUTOSAR—Technical Overview V2.0.1. Jun.
2006.
566 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
[8] “ARINC Specification 651: Design guide for integrated modular
avionics,” Aeronautical Radio, Inc.. Annapolis, MD, Nov. 1991.
[9] K. Kronlöf, S. Kontinen, I. Oliver, and T. Eriksson, “A method for
mobile terminal platform architecture development,” Advances in De-
sign and Specification Languages for Embedded Systems, pp. 285–300,
2007.
[10] IBM, Sony, and Toshiba, “Cell broadband engine architecture,” Tech.
Rep, 2006.
[11] K. Goossens, J. Dielissen, and A. Radulescu, “The Aethereal network
on chip: Concepts, architectures, and implementations,” IEEE Design
and Test of Computers, vol. 22, pp. 414–421, 2005.
[12] Sonics, “Sonics  network technical overview,” 2002. [Online]. Avail-
able: www.sonicsinc.com
[13] A. Hansson, K. G. M. Bekooij, and J. Huisken, “Compsoc: A
template for composable and predictable multi-processor system on
chips,” ACM Trans. Des. Autom. Electron. Syst., vol. 14, no. 1, pp.
1–24, 2009.
[14] M. Millberg, E. Nilsson, R. Thid, S. Kumar, and A. Jantsch, “The
nostrum backbone—A communication protocol stack for networks on
chip,” in Proc. 17th Int. Conf. VLSI Design, 2004, pp. 693–696.
[15] M. Coppola, R. Locatelli, G. Maruccia, L. Pieralisi, and A. Scandurra,
“Spidergon: A novel on-chip communication network,” in Proc. Int.
Symp. System-on-Chip, Nov. 2004, p. 15.
[16] OCP-IP Association, “Open core protocol specification 2.1,” 2005.
[17] ARM, “AXI protocol specification,” 2004.
[18] G. Engleder, “Time-triggered network-on-a-chip,” M.S. thesis, Faculty
of Computer Science, Real-Time Systems Group, Vienna Univ. Tech-
nology, Vienna, Austria, 2007.
[19] C. Paukovits and H. Kopetz, “Concepts of switching in the time-trig-
gered network-on-chip,” in Proc. 14th IEEE Int. Conf. Embedded Real-
Time Comput. Syst. Appl. (RTCSA), 2008, pp. 120–129.
[20] N. Suri, C. Walter, and M. Hugue, Advances in Ultra-Dependable Dis-
tributed Systems. Los Alamitos, CA: IEEE Computer Society Press,
1995, ch. 1.
[21] B. Pauli, A. Meyna, and P. Heitmann, “Reliability of electronic compo-
nents and control units in motor vehicle applications,” in VDI Berichte
1415, Electronic Systems for Vehicles, 1998, Verein Deutscher Inge-
nieure, pp. 1009–1024.
[22] ARINC Specification 653: Avionics Application Software Standard
Interface, Part 1—Required Services, Aeronautical Radio, Inc. An-
napolis, MD, Mar. 2006.
[23] R. Obermaisser and B. Huber, “A multi-core platform for integrated
modular avionics derived from a cross-domain embedded system ar-
chitecture,” in Proc. SAE 2009 AeroTech Congr. Exhibition, Seattle,
WA, Nov. 2009, p. 2009-01-3262, DOI: 10.4271/2009-01-3262.
[24] AUTOSAR GbR, AUTOSAR—Specification of RTE Software V1.0.1,
Jul. 2006.
[25] B. Huber and R. Obermaisser, “An ARTEMIS cross-domain embedded
system architecture and its instantiation for real-time automotive ap-
plications,” in Proc. 30th IFAC Workshop on Real-Time Programming
and 4th Int. Workshop on Real-Time Software, Mragowo, Poland, Oct.
2009, pp. 19–26.
[26] R. Lauwereins, “Multi-core platforms are a reality . . . but where is the
software support?,” presented at the Proc. 6th Int. Forum on Embedded
MPSoC and Multicore, 2006.
[27] H. Kopetz and N. Suri, “Compositional design of RT systems: A con-
ceptual basis for specification of linking interfaces,” in Proc. 6th IEEE
Int. Symp. Object-Oriented Real-Time Distrib. Comput., May 2003, pp.
51–60.
[28] R. Obermaisser and P. Gutwenger, “Model-based development of MP-
SOCS with support for early validation,” in Proc. 35th Annu. Conf.
IEEE Ind. Electron. Soc. (IECON 2009), Porto, Portugal, Nov. 2009,
pp. 2867–2873.
[29] “Road vehicles—Interchange of digital information—Controller area
network (CAN) for high-speed communication,” Int. Standardization
Organization, ISO 11898, 1993.
[30] LIN Specification Package Revision 2.0, LIN Consortium., Sep. 2003.
[31] “IEEE Std. 1149.1-1990, IEEE standard test access port and
boundary-scan architecture description,” IEEE Standards Assoc,,
Tech. Rep., 1990.
[32] DO-178B: “Software considerations in airborne systems and equip-
ment certification,” Radio Technical Commission for Aeronautics, Inc.
(RTCA). Washington, DC, Dec. 1992.
[33] “IEC 61508-7: Functional safety of electrical/electronic/pro-
grammable electronic safety-related systems—Part 7: Overview
of techniques and measures,” IEC: Int. Electrotechnical Commission,
1999.
[34] H. Kopetz, Real-Time Systems, Design Principles for Distributed Em-
bedded Applications. Boston, MA: Kluwer, 1997.
[35] C. Hoefer, “Causality and determinism: Tension, or outright conflict,”
Revista de Filosofia, vol. 29, no. 2, pp. 99–225, 2004.
[36] J. Muttersbach, T. Villiger, and W. Fichtner, “Practical design
of globally-asynchronous locally-synchronous systems,” in Proc.
6th Int. Symp. Advanced Res. Asynchronous Circuits and Systems
(ASYNC’00), Washington, DC, 2000, pp. 52–59.
[37] “Smart transducers interface, Version 1.0,” Object Management Group
(OMG), Jan. 2003.
[38] S. Chandra, J. Larus, and A. Rogers, “Where is time spent in mes-
sage-passing and shared-memory programs?,” in Proc. 6th Int. Conf.
Architectural Support for Programming Languages and Operating Sys-
tems, 1994, pp. 61–73.
[39] Y. Dou, Z. Pang, and X. Zhou, “Implementing a software virtual shared
memory on PVM,” in Proc. Adv. Parallel and Distrib. Comput., 1997,
pp. 190–195.
[40] J. Leverich, H. Arakida, A. Solomatnikov, A. Firoozshahian, M.
Horowitz, and C. Kozyrakis, “Comparing memory systems for chip
multiprocessors,” in Proc. Int. Symp. Comput. Architecture (ISCA),
2007, pp. 358–368.
[41] Y. Li, V. Suhendra, Y. Liang, T. Mitra, and A. Roychoudhury,
“Timing analysis of concurrent programs running on shared
cache multi-cores,” in Proc. 30th IEEE Real-Time Syst. Symp.,
RTSS, Washington, DC, Dec. 1–4, 2009, pp. 57–67, DOI=
http://dx.doi.org/10.1109/RTSS.2009.32.
[42] F. Poletti, A. Poggiali, D. Bertozzi, L. Benini, P. Marchal, M. Loghi,
and M. Poncino, “Energy-efficient multiprocessor systems-on-chip for
embedded computing: Exploring programming models and their archi-
tectural support,” IEEE Trans. Comput., vol. 56, no. 5, pp. 606–621,
May 2007.
[43] T. Gaul, W. Lowe, and M. Noga, “Specification in a large industry
consortium—The MOST approach,” in Proc. 27th Annu. Conf. IEEE
Ind. Electron. Soc. (IECON’01), Denver, CO, Nov. 2001, vol. 3, pp.
1828–1833.
[44] E. Onieva, D. A. Pelta, J. Alonso, V. Milanes, and J. Perez,
“A modular parametric architecture for the TORCS racing en-
gine,” in Proc. IEEE Symp. Computat. Intell. Games, 2009, pp.
256–262.
[45] H. Paulitsch, C. Paukovits, and C. E. Salloum, “Fault isolation with
intermediate checks of end-to-end checksums in the time-triggered
system-on-chip architecture,” in Proc. 4th Symp. Ind. Embedded Syst.
(SIES’09), 2009, pp. 90–99.
[46] B. Huber, C. E. Salloum, and R. Obermaisser, “A resource manage-
ment framework for mixed-criticality embedded systems,” in Proc.
34th Annu. Conf. IEEE Ind. Electron. Soc. (IECON 2008), Orlando,
FL, 2008, pp. 2425–2431.
[47] Avalon Interface Specification, Chapter Avalon Memory-Mapped In-
terfaces, , Altera Cooperation,, 2008. [Online]. Available: http://www.
altera.com, available at
[48] AMBA 2 AHB Specification 1.0, , ARM Limited, 1999. [Online]. Avail-
able: http://www.arm.com, available at
[49] H. Kopetz and J. Reisinger, “The non-blocking write protocol
NBW: A solution to a real-time synchronization problem,” in
Proc. 14th Real-Time Syst. Symp., Raleigh-Durham, NC, 1993,
pp. 131–137.
[50] J. Labrosse, “MicroC/OS-II—The Real-Time Kernel” CMPBooks,
2002.
[51] Altera Corp., “Stratix III Device Handbook,” 2009.
[52] B. Ames, “Radiation threatens avionics as chip geometries shrink,”
Military Aerosp. Electron., 2004.
[53] S. Poledna, Fault-Tolerant Real-Time Systems: The Problem of Replica
Determinism. Boston, MA: Kluwer, 1996.
[54] H. Kopetz, “The complexity challenge in embedded system design,”
in Proc. 11th IEEE Int. Symp. Object-Oriented Real-Time Distrib.
Comput., 2008.
[55] P. Gelsinger, “Microprocessors for the new millenium, challenges, op-
portunities, and new frontiers,” in Proc. Solid State Circuit Conf., 2001,
pp. 22–25.
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 567

Roman Obermaisser is a Senior Researcher at Christian Paukovits is a former researcher at the

the Institute of Computer Engineering, TU Wien.
His research focuses on system architectures for
distributed embedded real-time systems. He is
the author of numerous conference and journal
publications and he wrote a book on an inte-
grated time-triggered architecture published by
Springer-Verlag, New York. He was coordinator
of the FP7-ICT collaborative project GENESYS
(GENeric Embedded SYStem Platform) with 23
partners. Currently, he is responsible for the Euro-
pean research project ACROSS (Artemis Cross-Domain Architecture).
Institute of Computer Engineering, TU Wien, and is
currently affiliated with TTTech, Vienna, as a Digital
Design Engineer and Research Engineer. He is
primarily engaged in the field of in-vehicle commu-
nication networks of the automotive industry as well
as network-on-chip architectures in multiprocessor
system-on-chips for cross-domain applicability. He
has been a key developer of the GENESYS MPSoC
and also participates in the follow-up research
project within ARTEMIS.

Hermann Kopetz (LF’10) is the Head of the Insti-

tute of Computer Engineering, TU Wien. His group
has done pioneering work in the field of high-de-
pendable embedded systems and time-triggered
real-time protocols, such as TTP and TT-Ethernet.
The TT-Ethernet protocol has been selected by the
U.S. NASA for deployment in the Orion project,
the successor of the space shuttle.