EP2452264A1 - System-on-chip fehlererkennung - Google Patents

System-on-chip fehlererkennung

Info

Publication number
EP2452264A1
EP2452264A1 EP10744654A EP10744654A EP2452264A1 EP 2452264 A1 EP2452264 A1 EP 2452264A1 EP 10744654 A EP10744654 A EP 10744654A EP 10744654 A EP10744654 A EP 10744654A EP 2452264 A1 EP2452264 A1 EP 2452264A1
Authority
EP
European Patent Office
Prior art keywords
core
message
trm
messages
sent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP10744654A
Other languages
English (en)
French (fr)
Inventor
Stefan Poledna
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FTS Computertechnik GmbH
Original Assignee
FTS Computertechnik GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by FTS Computertechnik GmbH filed Critical FTS Computertechnik GmbH
Publication of EP2452264A1 publication Critical patent/EP2452264A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H04L49/555—Error detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/004—Error avoidance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/273—Tester hardware, i.e. output processing circuits
    • G06F11/2736—Tester hardware, i.e. output processing circuits using a dedicated service processor for test
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7807—System on chip, i.e. computer system on a single chip; System in package, i.e. computer system on one or more chips in a single package
    • G06F15/7825—Globally asynchronous, locally synchronous, e.g. network on chip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/10—Packet switching elements characterised by the switching fabric construction
    • H04L49/109—Integrated on microchip, e.g. switch-on-chip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H04L49/552—Prevention, detection or correction of errors by ensuring the integrity of packets received through redundant connections
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/183—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components
    • G06F11/184—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components where the redundant components implement processing functionality

