DE112022003757T5 - TRANSFERRING DATA BETWEEN REGIONS WITH VARYING SECURITY INTEGRITY LEVELS IN A SYSTEM ON A CHIP - Google Patents

Abstract

In various examples, a system includes memory operating within a first risk level and circuitry operating within a second risk level indicating a higher risk than the first risk level. The circuitry reads and/or writes data to a first memory address within the memory and reads and/or writes error detection code to a second memory address within the memory.

Description

PRIORITY CLAIM

This application claims the benefit of Indian Provisional Application No. 202111034491 entitled “TRANSMITTING DATA BETWEEN REGIONS OF VARYING SAFETY INTEGRITY LEVELS IN A SYSTEM ON A CHIP,” filed July 30, 2021, and U.S. patent application No. 17/477,360 entitled “TRANSMITTING DATA BETWEEN REGIONS OF VARYING SAFETY INTEGRITY LEVELS IN A SYSTEM ON A CHIP”, filed September 16, 2021, the entire contents of which are hereby incorporated by reference.

TECHNICAL AREA

At least one embodiment relates to accessing memory in a second region of a circuit through a first region of the circuit. For example, at least one embodiment relates to a system on a chip implementing various novel techniques described herein. According to another example, at least one embodiment relates to an autonomous vehicle including such a system on a chip.

GENERAL STATE OF THE ART

The Automotive Safety Integrity Level (“ASIL”) is a risk classification system for the functional safety of road vehicles defined by the International Organization for Standardization (“ISO”) Functional Safety Standard 26262. In this risk classification system, there are four risk classification levels: ASIL-A, ASIL-B, ASIL-C and ASIL-D, with ASIL-D being the highest risk classification level. For example, components designated ASIL-D have higher safety requirements than components with lower risk classification levels (such as ASIL-B) and may be more expensive. Within many automotive platforms, at least some safety services are performed by an external control unit when specific faults are detected in a system on a chip (“SoC”) of the automotive vehicle that controls various driving functions of an autonomous or semi-autonomous vehicle. In general, the external control unit may operate at a higher risk level (e.g. ASIL-D) than the automotive SoC (e.g. ASIL-B). Unfortunately, such external controllers introduce latency and can be expensive because they require separate components that are also present in the automotive SoC, such as DRAM, non-volatile memory, etc., each of which occupies space within the automotive platform (e.g., on a circuit board).

BRIEF DESCRIPTION OF THE DRAWINGS

• 1 ist eine Veranschaulichung einer beispielhaften Kraftfahrzeugplattform gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 2 ist eine Veranschaulichung für (eine) beispielhafte Schnittstelle(n), die eine in ein Kraftfahrzeug-SoC integrierte Sicherheitsinsel mit anderen Komponenten des Fahrzeug-SoC verbinden, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 3 ist ein Ablaufdiagramm, das ein Verfahren für einen Wechsel der Sicherheitsinsel zwischen Kokon- und Nichtisolationsmodus zeigt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 4 ist eine Veranschaulichung für (eine) beispielhafte Störungsschnittstelle(n), die Störungen von den anderen Komponenten des Kraftfahrzeug-SoC an die Sicherheitsinsel kommunizieren, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 5A ist ein Ablaufdiagramm, das ein Verfahren zum Kommunizieren von Störungen an die Sicherheitsinsel zeigt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 5B ist ein Ablaufdiagramm, das ein Verfahren zeigt, das ein Prozessor verwenden kann, um von einem SoC-Störungsaggregator empfangene Interrupts zu verarbeiten, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 5C ist ein Ablaufdiagramm, das ein Verfahren zeigt, das die SI 110 verwenden kann, um korrigierte und unkorrigierte Fehlersignale zu verarbeiten, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 5D ist ein Ablaufdiagramm, das ein Verfahren zeigt, das die SI 110 verwenden kann, um ein SoC-Störungsaggregatorsignal zu verarbeiten, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 6A veranschaulicht ein beispielhaftes Signal-Zeitsteuerungs-Diagramm für Signale, die durch den Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit geringem Schweregrad (z. B. dem Minimalwert) erklärt wurde, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 6B veranschaulicht ein beispielhaftes Signal-Zeitsteuerungs-Diagramm für Signale, die durch den Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit hohem Schweregrad (z. B. dem Maximalwert) erklärt wurde, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 6C veranschaulicht ein beispielhaftes Signal-Zeitsteuerungs-Diagramm für Signale, die durch den Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler (z. B. der Maximalwert) erklärt wurde, die Sicherheitsinsel aber den Mailbox-Interrupt nicht empfängt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 7 ist ein Ablaufdiagramm, das ein Verfahren zum Schreiben von Daten in eine Ausgliederung zeigt, die in einem flüchtigen Speicher definiert ist, der durch die Sicherheitsinsel und die anderen Komponenten des Kraftfahrzeug-SoC gemeinsam genutzt wird, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 8 veranschaulicht ein Beispiel eines Fehlererkennungsblocks der Sicherheitsinsel, die das Verfahren der 7 durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 9 ist ein Ablaufdiagramm, das ein Verfahren zum Lesen von Daten aus der Ausgliederung zeigt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 10 veranschaulicht ein Beispiel eines Fehlererkennungsblocks der Sicherheitsinsel, die das Verfahren der 9 durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 11 ist eine Veranschaulichung eines Blockdiagramms, das Fehlermeldungen zeigt, die durch den Fehlererkennungsblock generiert werden, wenn der Fehlererkennungsblock einen Egress- und Ingress-Zeitgeber beinhaltet oder mit diesen verbunden ist, gemäß einigen Ausführungsformen;
• 12 ist eine Veranschaulichung eines beispielhaften autonomen Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 13 ist ein Beispiel für die Positionen und Sichtfelder von Kameras für das beispielhafte autonome Fahrzeug der 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 14 ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug der 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 15 ist ein Systemdiagramm für die Kommunikation zwischen dem/den Cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug aus 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung; und
• 16 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

The present systems and methods for isolating a region of a system on a chip are described in detail below with reference to the accompanying drawing figures, in which:

• 1 is an illustration of an exemplary automotive platform in accordance with some embodiments of the present disclosure;
• 2 is an illustration of example interface(s) connecting a security island integrated into an automotive SoC to other components of the vehicle SoC, in accordance with some embodiments of the present disclosure;
• 3 is a flow diagram illustrating a method for transitioning the safety island between cocoon and non-isolation modes, according to some embodiments of the present disclosure;
• 4 is an illustration of exemplary fault interface(s) that communicate faults from the other components of the automotive SoC to the safety island, in accordance with some embodiments of the present disclosure;
• 5A is a flow diagram illustrating a method for communicating faults to the safety island, according to some embodiments of the present disclosure;
• 5B is a flow diagram illustrating a method a processor may use to process interrupts received from a SoC disturbance aggregator, according to some embodiments of the present disclosure;
• 5C is a flow diagram illustrating a method that SI 110 may use to process corrected and uncorrected error signals, according to some embodiments of the present disclosure;
• 5D is a flow diagram illustrating a method that SI 110 may use to process a SoC fault aggregator signal, according to some embodiments of the present disclosure;
• 6A illustrates an example signal timing diagram for signals received and transmitted by the safety island processor after an uncorrected low severity (e.g., minimum value) error is declared, according to some embodiments of the present disclosure;
• 6B illustrates an example signal timing diagram for signals received and transmitted by the safety island processor after an uncorrected high severity (e.g., maximum value) error is declared, according to some embodiments of the present disclosure;
• 6C illustrates an example signal timing diagram for signals received and transmitted by the safety island processor after an uncorrected error (e.g., the maximum value) is declared but the safety island does not receive the mailbox interrupt, according to some embodiments of the present disclosure;
• 7 is a flow diagram illustrating a method for writing data to a partition defined in a volatile memory shared by the security island and the other components of the automotive SoC, according to some embodiments of the present disclosure;
• 8th illustrates an example of a safety island fault detection block that implements the 7 performs, according to some embodiments of the present disclosure;
• 9 is a flow diagram illustrating a method for reading data from the spin-off, according to some embodiments of the present disclosure;
• 10 illustrates an example of a safety island fault detection block that implements the 9 performs, according to some embodiments of the present disclosure;
• 11 is an illustration of a block diagram showing error messages generated by the error detection block when the error detection block includes or is coupled to egress and ingress timers, according to some embodiments;
• 12 is an illustration of an example autonomous vehicle, according to some embodiments of the present disclosure;
• 13 is an example of the positions and fields of view of cameras for the exemplary autonomous vehicle of the 12 according to some embodiments of the present disclosure;
• 14 is a block diagram of an example system architecture for the example autonomous vehicle of the 12 according to some embodiments of the present disclosure;
• 15 is a system diagram for the communication between the cloud-based server(s) and the example autonomous vehicle from 12 according to some embodiments of the present disclosure; and
• 16 is a block diagram of an example computing device suitable for use in implementing some embodiments of the present disclosure.

DETAILED DESCRIPTION

Systems and methods are disclosed relating to isolating a region of a circuit operating at a higher risk level (e.g., ASIL-D) from other regions of the circuit operating at a lower risk level (e.g., ASIL-B). For example, a region or "island" dedicated to functional safety may be isolated from other components on a system on a chip ("SoC"), such as an automotive SoC (e.g., communicative). 1 is an illustration of an exemplary automotive platform 100 according to at least one embodiment. The automotive platform 100 may include an autonomous or semi-autonomous vehicle, such as an autonomous vehicle 1200 (see 12 ), implement. The motor vehicle platform 100 includes a processing system 102 of the power vehicle that can implement a level of driving autonomy greater than Level 0 (no driving automation) as defined by the Society of Automotive Engineers (“SAE”). For example, the processing system 102 of the motor vehicle can implement Level 2 (partial driving automation) to Level 5 (full driving automation) as defined by the SAE. A Level 2 system may be referred to as an Advanced Driver Assistance System (“ADAS”).

The automotive processing system 102 includes at least one automotive SoC 104. The automotive SoC 104 performs at least some functions, but may outsource one or more safety functions to an optional external controller 106 (e.g., including an external ASIL-D microcontroller). The optional external controller 106 may operate under and conform to a higher risk classification level (e.g., ASIL-D) than the automotive SoC 104. In embodiments that include the optional external controller 106, when a fault occurs in the automotive SoC 104, that fault is communicated to the optional external controller 106, which may take one or more actions to return the automotive platform 100 to a safe state. Thus, at least a portion of the safety functions may be performed by the optional external controller 106. However, the optional external controller 106 may introduce latency and be expensive because it requires separate components such as DRAM, non-volatile memory, etc., each of which occupies space within the automotive platform 100 (e.g., on a circuit board).

To avoid at least some of the latency and costs introduced by the optional external control unit 106, the automotive platform 100 of the 1 a functional safety island or safety island (“SI”) 110 integrated into the automotive SoC 104. The SI 110 may be implemented as a compute cluster that operates under and conforms to a higher risk classification level (e.g., ASIL-D) than the rest of the automotive SoC 104. The SI 110 may perform at least a portion of the functions typically performed by the optional external control unit 106. The presence of the SI 110 may eliminate the optional external control unit 106 entirely or may be implemented using a less complex and/or less expensive external control unit. For example, the optional external control unit 106, when present, may perform one or more legacy functions such as providing communication on a Controller Area Network Bus (“CAN” bus), providing reset control for the automotive SoC 104, and/or performing in-vehicle voltage monitoring.

In addition to the automotive SoC 104 and the optional external control unit 106 (if present), the automotive processing system 102 may include a first (SoC) clock 112 for the automotive SoC 104, a second (SI) clock 114 for the SI 110, and an integrated circuit (“IC”) 116 for power management. Each of the components of the automotive processing system 102 is at least partially implemented in hardware. Logic components of the automotive processing system 102 (e.g., the automotive SoC 104 and the optional external control unit 106) are each typically implemented in hardware logic circuits within one or more integrated circuit chips. The logic may be hardwired or programmable, or a combination of hardwired and programmable elements. Additionally or alternatively, certain functions of the motor vehicle processing system 102 may be implemented in software or firmware executed by an embedded microprocessor or microcontroller.

The first and second clocks 112 and 114 provide two separate clock signals to the automotive SoC 104. More specifically, a first clock signal generated by the first (SoC) clock 112 is provided to other components 160 of the automotive SoC 104 other than the SI 110, and a second clock signal generated by the second (SI) clock 114 is provided to the SI 110. Thus, the SI 110 and the other components 160 may be characterized as operating within separate clock domains. The clock domain of the SI 110 is referred to as the SI clock domain, and the clock domain of the other components 160 is referred to as the SoC clock domain. The first and second clocks 112 and 114 may each be implemented at least partially as crystal oscillators. The first (SoC) clock 112 may be connected to each of at least some of the other components 160 of the automotive SoC 104 via a first clock connection (not shown), such as a wire, a signal trace, and the like. Thus, the first (SoC) clock 112 may provide the first clock signal to the other components 160 of the automotive SoC 104 via the first clock connection (not shown). The second (SI) clock 114 may be connected to each of at least some of the components of the SI 110 via a second clock connection (not shown), such as a wire, a signal trace, and the like. Thus, the second (SI) clock 114 may provide the second clock signal to the SI 110 via the second clock connection (not shown).

The power management IC 116 supplies power to other components of the automotive processing system 102. For example, power rails or interconnections 118A-118C connect the power management IC 116 to the other components 160 of the automotive SoC 104, the SI 110, or the optional external control unit 106, respectively. The power interconnections 118A-118C help to electrically isolate the other components 160 of the automotive SoC 104, the SI 110, or the optional external control unit 106 (if present) from each other. Thus, the SI 110 can operate within a separate voltage domain from the other components 160 and the optional external control unit 106 (if present). The voltage domain of the SI 110 is referred to as the SI voltage domain, and the voltage domain of the other components 160 is referred to as the SoC voltage domain. The power management IC 116 may be implemented as one or more integrated circuits that provide sufficient power to components of the automotive processing system 102. The power connections 118A-118C may each be implemented as a conductive element, such as an electrical transmission line, a wire, a power trace, and the like.

As mentioned above, the SI 110 operates in the SI clock domain and the SI voltage domain. Together, the SI clock domain and the SI voltage domain are referred to as the SI domain. Similarly, the other components 160 operate in the SoC clock domain and the SoC voltage domain. Together, the SoC clock domain and the SoC voltage domain are referred to as the SoC domain.

The other components 160 of the automotive SoC 104 may include a central processing unit (“CPU”) main complex 120, an additional security unit 122, circuitry 124 for performing automotive SoC functions, a volatile data storage or memory 126 (e.g., dynamic random access memory (“DRAM”)), and a non-volatile data storage or memory 128. The CPU main complex 120 may be implemented as one or more processors operating at ASIL-B. In such embodiments, the automotive SoC 104 may operate at multiple or mixed ASILs since the SI 110 may operate at a higher ASIL level (e.g., ASIL-D). As non-limiting examples, the circuitry 124 may include hardware that implements one or more displays, one or more input/output ("I/O") controls of the motor vehicle, one or more memory controllers, one or more interconnects, etc. In the illustrated embodiment, the circuitry 124 is shown as including or implementing a plurality of logic blocks LB(1) - LB(N), each of which is often referred to as intellectual property ("IP"). The logic blocks LB(1) - LB(N) may be implemented within the autonomous vehicle (e.g., the 12 illustrated autonomous vehicle 1200) implement various functions.

The optional external control unit 106 may include a controller 130, a fault aggregator 132, a volatile data store or memory 136 (e.g., DRAM), and a non-volatile data store or memory 138. The optional external control unit 106 may also include one or more logic blocks (not shown) that implement the safety functions performed by the optional external control unit 106. The controller 130 may be implemented as one or more processors (e.g., microcontroller(s)) operating at ASIL-D. The controller 130 executes instructions stored in the non-volatile memory 138, such as instructions compliant with one or more Automotive Open System Architecture (“AUTOSAR”) software standards. The instructions may instruct the controller 130 to take appropriate actions when the fault aggregator 132 receives a fault from the vehicle SoC 104.

In one or more embodiments, the SI 110 includes a processor 140, an interrupt controller 141, an SI fault aggregator 142, a volatile data store or memory 146 (e.g., static random access memory ("SRAM")), and one or more logic blocks 148. The processor 140 may be implemented as a cluster of processors, such as highly rated ASIL-D safety processors. The processor 140 executes instructions 149, such as instructions compliant with the AUTOSAR software standard(s), that are obtained from the non-volatile memory 128 at boot time and stored in the volatile memory 146. The instructions 149 may instruct the processor 140 to take appropriate action when the SI fault aggregator 142 receives a fault from the other components 160 of the automotive SoC 104. The logic block(s) 148 may help implement the safety functions performed by the Sl 110.

The auxiliary safety unit 122 may be implemented as a real-time auxiliary safety processing unit and/or may be rated ASIL-B or higher. In other words, the auxiliary safety unit 122 may be at the same risk classification level as or at a higher risk classification level than other components within the SoC domain. The auxiliary security unit 122 includes a processor 150, one or more SoC fault aggregators 152, an interrupt controller 154, and one or more logic blocks referred to as mailbox(es) 156. The SI fault aggregator 142 and the fault aggregator 132 (if present) may each receive faults from the SoC fault aggregator(s) 152. The SoC fault aggregator(s) 152 may thus be connected to the fault aggregator 132 via one or more fault interfaces 170 and to the SI fault aggregator 142 via one or more fault interfaces 172. Each of the disturbance interfaces 170 and 172 includes a connection, such as a wire, a signal trace, and the like, that physically connects each of the SoC disturbance aggregator(s) 152 to a respective disturbance aggregator 132 or the SI disturbance aggregator 142.

The mailbox(es) 156 may include a first mailbox to which the processor 150 writes and from which the processor 140 reads and a second mailbox to which the processor 140 writes and from which the processor 150 reads. The mailbox(es) 156 may be used by the processor 150 (e.g., a central processing unit ("CPU") rated ASIL-B or higher) to report mailbox interrupts to the interrupt controller 141 and to receive interrupts from the interrupt controller 141. The fault interface(s) 172 thus include at least one signal conductor connecting the mailbox(es) 156 to the interrupt controller 141. Each mailbox interrupt includes a severity identifier indicating a severity of the fault. As a non-limiting example, the severity identifier may be a numeric value ranging from a minimum value (e.g., zero) to a maximum value (e.g., seven). As another non-limiting example, the interrupt may have an interrupt number encoded a priori to indicate the severity. The processor 140 and/or the processor 150 may write fault information to the mailbox(es) 156. The fault information includes information about the error(s) that generated the fault, such as the logical block name(s) in which the error occurred, diagnostic identifier(s) of the logic block, the type of fault, the severity identifier, and the like.

By integrating the SI 110 into the automotive SoC 104, it may be possible to omit a number of separate components (e.g., the volatile memory 136 and the non-volatile memory 138) from the automotive processing system 102 when the optional external control unit 106 is also omitted. Nevertheless, it is necessary to isolate the SI 110 from the other components 160 (e.g., the main CPU complex 120, the auxiliary security unit 122, the circuitry 124, the volatile memory 126, and the non-volatile memory 128) of the automotive SoC 104 so that potential problems occurring in one or more of the other components 160 do not negatively affect the SI 110. Such isolation may, for example, help prevent the SI 110 from being affected by a failure in one or more of the other components 160 of the automotive SoC 104. Non-limiting examples of the types of failures that may occur in one or more of the other components 160 include random glitches, clock problems, power problems, and/or voltage problems. Due to the proximity and one or more interfaces 200 (see 2 ) that the SI 110 shares with the other components 160 of the automotive SoC 104, such failures may migrate to the SI 110 and prevent the SI 110 from performing fallback and/or fail-safe functionality for which the SI 110 was integrated into the automotive SoC 104. Thus, the automotive processing system 102 isolates the SI 110 from the other components 160 of the automotive SoC 104 to achieve isolation comparable to that between the automotive SoC 104 and the optional external controller 106. Such isolation may be achieved by the first and second clocks 112 and 114, the first and second power connections 118A and 118B, and the interface(s) 200.

The first (SoC) clock 112 is separate from the second (SI) clock 114 (e.g., includes a separate reference crystal), which helps isolate the SI 110 from the other components 160 of the automotive SoC 104. Likewise, the first power connection 118A is separate from the second power connection 118B, which helps isolate the SI 110 from the other components 160 of the automotive SoC 104. As mentioned above, the SI 110 can operate in the SI voltage domain separate from the other components 160 of the automotive SoC 104. However, even with a separate second (SI) clock 114 and separate second power connection 118B, the SI 110 communicates with the other components 160 of the automotive SoC 104 via the interface(s) 200 (see 2 ).

The logic block(s) 148 include a clock and reset circuitry 230 (see 2 ) that is connected to the dedicated second (SI) clock 114. The dedicated second (SI) clock 114 may be used as a reference clock for the clock and reset circuitry 230. For example, the clock and reset circuitry 230 may include an internal dedicated phase-locked loop (“PLL”) used to derive other functional and debug clocks of the SI 110. As non-limiting examples, the clock and reset circuitry 230 may provide a debug clock signal and a test clock signal that may be derived from the PLL. The clock and reset circuitry 230 may generate all clock and reset signals used within the SI 110. In other words, the clock and reset circuitry 230 may generate the clock signal(s) and reset signal(s) used within the SI domain. Additionally or alternatively, the second (SI) clock 114 may be used directly as a functional clock for one or more of the logic blocks 148. In this way, the SI 110 uses the locally generated clock signal(s) and reset signal(s) and/or the clock signal provided by the second (SI) clock 114. No clock signals or reset signals from the other components 160 are used in the SI 110. The clock and reset circuitry 230 helps to prevent interference from logic-generating resets (e.g., reset blocks) within the other components 160 from reaching the components of the SI 110.

2 is an illustration of interface(s) 200 connecting the SI 110 to other components 160 of the vehicle SoC 104, according to some embodiments of the present disclosure. The interface(s) 200 provide, with reference to 2 provide logical isolation for the circuitry and logic of the SI 110 in the automotive SoC 104. In the illustrated embodiment, the interface(s) 200 include the fault interface(s) 172, a volatile memory interface 200A, a first control backbone interface 200B, a second control backbone interface 200C, a secure content interface 200D, a debug interface 200E, and a test interface 200F. The fault interface(s) 172 may not be logically isolated from the SoC fault aggregator(s) 152, but may each pass through or include one or more voltage level shifters 240, each providing electrical isolation between the SI and SoC voltage domains. While the voltage level shifter(s) 240 each provide electrical isolation, the voltage level shifter(s) 240 may not provide sufficient isolation for some types of failures, such as interrupt storms, fault storms, and/or continuous declarations. The SI fault aggregator 142 may include one or more status bits 242 that receive fault information via the fault interface(s) 172 and provide notification of such failures to the instructions 149 executed by the processor 140. In the illustrated embodiment, the status bits 242 include the status bits "BT1", "BT2", and "BT3" (see 4 ). Instructions 149 instruct processor 140 to use this notification to mitigate failures occurring at fault interface(s) 172.

The volatile memory interface 200A is an interface between the processor 140 and the volatile memory 126 of the automotive SoC 104. The volatile memory interface 200A enables the processor 140 to write information to the volatile memory 126 and read information from the volatile memory 126. The volatile memory interface 200A includes one or more connections to the volatile memory 126, such as a wire, a signal trace, and the like. The volatile memory interface 200A may include the logical isolation controller 220, an access timer 222, and domain synchronization circuitry 224. The logical isolation controller 220 includes a gate or locking mechanism that can be selectively locked and unlocked by the processor 140. The access timer 222 allows a timeout of an access attempt initiated by the processor 140.

The domain synchronization circuitry 224 includes phase synchronization circuitry and one or more voltage level shifters. The phase synchronization circuitry helps to synchronize the phases of signals communicated across the SI and SoC domains generated using the separate first and second clocks 112 and 114 (see 1 ). The resets generated by clock and reset circuitry 230 may be used by any elements that cross the SI and SoC voltage and clock domains, such as phase synchronization circuitry. Phase synchronization circuitry includes a SoC portion and an SI portion, each of which may act as a separate synthesis top-side. The SoC portion is physically located in the SoC domain and the SI portion is physically located in the SI domain. The logic of both the SI and SoC portions utilize resets generated by clock and reset circuitry 230. Thus, the resets generated by the SI 110 may be used by the logic of the automotive SoC 104, which may operate at a lower ASIL than the SI 110, but resets generated by the automotive SoC 104 are not communicated to and may not be used by the SI 110. As a non-limiting example, the phase synchronization circuitry may be implemented as a split first-in-first-out ("fifo"), and the like. The voltage level shifter(s) of domain synchronization circuitry 224 may be substantially identical to voltage level shifter(s) 240 and adjust the voltage of signals transmitted across the SI and SoC voltage domains to enable secure communication of signals across the SI and SoC domains. When access timer 222 indicates that an access by processor 140 has timed out, the request may be removed from domain synchronization circuitry 224 (e.g., taken from the split fifo).

When the volatile memory interface 200A is unlocked, the processor 140 may access the volatile memory 126, which starts the access timer 222. If the access timer 222 indicates that more than a first predetermined period of time has elapsed and no response has been received from the volatile memory 126, the processor 140 indicates a security fault, uses the logical isolation controller 220 to lock the volatile memory interface 200A, optionally locks any of the interface(s) 200 that are unlocked, and optionally takes one or more actions configured to lock the automotive platform 100 (see 1 ) to a secure state. Conversely, if the response is received before the access timer 222 indicates that the first predetermined period of time has elapsed, the access timer 222 resets itself, the processor 140 completes the access, and the processor 140 disables the volatile memory interface 200A after the access is complete. The volatile memory interface 200A thus remains disabled whenever the processor 140 is not accessing the volatile memory 126, which helps protect the SI 110 from faults and/or failures passing from the volatile memory 126 to the SI 110.

The first and second control backbone interfaces 200B and 200C are interfaces between the processor 140 and a control backbone 210. The control backbone 210 may be implemented as a bus and the like. The first control backbone interface 200B is for communication from the processor 140 to the control backbone 210 and the second control backbone interface 200C is for communication from the control backbone 210 to the processor 140. As a non-limiting example, the processor 140 may access at least some of the other components 160 (e.g., the circuitry 124, the mailbox(es) 156, and the non-volatile memory 128) of the automotive SoC 104 via the control backbone 210.

The first control backbone interface 200B enables the processor 140 to send instructions and/or information to the control backbone 210. The first control backbone interface 200B may include the logical isolation controller 220, the access timer 222, the domain synchronization circuitry 224, and a firewall 226. The logical isolation controller 220 of the first control backbone interface 200B is substantially identical to the logical isolation controller 220 of the volatile memory interface 200A and functions substantially identically. Thus, the logical isolation controller 220 of the first control backbone interface 200B enables the processor 140 to lock and unlock the first control backbone interface 200B. The access timer 222 of the first control backbone interface 200B enables a timeout of an access attempt initiated by the processor 140. The domain synchronization circuitry 224 of the first control backbone interface 200B is substantially identical to the domain synchronization circuitry 224 of the volatile memory interface 200A and functions substantially identically. The firewall 226 of the first control backbone interface 200B implements one or more security rules and allows or blocks any communication based on the security rule(s).

The second control backbone interface 200C enables the processor 140 to receive instructions and/or information from the control backbone 210. The second control backbone interface 200C may include the logical isolation controller 220, the domain synchronization circuitry 224, and the firewall 226. The logical isolation controller 220 of the second control backbone interface 200C is substantially identical to the logical isolation controller 220 of the volatile memory interface 200A and functions substantially identically. Thus, the logical isolation controller 220 of the second control backbone interface 200C enables the processor 140 to lock and unlock the second control backbone interface 200C. The domain synchronization circuitry 224 of the second control backbone interface 200C is substantially identical to the domain synchronization circuitry 224 of the volatile memory interface 200A and functions substantially identically. The firewall 226 of the second control backbone interface 200C implements one or more security rules and allows or blocks any communication based on the security rule(s).

Secure content interface 200D is an interface between processor 140 and secure content circuitry 212. Secure content interface 200D enables processor 140 to receive instructions and/or information (e.g., secure and/or sensitive content) from secure content circuitry 212. Secure content interface 200D may include logical isolation controller 220 and domain synchronization circuitry 224. Logical isolation controller 220 of secure content interface 200D is substantially identical to and functions substantially identically to logical isolation controller 220 of volatile memory interface 200A. Thus, logical isolation controller 220 of secure content interface 200D enables processor 140 to lock and unlock secure content interface 200D. The domain synchronization circuitry 224 of the secure content interface 200D is substantially identical to the domain synchronization circuitry 224 of the volatile memory interface 200A and functions substantially identically.

