WO2009140707A1

WO2009140707A1 - Cross-domain soc architecture for dependable embedded applications

Info

Publication number: WO2009140707A1
Application number: PCT/AT2009/000207
Authority: WO
Inventors: Christian El Salloum; Bernhard Huber; Hermann Kopetz; Roman Obermaisser; Roberto Zafalon; Valentin Gherman; Klaus Kronloef; Heikki Waris; Eric Lenormand; Philippe Millet; Michael Borth; Chantal Couvreur; Neeraj Suri; Sergio Campos; Eila Ovaska; Kari Tiensyrjä; Michael Goedecke; Knut Hufeld; Mohammad-Reza Tazari; Antonio Perez Berdud
Original assignee: Technische Universität Wien; Interuniversitair Micro-Electronica Centrum Vzw Party's
Priority date: 2008-05-21
Filing date: 2009-05-20
Publication date: 2009-11-26

Abstract

A computer architecture for dependable distributed embedded systems is presented. This architecture consists of a plurality of computational units that are interconnected by a hierarchy of heterogeneous communication networks. At the lowest level, one or more functional units, at least one diagnostic unit and at least one security unit are allocated to a single MPSoC in order to support the dependable operation. These units interact via a deterministic network-on-chip. The unique integration of functionality, dependability and security concerns in a single deterministic SoC is an important innovative aspect of this new architecture.

Description

Cross-Domain SoC Architecture for Dependable Embedded Applications

Field of the Invention

This invention relates to the field of embedded computer-system architecture, in particular to the design of an MPSoC (Multi-Processor-System-on-Chip) that serves as a node computer in a variety of dependable distributed embedded applications.

Background of the Invention

During the last twenty-five years, the subject of embedded computer applications has grown to become one of the most important areas in the computer field. Due to the increasing computational capabilities of microcomputers and their decreasing cost, many mechanical and hydraulic control systems have been replaced in a bottom-up fashion by embedded computers (e.g., electronics in the automobile). Additionally, important new embedded applications, such as the mobile phone or digital television, have been enabled by the extraordinary progress of the micro-electronics industry.

In the past, embedded applications in different domains (e.g., process control, automotive, aerospace, consumer electronics, mobile phones) have been developed more or less in isolation without any cross- domain architectural framework. This has lead to a wide proliferation of electronic devices, making it difficult to take full benefit from the enormous economies of scale of the semiconductor industry. The further development of the semiconductor industry [12] such as the costs associated with the design of a multi-million transistor device with a feature size of 65 ran and below, poses substantial challenges to the fragmented embedded system industry, such as

• Only few mass-market applications (e.g., the mobile phone or the television set) are in the position to recover the cost of design and manufacture of a specialized SoC (System-on- Chip).

• The increasing transient failure of highly integrated SoCs, due to ambient radiation and manufacturing intricacies, requires system-level techniques to guarantee a high-level of system dependability [10].

• The connection of embedded devices to the Internet {Internet of things) poses new security challenges that have to be faced in many application domains in a similar manner.

It is therefore expedient to design a generic embedded system architecture that supports the development of dependable embedded applications in many different application domains, using the same hardware devices and software modules [H]. At the heart of such a cross-domain architecture is a versatile MPSoC that forms the basic building block for the development of a plethora of applications in widely differing domains. By interconnecting many of these MPSoCs by appropriate networks, large distributed applications can be supported. Such an MPSoC must have the following characteristics:

• Flexibility: It must be possible to realize widely varying functionalities in many different application domains within the same basic hardware/software framework. Different interconnection technologies (wire-bound and wireless) of the basic building blocks must be supported • Dependability: The framework must provide basic mechanisms to enable the design of embedded system of high dependability. Dependability encompasses among others, reliability, maintainability and security.

• Cost-Effectiveness: Due to the mass-production of the basic hardware devices and the wide reuse of software modules the cost-effectiveness of applications that are developed within this framework is achieved.

