A Cross-Domain Multiprocessor System-on-a-Chip
Post on 08-Apr-2018
221 Views
Preview:
Transcript
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
1/20
548 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
A Cross-Domain Multiprocessor System-on-a-Chipfor Embedded Real-Time Systems
Roman Obermaisser, Hermann Kopetz, Life Fellow, IEEE, and Christian Paukovits
AbstractGENESYS Multiprocessor System-on-a-Chip(MPSoC) is the building block of a generic platform for thecomponent-based development of embedded real-time systems indifferent domains, such as in automotive, aerospace, industrialcontrol, and consumer-electronic applications. The GENESYSMPSoC 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 beimplemented by domain-independent and domain-specific systemcomponents that customize the platform to the needs of the specificapplication domain. Through its cross-domain applicability, theGENESYS MPSoC supports the wide reuse of components and
realizes the benefits of the economies of scale of the semiconductortechnology. Furthermore, the GENESYS MPSoC contributestowards the solution of prevalent technological challenges such ascomplexity management, robustness, and technology obsolescence.This paper presents the GENESYS MPSoC and provides insightsfrom a prototype implementation, which demonstrates that sucha cross-domain MPSoC can be built with todays technology.
Index TermsComputer architecture, computer interfaces,fault tolerance, multicore processing, real-time systems, robust-ness, system-on-a-chip.
I. INTRODUCTION
DRIVEN by the dramatically increasing performance/priceratio of the semiconductor industry, many mechanical,
hydraulic and electronic-analogue control systems have beenreplaced by digital microelectronics over the past 20 years.Embedded technologies are becoming dominant in many in-dustries such as avionics, automotive, industrial control, themedical sector and consumer electronics. This trend is likelyto continue due to the continuously increasing possibilitiesoffered 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 theindustrial 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; dateof current version November 05, 2010. This work was supported in part by theEuropean 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
technologies motivates a consolidation in order to avoid par-allel developments and multiple reinventions of the wheel indifferent industrial domains.
In particular, some fundamental challenges have been iden-tified, which are common to many application domains in thearea of embedded systems [3].
Cognitive complexity: One major challenge is the man-agement of the ever-increasing cognitive effort neededby 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 shorttime-to-market) lead to an enormous growth in the com-plexity of the design at the system level. This challengehas also been identified in the International Roadmap onSemiconductors 2007, which states that the silicon andsystem 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 increaseof transient failure rates, which go along with the shrinkinggeometries, lower voltages, and higher frequencies of thesemiconductor industry [5].
Energy efficiency: Energy efficiency of embedded systemsis of utmost concern, e.g., in the mass market of mobiledevices, to limit car-battery load in a car when the engineis 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. TheGENESYS MPSoC exhibits cross-domain applicability. It hasbeen developed in the European research project GENESYS incollaboration 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 theresult of discussions and convergence among industrialpartners 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
1551-3203/$26.00 2010 IEEE
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
2/20
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 549
for specific applications, it can be extended by systemcomponents providing optional services on top of the coreservices. The set of optional services is open and can beextended.
Architectural services addressing the technological chal-lenges: Fundamental core and optional services supportingcomplexity management and robustness are identified inthis paper.
Mapping an automotive example application to a proto-type of the MPSoC: A prototype of the introduced MPSoCis used to implement an automotive example applicationand provide information about performance and resourcerequirements.
The GENESYS MPSoC leads to a significant reduction offragmentation in the area of embedded systems. By advancingfrom domain-specific solutions towards a cross-domainMPSoC, a significantly larger market for embedded systemtechnologies (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 ofparticular importance for the semiconductor industry wherethe engineering costs associated with the design and toolingof chips grows rapidly. According to the International Tech-nology Roadmap for Semiconductors (ITRS) the production ofmasks and exposure systems is becoming a bottleneck for thedevelopment 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]. Thecross-domain usability helps to amortize such nonrecurringcosts.
The paper is structured as follows. Section II provides anoverview of related work in the area of MPSoCs and system
architectures. An overview of the GENESYS MPSoC is thetopic of Section III. The stable set of core services is detailedin Section IV. Section V is devoted to the optional services.Section VI presents the prototype implementation and theautomotive example. This paper ends with a discussion inSection 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
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 performsfault 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 designand 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. Anunintended 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 emergencein 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 onthe 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 controllercomponent.
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
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
3/20
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 servicesof 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 inFig. 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. Towardsthe 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, thereafterinto 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 targetedapplication domains (e.g., automotive, avionic, and consumer
electronics). Through the ability of being implemented spaceand energy efficiently in hardware for a multitude of application
domains, the core services lay the foundation for exploitingthe 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 andapplication services. These core services and an explanation for
the rationale of their inclusion in the waist of the GENESYSMPSoC will be given in Section IV.
Different underlying implementation options exist for each
of the core services. For example, the core communicationservices 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 anddistributed 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 dedicatedhardware solutions. The possible variants increase towards the
bottom of the waist as indicated by the increasing width of thetrapezoidal shape.
In analogy, variability increases towards the waistlines 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 applicationbuilt with the GENESYS MPSoC. The implementation of
these optional services uses the core services. Examples ofthese services will be given in Section V.
Domain-specific optional services are highly specializedoptional 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. Thetransmission 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 theTT-NoC is known a priori and independent from all othermessages exchanges. This predictability is essential for
real-time applications, the implementation of fault-toler-
ance through active redundancy and certification. Differentimplementations 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. Thecommunication 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 aTrusted Resource Manager (TRM). Hence, the temporal
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
4/20
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
5/20
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 GENESYSMPSoC.
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 witheach 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 toencrypt/decrypt the boot messages.
From the perspective of safety-criticality, a wholeGENESYS 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 ispossible.
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 messageinterfaces it is expedient to provide a model of the component-
internal structure, in particular of the software elements thatform a job.
We consider a job to be structured into a component-localoperating system, the middleware, and the application softwareas outlined in Fig. 3. The middleware can be further partitionedinto the GENESYS Middleware (GEM) and application-spe-cific middleware. The application-specific middleware ispeculiar to the implementation of a certain component and thusoutside the scope of this paper. The GENESYS Middleware
(GEM), on the other hand, is concerned with the provisionof the GENESYS architectural services to the application
software. The GEM can establish APIs for the applicationsoftware in order to use optional architectural services that areprovided in the system components. These APIs can hide themessage-based interaction with the system components.
For example, an external memory (cf. Section V) is anoptional service that is provided by a system component with alocal interface to an off-chip memory. Application components
can exploit this external memory service by interacting withthe respective system component through the core services. Animplementation of the external memory can use the followinginteraction pattern: The application component sends a sporadicmessage (cf. Section IV-B) with a request for a certain memorypage, which is in turn answered by the system component withanother sporadic message containing the requested memorypage. The GEM can hide this low-level interaction from theapplication software. In the above example, the GEM canprovide a memory region to the application code, making thedifference between local memory in the application componentand 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. Forexample, avionic applications based on Integrated ModularAvionics (IMA) can interact with the underlying platformthrough the APplication EXecutive (APEX) as standardized inARINC 653 [22]. The mapping of the GENESYS architecturalservices to APEX has been described in [23] in order to enablethe reuse of existing avionic applications. Likewise, the GEMcan establish the Run-Time Environment (RTE) [24] of theAUTomotive Open System ARchitecture (AUTOSAR) in orderto support the execution of existing automotive applicationsoftware. The mapping of the GENESYS architectural servicesto the AUTOSAR RTE is discussed in [25].
In addition to the establishments of APIs, the GEM can servefor the implementation of optional architectural services. Anoptional architectural service can either be implemented in asystem component (with APIs in the GEM of the applicationcomponents that exploit the service) or the optional service canbe fully implemented in the GEM. The latter implementationchoice can be advantageous for specific optional services be-cause of performance constraints or due to the requirement ofphysical proximity to the application code (e.g., certain fault-tolerance or diagnostic services).
For example, the computation of end-to-end checksums forthe detection of communication faults on the TT-NoC shouldoccur in the GEM. If checksums were checked in a system com-ponent, then a communication fault could affect the message inbetween the application component and the system componentproviding the checksum service.
Optional services in the GEM are offered across the com-ponent LIF (see Section III-E) if they relate to the operationalaspects of a component and across the TII if they relate tothe meta-level aspects of a component, such as componentconfiguration.
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.,
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
6/20
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 553
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), andthe 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 canimprove 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 thatcontains information for the restart of a component at the next
restart instant. The operational specification must be precise andformal and ensures the interoperability of components.
Information on how interfaces are specified in the presented
MPSoC using SystemC can be found in [28]. Theinterface spec-ification starts with a structural model that partitions the overall
system into jobs that interact through message-based interfaces.
As part of the structural model, the timing, syntactic propertiesand the state are captured. Subsequently, the structural model
is refined into a behavioral model that captures the productionof 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 operationswithout 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 theapplication 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 reducesthe overall complexity of a component.
For example, the trusted subsystem (cf. basic configurationand execution control in Section IV) use the TII to configure
and reconfigure a component (e.g., assign the proper names to acomponent 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 aspecific 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, thelocal 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 viafieldbuses (e.g., Controller Area Network (CAN) bus [29]). The
latter approach simplifies the installationboth from a logicaland a physical point-of-viewat the expense of increased la-
tency of sensory information and actuator control values.
The local interfaces are used by the implementor of a compo-nentin order to provide the specified services at the LIF. From
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
7/20
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 onthe 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 TDIis 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 TDIdepends on the technology of the component implementation,
and will be different if the same functionality of a componentis 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 capabilitiesare 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 ofpowerful dynamic system capabilitiesin 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 commontime 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 andalignment.
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
8/20
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 555
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 nowand 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 timereference. 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-
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 todays
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 messageexchange 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 exactlyonce.
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
9/20
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 transportis 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 receivers ports. The size of the message
queuesoutgoing queues at sending components as well as in-
coming queues at receiving componentsis 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 andsignals 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 modeof 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 considerationsthe 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 schedulingtables, 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 forthe 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 ofthe 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 systemcomponent. The gateway system component connects
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
10/20
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 557
Fig. 6. Resource Management: (1) Generation. (2) Verification. (3) Adoptionof 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-criticalcomponents).
As depicted in Fig. 6, the configuration of the GENESYS
MPSoC is structured into three distinct stepsgeneration, ver-
ification and adoption of new resource allocationssupported
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
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 theinvolved 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 bysending 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 giveninstantiation. These commands can relate to power management
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
11/20
558 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
(e.g., power gating, voltage level), time-management, sched-
uling, and other execution control issues.
The basic execution control services are essential to facili-
tate two key properties of the GENESYS MPSoC: robustness
and energy efficiency. A component can recover from transient
faults by being reset via the TII. In order to improve energy ef-
ficiency, component can be stopped using the execution controlservices. When the component services are needed again, the
component can be started and the state is restored using an ex-
ecution request.
V. OPTIONAL SERVICES
The GENESYS MPSoC is designed for the use in multiple
application domains in order to exploit the economies of scale
of the hardware. Using optional services in the waistline archi-
tecture, the core architectural services can be refined according
to the requirements of specific domains (e.g., automotive) and
applications (e.g., powertrain). This section presents some
optional services (e.g., external memory management, state
restoration) as examples for this refinement. The external
memory management service is essential for components
requiring more memory than can be provided on-chip within
the components. The state restoration service allows to tolerate
transient faults through the external reset and restart of a
component. State restoration is important to address increasing
transient failure rates induced by trends in the semiconductor
industry.
An optional service encapsulates a well-defined supportive
functionality into a self-contained system component that inter-
acts with the GEM of the application components by the ex-change of messages. Alternatively, an optional service can be
implemented directly in the GEM of an application component.
Optional services are can be useful across many application do-
mains and may be needed on many different occasions. They
simplify the system development process by providing ready
building blocks that can be reused on the basis of their LIF speci-
fication without the need to know the internals of the component
implementation.
The set of optional services is an open set that can be extended
and modified as new services are identified and conceptualized
into a self-contained entity.
The partitioning of the software on a GENESYS MPSoCinto a set of self-contained system and application components
that interact with each other solely by the exchange of mes-
sages, takes advantage of the enormous and cheap bandwidth
of the deterministic NoC that connects the components. It is
thus possible to partition the software cleanly according to func-
tional and fault-containment criteria without causing an undue
performance penalty because of the distributed nature of the
implementation.
As any other component, a system component forms its own
fault-containment region. If a transient fault affects a system
component without internal state, the component can be reset
immediately. If the component contains internal state, then this
internal state must be repaired before the component can con-tinue to provide its services.
A. Domain-Independent Optional Services
The domain-independent services build upon the core ser-
vices and are generic in the sense that they can be used in mul-
tiple application domains. These services are optional in the
sense that they are not required in every instantiation of the ar-
chitecture. If needed, developers can pick them out of compo-
nent libraries with existing, validated architectural services.At present, the domain-independent optional services are
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
the GENESYS project1 these services were identified with
the support of experts from the automotive, industrial control,
avionics, consumer electronics and mobile domains. Selected
optional services were implemented and tested for the case
study in Section VI, namely, gateway, diagnosis, untrusted
resource manager, and input/output services.
An example of a domain-independent optional service, whichhas already been introduced in the explanation of the GEM, is
the external memory management service. In many applications
built with the GENESYS MPSoC there may be the need to pro-
vide, in addition to the internal local memories of the compo-
nents a (large) external memory. While the organization and at-
tributes of the component-internal memory is a local issue of
the component and of no relevance at the architecture level,
the external memory that is provided in the form of a system
component and accessed by many application components must
be properly managed from the point-of-view of inter-compo-
nent data integrity. Access to the external memory is controlled
by this memory system component which acts as an intelligent
memory controller that communicates with the application com-
ponents exclusively by the exchange of messages through the
LIF.
Another example of a domain-independent optional service
is the state externalization service. For various reasons, such as
state validity checking, state exchange, logging purposes, global
state snapshot, and power gating for energy saving, components
should periodically externalize their internal state at predefined
cyclic recovery instants. State externalization is very important
for the fast recovery of components affected by transient faults.
The externalized information can be used to: 1) allow error de-
tection and/or 2) enable checkpointing and retry mechanisms.
In a time-triggered system, the state externalization can besynchronized with the processing cycle within the component.
After the component has entered its ground state at its ground
state instant, i.e., an instant where the internal tasks of the last
component cycle have been completed and all data that is rele-
vant for the next cycle is stored in a ground-state data structure,
the ground state can be sent in a ground-state message to a di-
agnostic system component.
The diagnostic system component will use the component
restart service to reset and restart a failed component by sending
a restart message to the TII interface of a failed component, with
an internal state that is expected to be acceptable at the next fu-
ture restart instant in order to force the component into a restart.1www.genesys-platform.eu.
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
12/20
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 559
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. Thedomain-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 ANDAUTOMOTIVE EXAMPLE
This section describes a prototype implementation of the
GENESYS MPSoC and presents an automotive exampleapplication. Like the in-vehicle electronic systems in todays
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 componentsin each subsystem realize the application services.
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
13/20
560 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
Fig. 9. Messages sent by components in the prototype implementation.
Fig. 9 gives an overview of the messages exchanged betweenthe components on the TT-NoC.
A. Implementation of Core Services
1) Basic Time Services: Each communication interfacemaintains a counter value that is a local representation of thecommon time. All counter values are synchronized by means ofa shared clock distribution network, which spans all communi-cation interfaces and produces the macro ticks of the commontime. The granularity of a macro tick obeys the reasonablenesscondition ([34, p. 52]).
2) Basic Communication Services: The time-triggeredcommunication schedule, which controls the operation of the
TT-NoC, is distributed across the communication interfaces. Adispatcher in each communication interface uses the scheduleto determine the instants of the common time when a com-munication activity has to be processed. For this purpose, aseparate control logic for each message period compares thecurrent value of the common time with the phase of the nextcommunication activity in that period. On compare match, thecontrol interface triggers the processing of the communicationactivity.
For each sending activity listed in the schedule at a communi-cation interface, there must be a matching entry in the scheduleof at least one receiving communication interface. According tothis 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, physicallyreside in a memory buffer beyond the trusted subsystem withinthe component, the port memory. A port is realized as a distinctaddress range within the port memory. A port synchronizationprotocol [19] defines the physical arrangement of periodic andsporadic messages in ports and ensures memory consistency.
For periodic messages, the communication interface alwaysdisseminates 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 correspondingport (for receive operations). For sporadic messages, a message
transfer only takes place if the message queue at the sender sideis not empty.
In the prototype, the messages travel predefined seg-mented routes, i.e., using source (wormhole) routing [19]. TheTT-NoC consists of switching nodes, which embody the hopson the segmented route. In fact, this prototype instantiatessix switching nodes in a 2 3 mesh. Each communicationinterface is attached to exactly one switching node at the com-munication interface, which can be organized in any non-bustopology, preferably a mesh. Generally, the connections be-tween switching nodes are distinct and unidirectional, but twolanes in reverse direction are grouped to form an interconnectbetween a pair of switching nodes. Consequently, the TT-NoCsupports quasi-bidirectional communication patterns.
The routing information, which characterizes the path from
a sending to the receiving communication interfaces, is a prioriknown and is organized in such a way that it avoids any tem-poral or spatial collisions at switching nodes in the TT-NoC. Therouting information for each communication channel resides inthe sending communication interface. It precedes messages ina header, which is injected by the sending communication in-terface before it passes on the payload of the message at thecommunication interface.
As a consequence, switching nodes have no knowledge aboutthe communication schedule or the routes of communicationchannels, 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 intercomponentchannels. For this purpose, the TRM maintains a dedicatedcommunication channel to each communication interface,which embodies the realization of the components TII. Fromthe point-of-view of the TRM, these dedicated channels aresporadic communication channels. From the point-of-view ofa given communication interface, they are directly processedand not visible to the application code. Whenever configurationdata arrives, the communication interface redirects the data intoits internal memories where the local communication scheduleand 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 ofthe communication schedule, but it delivers the new data in an
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
14/20
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 561
unused area of the internal memory. As a result, the operationof communication interfaces need not be interrupted. Hence,during an intercomponent channel configuration there exist twodifferent configurations in each communication interface: theactive and the shadow configuration. After the TRM has dis-tributed new configuration data to all communication interfacesinto their shadow areas, they switch to the new setup simultane-ously at a common instantthe reconfiguration instantalsopresent in the communication schedule. In other words, weleverage the infrastructure of dispatching communication ac-tivities to create a global synchronization event, namely thereconfiguration instant.
4) Basic Execution Control Services: Besides configurationdata of the communication schedule and routing information,the TRM is able to modify the parameters of execution controlin each control interface. Each control interface offers a collec-tion of special control registers, which are writable for the TRMand readable for the component. One of these special controlregisters is the host mode, which represents the basic execution
control commands introduced in Section IV-D. Using the hostmode, 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, throughouttransfer 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.
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 applicationservices 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 bythe communication interface according to the time-triggered
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
15/20
562 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 6, NO. 4, NOVEMBER 2010
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 supportedin 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 isactive and used for the ongoing communication on the TTNoC.
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 StudyThe 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, boththe library and the application code were written in C.
8/7/2019 A Cross-Domain Multiprocessor System-on-a-Chip
16/20
OBERMAISSER et al.: A CROSS-DOMAIN MULTIPROCESSOR SYSTEM-ON-A-CHIP FOR EMBEDDED REAL-TIME SYSTEMS 563
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 asVHDL 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 realizedas a software-based implementation on that soft-core CPU.
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 iss (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 onthis 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-
cessi
top related