The debug interface 200E is an interface between the processor 140 and a debug circuitry 214. The debug interface 200E enables the processor 140 to receive instructions and/or information from the debug circuitry 214. The debug interface 200E may include the logical isolation control 220 and the domain synchronization circuitry 224. The logical isolation control 220 of the debug interface 200E is substantially identical to the logical isolation control 220 of the volatile memory interface 200A and functions substantially identically. Thus, the logical isolation control 220 of the debug interface 200E enables the processor 140 to lock and unlock the debug interface 200E. The domain synchronization circuitry 224 of the debug interface 200E is substantially identical to the domain synchronization circuitry 224 of the volatile memory interface 200A and functions substantially identically. As mentioned above, the SI 110 and the other components 160 operate in separate clock domains. In one or more embodiments, no signals from an external clock of one or more of the other components 160 of the automotive SoC 104, such as the debug circuitry 214, are fed to the SI 110. Debug functions performed by the automotive SoC 104 receive the debug clock signal via the domain synchronization circuitry 224 of the debug interface 200E, which switches or converts debug functions performed by the automotive SoC 104 using the debug clock signal generated by the SI 110 and/or the second (SI) clock 114. Since the debug logic is not used while the SI 110 is in use mode (e.g., when the vehicle is driving), the SI 110 includes a first clock gate on the debug clock to prevent interference that could potentially be caused by the debug clock signal. As a non-limiting example, the first clock gate may be a component of the clock and reset circuitry 230. The first clock gate may be controlled (e.g., selectively turned on and off) using a first configuration bit set by the processor 140.

The test interface 200F is an interface between the processor 140 and a test circuitry 216. The test interface 200F enables the processor 140 to receive instructions and/or information from the test circuitry 216. The test interface 200F may include the logical isolation controller 220 and the domain synchronization circuitry 224. The logical isolation controller 220 of the test interface 200F is substantially identical to the logical isolation controller 220 of the volatile memory interface 200A and functions substantially identically. Thus, the logical isolation controller 220 of the test interface 200F enables the processor 140 to lock and unlock the test interface 200F. The domain synchronization circuitry 224 of the test interface 200F is substantially identical to the domain synchronization circuitry 224 of the volatile memory interface 200A and functions substantially identically. As mentioned above, this configuration prevents external signals from one or more of the other components 160 of the automotive SoC 104, such as the test circuitry 216, from being injected into the SI 110. Test functions performed by the automotive SoC 104 receive the test clock signal via the domain synchronization circuitry 224 of the debug interface 200E, which switches or converts test functions performed by the automotive SoC 104 using the test clock signal generated by the SI 110 and/or the second (SI) clock 114. Since the test logic is not used while the SI 110 is in deployment mode (e.g., when the vehicle is running), the SI 110 includes a second clock gate on the test clock to prevent interference that could potentially be caused by the test clock signal. As a non-limiting example, the second clock gate may be a component of the clock and reset circuitry 230. The second clock gate may be controlled (e.g., selectively turned on and off) using a second configuration bit set by the processor 140.

The SI 110 may have at least two modes of operation, an isolated or cocoon mode and a non-isolated mode. When the SI 110 is operating in cocoon mode, the only information from the automotive SoC 104 that is allowed to enter the SI 110 is fault information that enters the SI 110 via the fault interface(s) 172. In this manner, the SI fault aggregator 142 maintains a cumulative integration status of the automotive SoC 104 and the SI 110. On the other hand, when the SI 110 is operating in non-isolated mode, information may enter the SI 110 via one or more of the interface(s) 200. Whether the SI 110 is operating in cocoon mode or non-isolated mode is determined at least in part by instructions 149 executed by the processor 140 and at least in part by the interface(s) 200.

To prevent a potential safety-critical issue originating from the other components 160 of the automotive SoC 104 from reaching the SI 110 via one or more of the interface(s) 200, each of the interface(s) 200 includes the separate logical isolation controller 220 that is selectively locked and unlocked by the processor 140. When the locking mechanism of the logical isolation controller 220 is locked by the processor 140, the locking mechanism prevents any communication between the automotive SoC 104 and the SI 110 via the locked interface. On the other hand, the interface can be unlocked by the processor 140 to enable such communication via the unlocked interface. Thus, the processor 140 can selectively place the SI 110 in the cocoon mode or the non-isolated mode. When all of the interface(s) 200 are disabled, the processor 140 cannot access either the volatile memory 126 or the non-volatile memory 128 and executes the instructions 149 stored in the volatile memory 146 (e.g., SRAM) located within the SI 110.

Referring now to 3 Each block of a method 300 described herein includes a computational process that may be performed using any combination of hardware, firmware, and/or software. For example, various functions may be performed by a processor (e.g., the processor described in the 1 , 2 and 4 illustrated processor 140) that executes instructions (e.g. those described in the 1 , 2 and 4 instructions 149) stored in a memory (e.g., the memory in the 1 , 2 and 4 illustrated volatile memory 146). The method 300 may also be presented as computer-usable instructions stored on computer storage media. The method 300 may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Furthermore, the method 300 is exemplified with reference to the automotive platform 100 of 1 However, the method 300 may additionally or alternatively be performed by a system or combination of systems, including but not limited to those described herein.

3 is a flow diagram illustrating the method 300 for switching the SI 110 between the cocoon and non-isolation modes, according to some embodiments of the present disclosure. For ease of illustration, the method 300 is illustrated as being performed by the processor 140 (see 1 , 2 and 4 ) described. Referring to 3 the processor 140 determines in a first block 302 that it is communicating with one of the other components 160 (see 1 and 2 ) of the automotive SoC 104. For example, this communication may occur via the volatile memory interface 200A or the first control backbone interface 200B, each of which enables the SI 110 to initiate communication with the other components 160 of the automotive SoC 104. Alternatively, this communication may occur via the second control backbone interface 200C, the secure content interface 200D, the debug interface 200E, or the test interface 200F, each of which enables the SI 110 to receive communications initiated by the other components 160 of the automotive SoC 104. As mentioned above, the communication occurs via the fault interface(s) 172 (see 2 ) regardless of whether the SI 110 is in cocoon mode or non-isolation mode.

If the processor 140 needs to communicate with a particular one of the other components 160 of the automotive SoC 104, the processor 140 makes a determination that communication with the particular component is safe before attempting to do so. To make this determination, in block 304, the processor 140 may check the contents of the SI fault aggregator 142 provided via the fault interface(s) 172 (see 2 ) receives fault information from the SoC fault aggregator(s) 152 that are external to the SI 110. As mentioned above, the fault interface(s) 172 are not logically isolated from the SoC fault aggregator(s) 152, but pass through or include the voltage level shifter(s) 240 that provide electrical isolation between the SI and SoC voltage domains.

In decision block 306, the processor 140 determines whether faults have been detected in the SI fault aggregator 142. The decision in decision block 306 is “YES” if at least one fault is detected, meaning that a fault identified for one or more of the other components 160 has been reported to the SI fault aggregator 142 by the SoC fault aggregator(s) 152. The processor 140 may detect the fault using the status bits 242 within the SI fault aggregator 142. The status bits 242 may be characterized to track the state of the automotive SoC 104. Alternatively, the SI fault aggregator 142 may notify the processor 140 of the fault by sending an interrupt to the processor 140. Otherwise, the decision in decision block 306 is “NO” if no faults are detected.

If the decision in decision block 306 is "YES," the processor 140 may take one or more corrective actions in block 308. The corrective action(s) may help place the vehicle in a safe condition. As non-limiting examples, such corrective actions may include applying the vehicle brakes, reducing the vehicle speed, guiding the vehicle to the shoulder of the road, and the like. The processor 140 may then return to block 304.

If the decision in decision block 306 is "NO," in block 310, the processor 140 unlocks the locking mechanism of the logical isolation controller 220 of a particular one of the interface(s) 200 connected to the particular component if the locking mechanism of the respective interface was locked. In other words, the processor 140 may determine that it is safe to access the particular component of the automotive SoC 104 via the particular interface if the SI fault aggregator 142 does not store any faults. Thus, the processor 140 unlocks the particular interface in block 310.

In block 312, the processor 140 may then send or receive communications to or from the concrete component via the unlocked concrete interface, automatically starting the concrete interface access timer 222. When the concrete interface is unlocked, the processor 140 may initiate one or more highly ordered accesses (one at a time) to the automotive SoC 104. The access timer 222 automatically starts per access. Thus, the access timer 222 may begin counting down as soon as a concrete access is initiated by the processor 140.

In decision block 314, processor 140 determines whether a timeout has occurred. The decision in decision block 314 is "YES" if access timer 222 indicates that more than the first predetermined time period has elapsed and no response has been received from the particular component. Otherwise, the decision in decision block 314 is "NO" if a response is received from the particular component before access timer 222 indicates that more than the first predetermined time period has elapsed.

If the decision in decision block 314 is "YES," the processor 140 indicates that a security fault has occurred in block 316. Then, in block 318, the processor 140 disables the locking mechanism of the logical isolation controller 220 of the particular interface, optionally disables the locking mechanism of the logical isolation controller 220 of any of the other interface(s) that are unlocked, and optionally takes one or more actions configured to return the automotive platform 100 to a secure state.

If, however, the decision in decision block 314 is "NO," the processor 140 terminates the communication in block 320. The access timer 222 is automatically reset. In block 318, the processor 140 then disables the locking mechanism of the specific interface. The method 300 thus ensures that the interface(s) 200 remain disabled whenever the processor 140 is not accessing one of the other components 160 of the automotive SoC 104. The method 300 then ends.

The SI 110 may avoid accessing the shared non-volatile memory 128 by copying the instructions 149 (e.g., critical instructions that place the system in a safe state) from the shared non-volatile memory 128 to its internal volatile memory 146 when the vehicle SoC 104 is started. The processor 140 may authenticate and validate the instructions 149 before the SI 110 enters a deployment mode that releases the vehicle's drive cycle. The SI 110 may operate in deployment mode and either cocoon or non-isolation mode simultaneously. The instructions 149 remain in the volatile memory 146, allowing the processor 140 to avoid accessing the shared non-volatile memory 128. From the shared volatile memory 126 may store non-critical data, such as application code, fusion data, and the like, using an internal direct memory access (“DMA”) engine 402 (see 4 ) included in the SI 110. The DMA engine 402 may optionally be a component of the processor 140. Failure of the DMA engine 402 will not adversely affect the processor 140 because the processor 140 will continue to execute the instructions 149 stored in the volatile memory 146 even if the DMA engine 402 fails while data obtained from the shared volatile memory 126 is being paged out.

4 is an illustration of the fault interface(s) 172 according to some embodiments of the present disclosure. Referring to 4 First fault aggregators 260-1 to 260-N may be associated with the logic blocks LB(1) - LB(N) of the motor vehicle SoC 104, respectively. The first fault aggregators 260-1 to 260-N aggregate faults generated by the logic blocks LB(1) to LB(N), respectively, and transmit first aggregated fault signals to the auxiliary safety unit 122 of the motor vehicle SoC 104. The auxiliary safety unit 122 implements the second SoC fault aggregator(s) 152, which aggregate the first aggregated fault signal(s) received from the first fault aggregators 260-1 to 260-N and transmit one or more second aggregated fault signals to the optional external control unit 106 (see 1 ), if present. When the optional external control unit 106 is notified of a fault by the second aggregated fault signal(s), the optional external control unit 106 may take one or more of a number of possible actions. First, the optional external control unit 106 may clear the fault. Second, the optional external control unit 106 may take a corrective action. Third, the optional external control unit 106 may notify an external system (e.g., one or more external microcontrollers, one or more external agents, and the like). However, as previously mentioned, in some embodiments, the optional external control unit 106 may be omitted.

While, as described above, with reference to 1 the SI 110 is isolated from the other components 160 of the automotive SoC 104, at least some communication must be possible between the SI 110 and the other components 160 of the automotive SoC 104. In particular, faults occurring in the logic blocks LB(1) to LB(N) of the automotive SoC 104 must be communicated to the SI 110 via the fault interface(s) 172. One method for providing such communication would be to use the first fault aggregators 260-1 to 260-N (see 4 ) to send the first aggregated disturbance signals directly to the SI 110. This requires that the disturbance interface(s) 172 include a separate transmission line or signal conductor between the SI 110 and each of the first disturbance aggregators 260-1 to 260-N, which is complicated by the isolation of the SI 110 from the other components 160 of the automotive SoC 104. For example, the voltage level shifter(s) 240 would have to be connected to the SI 110 via a separate transmission line or signal conductor between the SI 110 and each of the first disturbance aggregators 260-1 to 260-N. 2 include a separate voltage level shifter for each signal conductor. Furthermore, the greater the number of signal conductors between the SI 110 and the other components 160 of the automotive SoC 104, the more susceptible the SI 110 is to interference emanating from the automotive SoC 104.

Instead, with reference to 4 each of the SoC disturbance aggregator(s) 152 may be connected to the SI 110 by three signal conductors: (1) a corrected disturbance signal conductor 410; (2) an uncorrected disturbance signal conductor 412; and (3) a SoC disturbance aggregator signal conductor 414. This arrangement may enable the disturbance interface(s) 172 to report disturbances from the logic blocks LB(1) through LB(N) to the SI 110 without the disturbance interface(s) 172 including so many conductors that the conductors cause electrical noise, and without the disturbance interface(s) 172 becoming so large that they cause overcrowding in the automotive SoC 104 and/or the SI 110. The signal conductors 410, 412 and 414 can set the status bits “BT1”, “BT2” and “BT3”, respectively, which can be subsequently cleared by the processor 140 after being set.

The mailbox(es) 156 may be connected to the interrupt controller 141 of the SI 110 via a mailbox interrupt signal conductor 416. The signal conductors 410-416 may each be implemented as a wire, signal trace, and the like.

5A is a flowchart illustrating a method 500 for communicating faults to the SI 110 (see 1 , 2 , 4 , 8th and 10 ), according to some embodiments of the present disclosure. Referring now to 5A Each block of the method 500 described herein includes a computational process that may be performed using any combination of hardware, firmware, and/or software. For example, various functions may be performed by a processor (e.g., B. the 1 and 4 illustrated processor 150) that executes instructions stored in memory. At least portions of the method 500 may be embodied as computer-usable instructions stored on computer storage media. The method 500 may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Furthermore, the method 500 is exemplified with respect to the automotive platform 100 of 1 However, the method 500 may additionally or alternatively be performed by a system or combination of systems, including but not limited to those described herein.

For better illustration, the method 500 is described as being implemented by a specific SoC fault aggregator(s) 152 (see 1 , 2 and 4 ) described. In other words, the method 500 can be performed by hardware. Referring to 5A the specific SoC fault aggregator receives in a first block 502 first aggregated fault signals from at least a portion of the first fault aggregators 260-1 to 260-N (see 2 and 4 ).

In block 506, the specific SoC fault aggregator aggregates those of the first aggregated fault signals that identify a fault caused by a fault that has been corrected into a corrected fault signal. Then, in block 508, the specific SoC fault aggregator transmits the corrected fault signal over the corrected fault signal conductor 410 (see 4 ) to SI 110 (see 1 , 2 , 4 , 8th and 10 ). In block 510, the specific SoC fault aggregator sends an interrupt to the interrupt controller 154 for each corrected fault (see 1 and 4 ) that sends the interrupt(s) to the processor 150 (see 1 and 4 ) of the auxiliary safety unit 122 (see 1 and 4 ). Each interrupt informs the processor 150 of the corrected error associated with the interrupt.

In block 512, the concrete SoC fault aggregator starts a corrected fault timer 420C (see 4 ) for a first corrected error identified in the corrected error signal.

In decision block 514, the specific SoC fault aggregator determines whether the first corrected fault was cleared from the specific SoC fault aggregator. The decision in decision block 514 is "YES" if the first corrected fault was cleared before the corrected fault timer 420C (see 4 ) indicated that more than a second predetermined period of time has elapsed. Otherwise, the decision in decision block 514 is "NO." If the decision in decision block 514 is "YES," the specific SoC fault aggregator takes no action in block 515. Conversely, if the decision in decision block 514 is "NO," the specific SoC fault aggregator proceeds to decision block 516.

In decision block 516, the processor 150 determines whether the corrected error timer 420C (see 4 ) indicates that more than the second predetermined period of time has elapsed, that is, the corrected fault timer 420C has expired or timed out. The decision in decision block 516 is "YES" if the second predetermined period of time has elapsed. Otherwise, the decision in decision block 516 is "NO". If the decision in decision block 516 is "YES", the specific SoC fault aggregator proceeds to block 518. Otherwise, if the decision in decision block 516 is "NO", the specific SoC fault aggregator returns to decision block 514 to await the clearing of the first corrected fault by the processor 150. Thus, the specific SoC fault aggregator continues to monitor whether the first corrected fault has been cleared and whether the corrected fault timer 420C has expired. If the first corrected fault is cleared before the corrected fault timer 420C expires, the specific SoC fault aggregator takes no action in block 515. On the other hand, if the corrected fault timer 420C expires before the first corrected fault is cleared, the specific SoC fault aggregator proceeds to block 518. In block 518, the specific SoC fault aggregator transmits the SoC fault aggregator signal over the SoC fault aggregator signal conductor 414 (see 4 ) to SI 110 (see 1 , 2 , 4 , 8th and 10 ).

In block 520, the specific SoC fault aggregator aggregates those of the first aggregated fault signals received in block 502 that identify a fault caused by a fault that has not been corrected into an uncorrected fault signal. Then, in block 522, the specific SoC fault aggregator transmits the uncorrected fault signal over the uncorrected fault signal conductor 412 (see 4 ) to SI 110 (see 1 , 2 , 4 , 8th and 10 ). In block 524, the specific SoC fault aggregator sends an interrupt to the interrupt controller 154 for each uncorrected fault (see 1 and 4 ) that sends the interrupt(s) to the processor 150 (see 1 and 4 ) of the auxiliary safety unit 122 (please refer 1 and 4 ). Each interrupt informs the processor 150 of the uncorrected error associated with the interrupt.

In block 526, the concrete SoC fault aggregator starts an uncorrected fault timer 420U (see 4 ) for a first uncorrected error identified in the uncorrected error signal.

In decision block 528, the specific SoC fault aggregator determines whether the first uncorrected fault was cleared from the specific SoC fault aggregator. The decision in decision block 528 is "YES" if the first uncorrected fault was cleared before the uncorrected fault timer 420U (see 4 ) indicated that more than a third predetermined period of time has elapsed. Otherwise, the decision in decision block 528 is "NO." If the decision in decision block 528 is "YES," the specific SoC fault aggregator takes no action in block 529. If the decision in decision block 528 is "NO," the specific SoC fault aggregator proceeds to decision block 530.

In decision block 530, the processor 150 determines whether the uncorrected error timer 420U indicates that more than the third predetermined time period has elapsed, which means that the uncorrected error timer 420U (see 4 ) has expired or timed out. The decision in decision block 530 is YES if the third predetermined time period has elapsed. Otherwise, the decision in decision block 530 is NO. If the decision in decision block 530 is YES, the specific SoC fault aggregator proceeds to block 532. Otherwise, if the decision in decision block 530 is NO, the specific SoC fault aggregator returns to decision block 528 to wait for the processor 150 to clear the first uncorrected fault. Thus, the specific SoC fault aggregator continues to monitor whether the first uncorrected fault has been cleared and whether the uncorrected fault timer 420U has expired. If the first uncorrected fault is cleared before the uncorrected fault timer 420U expires, the specific SoC fault aggregator takes no action in block 529. On the other hand, if the uncorrected error timer 420U expires before the first uncorrected error is cleared, the specific SoC fault aggregator proceeds to block 532. In block 532, the specific SoC fault aggregator transmits the SoC fault aggregator signal over the SoC fault aggregator signal conductor 414 (see 4 ) to SI 110 (see 1 , 2 , 4 , 8th and 10 ). At this point, procedure 500 ends.

5B a flowchart showing a method 540 that the processor 150 (see 1 and 4 ) to receive from the SoC fault aggregator(s) 152 (see 1 , 2 and 4 ) to process interrupts received, according to some embodiments of the present disclosure. Referring now to 5B Each block of the method 540 described herein includes a computational process that may be performed using any combination of hardware, firmware, and/or software. For example, various functions may be implemented by a processor (e.g., processor 150) executing instructions stored in memory. At least portions of the method 540 may be embodied as computer-usable instructions stored on computer storage media. The method 540 may be provided by a standalone application, service, or hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Furthermore, the method 540 is described by way of example with respect to the automotive platform 100 of 1 However, the method 540 may additionally or alternatively be performed by a system or combination of systems, including but not limited to those described herein.

For better illustration, the method 540 is described as being performed by the processor 150 (see 1 and 4 ) is described. With reference to 5B in a first block 541, the processor 150 receives a particular interrupt from a particular one of the SoC fault aggregator(s) 152. Then, in block 542, the processor 150 reviews one or more faults identified in the particular interrupt and may take one or more corrective actions to resolve the fault(s).

If a problem occurs while the processor 150 is reviewing the error(s) and/or taking the corrective action(s), the processor 150 may not be able to continue processing the particular interrupt. If this occurs, the decision in decision block 543 is "YES" and at block 544 the processor 150 takes no further action with respect to the particular interrupt. On the other hand, if the processor 150 is able to review the particular interrupt and take the corrective action(s) if necessary, the decision in decision block 543 is "NO". If the decision If the decision in decision block 543 is "NO," in block 545, the processor 150 writes information regarding the particular interrupts to the mailbox(es) 156 that can be read by the processor 140. Next, in block 546, the processor 150 sends a mailbox interrupt to the interrupt controller 141 via the mailbox interrupt signal conductor 416. The mailbox interrupt indicates a severity level of the error identified in the interrupt received in block 541.

Then, in decision block 547, the processor 150 determines whether the processor 150 should clear the fault for which the particular interrupt was generated by the particular SoC fault aggregator. The decision in decision block 547 is "YES" if the processor 150 decides to clear the fault. Otherwise, the decision in decision block 547 is "NO". The decision in decision block 547 may be "YES" if the corrective action(s) taken by the processor 150 were able to correct the fault or the fault was generated by a corrected fault (e.g., a fault corrected by one of the logic blocks LB(1) - LB(N)). As another non-limiting example, the decision in decision block 547 may be "YES" if the processor 150 receives a mailbox interrupt from the processor 140 indicating that the processor 140 has cleared the fault. If the decision in decision block 547 is "NO," the processor 150 takes no further action with respect to the particular interrupt in block 548. On the other hand, if the decision in decision block 547 is "YES," the processor 150 deletes the fault from the particular SoC fault aggregator in block 549. The processor 150 may inform the processor 140 that the fault has been deleted from the particular SoC fault aggregator. Then, the method 540 ends.

5C a flow chart showing a method 550 that implements SI 110 (see 1 , 2 , 4 , 8th and 10 ) to process the corrected and uncorrected error signals, according to some embodiments of the present disclosure. Referring now to 5C Each block of the method 550 described herein includes a computational process that may be performed using any combination of hardware, firmware, and/or software. For example, various functions may be performed by a processor (e.g., the processor described in the 1 , 2 and 4 illustrated processor 140) that executes instructions (e.g. those described in the 1 , 2 and 4 instructions 149) stored in a memory (e.g., the memory in the 1 , 2 and 4 illustrated volatile memory 146). At least portions of the method 550 may be embodied as computer-usable instructions stored on computer storage media. The method 550 may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Moreover, the method 550 is exemplary described with reference to the automotive platform 100 of 1 However, the method 550 may additionally or alternatively be performed by a system or combination of systems, including but not limited to those described herein.

For better illustration, the method 550 is described as being implemented by the SI disturbance aggregator 142 (see 1 , 2 and 4 ) and the processor 140 (see 1 , 2 and 4 ) is described. With reference to 5C the SI disturbance aggregator 142 of the SI 110 receives (see 1 , 2 , 4 , 8th and 10 ) in a first block 552 the corrected error signal setting the status bit "BT1" and/or the uncorrected error signal setting the status bit "BT2". When the SI fault aggregator 142 receives the corrected error signal on the corrected error signal conductor 410, the SI fault aggregator 142 sends an interrupt to the interrupt controller 141 in block 554 (see 1 , 2 and 4 ) of the processor 140. This interrupt informs the processor 140 of the corrected error(s).

In decision block 556, the processor 140 determines (see 1 , 2 and 4 ) whether a mailbox interrupt from the processor 150 (see 1 and 4 ) was received over the mailbox interrupt signal conductor 416. When the mailbox interrupt is received, the mailbox interrupt indicates the severity of the error being corrected. The decision in decision block 556 is YES if the processor 140 received the mailbox interrupt. Otherwise, the decision in decision block 556 is NO. If the decision in decision block 556 is NO, the processor 140 waits to receive either the mailbox interrupt or the SoC fault aggregator signal in block 558. If the decision in decision block 556 is YES, the processor 140 proceeds to decision block 560.

In decision block 560, processor 140 decides (see 1 , 2 and 4 ) whether to read the mailbox(es) 156. This decision may be based at least in part on the severity of the corrected error communicated to the processor 140 through the mailbox interrupt. For example, the Processor 140 may decide not to read mailbox(es) 156 if the severity of the corrected error meets or exceeds a threshold (e.g., 7), and may decide to read mailbox(es) 156 if the severity of the corrected error(s) is below the threshold. If the decision in decision block 560 is YES, processor 140 reads mailbox(es) 156 in block 562. Then, processor 140 proceeds to block 564, where processor 140 clears the corrected error, for example, by unsetting status bit BT1. If the decision in decision block 560 is NO, processor 140 proceeds to block 564 and clears the corrected error, for example, by unsetting status bit BT1. The processor 140 may wait for a notification from the processor 150 that the fault corresponding to the corrected fault has been deleted from the particular SoC fault aggregator before the processor 140 deletes the corrected fault from the SI fault aggregator 142. However, since the fault has been corrected, in some embodiments the processor 140 may simply delete the corrected fault without first receiving such a notification.

When the SI fault aggregator 142 receives the uncorrected fault signal on the uncorrected fault signal conductor 412, the SI fault aggregator 142 sends an interrupt to the interrupt controller 141 in block 566 (see 1 , 2 and 4 ) of the processor 140. This interrupt informs the processor 140 of the uncorrected error(s).

In decision block 568, the processor 140 determines (see 1 , 2 and 4 ) whether a mailbox interrupt from the processor 150 (see 1 and 4 ) was received over the mailbox interrupt signal conductor 416. When the mailbox interrupt is received, the mailbox interrupt indicates the severity of the uncorrected error. The decision in decision block 568 is YES if the processor 140 received the mailbox interrupt. Otherwise, the decision in decision block 568 is NO. If the decision in decision block 568 is NO, the processor 140 waits to receive either the mailbox interrupt or the SoC fault aggregator signal in block 558. If the decision in decision block 568 is YES, the processor 140 proceeds to decision block 570.

In decision block 570, processor 140 decides (see 1 , 2 and 4 ) whether to read the mailbox(es) 156. This decision may be based at least in part on the severity of the uncorrected error. For example, the processor 140 may decide not to read mailbox(es) 156 if the severity of the uncorrected error(s) meets or exceeds a threshold (e.g., 7), and may decide to read mailbox(es) 156 if the severity of the corrected error(s) is below the threshold. If the decision in decision block 570 is YES, the processor 140 reads the mailbox(es) 156 in block 572. The processor 140 then proceeds to decision block 573. If the decision in decision block 570 is NO, the processor 140 proceeds to block 573.

In decision block 573, the processor 140 determines whether to take one or more corrective actions. If the decision in decision block 573 is "YES," the processor 140 takes the corrective action(s), such as applying the vehicle brakes, in block 574. The processor 140 then proceeds to decision block 575.

If the decision in decision block 573 is "NO," the processor 140 proceeds to block 575. In decision block 575, the processor 140 decides whether to notify the external system 404. If the decision in decision block 575 is "YES," the processor 140 notifies the external system 404 in block 576 and proceeds to block 578. If the decision in decision block 575 is "NO," the processor 140 proceeds to block 578.

In block 578, the processor 140 sends a mailbox interrupt to the mailbox(es) 156 and/or clears the uncorrected error, for example, by unsettling the status bit “BT2”. Optionally, the processor 140 may write fault information to the mailbox(es) 156. The processor 140 may wait for a notification from the processor 150 that the fault corresponding to the uncorrected error has been cleared from the specific SoC fault aggregator before the processor 140 clears the uncorrected error from the SI fault aggregator 142. Then, the method 550 ends. The mailbox interrupt is received by the processor 150 and may be processed in decision block 547 (see 5B) used when deciding whether the processor 150 should clear the fault corresponding to the uncorrected error. The processor 150 may optionally read the fault information written by the processor 140 to the mailbox(es) 156 before making this decision.

5D is a flow chart showing a method 580 that implements the Sl 110 (see 1 , 2 , 4 , 8th and 10 ) to process a SoC fault aggregator signal, according to some embodiments of the present disclosure. Referring now to 5D Each block of the method 580 described herein includes a computational process that may be performed using any combination of hardware, firmware, and/or software. For example, various functions may be performed by a processor (e.g., the processor described in the 1 , 2 and 4 illustrated processor 140) that executes instructions (e.g. those described in the 1 , 2 and 4 instructions 149) stored in a memory (e.g., the memory in the 1 , 2 and 4 illustrated volatile memory 146). At least portions of the method 580 may be embodied as computer-usable instructions stored on computer storage media. The method 580 may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Moreover, the method 580 is exemplary described with reference to the automotive platform 100 of 1 However, the method 580 may additionally or alternatively be performed by a system or combination of systems, including but not limited to those described herein.

For better illustration, the method 580 is described as being implemented by the SI disturbance aggregator 142 (see 1 , 2 and 4 ), the processor 140 (see 1 , 2 and 4 ) and a SoC error handling circuitry 422 (see 4 ) is described. The SoC fault handling circuitry 422 may be implemented as a component of the SI fault aggregator 142. Referring to 5D The SI disturbance aggregator 142 receives (see 1 , 2 and 4 ) in a first block 582 the SoC fault aggregator signal which sets the status bit “BT3”.