It is the objective of this invention to present an architecture for dependable embedded applications and give details of the design of a generic MPSoC that sits at the core of this architecture.

Overview of the Invention

The proposed embedded system architecture follows a strict component-based design approach, where components communicate solely by exchanging messages and not by accessing a common memory, as stipulated in [3] and in many other MPSoC proposals. At the level of an application specification, a component is a unit of defined application functionality. At the implementation level, a component is realized by an IP-Core of an MPSoC. The architecture requires a one-to-one mapping of a defined application functionality to an IP-Core [15]. An IP-Core is thus the basic implementation unit of a component. It is a fault-containment region (FCR) from the point of view of the defined application functionality [16]. An IP-Core on an MPSoC will have one message interface to send messages to the other IP-Cores of the MPSoC and another local message interface to interact with its local environment (e.g, the sensors, actuators and other entities in the local environment of the IP-Core).

Components communicate with other components exclusively by the exchange of unidirectional multicast messages across interfaces. A component can have one or more interface, where each interface contains one or more ports. Each port is used for the sequential sending and receiving of a message. In the proposed architecture, all components are time-aware. A common time of known precision is established at all components. The establishment of such a common time of known precision is known in the art [7]. In order to solve the problem of system-wide consistent view of the simultaneity of events that are generated within the architecture, a sparse time model is used in the architecture [7].

In the proposed architecture three integration levels of components are distinguished: the chip level, the device level and the system level. The interface across which units are integrated at a given integration level is called a linking interface (LIF) of that level [8].

At the chip level the IP-Cores of an MPSoC are integrated by sending messages across a Network- on-Chip (NoC) to the other IP-Cores of the MPSoC. The interface between an IP-Core and the NoC is thus the chip-level LIF of the component.

At the device level, chips are integrated by an inter-chip communication system to form a device. At the device level, the inter-chip communication interface (which is considered to be a local interface of the IP-Core at the chip level) becomes the device level LIF.

At the system level, devices are integrated by an inter-device communication system. The inter- device communication system can be wire-bound or wireless, hi a system where the devices are integrated by wireless communication services, devices can leave and join an ensemble dynamically. We call such a system and open system in contrast to a closed system, where the devices are established at system startup and remain in the system during the operation. Temporal guarantees can only be given in closed systems. Looking at a given LIF, the behavior of a component at this LIF is defined by the sequences of messages a component sends and receives across this LIF and by the internal state of the component at this LEF. This internal state should be made visible regularly at this LIF. The sequence of messages that cross the LIF must be fully defined at the operational level and at the semantic level. At the operational level the syntax of the messages and the timing of the messages must be precisely specified [8] making use of the common sparse time. At the semantic level, meaning is assigned to the syntactic units established at the operational level.

At the chip level, IP-Cores can be either hard or so/?. A component is hard if the functionality of the IP-Core is realized in the hardware of the IP-Core and cannot be changed. An example of a hard IP-Core is an IP-Core that implements the Advanced Encryption Standard AES in hardware. An IP-Core is soft, if the functionality of the IP-Core is determined by software and can be changed by changing the software. An example of a soft IP-Core is software on an IP-Core with a CPU und memory or an FPGA fabric, where the functionality is determined by the software controlled wiring of the logic elements. From the point of view of the chip-level LIF it is not discernable whether the IP-Core behind the LEF is soft or hard. In the proposed architecture it is thus possible to change the implementation of an IP-Core from soft to a hard without changing the chip— level LIF of the EP-Core. Such a change of the implementation may be required in order to improve meta-functional properties of the IP-Core, such as power usage, energy efficiency or the chip area needed to implement the functionality. The proposed MPSoC can contain a mixture of soft and hard EP-Cores.