Definitions

  • This invention relates to a method and apparatus for improving the reliability of a system-on-chip in an embedded computer system.
  • the invention relates to a method for error detection in a system-on-chip (SoC) consisting of a number of IP cores, each IP core being a fault-containment unit, and where the IP cores are via a network-on -Chip communicate with each other by means of messages and an excellent IP core, a TRM (Trusted Resource Monitor) realized.
  • SoC system-on-chip
  • TRM Trusted Resource Monitor
  • SoC system-on-chip
  • An IP core is a hardware / software component that fulfills a given function.
  • the communication of IP cores can be done either through the access of the IP cores to a common memory or via messages.
  • PCT / AT 2009/00207 an SoC architecture is presented in which the IP cores communicate exclusively via messages.
  • the present invention aims to prevent a faulty IP core of a SoC from failing other IP cores not directly affected by the fault.
  • the present invention aims to prevent, in a system-on-chip (SoC) in which a plurality of components (IP cores) communicate exclusively by means of messages, to prevent a fault of one IP core on the others, from Error not directly affected IP cores, propagates.
  • SoC system-on-chip
  • This goal is achieved by detecting and discarding a faulty control message sent from a nonprivileged IP core to another unprivileged IP core from a (by definition independent) fault containment unit, so that it fails Control message can not cause failure of the message recipient.
  • Any message from one IP core that can cause another IP core to fail can be checked by a third IP core and discarded if necessary prevent this erroneous message sent by a failed IP core from causing the failure of another IP core.
  • any control message to be sent from a non-privileged IP core to another unprivileged IP core is first sent to a third IP core, this third IP core verifying the message, and where if the message is not faulty, the message is forwarded from this third IP core to the intended final recipient.
  • the checking IP core may classify a message as faulty if the evaluation of one of the assurances known to the verifying IP core a priori has the value wrong.
  • An advantage is the third IP core of the TRM.
  • the TRM only forwards messages from a sender entitled to send a control message to the IP core specified in the message.
  • TRM can send a control message to the TII (technology-independent interface) of a non-privileged IP core.
  • At least three messages, each from a different IP core, must be sent to the TRM within a predetermined time interval, and where the receiving TRM verifies that at least two of the three messages contain the same instruction before issuing this message the TII interface of the addressed IP core is forwarded.
  • At least three messages, each from another SoC, must be sent to the TRM within a predetermined time interval, and where the receiving TRM checks to see if at least two of the three messages contain the same instruction before that message to the TII Interface of the addressed IP core is forwarded. It is expedient if the functions of the privileged subsystem, which consists of the TRM, the Network on Chip and the Network Interfaces, are protected by error-correcting codes.
  • the invention relates to an apparatus for performing a method as described above, wherein one or more or all process steps are performed directly in the hardware of the SoCs.
  • Fig. 1 shows the structure of a system-on-chip (SoC).
  • Fig. 2 shows the structure of an IP core of a SoC.
  • Fig. 3 shows the sending of a control message from one IP core to another IP core of a SoC.
  • IP 1 shows a SoC 100 with the eight IP cores 111, 112, 113, 114, 115, 116, 117 and 118. These eight IP cores can exchange messages via a network-on-chip 101.
  • Each IP core e.g., the IP core 114, is connected to the NoC 101 via a network interface (NI) 102.
  • NI network interface
  • One of these eight IP cores, e.g. the IP core 111 is a privileged IP core called the Trusted Resource Monitor (TRM), while the remaining seven IP cores 112, 113, 114, 115, 116, 117 and 118 are nonprivileged IP cores.
  • TRM Trusted Resource Monitor
  • the TRM 111, the Network on Chip 101, and the eight Network Interfaces 102 form the privileged subsystem of the SoC 100.
  • an error in this privileged subsystem may result in failure of the entire SoC. Therefore, according to the invention, the functions of the privileged subsystem are to be protected by special error control measures, such as the use of error-correcting codes. Corresponding error-correcting codes can be used to detect and correct transient and permanent hardware errors in the privileged subsystem.
  • Each of the seven non-privileged IP cores forms its own Fault-Containment Unit (FCU) (Kopetz, H. (1997) Real-Time Systems, Design Principles for Distributed Embedded Applications; ISBN: 0-7923-9894-7. Boston, Kluwer Academic Publishers.), Ie the consequences of any one Software or hardware failures within an unprivileged IP core can only directly disrupt the functions of the affected IP core, but they can only indirectly affect the functionality of the other IP cores through faulty messages. If bad messages are detected and rejected, the indirect consequences of an IP Core error can not be reproduced. In PCT / AT 2006/00278 an architecture is described in which temporal errors of IP core messages are recognized and discarded by the privileged network interface (NI) 102 of the NoC 101.
  • NI privileged network interface
  • PCT / AT 2009/00207 (WO 2009/140707), only the TRM 111 is allowed to write temporal parameters to the NI 102 in order to prevent a faulty IP core from independently changing the transmission parameters of a message.
  • the method as described in PCT / AT 2006/00278 does not prevent contentually incorrect control messages from being sent from an unprivileged faulty IP core to the other non-privileged IP cores.
  • Fig. 2 shows the structure of a nonprivileged IP core, e.g. IP core 114.
  • This IP core has four external interfaces: 211, 212, 213 and 122.
  • the three message interfaces 211, 212 and 213 are connected to the Network Interface (NI) 102 of FIG.
  • the interface 122 is a local interface of the IP core, via which a connection to the outside world of the SoC 100 is realized.
  • This interface 122 may be e.g. an input / output network (e.g., a CAN network) or a wireless connection to the SoC 100 environment.
  • the message interface 211 is referred to as the Linking Interface (LIF) of the IP core 114. Via the LIF 211, the services of the IP core 114 are offered to the seven other IP cores of the SoC 100.
  • LIF Linking Interface
  • the message interface 212 will be referred to as a Technology Dependent Interface (TDI) that allows the service technician to communicate with the internal functions of the IP core 114. Since the format and content of these TDI messages depend on the specific implementation technique of the IP core, this interface is implementation-dependent.
  • TDI Technology Dependent Interface
  • the message interface 213 is called TII (Technology-Independent Interface). Via this TII interface 213, the configuration and the sequence control of the IP core 114 are realized by means of control messages.
  • a control message is a message that controls the flow of the calculation in an IP Core. For example, by means of control messages, a hardware reset of the entire IP core 114 is initiated, or the start of a program execution or the termination of a program execution of the IP address. Cores 114 arranged. Furthermore, control messages can be used to configure or reconfigure the SoC.
  • a faulty control message sent to the TII interface of the IP core may cause the failure of the IP core 114, eg, if during the correct work of the IP core 114 suddenly a faulty hardware reset message is received at the TII interface 213 becomes.
  • the internal structure of the IP core 114 is shown.
  • IP core hardware executing the software loaded in the IP core 114.
  • IP core internal operating system executing the software loaded in the IP core 114.
  • the IP Core internal middleware At the next level 202 is the IP Core internal operating system and at level 203 is the IP Core internal middleware.
  • the application software is the application software.
  • API application program interface
  • the messages received over the TII interface 213 communicate either directly with the IP core hardware 201 (eg a reset message), with the operating system 202 (eg a control message for scheduling a process) or the middleware 203, but not with the application software 204. It is therefore the application software of a non-privileged IP core not possible, faulty control messages, which can be detected via the TII interface 213 to recognize.
  • Fig. 3 shows the sending of a control message to the TII interface of a non-privileged IP core. If e.g. If the IP core 115 wants to send a reset message 140 to the IP core 116, it must first send this message 140 to an independent third IP core, the TRM 111, according to the invention. The TRM 111 checks if the message 140 is faulty. This verification is done on the basis of assertions that the TRM needs to know a priori. These representations may relate to the state of the overall system, the identity of the sender, the time of the message, and the content of the message. If all the assertions evaluated by the TRM are correct, then the TRM sends the reset message 141 to the TII interface of the IP core 115.
  • the architecture it must be ensured by the architecture that only the (privileged) TRM 111 is able to handle messages to the TII interface of a non-privileged IP core.
  • the implementation of a non-privileged IP core must ensure that control messages (such as the reset message) that could cause an IP core failure can only be received via the TII interface. Therefore, according to the invention, it is not possible for a nonprivileged IP core to directly send a control message to another unprivileged IP core.
  • the error detection of the control messages via assurances can be regarded as insufficient.
  • three parallel-running IP cores need the control commands that are included in the control are embedded, calculate.
  • the TRM compares these three control messages and sends a corresponding message to the TII interface of the receiver only if at least two of these messages are identical. This masks any error in one of the three sending IP cores.
  • these three parallel control messages must come from three independent SoCs to prevent a common-mode error that can occur within a single SoC.
  • This invention substantially improves the reliability of a SoC by preventing a faulty IP core from causing the failure of another IP core.
  • the error detection in the received IP core does not make sense, since the receiving IP core can not correctly execute its own error detection in the event of an error.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)
  • Multi Processors (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Fehlererkennung in einem System-on-Chip (SoC) bestehend aus einer Anzahl von IP-Cores, wobei jedes IP-Core eine Fault-Containment Unit ist, und wo die IP-Cores über ein Network-on-Chip mittels Nachrichten miteinander kommunizieren und wobei ein ausgezeichnetes IP-Core einen TRM (Trusted Resource Monitor) realisiert, wobei eine fehlerhafte Steuerungsnachricht, die von einem nicht privilegierten IP-Core an ein anderes nicht privilegierten IP-Core gesendet wird, von einer (unabhängigen) Fault-Containment Unit erkannt und verworfen wird, so dass diese fehlerhafte Steuerungsnachricht keinen Ausfall des Nachrichtenempfängers verursachen kann.

Description

SYSTEM-ON-CHIP FEHLERERKENNUNG
Diese Erfindung betrifft ein Verfahren und eine Vorrichtung zur Verbesserung der Zuverlässigkeit eines System-on-Chips in einem eingebetteten Computersystem.
Insbesondere betrifft die Erfindung ein Verfahren zur Fehlererkennung in einem System-on- Chip (SoC) bestehend aus einer Anzahl von IP-Cores, wobei jedes IP-Core eine Fault- Containment Unit ist, und wo die IP-Cores über ein Network-on-Chip mittels Nachrichten miteinander kommunizieren und wobei ein ausgezeichnetes IP-Core einen TRM (Trusted Resource Monitor) realisiert.
Unter einem System-on-Chip (SoC) versteht man ein System, bei dem der Grossteil der Systemfunktionen auf einem einzigen Stück Silizium integriert sind. Aufgrund von Pollack's Regel (Borkar, S. (2007) Thousand-Core Chips, A Technology Perspective, Proc. of the 4401 ACM IEEE Design Automation Conference, p. 746-749, ACM Press, New York) bestehen leistungsfähige SoCs aus einer Anzahl von IP-Cores, die über ein Network-on-Chip kommunizieren. Ein IP-Core ist eine Hardware /Software Komponente, die eine vorgegebene Funktion erfüllt. Die Kommunikation von IP-Cores kann entweder über den Zugriff der IP-Cores auf einen gemeinsamen Speicher oder über Nachrichten erfolgen. In der Anmeldung PCT/AT 2009/00207 wird eine SoC Architektur vorgestellt, bei der die IP-Cores ausschließlich über Nachrichten kommunizieren.
Die vorliegende Erfindung verfolgt das Ziel zu verhindern, dass ein fehlerhaftes IP-Core eines SoCs andere, vom Fehler nicht unmittelbar betroffene IP-Cores, zum Ausfall bringt.
Die vorliegende Erfindung hat somit zum Ziel, in einem System-on-Chip (SoC) in dem eine Vielzahl von Komponenten (IP-Cores) ausschließlich mittels Nachrichten kommunizieren, zu verhindern, dass sich ein Fehler eines IP-Cores auf die anderen, vom Fehler nicht unmittelbar betroffenen IP-Cores, fortpflanzt. Dieses Ziel wird dadurch erreicht, dass eine fehlerhafte Steuerungsnachricht, die von einem nicht privilegierten IP-Core an ein anderes nicht privilegierten IP-Core gesendet wird, von einer (per Definition unabhängigen) Fault- Containment Unit erkannt und verworfen wird, so dass diese fehlerhafte Steuerungsnachricht keinen Ausfall des Nachrichtenempfängers verursachen kann.
Es kann jede Nachricht eines IP-Cores, die einen Ausfall eines anderen IP-Cores hervorrufen kann, von einem dritten IP-Core überprüft und gegebenenfalls verworfen werden, um zu verhindem, dass diese fehlerhafte Nachricht die von einem fehlerhaften IP-Core gesendet wird, den Ausfall eines anderer IP-Cores bewirken kann.
Besondere Vorteile ergeben sich wenn jede Steuerungsnachricht, die von einem nicht privilegierten IP-Core an ein anderes nicht privilegiertes IP-Core gesendet werden soll, zuerst an ein drittes IP-Core gesendet wird, wobei dieses dritte IP-Core die Nachricht überprüft, und wobei, falls die Nachricht nicht fehlerhaft ist, die Nachricht von diesem dritten IP-Core an den beabsichtigten endgültigen Empfänger weitergeleitet wird.
Das überprüfende IP-Core kann eine Nachricht als fehlerhaft klassifizieren, wenn die Evaluierung einer der dem überprüfenden IP-Core a priori bekannten Zusicherung den Wert falsch hat.
Mit Vorteil ist das dritte IP-Core der TRM.
Weiters ist es günstig, wenn der TRM nur Nachrichten von einem Sender, der berechtigt ist, eine Steuerungsnachricht an das in der Nachricht angeführte IP-Core zu senden, weiterleitet.
Außerdem kann vorgesehen sein, dass nur der TRM eine Steuerungsnachricht an die TII (technology-independent interface) eines nicht privilegiertes IP-Core senden kann.
Zweckmäßig ist es, wenn jede Steuerungsnachricht an die TII Schnittstelle eines IP-Cores gesendet werden muss.
Weiters kann vorgesehen sein, dass mindestens drei Nachrichten, jede von einem anderen IP-Core, innerhalb eines vorgegebenen Zeitintervalls an den TRM gesendet werden müssen, und wo der empfangende TRM überprüft, ob mindesten zwei der drei Nachrichten denselben Befehl enthalten, ehe diese Nachricht an die TII Schnittstelle des angesprochenen IP- Cores weitergeleitet wird.
Außerdem kann vorgesehen sein, dass mindestens drei Nachrichten, jede von einem anderen SoC, innerhalb eines vorgegebenen Zeitintervalls an den TRM gesendet werden müssen, und wo der empfangende TRM überprüft, ob mindesten zwei der drei Nachrichten denselben Befehl enthalten, ehe diese Nachricht an die TII Schnittstelle des angesprochenen IP-Cores weitergeleitet wird. Zweckmäßig ist es, wenn die Funktionen des privilegierten Subsystems, welches aus dem TRM, dem Network on Chip und den Network Interfaces besteht, durch fehlerkorrigierende Codes abgesichert werden.
Außerdem betrifft die Erfindung eine Vorrichtung zum Durchführen eines oben beschriebenen Verfahrens, wobei ein oder mehrere bzw. alle Verfahrensschritte direkt in der Hardware des SoCs ausgeführt werden.
Das vorab beschriebene Ziel und andere neue Eigenschaften der vorliegenden Erfindung werden in den angeführten Abbildungen erläutert.
Fig. 1 zeigt den Aufbau eines System-on-Chip (SoC). Fig. 2 zeigt die Struktur eines IP-Cores eines SoCs.
Fig. 3 zeigt das Senden einer Steuerungsnachricht von einem IP-Core an ein anderes IP-Core eines SoCs.
Im folgenden Abschnitt wird eine Realisierung des neuen Verfahrens an einem möglichen Beispiel eines SoCs mit acht IP-Cores gezeigt.
Fig. 1 zeigt einen SoC 100 mit den acht IP-Cores 111, 112, 113, 114, 115, 116, 117 und 118. Diese acht IP-Cores können über ein Network-on-Chip 101 Nachrichten austauschen. Jedes IP-Core, z.B., das IP-Core 114, wird über ein Netzwerk-Interface (NI) 102 an das NoC 101 angebunden. Eines dieser acht IP-Cores, z.B. das IP-Core 111, ist ein privilegiertes IP-Core, das Trusted Resource Monitor (TRM) genannt wird, während die übrigen sieben IP-Cores 112, 113, 114, 115, 116, 117 und 118 nicht privilegierte IP-Cores sind. Der TRM 111, das Network on Chip 101 und die acht Network Interfaces 102 bilden das privilegierte Subsystem des SoC 100. Ein Fehler in diesem privilegierten Subsystem kann zu einem Ausfall des gesamten SoC führen. Deshalb sollen erfindungsgemäss die Funktionen des privilegierten Subsystems durch besondere Fehlersicherungsmaßnahmen, wie zum Beispiel durch den Einsatz von fehlerkorrigierenden Codes, abgesichert werden. Durch entsprechende fehlerkorrigierende Codes können transiente und permanente Hardwarefehler im privilegierten Subsystem erkannt und korrigiert werden.
Jedes der sieben nicht-privilegierten IP-Cores bildet eine eigene Fault-Containment Unit (FCU) (Kopetz, H. (1997). Real-Time Systems, Design Principles for Distributed Embedded Applications; ISBN: 0-7923-9894-7. Boston. Kluwer Academic Publishers.), d.h. die Folgen eines beliebigen Software- oder Hardwarefehlers innerhalb eines nicht privilegierten IP-Cores können nur die Funktionen des betroffenen IP-Cores unmittelbar stören, sie können sich jedoch auf die Funktionen der anderen IP-Cores nur mittelbar über fehlerhafte Nachrichten auswirken. Wenn es gelingt, fehlerhafte Nachrichten zu erkennen und zu verwerfen, so können sich die mittelbaren Folgen eines IP-Core Fehlers nicht fortpflanzen. In der PCT/AT 2006/00278 wird eine Architektur beschrieben, in der temporale Fehler von IP-Core Nachrichten durch das privilegierte Netzwerk Interface (NI) 102 des NoC 101 erkannt und verworfen werden. Entsprechend der PCT/AT 2009/00207 (WO 2009/140707) ist es nur dem TRM 111 erlaubt, temporalen Parameter in das NI 102 zu schreiben, um zu verhindern, dass ein fehlerhaftes IP-Core die Sendeparameter einer Nachricht selbständig ändern kann. Das Verfahren wie in der PCT/AT 2006/00278 beschrieben verhindert jedoch nicht, dass inhaltlich falsche Steuerungsnachrichten von einem nicht privilegiertem fehlerhaften IP-Core an die anderen nicht privilegierten IP-Cores gesendet werden können.
Fig. 2 zeigt den Aufbau eines nicht privilegierten IP-Cores, z.B. das IP-Core 114. Dieses IP- Core verfügt über vier äußere Schnittstellen: 211, 212, 213 und 122. Die drei Nachrichtenschnittstellen 211, 212 und 213 sind mit dem Network Interface (NI) 102 der Fig. 1 verbunden. Die Schnittstelle 122 ist eine lokale Schnittstelle des IP-Cores, über die eine Verbindung zur Außenwelt des SoC 100 realisiert wird. Diese Schnittstelle 122 kann z.B. ein In- put/Output Netzwerk (z.B. ein CAN Netzwerk) oder eine drahtlose Verbindung zur Umgebung des SoC 100 sein.
Die Nachrichtenschnittstelle 211 bezeichnen wir als Linking Interface (LIF) des IP-Cores 114. Über das LIF 211 werden die Dienste des IP-Cores 114 den sieben anderen IP-Cores des SoC 100 angeboten.
Die Nachrichtenschnittstelle 212 bezeichnen wird als Technology-Dependant Interface (TDI), die es dem Wartungstechniker ermöglicht, mit den internen Funktionen des IP-Cores 114 zu kommunizieren. Da das Format und der Inhalt dieser TDI Nachrichten von der konkreten Implementierungstechnik des IP-Cores abhängen, ist diese Schnittstelle implementierungsabhängig.
Die Nachrichtenschnittstelle 213 bezeichnen wir als TII (Technology-Independent Interface). Über diese TII Schnittstelle 213 wird die Konfiguration und die Ablaufsteuerung des IP- Cores 114 mittels Steuerungsnachrichten realisiert. Eine Steuerungsnachricht ist eine Nachricht, die den Ablauf der Berechnung in einem IP Core steuert. Zum Beispiel wird mittels Steuerungsnachrichten ein Hardware-Reset des gesamten IP-Cores 114 veranlasst, oder der Start einer Programmausführung oder die Terminierung einer Programmausführung des IP- Cores 114 angeordnet. Weiters kann mittels Steuerungsnachrichten die Konfiguration oder eine Rekonfiguration des SoCs veranlasst werden. Eine fehlerhafte Steuerungsnachricht, die an die TII Schnittstelle des IP-Cores gesendet wird, kann den Ausfall des IP-Cores 114 bewirken, z.B. wenn während der korrekten Arbeit des IP-Cores 114 plötzlich eine fehlerhafte Hardware-Reset Nachricht an der TII Schnittstelle 213 empfangen wird. In Fig. 2 ist auch der innere Aufbau des IP-Cores 114 dargestellt. Auf der untersten Ebene 201 befindet sich IP-Core Hardware, die die im IP-Core 114 geladene Software ausführt. Auf der nächsten Ebene 202 befindet sich das IP-Core interne Betriebssystem und auf der Ebene 203 befindet sich die IP-Core interne Middleware. Schließlich befindet auf der Ebene 204 die Applikationssoftware. Die IP-Core interne Schnittstelle 214 zwischen der Middleware 203 und der Applikationssoftware 204 bezeichnet man als das Application-Program-Interface (API) 214. Die Nachrichten, die über die TII Schnittstelle 213 empfangen werden, kommunizieren entweder direkt mit der IP-Core Hardware 201 (z.B. eine Reset Nachricht), mit dem Betriebssystem 202 (z.B. eine Steuerungsnachricht zur Terminierung eines Prozesses) oder der Middleware 203, jedoch nicht mit der Applikationssoftware 204. Es ist deshalb der Applikationssoftware eines nicht privilegierten IP-Cores nicht möglich, fehlerhafte Steuerungsnachrichten, die über die TII Schnittstelle 213 eintreffen, zu erkennen.
Fig. 3 zeigt das Senden einer Steuerungsnachricht an die TII Schnittstelle eines nicht privilegierten IP-Cores. Wenn z.B. das IP-Core 115 eine Reset Nachricht 140 an das IP-Core 116 senden will, so muss es diese Nachricht 140 erfindungsgemäß zuerst an ein unabhängiges drittes IP-Core, den TRM 111 senden. Der TRM 111 überprüft ob die Nachricht 140 fehlerhaft ist. Diese Überprüfung erfolgt anhand von Zusicherungen (Assertions), die dem TRM a priori bekannt sein müssen. Diese Zusicherungen können sich auf den Zustand des Gesamtsystems, auf die Identität des Senders, den Zeitpunkt der Nachricht und dem Inhalt der Nachricht beziehen. Wenn alle von der TRM evaluierten Zusicherungen richtig sind, dann sendet das TRM die Reset Nachricht 141 an das TII Interface des IP-Cores 115. Erfindungsgemäß muss durch die Architektur sichergestellt werden, dass nur der (privilegierte) TRM 111 in der Lage ist, Nachrichten an das TII Interface eines nicht privilegierten IP-Cores zu senden. Die Implementierung eines nicht privilegierten IP-Cores muss sicherstellen, dass Steuerungsnachrichten (wie zum Beispiel die Reset Nachricht), die zu einem Ausfall eines IP- Cores führen könnten, nur über das TII Interface empfangen werden können. Erfindungsgemäß ist es daher nicht möglich, dass ein nicht privilegiertes IP-Core direkt eine Steuerungsnachricht an ein anderes nicht privilegiertes IP-Core senden kann.
In einem sicherheitsrelevanten System kann die Fehlererkennung der Steuerungsnachrichten über Zusicherungen als nicht ausreichend betrachtet werden. In einem solchen System müssen drei parallel laufende IP-Cores die Steuerungsbefehle, die in den Steuerungsnach- richten eingebettete sind, errechnen. Der TRM vergleicht diese drei Steuerungsnachrichten und sendet eine entsprechende Nachricht an das TII Interface des Empfängers nur weiter, wenn mindestens zwei dieser Nachrichten identisch sind. Damit wird ein beliebiger Fehler in einem der drei sendenden IP-Cores maskiert. In hochzuverlässigen Systemen müssen diese drei parallelen Steuerungsnachrichten von drei unabhängigen SoCs stammen, um einen common-mode Fehler, der innerhalb eines einzigen SoCs auftreten kann, zu verhindern.
Durch diese Erfindung wird die Zuverlässigkeit eines SoC wesentlich verbessert, da verhindert wird, dass ein fehlerhaftes IP-Core den Ausfall eines anderen IP-Cores verursachen kann. Die Fehlererkennung im empfangenen IP Core ist nicht sinnvoll, da das empfangende IP-Core im Fehlerfall nicht die eigene Fehlererkennung korrekt ausführen kann.
Die hier beschriebene konkrete Realisierung der Erfindung stellt nur eine von vielen Realisierungsmöglichkeiten dieser Erfindung dar.

Claims

ANSPRÜCHE
1. Verfahren zur Fehlererkennung in einem System-on-Chip (SoC) bestehend aus einer Anzahl von IP-Cores, wobei jedes IP-Core eine Fault-Containment Unit ist, und wo die IP- Cores über ein Network-on-Chip mittels Nachrichten miteinander kommunizieren und wobei ein ausgezeichnetes IP-Core einen TRM (Trusted Resource Monitor) realisiert, dadurch gekennzeichnet, dass eine fehlerhafte Steuerungsnachricht, die von einem nicht privilegierten IP-Core an ein anderes nicht privilegierten IP-Core gesendet wird, von einer Fault- Containment Unit erkannt und verworfen wird, so dass diese fehlerhafte Steuerungsnachricht keinen Ausfall des Nachrichtenempfängers verursachen kann.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass jede Steuerungsnachricht, die von einem nicht privilegierten IP-Core an ein anderes nicht privilegiertes IP-Core gesendet werden soll, zuerst an ein drittes IP-Core gesendet wird, wobei dieses dritte IP-Core die Nachricht überprüft, und wobei, falls die Nachricht nicht fehlerhaft ist, die Nachricht von diesem dritten IP-Core an den beabsichtigten endgültigen Empfänger weiter geleitet wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das überprüfende IP- Core eine Nachricht als fehlerhaft klassifiziert, wenn die Evaluierung einer der dem überprüfenden IP-Core a priori bekannten Zusicherung den Wert falsch hat.
4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das dritte IP-Core der TRM ist.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der TRM nur Nachrichten von einem Sender, der berechtigt ist, eine Steuerungsnachricht an das in der Nachricht angeführte IP-Core zu senden, weiterleitet.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass nur der TRM eine Steuerungsnachricht an die TII (technology-independent interface) eines nicht privilegiertes IP-Core senden kann.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass jede Steuerungsnachricht an die TII Schnittstelle eines IP-Cores gesendet werden muss.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass mindestens drei Nachrichten, jede von einem anderen IP-Core, innerhalb eines vorgegebenen Zeitintervalls an den TRM gesendet werden müssen, und wo der empfangende TRM überprüft, ob mindesten zwei der drei Nachrichten denselben Befehl enthalten, ehe diese Nachricht an die TII Schnittstelle des angesprochenen IP-Cores weitergeleitet wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass mindestens drei Nachrichten, jede von einem anderen SoC, innerhalb eines vorgegebenen Zeitintervalls an den TRM gesendet werden müssen, und wo der empfangende TRM überprüft, ob mindesten zwei der drei Nachrichten denselben Befehl enthalten, ehe diese Nachricht an die TII Schnittstelle des angesprochenen IP-Cores weitergeleitet wird.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Funktionen des privilegierten Subsystems, welches aus dem TRM, dem Network on Chip und den Network Interfaces besteht, durch fehlerkorrigierende Codes abgesichert werden.
11. Vorrichtung zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass ein oder mehrere bzw. alle Verfahrensschritte direkt in der Hardware des SoCs ausgeführt werden.
EP10744654A 2009-07-09 2010-07-07 System-on-chip fehlererkennung Withdrawn EP2452264A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AT10772009 2009-07-09
PCT/AT2010/000248 WO2011003121A1 (de) 2009-07-09 2010-07-07 System-on-chip fehlererkennung

Publications (1)

Publication Number Publication Date
EP2452264A1 true EP2452264A1 (de) 2012-05-16

Family

ID=43012654

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10744654A Withdrawn EP2452264A1 (de) 2009-07-09 2010-07-07 System-on-chip fehlererkennung

Country Status (5)

Country Link
US (1) US8732522B2 (de)
EP (1) EP2452264A1 (de)
JP (1) JP2012532385A (de)
CN (1) CN102473121A (de)
WO (1) WO2011003121A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9164852B2 (en) 2009-07-09 2015-10-20 Fts Computertechnik Gmbh System on chip fault detection
US9575859B2 (en) 2012-02-22 2017-02-21 Fts Computertechnik Gmbh Method for fault recognition in a system of systems
AT512665B1 (de) * 2012-03-20 2013-12-15 Fts Computertechnik Gmbh Verfahren und Apparat zur Bildung von Software Fault Containment Units in einem verteilten Echtzeitsystem
US9160617B2 (en) 2012-09-28 2015-10-13 International Business Machines Corporation Faulty core recovery mechanisms for a three-dimensional network on a processor array
US8990616B2 (en) 2012-09-28 2015-03-24 International Business Machines Corporation Final faulty core recovery mechanisms for a two-dimensional network on a processor array
AT515454A3 (de) * 2013-03-14 2018-07-15 Fts Computertechnik Gmbh Verfahren zur Behandlung von Fehlern in einem zentralen Steuergerät sowie Steuergerät
EP3036649B1 (de) * 2013-08-21 2018-08-01 Siemens AG Österreich Verfahren und schaltungsanordnung zur zeitlichen eingrenzung und trennung von zugriffen in einem ein-chip-system
FR3026869B1 (fr) * 2014-10-07 2016-10-28 Sagem Defense Securite Systeme embarque sur puce a haute surete de fonctionnement
CN105991384B (zh) * 2016-06-23 2019-03-08 天津大学 兼容时间触发以太网与1553b的航天以太网通信方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09153020A (ja) * 1995-11-29 1997-06-10 Hitachi Ltd 疎結合計算機システム
US7007099B1 (en) * 1999-05-03 2006-02-28 Lucent Technologies Inc. High speed multi-port serial-to-PCI bus interface
AT411948B (de) * 2002-06-13 2004-07-26 Fts Computertechnik Gmbh Kommunikationsverfahren und apparat zur übertragung von zeitgesteuerten und ereignisgesteuerten ethernet nachrichten
US7606190B2 (en) * 2002-10-18 2009-10-20 Kineto Wireless, Inc. Apparatus and messages for interworking between unlicensed access network and GPRS network for data services
JP2009524952A (ja) * 2006-01-27 2009-07-02 エフテーエス コンピューターテヒニク ゲゼルシャフト ミット ベシュレンクテル ハフツング 時間制御型のセキュアな通信
ATE527780T1 (de) * 2007-04-11 2011-10-15 Fts Computertechnik Gmbh Kommunikationsverfahren und apparat zur effizienten und sicheren übertragung von tt- ethernet nachrichten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2011003121A1 *

Also Published As

Publication number Publication date
US8732522B2 (en) 2014-05-20
JP2012532385A (ja) 2012-12-13
WO2011003121A1 (de) 2011-01-13
CN102473121A (zh) 2012-05-23
US20120124411A1 (en) 2012-05-17

Similar Documents

Publication Publication Date Title
WO2011003121A1 (de) System-on-chip fehlererkennung
DE3687777T2 (de) Verfahren und geraet zur sicherstellung eines datenuebertragungssystems.
DE3879069T2 (de) Schwellenalarme zur Verarbeitung von Fehlern in einem Multiplex-Kommunikationssystem.
DE3879071T2 (de) Verwaltung einer defekten Hilfsquelle in einem Multiplex-Kommunikationssystem.
EP1789857B1 (de) Datenübertragungsverfahren und automatisierungssystem zum einsatz eines solchen datenübertragungsverfahrens
EP3662601A1 (de) Konzept zum unidirektionalen übertragen von daten
DE102010012904B4 (de) Systeme zum Durchführen eines Tests
DE69433468T2 (de) Logischer Schaltkreis mit Fehlernachweisfunktion
DE102015119643A1 (de) Verfahren und Vorrichtungen zur Bereitstellung von Redundanz in einem Prozesssteuerungssystem
DE102010010198A1 (de) System und Verfahren zum Testen eines Moduls
DE102014111361A1 (de) Verfahren zum Betreiben einer Sicherheitssteuerung und Automatisierungsnetzwerk mit einer solchen Sicherheitssteuerung
EP3201774B1 (de) Verteiltes echtzeitcomputersystem und zeitgesteuerte verteilereinheit
EP3061213B1 (de) Verfahren zur übertragung von nachrichten in einem computernetzwerk sowie computernetzwerk
DE102013017951A1 (de) Elektronische Steuervorrichtung und Verfahren zum Überprüfen einer Rücksetzfunktion
DE102004044764B4 (de) Datenübertragungsverfahren und Automatisierungssystem zum Einsatz eines solchen Datenübertragungsverfahrens
DE102017103147A1 (de) Alarmabwicklungs-Schaltungsanordnung und Verfahren zur Abwicklung eines Alarms
US9524259B2 (en) Method for operating an automation device to reduce dead time on account of a physical interruption in a ring or a failed unit
CN110381035A (zh) 网络安全测试方法、装置、计算机设备及可读存储介质
DE3138989A1 (de) Zusaetzliche funktionseinheit in einem mikroprozessor, mikroprozessorsystem und verfahren zu seinem betrieb
EP2250560B1 (de) Verfahren zur erhöhung der robustheit von computersystemen sowie computersystem
EP4127934A1 (de) Verfahren und sicherheitsgerichtetes system zum ausführen von sicherheitsfunktionen
DE102013204371B4 (de) Verfahren und Bussystem zum protokollunabhängigen Übertragen von Standarddatenpaketen mit Sicherheitsdaten
DE112019002278T5 (de) Integritätsüberwachungsperipheriegerät für mikrocontroller- und prozessor-eingangs-/ausgangs-pins
US9164852B2 (en) System on chip fault detection
EP3696629A1 (de) Verfahren zur überprüfung einer industriellen anlage, computerprogramm, computerlesbares medium und system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20111215

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20141114

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150325