A Cross-Domain Multiprocessor System-on-a-Chip

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: [email protected]).

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


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


3/20


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


4/20


5/20


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.,


6/20


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


7/20


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/20


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.


9/20


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


10/20


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


11/20


(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.


12/20


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.


13/20


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


14/20


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


15/20


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.


16/20


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

A Cross-Domain Multiprocessor System-on-a-Chip

Documents