At the chip level, the EP-Cores communicate by a deterministic NoC. A system behaves deterministically if and only if, given a full set of initial conditions (the initial state) at the initial instant time t_o, and a sequence of future timed inputs, the outputs at any future instant t are entailed [18]. This definition of determinism is required in order to simplify the implementation of fault tolerant systems by triple modular redundancy (TMR). The determinism of the NoC also helps to support the constructive composition of EP-Cores. There are different means to implement a deterministic NoC that are known in the art, for example by dedicated links between ports that avoid any contention or by a time-triggered NoC. In the proposed architecture the NoC communication bandwidth that is allocated to a port of an EP- Core interface can be changed dynamically [17]. A change of the bandwidth can be restricted to a trusted IP-Core, such that an arbitrary failure of any non-trusted IP-Core cannot cause a modification of the NoC communication bandwidth [4]. If the implementation of the IP-Core is also deterministic, then the behavior of a subsystem of the MPSoC, consisting of deterministic EP-Cores and the NoC, will be deterministic as well. The establishment of deterministic subsystems is needed if faults of an EP Core or a communication system are to be masked by active redundancy.

In the proposed architecture, functional EP-Cores provide application services. In addition to the functional EP-Cores the MPSoC contains a diagnostic IP-Core and a security IP-Core. These two EP- Cores are essential for the attainment of a high dependability of the MPSoC.

The diagnostic IP-Core, which forms an independent FCR (fault containment region) monitors the behavior of the functional IP-Cores of the MPSoC (which are located in different FCRs of the same MPSoC) [14] and initiates a hardware reset and restart of the failed EP-Core in case the behavior of a functional EP core has failed. Since it is assumed that the majority of transient faults of an EP-Core is caused by ambient cosmic radiation [10], where the impact of a neutron fission event is localized to an area of few μm in square [9], the transient error of such an event is assumed to effect only a single EP- Core and thus a defined application functionality that can be reestablished by an intelligent restart of the application function.

The security IP-Core contains a cryptographic engine to encrypt sensitive messages that leave the MPSoC and decrypt incoming encrypted messages. The proposed architecture thus provides the means to encrypt all sensitive data that leave the physical boundary of the MPSoC. Since the unencrypted messages that flow within the MPSoC among the IP-Cores are protected by the physical structure of a single chip and can hardly be observed from the outside without destroying with the chip, the proposed architecture provides a high level of security.

Summary of the Invention

Detailed Description of the Invention

The invention is now explained in detail be making reference to the enclosed drawings.

Fig. 1: depicts the structure of an MPSoC

Fig. 2: depicts a TMR configuration of three MPSoC.

Fig. 1 shows an MPSoC 100 containing six computational units, namely a Security IP-Core 110, a diagnostic IP-Core 111, and the four functional IP-Cores 112, 113, 114 and 115. All IP-Cores are connected to the Network-on-Chip (NoC) 101 by their chip-level linking interfaces that are placed between the IP-Cores and the NoC. Additionally the IP-Cores 112, 113 and 115 have a second (local from the perspective of the chip integration level) interface to the IP-Core environment. For example, the local interface 122 of IP-Core 112 can be an Ethernet that connects the MP-SoC 100 to other MPSoCs, thus forming a device-level LEF. The Interface 123 can be an interface to sensors in the environment of the IP-Core 113. Similarly, IP-Core 115 can have a local interface 125 to its actuators.

A functional IP core is formed by allocating a software subsystem that implements the desired function to the IP core hardware. Such a functional IP core forms a fault containment region where design or hardware faults that occur inside the functional IP core are contained within such a functional IP core and can affect the IP core environment only by the generation of erroneous messages. A message is erroneous if it is sent at an unintended time (temporal error) or if it contains an unintended value (value error).

The NoC 101 can transport unidirectional multicast event-triggered messages, time-triggered messages and data-streams among the IP-Cores of the MPSoC 100.