As indicated by an arrow with a dashed line in 5D shown, if the SI disturbance aggregator 142 (see 1 , 2 and 4 ) receives the SoC fault aggregator signal, the SoC fault handling circuitry 422 (see 4 ) the SI 110 will automatically proceed to block 584 and automatically transmit a SoC error signal containing a SoC error via connection 406 (see 4 ) to the external system 404 (see 4 ). Alternatively, the SoC fault handling circuitry 422 may proceed to block 586 and send a SoC fault timer 424 (see 4 ). The SoC fault timer 424 may introduce a delay between receiving the SoC fault aggregator signal and notifying the external system 404. While the SoC fault timer 424 is running, the processor 140 may take one or more corrective actions. If the corrective action(s) are successful, the processor 140 may clear the uncorrected fault(s) by unsetting the status bit "BT2" and the SoC fault aggregator fault by unsetting the status bit "BT3". Clearing the SoC fault aggregator fault stops the SoC fault timer 424. The processor 140 may wait for notification from the processor 150 that the fault(s) corresponding to the uncorrected fault(s) have been cleared from the particular SoC fault aggregator before the processor 140 clears the uncorrected fault(s) from the SI fault aggregator 142.

After starting the SoC fault timer 424 in decision block 588, the SoC fault handling circuitry 422 determines whether the SoC fault timer 424 indicates that more than a fourth predetermined period of time has elapsed. The decision in decision block 588 is "YES" if the SoC fault timer 424 indicates that more than the fourth predetermined period of time has elapsed and the SoC fault aggregator fault has not been cleared. On the other hand, the decision in decision block 588 is "NO" if the SoC fault aggregator fault has been cleared before the SoC fault timer 424 indicates that more than the fourth predetermined period of time has elapsed.

If the decision in decision block 588 is "NO," the SoC fault handling circuitry 422 waits in block 590 for the SoC fault timer 424 to indicate that more than the fourth predetermined time period has elapsed. Conversely, if the decision in decision block 588 is "YES," the SoC fault handling circuitry 422 transmits the SoC fault signal including the SoC fault indicating that the first uncorrected fault was not cleared and the SoC fault aggregator fault was declared over the connection 406 in block 584 (see 4 ) to the external system 404 (see 4 ) The SoC fault timer 424 automatically stops and/or resets when the SoC fault is sent. Alternatively, the SoC fault handling circuitry 422 may reset the SoC fault timer 424 or the SoC fault timer 424 may simply expire without the SoC fault handling circuitry 422 taking any action.

After the SI disturbance aggregator 142 (see 1 , 2 and 4 ) has received the SoC fault aggregator signal, the SI fault aggregator 142 may send an interrupt to the processor 140 in block 592. In block 594, the processor 140 views the first uncorrected fault. In decision block 595, the processor 140 decides whether to take one or more corrective actions. The decision in decision block 595 is "YES" if the processor 140 decides to take one or more corrective actions. Otherwise, the decision in decision block 595 is "NO". If the decision in decision block 595 is "NO", the processor 140 proceeds to block 596 and takes no action. Conversely, if the decision in decision block 595 is "YES", the processor 140 takes the corrective action(s) in block 597.

Then, in block 598, the processor 140 sends a mailbox interrupt to the mailbox(es) 156 and/or clears the SoC fault aggregator error, for example, by unsettling the status bit "BT3," and the uncorrected error(s) by unsettling the status bit "BT2." Clearing the SoC fault aggregator error stops the SoC fault timer 424. The mailbox interrupt sent to the mailbox(es) 156 may indicate that the uncorrected error has been cleared and/or the processor 140 has taken the corrective action(s) in block 597. Optionally, the processor 140 may write fault information to the mailbox(es) 156. The processor 140 may wait for notification from the processor 150 that the fault(s) corresponding to the uncorrected fault(s) have been deleted from the particular SoC fault aggregator before the processor 140 deletes the SoC fault aggregator fault and the uncorrected fault(s) from the SI fault aggregator 142. Then, the method 580 ends. The mailbox interrupt is received by the processor 150, which may delete the fault corresponding to the uncorrected fault. The processor 150 may optionally read the fault information written by the processor 140 to the mailbox(es) 156 before deleting the fault.

In the 5A-5D the automotive SoC 104 includes the processor 150. In at least some embodiments, the processor 150 may be omitted. In such embodiments, the method 540 is not performed. For each fault, the particular SoC fault aggregator generates the SoC fault aggregator error (blocks 518 and 532) and sends it to the SI fault aggregator 142. Since the processor 150 is not present, the mailbox interrupts are not transmitted to the interrupt controller 141, so the processor 140 waits for the SoC fault aggregator signal (block 558 in 5C ) before the processor 140 acts. Then, when the SoC fault aggregator error is received (block 582 in 5D ), the Sl 110 moves to the other components 160 to make a sighting (block 594 in 5D ) for each corrected and uncorrected error received in the method 550 (see 5C ). If the screening is successful, the processor 140 takes the corrective action(s) (block 597 in 5D ). If, however, the sighting is not successful, the processor 140 takes no action (block 596 in 5D ), which causes the SoC error handling circuitry 422 to send the SoC error (without software intervention) after the SoC fault timer 424 expires (block 584 in 5D ). The SoC error informs the external system 404 (e.g., the optional external control unit 106, one or more external microcontrollers, one or more external agents, and the like), causing the external system 404 to disable the automotive platform 100 (see 1 ) to a safe state.

The 6A-6C illustrate exemplary actions that may be taken by the SI 110 when the SI 110 is informed of a specific fault by at least one of the corrected fault signal, the uncorrected fault signal, or the SoC fault aggregator signal. 6A illustrates an example signal timing diagram for signals received and transmitted by processor 140 after an uncorrected low severity error (e.g., the minimum value) is declared, in accordance with some embodiments of the present disclosure. Lines 612A-618A of 6A represent the uncorrected error signal, a mailbox interrupt signal, the SoC fault aggregation signal, and the SoC error signal, respectively. The uncorrected error signal, the mailbox interrupt signal, the SoC fault aggregation signal, and the SoC error signal are synchronized with a clock signal represented by a line 610A. The clock signal represented by the line 610A was generated based on the second (SI) clock 114 (see 1 ) in the SI domain.

Line 612A represents the uncorrected error signal carried by uncorrected error signal conductor 412 (see 4 ) to the SI fault aggregator 142. A portion 622A of line 612A represents the declaration of the uncorrected fault. After receiving the uncorrected fault signal (e.g., block 552 in 5C ), the SI fault aggregator 142 sends an interrupt to the processor 140 (e.g., block 566 in 5C ).

Then receive in 6A the interrupt controller 141 issues a mailbox interrupt (decision in decision block 568 in 5C is "YES"). A portion 626A of line 614A represents the mailbox interrupt (sent by processor 150) indicating the severity of the uncorrected error. Since the mailbox interrupt indicates that the particular fault is of low severity, processor 140 decides to access mailbox(es) 156 (e.g., decision in decision block 570 in 5C is “YES”) and read the contents of mailbox(es) 156 (e.g. block 572 in 5C ). If the mailbox(es) 156 contain fault information (created by the processor 150) indicating that the particular fault has been deleted, the processor 140 deletes the particular fault in the SI fault aggregator 142 (e.g., block 578 in 5C ). If this occurs before the corrected fault timer 420U expires, the SoC fault aggregator(s) 152 do not declare the SoC fault aggregator fault (e.g., block 529 in 5A) .

On the other hand, if the contents of the mailbox(es) 156 do not indicate that the processor 150 has corrected the particular fault, the processor 140 may decide to take one or more corrective actions (e.g., the decision in decision block 573 in 5C “YES”). If the corrective action(s) (e.g. in block 574 in 5C taken) are successful, the processor 140 may notify the processor 150 to revert the error (or clear the fault). For example, the processor 140 may send a mailbox interrupt to the processor 150 and/or write fault information to the mailbox(es) 156. After the processor 150 receives this notification and reverts the error, the processor 150 notifies the processor 140 that the error has been reverted (e.g., via the uncorrected error signal, a mailbox interrupt, and/or fault information stored in the mailbox(es) 156). After receiving this notification, the processor 140 may clear the error, for example, by unsettling the status bit “BT2” (e.g., block 578 in 5C ). A portion 624A of line 612A represents a retraction of the declaration of the uncorrected error after the processor 140 reads the mailbox(es) 156 and takes corrective action. A curved arrow 628A represents a delay between the time the processor 140 receives the mailbox interrupt and the time the processor 140 retracts the error (or clears the error).

If the corrective action(s) are successful, the processor 140 may send a mailbox interrupt to the mailbox(es) 156 indicating that the processor 140 has cleared the particular fault (e.g., block 578 in 5C ). Optionally, the processor 140 may write fault information to the mailbox(es) 156. The processor 150 receives the mailbox interrupt, determines that the particular fault has been corrected by the processor 140 (e.g., the decision in decision block 547 is “YES”), and deletes the particular fault from the SoC fault aggregator(s) 152 (e.g., block 549 in 5B) . If this occurs before the uncorrected fault timer 420U expires, the SoC fault aggregator(s) 152 do not declare the SoC fault aggregator fault (e.g., block 529 in 5A) . Thus, the SoC fault aggregator(s) 152 monitor the particular fault to ensure that it has been handled by one of the processors 140 and 150, and if the particular fault has not been cleared before the expiration of the uncorrected fault timer 420U, the SoC fault aggregator(s) 152 notifies the SoC fault handling circuitry 422. As mentioned above, after the processor 150 reverts the fault, the processor 150 notifies the processor 140 that the fault has been reverted (e.g., via the uncorrected fault signal, a mailbox interrupt, and/or fault information stored in the mailbox(es) 156), and the processor 140 may clear the fault in the SI fault aggregator 142.

Line 616A represents the SoC fault aggregation signal and illustrates that the SoC fault aggregation fault was not declared. Thus, the uncorrected fault(s) were cleared before the expiration of the uncorrected fault timer 420U.

Line 618A represents a SoC fault signal that may be sent to the external system 404 (e.g., the optional external controller 106, one or more external microcontrollers, one or more external agents, and the like) over connection 406. Since the uncorrected fault(s) have been handled and the SoC fault aggregation fault has not been declared, line 618A indicates that the SI 110 will not inform the external system 404 of the uncorrected fault(s) (e.g., the decision in decision block 575 is "NO").

6B illustrates an example signal timing diagram for signals received and transmitted by processor 140 after an uncorrected high severity error (e.g., the maximum value) is declared, according to some embodiments of the present disclosure. The lines 612B-618B of the 6B represent the uncorrected error signal, a mailbox interrupt signal, the SoC fault aggregation signal, and the SoC error signal, respectively. The uncorrected error signal, the mailbox interrupt signal, the SoC fault aggregation signal, and the SoC error signal are synchronized with a clock signal represented by a line 610B. The clock signal represented by the line 610B was generated based on the second (SI) clock 114 (see 1 ) in the SI domain.

Line 612B represents the uncorrected error signal carried by the uncorrected error signal conductor 412 (see 4 ) to the SI fault aggregator 142. A portion 622B of line 612B represents a declaration of an uncorrected fault. Upon receipt of the uncorrected fault signal (e.g., block 552 in 5C ), the SI fault aggregator 142 sends an interrupt to the processor 140 (e.g., block 566 in 5C ).

Then receive in 6B the interrupt controller 141 issues a mailbox interrupt (e.g. decision in decision block 568 in 5C is "YES"). A portion 624B of line 614B represents the mailbox interrupt indicating that the first uncorrected error has a high severity level (e.g., seven). Since the mailbox interrupt indicates that the particular fault has a high severity level, the processor 140 decides not to access the mailbox(es) 156 (e.g., decision in decision block 570 in 5C is "NO"). For example, the processor 140 may determine that it is too risky to access the other components 160 of the automotive SoC 104 and this could harm the SI 110. In 6B the processor 140 also decides not to take one or more corrective actions (e.g., the decision in decision block 573 is in 5C “NO”). In 6B the uncorrected error will not be withdrawn because SI 110 is not able to implement one or more corrective measures.

However, the processor 140 decides to use the external system 404 (see 4 ) by sending the SoC error in the SoC error signal (e.g. decision in decision block 575 in 5C is “YES”). Then the processor 140 sends the SoC error signal (e.g., block 576 in 5C ). This means that 6B if the severity of the fault is high (e.g., the maximum value), the SI 110 may decide not to access the automotive SoC 104, take no corrective action, and instead inform the external system 404. Line 618B represents the SoC fault signal sent by the SI 110 to the external system 404, and a portion 626B of line 618B represents the declaration of the SoC fault. Line 616B represents the SoC fault aggregation signal and does not indicate that a SoC fault aggregation fault has already been declared. Therefore, the SI 110 recognized that the uncorrected fault was not handled and decided to inform the external system 404 before declaring the SoC fault aggregation fault.

6C illustrates an example signal timing diagram for signals received and transmitted by the processor 140 after an uncorrected error (e.g., the maximum value) is declared but the SI 110 does not receive the mailbox interrupt, in accordance with some embodiments of the present disclosure. Lines 612C-618C of the 6C represent the uncorrected error signal, a mailbox interrupt signal, the SoC fault aggregation signal, and the SoC error signal, respectively. The uncorrected error signal, the mailbox interrupt signal, the SoC fault aggregation signal, and the SoC error signal are synchronized with a clock signal represented by a line 610C. The clock signal represented by the line 610C was generated based on the second (SI) clock 114 (see 1 ) in the SI domain.

Line 612C represents the uncorrected error signal carried by the uncorrected error signal conductor 412 (see 4 ) to the SI fault aggregator 142. A portion 622C of line 612C represents a declaration of an uncorrected fault. Upon receipt of the uncorrected fault signal (e.g., block 552 in 5C ), the SI fault aggregator 142 sends an interrupt to the processor 140 (e.g., block 566 of 5C ).

In 6C line 614C does not indicate that the mailbox interrupt was received. Thus, in this example, interrupt controller 141 does not receive the mailbox interrupt (e.g., decision in decision block 568 in 5C “NO”). This may occur, for example, if the processor 150 detects the uncorrected error (e.g., block 542 in 5B) could not complete, which leads to (decision in decision block 543 in 5C is “YES”) that the processor 150 receives the mailbox interrupt (e.g. block 544 in 5B) Therefore, the processor 140 waits to receive either the mailbox interrupt or the SoC fault aggregator error, whichever occurs first (e.g., block 558 in 5C ).

A line 628C represents the third predetermined period of time and indicates the uncorrected error timer 420U as expired. Since neither the processor 140 nor the processor 150 was able to clear the first uncorrected error, the uncorrected error timer 420U is allowed to expire (e.g., decision in decision block 530 in 5A is “YES”) that caused a particular one of the SoC fault aggregator(s) 152 that sent the uncorrected error signal to the SI 110 and the interrupt to the processor 150 to send the SoC fault aggregator signal to the SI fault aggregator 142 via the SoC fault aggregator signal conductor 414 (e.g., in block 532 in 5A) . The SI fault aggregator 142 receives the SoC fault aggregator signal (e.g., in block 582 in 5D ). A portion 624C of line 616C represents the SI fault aggregator error sent by the particular SoC fault aggregator to the SI 110. A curved arrow 630C represents a delay between the receipt of the uncorrected error by the SI 110 and the receipt of the SI fault aggregator error by the SI 110.

After receiving the SI disturbance aggregator signal (e.g. block 582 in 5D ), the SI fault aggregator 142 sends an interrupt to the processor 140 (e.g., block 592 in 5D ). Then, the processor 140 may detect the first uncorrected error (e.g., block 594 in 5D ) and decide whether to take corrective action. If the processor 140 cannot take corrective action (e.g., decision in decision block 595 in 5D is “NO”), the SoC error handling circuitry 422 sends the SoC error signal to the external system 404 (e.g., block 584 in 5C ). A portion 626C of line 612C represents the SoC error sent to the external system 404. In embodiments that use the SoC fault timer 424, the SoC error is sent when the SoC fault timer 424 expires. In 6C a line 632C indicates that more than the fourth predetermined period of time has elapsed, meaning that the SoC fault timer 424 has expired. A curved arrow 634C represents a delay between the SI 110 receiving the SI fault aggregator fault and the SI 110 declaring the SoC fault. Thus, hardware in the SI 110 informs the external system 404, which will attempt to return the automotive platform 100 to a safe state.

With reference to 2 and as mentioned above, the SI 110 and the other components 160 of the automotive SoC 104 share the volatile memory 126. However, the SI 110 operates within a first risk classification level and the other components 160 of the automotive SoC 104 may operate within a lower second risk classification level. For example, the SI 110 may operate at ASIL-D, but the other components of the automotive SoC, including the volatile memory 126 and a communication path (e.g., interconnect, memory controller, and the like) between the SI 110 and the volatile memory 126, may operate at ASIL-B.

To enable the SI 110 to share the volatile memory 126 with the other components 160 of the automotive SoC 104, a separate dedicated memory region (referred to as a “carve-out” 250) is created in the volatile memory 126 for exclusive use by the SI 110. The carve-out 250 may not be visible to memory management software (e.g., Rich OS memory management, Rich OS memory management software) executed by the main CPU complex 120 (see 1 ). The carve-out 250 may be created and configured at boot time and remain associated with the SI 110 for a given boot cycle. For example, the size of the carve-out 250 may be determined by a user-editable software parameter used by software (e.g., executed by the CPU main complex 120) to configure the carve-out 250. The carve-out 250 may be divided into a first sub-area 252 (see 8th ) and a second sub-area 254 (see 8th ). The SI 110 may access the outsource 250 via a communication path operating at the first risk classification level, and any access to the outsource 250 by the SI 110 via the communication path may be subject to security authorization checks, such as those described below.

The SI 110 includes an error detection block 272 that includes hardware positioned between other components of the SI 110 and the spin-off 250. Thus, the error detection block 272 may be implemented as part of the volatile memory interface 200A. Alternatively, the error detection block 272 may be positioned between the processor 140 and the volatile memory interface 200A. In such embodiments, one or more signal conductors (e.g., a wire, a signal trace, and the like) may connect the error detection block 272 to each of the processor 140 and the volatile memory interface 200A.

The hardware of the error detection block 272 may include a code generation sub-block 273 (see 8th ). The code generation sub-block 273 may be implemented using cyclic redundancy check (“CRC”) code generation circuitry that generates a CRC code. Alternatively, the error detection block 272 may include other types of code generation circuitry that generate different types of error detection codes, such as error correction code (“ECC”). The hardware of the error detection block 272 determines one or more error detection codes (e.g., CRC codes) for data passing through the error detection block 272. For example, the error detection block 272 may determine a separate error detection code for each byte of data passing through the error detection block 272. The error detection code may be calculated based on the byte and a data address in the partition 250 where the byte is to be stored. For example, Equation 1 below can be used to determine the error detection code for a specific byte of data to be written to the partition 250: $${\text{crc\_out}}_{\text{Bytes x}}=\text{CRC}\left(\text{Byte address},\text{Byte data}\right)$$

In Equation 1 above, a variable "crc_outByte x" represents the error detection code calculated based on the byte represented by a variable "byte data" and the data address represented by a variable "byte address". In Equation 1, a function "CRC" takes the values of the variables "byte data" and "byte address" as inputs and outputs the value of the variable "crc_outByte x". The output of the function "CRC" may be at least partially provided by the code generation sub-block 273 (see 8th ), if available, will be calculated.

After the error detection code is determined, the error detection block 272 determines (e.g., using an offset) a code address for the error detection code. For example, Equation 2 below may be used to determine the error detection code for a particular byte of data to be written to the partition 250: $$\text{crc\_out\_address}=\text{write\_address}+\text{fixed\_offset}$$

In Equation 2 above, a variable "crc_out_address" represents the code address calculated based on the data address, represented by a variable "write_address", of the byte and an offset, represented by a variable "fixed_offset". As mentioned above, the outbox 250 may be divided into sub-areas, with the first sub-area 252 (see 8th ) the data and the second subsection 254 (see 8th ) stores the error detection codes. Thus, the data address represented by the variable "byte_address" in Equation 1 above may be located in the first sub-area 252 and the code address represented by the variable "write_address" in Equation 2 above may be located in the sub-area 254. In such embodiments, the value of the variable "fixed_offset" may be equal to the size of the first sub-area 252 of the partition 250 to ensure that the error detection codes are stored in the second sub-area 254. In this way, address-based separation is used to separate the data from the error detection codes so that a disturbance occurring in one of the first and second sub-areas 252 and 254 cannot affect the other.

The error detection block 272 introduces a delay (e.g., a few clock cycles) between storing the data in the data address(es) and storing the error detection code in the code address(es). This delay reduces the likelihood that an event (e.g., a transient event) that negatively affects the data will also negatively affect the error detection code. In other words, the delay helps provide immunity from common and transient errors, which helps protect against problems such as clock glitches. The error detection block 272 may buffer two or more bytes of data and their corresponding error detection codes before storing them in the partition 250. Then, the error detection block 272 may store the bytes of data (e.g., 16 bytes) in the first partition 252, followed by the delay. The error detection block 272 can then store the corresponding error detection codes (e.g. 16 bytes) in the second subarea 254.

Referring now to 7 Each block of a method 700 described herein includes a computational process that may be performed using any combination of hardware, firmware, and/or software. For example, the method 700 may be performed by the hardware of the error detection block 272 (see 2 , 8th and 10 ). Do not restrict further In the example, one or more functions may be performed by a processor (e.g. the processor in the 1 , 2 and 4 illustrated processor 140) that executes instructions (e.g. those described in the 1 , 2 and 4 instructions 149) stored in a memory (e.g., the memory in the 1 , 2 and 4 illustrated volatile memory 146). In such embodiments, at least portions of the method 700 may be embodied as computer-usable instructions stored on computer storage media. The method 700 may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Moreover, the method 700 is exemplified with respect to the automotive platform 100 of 1 However, the method 700 may additionally or alternatively be performed by a system or combination of systems, including but not limited to those described herein.

7 is a flowchart illustrating a method 700 for writing data to the spin-off 250 (see 2 , 8th and 10 ) according to some embodiments of the present disclosure. For better illustration, the method 700 is illustrated as being executed by the error detection block 272 (see 2 , 8th and 10 ). Prior to beginning the method 700, an initiator operating in the SI domain (e.g., the processor 140, the DMA engine 402, or the like) forwards a first write instruction including data and data address(es) to the error detection block 272. The initiator may write data of a predetermined size (e.g., 16 bytes) to the partition 250.

With reference to 7 receives the error detection block 272 (see 2 , 8th and 10 ) in a first block 702, the first write instruction including the data and data address(es) from the initiator. In block 704, the error detection block 272 selects a portion of the data and one of the data address(es) corresponding to that portion. As a non-limiting example, the error detection block 272 may select a byte of the data in block 704 and the data address corresponding to the selected byte. In some embodiments, the first write instruction may include only a single data address (e.g., a first address). Subsequent data addresses may be determined based on that single address (e.g., by adding a predetermined data size to the single data address). Therefore, in some embodiments, the data address may be calculated in block 704 for at least some of the data.

Then, in block 706, the error detection block 272 determines an error detection code for the portion of data selected in block 704 (e.g., using equation 1 above). Then, in block 708, the error detection block 272 directs the first write instruction, which includes the portion of data selected in block 704 and the corresponding data address, to the first sub-area 252 (see 8th and 10 ) of the spin-off 250 (see 2 , 8th and 10 ). According to the first write instruction, the partition 250 stores the section in the corresponding data address in the first subarea 252.

In the next block 710, the error detection block 272 (see 2 , 8th and 10 ) a code address for the error detection code determined in block 706 (e.g., using equation 2 above). In block 712, the error detection block 272 waits (e.g., several clock cycles) to send the error detection code to the first sub-area 252 (see 8th and 10 ) of the spin-off 250 (see 2 , 8th and 10 ) to thereby store it in the code address. Thus, in block 712, the error detection block 272 introduces a delay between storing the data in the data address and storing the error detection code in the code address. The error detection block 272 may include a write delay timer (not shown) used to determine how long the error detection block 272 waits in block 712. Thus, the error detection block 272 may wait a fifth predetermined period of time before sending the error detection code to the partition 250 for storage in the code address. Next, in block 714, the error detection block 272 sends a second write instruction including the error detection code determined in block 706 and the code address determined in block 710 to the second partition 254 (see 8th and 10 ) of the spin-off 250 (see 2 , 8th and 10 ). The error detection block 272 thus accesses the partition 250 twice to store the data, once each in blocks 708 and 714. According to the second write instruction, the partition 250 stores the error detection code in the code address in the second subarea 254.

In decision block 716, the error detection block 272 (see 2 , 8th and 10 ) whether any of the data was not stored. The decision in decision block 716 is "YES" if the error detection block 272 determines that at least some of the data was not stored. Otherwise, the decision in decision block 516 is "NO." If the decision in decision block 716 is "YES," the error detection block 272 returns to block 704 to select a new portion of the data. Conversely, if the decision in decision block 716 is "NO," the error detection block 272 returns to block 702 to receive new data and a new data address(es).

As mentioned above, the error detection block 272 may latch two or more bytes of data and their corresponding error detection codes before storing them in the partition 250. For example, blocks 706-714 may each be performed for multiple blocks of data (e.g., selected in block 704). As a non-limiting example, the error detection block 272 may perform block 706 for two or more bytes of data before sending the first write instruction along with the bytes of data and corresponding data address(es) to the partition 250 in block 708. For example, the error detection block 272 may send the bytes of data along with a first data address to the first partition 252. The first partition 252 may write the bytes of data to consecutive memory addresses starting with the first data address. Then, in block 710, the error detection block 272 may determine code addresses for the two or more error detection codes determined in block 706. In block 712, the error detection block 272 introduces a delay between writing the bytes of data and writing the error detection codes to the partition 250. Then, in block 714, the error detection block 272 passes the second write instruction including the error detection codes and the code addresses to the second partition 254. The second partition 254 writes the error detection codes to the code addresses. Depending on implementation details, the second write instruction may only include a first code address and the second partition 254 may write the error detection codes to consecutive memory addresses starting with the first code address.

8th illustrates an example of the error detection block 272 that implements the method 700 (see 7 ). The SI 110 may include one or more initiators 800, such as the processor 140, the DMA engine 402, and the like, each operating within the SI domain. In 8th the initiator(s) 800 include an initiator 802 (e.g., the processor 140). The initiator 802 (e.g., the processor 140) can write data of a predetermined size (e.g., 16 bytes) to the partition 250. In the 8th In the example illustrated, the initiator 802 sends 16 bytes of data and a first data address to the error detection block 272. The data is 8th stored in or represented by an array of 128 bits called "wdata_in[127:0]" and the first data address is stored in 8th stored in or represented by an array of 40 bits named "address_0[39:0]". However, depending on implementation details, the data may be of other sizes and 128 bits is provided as a non-limiting example. Similarly, the first data address may be of other sizes and 40 bits is provided as a non-limiting example. The first byte of data may be stored in the first data address, then a next data address for a second byte of data may be identified by adding a byte to the first data address, and so on. 8th shows the initiator 802 sending a first write instruction 804 to the fault detection block 272 in a signal 806 via a safety island interconnect 808. As mentioned above, the first write instruction 804 includes the data and the first data address. The safety island interconnect 808 may be implemented as a bus and the like.

The safety island interconnection 808 provides the first write instruction 804 to the error detection block 272 (e.g. block 702 in 7 ). In the illustrated embodiment, the safety island interconnect 808 provides the first write instruction 804 in signals 810-0 through 810-15, each of which includes one of the bytes of data and the first data address. In this embodiment, the error detection block 272 generates an error detection code for each byte of data, and the generated error detection code is a CRC code. The error detection block 272 may begin processing the bytes as indicated in the signals 810-0 through 810-15 (e.g., block 704 in 7 ) can be received.

Next, the code generation sub-block 273 determines an error detection code for each byte of data (e.g., block 706 in 7 ). In 8th the signals carrying the error detection codes and a signal 838 carrying responses from the outsource 250 concerning the error detection codes are illustrated by dashed line arrows. Thus, the code generation sub-block 273 outputs the bytes of data in the signals 812-0 to 812-15 and the corresponding error detection codes in the signals 814-0 to 814-15. The (data) signals 812-0 to 812-15 are passed to the first Sub-area 252 and the (code) signals 814-0 to 814-15 are forwarded to the second sub-area 254 for storage.

The error detection block 272 sends the data and the first data address (e.g. in signals 812-0 to 812-15) via the volatile memory interface 200A (see 2 ) at a first point in time (e.g. in 8th referred to as “time=T0”) to the first sub-area 252 of the outsourcing 250. In other words, the error detection block 272 sends the first write instruction to the first sub-area 252 of the outsourcing 250 (e.g., block 708 in 7 ). The volatile memory interface 200A communicates the first write instruction via a data backbone and memory subsystem 826 of the automotive SoC 104 (see 1 , 2 and 4 ) to the spin-off 250. In 8th the first write instruction is sent by the error detection block 272 in a signal 824 to the first subarea 252.

The first subarea 252 writes the data into memory by writing the first byte (in 8th as “Data0” “represented”) at the first data address (in 8th represented as “Address_0”) and the subsequent bytes are written to subsequent data addresses after the first data address. This writing occurs at the first time, which is 8th as "Time=T0". Then, the first sub-area 252 sends a response signal 828 to the initiator 802 confirming that the data has been stored. The response signal 828 is sent by the first sub-area 252 to the data backbone and storage subsystem 826, which sends the response signal 828 to the volatile memory interface 200A (see 2 ). When the volatile memory interface 200A is unlocked, the volatile memory interface 200A forwards the response signal 828 to a first (data) buffer 820.