An event-triggered message is a message that is sent whenever a significant event occurs at the sender. In case the communication channel is not free at the instant of event-occurrence, the event- triggered message must ^"be stored in a queue at the sender's site before it can be transmitted by the NoC 101. Similarly, an event-triggered message that is delivered from the NoC 101 to a destined receiver must be stored in a message queue before the receiver in case the receiver is not ready to accept the message at the moment of message arrival. Event-triggered message conform to the exactly-once semantics, i.e., every message produced by a sender must be eventually consumed exactly once by its receiver(s). It is difficult to give precise temporal guarantees to event-triggered messages, since the delay of the event-triggered messages in the sender queue and the receiver queue is difficult to quantify.

A time-triggered message is sent whenever the periodic sent instant that has been assigned to this message occurs. A pre-defined cycle that specifies the send instants is associated with every time- triggered message. A cycle is a period of physical time between the repetitions of regular events. A cycle is specified by the duration of its period and the position of its start, the cycle start phase relative to the common time. In order to avoid the exponential explosion in the combination of cycles and thus an enormous increase in complexity, it is expedient establish the rule that all cycles must be in a harmonic relationship to each other, i.e., the duration of any cycle must be a power of two of the duration of the shortest allowed cycle. The cycles allocated to the time-triggered messages must be planned by a message scheduler, in order to avoid any message conflicts among time-triggered messages [17]. Whenever the instant cycle-start of a time-triggered message occurs, the contents of the message buffer at the sender's site are fetched by the NoC 101 and transmitted to the receivers (non-consuming read) within a know interval. At the instant of message delivery from the NoC 101, the contents of the message buffer at the receiver's site is overwritten by the arriving time-triggered message. There are no queues associated with time-triggered messages. Since the communication system is deterministic it is possible to associate tight temporal guarantees with time-triggered messages.

A data stream is a regular sequence of messages that is produced by a sender and consumed by a receiver. The temporal interval between any two messages of the data stream is known a priori. It is thus possible to perform on-the-fly processing of data streams in this temporal interval. Data streams have the temporal properties {precise instant of transmission) of time-triggered messages and value properties (exactly-once-semantics) of event-triggered messages. Since in the proposed architecture it is possible to synchronize data-streams from different sources, this architecture is well-suited for multi-media applications (e.g., lip synchronization by synchronizing an audio stream with a video stream).

The common time that controls the transmission of time-triggered messages and of data streams is an NoC time, but not the local time of the IP-cores [I]. The local times of the IP-Cores (the oscillator frequency of the IP-Core) is independent of the NoC time and can be changed without changing the NoC time in order to set an IP-Core into a sleep mode or into a low-power mode. Every IP-core is thus an island of synchronicity. It is thus possible to control the speed and power consumption of an IP-Core by controlling its frequency and voltage dynamically. The time-domain crossing between the time domain of the NoC time and the time of the respective IP-Core occurs in the NoC interface between the NoC 101 and the respective IP-Core. The NoC time can be synchronized with an external time reference, for example with GPS time or any other external time source that is available. If this synchronization is provided, then it is possible to synchronize the actions of many distributed devices in a distributed system, establishing the basis for off-chip TMR [19].

The NoC 101 transmits unidirectional multicast messages. This implies that a single message that is sent by a sending IP-Core, for example IP-Core 114 can be received by the diagnostic IP-Core 111 and the security IP-Core 110 concurrently. This multicast sending allows the non-intrusive monitoring of the behavior of any IP-Core by the diagnostic IP-Core 111. Since the data and control flow in the NoC is unidirectional, the possibility of backward error propagation in the NoC 101 from a receiver to the sender is excluded by- design. This characteristic of the NoC is of paramount importance for the implementation of fault-tolerance by triple modular redundancy. A faulty receiving IP-Core cannot interfere with the operation of a correct sending IP-Core.

The NoC 101 also provides error containment with respect to temporal faults of an IP-Core [16]. This is realized by informing the NoC about the permitted temporal behavior of an IP core before start-up. Every communication channel between a sender and its receivers is provided with the so-defined a priori determined bandwidth within the NoC. This bandwidth can be changed dynamically by setting the appropriate parameters in the chip-level LIF at run-time. If a faulty IP-Core sends more messages than currently specified, it cannot flood the NoC but will overflow its local send buffer. The temporal properties of the communication among the correct IP-Cores will not be affected by such a temporal fault. This is in contrast to other networks, e.g., a Control Area (CAN) network , where a faulty sender can monopolize the network and thus cause a system failure.

The operation and message format the NoC 101 is compatible with the Internet naming and protocol conventions. It is thus possible to connect IP cores by a hierarchy of networks - an NoC at the lowest level and the Internet at the highest level. This implies that the state of higher level protocols is stored in the IP-Cores and not in the network or the gateway components (principle of fate sharing [6] in the Internet). Only soft state, that is state that can be restored in case of a fault, is maintained outside the endpoints of the communication.

In the NoC a clear distinction between the logical name space of an application and the physical name space of the MPSoC is maintained as outlined in [13]. This distinction between the logical names (that define the functionality of an IP-Core) and the physical names (that defines the location of the physical IP-Core) is important from the point of view of reconfiguration.

The diagnostic IP-Core 111 has the capability to restart any of the functional IP-Cores 112, 113, 114 and 115 by sending a restart message to the IP-Core which must be restarted. The restart message must contain the up-to-date restart state of the IP-Core that is to be restarted. A special input port of the chip- level LIF of an IP-Core, the restart port, is the receiving port of such a restart message. Whenever an IP- Core receives such a restart message at its restart port, it will perform a hardware resest and a restart of the IP-Core, taking the received restart state as the starting state for its renewed operation. Every IP-Core should transmit its restart state periodically to the diagnostic node 111 in the form a time-triggered message. Because of the semantics of time-triggered message, the specified receive port of the restart state will always contains the most up-to-date version of the restart state. In case of a restart, the diagnostic component can either use this up-to-date version of the restart state or can perform state estimation [7] to transform this restart state to a form that will be valid at the precise time of the restart.

The security IP-Core 110 contains the unique tamperproof security credentials of the MP-SoC and an engine for the encryption and decryption of messages. The security credentials can consist of a UED, that is a globally unique MPSoC identifier that is part of the MPSoC hardware and cannot be modified without destroying the MPSoC. This globally unique MP-SoC identifier gives every MPSoC its unique identity. Additionally, the security credentials can contain the public key of a trusted security authority, i.e., a trusted network node that distributes its authentic data with an electronic signature the authenticity of which can be validated with this public key. In systems that use a different security strategy, the security credentials of the IP Core 110 can contain different parameters. The security EP core can deploy standard encryption techniques to protect the confidentiality of the message generated by the MPSoC and to make it possible for the receivers of the information to establish the integrity and authenticity of the received data by adding electronic signatures to an unencrypted message.

In case a complete SoC needs to be restarted from the outside of the SoC an encrypted message containing the restart states of all functional EP cores of an SoC is sent to the SoC that must be restarted. This message will be decrypted by the security EP core 110 before it is relayed to the functional IP cores.