The first (data) buffer 820 reorders the “data write completion responses” received in the response signal 828 from the spin-off 250. For example, the error detection block 272 may reorder a pair of write instructions A and B (e.g., in the first write instruction received in block 708 in 7 sent) to the outsource 250, with write instruction B being sent by the error detection block 272 after write instruction A. After the outsource 250 has written the data included in write instructions A and B, the outsource 250 sends first and second data write completion responses to the error detection block 272. However, the second data write completion response received for write instruction B may arrive at the error detection block 272 before the first data write completion response for write instruction A. When this happens, the first (data) buffer 820 stores the second data write completion response, waits for the first data write completion response, sends the first data write completion response when it arrives, and sends the second data write completion response after the first data write completion response. The first (data) buffer 820 thus places the data write completion responses in an expected order in the response signal 828.

The first (data) buffer 820 forwards the response signal 828 to the safety island interconnection 808, which forwards the response signal 828 to the initiator 802. At this point, in this example, the data (e.g., 16 bytes) were written to the first subarea 252 in a first single write operation.

The error detection block 272 also determines a first code address based on the first data address (e.g., block 710 in 7 ). In 8th the first code address is calculated by adding 16 megabytes ("MB") to the first data address. However, depending on the implementation details, the offset may also have other sizes and may be 16 MB, for example. Furthermore, the location of the first code address may be determined using other methods and/or calculations.

The error detection block 272 waits (e.g. block 712 in 7 ) to the second point in time (e.g. in 8th referred to as “time=T1”). The first and second times are different. At the second time, the error detection block 272 sends the error detection codes and the first code address via the volatile memory interface 200A (see 2 ) to the second sub-area 254 of the outsourcing 250. In other words, the error detection block 272 sends the second write instruction to the second sub-area 254 of the outsourcing 250 (e.g., block 714 in 7 ). The volatile memory interface 200A communicates the second write instruction via the data backbone and memory subsystem 826 of the automotive SoC 104 (see 1 , 2 and 4 ) to the spin-off 250. In 8th the second write instruction is sent by the error detection block 272 in a signal 834 to the second subarea 254.

The second subarea 254 writes the error detection codes into the memory by the first error detection code (shown in 8th as “CRC0”) at the first code address (shown in 8th as "Address_1") and the subsequent error detection codes are written to subsequent code addresses after the first code address. Then the second sub-area 254 sends a response signal 838 to the initiator 802, which confirms that the error detection codes have been stored. In the 8th illustrated embodiment, the response signal 838 is sent by the second portion 254 to the data backbone and storage subsystem 826, which transmits the response signal 838 to the volatile memory interface 200A (see 2 ). When the volatile memory interface 200A is unlocked, the volatile memory interface 200A forwards the response signal 838 to a second (code) buffer 822. The second (code) buffer 822 reorders the "code write completion responses" received in the response signal 838 from the outsource 250. For example, the error detection block 272 determines first and second error detection codes for the data included in write instructions A and B, respectively, and sends the first and second error detection codes to the outsource 250 (e.g., in the second write instruction). After the decommissioner 250 writes the first and second error detection codes to memory, the decommissioner 250 sends first and second code write completion responses, respectively, to the second (code) buffer 822. However, the second code write completion response received for the second error detection code may arrive at the error detection block 272 before the first code write completion response for the first error detection code. When this happens, the second (code) buffer 822 stores the second code write completion response, waits for the first code write completion response, sends the first code write completion response when it arrives, and sends the second code write completion response after the first code write completion response.

The second (code) buffer 822 may drop the response signal 838. Alternatively, the second (code) buffer 822 may forward the response signal 838 to the safety island interconnect 808, which may forward the response signal 838 to the initiator 802. At this point, in this example, in a second single write operation, the error detection codes (e.g., 16 bytes) have been written to the second subarea 254.

The volatile memory interface 200A may include two parallel and optionally dedicated interfaces connecting the error detection block 272 to the volatile memory 126. The first interface may send the data to the first data address and the second interface may send the error detection code(s) to the first code address. In such embodiments, the error detection block 272 may send the first write instruction including the data and the first data address (e.g., in signal 824) to the first sub-area 252 over the first interface simultaneously with the error detection block 272 sending the second write instruction including the error detection code(s) and the first code address (e.g., in signal 834) to the second sub-area 254 over the second interface. Furthermore, the (data) response signal 828 and the (code) response signal 838 can be transmitted simultaneously via the first and second interfaces to the first and second buffers 820 and 822, respectively.

When the initiator 802 (e.g., processor 140) of the SI 110 wishes to read the data from the spin-off 250, the SI 110 receives both the data and the error detection code(s) from the spin-off 250. The SI 110 introduces a delay between reading the data from the data address(es) and reading the error detection code(s) from the code address(es). This delay reduces the likelihood that an event that negatively affects the data will also negatively affect the error detection code. The SI 110 passes the read data through the error detection block 272, which determines a check code for the read data and compares the error detection code to the check code. This comparison can be represented by an equation 3 below: $$\text{CRC\_gen}\left(\text{Requested address},\text{Retrieved data}\right)=={\text{CRC\_in}}_{\text{Bytes x}}\left(\text{CRC\_Address}\right)$$

In Equation 3, an operator "==" indicates whether an expression to the left of the operator "=" is equal to an expression to the right of the operator "==". A variable "retrieved data" represents at least one section (e.g., byte x) of the data obtained in block 906, a variable "requested address" represents the data address of that section of the data, and a variable "CRC_address" represents the code address determined based on the data address of the section (e.g., byte x) of the data. A function "CRC_gen" takes the values of the variables "retrieved data" and "requested address" as inputs, and the function "CRC_gen" outputs the check code for the section (e.g., byte x). The function "CRC_gen" may be identical. be identical with the function “CRC” of equation 1 above. The output of the function “CRC_gen” may be at least partially generated by the code generation sub-block 273 (see 8th ), if present. An expression "crc_inByte x(CRC_address)" represents the error detection code obtained from the code address determined for the section (e.g., byte x) using its data address. Equation 3 thus determines whether the check code is equal to or matches the error detection code. The error detection block 272 may generate a mismatch error if the check code does not match the error detection code. The error detection block 272 may send the mismatch error to the initiator 802 and the SI fault aggregator 142 so that the mismatch error can be cleared by safety software implemented by instructions 149 and executed by the processor 140.

Referring now to 9 Each block of a method 900 described herein includes a computational process that may be performed using any combination of hardware, firmware, and/or software. For example, the method 900 may be performed by the hardware of the error detection block 272 (see 2 , 8th and 10 ). As another non-limiting example, one or more functions may be performed by a processor (e.g., the processor described in 1 , 2 and 4 illustrated processor 140) that executes instructions (e.g. those described in the 1 , 2 and 4 instructions 149) stored in a memory (e.g., the memory in the 1 , 2 and 4 illustrated volatile memory 146). At least portions of the method 900 may be embodied as computer-usable instructions stored on computer storage media. The method 900 may be provided by a standalone application, a service or hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. Moreover, the method 900 is exemplary described with reference to the automotive platform 100 of 1 However, the method 900 may additionally or alternatively be performed by a system or combination of systems, including but not limited to those described herein.

9 is a flowchart illustrating the method 900 for reading data from the spin-off 250 (see 2 , 8th and 10 ), according to some embodiments of the present disclosure. For better illustration, the method 900 is illustrated as being performed by the error detection block 272 (see 2 , 8th and 10 ) is described. Before starting the procedure 900, the initiator 802 (see 8th ) forwards a first read instruction including one or more data addresses to the error detection block 272. As a non-limiting example, the first read instruction may only include a first data address. Referring to 9 In a first block 902, the error detection block 272 receives the first read instruction including the data address(es) from the initiator 802. In block 904, the error detection block 272 forwards the first read instruction to the first partition 252, which requests the data stored at the data address(es). If the first read instruction includes only the first data address, the first partition 252 may read a predetermined amount of data (e.g., 16 bytes) from consecutive memory addresses starting at the first data address. In block 906, the error detection block 272 receives the data stored at the data address(es) from the first partition 252.

Then, in block 908, the error detection block 272 determines the code address(es) for the error detection code(s) corresponding to the data (e.g., using Equation 2 above). As a non-limiting example, the code address(es) may be determined based at least in part on the data address(es). For example, according to Equation 2 above, each of the code address(es) may be calculated by adding the offset (the value of the variable “fixed_offset”) to a corresponding one of the data address(es) (the value of the variable “write_address”). Depending on the implementation details, the error detection block 272 may only identify a first code address based on the first data address. Then, in block 910, the error detection block 272 waits (e.g., a few clock cycles) to request the error detection code(s) stored at the code address(es) determined in block 908. Thus, in block 910, the error detection block 272 introduces a delay between reading the data and reading the error detection code(s) from the code address(es). The error detection block 272 may include a read delay timer (not shown) used to determine how long the error detection block 272 waits in block 910. Thus, the error detection block 272 may wait a sixth predetermined period of time before requesting the error detection code(s) from the second partition 254.

After waiting, the error detection block 272 sends a second read instruction to the second subarea 254 in the next block 912, which contains the code address(es) determined in block 908 and requests the error detection code(s) stored at that code address(es). The error detection block 272 thus accesses the partition 250 twice to read the data, once each in blocks 904 and 912. If the second read instruction includes only the first code address, the second partition 254 may read a predetermined number of error detection codes (e.g., 16 bytes) from consecutive memory addresses starting at the first code address. In block 914, the error detection block 272 receives the error detection code(s) stored at the code address(es) from the second partition 254. In block 916, the error detection block 272 determines a check code for each of the error detection codes obtained in block 914 (e.g., using Equation 1 above).

At decision block 918, the error detection block 272 determines for each of the error detection code(s) whether the error detection code matches the check code corresponding to the error detection code (e.g., using Equation 3 above). The decision in decision block 918 is "YES" if the error detection code matches its corresponding check code. Otherwise, the decision in decision block 918 is "NO". If the decision in decision block 918 is "YES", the error detection block 272 passes the data corresponding to the error detection code to the initiator 802 in block 920 (see 8th ). If the decision in decision block 918 is “NO”, the error detection block 272 generates a mismatch error in block 922 and sends it to the initiator 802 and the SI fault aggregator 142 (see 1 , 2 and 4 ) so that the mismatch error can be cleared by security software implemented by instructions 149 and executed by processor 140. Optionally, if the error detection code (e.g., implemented as ECC) includes information (e.g., bits) that can be used to recover the data, error detection block 272 may attempt to correct the mismatch in block 922. If error detection block 272 is able to correct the error, error detection block 272 may omit generating the mismatch error in block 922. After block 920, error detection block 272 proceeds to block 920 and passes the data to initiator 802. Method 900 then ends.

The error detection block 272 may read two or more bytes of data and their corresponding error detection codes from the carve-out 250 at a time. For example, blocks 904-914 may each be performed for multiple data blocks. As a non-limiting example, in block 904, the error detection block 272 may send the first read instruction to the first sub-area 252 requesting two or more bytes of data from a first data address. The first sub-area 252 may read the bytes of data from consecutive memory addresses beginning with the first data address and send the bytes of data to the error detection block 272 that the error detection block 272 receives in block 906. Then, in block 908, the error detection block 272 may determine code address(es) based on the data address(es). Depending on implementation details, the error detection block 272 may only identify a first code address based on the first data address. Then, in block 910, the error detection block 272 introduces a delay between reading the bytes of data and reading the error detection codes from the carve-out 250. The error detection block 272 may then request the error detection codes stored in the carve-out 250 for the bytes of data obtained in block 906. For example, the error detection block 272 may send the first code address to the second sub-area 254. The second sub-area 254 may read the error detection codes from consecutive memory addresses starting with the first code address and send the error detection codes to the error detection block 272, which the error detection block 272 receives in block 914. The method 900 then continues with block 916.

10 illustrates an example of the error detection block 272 that performs the method 900. In this example, the processor 140 reads 16 bytes of data from the partition 250 provided by the 8th illustrated example. In 10 the read data is stored in or represented by an array of 128 bits named "rdata_in[127:0]" and the data is stored starting with the first data address, which is stored in or represented by an array of 40 bits named "address_0[39:0]". 10 shows the initiator 802 (e.g., the processor 140) sending a first read instruction 1004 to the fault detection block 272 via the safety island interconnect 808. The safety island interconnect 808 provides the first read instruction 1004 to the fault detection block 272 (e.g., block 902 in 9 ).

The error detection block 272 sends the first data address via the volatile memory interface 200A (see 2 ) at a third point in time (e.g. in 8th referred to as “time=T3”) to the first sub-area 252 of the outsourcing 250. In other words, the error detection block 272 forwards the first read instruction to the first subarea 252 of the outsourcing 250 (e.g. block 904 in 9 ). The volatile memory interface 200A communicates the first read instruction to the spin-off 250 via the data backbone and memory subsystem 826 of the automotive SoC 104. In 10 the first read instruction is sent by the error detection block 272 in a signal 1010 to the first subarea 252.

The first sub-area 252 reads the data from the memory starting with the first byte (“byte 0”) at the first data address and reads the subsequent bytes from subsequent data addresses after the first data address. The SI 110 may read data of a predetermined size (e.g., 16 bytes) from the partition 250. Then, the first sub-area 252 sends a response signal 1012 to the initiator 802 that includes the read data. The response signal 1012 is sent by the first sub-area 252 to the data backbone and storage subsystem 826, which sends the response signal 1012 to the volatile memory interface 200A (see 2 ). When the volatile memory interface 200A is unlocked, the volatile memory interface 200A forwards the response signal 1012 to a first (data) buffer 820 (e.g., block 906 in 9 ). The data read and included in the response signal 1012 automatically indicates the data read completions and thus may be characterized as data read completion responses. As the first (data) buffer 820 does with the data write completion responses, the first (data) buffer 820 may place the data read completion responses in an expected order in the response signal 1012. At this point, in this example, the data (e.g., 16 bytes) has been read from the first sub-area 252 in a first single read operation and placed in the expected order by the first (data) buffer 820.

Then, the error detection block 272 determines a first code address (“Address_1”) based on the first data address (e.g., block 908 in 9 ). In 10 the first code address is calculated by adding (for example) 16 megabytes (“MB”) to the first data address (“Address_0”).

Next, the error detection block 272 (e.g. block 910 in 9 ) to a fourth point in time (e.g. in 10 identified as “Time=T4”). At the fourth time, the error detection block 272 requests the error detection code(s) stored at the first code address(es) within the second sub-area 254 via the volatile memory interface 200A (see 2 ). In other words, the error detection block 272 sends the second read instruction to the second subarea 254 of the partition 250 (e.g., block 912 in 9 ). The volatile memory interface 200A communicates the second read instruction to the spin-off 250 via the data backbone and memory subsystem 826 of the automotive SoC 104. In 10 the second read instruction is sent by the error detection block 272 in a signal 1014 to the second subarea 254.

The second sub-area 254 reads the error detection codes from the memory by reading the first error detection code (for “byte 0”) at the first code address and reading the subsequent error detection codes from subsequent code addresses after the first code address. In the example of 8th and 10 the error detection code(s) are each one byte in size. Then the second sub-area 254 sends a response signal 1016 to the initiator 802, which contains the error detection code(s) read from the memory. In 10 are signals that carry the error detection codes, and the signal 1014 is illustrated by dashed arrows. 10 illustrated embodiment, the response signal 1016 is sent by the second portion 254 to the data backbone and storage subsystem 826, which transmits the response signal 1016 to the volatile memory interface 200A (see 2 ). When the volatile memory interface 200A is unlocked, the volatile memory interface 200A forwards the response signal 1016 to a second (code) buffer 822 (e.g., block 914 in 9 ). The error detection codes read and included in the response signal 1016 automatically indicate the data read completions and therefore may be characterized as data read completion responses. As the second (code) buffer 822 does with the code write completion responses, the second (code) buffer 822 may place the code read completion responses in an expected order in the response signal 1016. At this point, in this example, the error detection codes (e.g., 16 bytes) have been read from the second sub-area 254 in a second single read operation and placed in the expected order by the second (code) buffer 822.

If the error detection block 272 is not active until the fourth time (e.g. in 10 referred to as time=T4) waits (e.g. block 910 in 9 ), the error detection block 272 merely separates the first and second read instructions in time. The error detection block 272 may request the error detection code(s) from the second subarea 254 after the error detection block 272 has received the data in the response signal 1012. Alternatively, the error detection block 272 may not wait until it receives the data in the Response signal 1012 before requesting the error detection code(s) from the second subarea 254. In other words, the fourth time may be determined based on the sending of the first read instruction and not on the receiving of the response signal 1012.

As mentioned above, the first (data) buffer 820 may reorder the bytes because the bytes in the response signal 1012 may be scrambled. Similarly, the second (code) buffer 822 may reorder the error detection codes if the error detection codes in the response signal 1016 are scrambled. The first (data) buffer 820 outputs signals 1022-0 through 1022-15, each carrying one of the bytes of data, and the second (code) buffer 822 outputs signals 1024-0 through 1024-15, each carrying one of the error detection codes. The signals 1022-0 through 1022-15 correspond to the signals 1024-0 through 1024-15, respectively. The first and second buffers 820 and 822 may route or reorder the signals 1022-0 through 1022-15 and 1024-0 through 1024-15 to position each byte of data at a known location relative to the error detection code created for the byte. In the 10 illustrated embodiment, the bytes carried by signals 1022-0 through 1022-15 are interleaved with the error detection codes carried by signals 1024-0 through 1024-15. Thus, as in 10 , the bytes of data are placed at locations represented by the hatched blocks b0-b15, and the error detection code(s) are placed at locations represented by the blocks c0-c15.

Then, the code generation sub-block 273 determines (e.g., using Equation 1 above) a check code for each of the bytes of data (e.g., block 916 in 9 ). Thus, code generation sub-block 273 receives the bytes of data in signals 1022-0 through 1022-15 and the corresponding error detection codes in signals 1024-0 through 1024-15 as inputs.

The error detection block 272 determines for each of the error detection codes whether the error detection code matches the check code corresponding to the error detection code (e.g., decision block 918 in 9 ). The error detection block 272 indicates whether they match in a pass signal 1030 which is passed along with a data signal 1032 containing the byte of data to a logic component 1034 which is in 10 implemented as an AND gate. If the pass signal 1030 indicates that the error detection code stored for the byte matches the check code generated for the byte, the logic component 1034 outputs the byte in a checked data signal 1036 (which includes only bytes of data) and passes the checked data signal 1036 to the initiator 802. Conversely, if the pass signal 1030 indicates a mismatch, the logic component 1034 does not pass the byte in the checked data signal 1036 to the initiator 802. Instead, the error detection block 272 may discard the byte and/or replace the byte with information (e.g., zeros) indicating that a mismatch occurred. As a non-limiting example, the bits of the byte that generated the mismatch may be set to zero. The tested data signal 1036 is sent to the initiator 802 (e.g. block 920 in 9 ). The error detection block 272 may generate and send a mismatch error to the initiator 802 if the error detection code does not match the check code corresponding to the error detection code (e.g., block 922 in 9 ). In other words, if the pass signal 1030 indicates one or more mismatches, the error detection block 272 may generate and send a mismatch error to the initiator 802. Alternatively or additionally, the error detection block 272 may send the mismatch error to the SI fault aggregator 142 as an uncorrected error. Thus, an error that occurs in the data or error detection code(s) during storage in the partition 250 and/or retrieval from the partition 250 may be detected and reported (e.g., as an uncorrected error).

As mentioned above, the volatile memory interface 200A may include the two parallel and optionally dedicated interfaces connecting the error detection block 272 to the volatile memory 126. In such embodiments, the error detection block 272 may send the first read instruction including the first data address (e.g., in the signal 1010) to the first partition 252 over the first interface simultaneously with the error detection block 272 sending the second read instruction including the first code address (e.g., in the signal 1014) to the second partition 254 over the second interface. Furthermore, the data read from the first sub-area 252 (e.g., and transmitted in the response signal 1012) and the error detection code(s) read from the second sub-area 254 (e.g., and transmitted in the response signal 1016) may be simultaneously transmitted to the first and second buffers 820 and 822, respectively, via the first and second interfaces, respectively.

With reference to 2 the error detection block 272 may include or be connected to at least one transaction timer, such as egress and ingress timers 274 and 276, that limits a period of time that the error detection block 272 has to read data from and/or write data to the egress 250. The egress timer 274 and/or the ingress timer 276 start automatically when an access passes through the error detection block 272. For example, the ingress timer 276 may start whenever data passes between the error detection block 272 and the initiator 802 (e.g., the processor 140), and the egress timer 274 may start whenever data passes between the error detection block 272 and the SoC domain (e.g., the egress 250). The ingress timer 276 may help monitor the operation of the error detection block 272 and/or may help provide backup functionality for the egress timer 274 (e.g., if the egress timer 274 is not functioning properly).

During a write operation, the ingress timer 276 may start when the initiator 802 passes data to the error detection block 272 to enter the outgress 250 (e.g., at block 702 in 7 ). Then, the egress timer 274 may start when this data leaves the error detection block 272 and/or the SI domain (e.g., at block 708 in 7 ). The egress timer 274 may stop or be reset when the response (e.g., the 8th illustrated response signal 828) from the outsource 250 is received by the error detection block 272. Then, the ingress timer 276 may stop or reset when the response (e.g., the 8th illustrated response signal 828) by the error detection block 272 to the initiator 802 (see 8th ). If the egress timer 274 indicates that more than a first threshold time period has elapsed and the error detection block 272 has not received the response, meaning that the initiator 802 has not received a response from the egress 250 (e.g., the 8th illustrated response signal 828), the initiator 802 (e.g., the processor 140) generates an egress timeout error. If the ingress timer 276 indicates that more than a second threshold time period has elapsed and the error detection block 272 has not sent the response to the initiator 802, meaning that the initiator 802 has not received a response from the outsource 250, the initiator 802 generates an ingress timeout error.