Fig. 2 depicts an example of a distributed embedded computer system which is designed according to the inventive computer architecture. In detail Fig. 2 depicts a triad of MP-SoCs 201, 202 and 203 of the kind introduced in Fig. 1. This triad is interconnected by two deterministic time-triggered off-chip networks 210 and 220 to form a Fault-Tolerant Unit (FTU). Any deterministic network, for example Time-Triggered (TT)-Ethernet [2], can be used for this purpose. It is assumed that in the three MP-SoCs 201, 202 and 203 contain three replicas of the safety-relevant EP cores that operate deterministically and concurrently. Any safety-relevant message produced by any of the safety-relevant IP-Cores in the MP- SoCs 201, 202 and 203 is transmitted via both networks 210 and 220 to all MP-SoCs of the triad. Every receiving IP-Core on any of the three MP-SoCs will analyze the six incoming message replicas and will only forward the message for further processing if at least two message replicas from two different sending IP-cores are bit-by-bit identical in their message data fields. Given that the relevant IP cores operate deterministically, the NoC is deterministic and the off chip time-triggered networks 210 and 220 are deterministic the FTU depicted in Fig. 2 will mask any physical fault in any one of the three MP- SoCs 201, 202 and 203 of or in any one of the two networks 210 and 220. Furthermore there is a high probability that Heisenbugs [5] that are design faults that manifest themselves probabilistically will also be masked. In order to reestablish the redundancy after a transient failure has corrupted the restart state in any of the replicated IP-Cores in the MPSoCs, the restart state of every safety relevant IP-Core should be sent out for voting and state-error masking by the other replicas of the IP cores periodically [19]. The duration of this period determines the length of the window of vulnerability with respect to the occurrence of a second transient fault and is thus an important parameter in any reliability model [19].

In a TMR configuration consisting of three SoCs in a FTU where the determinism of the NoC and the network between the SoCs is required, the replicated IP cores of the FTUs will send periodically the encrypted restart state of each replicated SoC to the other two replicated SoCs. The three messages (two coming from the outside of the SoC and one coming from the inside of the SoC) containing the restart state will be decrypted by the security EP core and voted upon by the diagnostic IP core before the correct restart state is relayed to the functional EP cores.

The diagnostic EP core detects any error in the restart state received from the functional EP cores by comparing this restart state with the restart state received from the outside of the SoC and maintains an error statistic in order to detect functional EP cores with a high transient failure rate. A high transient failure rate of EP cores is an indication of an upcoming permanent failure and suggests an early reconfiguration of the EP cores or replacement of the SoCs which is expected to exhibit a permanent failure soon.

The proposed architecture also enables the implementation of a TMR triad of replicated EP cores on a single MPSoC as shown in Fig. 1. However in such an on-chip TMR configuration the three replicas will not achieve the independence achieved with the off-chip TMR structure depicted in Fig. 2 due the fact that some faults (e.g., a power outage) will effect all EP-Cores that are positioned on the same die.

To summarize, the proposed cross domain architecture for embedded system achieves the dependable operation by the following mechanism that are provided by the described MPSoC

• Transient failures of a functional EP-Core can be handled within the MPSoC by the diagnostic EP-Core that monitors the behavior of the functional cores and enforces a restart in case the behavior becomes faulty. This will result in a short service interruption

• If such a short service interruption is not acceptable, than a TMR triad of three replicas can be implemented within the MPSoC in order to mask transient failures of an EP Core and tolerate a single permanent failure within a MPSoC without any external service degradation.

• If the limited independence of EP-Cores implemented on a single die is not acceptable, than an off chip TMR triad as depicted in Fig. 2 can be configured.

• The confidentiality, authenticity and integrity of the information produced by the proposed MP-SoC is established by the security IP Core that is part of any MP-SoC. This unique combination of functional IP Cores, a diagnostic IP Core and a security EP-Core on a single MP-SoC, interconnected by a deterministic NoC that distributes a common notion of network time establishes an innovative MP-SoC structure that contains all essential mechanism for building dependable embedded applications in many different application domains. Such an MP-SoC has thus a significant economic potential.

References Cited

Patent Documents

[I] US 6,755,788 granted Aug.lO, 2004: Method for providing a synchronous communication and transaction between functions on an integrated circuit therefore the functions operate independently at their own optimized speeds

[2] EP 1512254 granted Oct 5, 2005: Communication method and system for transmitting timed and event driven Ethernet Messages

[3] US 6,998,170 granted Jan 16, 2006: Scalable Architecture based on single-chip multiprocessing [4] WO 2007/085028 published Aug. 2, 2007: Time Controlled Secure Communication

Claims

1. Computer Architecture for dependable distributed embedded computer systems, consisting of a plurality of computational units that are interconnected by a hierarchy of heterogeneous communication networks, where the lowest communication network in the hierarchy is a Network-on-Chip (NoC) that links the computational units (IP-Cores) of a Multiprocessor System-on-Chip (MPSoC), and where all IP- Cores have access to a common sparse time-base that is established by the architecture and where the interface of an IP-Core to the NoC is precisely defined in the domains of value and time, making use of the sparse common time that is available in the SoC characterized in that the SoC contains at least one functional IP-Core, at least one diagnostic IP-Core, at least one security IP-Core, and a network-on-chip that interconnects all IP-Cores of the SoC and where

IP-Cores communicate exclusively by the exchange of unidirectional multicast messages over an NoC that provides deterministic and dynamic communication channels for the transmission of event-triggered messages, time-triggered messages and data streams, and where the NoC enforces IP-Core error containment in the temporal domain and supports an NoC message format and NoC message name space that is compatible with the Internet fate sharing principle and where a functional IP-Core is a fault-containment region formed by the allocation of a self-contained software subsystem of specified application functionality to an IP-Core of the SoC and where the diagnostic IP-Core realizes a restart of a functional IP-Core by sending a message with a defined restart state to the restart port of the functional IP-Core which causes a hardware reset of the functional IP-Core and the loading of the received restart state into the IP-Core before the processing within the IP- Core is initiated with this received restart state and where every SoC contains unique tamper-proof security credentials in a security IP-Core that contains a cryptographic engine for encrypting messages that are leaving the SoC and decrypting messages that arrive at the SoC from the outside and where an encrypted restart message that originates from the outside of the SoC in order to restart the complete SoC is decrypted by the security IP core and sent to all stateful functional IP cores to enforce a restart of the complete SoC.

2. Computer Architecture according to claim 1, characterized in that an IP-Core implementation consists of at least one CPU with memory, at least one Input/Output Interface and a program containing the instructions for execution by the CPU.

3. Computer Architecture to claim 1, characterized in that an IP-Core implementation consists of an FPGA and a program containing the instructions for linking the logic elements of the FPGA.

4. Computer Architecture to claim 1, characterized in that an IP-Core is an ASIC of given functionality.

5. Computer Architecture according to one of the claims 1 to 4, characterized in that the allocation of power, energy and bandwidth to the IP-Cores of an SoC is dynamic.

6. Computer Architecture according to one of the claims 1 to 5, characterized in that a functional IP-Core outputs regularly its restart state in a message to a diagnostic IP-Core.

7. Computer Architecture according to one of the claims 1 to 6, characterized in that a diagnostic IP-Core performs a state estimation of the restart state for the instant, when the restart state is enforced at a functional IP-Core.

8. Computer Architecture according to one of the claims 1 to 7, characterized in that the SoCs are connected by a deterministic off-chip communication system.

9. Computer Architecture according to one of the claims 1 to 8, characterized in that the SoCs are connected by a best-effort off-chip communication system.

10. Computer Architecture according to one of the claims 1 to 9, characterized in that the architecture supports synchronized data streaming over heterogeneous on-chip and off-chip networks and where the intermediate storage of data streams is minimized by the synchronization of sender, networks and receivers.

11. Computer Architecture according to one of the claims 1 to 10, characterized in that the architecture supports on-the-fly processing of data streams.

12. Computer Architecture according to one of the claims 1 to 11, characterized in that the behavior of an IP-Core implementation is deterministic.

13. Computer Architecture according to one of the claims 1 to 12, characterized in that the NoC and some of the IP-Cores are implemented in an FPGA.

14. Computer Architecture according to claim 13, characterized in that some of IP-Cores are implemented by single chip Micro-controllers that are interfaced to the NoC with the FPGA.