During a read operation, the ingress timer 276 may start when the error detection block 272 receives the read request from the initiator 802 (e.g., at block 902 in 9 ). Then, the egress timer 274 may start when the error detection block 272 retrieves the data stored at the first data address from the egress 250 (e.g., at block 904 in 9 ). The egress timer 274 may stop or be reset when the data from the egress 250 is received by the error detection block 272 (e.g., at block 906 in 9 ). Then, the ingress timer 276 may stop or be reset when the data is transferred to the initiator 802 by the error detection block 272 (e.g., at block 920 in 9 ). If the egress timer 274 indicates that the first threshold period has elapsed and the error detection block 272 has not received the data from the egress 250, meaning that the initiator 802 has received the data from the error detection block 272 (e.g., in the example shown in 10 If the ingress timer 276 indicates that more than the second threshold time period has elapsed and the error detection block 272 has not sent the data to the initiator 802, meaning that the initiator 802 has not received data from the egress 250, the initiator 802 generates an ingress timeout error.

11 is an illustration of a block diagram showing error messages generated by the error detection block 272 (see 2 , 8th and 10 ) are generated when the error detection block 272 triggers the egress and ingress timers 274 and 276 (see 2 ), according to some embodiments. In 11 the initiator sends 802 (see 8th and 10 ) a signal 1102 which either indicates the first write instruction 804 (see 8th ) or the first reading instruction 1004 (see 10 ) to the error detection block 272. As mentioned above, the egress timer 274 may start when the data leaves the error detection block 272 and/or the SI domain during a write operation, and the egress timer 274 may start when the error detection block 272 requests the data stored at the first data address from the egress 250 during a read operation. Block 1104 indicates that the egress timer 274 has timed out. For example, the egress timer 274 may time out if the error detection block 272 does not receive a response from the egress 250 (e.g., the one shown in 8th illustrated response signal 828) and more than the first threshold time period has elapsed. As another non-limiting example, the egress timer 274 may time out when the error detection block 272 receives the data from the error detection block 272 (e.g., in the 10 illustrated response signal 1012) during a reading operation and more when the first threshold time period has elapsed. If the egress timer 274 times out, the initiator 802 (e.g., the processor 140) generates an egress timeout error 1106 and forwards the egress timeout error 1106 to an error logger 1108. On the other hand, if the egress timer 274 does not time out, the egress timer 274 may stop or be reset. This may occur if the error detection block 272 receives either the response (e.g., response signal 828) from the egress 250 during a write operation or the data (e.g., in response signal 1012) from the egress 250 during a read operation before the first threshold time period has elapsed.

As mentioned above, the ingress timer 276 may start when the initiator 802 passes data to the error detection block 272 during a write operation to enter the outgress 250 (e.g., at block 702 in 7 ), or the ingress timer 276 may start when the error detection block 272 is triggered during a read operation (e.g., at block 902 in 9 ) receives the read request from the initiator 802. Thus, the ingress timer 276 (see 2 ) when the signal 1102 receives the first read instruction 804 (see 8th ) or the first reading instruction 1004 (see 10 ) and this instruction is checked by the error detection block 272 (see 2 , 8th and 10 ) is received. Block 1114 indicates that the ingress timer 276 has timed out. For example, the ingress timer 276 may time out if more than the second threshold time period has elapsed and the initiator 802 (see 8th ) during a write operation no response from the outsourcing 250 (e.g. the 8th response signal 828 illustrated). As another non-limiting example, the ingress timer 276 may time out if more than the second threshold time period has elapsed and the initiator 802 has received the data (e.g., the 10 illustrated) from the ingress gate 250 during a read operation. If the ingress timer 276 times out, the initiator 802 generates an ingress timeout error 1116 and forwards the ingress timeout error 1116 to the error logger 1108. On the other hand, if the ingress timer 276 does not time out, the ingress timer 276 may stop or be reset. This may occur when the error detection block 272 transmits the response (e.g., response signal 828) to the initiator 802 during a write operation or the error detection block 272 transmits the data (e.g., the inspected data signal 1036) to the initiator 802 during a read operation.

Block 1124 indicates that the code generation sub-block 273 (see 2 , 8th and 10 ) of the error detection block 272 (see 2 , 8th and 10 ) may generate a code generation/check error 1126 indicating that an error occurred during the generation of an error detection code or a check code. In some embodiments, the code generation/check error 1126 may be used to indicate that a mismatch occurred. As a non-limiting example, when the signal 1102 includes the first write instruction 804, the code generation sub-block 273 may generate a code generation error while generating the error detection code(s). As further non-limiting examples, when the signal 1102 includes the first read instruction 1004, the error detection block 272 may generate a mismatch error and/or a code generation error during the generation of the check code(s), which may be forwarded to the error logger 1108 as a code generation/check error 1126.

The error logger 1108 may act as a fault aggregator that aggregates the errors 1106, 1116, and 1126 into an error message 1130 that the error logger 1108 sends to the SI fault aggregator 142.

When the automotive SoC 104 first boots, the processor 140 of the SI 110 may attempt to prefetch data from the spin-off 250. The prefetch may be characterized as a type of unintentional reading of data from the spin-off 250. Because the shared volatile memory 126 is volatile, the spin-off 250 may store uninitialized data at this point that does not have any error detection code(s) or is associated with mismatched error detection code(s). To prevent the error detection block 272 from generating mismatch errors, the SI 110 (e.g., the processor 140, the DMA engine 402, and/or the like) may write one or more error detection codes to the spin-off 250 for the data that the processor 140 will or may prefetch. As a non-limiting example, the SI 110 may write initial data to the partition 250, causing the hardware of the error detection block 272 to determine one or more error detection codes for the initial data, each associated with a code address. Then, the SI 110 may cause the partition 250 to store each error detection code in its associated code address. Thus, during a prefetch, the error detection codes that stored by the second subarea 254 corresponds to the data stored in the first subarea 252 and the error detection block 272 will not generate any mismatch errors.

SI 110 can be interpreted with reference to 2 the code generation sub-block 273 (see 2 , 8th and 10 ) and/or the error detection block 272 (e.g. by means of a software register write) when the motor vehicle platform 100 (see 1 ) the outsourcing 250 is not required. For example, the SI 110 may disable the code generation sub-block 273 and/or the error detection block 272 when the volatile memory 126 is operating at a risk level sufficient for the automotive platform 100.

It should be understood that these and other arrangements described herein are provided as examples only. Other arrangements and elements (e.g., engines, interfaces, functions, instructions, groupings of functions, etc.) may be used in addition to or in place of those shown, and some elements may be omitted entirely. Further, many of the elements described herein are functional units that may be implemented as discrete or distributed components, or in conjunction with other components, and in any suitable combination and location. Various functions described herein as being performed by units may be performed by hardware, firmware, and/or software. For example, various functions may be performed by a processor executing instructions stored in memory.

EXEMPLARY AUTONOMOUS VEHICLE

12 is an illustration of an example autonomous vehicle 1200 in accordance with some embodiments of the present disclosure. The autonomous vehicle 1200 (alternatively referred to herein as “vehicle 1200”) may be, without limitation, a passenger vehicle, such as a car, a truck, a bus, an emergency vehicle, a shuttle, an electric or motorized bicycle, a motorcycle, a fire truck, a police vehicle, an ambulance, a boat, a construction vehicle, an underwater vehicle, a drone, and/or another type of vehicle (e.g., an unmanned vehicle and/or a vehicle that accommodates one or more passengers). Autonomous vehicles are generally described in terms of automation levels defined by the National Highway Traffic Safety Administration (NHTSA), a division of the U.S. Department of Transportation, and the Society of Automotive Engineers (SAE) “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles” (e.g., Standard No. J3016-201806, published June 15, 2018, Standard No. J3016-201609, published September 30, 2016, and prior and future versions of that standard). The vehicle 1200 may be capable of functionality according to one or more of Level 2 - Level 5 of the levels for autonomous driving as defined by the SAE. For example, depending on the embodiment, the vehicle 1200 may be capable of partial automation of driving (Level 2), conditional automation (Level 3), high automation (Level 4), and/or full automation (Level 5).

The vehicle 1200 may include components such as a chassis, a vehicle body, wheels (e.g., 2, 4, 6, 8, 18, etc.), tires, axles, and other components of a vehicle. The vehicle 1200 may include a propulsion system 1250, such as an internal combustion engine, a hybrid electric powerplant, an all-electric motor, and/or another type of propulsion system. The propulsion system 1250 may be connected to a drivetrain of the vehicle 1200, which may include a transmission to facilitate propulsion of the vehicle 1200. The propulsion system 1250 may be controlled in response to receiving signals from the throttle/accelerator pedal 1252.

A steering system 1254, which may include a steering wheel, may be used to steer the vehicle 1200 (e.g., along a desired path or route) when the propulsion system 1250 is operating (e.g., when the vehicle is in motion). The steering system 1254 may receive signals from a steering actuator 1256. For full automation functionality (Level 5), the steering wheel may be optional.

The brake sensor system 1246 may be used to operate the vehicle brakes in response to receiving signals from the brake actuators 1248 and/or brake sensors.

Controller(s) 1236, the one or more CPU(s), System on Chips (SoCs) 1204 ( 14 ) and/or GPU(s), may include signals (e.g., representing commands) for a or multiple components and/or systems of the vehicle 1200. For example, the controller(s) may send signals to actuate the vehicle brakes via one or more brake actuators 1248, to actuate the steering system 1254 via one or more steering actuators 1256, and/or to operate the propulsion system 1250 via one or more throttle/accelerator pedal actuators 1252. The controller(s) 1236 may include one or more on-board (e.g., embedded) computing devices (e.g., supercomputers) that process sensor signals and issue operating commands (e.g., signals representing commands) to enable autonomous driving and/or to assist a human driver in operating the vehicle 1200. The controller(s) 1236 may include a first controller 1236 for autonomous driving functions, a second controller 1236 for functional safety functions, a third controller 1236 for artificial intelligence functionality (e.g., computer vision), a fourth controller 1236 for infotainment functionality, a fifth controller 1236 for emergency redundancy, and/or other controllers. In some examples, a single controller 1236 may handle two or more of the foregoing functionalities, two or more controllers 1236 may handle a single functionality, and/or any combination thereof.

The controller(s) 1236 provides signals to control one or more components and/or systems of the vehicle 1200 in response to sensor data received from one or more sensors (e.g., sensor inputs). The sensor data may be received, for example and without limitation, from global navigation satellite system sensor(s) 1258 (e.g., global positioning system sensor(s), RADAR sensor(s) 1260, vibration sensor(s) 1262, LIDAR sensor(s) 1264, inertial measurement unit (IMU) sensor(s) 1266 (e.g., accelerometer(s), gyroscope(s), magnetic compass(s), magnetometer(s), etc.), microphone(s) 1296, stereo camera(s) 1268, wide view camera(s) 1270 (e.g., fisheye cameras), infrared camera(s) 1272, environmental camera(s) 1274 (e.g., 360-degree cameras), long range and/or medium range camera(s) 1298, speed sensor(s) 1244 (e.g., for measuring the speed of the vehicle 1200), vibration sensor(s) 1242, steering sensor(s) 1240, brake sensor(s) 1246 (e.g., as part of the brake sensor system 1246), and/or other types of sensors.

One or more of the controllers 1236 may receive inputs (e.g., represented by input data) from an instrument cluster 1232 of the vehicle 1200 and provide outputs (e.g., represented by output data, display data, etc.) via a human-machine interface (HMI) display 1234, an audible annunciator, a speaker, and/or via other components of the vehicle 1200. The outputs may include information such as vehicle speed, RPM, time, mapping data (e.g., the HD map 1222 of 14 ), location data (e.g., the location of the vehicle 1200, such as on a map), direction, location of other vehicles (e.g., an occupancy grid), information about objects and status of objects as perceived by the controller(s) 1236, etc. For example, the HMI display 1234 may display information about the presence of one or more objects (e.g., a road sign, a warning sign, a changing traffic light, etc.) and/or information about maneuvers the vehicle has made, is making, or will make (e.g., that it is changing lanes now, will take exit 34B in two miles, etc.).

The vehicle 1200 further includes a network interface 1224 that may utilize wireless antenna(s) 1226 and/or modem(s) to communicate over one or more networks. For example, the network interface 1224 may be capable of communicating over LTE, WCDMA, UMTS, GSM, CDMA2000, etc. The wireless antenna(s) 1226 may also enable communication between objects in the environment (e.g., vehicles, mobile devices, etc.) using local area network(s) such as Bluetooth, Bluetooth LE, Z-Wave, ZigBee, etc. and/or low power wide-area networks (LPWANs) such as LoRaWAN, SigFox, etc.

As mentioned above, in at least some embodiments, the motor vehicle platform 100 (see 1 ) may be a component of the autonomous vehicle 1200. In such embodiments, the controller(s) 1236 include the automotive SoC 104.

13 is an example of the positions and fields of view of cameras for the exemplary autonomous vehicle 1200 of the 12 in accordance with some embodiments of the present disclosure. The cameras and corresponding fields of view represent an example embodiment and are not intended to be limiting. For example, additional and/or alternative cameras may be included and/or the cameras may be located at different locations on the vehicle 1200.

The camera types for cameras may include, but are not limited to, digital cameras designed for use with the components and/or systems of the vehicle 1200. The camera(s) may operate at Automotive Safety Integrity Level (ASIL) B and/or another ASIL. The camera types may be capable of any image capture rate, such as 60 frames per second (fps), 120 fps, 240 fps, etc., depending on the embodiment. The cameras may be capable of using rolling shutters, global shutters, another type of shutter, or a combination thereof. In some examples, the color filter array may include a red clear clear clear (RCCC) color filter array, a red clear clear blue (RCCB) color filter array, a red blue green clear (RBGC) color filter array, a Foveon X3 color filter array, a Bayer sensor (RGGB) color filter array, a monochrome sensor color filter array, and/or another type of color filter array. In some embodiments, clear pixel cameras, such as cameras with an RCCC, an RCCB, and/or an RBGC color filter array, may be used in an effort to increase light sensitivity.

In some examples, one or more of the camera(s) may be used to perform advanced driver assistance systems (ADAS) functions (e.g., as part of a redundant or fail-safe design). For example, a multi-function mono camera may be installed that provides functions such as lane departure warning, traffic sign assist, and intelligent headlight control. One or more of the camera(s) (e.g., all cameras) may simultaneously capture and provide image data (e.g., a video).

One or more of the cameras may be mounted in a mounting assembly, such as a custom designed (3D printed) assembly, to eliminate stray light and reflections from inside the car (e.g., reflections from the dashboard reflected in the windshield mirrors) that may affect the camera's image data collection capabilities. With reference to outside mirror mounting assemblies, the outside mirror assemblies may be custom 3D printed so that the camera mounting plate conforms to the shape of the outside mirror. In some examples, the camera(s) may be integrated into the side view mirror. For side view cameras, the camera(s) may also be integrated into the four pillars at each corner of the cab.

Cameras with a field of view that includes portions of the environment in front of the vehicle 1200 (e.g., forward-facing cameras) may be used for surround visibility to help identify forward paths and obstacles, as well as, with the assistance of one or more controllers 1236 and/or control SoCs, to help provide information critical to generating an occupancy grid and/or determining preferred vehicle paths. Forward-facing cameras may be used to perform many of the same ADAS functions as LIDAR, including emergency braking, pedestrian detection, and collision avoidance. Forward-facing cameras may also be used for ADAS functions and systems, including Lane Departure Warning (LDW), Autonomous Cruise Control (ACC), and/or other functions such as traffic sign recognition.

A variety of cameras may be used in a forward-facing configuration, including, for example, a monocular camera platform that includes a CMOS (complementary metal oxide semiconductor) color imager. Another example is a wide angle camera(s) 1270 that may be used to perceive objects coming into view from the periphery (e.g., pedestrians, crossing traffic, or bicycles). Although in 13 While only one wide-view camera is illustrated, any number of wide-view cameras 1270 may be present on the vehicle 1200. Additionally, a long-range camera(s) 1298 (e.g., a wide-view stereo camera pair) may be used for depth-based object detection, particularly for objects for which a neural network has not yet been trained. The long-range camera(s) 1298 may also be used for object detection and classification, as well as simple object tracking.

One or more stereo cameras 1268 may also be included in a forward-facing configuration. The stereo camera(s) 1268 may include an integrated control unit that includes a scalable processing unit that may provide programmable logic (e.g., FPGA) and a multi-core microprocessor with an integrated interface for CAN or Ethernet on a single chip. Such a unit may be used to generate a 3-D map of the vehicle's surroundings that includes a distance estimate for all points in the image. Alternative stereo camera(s) 1268 may include one or more compact stereo vision sensors that have two camera ob lenses (one each on the left and right) and an image processing chip that can measure the distance from the vehicle to the target object and use the information generated (e.g., metadata) to activate the autonomous emergency braking and lane departure warning functions. Other types of stereo camera(s) 1268 may be used in addition to or alternatively to those described herein.

Cameras with a field of view that includes portions of the environment to the side of the vehicle 1200 (e.g., side view cameras) may be used for surround view, thereby providing information used to create and update an occupancy grid and to generate side impact collision warnings. For example, the surround camera(s) 1274 (e.g., four surround cameras 1274 as shown in 13 illustrated) may be positioned on the vehicle 1200. The surround camera(s) 1274 may include wide view camera(s) 1270, fisheye camera(s), 360 degree camera(s), and/or the like. For example, four fisheye cameras may be mounted on the front, rear, and sides of the vehicle. In an alternative arrangement, the vehicle may utilize three surround cameras 1274 (e.g., left, right, and rear) and utilize one or more other cameras (e.g., a forward-facing camera) as a fourth surround camera.

Cameras with a field of view that includes portions of the environment behind the vehicle 1200 (e.g., rearview cameras) may be used for parking assistance, surround view, rear collision warnings, and creating and updating the occupancy grid. A wide variety of cameras may be used, including, but not limited to, cameras that are also suitable as forward-facing camera(s) (e.g., long and/or medium range camera(s) 1298, stereo camera(s) 1268, infrared camera(s) 1272, etc.) as described herein.

14 is a block diagram of an example system architecture for the example autonomous vehicle 1200 of the 12 in accordance with some embodiments of the present disclosure. It should be understood that these and other arrangements described herein are provided as examples only. Other arrangements and elements (e.g., engines, interfaces, functions, instructions, groupings of functions, etc.) may be used in addition to or in place of those shown, and some elements may be omitted entirely. Furthermore, many of the elements described herein are functional units that may be implemented as discrete or distributed components, or in conjunction with other components, and in any suitable combination and location. Various functions described herein as being performed by units may be performed by hardware, firmware, and/or software. For example, various functions may be performed by a processor executing instructions stored in memory.

Each of the components, features and systems of the 1200 vehicle in 14 are illustrated as being connected via bus 1202. Bus 1202 may include a Controller Area Network (CAN) data interface (alternatively referred to herein as a "CAN bus"). A CAN may be a network within vehicle 1200 used to support control of various features and functions of vehicle 1200, such as brake application, acceleration, braking, steering, windshield wipers, etc. A CAN bus may be configured to have dozens or even hundreds of nodes, each with its own unique identifier (e.g., a CAN ID). The CAN bus may be read to determine steering wheel angle, ground speed, engine revolutions per minute (RPMs), button positions, and/or other vehicle status indicators. The CAN bus may be ASIL B compliant.

Although bus 1202 is described herein as a CAN bus, this is not a limitation. For example, FlexRay and/or Ethernet may be used in addition to or as an alternative to the CAN bus. Although bus 1202 is shown with a single line, this is not a limitation. For example, there may be any number of buses 1202, which may include one or more CAN buses, one or more FlexRay buses, one or more Ethernet buses, and/or one or more other types of buses using a different protocol. In some examples, two or more buses 1202 may be used to perform different functions and/or may be used for redundancy. For example, a first bus 1202 may be used for collision avoidance functionality and a second bus 1202 may be used for actuation control. In each example, each bus 1202 may communicate with any components of vehicle 1200, and two or more buses 1202 may communicate with the same components. In some examples, each SoC 1204, each controller 1236, and/or each computer in the vehicle may have access to the same input data (e.g., inputs from sensors of the vehicle 1200) and be connected to a common bus, such as the CAN bus.

The vehicle 1200 may include one or more controllers 1236, such as those described herein with respect to 12 The controller(s) 1236 may be used for a variety of functions. The controller(s) 1236 may be coupled to any of various other components and systems of the vehicle 1200 and may be used to control the vehicle 1200, the artificial intelligence of the vehicle 1200, the infotainment for the vehicle 1200, and/or the like.

The vehicle 1200 may include a system (or multiple systems) on a chip (SoC) 1204. The SoC 1204 may include CPU(s) 1206, GPU(s) 1208, processor(s) 1210, cache(s) 1212, accelerator pedal(s) 1214, data storage 1216, and/or other components and functions not illustrated. The SoC(s) 1204 may be used to control the vehicle 1200 in a variety of platforms and systems. For example, the SoC(s) 1204 in a system (e.g., the system of the vehicle 1200) may be combined with an HD card 1222 that may be accessed via a network interface 1224 from one or more servers (e.g., the server(s) 1278 in 15 ) can obtain updates to the map.

The CPU(s) 1206 may include a CPU cluster or CPU complex (alternatively referred to herein as a "CCPLEX"). The CPU(s) 1206 may include multiple cores and/or L2 caches. For example, in some embodiments, the CPU(s) 1206 may include eight cores in a coherent multiprocessor configuration. In some embodiments, the CPU(s) 1206 may include four dual-core clusters, with each cluster having a dedicated L2 cache (e.g., a 2 MB L2 cache). The CPU(s) 1206 (e.g., CCPLEX) may be configured to support simultaneous cluster operations such that any combination of clusters of the CPU(s) 1206 may be active at any given time.

The CPU(s) 1206 may implement power management capabilities that include one or more of the following features: individual hardware blocks may be automatically clock controlled when idle to conserve dynamic power; each core clock may be controlled when the core is not actively executing instructions due to the execution of WFI/WFE instructions; each core may be independently power controlled; each core cluster may be independently clock controlled if all cores are clock controlled or power controlled; and/or each core cluster may be independently power controlled if all cores are power controlled. The CPU(s) 1206 may further implement an advanced power state management algorithm where allowable power states and expected wake-up times are specified and the hardware/microcode determines the best power state to enter for the core, cluster, and CCPLEX. The processing cores may support simplified power state entry sequences in software, offloading the work to the microcode.

The GPU(s) 1208 may include an integrated GPU (alternatively referred to herein as an "iGPU"). The GPU(s) 1208 may be programmable and efficient for parallel workloads. The GPU(s) 1208 may use an extended tensor instruction set in some examples. The GPU(s) 1208 may include one or more streaming microprocessors, where each streaming microprocessor may include a level one ("L1") cache (e.g., an L1 cache with a memory capacity of at least 96 KB), and two or more streaming microprocessors may share an L2 cache (e.g., an L2 cache with a memory capacity of 512 KB). In some embodiments, the GPU(s) 1208 may include at least eight streaming microprocessors. The GPU(s) 1208 may use computer-based application programming interface(s) (API(s)). Additionally, the GPU(s) 1208 may utilize one or more parallel computing platforms and/or programming models (e.g., NVIDIA's CUDA).

The GPU(s) 1208 may be power optimized for the best computing performance in automotive and embedded use cases. For example, the GPU(s) 1208 may be fabricated on a Fin Field Effect Transistor (FinFET). However, this is not intended to be limiting and the GPU(s) 1208 may be fabricated using other semiconductor fabrication processes. Each streaming microprocessor may include a number of mixed precision processing cores partitioned into multiple blocks. For example, and without limitation, 64 PF32 cores and 32 PF64 cores may be partitioned into four processing blocks. In such an example, each processing block may include 16 FP32 cores, 8 FP64 cores, 16 INT32 cores, two mixed precision NVIDIA TENSOR COREs for deep learning matrix processing, and 16 FP64 cores. xarithmetic, an L0 instruction cache, a warp scheduler, a distribution unit, and/or a 64 KB register file. In addition, streaming microprocessors may include independent parallel integer and floating-point data paths to enable efficient execution of workloads with a mix of computation and addressing calculations. The streaming microprocessors may include an independent thread scheduling function to enable finer-grained synchronization and cooperation between parallel threads. The streaming microprocessors may include a unit of combined L1 data cache and shared memory to improve performance while simplifying programming.

The GPU(s) 1208 may include high bandwidth memory (HBM) and/or a 16 GB HBM2 memory subsystem to provide a peak memory bandwidth of about 900 GB/second in some examples. In some examples, in addition to or alternatively to the HBM memory, a synchronous graphics random-access memory (SGRAM) may be used, such as a graphics double data rate type five (GDDR5) synchronous random-access memory.

The GPU(s) 1208 may include a unified memory technology with access counters that allows for more accurate allocation of memory pages to the processor that accesses them most frequently, thus improving the efficiency of memory regions shared by multiple processors. In some examples, address translation services (ATS) support may be used to allow the GPU(s) 1208 to directly access the page tables of the CPU(s) 1206. In such examples, when the GPU(s) 1208 memory management unit (MMU) fails, an address translation request may be transmitted to the CPU(s) 1206. In response, the CPU(s) 1206 may look in their page tables for a virtual-to-physical mapping for the address and transmit the translation back to the GPU(s) 1208. Therefore, the unified memory technology may enable a single unified virtual address space for the memory of both the CPU(s) 1206 and the GPU(s) 1208, thereby simplifying programming of the GPU(s) 1208 and porting applications to the GPU(s) 1208.

Additionally, the GPU(s) 1208 may include an access counter that tracks the frequency of the GPU(s) 1208 accessing the memory of other processors. The access counter may help move memory pages into the physical memory of the processor that accesses the pages most frequently.

The SoC(s) 1204 may include any number of cache(s) 1212, including those described herein. For example, the cache(s) 1212 may include an L3 cache that is available to both the CPU(s) 1206 and the GPU(s) 1208 (e.g., connected to both the CPU(s) 1206 and the GPU(s) 1208). The cache(s) 1212 may include a write-back cache that may track the states of lines, such as through the use of a cache coherence protocol (e.g., MEI, MESI, MSI, etc.). The L3 cache may include 4 MB or more, depending on the embodiment, although smaller cache sizes may also be used.

The SoC(s) 1204 may include an arithmetic logic unit(s) (ALU(s)) that may be utilized in performing methods related to any of the many tasks or operations of the vehicle 1200, such as processing DNNs. Additionally, the SoC(s) 1204 may include one or more floating point units (FPU(s))—or other mathematical coprocessors or numerical coprocessors—for performing mathematical operations within the system. For example, the SoC(s) 1204 may include one or more FPUs integrated as execution units within a CPU(s) 1206 and/or GPU(s) 1208.

The SoC(s) 1204 may include one or more accelerators 1214 (e.g., hardware accelerators, software accelerators, or a combination thereof). For example, the SoC(s) 1204 may include a hardware acceleration cluster, which may include optimized hardware accelerators and/or a large on-chip memory. The large on-chip memory (e.g., 4 MB of SRAM) may enable a hardware acceleration cluster to accelerate neural networks and other computations. The hardware acceleration cluster may be used to supplement the GPU(s) 1208 and offload some tasks of the GPU(s) 1208 (e.g., free up more cycles of the GPU(s) 1208 to perform other tasks). As an example, the accelerator(s) 1214 may be used for targeted workloads (e.g., perception, convolutional neural networks (CNNs), etc.) that are stable enough to be suitable for acceleration. The term "CNN" as used herein can include all types of CNNs, including region-based or regional convolutional neural networks (RCNNs) and fast RCNNs (e.g. for object detection).

The accelerator(s) 1214 (e.g., hardware acceleration clusters) may include deep learning accelerator(s) (DLA(s). The DLA(s) may include one or more tensor processing units (TPUs), which may be configured to provide an additional tens of trillion operations per second for deep learning applications and inferencing. The TPUs may be accelerators configured and optimized to perform image processing functions (e.g., for CNNs, RCNNs, etc.). The DLA(s) may be further optimized for a specific set of types of neural networks and floating point operations, as well as for inference. The design of the DLA(s) may provide more performance per millimeter than a typical general purpose GPU, far exceeding the performance of a CPU. The TPU(s) may perform multiple functions, including a single instance convolution function, for example, to perform a single instance convolution function. B. INT8, INT16 and FP16 data types are supported for both features and weights, as well as post-processor functions.

The DLA(s) may quickly and efficiently execute neural networks, particularly CNNs, on processed or unprocessed data for any of a variety of functions, including, for example and without limitation: a CNN for object identification and recognition using data from camera sensors; a CNN for distance estimation using data from camera sensors; a CNN for emergency vehicle detection and identification and recognition using data from microphones; a CNN for facial recognition and vehicle owner identification using data from camera sensors; and/or a CNN for safety and/or security-related events.

The DLA(s) may perform any function of the GPU(s) 1208, and by using an inference accelerator, for example, a designer may target either the DLA(s) or GPU(s) 1208 for any function. For example, the designer may focus the processing of CNNs and floating point operations on the DLA(s) and leave other functions to the GPU(s) 1208 and/or other accelerators 1214.

The accelerator(s) 1214 (e.g., the hardware acceleration cluster) may include a programmable vision accelerator (“PVA”), which may alternatively be referred to herein as a machine vision accelerator. The PVA(s) may be designed and configured to accelerate machine vision algorithms for advanced driver assistance systems (ADAS), autonomous driving, augmented reality (AR), and/or virtual reality (VR) applications. The PVA(s) may provide a balance between performance and flexibility. For example, and without limitation, all PVA(s) may include any number of reduced instruction set computer (RISC) cores, direct memory access (DMA), and/or any number of vector processors.

RISC cores may interact with image sensors (e.g., the image sensors of any of the cameras described herein), image signal processor(s), and/or the like. Each of the RISC cores may include any amount of memory. The RISC cores may use any of a number of protocols, depending on the embodiment. In some examples, the RISC cores may execute a real-time operating system (RTOS). The RISC cores may be implemented using one or more integrated circuit devices, application specific integrated circuits (ASICs), and/or memory devices. For example, the RISC cores may include an instruction cache and/or tightly coupled RAM.

The DMA may enable components of the PVA(s) to access system memory independently of the CPU(s) 1206. The DMA may support any number of features used to provide optimization of the PVA, including, but not limited to, support for multi-dimensional addressing and/or circular addressing. In some examples, the DMA may support up to six or more dimensions of addressing, which may include block width, block height, block depth, horizontal block gradation, vertical block gradation, and/or depth gradation.

The vector processors may be programmable processors that may be configured to efficiently and flexibly execute programming for computer vision algorithms and provide signal processing capabilities. In some examples, the PVA may include a PVA core and two Vector processing subsystem partitions. The PVA core may include a processor subsystem, DMA engine(s) (e.g., two DMA engines), and/or other peripherals. The vector processing subsystem may operate as the primary processing engine of the PVA and may include a vector processing unit (VPU), an instruction cache, and/or a vector memory (e.g., VMEM). A VPU core may include a digital signal processor, such as a single-instruction-multiple-data (SIMD)-very-long-instruction-word (VLIW) digital signal processor. The combination of SIMD and VLIW may increase throughput and speed.

Each of the vector processors may include an instruction cache and be coupled to dedicated memory. Therefore, in some examples, each of the vector processors may be configured to execute independently of the other vector processors. In other examples, vector processors included in a particular PVA may be configured to employ data parallelism. For example, in some embodiments, the plurality of vector processors included in a single PVA may execute the same computer vision algorithm, but on different regions of an image. In other examples, the vector processors included in a particular PVA may simultaneously execute different computer vision algorithms on the same image, or even execute different algorithms on sequential images or portions of an image. Among other things, any number of PVAs may be included in the hardware acceleration cluster, and any number of vector processors may be included in each of the PVAs. In addition, the PVA(s) may include additional error correction code (ECC) memory to increase overall system security.

The accelerator(s) 1214 (e.g., a hardware acceleration cluster) may include an on-chip computer vision network and SRAM to provide high-bandwidth, low-latency SRAM to the accelerator(s) 1214. In some examples, the on-chip memory may include at least 4 MB of SRAM, consisting of, for example and without limitation, eight field-configurable memory blocks accessible by both the PVA and the DLA. Each pair of memory blocks may include an advanced peripheral bus (APB) interface, configuration circuitry, a controller, and a multiplexer. Any type of memory may be used. The PVA and DLA may access the memory via a backbone that provides the PVA and DLA with high-speed access to the memory. The backbone may include an on-chip computer vision network that connects the PVA and DLA to the memory (e.g., using the APB).

The on-chip machine vision network may include an interface that determines that both a PVA and a DLA are providing ready and valid signals before transmitting any control signal/address/data. Such an interface may provide separate phases and separate channels for transmitting control signals/addresses/data, as well as burst-type communication for continuous data transmission. This type of interface may conform to ISO 26262 or IEC 61508 standards, although other standards and protocols may be used.

In some examples, the SoC(s) 1204 may include a real-time ray tracing hardware accelerator as described in the US Patent Application No. 16/101,232 , filed August 10, 2018. The real-time ray tracing hardware accelerator may be used to quickly and efficiently determine the positions and extents of objects (e.g., within a world model), to generate real-time visualization simulations, for RADAR signal interpretation, for sound propagation synthesis and/or analysis, for simulation of SONAR systems, for general wave propagation simulation, for comparison with LIDAR data for localization purposes and/or for other functions, and/or for other applications. In some embodiments, one or more tree traversal units (TTUs) may be used to perform one or more ray tracing-related operations.

The accelerator(s) 1214 (e.g., the hardware accelerator cluster) have a wide range of uses for autonomous driving. The PVA can be a programmable vision accelerator that can be used for important processing stages in ADAS and autonomous vehicles. The capabilities of the PVA are a good complement for algorithmic domains that require predictable processing at low power and low latency. In other words, the PVA shows good performance for semi-dense or dense regular computations, even on small data sets that require predictable runtimes with low latency and low power. Consequently, the PVAs in combination are In conjunction with autonomous vehicle platforms, the system is designed to run classical machine vision algorithms because they are efficient at object recognition and use integer mathematics.

For example, according to one embodiment of the technology, the PVA is used to perform stereo machine vision. A semi-global matching based algorithm may be used, although this is not to be construed as a limitation. Many Level 3-5 autonomous driving applications require motion estimation/stereo matching on the fly (e.g., structure from motion, pedestrian detection, lane detection, etc.). The PVA can perform a stereo machine vision function on inputs from two monocular cameras.

In some examples, the PVA may be used to perform dense optical flow. For example, the PVA may be used to process raw RADAR data (e.g., using a 4D Fast Fourier Transform) to provide a processed RADAR signal before the next RADAR pulse is transmitted. In other examples, the PVA is used for time-of-flight deep processing, e.g., by processing raw time-of-flight data to provide processed time-of-flight data.

The DLA can be used to run any type of network to improve control and driving safety, including, for example, a neural network that outputs a level of confidence for each object detection. Such a confidence value can be interpreted as a probability, or as providing a relative “weight” of each detection compared to other detections. The confidence value allows the system to make further decisions about which detections should be considered true positive detections rather than false positive detections. For example, the system can set a threshold for confidence and only consider detections that exceed the threshold as true positive detections. In an automatic emergency braking (AEB) system, false positive detections would cause the vehicle to automatically perform emergency braking, which is of course undesirable. Therefore, only the most certain detections should be considered as triggers for AEB. The DLA can run a neural network to regress the confidence value. The neural network may use as input at least a subset of parameters, such as the dimensions of the bounding box, the ground plane estimate obtained (e.g., from another subsystem), the output of the IMU sensor 1266 correlated with the orientation of the vehicle 1200, the range, the estimate of the 3D position of the task obtained from the neural network and/or other sensors (e.g., LIDAR sensor(s) 1264 or RADAR sensor(s) 1260), and others.

The SoC(s) 1204 may include storage 1216 (e.g., memory). The storage 1216 may be on-chip memory of the SoC(s) 1204 that may store neural networks to be executed on the GPU and/or DLA. In some examples, the capacity of the storage 1216 may be large enough to store multiple instances of neural networks for redundancy and security. The storage 1216 may include L2 or L3 cache(s) 1212. The reference to the storage 1216 may include a reference to the memory associated with the PVA, DLA, and/or other accelerators 1214, as described herein.

The SoC(s) 1204 may include one or more processor(s) 1210 (e.g., embedded processors). The processor(s) 1210 may include a booting and power management processor, which may be a dedicated processor and subsystem to handle the booting power and management functions and associated security enforcement. The booting and power management processor may be part of the booting sequence of the SoC(s) 1204 and provide runtime power management services. The booting power and management processor may provide clock and voltage programming, assisting with system transitions to a low power state, managing thermal and temperature sensors of the SoC(s) 1204, and/or managing power states of the SoC(s) 1204. Each temperature sensor may be implemented as a ring oscillator whose output frequency is proportional to temperature, and the SoC(s) 1204 may use ring oscillators to detect temperatures of CPU(s) 1206, GPU(s) 1208, and/or accelerator(s) 1214. If temperatures are determined to exceed a threshold, the booting and power management processor may then enter a temperature fault routine and place the SoC(s) 1204 into a lower power state and/or place the vehicle 1200 into a drive to safe stop mode (e.g., bring the vehicle 1200 to a safe stop).

The processor(s) 1210 may further include a set of embedded processors that may serve as an audio processing engine. The audio processing engine may be an audio subsystem that enables full hardware support for multi-channel audio over multiple interfaces, as well as a wide and flexible range of audio I/O interfaces. In some examples, the audio processing engine is a dedicated processor core with a digital signal processor with dedicated RAM.

The processor(s) 1210 may further include an always-on processor engine that may provide necessary hardware features to support low power sensor management and wake-up use cases. The always-on processor engine may include a processor core, tightly coupled RAM, supporting peripherals (e.g., timers and interrupt controllers), various I/O control peripherals, and routing logic.

The processor(s) 1210 may further include a security cluster engine that includes a dedicated processor subsystem for handling security management for automotive applications. The security cluster engine may include two or more processor cores, tightly coupled RAM, supporting peripherals (e.g., timers, an interrupt controller, etc.), and/or routing logic. In a security mode, the two or more cores may operate in a lockstep mode and function as a single core with comparison logic to detect any differences between their operations.

The processor(s) 1210 may further include a real-time camera engine, which may include a dedicated processor subsystem for handling real-time camera management.

The processor(s) 1210 may also include a high dynamic range signal processor that includes an image signal processor that is part of the camera processing pipeline as a hardware engine.

The processor(s) 1210 may include a video image compositor, which may be a processing block (e.g., implemented on a microprocessor) that implements video post-processing functions required by a video playback application to generate the final image for the player window. The video image compositor may perform lens distortion correction on the wide view camera(s) 1270, surround camera(s) 1274, and/or in-cab surveillance camera sensors. An in-cab surveillance camera sensor is preferably monitored by a neural network running on another instance of the advanced SoC and configured to detect and respond to events in the cabin. An in-cab system may perform lip reading to activate cellular service and make a call, dictate emails, change the vehicle's destination, activate or change the vehicle's infotainment system and its settings, or provide voice-activated web browsing. Certain functions are only available to the driver when the vehicle is operating in autonomous mode and are otherwise deactivated.

The video image compositor may include advanced temporal noise reduction for both spatial and temporal noise reduction. For example, when motion is present in a video, the noise reduction weights the spatial information accordingly by reducing the weight of the information provided by neighboring frames. When a frame or portion of a frame does not include motion, the temporal noise reduction performed by the video image compositor may use information from the previous frame to suppress noise in a current frame.

The video image compositor may also be configured to perform stereo de-warping on the input stereo lens frames. The video image compositor may further be used for user interface composition when the operating system desktop is in use and the GPU(s) 1208 are not needed to continuously render new surfaces. Even when the GPU(s) 1208 are on and actively performing 3D rendering, the video image compositor may be used to offload the GPU(s) 1208, thereby improving performance and responsiveness.

The SoC(s) 1204 may further include a serial Mobile Industry Processor Interface (MIPI) camera interface for receiving video and input from cameras, a high-speed interface position and/or a video input block that can be used for camera and associated pixel input functions. The SoC(s) 1204 can further include input/output controller(s) that can be controlled by software and can be used to receive I/O signals that are not assigned to a specific role.

The SoC 1204 may further include a wide range of peripheral interfaces to enable communication with peripherals, audio codecs, power management, and/or other devices. The SoC(s) 1204 may be used to process data from cameras (e.g., connected via Gigabit Multimedia Serial Link and Ethernet), sensors (e.g., LIDAR sensor(s) 1264, RADAR sensor(s) 1260, etc., which may be connected via Ethernet), data from bus 1202 (e.g., speed of vehicle 1200, steering wheel position, etc.), data from GNSS sensor(s) 1258 (e.g., connected via Ethernet or CAN bus). The SoC(s) 1204 may further include dedicated high performance mass storage controllers, which may include their own DMA engines and which may be used to free the CPU(s) 1206 from routine data management tasks.

The SoC(s) 1204 may be an end-to-end platform with a flexible architecture spanning automation levels 3-5, thereby providing a comprehensive functional safety architecture, leveraging and efficiently deploying machine vision and ADAS techniques for diversity and redundancy, and providing a platform for a flexible, reliable driving software stack along with deep learning tools. The SoC(s) 1204 may be faster, more reliable, and even more power and space efficient than traditional systems. For example, the accelerator(s) 1214, when combined with the CPU(s) 1206, GPU(s) 1208, and data storage(s) 1216, may provide a fast, efficient platform for Level 3-5 autonomous vehicles.

The technology thus provides capabilities and functions that cannot be achieved with conventional systems. For example, machine vision algorithms can be executed on CPUs that can be configured using a high-level programming language, such as the C programming language, to perform a wide variety of processing algorithms on a wide variety of visual data. However, the CPUs are often unable to meet the performance requirements of many machine vision applications, such as execution time and power consumption. In particular, many CPUs are unable to execute complex real-time object detection algorithms required in in-vehicle ADAS applications and in practical Level 3-5 autonomous vehicles.

Unlike traditional systems, by providing a CPU complex, a GPU complex, and a hardware acceleration cluster, the technology described here enables the simultaneous and/or sequential execution of multiple neural networks and the combination of the results to enable Level 3-5 autonomous driving capabilities. For example, a CNN running on the DLA or dGPU (e.g., the GPU 1220) may include text and word recognition that allows the supercomputer to read and understand traffic signs, including signs for which the neural network was not specifically trained. The DLA may further include a neural network capable of identifying, interpreting, and providing a semantic understanding of the sign and passing this semantic understanding to path planning modules running on the CPU complex.

As another example, multiple neural networks may be executed simultaneously, as required for driving at Levels 3, 4, or 5. For example, a warning sign reading "Caution: Flashing lights indicate icing" along with an electric light may be interpreted by multiple neural networks independently or jointly. The warning sign itself may be identified as a traffic sign by a first deployed neural network (e.g., a neural network that has been trained), and text "Flashing lights indicate icing" may be interpreted by a second deployed neural network, informing vehicle path planning software (preferably running on the CPU complex) that if flashing lights are detected, icing is present. The flashing light may be identified by running a third deployed neural network over multiple frames, informing the vehicle path planning software of the presence (or absence) of flashing lights. All three neural networks can run simultaneously, such as within the DLA and/or on the GPU(s) 1208.

In some examples, a CNN for facial recognition and vehicle owner identification may use data from camera sensors to detect the presence of an authorized driver and/or owner. cers of the vehicle 1200. The always-on sensor processing engine can be used to unlock the vehicle when the owner approaches the driver's door and turns on the lights, and to disable the vehicle in security mode when the owner exits the vehicle. In this way, the SoC(s) 1204 provide security against theft and/or carjacking.

In another example, a CNN for emergency vehicle detection and identification may use data from microphones 1296 to detect and identify emergency vehicle sirens. Unlike conventional systems that use general classifiers to detect sirens and manually extract features, the SoC(s) 1204 use the CNN for environmental and urban noise classification, as well as visual data classification. In a preferred embodiment, the CNN running on the DLA is trained to identify the relative approach speed of the emergency vehicle (e.g., by using the Doppler effect). The CNN may also be trained to identify emergency vehicles specific to the local area in which the vehicle is operating, as identified by the GNSS sensor(s) 1258. Thus, for example, when operating in Europe, the CNN will attempt to detect European sirens, and in the United States, the CNN will attempt to identify only North American sirens. Once an emergency vehicle is detected, a control program may be used to execute an emergency vehicle safety routine, slow the vehicle, pull over to the side of the road, park the vehicle, and/or idle the vehicle using the ultrasonic sensors 1262 until the emergency vehicle(s) passes.

The vehicle may include CPU(s) 1218 (e.g., discrete CPU(s) or dCPU(s)) that may be coupled to the SoC(s) 1204 via a high-speed interconnect (e.g., PCIe). The CPU(s) 1218 may include, for example, an X86 processor. The CPU(s) 1218 may be used to perform a variety of functions, including, for example, arbitrating potentially inconsistent results between ADAS sensors and the SoC(s) 1204 and/or monitoring the status and condition of the controller(s) 1236 and/or the infotainment SoC 1230.

The vehicle 1200 may include GPU(s) 1220 (e.g., discrete GPU(s) or dGPU(s)) that may be coupled to the SoC(s) 1204 via a high-speed interconnect (e.g., NVIDIA's NVLINK). The GPU(s) 1220 may provide additional functionality for artificial intelligence, such as by running redundant and/or different neural networks, and may be used to train and/or update neural networks based on inputs (e.g., sensor data) from sensors of the vehicle 1200.

The vehicle 1200 may further include the network interface 1224, which may include wireless antenna(s) 1226 (e.g., one or more wireless antennas for different communication protocols, such as a cellular antenna, a Bluetooth antenna, etc.). The network interface 1224 may be used to enable wireless connections over the Internet to the cloud (e.g., to the server 1278 and/or other network devices), to other vehicles, and/or to computing devices (e.g., passenger client devices). To communicate with other vehicles, a direct link may be established between the two vehicles and/or an indirect link may be established (e.g., over networks and over the Internet). Direct links may be established using a vehicle-to-vehicle communication link. A vehicle-to-vehicle communication link may provide the vehicle 1200 with information about vehicles in the vicinity of the vehicle 1200 (e.g., vehicles in front of, beside, and/or behind the vehicle 1200). This functionality may be part of a cooperative adaptive cruise control functionality of the vehicle 1200.

The network interface 1224 may include a SoC that provides modulation and demodulation functionality and enables the controllers 1236 to communicate over wireless networks. The network interface 1224 may include a radio frequency front end for upconversion from baseband to radio frequency and downconversion from radio frequency to baseband. The frequency conversions may be performed by well-known processes and/or using overlay techniques. In some examples, the radio frequency front end functionality may be provided by a separate chip. The network interface may include wireless functionality for communication over LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN, and/or other wireless protocols.

The vehicle 1200 may also include data storage(s) 1228, which may also include off-chip storage (e.g., outside of the SoC(s) 1204). The data storage(s) 1228 may include one or more memory elements, including RAM, SRAM, DRAM, VRAM, flash, hard drives, and/or other components and/or devices capable of storing at least one bit of data.

The vehicle 1200 may further include GNSS sensor(s) 1258 (e.g., GPS and/or assisted GPS sensors) to assist with mapping, sensing, occupancy grid generation, and/or path planning functions. Any number of GNSS sensor(s) 1258 may be used, including, for example and without limitation, a GPS using a USB connector with an Ethernet to serial bridge (e.g., RS-232 bridge).

The vehicle 1200 may further include RADAR sensor(s) 1260. The RADAR sensor(s) 1260 may be used by the vehicle 1200 to remotely detect vehicles, even in darkness and/or poor weather conditions. The RADAR functional safety levels may be ASIL B. The RADAR sensor(s) 1260 may use CAN and/or bus 1202 (e.g., to transmit data generated by the RADAR sensor(s) 1260) to control and access object tracking data, with raw data being accessed over Ethernet in some examples. A wide variety of RADAR sensor types may be used. For example, and without limitation, the RADAR sensor(s) 1260 may be suitable for use as front, rear, and side RADAR. In some examples, pulse-Doppler RADAR sensors are used.

The RADAR sensor(s) 1260 may include different configurations, e.g., long range with narrow field of view, short range with wide field of view, short side coverage, etc. In some examples, a long range RADAR may be used for adaptive cruise control. The long range RADAR systems may provide a wide field of view realized by two or more independent scans, e.g., within a range of 250 m. The RADAR sensor(s) 1260 may help distinguish between static and moving objects and may be used by ADAS systems for emergency braking assist and forward collision warning. Long range RADAR sensors may include a monostatic multi-modal RADAR with multiple (e.g., six or more) fixed RADAR antennas and a high-speed CAN and FlexRay interface. In a six-antenna example, the middle four antennas can create a focused bar pattern designed to detect the surroundings of the vehicle 1200 at higher speeds with minimal interference from traffic in adjacent lanes. The other two antennas can expand the field of view, making it possible to quickly detect vehicles entering or exiting the lane of the vehicle 1200.

For example, medium-range RADAR systems can include a range of up to 1260 m (front) or 80 m (rear) and a field of view of up to 42 degrees (front) or 1250 degrees (rear). Short-range RADAR systems can include, without limitation, RADAR sensors designed to be installed at both ends of the rear bumper. When installed at both ends of the rear bumper, the RADAR sensor system can create two beams that constantly monitor the blind spot behind and to the side of the vehicle.

Short-range RADAR systems can be used in an ADAS system for blind spot detection and/or lane change assistance.

The vehicle 1200 may further include one or more ultrasonic sensors 1262. The ultrasonic sensor(s) 1262, which may be positioned at the front, rear, and/or sides of the vehicle 1200, may be used as a parking aid and/or to create and update an occupancy grid. A wide variety of ultrasonic sensor(s) 1262 may be used, and different ultrasonic sensor(s) 1262 may be used for different detection ranges (e.g., 2.5 m, 4 m). The ultrasonic sensor(s) 1262 may operate at functional safety levels of ASIL B.

The vehicle 1200 may include LIDAR sensor(s) 1264. The LIDAR sensor(s) 1264 may be used for object and pedestrian detection, emergency braking, collision avoidance, and/or other functions. The LIDAR sensor(s) 1264 may meet functional safety level ASIL B. In some examples, the vehicle 1200 may include multiple LIDAR sensors 1264 (e.g., two, four, six, etc.) that may use Ethernet (e.g., to provide data to a Gigabit Ethernet switch).

In some examples, the LIDAR sensor(s) 1264 may be capable of providing a list of objects and their distances for a 360 degree field of view. For example, commercially available LIDAR sensor(s) 1264 may have an advertised range of approximately 100 m, with an accuracy of 2 cm-3 cm, and support for a 100 Mbps Ethernet connection. In some examples, one or more non-protruding LIDAR sensors 1264 may be used. In such examples, the LIDAR sensor(s) 1264 may be implemented as a small device that may be embedded in the front, rear, sides, and/or corners of the vehicle 1200. The LIDAR sensor(s) 1264 in such examples may provide a horizontal field of view of up to 120 degrees and a vertical field of view of up to 35 degrees with a range of 200 m even for low reflectivity objects. Front-mounted LIDAR sensors 1264 may be configured for a horizontal field of view between 45 degrees and 135 degrees.

In some examples, LIDAR technologies such as 3D flash LIDAR may also be used. 3D flash LIDAR uses a laser flash as a transmitting source to illuminate the surroundings of the vehicle up to a distance of approximately 200 m. A flash LIDAR unit includes a receptor that records the laser pulse time of flight and reflected light at each pixel, which in turn corresponds to the range from the vehicle to the objects. Flash LIDAR can enable highly accurate and distortion-free images of the surroundings to be generated with each laser flash. In some examples, four flash LIDAR sensors can be deployed, one on each side of the vehicle 1200. Available 3D flash LIDAR systems include a solid-state 3D staring array LIDAR camera with no moving parts other than a fan (e.g., a non-scanning LIDAR device). The flash lidar device(s) can use a five nanosecond Class I (eye-safe) laser pulse per image and can collect the reflected laser light as 3D range point clouds and co-registered intensity data. By using flash lidar and because flash lidar is a solid-state device with no moving parts, the lidar sensor(s) 1264 are less susceptible to motion blur, vibration, and/or shock.

The vehicle may further include IMU sensor(s) 1266. The IMU sensor(s) 1266 may be located in the center of the rear axle of the vehicle 1200 in some examples. The IMU sensor(s) 1266 may include, for example and without limitation, accelerometer(s), magnetometer(s), gyroscope(s), magnetic compass(s), and/or other types of sensors. In some examples, such as in six-axis applications, the IMU sensor(s) 1266 may include accelerometers and gyroscopes, while in nine-axis applications, the IMU sensor(s) 1266 may include accelerometers, gyroscopes, and magnetometers.

In some embodiments, the IMU sensor(s) 1266 may be implemented as a miniaturized, high-performance GPS-Aided Inertial Navigation System (GPS/INS) that combines micro-electro-mechanical systems (MEMS) inertial sensors, a highly sensitive GPS receiver, and advanced Kalman filter algorithms to provide estimates of position, velocity, and attitude. Thus, in such examples, the IMU sensor(s) 1266 may enable the vehicle 1200 to estimate heading without requiring inputs from a magnetic sensor by directly observing and correlating changes in velocity from the GPS to the IMU sensor(s) 1266. In some examples, the IMU sensor(s) 1266 and GNSS sensor(s) 1258 may be combined in a single integrated unit.

The vehicle may include one or more microphones 1296 mounted in and/or around the vehicle 1200. The microphone(s) 1296 may be used, among other things, to detect and identify emergency vehicles.

The vehicle may further include any number of camera types, including stereo camera(s) 1268, wide view camera(s) 1270, infrared camera(s) 1272, surround camera(s) 1274, long range and/or medium range camera(s) 1298, and/or other camera types. The cameras may be used to capture image data around the entire periphery of the vehicle 1200. The type of cameras used depends on the embodiments and requirements for the vehicle 1200, and any combination of camera types may be used to provide the required coverage around the vehicle 1200. Additionally, the number of cameras may vary depending on the embodiment. For example, the vehicle may include six cameras, seven cameras, ten cameras, twelve cameras, and/or another number of cameras. The cameras may for example and without limitation support Gigabit Multimedia Serial Link (GMSL) and/or Gigabit Ethernet. Each of the cameras is described here with reference to 12 and 13 described in more detail.

The vehicle 1200 may further include vibration sensor(s) 1242. The vibration sensor(s) 1242 may measure vibrations of components of the vehicle, such as the axle(s). For example, changes in vibrations may indicate a change in the road surface. In another example, when two or more vibration sensors 1242 are used, the differences between the vibrations may be used to determine the friction or slip of the road surface (e.g., when the difference in vibration is between a powered axle and a freely rotating axle).

The vehicle 1200 may include an ADAS system 1238. The ADAS system 1238 may include a SoC in some examples. The ADAS system 1238 may include autonomous/adaptive/automatic cruise control (ACC), cooperative adaptive cruise control (CACC), forward crash warning (FCW), automatic emergency braking (AEB), lane departure warning (LDW), lane keep assist (LKA), blind spot warning (BSW), rear cross-traffic warning (RCTW), collision warning (CWS) systems, lane centering (LC), and/or other systems, features, and/or functions.

The ACC systems may use RADAR sensor(s) 1260, LIDAR sensor(s) 1264, and/or camera(s). The ACC systems may include longitudinal ACC and/or lateral ACC. Longitudinal ACC controls and monitors the distance to another vehicle immediately ahead of vehicle 1200, and automatically adjusts the speed of the vehicle to maintain a safe distance from vehicles ahead. Lateral ACC performs distance keeping and advises vehicle 1200 to change lanes when necessary. Lateral ACC is interfaced with other ADAS applications such as LC and CWS.

The CACC utilizes information from other vehicles that may be received via the network interface 1224 and/or the wireless antenna(s) 1226 from other vehicles over a wireless link or indirectly over a network connection (e.g., over the Internet). Direct links may be provided through a vehicle-to-vehicle (V2V) communication link, while indirect links may be provided through an infrastructure-to-vehicle (I2V) communication link. In general, the V2V communication concept provides information about immediately preceding vehicles (e.g., vehicles immediately ahead of and in the same lane as the vehicle 1200), while the I2V communication concept provides information about more distantly preceding traffic. CACC systems may include either or both of 12V and V2V information sources. Given the information about the vehicles ahead of vehicle 1200, CACC can be more reliable and has the potential to improve traffic flow uniformity and reduce congestion on the road.

FCW systems are designed to warn the driver of a hazard so that the driver can take corrective action. FCW systems use a forward-facing camera and/or RADAR sensor(s) 1260 coupled to a dedicated processor, DSP, FPGA and/or ASIC that is electrically coupled to driver feedback, such as a display, speaker and/or vibrating component. FCW systems may provide a warning, such as a sound, a visual warning, a vibration and/or a rapid braking pulse.

AEB systems detect an impending collision with another vehicle or other object and may automatically apply the brakes if the driver does not take corrective action within a certain time or distance parameter. AEB systems may utilize forward-facing camera(s) and/or RADAR sensor(s) 1260 coupled to a dedicated processor, DSP, FPGA, and/or ASIC. When the AEB system detects a hazard, it typically first alerts the driver to take corrective action to avoid a collision, and, if the driver does not take corrective action, the AEB system may automatically apply the brakes in an effort to prevent or at least mitigate the effects of the predicted collision. AEB systems may include techniques such as dynamic brake assist and/or impending collision braking.

LDW systems provide visual, audible and/or tactile warnings, such as steering wheel or seat vibrations, to alert the driver when the vehicle 1200 crosses lane markings. An LDW system will not activate if the driver indicates an intentional lane departure by activating the turn signal. LDW systems may use forward-facing cameras coupled to a dedicated processor, DSP, FPGA and/or ASIC that are electrically coupled to driver feedback, such as a display, speaker and/or vibrating component.

LKA systems are a variation of LDW systems. LKA systems provide steering input or braking to correct the vehicle 1200 when the vehicle 1200 begins to depart from the lane.

BSW systems detect and warn a driver of vehicles in a blind spot of an automobile. BSW systems may provide a visual, audible, and/or tactile alarm to indicate that merging or changing lanes is unsafe. The system may provide an additional warning when the driver activates a turn signal. BSW systems may utilize rear and side facing camera(s) and/or RADAR sensor(s) 1260 coupled to a dedicated processor, DSP, FPGA, and/or ASIC, that is, electrically coupled to a driver feedback such as a display, speaker, and/or vibrating component.

RCTW systems may provide visual, audible and/or tactile notifications when an object is detected outside the range of the rear view camera when the vehicle 1200 is reversing. Some RCTW systems include the AEB system to ensure that the vehicle brakes are applied to avoid a collision. RCTW systems may use one or more rear-facing RADAR sensors 1260 coupled with a dedicated processor, DSP, FPGA and/or ASIC that is electrically coupled to driver feedback, such as a display, speaker and/or vibrating component.

Conventional ADAS systems can be prone to false positives, which can be annoying and distracting to the driver, but are typically not catastrophic because the ADAS systems alert a driver and allow that driver to decide whether a safety condition really exists and act accordingly. However, in an autonomous vehicle 1200, when conflicting results occur, the vehicle 1200 must decide for itself whether to heed the result of a primary computer or a secondary computer (e.g., a first controller 1236 or a second controller 1236). For example, in some embodiments, the ADAS system 1238 may be a backup and/or secondary computer that provides perception information to a rationality module of a backup computer. The rationality monitor of the backup computer may execute redundant, diverse software on hardware components to detect errors in perception and dynamic driving tasks. Outputs from the ADAS system 1238 can be provided to a supervisory MCU. If the outputs of the primary and secondary computers conflict, the supervisory MCU must determine how to resolve the conflict to ensure safe operation.

In some examples, the primary computer may be configured to provide the monitoring MCU with a confidence score indicating a confidence of the primary computer for the chosen outcome. If the confidence score exceeds a threshold, that monitoring MCU may follow the lead of the primary computer regardless of whether that secondary computer provides a conflicting or inconsistent result. If the confidence score does not meet the threshold and the primary and secondary computers indicate different results (e.g., the contradiction), the monitoring MCU may arbitrate between the computers to determine the appropriate outcome.

The control MCU may be configured to execute neural network(s) that are trained and configured to determine, based on the outputs of the primary computer and the secondary computer, the conditions under which the secondary computer provides false alarms. Consequently, the neural network(s) in the control MCU may learn when the output of the secondary computer can be trusted and when it cannot. For example, if the secondary computer is a RADAR-based FCW system, neural network(s) in the control MCU may learn when the FCW system identifies metallic objects that are not actually hazards, such as a drain grate or manhole cover, which triggers an alarm. If the secondary computer is a camera-based LDW system, a neural network in the monitoring MCU can similarly learn to override the LDW when cyclists or pedestrians are present and lane departure is indeed the safest maneuver. In embodiments that include one or more neural networks running on the control MCU, the control MCU can include at least one DLA or GPU suitable for executing the neural network(s) with associated memory. In preferred embodiments, the monitoring MCU can be included and/or incorporated as part of the SoC(s) 1204.

In other examples, the ADAS system 1238 may include a secondary computer that performs the ADAS functionality using traditional machine vision rules. Thus, the secondary computer may use classic machine vision rules (if-then), and the presence of neural network(s) in the monitoring MCU may improve reliability, safety, and performance. For example, implementation diversity and intentional non-identity make an overall system more fault-tolerant, particularly to errors caused by the functionality of software (or software-hardware interfaces). For example, if there is a software bug or error in the software running on the primary computer, and non-identical software code running on the secondary computer provides the same overall result, then the control MCU may have greater confidence that the overall result is correct and the bug in the software or hardware on the primary computer does not cause a significant error.

In some examples, the output of the ADAS system 1238 may be fed into a perception block of the primary computer and/or a dynamic driving task block of the primary computer. For example, if the ADAS system 1238 indicates a forward collision warning due to an object immediately ahead, the perception block may use this information in identifying objects. In other examples, the secondary computer may have its own neural network that is trained, thus reducing the risk of false positives, as described herein.

The vehicle 1200 may further include the infotainment SoC 1230 (e.g., an in-vehicle infotainment system (IVI system)). Although illustrated and described as a SoC, the infotainment system may not be a SoC and may include two or more discrete components. The infotainment SoC 1230 may include a combination of hardware and software that may be used to provide the vehicle 1200 with audio (e.g., music, a personal digital assistant, navigation instructions, news, radio, etc.), video (e.g., TV, movies, streaming, etc.), phone (e.g., hands-free calling), network connectivity (e.g., LTE, Wi-Fi, etc.), and/or information services (e.g., navigation systems, reverse parking assistance, a radio data system, vehicle-related information such as fuel level, total distance traveled, brake fuel level, oil level, door open/close, air filter information, etc.). The infotainment SoC 1230 may include, for example, radios, record players, navigation systems, video playback devices, USB and Bluetooth connectivity, carputers, in-car entertainment, WiFi, steering wheel audio controls, a hands-free voice control, a heads-up display (HUD), an HMI display 1234, a telematics device, a control panel (e.g., for controlling and/or interacting with various components, features, and/or systems), and/or other components. The infotainment SoC 1230 may further be used to provide information (e.g., visually and/or audibly) to a user(s) of the vehicle, such as information from the ADAS system 1238, autonomous driving information such as planned vehicle maneuvers, trajectories, environmental information (e.g., intersection information, vehicle information, road information, etc.), and/or other information.

The infotainment SoC 1230 may include GPU functionality. The infotainment SoC 1230 may communicate with other devices, systems, and/or components of the vehicle 1200 via the bus 1202 (e.g., CAN bus, Ethernet, etc.). In some examples, the infotainment SoC 1230 may be coupled to a supervisory MCU so that the GPU of the infotainment system may perform some self-driving functions in the event that the primary controller(s) 1236 (e.g., primary and/or backup computers of the vehicle 1200) fail. In such an example, the infotainment SoC 1230 may place the vehicle 1200 into safe stop mode, as described herein.

The vehicle 1200 may further include an instrument cluster 1232 (e.g., a digital dashboard, an electronic instrument cluster, a digital instrument panel, etc.). The instrument cluster 1232 may include a controller and/or supercomputer (e.g., a discrete controller or supercomputer) The instrument cluster 1232 may include a set of instruments such as a speedometer, fuel level, oil pressure, tachometer, odometer, turn signals, shift position indicator, seat belt warning light(s), parking brake warning light(s), engine malfunction light(s), airbag (SRS) system information, lighting controls, safety system controls, navigation information, etc. In some examples, information may be displayed and/or shared between the infotainment SoC 1230 and the instrument cluster 1232. In other words, the instrument cluster 1232 may be included as part of the infotainment SoC 1230 or vice versa.

As mentioned above, in at least some embodiments, the motor vehicle platform 100 (see 1 ) may be a component of the autonomous vehicle 1200. In such embodiments, the controller(s) 1236 include the automotive SoC 104. For example, the automotive SoC 104 may be implemented as one of the SoC 1204.

15 is a system diagram for communication between the cloud-based server(s) and the example autonomous vehicle 1200 of 12 according to some embodiments of the present disclosure. The system 1276 may include server(s) 1278, network(s) 1290, and vehicles, including the vehicle 1200. The server(s) 1278 may include a plurality of GPUs 1284(A)-1284(H) (collectively referred to herein as GPUs 1284), PCIe switches 1282(A)-1282(H) (collectively referred to herein as PCIe switches 1282), and/or CPUs 1280(A)-1280(B) (collectively referred to herein as CPUs 1280). The GPUs 1284, CPUs 1280, and PCIe switches may be interconnected with high-speed interconnects, such as, without limitation, NVLink interfaces 1288 and/or PCIe interconnects 1286 developed by NVIDIA. In some examples, the GPUs 1284 are interconnected via an NVLink and/or NVSwitch SoC, and the GPUs 1284 and the PCIe switches 1282 are interconnected via PCIe interconnects. Although eight GPUs 1284, two CPUs 1280, and two PCIe switches are illustrated, this is not intended to be limiting. Depending on the embodiment, each of the servers 1278 may include any number of GPUs 1284, CPUs 1280, and/or PCIe switches. For example, the server(s) 1278 may include eight, sixteen, thirty-two, and/or more GPUs 1284, respectively.

The server(s) 1278 may receive, over the network(s) 1290 and from vehicles, image data representative of images showing unexpected or changed road conditions, such as recently begun road construction. The server(s) 1278 may transmit, over the network(s) 1290 and to the vehicles, neural networks 1292, updated neural networks 1292, and/or map information 1294, including information about traffic and road conditions. Updates to the map information 1294 may include updates to the HD map 1222, such as information regarding construction, potholes, detours, flooding, and/or other obstructions. In some examples, the neural networks 1292, updated neural networks 1292, and/or map information 1294 may result from new training and/or experience represented in data received from any number of vehicles in the area and/or based on training performed in a data center (e.g., using the server(s) 1278 and/or other servers).

The server(s) 1278 may be used to train machine learning models (e.g., neural networks) based on training data. The training data may be generated by the vehicles and/or may be generated in a simulation (e.g., using a game engine). In some examples, the training data is tagged (e.g., if the neural network benefits from supervised learning) and/or undergoes other preprocessing, while in other examples, the training data is not tagged and/or preprocessed (e.g., if the neural network does not require supervised learning). The training may be performed using one or more classes of machine learning techniques, including but not limited to classes such as: supervised training, semi-supervised training, unsupervised training, self-learning, reinforcement learning, federated learning, transfer learning, feature learning (including principal component and cluster analysis), multilinear subspace learning, manifold learning, representation learning (including replacement dictionary learning), rule-based machine learning, anomaly detection, and any variations or combinations thereof. After training the machine learning models, the machine learning models may be used by the vehicles (e.g., transmitted to the vehicles via the network(s) 1290) and/or the machine learning models may be used by the server(s) 1278 to remotely monitor the vehicles.

In some examples, the server(s) 1278 may receive data from the vehicles and apply the data to current real-time neural networks for intelligent real-time inference. The server(s) Server(s) 1278 may include deep learning supercomputers and/or dedicated AI computers powered by GPU(s) 1284, such as the DGX and DGX Station machines developed by NVIDIA. However, in some examples, server(s) 1278 may include a deep learning infrastructure that uses only CPU-powered data centers.

The deep learning infrastructure of the server(s) 1278 may be capable of rapid real-time inference and use this capability to evaluate and verify the state of processors, software, and/or associated hardware in the vehicle 1200. For example, the deep learning infrastructure may receive periodic updates from the vehicle 1200, such as a sequence of images and/or objects that the vehicle 1200 has located in that sequence of images (e.g., via machine vision and/or other machine learning techniques for object classification). The deep learning infrastructure may execute its own neural network to identify objects and compare them to objects identified by the vehicle 1200, and if the results do not match and the deep learning infrastructure concludes that the AI in the vehicle 1200 is malfunctioning, then the server(s) 1278 may transmit a signal to the vehicle 1200 instructing a fail-safe computer of the vehicle 1200 to take control, notify the passengers, and perform a safe parking maneuver.

The server(s) 1278 may include the GPU(s) 1284 and one or more programmable inference accelerators (e.g., TensorRT from NVIDIA). The combination of GPU-powered servers and inference acceleration may enable real-time responsiveness. In other examples, such as when performance is less critical, servers powered by CPUs, FPGAs, and other processors may be used for inference.

EXAMPLE CALCULATION DEVICE

16 is a block diagram of an example computing device(s) 1600 suitable for use in implementing some embodiments of the present disclosure. The computing device 1600 may include an interconnect system 1602 that directly or indirectly couples the following devices: memory 1604, one or more central processing units (CPUs) 1606, one or more graphics processing units (GPUs) 1608, a communications interface 1610, I/O ports 1612, input/output components 1614, a power supply 1616, one or more presentation components 1618 (e.g., display(s)), and one or more logic units 1620.

Even though the different blocks of 16 as being connected to wires via the interconnect system 1602, this is not intended to be limiting and is for clarity only. For example, in some embodiments, a presentation component 1618, such as a display device, may be considered an I/O component 1614 (e.g., if the display is a touchscreen). As another example, the CPUs 1606 and/or GPUs 1608 may include memory (e.g., memory 1604 may be representative of a storage device in addition to the memory of the GPUs 1608, the CPUs 1606, and/or other components). In other words, the computing device of 16 for illustrative purposes only. No distinction is made between categories such as “workstation”, “server”, “laptop”, “desktop”, “tablet”, “client device”, “mobile device”, “handheld device”, “game console”, “electronic control unit (ECU),” “virtual reality system”, “augmented reality system” and/or other device or system types, as all within the scope of the computing device of the 16 to be viewed as.

The interconnect system 1602 may represent one or more connections or buses, such as an address bus, a data bus, a control bus, or a combination thereof. The interconnect system 1602 may include one or more types of buses or connections, such as an industry standard architecture (ISA) bus, an extended industry standard architecture (EISA) bus, a Video Electronic Standards Association (VESA) bus, a peripheral interconnect (PCI) bus, a peripheral express interconnect (PCIe) bus, and/or another type of bus or connection. In some embodiments, there are direct connections between components. As an example, the CPU 1606 may be directly connected to the memory 1604. Further, the CPU 1606 may be directly connected to the GPU 1608. Where there is a direct or point-to-point connection between components, the interconnect system 1602 may include a PCIe connection to implement the connection. In these examples, a PCI bus may not be included in the computing device 1600.

The storage 1604 may include any variety of computer-readable media. The computer-readable media may be any available media accessible to the computing device 1600. The computer-readable media may include both volatile and non-volatile media, as well as removable and non-removable media. By way of example and not limitation, the computer-readable media may include computer storage media and communications media.

The computer storage media may include both volatile and non-volatile and/or removable and non-removable media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules, and/or other data. For example, the memory 1604 may store computer readable instructions (e.g., representing a program or programs and/or one or more program elements, such as an operating system). The computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disks (DVD) or other optical media, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing device 1600. As used herein, computer storage media does not include signals per se.

The computer storage media may embody computer-readable instructions, data structures, program modules, and/or other types of data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may refer to a signal that has one or more of its characteristics altered in such a way that information is encoded in the signal. For example, and not by way of limitation, computer storage media may include wired media, such as a wired network or wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of all of the foregoing are also intended to be included within the scope of computer-readable media.

The CPU(s) 1606 may be configured to execute at least some of the computer-readable instructions to control one or more components of the computing device 1600 to perform one or more of the methods and/or processes described herein. The CPU(s) 1606 may each include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of handling a plurality of software threads simultaneously. The CPU(s) 1606 may include any type of processor and may include different types of processors depending on the type of computing device 1600 (e.g., processors with fewer cores for mobile devices and processors with more cores for servers). For example, depending on the type of computing device 1600, the processor may be an Advanced RISC Machines (ARM) processor implemented using Reduced Instruction Set Computing (RISC) or an x86 processor implemented using Complex Instruction Set Computing (CISC). Computing device 1600 may include one or more CPUs 1606 in addition to one or more microprocessors or additional coprocessors, such as math coprocessors.

In addition or alternatively to the CPU(s) 1606, the GPU(s) 1608 may be configured to execute at least some of the computer-readable instructions to control one or more components of the computing device 1600 to perform one or more of the methods and/or processes described herein. One or more of the GPU(s) 1608 may be an integrated GPU (e.g., with one or more of the CPU(s) 1606) and/or one or more of the GPU(s) 1608 may be a discrete GPU. In embodiments, one or more of the GPU(s) 1608 may be a coprocessor of one or more of the CPU(s) 1606. The GPU(s) 1608 may be used by the computing device 1600 to render graphics (e.g., 3D graphics) or perform general purpose computations. For example, the GPU(s) 1608 may be used for general purpose computations on GPUs (GPGPU). The GPU(s) 1608 may include hundreds or thousands of cores capable of handling hundreds or thousands of software threads simultaneously. The GPU(s) 1608 may generate pixel data for output images in response to rendering commands (e.g., rendering commands from the CPU(s) 1606 received via a host interface). The GPU(s) 1608 may include graphics memory, such as display memory, to store pixel data or other suitable data, such as GPGPU data. The display memory may be included as part of the memory 1604. The GPU(s) 1608 may include two or more GPUs operating in parallel (e.g., via a link). The connection may connect the GPUs directly (e.g., using NVLINK) or may connect the GPUs via a switch. (e.g. using NVSwitch). When combined together, each GPU 1608 can generate pixel data or GPGPU data for different sections of an output or for different outputs (e.g. a first GPU for a first image and a second GPU for a second image). Each GPU can contain its own memory or can share memory with other GPUs.

In addition or alternatively to the CPU(s) 1606 and/or the GPU(s) 1608, the logic unit(s) 1620 may be configured to execute at least some of the computer-readable instructions to control one or more components of the computing device 1600 to perform one or more of the methods and/or processes described herein. In embodiments, the CPU(s) 1606, the GPU(s) 1608, and/or the logic unit(s) 1620 may individually or collectively perform any combination of the methods, processes, and/or portions thereof. One or more of the logic units 1620 may be part of and/or integrated with one or more of the CPU(s) 1606 and/or the GPU(s) 1608, and/or one or more of the logic units 1620 may be discrete components or otherwise external to the CPU(s) 1606 and/or the GPU(s) 1608. In embodiments, one or more of the logic units 1620 may be a coprocessor of one or more of the CPU(s) 1606 and/or one or more of the GPU(s) 1608.

Examples of the logic unit(s) 1620 include one or more processing cores and/or components thereof, such as tensor cores (TC), tensor processing units (TPU), pixel visual cores (PVC), vision processing units (VPU), graphics processing clusters (GPC), texture processing clusters (TPC), streaming multiprocessors (SM), tree traversal units (TTU), artificial intelligence accelerator (AIA), deep learning accelerator (DLA), arithmetic logic units (ALU), application specific integrated circuits (ASIC), floating point units (FPU), input/output (I/O) elements, peripheral interconnect (PCI) elements, or express peripheral interconnect (EXI) elements. (peripheral component interconnect express - PCIe) and/or the like.

The communication interface 1610 may include one or more receivers, transmitters, and/or transceivers that enable the computing device 1600 to communicate with other computing devices over an electronic communication network, including wired and/or wireless communication. The communication interface 1610 may include components and functionality to enable communication over a number of different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., communications over Ethernet or InfiniBand), low-power wide area networks (e.g., LoRaWAN, SigFox, etc.), and/or the Internet.

The I/O ports 1612 may enable the computing device 1600 to be logically coupled to other devices, including the I/O components 1614, the presentation component(s) 1618, and/or other components, some of which may be built into (e.g., integrated into) the computing device 1600. Illustrative I/O components 1614 include a microphone, a mouse, a keyboard, a joystick, a gamepad, a game controller, a satellite dish, a scanner, a printer, a wireless device, etc. The I/O components 1614 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological inputs generated by a user. In some cases, inputs may be transmitted to an appropriate network element for further processing. A NUI may implement any combination of speech recognition, pen recognition, facial recognition, biometric recognition, both on-screen and off-screen gesture recognition, air gestures, head and eye tracking, and touch detection (as described in more detail below) associated with a display of the computing device 1600. The computing device 1600 may include depth cameras, such as stereoscopic camera systems, infrared camera systems, RGB camera systems, touchscreen technology, and combinations thereof, for gesture detection and recognition. Additionally, the computing device 1600 may include accelerometers or gyroscopes (e.g., as part of an inertial measurement unit (IMU)) that enable motion detection. In some examples, the output of the accelerometers or gyroscopes may be used by the computing device 1600 to render immersive augmented reality or virtual reality.

The power supply 1616 may also include a hardwired power supply, a battery power supply, or a combination thereof. The power supply 1616 may provide power to the computing device 1600 to enable the components of the computing device 1600 to operate.

The presentation component(s) 1618 may include a display (e.g., a monitor, a touchscreen, a television screen, a heads-up display (HUD), other types of displays, or a combination thereof), speakers, and/or other presentation components. The presentation component(s) 1618 may receive data from other components (e.g., the GPU(s) 1608, the CPU(s) 1606, etc.) and output the data (e.g., as an image, video, audio, etc.).

The disclosure may be described in the general context of computer code or machine-usable instructions, including computer-executable instructions such as program modules, executed by a computer or another computer, such as a personal data assistant or other handheld device. In general, program modules, including routines, programs, objects, components, data structures, etc., refer to codes that perform specific tasks or implement specific abstract data types. The disclosure may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general purpose computers, more specialized computing devices, etc. The disclosure may also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communications network.

• 1. System, umfassend: einen Speicher, der unter Beachtung einer ersten Risikoklassifizierungsstufe arbeitet; und eine Schaltungsanordnung, die unter Beachtung einer zweiten Risikoklassifizierungsstufe arbeitet, die eine höhere Risikoklassifizierung als die erste Risikoklassifizierungsstufe angibt, wobei die Schaltungsanordnung dazu dient, einen Fehlererkennungscode für Daten, die in eine erste Speicheradresse innerhalb des Speichers zu schreiben sind, zu bestimmen, eine zweite Speicheradresse innerhalb des Speichers zumindest teilweise basierend auf der ersten Speicheradresse zu bestimmen und zu veranlassen, dass die Daten in der ersten Speicheradresse gespeichert werden und der Fehlererkennungscode in der zweiten Speicheradresse gespeichert werden.
• 2. System nach Absatz 1, wobei nach dem Speichern der Daten in der ersten Speicheradresse und dem Speichern der Fehlererkennungscode in der zweiten Speicheradresse: die Schaltungsanordnung dazu dient, die Daten aus der ersten Speicheradresse zu erlangen, den Fehlererkennungscode aus der zweiten Speicheradresse zu erlangen, einen Prüfcode basierend auf der ersten Speicheradresse und den aus der ersten Speicheradresse erlangten Daten zu generieren und eine Benachrichtigung zu generieren, wenn der Fehlererkennungscode angibt, dass die Daten mindestens einen Fehler enthalten.
• 3. System nach Absatz 2, wobei der Fehlererkennungscode angibt, dass die Daten den mindestens einen Fehler enthalten, wenn der Fehlererkennungscode nicht mit dem Prüfcode übereinstimmt.
• 4. System nach Absatz 2 oder 3, wobei die Schaltungsanordnung dazu dient, während eines ersten Speicherzugriffs die Daten aus der ersten Speicheradresse zu erlangen und während eines zweiten Speicherzugriffs den Fehlererkennungscode aus der zweiten Speicheradresse zu erlangen.
• 5. System nach einem der Absätze 2-4, ferner umfassend: eine erste Schnittstelle, über die die Daten aus der ersten Speicheradresse erlangt werden; und eine zweite Schnittstelle, über die der Fehlererkennungscode aus der zweiten Speicheradresse parallel zum Erlangen der Daten über die erste Schnittstelle erlangt wird, wobei sich die erste Schnittstelle von der zweiten Schnittstelle unterscheidet.
• 6. System nach Absatz 4, wobei die Schaltungsanordnung eine Zeitverzögerung zwischen dem ersten und dem zweiten Speicherzugriff einführt.
• 7. System nach einem der Absätze 1-6, wobei der Speicher einen ersten Teilbereich und einen zweiten Teilbereich umfasst, der erste Teilbereich die erste Speicheradresse umfasst, der zweite Teilbereich die zweite Speicheradresse umfasst, und die Schaltungsanordnung dazu dient, während einer Startprozedur einen neuen Fehlererkennungscode in jede Speicheradresse in dem zweiten Teilbereich zu schreiben.
• 8. System nach einem der Absätze 1-7, wobei die Schaltungsanordnung dazu dient, den Fehlererkennungscode basierend auf der ersten Speicheradresse und den Daten zu bestimmen, bevor die Daten in eine erste Speicheradresse geschrieben werden.
• 9. System nach einem der Absätze 1-8, wobei die Schaltungsanordnung einen ersten und einen zweiten Block umfasst, der erste Block dazu dient, eine Schreibanforderung, die die Daten und die erste Speicheradresse umfasst, an den zweiten Block zu übertragen, der zweite Block dazu dient, die Schreibanforderung zur empfangen, den Fehlererkennungscode zu bestimmen, die zweite Speicheradresse zu bestimmen und zu veranlassen, dass die Daten in der ersten Speicheradresse gespeichert werden und der Fehlererkennungscode in der zweiten Speicheradresse gespeichert wird.
• 10. System nach Absatz 9, wobei der erste Block einen Schreibzeitgeber umfasst, der startet, wenn der erste Block die Schreibanforderung an den zweiten Block überträgt, und der erste Block dazu dient, einen Schreibfehler zu generieren, wenn der Schreibzeitgeber angibt, dass mehr als eine vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block eine Antwort von dem Speicher empfängt.
• 11. System nach Absatz 9 oder 10, wobei, nachdem der erste Block die Schreibanforderung sendet: der erste Block dazu dient, eine Leseanforderung an den zweiten Block für die in der ersten Speicheradresse gespeicherten Daten zu senden, und der zweite Block dazu dient, die Leseanforderung zu empfangen, die Daten aus der ersten Speicheradresse zu erlangen, den Fehlererkennungscode aus der zweiten Speicheradresse zu erlangen und eine Benachrichtigung an den ersten Block zu übertragen, wenn der zweite Block bestimmt, dass der Fehlererkennungscode angibt, dass die Daten den mindestens einen Fehler enthalten.
• 12. System nach Absatz 11, wobei der erste Block einen Lesezeitgeber umfasst, der startet, wenn der erste Block die Leseanforderung sendet, und der erste Block dazu dient, einen Lesefehler zu generieren, wenn der Lesezeitgeber angibt, dass mehr als eine vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block die Daten empfängt.
• 13. System nach einem der Absätze 1-12, wobei die Schaltungsanordnung dazu dient zu veranlassen, dass die Daten während eines ersten Speicherzugriffs in der ersten Speicheradresse gespeichert werden und dass der Fehlererkennungscode während eines zweiten Speicherzugriffs in der zweiten Speicheradresse gespeichert wird.
• 14. System nach Absatz 13, wobei die Schaltungsanordnung eine erste Zeitverzögerung zwischen dem ersten und dem zweiten Speicherzugriff einführt.
• 15. System nach einem der Absätze 1-14, das sich auf einem zusammenhängenden Stück aus Halbleitermaterial befindet.
• 16. System nach Absatz 15, das einen Abschnitt eines Systems auf einem Chip („SoC“) implementiert, das einem Kraftfahrzeug entspricht.
• 17. System nach einem der Absätze 1-16, wobei die erste und die zweite Risikoklassifizierungsstufe jeweils ein Automotive Safety Integrity Level („ASIL“) sind.
• 18. System nach einem der Absätze 1-17, wobei der Fehlererkennungscode ein Prüfcode mit zyklischer Redundanz oder ein Fehlerkorrekturcode ist.
• 19. System, umfassend: einen Speicher, der innerhalb einer ersten Risikoklassifizierungsstufe arbeitet, wobei der Speicher eine isolierte Speicherregion umfasst, umfassend eine erste Speicheradresse, die Daten speichert, und eine zweite Speicheradresse, die einen Fehlererkennungscode speichert; und eine Schaltungsanordnung, die innerhalb einer zweiten Risikoklassifizierungsstufe arbeitet, die eine höhere Risikostufe als die erste Risikoklassifizierungsstufe angibt, wobei die Schaltungsanordnung dazu dient, die Daten aus der ersten Speicheradresse zu erlangen, den Fehlererkennungscode aus der zweiten Speicheradresse zu erlangen und eine Benachrichtigung zu generieren, wenn der Fehlererkennungscode angibt, dass die Daten mindestens einen Fehler enthalten.
• 20. System nach Absatz 19, wobei die Schaltungsanordnung dazu dient, einen Prüfcode basierend auf der ersten Speicheradresse und den aus der ersten Speicheradresse erlangten Daten zu generieren, wobei der Fehlererkennungscode angibt, dass die Daten den mindestens einen Fehler enthalten, wenn der Fehlererkennungscode nicht mit dem Prüfcode übereinstimmt.
• 21. System nach Absatz 19 oder 20, wobei die Schaltungsanordnung einen ersten und einen zweiten Block umfasst, wobei der erste Block dazu dient, eine Leseanforderung für die in der ersten Speicheradresse gespeicherten Daten an den zweiten Block zu senden, und der zweite Block dazu dient, die Leseanforderung zu empfangen, die Daten zu erlangen, den Fehlererkennungscode zu erlangen und die Benachrichtigung zu generieren, wenn der Fehlererkennungscode angibt, dass die Daten den mindestens einen Fehler enthalten.
• 22. System nach Absatz 21, wobei der erste Block einen Lesezeitgeber umfasst, der startet, wenn der erste Block die Leseanforderung sendet, und der erste Block dazu dient, einen Fehler zu generieren, wenn der Lesezeitgeber angibt, dass mehr als eine vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block die Daten empfängt.
• 23. System nach Absatz 21 oder 22, wobei, bevor der erste Block die Leseanforderung sendet: der erste Block dazu dient, die Daten und die erste Speicheradresse an den zweiten Block zu übertragen, und der zweite Block dazu dient, den Fehlererkennungscode zu bestimmen, die zweite Speicheradresse zu bestimmen, zu veranlassen, dass die Daten in der ersten Speicheradresse gespeichert werden, und zu veranlassen, dass der Fehlererkennungscode in der zweiten Speicheradresse gespeichert wird.
• 24. System nach Absatz 23, wobei der erste Block einen Schreibzeitgeber umfasst, der startet, wenn der erste Block die Daten und die erste Speicheradresse an den zweiten Block überträgt, und der erste Block dazu dient, einen Schreibfehler zu generieren, wenn der Schreibzeitgeber angibt, dass mehr als eine erste vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block eine Antwort von dem Speicher empfängt.
• 25. System nach Absatz 24, wobei der erste Block einen Lesezeitgeber umfasst, der startet, wenn der erste Block die Leseanforderung sendet, und der erste Block dazu dient, einen Lesefehler zu generieren, wenn der Lesezeitgeber angibt, dass mehr als eine zweite vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block die Daten aus dem Speicher empfängt.
• 26. System nach einem der Absätze 19-25, wobei die Schaltungsanordnung dazu dient, während eines ersten Speicherzugriffs die Daten aus der ersten Speicheradresse zu erlangen und während eines zweiten Speicherzugriffs den Fehlererkennungscode aus der zweiten Speicheradresse zu erlangen.
• 27. System nach Absatz 26, wobei die Schaltungsanordnung eine Zeitverzögerung zwischen dem ersten und dem zweiten Speicherzugriff einführt.
• 28. System nach einem der Absätze 19-27, wobei die Schaltungsanordnung den Fehlererkennungscode während einer Startprozedur in die zweite Speicheradresse geschrieben hat.
• 29. System nach einem der Absätze 19-28, das sich auf einem zusammenhängenden Stück aus Halbleitermaterial befindet.
• 30. System nach Absatz 29, das einen Abschnitt eines Systems auf einem Chip („SoC“) implementiert, das einem Kraftfahrzeug entspricht.
• 31. System nach einem der Absätze 19-30, wobei die erste und die zweite Risikoklassifizierungsstufe jeweils ein Automotive Safety Integrity Level („ASIL“) ist.
• 32. System nach einem der Absätze 19-31, wobei der Fehlererkennungscode ein Prüfcode mit zyklischer Redundanz oder ein Fehlerkorrekturcode ist.
• 33. Verfahren, das durch eine Schaltungsanordnung durchgeführt wird, die auf einer ersten Risikoklassifizierungsstufe arbeitet, wobei das Verfahren Folgendes umfasst: Bestimmen eines Fehlererkennungscodes für Daten, die in eine erste Speicheradresse innerhalb eines Speichers zu schreiben sind, der auf einer zweiten Risikoklassifizierungsstufe arbeitet, die eine niedrigere Risikostufe als die erste Risikoklassifizierungsstufe angibt; Bestimmen einer zweiten Speicheradresse innerhalb des Speichers zumindest teilweise basierend auf der ersten Speicheradresse; und Veranlassen, dass die Daten in der ersten Speicheradresse gespeichert werden und der Fehlererkennungscode in der zweiten Speicheradresse gespeichert wird.
• 34. Verfahren nach Absatz 33, ferner umfassend: Erlangen der Daten aus der ersten Speicheradresse, nachdem die Daten in der ersten Speicheradresse gespeichert wurden; Erlangen des Fehlererkennungscodes aus der zweiten Speicheradresse, nachdem der Fehlererkennungscode in der zweiten Speicheradresse gespeichert wurde; Generieren eines Prüfcodes basierend auf der ersten Speicheradresse und den aus der ersten Speicheradresse erlangten Daten; und Generieren einer Benachrichtigung, wenn der Prüfcode angibt, dass die Daten mindestens einen Fehler enthalten.
• 35. Verfahren nach Absatz 34, wobei der Fehlererkennungscode basierend auf der ersten Speicheradresse und den Daten generiert wurde, bevor die Daten in der ersten Speicheradresse gespeichert wurden, und der Prüfcode angibt, dass die Daten den mindestens einen Fehler enthalten, wenn der Prüfcode nicht mit dem Fehlererkennungscode übereinstimmt.
• 36. Verfahren nach einem der Absätze 33-35, wobei der Speicher einen ersten Teilbereich und einen zweiten Teilbereich umfasst, der erste Teilbereich die erste Speicheradresse umfasst, der zweite Teilbereich die zweite Speicheradresse umfasst, und das Verfahren ferner Folgendes umfasst: Schreiben eines neuen Fehlererkennungscodes in jede Speicheradresse in dem zweiten Teilbereich während einer Startprozedur.
• 37. Verfahren, das durch eine Schaltungsanordnung durchgeführt wird, die auf einer ersten Risikoklassifizierungsstufe arbeitet, wobei das Verfahren Folgendes umfasst: Erlangen von Daten aus einer ersten Speicheradresse eines Speichers, der auf einer zweiten Risikoklassifizierungsstufe arbeitet, die eine niedrigere Risikostufe als die erste Risikoklassifizierungsstufe angibt; Bestimmen einer zweiten Speicheradresse innerhalb des Speichers zumindest teilweise basierend auf der ersten Speicheradresse; Erlangen eines Fehlererkennungscodes aus der zweiten Speicheradresse; und Generieren einer Benachrichtigung, wenn der Fehlererkennungscode angibt, dass die Daten mindestens einen Fehler enthalten.
• 38. Verfahren nach Absatz 37, ferner umfassend: Generieren eines Prüfcodes basierend auf der ersten Speicheradresse und den aus der ersten Speicheradresse erlangten Daten; und Bestimmen, ob der Prüfcode mit dem Fehlererkennungscode übereinstimmt, wobei der Fehlererkennungscode angibt, dass die Daten den mindestens einen Fehler enthalten, wenn der Fehlererkennungscode nicht mit dem Prüfcode übereinstimmt.
• 39. Verfahren nach Absatz 37 oder 38, wobei die Schaltungsanordnung die Daten aus der ersten Speicheradresse während eines ersten Speicherzugriffs erlangt, die Schaltungsanordnung den Fehlererkennungscode aus der zweiten Speicheradresse während eines zweiten Speicherzugriffs erlangt, und das Verfahren ferner Folgendes umfasst: Einführen einer Zeitverzögerung zwischen dem ersten und dem zweiten Speicherzugriff.
• 40. Verfahren nach einem der Absätze 37-39, wobei die Schaltungsanordnung einen ersten und einen zweiten Block umfasst und das Verfahren ferner Folgendes umfasst: Senden einer Leseanforderung durch den ersten Block an den zweiten Block für die in der ersten Speicheradresse gespeicherten Daten; und Empfangen der Leseanforderung durch den zweiten Block, wobei der zweite Block die Daten erlangt, den Fehlererkennungscode erlangt und die Benachrichtigung generiert, wenn der Fehlererkennungscode angibt, dass die Daten den mindestens einen Fehler enthalten.
• 41. Verfahren nach Absatz 40, wobei ein Lesezeitgeber startet, wenn der erste Block die Leseanforderung sendet, und das Verfahren ferner Folgendes umfasst: Generieren einen Lesefehlers durch den ersten Block, wenn der Lesezeitgeber angibt, dass mehr als eine vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block die Daten empfängt.
• 42. Verfahren nach Absatz 40 oder 41, ferner umfassend: Übertragen einer Schreibanforderung durch den ersten Block an den zweiten Block, bevor der erste Block die Leseanforderung sendet, wobei die Schreibanforderung die Daten und die erste Speicheradresse umfasst; Bestimmen des Fehlererkennungscodes durch den zweiten Block, bevor der erste Block die Leseanforderung sendet; Bestimmen der zweiten Speicheradresse durch den zweiten Block, bevor der erste Block die Leseanforderung sendet; und Veranlassen durch den zweiten Block, dass die Daten in der ersten Speicheradresse gespeichert werden und der Fehlererkennungscode in dem zweiten Speicher gespeichert wird, bevor der erste Block die Leseanforderung sendet.
• 43. Verfahren nach Absatz 42, wobei ein Schreibzeitgeber startet, wenn der erste Block die Schreibanforderung sendet, und das Verfahren ferner Folgendes umfasst: Generieren einen Schreibfehlers durch den ersten Block, wenn der Schreibzeitgeber angibt, dass mehr als eine erste vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block eine Antwort von dem Speicher empfängt.
• 44. Verfahren nach Absatz 43, wobei ein Lesezeitgeber startet, wenn der erste Block die Leseanforderung sendet, und das Verfahren ferner Folgendes umfasst: Generieren einen Lesefehlers durch den ersten Block, wenn der Lesezeitgeber angibt, dass mehr als eine zweite vorbestimmte Zeitdauer verstrichen ist, bevor der erste Block die Daten empfängt.
• 45. Verfahren nach einem der Absätze 42-44, wobei der zweite Block veranlasst, dass die Daten während eines ersten Speicherzugriffs in der ersten Speicheradresse gespeichert werden, der zweite Block veranlasst, dass der Fehlererkennungscode während eines zweiten Speicherzugriffs in der zweiten Speicheradresse gespeichert wird, und das Verfahren ferner Folgendes umfasst: Einführen einer Zeitverzögerung zwischen dem ersten und dem zweiten Speicherzugriff.
• 46. Verfahren nach einem der Absätze 37-45, ferner umfassend: Schreiben des Fehlererkennungscodes in die zweite Speicheradresse während einer Startprozedur.
• 47. Verfahren nach einem der Absätze 37-46, wobei die erste und die zweite Risikoklassifizierungsstufe jeweils ein Automotive Safety Integrity Level („ASIL“) ist.
• 48. Verfahren nach einem der Absätze 37-47, wobei der Fehlererkennungscode ein Prüfcode mit zyklischer Redundanz oder ein Fehlerkorrekturcode ist.

At least one embodiment of the disclosure may be described with respect to the following paragraphs:

• 1. A system comprising: a memory operating in compliance with a first risk classification level; and circuitry operating in compliance with a second risk classification level indicating a higher risk classification than the first risk classification level, the circuitry to determine an error detection code for data to be written to a first memory address within the memory, determine a second memory address within the memory based at least in part on the first memory address, and cause the data to be stored in the first memory address and the error detection code to be stored in the second memory address.
• 2. The system of paragraph 1, wherein after storing the data in the first memory address and storing the error detection code in the second memory address: the circuitry is to obtain the data from the first memory address, obtain the error detection code from the second memory address, generate a check code based on the first memory address and the data obtained from the first memory address, and generate a notification if the error detection code indicates that the data contains at least one error.
• 3. A system according to paragraph 2, wherein the error detection code indicates that the data contains the at least one error if the error detection code does not match the check code.
• 4. A system according to paragraph 2 or 3, wherein the circuit arrangement serves to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access.
• 5. The system of any of paragraphs 2-4, further comprising: a first interface through which the data is obtained from the first memory address; and a second interface through which the error detection code is obtained from the second memory address in parallel with obtaining the data through the first interface, wherein the first interface is different from the second interface.
• 6. A system according to paragraph 4, wherein the circuit arrangement introduces a time delay between the first and the second memory access.
• 7. The system of any of paragraphs 1-6, wherein the memory comprises a first sub-area and a second sub-area, the first sub-area comprises the first memory address, the second sub-area comprises the second memory address, and the circuitry is operable to write a new error detection code to each memory address in the second sub-area during a start-up procedure.
• 8. The system of any of paragraphs 1-7, wherein the circuitry is to determine the error detection code based on the first memory address and the data before the data is written to a first memory address.
• 9. The system of any of paragraphs 1-8, wherein the circuitry comprises a first and a second block, the first block is operable to transmit a write request comprising the data and the first memory address to the second block, the second block is operable to receive the write request, determine the error detection code, determine the second memory address, and cause the data to be stored in the first memory address and the error detection code to be stored in the second memory address.
• 10. The system of paragraph 9, wherein the first block includes a write timer that starts when the first block transmits the write request to the second block, and the first block is operable to generate a write error when the write timer indicates that more than a predetermined amount of time has elapsed before the first block receives a response from the memory.
• 11. The system of paragraph 9 or 10, wherein after the first block sends the write request: the first block is to send a read request to the second block for the data stored in the first memory address, and the second block is to receive the read request, obtain the data from the first memory address, obtain the error detection code from the second memory address, and transmit a notification to the first block when the second block determines that the error detection code indicates that the data contains the at least one error.
• 12. The system of paragraph 11, wherein the first block includes a read timer that starts when the first block sends the read request, and the first block is operable to generate a read error when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.
• 13. The system of any of paragraphs 1-12, wherein the circuitry is operable to cause the data to be stored in the first memory address during a first memory access and the error detection code to be stored in the second memory address during a second memory access.
• 14. The system of paragraph 13, wherein the circuitry introduces a first time delay between the first and second memory accesses.
• 15. A system according to any one of paragraphs 1-14 located on a continuous piece of semiconductor material.
• 16. A system as defined in paragraph 15 that implements a portion of a system on a chip (“SoC”) corresponding to a motor vehicle.
• 17. A system according to any one of paragraphs 1-16, wherein the first and second risk classification levels are each an Automotive Safety Integrity Level (“ASIL”).
• 18. A system according to any one of paragraphs 1-17, wherein the error detection code is a cyclic redundancy check code or an error correction code.
• 19. A system comprising: a memory operating within a first risk classification level, the memory comprising an isolated memory region comprising a first memory address storing data and a second memory address storing an error detection code; and circuitry operating within a second risk classification level indicating a higher risk level than the first risk classification level, the circuitry operable to obtain the data from the first memory address, obtain the error detection code from the second memory address, and generate a notification when the error detection code indicates that the data contains at least one error.
• 20. The system of paragraph 19, wherein the circuitry is to generate a check code based on the first memory address and the data obtained from the first memory address, the error detection code indicating that the data contains the at least one error if the error detection code does not match the check code.
• 21. The system of paragraph 19 or 20, wherein the circuitry comprises first and second blocks, the first block operable to send a read request for the data stored in the first memory address to the second block, and the second block operable to receive the read request, obtain the data, obtain the error detection code, and generate the notification when the error detection code indicates that the data contains the at least one error.
• 22. The system of paragraph 21, wherein the first block includes a read timer that starts when the first block sends the read request, and the first block is operable to generate an error if the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.
• 23. The system of paragraph 21 or 22, wherein, before the first block sends the read request: the first block is to transfer the data and the first memory address to the second block, and the second block is to determine the error detection code, determine the second memory address, cause the data to be stored in the first memory address, and cause the error detection code to be stored in the second memory address.
• 24. The system of paragraph 23, wherein the first block includes a write timer that starts when the first block transfers the data and the first memory address to the second block, and the first block is operable to generate a write error when the write timer indicates that more than a first predetermined period of time has elapsed before the first block receives a response from the memory.
• 25. The system of paragraph 24, wherein the first block includes a read timer that starts when the first block sends the read request, and the first block is operable to generate a read error when the read timer indicates that more than a second predetermined period of time has elapsed before the first block receives the data from the memory.
• 26. The system of any of paragraphs 19-25, wherein the circuitry is operable to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access.
• 27. The system of paragraph 26, wherein the circuitry introduces a time delay between the first and second memory accesses.
• 28. The system of any of paragraphs 19-27, wherein the circuitry has written the error detection code to the second memory address during a start-up procedure.
• 29. A system according to any one of paragraphs 19 to 28 located on a continuous piece of semiconductor material.
• 30. A system as defined in paragraph 29 that implements a portion of a system on a chip (‘SoC’) corresponding to a motor vehicle.
• 31. A system according to any of paragraphs 19 to 30, wherein the first and second risk classification levels are each an Automotive Safety Integrity Level (“ASIL”).
• 32. A system according to any one of paragraphs 19 to 31, wherein the error detection code is a cyclic redundancy check code or an error correction code.
• 33. A method performed by circuitry operating at a first risk classification level, the method comprising: determining an error detection code for data to be written to a first memory address within a memory operating at a second risk classification level indicating a lower risk level than the first risk classification level; determining a second memory address within the memory based at least in part on the first memory address; and causing the data to be stored at the first memory address and the error detection code to be stored at the second memory address.
• 34. The method of paragraph 33, further comprising: obtaining the data from the first memory address after storing the data in the first memory address; obtaining the error detection code from the second memory address after storing the error detection code in the second memory address; generating a check code based on the first memory address and the data obtained from the first memory address; and generating a notification if the check code indicates that the data contains at least one error.
• 35. The method of paragraph 34, wherein the error detection code was generated based on the first memory address and the data before the data was stored in the first memory address, and the check code indicates that the data contains the at least one error if the check code does not match the error detection code.
• 36. A method according to any one of paragraphs 33-35, wherein the memory comprises a first sub-area and a second sub-area, the first sub-area comprises the first memory address, the second sub-area area comprises the second memory address, and the method further comprises: writing a new error detection code to each memory address in the second sub-area during a start-up procedure.
• 37. A method performed by circuitry operating at a first risk classification level, the method comprising: obtaining data from a first memory address of a memory operating at a second risk classification level indicating a lower risk level than the first risk classification level; determining a second memory address within the memory based at least in part on the first memory address; obtaining an error detection code from the second memory address; and generating a notification if the error detection code indicates that the data contains at least one error.
• 38. The method of paragraph 37, further comprising: generating a check code based on the first memory address and the data obtained from the first memory address; and determining whether the check code matches the error detection code, wherein the error detection code indicates that the data contains the at least one error if the error detection code does not match the check code.
• 39. The method of paragraph 37 or 38, wherein the circuitry obtains the data from the first memory address during a first memory access, the circuitry obtains the error detection code from the second memory address during a second memory access, and the method further comprises: introducing a time delay between the first and second memory accesses.
• 40. The method of any of paragraphs 37-39, wherein the circuitry comprises a first and a second block, the method further comprising: sending a read request by the first block to the second block for the data stored in the first memory address; and receiving the read request by the second block, wherein the second block obtains the data, obtains the error detection code, and generates the notification if the error detection code indicates that the data contains the at least one error.
• 41. The method of paragraph 40, wherein a read timer starts when the first block sends the read request, the method further comprising: generating a read error by the first block if the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.
• 42. The method of paragraph 40 or 41, further comprising: transmitting a write request by the first block to the second block before the first block sends the read request, the write request comprising the data and the first memory address; determining the error detection code by the second block before the first block sends the read request; determining the second memory address by the second block before the first block sends the read request; and causing the second block to store the data in the first memory address and the error detection code to be stored in the second memory before the first block sends the read request.
• 43. The method of paragraph 42, wherein a write timer starts when the first block sends the write request, the method further comprising: generating a write error by the first block if the write timer indicates that more than a first predetermined period of time has elapsed before the first block receives a response from the memory.
• 44. The method of paragraph 43, wherein a read timer starts when the first block sends the read request, the method further comprising: generating a read error by the first block if the read timer indicates that more than a second predetermined period of time has elapsed before the first block receives the data.
• 45. The method of any of paragraphs 42-44, wherein the second block causes the data to be stored in the first memory address during a first memory access, the second block causes the error detection code to be stored in the second memory address during a second memory access, and the method further comprises: introducing a time delay between the first and second memory accesses.
• 46. The method of any of paragraphs 37-45, further comprising: writing the error detection code to the second memory address during a boot procedure.
• 47. A method according to any of paragraphs 37 to 46, wherein the first and second risk classification levels are each an Automotive Safety Integrity Level (‘ASIL’).
• 48. A method according to any one of paragraphs 37 to 47, wherein the error detection code is a cyclic redundancy check code or an error correction code.

The use of the terms "a" and "an" and "the" and similar referents in the context of describing disclosed embodiments (particularly in the context of the following claims) is to be interpreted to cover both the singular and plural, unless otherwise specified herein or the context clearly contradicts it, and not as a definition of a term. The terms "comprising," "having," "including," and "containing" are to be interpreted as open-ended terms (i.e., "including but not limited to") unless otherwise specified. The term "connected" is to be interpreted as partially or completely contained, attached, or attached to one another when unmodified and refers to physical connections even when an element is inserted therebetween. The mention of ranges of values herein is intended to serve only as a shorthand method for individually referring to each separate value that falls within the range, unless otherwise specified herein, and each separate value is included in the description as if it were individually recited herein. In at least one embodiment, use of the term "set" (e.g., "a set of items") or "subset" is to be construed as a non-empty collection comprising one or more items, unless otherwise noted or the context otherwise contradicts. Furthermore, unless otherwise noted or the context otherwise contradicts, the term "subset" does not necessarily refer to a proper subset of the corresponding set, but the subset and the corresponding set may be the same.

As used herein, the use of "and/or" in reference to two or more elements should be construed as referring to only one element or combination of elements. For example, "Element A, Element B, and/or Element C" may include only Element A, only Element B, only Element C, Element A and Element B, Element A and Element C, Element B and Element C, or Elements A, B, and C.

Unless specifically stated otherwise or the context clearly contradicts it, linking language, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C," is otherwise to be understood in the context in which it is generally used to represent that an item, expression, etc. can be either A or B or C or any nonempty subset of the set of A and B and C. For example, in the illustrated example of a set having three elements, the linking phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such linking language is generally not intended to imply that particular implementations require that at least one of A, at least one of B, and at least one of C be present. Unless otherwise noted or the context contradicts, the term "plurality" indicates a state of plurality (e.g., "a plurality of items" indicates multiple items). In at least one embodiment, a number of items in a plurality is at least two, but can be more if indicated either explicitly or by context. Further, unless otherwise specified or evident from the context, the phrase "based on" means "at least partially based on" and not "solely based on."

Operations of processes described herein may be performed in any suitable order, unless otherwise specified herein or the context clearly contradicts it. In at least one embodiment, a process, such as the processes described herein (or variations and/or combinations thereof), is performed under the control of one or more computer systems configured with executable instructions, and is implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing together on one or more processors, by hardware, or combinations thereof. In at least one embodiment, code is stored on a computer-readable storage medium. In one embodiment, in the form of a computer program comprising a plurality of instructions executable by one or more processors. In at least one embodiment, a computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transitory signals (e.g., a propagating transient electrical or electromagnetic transmission) but includes non-transitory data storage circuits (e.g., buffers, caches, and queues) within the transceivers of transitory signals. In at least one embodiment, the code (e.g., executable code or source code) is embodied on a set of stored by one or more non-transitory computer-readable storage mediums storing executable instructions (or other storage for storing executable instructions) that, when executed (i.e., as a result of execution) by one or more processors of a computer system, cause the computer system to perform operations described herein. A set of non-transitory computer-readable storage mediums, in at least one embodiment, comprises a plurality of non-transitory computer-readable storage mediums, and one or more of the individual non-transitory storage mediums of a plurality of non-transitory computer-readable storage media lack all of the code, while a plurality of non-transitory computer-readable storage media collectively store all of the code. In at least one embodiment, the executable instructions are executed such that different instructions are executed by different processors—in at least one embodiment, a non-transitory computer-readable storage medium stores instructions and a primary central processing unit (“CPU”) executes some of the instructions while a graphics processing unit (“GPU”) executes other instructions. In at least one embodiment, different components of a computer system have separate processors, and different processors execute different subsets of instructions.

Accordingly, in at least one embodiment, computer systems are configured to implement one or more services that individually or collectively perform operations of the processes described herein, and such computer systems are configured with applicable hardware and/or software that enable operations to be performed. Further, a computer system implementing at least one embodiment of the present disclosure is a single device, and in another embodiment, a distributed computer system that includes multiple devices that operate differently such that the distributed computer system performs the operations described herein and such that a single device does not perform all operations.

The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate embodiments of the disclosure and is not intended to limit the scope of the disclosure unless otherwise claimed. No language in the specification should be construed to identify any unclaimed element as essential to practicing the disclosure.

Any references, including publications, patent applications and patents cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and set forth in its entirety herein.

In the specification and claims, the terms "coupled" and "connected" may be used together with their derivatives. It is understood that these terms may not be intended as synonyms for each other. Rather, in specific examples, "connected" or "coupled" may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. "Coupled" may also mean that two or more elements are not in direct contact with each other, but nevertheless cooperate or interact with each other.

Unless expressly stated otherwise, it is to be understood that terms such as "processing", "computation", "calculating", "determining" or the like throughout the specification refer to acts and/or processes of a computer or computing system or similar electronic computing device that manipulate and/or transform data represented as physical, e.g. electronic, quantities in the registers and/or memories of the computing system into other data similarly represented as physical quantities in the memories, registers or other such information storage, transmission or display devices of the computing system.

Similarly, the term “processor” may refer to any device or portion of a device that processes electronic data from registers and/or memories and converts that electronic data into other electronic data that can be stored in registers and/or memories. As non-limiting examples, the “processor” may be a CPU or a GPU. A “computing platform” may include one or more processors. As used herein, “software” processes may include, for example, software and/or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. In addition, each process may refer to multiple processes to execute instructions sequentially or in parallel, continuously or intermittently. The terms "system" and "process" are used interchangeably herein in that the system may embody one or more processes and the processes may be considered as a system.

In at least one embodiment, an arithmetic logic unit is a set of combinational logic circuits that processes one or more inputs to produce a result. In at least one embodiment, an arithmetic logic unit is used by a processor to perform mathematical operations such as addition, subtraction, or multiplication. In at least one embodiment, an arithmetic logic unit is used to implement logical operations such as logical AND/OR or XOR. In at least one embodiment, an arithmetic logic unit is stateless and consists of physical circuitry, such as semiconductor transistors, arranged to form logical gates. In at least one embodiment, an arithmetic logic unit may operate internally as a stateful logic circuit with an associated clock. In at least one embodiment, an arithmetic logic unit may be constructed as an asynchronous logic circuit whose internal state is not maintained in an associated set of registers. In at least one embodiment, an arithmetic logic unit is used by one to combine operands stored in one or more registers of the processor and produce an output that can be stored by the processor in another register or memory location.

In at least one embodiment, as a result of processing an instruction fetched by the processor, the processor provides one or more inputs or operands to an arithmetic logic unit, causing the arithmetic logic unit to produce a result based at least in part on instruction code provided to the inputs of the arithmetic logic unit. In at least one embodiment, the instruction codes provided by the processor to the ALU are based at least in part on the instruction executed by the processor. In at least one embodiment, combinational logic in the ALU processes the inputs and produces an output that is placed on a bus within the processor. In at least one embodiment, the processor selects a destination register, memory location, output device, or output memory location on the output bus such that a clock of the processor causes the results produced by the ALU to be sent to the desired location.

Reference may be made herein to obtaining, acquiring, receiving, or inputting analog or digital data to a subsystem, computer system, or computer-implemented machine. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog and digital data may be accomplished in a variety of ways, such as by receiving data as a parameter of a function call or an application programming interface call. In some implementations, the process of obtaining, acquiring, receiving, or inputting analog or digital data may be accomplished by transmitting data over a serial or parallel interface. In another implementation, processes of obtaining, acquiring, receiving, or inputting analog or digital data may be accomplished by communicating data over a computer network from the providing entity to the acquiring entity. Reference may also be made to providing, outputting, transmitting, sending, or displaying analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or displaying analog or digital data may be performed by passing data as an input or output parameter of a function call, a parameter of an application programming interface, or an interprocess communication mechanism.

Although the above discussion sets forth exemplary implementations of the described techniques, other architectures may be used to implement the described functionality and are intended to be within the scope of this disclosure. Moreover, although specific distributions of responsibilities are defined above for purposes of discussion, various functions and responsibilities could be distributed and allocated differently depending on the circumstances.

Further, although the subject matter has been described in language specific to structural features and/or procedural acts, it is to be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or acts described. Rather, specific features and acts are disclosed as exemplary forms for implementing the claims.

The subject matter of the present disclosure is described herein in detail to satisfy legal requirements. However, the description itself is not intended to limit the scope of this disclosure. Rather, the inventors have contemplated that the claimed subject matter could be embodied in other ways to include other steps or combinations of steps similar to those described herein in connection with other present or future technologies. Furthermore, although the terms "step" and/or "block" may be used herein to refer to various elements of the methods used, the terms should not be construed to imply a particular order between or among various steps disclosed herein unless the order of each step is explicitly described.

Other variations are within the spirit of the present disclosure. Thus, while various modifications and alternative constructions may be made to the disclosed techniques, certain illustrated embodiments thereof are shown in the drawings and have been described in detail above. However, it is to be understood that there is no intention to limit the disclosure to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure as defined in the appended claims.

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions.

Cited patent literature

• IN202111034491 [0001]
• US17/477360 [0001]
• US 16101232 [0194]

Claims (48)

A system comprising: a memory operating in compliance with a first risk classification level; and circuitry operating in compliance with a second risk classification level indicating a higher risk classification than the first risk classification level, wherein the circuitry is operable to determine an error detection code for data to be written to a first memory address within the memory, determine a second memory address within the memory based at least in part on the first memory address, and cause the data to be stored in the first memory address and the error detection code to be stored in the second memory address. System according to Claim 1 wherein after storing the data in the first memory address and storing the error detection code in the second memory address: the circuitry is to obtain the data from the first memory address, obtain the error detection code from the second memory address, generate a check code based on the first memory address and the data obtained from the first memory address, and generate a notification if the error detection code indicates that the data contains at least one error. System according to Claim 2 , where the error detection code indicates that the data contains the at least one error if the error detection code does not match the check code. System according to Claim 2 , wherein the circuit arrangement serves to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access. System according to Claim 2 , further comprising: a first interface via which the data is obtained from the first memory address; and a second interface via which the error detection code is obtained from the second memory address in parallel with obtaining the data via the first interface, wherein the first interface is different from the second interface. System according to Claim 4 , wherein the circuit arrangement introduces a time delay between the first and the second memory access. System according to Claim 1 , wherein the memory comprises a first sub-area and a second sub-area, the first sub-area comprises the first memory address, the second sub-area comprises the second memory address, and the circuit arrangement serves to write a new error detection code into each memory address in the second sub-area during a start-up procedure. System according to Claim 1 , wherein the circuitry is operable to determine the error detection code based on the first memory address and the data before the data is written to a first memory address. System according to Claim 1 , wherein the circuit arrangement comprises a first and a second block, the first block is for transmitting a write request comprising the data and the first memory address to the second block, the second block is for receiving the write request, determining the error detection code, determining the second memory address and causing the data to be stored in the first memory address and the error detection code to be stored in the second memory address. System according to Claim 9 wherein the first block includes a write timer that starts when the first block transmits the write request to the second block, and the first block is operable to generate a write error when the write timer indicates that more than a predetermined amount of time has elapsed before the first block receives a response from the memory. System according to Claim 9 wherein, after the first block sends the write request: the first block is to send a read request to the second block for the data stored in the first memory address, and the second block is to receive the read request, obtain the data from the first memory address, obtain the error detection code from the second memory address, and transmit a notification to the first block when the second block determines that the error detection code indicates that the data contains the at least one error. System according to Claim 11 wherein the first block includes a read timer that starts when the first block sends the read request, and the first block is operable to generate a read error when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data. System according to Claim 1 , wherein the circuit arrangement serves to cause the data to be stored in the first memory address during a first memory access and the error detection code to be stored in the second memory address during a second memory access. System according to Claim 13 , wherein the circuit arrangement introduces a first time delay between the first and the second memory access. System according to Claim 1 located on a continuous piece of semiconductor material. System according to Claim 15 that implements a portion of a system on a chip (“SoC”) corresponding to an automobile. System according to Claim 1 , where the first and second risk classification levels are each an Automotive Safety Integrity Level (“ASIL”). System according to Claim 1 , where the error detection code is a check code with cyclic redundancy or an error correction code. A system comprising: a memory operating within a first risk classification level, the memory comprising an isolated memory region comprising a first memory address storing data and a second memory address storing an error detection code; and circuitry operating within a second risk classification level indicating a higher risk level than the first risk classification level, the circuitry operable to obtain the data from the first memory address, obtain the error detection code from the second memory address, and generate a notification when the error detection code indicates that the data contains at least one error. System according to Claim 19 , wherein the circuit arrangement serves to generate a check code based on the first memory address and the data obtained from the first memory address, the error detection code indicating that the data contains the at least one error if the error detection code does not match the check code. System according to Claim 19 , wherein the circuitry comprises a first and a second block, the first block is operable to send a read request for the data stored in the first memory address to the second block, and the second block is operable to receive the read request, obtain the data, obtain the error detection code, and generate the notification when the error detection code indicates that the data contains the at least one error. System according to Claim 21 , wherein the first block includes a read timer that starts when the first block sends the read request, and the first block is operable to generate an error if the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data. System according to Claim 21 wherein, before the first block sends the read request: the first block is to transfer the data and the first memory address to the second block, and the second block is to determine the error detection code, determine the second memory address, cause the data to be stored in the first memory address, and cause the error detection code to be stored in the second memory address. System according to Claim 23 wherein the first block includes a write timer that starts when the first block transfers the data and the first memory address to the second block, and the first block is operable to generate a write error when the write timer indicates that more than a first predetermined period of time has elapsed before the first block receives a response from the memory. System according to Claim 24 wherein the first block includes a read timer that starts when the first block sends the read request, and the first block is operable to generate a read error when the read timer indicates that more than a second predetermined period of time has elapsed before the first block receives the data from the memory. System according to Claim 19 , wherein the circuit arrangement serves to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access. System according to Claim 26 , wherein the circuit arrangement introduces a time delay between the first and the second memory access. System according to Claim 19 , wherein the circuit arrangement has written the error detection code into the second memory address during a start-up procedure. System according to Claim 19 located on a continuous piece of semiconductor material. System according to Claim 29 that implements a portion of a system on a chip (“SoC”) corresponding to an automobile. System according to Claim 19 , where the first and second risk levels are each an Automotive Safety Integrity Level (“ASIL”). System according to Claim 19 , where the error detection code is a check code with cyclic redundancy or an error correction code. A method performed by circuitry operating at a first risk classification level, the method comprising: determining an error detection code for data to be written to a first memory address within a memory operating at a second risk classification level indicating a lower risk level than the first risk classification level; determining a second memory address within the memory based at least in part on the first memory address; and causing the data to be stored at the first memory address and the error detection code to be stored at the second memory address. Procedure according to Claim 33 , further comprising: obtaining the data from the first memory address after the data is stored in the first memory address; obtaining the error detection code from the second memory address after the error detection code is stored in the second memory address; generating a check code based on the first memory address and the data obtained from the first memory address; and generating a notification when the check code indicates that the data contains at least one error. Procedure according to Claim 34 , wherein the error detection code was generated based on the first memory address and the data before the data was stored in the first memory address, and the check code indicates that the data contains the at least one error if the check code does not match the error detection code. Procedure according to Claim 33 , wherein the memory comprises a first sub-area and a second sub-area, the first sub-area comprises the first memory address, the second sub-area comprises the second memory address, and the method further comprises: writing a new error detection code to each memory address in the second sub-area during a start-up procedure. A method performed by circuitry operating at a first risk classification level, the method comprising: obtaining data from a first memory address of a memory operating at a second risk classification level indicating a lower risk level than the first risk classification level; determining a second memory address within the memory based at least in part on the first memory address; obtaining an error detection code from the second memory address; and generating a notification if the error detection code indicates that the data contains at least one error. Procedure according to Claim 37 , further comprising: generating a check code based on the first memory address and the data obtained from the first memory address; and determining whether the check code matches the error detection code, wherein the error detection code indicates that the data contains the at least one error if the error detection code does not match the check code. Procedure according to Claim 37 wherein the circuitry obtains the data from the first memory address during a first memory access, the circuitry obtains the error detection code from the second memory address during a second memory access, and the method further comprises: introducing a time delay between the first and second memory accesses. Procedure according to Claim 37 , wherein the circuitry comprises a first and a second block, and the method further comprises: sending a read request by the first block to the second block for the data stored in the first memory address; and receiving the read request by the second block, wherein the second block obtains the data, obtains the error detection code, and generates the notification if the error detection code indicates that the data contains the at least one error. Procedure according to Claim 40 wherein a read timer starts when the first block sends the read request, and the method further comprises: generating a read error by the first block when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data. Procedure according to Claim 40 , further comprising: transmitting a write request by the first block to the second block before the first block sends the read request, the write request comprising the data and the first memory address; determining the error detection code by the second block before the first block sends the read request; determining the second memory address by the second block before the first block sends the read request; and causing the second block to store the data in the first memory address and the error detection code to be stored in the second memory before the first block sends the read request. Procedure according to Claim 42 , wherein a write timer starts when the first block sends the write request, and the method further comprises: generating a write error by the first block if the write timer indicates that more than a first predetermined period of time has elapsed before the first block receives a response from the memory. Procedure according to Claim 43 wherein a read timer starts when the first block sends the read request, and the method further comprises: generating a read error by the first block when the read timer indicates that more than a second predetermined period of time has elapsed before the first block receives the data. Procedure according to Claim 42 wherein the second block causes the data to be stored in the first memory address during a first memory access, the second block causes the error detection code to be stored in the second memory address during a second memory access, and the method further comprises: introducing a time delay between the first and second memory accesses. Procedure according to Claim 37 , further comprising: writing the error detection code to the second memory address during a start-up procedure. Procedure according to Claim 37 , where the first and second risk classification levels are each an Automotive Safety Integrity Level (“ASIL”). Procedure according to Claim 37 , where the error detection code is a check code with cyclic redundancy or an error correction code.

Images