DE112022001192T5 - Isolating an area of a system on a chip for safety-critical operations - Google Patents

Abstract

In various examples, an integrated circuit has first and second sections that operate in separate areas. The second section has an interface that connects the first and second sections together. The second section selectively disables the interface to prevent communication with the first section via the interface and selectively unlocks the interface to enable communication with the first section via the interface.

Description

CLAIM TO PRIORITY

This application relies on Indian Provisional Application No. 202111034492 entitled "ISOLATING A REGION OF A SYSTEM ON A CHIP FOR SAFETY CRITICAL OPERATIONS" filed on July 30, 2021 and US Patent Application No. 17/477,214 entitled “ISOLATING A REGION OF A SYSTEM ON A CHIP FOR SAFETY CRITICAL OPERATIONS,” filed on September 16, 2021, the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

At least one embodiment relates to isolating a portion of a circuit operating at a higher level of risk from other portions of the circuit operating at a lower level of risk. For example, at least one embodiment relates to a system on a chip that implements various new methods described herein. In a further example, at least one embodiment relates to an autonomous vehicle that has such a system on a chip.

BACKGROUND

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

BRIEF DESCRIPTION OF THE DRAWINGS

• 1 ist eine Illustration einer beispielhaften Fahrzeug-Plattform gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 2 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung von (einer) beispielhaften Schnittstelle(n), die eine in einem Fahrzeug-SoC integrierte Sicherheitsinsel mit anderen Komponenten des Fahrzeug-SoCs verbindet;
• 3 ist ein Flussdiagramm, das ein Verfahren zum Übergang der Sicherheitsinsel zwischen einem Cocoon-Modus und einem Nicht-Isolations-Modus gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt.
• 4 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Illustration von (einer) beispielhaften Fehlerschnittstelle(n), die Fehler von den anderen Komponenten des Fahrzeug-SoC an die Sicherheitsinsel übertragen;
• 5A ist ein Flussdiagramm, das ein Verfahren zur Übermittlung von Fehlern an die Sicherheitsinsel gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
• 5B ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zeigt, das ein Prozessor verwenden kann, um von einem SoC-Fehleraggregator empfangene Interrupts zu verarbeiten;
• 5C ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zeigt, das die SI 110 verwenden kann, um Signale für korrigierte und unkorrigierte Fehler zu verarbeiten;
• 5D ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zeigt, das die SI 110 verwenden kann, um ein SoC-Fehleraggregatorsignal zu verarbeiten;
• 6A veranschaulicht gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein beispielhaftes Signalzeitdiagramm für Signale, die von dem Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit niedrigem Schweregrad (z. B. dem Mindestwert) aufgetreten ist;
• 6B zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein beispielhaftes Signalzeitdiagramm für Signale, die von dem Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit hohem Schweregrad (z.B. dem Maximalwert) aufgetreten ist;
• 6C zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein beispielhaftes Signalzeitdiagramm für Signale, die von dem Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit hohem Schweregrad (z.B. dem Maximalwert) aufgetreten ist, aber die Sicherheitsinsel keinen Mailbox-Interrupt empfängt;
• 7 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zum Schreiben von Daten in einen Carve-Out zeigt, der in einem flüchtigen Speicher definiert ist, der von der Sicherheitsinsel und den anderen Komponenten des Fahrzeug-SoC gemeinsam genutzt wird;
• 8 illustriert gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Beispiel eines Fehlererkennungsblocks der Sicherheitsinsel, der das Verfahren von 7 durchführt;
• 9 ist ein Flussdiagramm, das ein Verfahren zum Lesen von Daten aus dem Carve-Out gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt.
• 10 illustriert gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Beispiel eines Fehlererkennungsblocks der Sicherheitsinsel, der das Verfahren von 9 durchführt;
• 11 ist eine Illustration eines Blockdiagramms, das Fehlermeldungen zeigt, die von dem Fehlererkennungsblock erzeugt werden, wenn der Fehlererkennungsblock bei einigen Ausführungsformen Ausstiegs- und Einstiegs-Timer aufweist oder mit diesen verbunden ist;
• 12 ist eine Darstellung eines beispielhaften autonomen Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• FIG. ist 13 ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug aus 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 14 ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
• 15 ist ein Systemdiagramm für eine Kommunikation zwischen einem oder mehreren Cloud-basierten Servern und dem beispielhaften autonomen Fahrzeug aus 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung; und
• 16 ist ein Blockdiagramm eines Beispiels einer Rechenvorrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

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

• 1 is an illustration of an example vehicle platform in accordance with some embodiments of the present disclosure;
• 2 is an illustration of example interface(s) that connects a security island integrated in a vehicle SoC to other components of the vehicle SoC, according to some embodiments of the present disclosure;
• 3 is a flowchart depicting a method for transitioning the security island between a cocoon mode and a non-isolation mode in accordance with some embodiments of the present disclosure.
• 4 is an illustration of example fault interface(s) that communicate faults from the other components of the vehicle SoC to the safety island, according to some embodiments of the present disclosure;
• 5A is a flowchart depicting a method for communicating errors to the security island in accordance with some embodiments of the present disclosure;
• 5B is a flowchart illustrating a method that a processor may use to process interrupts received from an SoC error aggregator, according to some embodiments of the present disclosure;
• 5C is a flowchart illustrating a method that the SI 110 may use to process corrected and uncorrected error signals, according to some embodiments of the present disclosure;
• 5D is a flowchart illustrating a method that SI 110 may use to process an 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 security island processor after, according to some embodiments of the present disclosure an uncorrected error of low severity (e.g. the minimum value) occurred;
• 6B shows an exemplary signal timing diagram for signals received and transmitted by the security island processor after an uncorrected high severity error (e.g., the maximum value) occurs, according to some embodiments of the present disclosure;
• 6C shows, in accordance with some embodiments of the present disclosure, an exemplary signal timing diagram for signals received and sent by the security island's processor after an uncorrected high severity error (e.g., the maximum value) occurs but the security island does not receive a mailbox interrupt;
• 7 is a flowchart illustrating a method for writing data to a carve-out defined in a volatile memory shared by the security island and the other components of the vehicle SoC, according to some embodiments of the present disclosure;
• 8th illustrates, according to some embodiments of the present disclosure, an example of a safety island error detection block that implements the method of 7 carries out;
• 9 is a flowchart showing a method for reading data from the carve-out in accordance with some embodiments of the present disclosure.
• 10 illustrates, according to some embodiments of the present disclosure, an example of a safety island error detection block that implements the method of 9 carries out;
• 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 associated with exit and entry timers in some embodiments;
• 12 is an illustration of an example autonomous vehicle in accordance with some embodiments of the present disclosure;
• FIG. 13 is an example of camera positions and fields of view for the exemplary autonomous vehicle 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 12 according to some embodiments of the present disclosure;
• 15 is a system diagram for communication between one or more cloud-based servers and the exemplary autonomous vehicle 12 according to some embodiments of the present disclosure; and
• 16 is a block diagram of an example of a computing device suitable for use in implementing some embodiments of the present disclosure.

DETAILED DESCRIPTION

Systems and methods are disclosed that focus on isolating a portion of a circuit operating at a higher risk level (e.g., ASIL-D) from other portions of the circuit operating at a lower risk level (e.g., ASIL-B). For example, an area or "island" dedicated to functional safety may be separated from other components on a system on a chip ("SoC"), e.g. B. a vehicle SoC, (e.g. communicatively) isolated. 1 is an illustration of an example vehicle platform 100 according to at least one embodiment. The vehicle platform 100 may implement an autonomous or semi-autonomous vehicle, such as. B. an autonomous vehicle 1200 (see 12 ). The vehicle platform 100 includes a vehicle processing system 102 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 vehicle processing system 102 may implement Level 2 (partial driving automation) to Level 5 (full driving automation) according to the SAE definition. A Level 2 system may be referred to as an Advanced Driver Assistance System (“ADAS”).

The vehicle processing system 102 includes at least one vehicle SoC 104. The vehicle SoC 104 performs at least some functions, but may provide one or more security functions to an optional external control unit 106 (e.g., comprising an external ASIL-D microcontroller unit). The optional external control unit 106 may operate under and comply with a higher risk classification level (e.g., ASIL-D) than the vehicle SoC 104. In embodiments that include the optional external control unit 106, when an error occurs in the vehicle SoC 104, that error is communicated to the optional external control unit 106, which takes one or more actions can to put the vehicle platform 100 in a safe state. Thus, at least some of the security functions can be carried out by the optional external control unit 106. However, the optional external control unit 106 can cause latency and be expensive because it requires separate components such as DRAM, non-volatile memory, etc., each of which takes up space in the vehicle platform 100 (e.g., on a circuit board).

In order to avoid at least some of the latency and costs caused by the optional external control unit 106, the vehicle platform 100 of 1 a functional safety island or safety island (“SI”) 110 integrated into the vehicle SoC 104. The SI 110 may be implemented as a computing cluster that operates under and complies with a higher risk classification level (e.g., ASIL-D) compared to the rest of the vehicle SoC 104. The SI 110 may perform at least some of the functions normally performed by the optional external control unit 106. The presence of the SI 110 allows the optional external control unit 106 to be omitted entirely or implemented with a less sophisticated and/or less expensive external control unit. For example, if the optional external control unit 106 is present, it may perform one or more legacy functions, such as: B. providing communication on a Controller Area Network bus (“CAN” bus), providing reset control for the vehicle SoC 104 and/or performing on-board voltage monitoring.

In addition to the vehicle SoC 104 and the optional external control unit 106 (if present), the vehicle processing system 102 may include a first (SoC) clock 112 for the vehicle SoC 104, a second (SI) clock, or Clock 114 for the SI 110 and an integrated circuit (“IC”) 116 for the power supply. Each of the components of the vehicle processing system 102 is at least partially implemented in hardware. The logical components of the vehicle processing system 102 (e.g., the vehicle SoC 104 and the optional external control unit 106) are typically each implemented in logical hardware circuits within one or more integrated circuit chips. The logical components may be hardwired or programmable or a combination of hardwired and programmable elements. Additionally or alternatively, certain functions of the 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, respectively, provide two separate clock signals to the vehicle SoC 104. In particular, a first clock signal generated by the first (SoC) clock 112 is sent to other components 160 of the vehicle SoC 104 as the SI 110 is supplied, and a second clock signal generated by the second (SI) clock 114 is supplied to the SI 110. Thus, the SI 110 and the other components 160 may be referred to as operating in separate clock domains. The clock range of the SI 110 is referred to as the SI clock range and the clock range of the other components 160 is referred to as the SoC clock range. The first and second clock generators 112 and 114 can each be implemented at least partially as crystal oscillators. The first (SoC) clock 112 may have a first clock connection (not shown), such as. B. a line, a signal trace, and the like, may be connected to each of the other components 160 of the vehicle SoC 104. Thus, the first (SoC) clock 112 may provide the first clock signal to the other components 160 of the vehicle SoC 104 via the first clock connection (not shown). The second (SI) clock 114 may be connected to each of the components of the SI 110 via a second clock connection (not shown), such as. B. a wire, a signal track 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 IC 116 provides power to other components of the vehicle processing system 102. For example, power rails or connections 118A-118C connect the power supply IC 116 to the other components 160 of the vehicle SoC 104, the SI 110, and the optional external control unit 106, respectively. The power connections 118A-118C help power the other components 160 of the vehicle -SoC 104, the SI 110 or the optional external control unit 106 (if present) to be electrically isolated from each other. This allows the SI 110 to operate in a voltage range separate from the other components 160 and the optional external control unit 106 (if present). The voltage range of the SI 110 is referred to as the SI voltage range and the voltage range of the other components 160 is referred to as the SoC voltage range. The power supply IC 116 may be implemented as one or more integrated circuits that provide sufficient power to the components of the vehicle processing system 102. The power connections 118A-118C can each be used as a conductive element, such as. B. an electrical transmission line, a wire, a power line and the like may be implemented.

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

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

The optional external control unit 106 may include a controller 130, an error aggregator 132, a volatile data memory or memory 136 (e.g., a DRAM), and a non-volatile data memory or memory 138. The optional external controller 106 may also include one or more logic blocks (not shown) that implement the security functions performed by the optional external controller 106. The controller 130 may be implemented as one or more processors (e.g., microcontrollers) operating under ASIL-D. The controller 130 executes instructions such as: B. Instructions that conform to one or more Automotive Open System Architecture (“AUTOSAR”) software standards and are stored in non-volatile memory 138. The instructions may instruct the controller 130 to take appropriate action when the error aggregator 132 receives an error from the vehicle SoC 104.

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

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

The mailbox(es) 156 may include a first mailbox that the processor 150 writes to and from which the processor 140 reads, and a second mailbox that the processor 140 writes to and reads from. The mailbox(es) 156 may be used by the processor 150 (e.g., a central processing unit (“CPU”) of ASIL-B or higher level) to report mailbox interrupts to the interrupt controller 141 and interrupts from the interrupt controller 141. Therefore the error interface(s) shows 172 at least one signal conductor that connects the mailbox(es) 156 to the interrupt control 141. Each mailbox interrupt has a severity identifier that indicates the severity of the error. 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 that is pre-coded to indicate severity. The processor 140 and/or the processor 150 may write error information to the mailbox(es) 156. The error information includes information about the error(s) that generated the error, such as: B. the name(s) of the logic block in which the error(s) occurred, the logic block diagnostic identifier(s), the type of error, the severity identifier, and the like.

The integration of the SI 110 into the vehicle SoC 104 may allow a number of separate components (e.g., volatile memory 136 and non-volatile memory 138) to be omitted from the vehicle processing system 102 when the optional external Control unit 106 is also omitted. However, it is necessary to separate the SI 110 from the other components 160 (e.g., the main CPU complex 120, the auxiliary security unit 122, the circuit 124, the volatile memory 126 and the non-volatile memory 128) of the vehicle SoC 104 isolate so that potential problems occurring in one or more of the other components 160 do not negatively impact the SI 110. For example, such isolation may prevent the SI 110 from being affected by a failure in one or more of the other components 160 of the vehicle SoC 104. Non-limiting examples of the types of failures that may occur in one or more of the other components 160 include random errors, timing problems, performance problems, and/or voltage problems. Due to the spatial proximity and one or more interfaces 200 (see 2 ), which the SI 110 shares with the other components 160 of the vehicle SoC 104, such failures can propagate to the SI 110 and prevent the SI 110 from executing the fallback and/or failsafe functionality for which the SI 110 was integrated into the vehicle SoC 104. Therefore, the vehicle processing system 102 isolates the SI 110 from the other components 160 of the vehicle SoC 104 to achieve isolation comparable to that between the vehicle SoC 104 and the optional external control unit 106. Such isolation may be achieved by the first and second clocks 112 and 114, respectively, 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., has a separate reference crystal), which helps separate the SI 110 from the other components 160 of the vehicle SoC 104 isolate. Likewise, the first power connection 118A is separated from the second power connection 118B, which helps isolate the SI 110 from the other components 160 of the vehicle SoC 104. As previously mentioned, the SI 110 may operate in a separate SI voltage range from the other components 160 of the vehicle SoC 104. However, even with the separate second (SI) clock 114 and the separate second power connection 118B, the SI 110 communicates with the other components 160 of the vehicle SoC 104 via the interface(s) 200 (see 2 ).

The logic block(s) 148 includes a clock and reset circuit 230 (see 2 ) connected to the dedicated second (SI) clock 114. The dedicated second (SI) clock 114 can be used as a reference clock for the clock and reset circuit 230. For example, the clock and reset circuit 230 may include an internal dedicated phase locked loop (“PLL”) that is used to derive other functional and debugging clocks of the SI 110. As non-limiting examples, the clock and reset circuit 230 may provide a debug clock signal and a test clock signal that may be derived from the PLL. The clock and reset circuit 230 can generate all clock and reset signals used within the SI 110. In other words, the clock and reset circuit 230 may generate the clock signal(s) and reset signal(s) used within the SI range. 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(s) and/or the clock signal provided by the second (SI) clock 114. No clock signals or resets from the other components 160 are used in the SI 110. The clock and reset circuit 230 helps prevent interference from the logic (e.g., reset blocks) that generates resets within the other components 160 from reaching the components of the SI 110.

2 is an illustration of the interface(s) 200 that connects the SI 110 to the other components 160 of the vehicle SoC 104, according to at least one embodiment. Referring to 2 the interface(s) 200 provides a logi provides physical isolation for the circuitry and logic of the SI 110 in the vehicle SoC 104. In the illustrated embodiment, the interface(s) 200 includes the error interface(s) 172, a volatile memory interface 200A, a first control backbone interface 200B, a second control backbone interface 200C, a secure interface Contents 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 include one or more voltage level shifters 240, each providing electrical isolation between the SI and the SoC voltage range. While the voltage level shifter(s) 240 each provide electrical isolation, the voltage level shifter(s) 240 may be suitable for some types of faults, such as: B. Interrupt storms, error storms and/or continuous assertions do not provide adequate isolation. The SI error aggregator 142 may include one or more status bits 242 that receive error information via the error interface(s) 172 and inform the instructions 149 executed by the processor 140 of such errors. In the illustrated embodiment, the status bits 242 have the status bits “BT1”, “BT2” and “BT3” (see 4 ). Instructions 149 instruct processor 140 to use this notification to minimize failures occurring on fault interface(s) 172.

The volatile memory interface 200A is an interface between the processor 140 and the volatile memory 126 of the vehicle SoC 104. The volatile memory interface 200A allows the processor 140 to write information to the volatile memory 126 and information from the read volatile memory 126. The volatile memory interface 200A includes one or more connections to the volatile memory 126, such as: B. a line, a signal track and the like. The volatile memory interface 200A may include the logical isolation controller 220, an access timer 222, and an area synchronization circuit 224. The logical isolation controller 220 includes a gating or locking mechanism that can be selectively locked and unlocked by the processor 140. The access timer 222 allows a timeout on an access attempt initiated by the processor 140.

The range synchronization circuit 224 includes a phase synchronization circuit and one or more voltage level shifters. The phase synchronization circuit helps to synchronize the phases of signals communicated across the SI and SoC domains that were generated using the separate first and second clocks 112 and 114 (see 1 ). Resets generated by the clock and reset circuit 230 can be used by all elements that pass the SI and SoC voltage and clock ranges, such as: B. from the phase synchronization circuit. The phase synchronization circuit has an SoC section and an SI section, each of which can act as a separate synthesis top. The SoC section is physically located in the SoC area and the SI section is physically located in the SI area. The logic of both the SI and SoC sections uses resets generated by the clock and reset circuit 230. Thus, the resets generated by the SI 110 may be used by the logic of the vehicle SoC 104, which may operate under a lower ASIL than the SI 110, but the resets generated by the vehicle SoC 104 are not communicated to the SI 110 and cannot be used by them. As a non-limiting example, the phase synchronization circuit may be implemented as a split first-in-first-out (“FIFO”) or similar. The voltage level shifter(s) of the range synchronization circuit 224 may be substantially identical to the voltage level shifter(s) 240 and may adjust the voltage of the signals transmitted across the SI and SoC voltage ranges so that the signals are safely included in the SI and SoC voltage ranges. area can be transferred. When the access timer 222 indicates that an access by the processor 140 has timed out, the request may be removed from the range synchronization circuit 224 (e.g., popped from the split FIFO).

When the volatile memory interface 200A is unlocked, the processor 140 can access the volatile memory 126, thereby starting 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 error, uses the logical isolation controller 220 to reset the volatile memory interface 200A To lock memory, optionally locks any of the interface(s) 200 that are not locked, and optionally performs one or more measures designed to ensure that the vehicle platform 100 (see 1 ) returns to a safe state. On the other hand, 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 locks the interface 200A of the volatile memory after access is terminated is closed. In this way, the volatile memory interface(s) 200A remains locked whenever the processor 140 is not accessing the volatile memory 126, helping to protect the SI 110 from errors and/or failures caused by the volatile memory 126 to the SI 110.

The first and second control backbone interfaces 200B and 200C, respectively, 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 between the processor 140 and the control backbone 210, and the second control backbone interface 200C is for communication between the control backbone 210 and the processor 140. As a non-limiting example, the processor 140 accesses 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 vehicle SoC 104 via the control backbone 210.

The first control backbone interface 200B allows 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 area synchronization circuit 224, and a firewall 226. The logical isolation controller 220 of the first control backbone interface 200B is substantially identical to and functions substantially identically to the logical isolation controller 220 of the volatile memory interface 200A. Thus, to logically isolate the first control backbone interface 200B, the controller 220 allows the processor 140 to lock and unlock the first control backbone interface 200B. The access timer 222 of the first control backbone interface 200B allows an access attempt initiated by the processor 140 to time out. The area synchronization circuit 224 of the first control backbone interface 200B is substantially identical to the area synchronization circuit 224 of the volatile memory interface 200A and functions essentially the same. 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 allows 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 range synchronization circuit 224, and the firewall 226. The logical isolation controller 220 of the second control backbone interface 200C is substantially identical to and functions substantially identically to the logical isolation controller 220 of the volatile memory interface 200A. Thus, to logically isolate the second control backbone interface 200C, the controller 220 allows the processor 140 to lock and unlock the second control backbone interface 200C. The area synchronization circuit 224 of the second control backbone interface 200C is substantially identical to and functions essentially the same as the area synchronization circuit 224 of the volatile memory interface 200A. 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).

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

The debug interface 200E is an interface between the processor 140 and the debug circuit 214. The debug interface 200E allows the processor 140 to receive instructions and/or information from the debug circuit 214. The debug interface 200E may include the logical isolation controller 220 and the range synchronization circuit 224. The logical isolation control 220 of the debug interface 200E is essentially identical to the logical isolation control 220 tion of the volatile memory interface 200A and functions essentially identically to it. Thus, to logically isolate the debug interface 200E, the controller 220 allows the processor 140 to lock and unlock the debug interface 200E. The range synchronization circuit 224 of the debug interface 200E is substantially identical to and functions substantially identically to the range synchronization circuit 224 of the volatile memory interface 200. As mentioned above, the SI 110 and the other components 160 operate in separate clock domains. In such embodiments, no signals are received from an external clock of one or more of the other components 160 of the vehicle SoC 104, such as. B. the debug circuit 214, fed into the SI 110. The debug functions performed by the vehicle SoC 104 receive the debug clock signal via the range synchronization circuit 224 of the debug interface 200E, which responds to the debug functions performed by the vehicle SoC 104 using the signal provided by the SI 110 and/or the second (SI) clock 114 switches or converts generated debug clock signal. Since the debug logic is not used while the SI 110 is in the deployment mode (e.g., when the vehicle is running), the SI 110 includes a first clock gate for the debug clock to prevent interference that may occur could 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 circuit 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 the test circuit 216. The test interface 200F allows the processor 140 to receive instructions and/or information from the test circuit 216. The test interface 200F may include the logical isolation controller 220 and the range synchronization circuit 224. The test interface 200F logical isolation controller 220 is substantially identical to and functions substantially identical to the volatile memory interface 200A logical isolation controller 220. Thus, to logically isolate the test interface 200F, the controller 220 allows the processor 140 to lock and unlock the test interface 200F. The range synchronization circuit 224 of the test interface 200F is substantially identical to and functions substantially identically to the range synchronization circuit 224 of the volatile memory interface 200A. As noted, this configuration prevents external signals from one or more of the other components 160 of the vehicle SoC 104, such as. B. the test circuit 216, into which SI 110 are fed. The test functions performed by the vehicle SoC 104 receive the test clock signal via the range synchronization circuit 224 of the debug interface 200E, which responds to the test functions performed by the vehicle SoC 104 using the signal provided by the SI 110 and/or the second (SI) clock 114 generated test clock signal switches or converts. Since the test logic is not used while the SI 110 is in the deployment mode (e.g., when the vehicle is running), the SI 110 includes a second clock gate for the test clock to prevent any interference that may be caused by the test clock signal could be caused. As a non-limiting example, the second clock gate may be a component of the clock and reset circuit 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 can have at least two operating modes, an isolated or cocoon mode and a non-isolated mode. When the SI 110 is operating in the cocoon mode, the only information that is allowed to enter the SI 110 from the vehicle SoC 104 is error information that enters the SI 110 via the error interface(s) 172. In this way, the SI fault aggregator 142 maintains a cumulative health status of the vehicle SoC 104 and the SI 110 up to date. On the other hand, when the SI 110 is operating in non-isolated mode, information about one or more of the interfaces 200 can be included in reach the SI 110. Whether the SI 110 operates in the cocoon mode or the non-isolated mode is determined at least in part by the 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 in the other components 160 of the vehicle SoC 104 from reaching the SI 110 via one or more of the interfaces 200, each of the interfaces 200 has the separate controller 220 for logical isolation, which is selectively locked and unlocked by the processor 140. When the logic isolation controller 220's locking mechanism is locked by the processor 140, the locking mechanism prevents any communication between the vehicle SoC 104 and the SI 110 over the locked interface. On the other hand, the interface may be unlocked by the processor 140 to enable such communication over the unlocked interface. So the processor 140 can optionally put the SI 110 in the Cocoon mode or put into non-isolated mode. When all interfaces 200 are disabled, processor 140 cannot access either volatile memory 126 or non-volatile memory 128 and executes instructions 149 stored in volatile memory 146 (e.g., SRAM) in SI 110 .

Now with reference to 3 Each block of a method 300, as described herein, includes a computing method that can be performed with any combination of hardware, firmware and/or software. For example, various functions can be performed by a processor (e.g. the one in the 1 , 2 and 4 processor 140 shown) are executed, the instructions (e.g. those in the 1 , 2 and 4 instructions 149 shown) which are stored in a memory (e.g. that in the 1 , 2 and 4 shown volatile memory 146) are stored. The method 300 may also be embodied in the form of computer-usable instructions stored on computer storage media. Method 300 may be provided as a standalone application, as a service or hosted service (standalone or in combination with another hosted service), or as a plug-in for another product, to name just a few examples. In addition, the method 300 is exemplary for the vehicle platform 100 of 1 described. However, method 300 may additionally or alternatively be performed by any system or combination of systems, including but not limited to the systems described herein.

3 is a flowchart depicting the method 300 for transitioning the SI 110 between cocoon and non-isolated modes, according to some embodiments of the present disclosure. For ease of illustration, method 300 is described as if it were executed by processor 140 (see 1 , 2 and 4 ). With reference to 3 the processor 140 determines in a first block 302 that it is connected to one of the other components 160 (see 1 and 2 ) of the vehicle SoC 104 must communicate. This communication may occur, for example, via the volatile memory interface 200A or the first control backbone interface 200B, each of which allows the SI 110 to initiate communication with the other components 160 of the vehicle 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 allows the SI 110 to be informed by the other components 160 of the vehicle Receive SoC 104 initiated communications. As mentioned above, communication occurs via the error interface(s) 172 (see 2 ) regardless of whether the SI 110 is in cocoon mode or non-isolated mode.

Whenever the processor 140 needs to communicate with a particular one of the other components 160 of the vehicle SoC 104, the processor 140 checks whether communication with the particular component is secure before attempting to do so. To make this check, the processor 140 may, in block 304, check the contents of the SI error aggregator 142, which is available via the error interface(s) 172 (see 2 ) Receives error information from the SoC error aggregator(s) 152 that is external to the SI 110. As previously mentioned, the fault interface(s) 172 is not logically isolated from the SoC fault aggregator(s) 152, but rather passes through the voltage level shifter(s) 240, which provides electrical isolation between the SI and SoC Provide/provide voltage range, or have these.

In query block 306, processor 140 determines whether any errors have been detected in SI error aggregator 142. The answer at query block 306 is “YES” if at least one fault has been detected, meaning that a fault identified for one or more of the other components 160 has been passed from the SoC fault aggregator(s) 152 to the SI fault aggregator 142 was reported. The processor 140 can detect the error based on the status bits 242 within the SI error aggregator 142. The status bits 242 may be labeled to track the health of the vehicle SoC 104. Alternatively, the SI error aggregator 142 may inform the processor 140 of the error by sending an interrupt to the processor 140. Otherwise, the answer in query block 306 is “NO” if no error is detected.

If the answer in query block 306 is “YES,” the processor 140 may take one or more corrective actions in block 308. The corrective action(s) may help return the vehicle to a safe condition. As non-limiting examples, such corrective actions may include applying the vehicle brakes, reducing the vehicle speed, pulling the vehicle to the side of the road, and the like. Then the processor 140 can return to block 304.

If the answer in query block 306 is "NO", then in block 310 the processor 140 unlocks the locking mechanism of the controller 220 to logically isolate a particular one of the controllers 220 interface(s) 200 associated with a specific component if the locking mechanism of the specific interface was locked. In other words, when the SI error aggregator 142 does not store an error, the processor 140 may determine that it is safe to access the particular component of the vehicle SoC 104 via the particular interface. Therefore, in block 310, the processor 140 unlocks the particular interface.

Then, in block 312, the processor 140 may send or receive messages to the particular component via the unlocked particular interface, which automatically starts the particular interface's access timer 222. When the particular interface is unlocked, the processor 140 may initiate one or more strictly ordered accesses (one at a time) on the vehicle SoC 104. The access timer 222 starts automatically for each access. Thus, the access timer 222 may begin counting down as soon as a particular access is initiated by the processor 140.

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

If the answer in query block 314 is “YES,” processor 140 indicates in block 316 that a security error has occurred. Then, in block 318, the processor 140 disables the locking mechanism of the controller 220 to logically isolate the particular interface, optionally disables the locking mechanism of the controller 220 to logically isolate each of the other interface(s) that is not locked, and optionally executes one or more actions designed to return the vehicle platform 100 to a safe state.

On the other hand, if the answer in query block 314 is “NO”, the processor 140 completes the communication in block 320. The access timer 222 is automatically reset. Then, in block 318, the processor 140 disables the locking mechanism of the respective interface. In this way, the method 300 ensures that the interface(s) 200 remains locked whenever the processor 140 is not accessing any of the other components 160 of the vehicle SoC 104. Then the procedure 300 is ended.

The SI 110 can avoid access to the shared non-volatile memory 128 by transferring the instructions 149 (e.g., critical instructions that bring the system to a safe state) from the shared non-volatile memory 128 to its internal volatile memory 146 copied when the vehicle SoC 104 boots up. The processor 140 may authenticate and validate the instructions 149 before the SI 110 enters a deployment mode that enables a vehicle drive cycle. The SI 110 can operate simultaneously in deployment mode and either cocoon mode or non-isolated mode. Instructions 149 remain in volatile memory 146, allowing processor 140 to avoid accessing shared non-volatile memory 128. Non-critical data, e.g. B. Application code, fusion data, etc., can be from the shared volatile memory 126 using an internal (Direct Memory Access) DMA engine 402 (see 4 ), which is contained in SI 110, can be retrieved. The DMA engine 402 may optionally be a component of the processor 140. A failure of the DMA engine 402 does not adversely affect the processor 140 because even if the DMA engine 402 fails while swapping data from the shared volatile memory 126, the processor 140 executes the instructions stored in the volatile memory 146 149 further out.

4 is an illustration of the error interface(s) 172 according to some embodiments of the present disclosure. With reference to 4 The logic blocks LB(1) - LB(N) of the vehicle SoC 104 can each be assigned to the first error aggregators 260-1 to 260-N. The first error aggregators 260-1 to 260-N aggregate errors generated by the logic blocks LB(1) to LB(N) and transmit first aggregated error signals to the auxiliary safety unit 122 of the vehicle SoC 104. The auxiliary safety unit 122 implements the ( the second SoC error aggregator(s) 152 aggregating the first aggregated error signal(s) received from the first error aggregators 260-1 to 260- N has been received and transmits one or more second aggregated error signals to the optional external control unit 106 (see 1 ), if available. If the optional external control unit 106 is notified of a failure by the second aggregated error signal(s), the optional external control unit 106 may take one or more actions from a range of possible actions. First, the optional external control unit 106 can clear the error. Second, the optional external control unit 106 may take corrective action. Third, the optional external control unit 106 can notify an external system (e.g. B. one or more external microcontrollers, one or more external agents and the like). However, as previously mentioned, in some embodiments the optional external controller 106 may not be present.

Referring to 1 Although the SI 110 is isolated from the other components 160 of the vehicle SoC 104, as described above, at least some communication between the SI 110 and the other components 160 of the vehicle SoC 104 must be possible. In particular, errors that occur in the logic blocks LB(1) through LB(N) of the vehicle SoC 104 must be communicated to the SI 110 via the error interface(s) 172. One method of providing such communication would be for the first error aggregators 260-1 to 260-N (see 4 ) send the first aggregated error signals directly to the SI 110. This requires that the fault interface(s) 172 have a separate transmission line or signal conductor between the SI 110 and each of the first fault aggregators 260-1 to 260-N, which is achieved by isolating the SI 110 from the other components 160 of the vehicle SoC 104 is made more difficult. For example, the voltage level sliders 240 (see 2 ) have a separate voltage level slider for each signal conductor. In addition, the greater the number of signal conductors between the SI 110 and the other components 160 of the vehicle SoC 104, the more susceptible the SI 110 is to interference emanating from the vehicle SoC 104.

Instead, as in 4 As shown, each of the SoC error aggregators 152 may be connected to the SI 110 via three signal conductors: (1) a corrected error signal conductor 410; (2) an uncorrected error signal conductor 412; and (3) a SoC fault aggregator signal conductor 414. This arrangement may allow the fault interface(s) 172 to report faults from logic blocks LB(1) through LB(N) to the SI 110 without the fault interface(s). n) 172 has so many conductors that the conductors cause electrical interference, and without causing the fault interface(s) 172 to become so large that they cause overloading of the SoC 104 and/or the SI 110. Signal conductors 410, 412, and 414 may set status bits “BT1,” “BT2,” and “BT3,” respectively, each of which, once set, may subsequently be cleared by processor 140.

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

5A is a flowchart illustrating a method 500 for communicating errors to the SI 110 (see 1 , 2 , 4 , 8th and 10 ) according to some embodiments of the present disclosure. As described herein, each block of the method 500 in 5A a computing method that can be performed with any combination of hardware, firmware and/or software. For example, various functions can be performed by a processor (e.g. the one in the 1 and 4 processor 150 shown), which executes instructions stored in memory. At least portions of the method 500 may be embodied as computer-usable instructions stored on computer storage media. Method 500 may be provided through a standalone application, service, or hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. In addition, the method 500 is exemplified with respect to the vehicle platform 100 of 1 described. However, method 500 may additionally or alternatively be performed by any system or combination of systems, including but not limited to the systems described herein.

For simplicity, method 500 is described as being executed by a particular SoC fault aggregator 152 (see 1 , 2 and 4 ). In other words, method 500 may be performed by hardware. With reference to 5A In a first block 502, the particular SoC error aggregator receives first aggregated error signals from at least a portion of the first error aggregators 260-1 to 260-N (see 2 and 4 ).

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

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

In query block 514, the designated SoC error aggregator determines whether the first corrected error was cleared by the designated SoC error aggregator. The answer in query block 514 is “YES” if the first corrected error was cleared before the corrected error timer 420C (see 4 ) indicates that a second predetermined period of time has elapsed. Otherwise, the answer in query block 514 is “NO”. If the answer in query block 514 is “YES”, the respective SoC fault aggregator takes no action in block 515. However, if the answer in query block 514 is “NO”, the special SoC error aggregator proceeds to query block 516.

In query block 516, the processor 150 determines whether the corrected error timer 420C (see 4 ) indicates that the second predetermined period of time has elapsed, meaning that the corrected error timer 420C has expired. The answer in query block 516 is “YES” when the second predetermined time period has expired. Otherwise, the answer in query block 516 is “NO”. If the answer in query block 516 is “YES”, the respective SoC error aggregator proceeds to block 518. Otherwise, if the answer in query block 516 is "NO", the designated SoC error aggregator returns to query block 514 to wait for the first corrected error to be cleared by processor 150. In this way, the respective SoC error aggregator continues to monitor whether the first corrected error has been cleared and whether the corrected error timer 420C has expired. If the first corrected error is cleared before the corrected error timer 420C expires, the respective SoC error aggregator takes no action in block 515. However, if the corrected error timer 420C expires before the first corrected error is cleared, the SoC error aggregator proceeds to block 518. In block 518, the designated SoC fault aggregator sends the SoC fault aggregator signal over the SoC fault aggregator signal conductor 414 (see 4 ) to the SI 110 (see 1 , 2 , 4 , 8th and 10 ).

In block 520, the designated SoC error aggregator aggregates those of the first aggregated error signals received in block 502 that identify an error caused by an uncorrected error into an uncorrected error signal. Then, in block 522, the respective SoC error aggregator transmits the uncorrected error signal via the uncorrected error signal conductor 412 (see 4 ) to the SI 110 (see 1 , 2 , 4 , 8th and 10 ). In block 524, the respective SoC error aggregator sends an interrupt to the interrupt controller 154 for each uncorrected error (see 1 and 4 ), which sends the interrupt(s) to the processor 150 (see 1 and 4 ) of the auxiliary security unit 122 (see 1 and 4 ) forwards. Each interrupt notifies processor 150 of the uncorrected error associated with the interrupt.

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

In query block 528, the designated SoC error aggregator determines whether the first uncorrected error was cleared by the designated SoC error aggregator. The answer in query block 528 is “YES” if the first uncorrected error was cleared before the uncorrected error timer 420U (see 4 ) indicates that a third predetermined period of time has elapsed. Otherwise, the answer in query block 528 is “NO”. If the answer in query block 528 is “YES”, the respective SoC fault aggregator takes no action in block 529. If the answer in query block 528 is “NO”, the designated SoC fault aggregator proceeds to query block 530.

In query block 530, the processor 150 determines whether the uncorrected error timer 420U indicates that the third predetermined period of time has elapsed, meaning that the uncorrected error timer 420U (see 4 ) has expired. The answer in query block 530 is “YES” when the third predetermined time period has expired. Otherwise, the answer in query block 530 is “NO”. If the answer in query block 530 is “YES,” the respective SoC fault aggregator proceeds to block 532. However, if the answer in query block 530 is "NO", the respective SoC error aggregator returns to query block 528 to wait for the first uncorrected error to be cleared by the processor 150. In this way, the designated SoC error aggregator continues to monitor whether the first uncorrected error is cleared and whether the uncorrected error timer 420U has expired. If the first uncorrected error is cleared before the uncorrected error timer 420U expires, the SoC error aggregator takes no action in block 529. Conversely, if the uncorrected error timer 420U expires before the first uncorrected error is cleared, the SoC error aggregator proceeds to block 532. In block 532, the particular SoC error transmits ag gregator the SoC fault aggregator signal via the SoC fault aggregator signal conductor 414 (see 4 ) to the SI 110 (see 1 , 2 , 4 , 8th and 10 ). At this point, procedure 500 is completed.

5B is a flowchart showing a method 540 that the processor 150 (see 1 and 4 ) according to some embodiments of the present disclosure, may be used by the SoC error aggregator(s) 152 (see 1 , 2 and 4 ) to process received interrupts. As described herein, each block of method 540 includes: 5B a computing method that can be performed with any combination of hardware, firmware and/or software. For example, various functions may be performed 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. Method 540 may be provided through a standalone application, service, or hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. In addition, the method 540 is exemplified with respect to the vehicle platform 100 of 1 described. However, method 540 may additionally or alternatively be performed by any system or combination of systems, including but not limited to the systems described herein.

For convenience, method 540 is described as executed by processor 150 (see 1 and 4 ). With reference to 5B In the first block 541, the processor 150 receives a particular interrupt from a particular SoC error aggregator 152. Then, in block 542, the processor 150 triages or evaluates one or more errors identified at the particular interrupt and can one or more take corrective action to resolve the error(s).

If a problem occurs while the processor 150 is evaluating the errors and/or taking corrective action, the processor 150 may not be able to continue processing the particular interrupts. In this case, the answer in query block 543 is "YES", and in block 544 the processor 150 takes no further action on the particular interrupt. However, if the processor 150 is able to classify the particular interrupt and optionally take the corrective action(s), the answer in query block 543 is "NO". If the answer in query block 543 is "NO", then in block 545 the processor 150 writes information about the particular interrupt into the mailbox(es) 156, which can be read by the processor 140. Next, in block 546, the processor 150 sends a mailbox interrupt to the interrupt controller 141 over the mailbox interrupt signal conductor 416. The mailbox interrupt indicates the severity of the error identified in the interrupt received in block 541.

Then, in query block 547, processor 150 determines whether processor 150 should clear the error for which the particular interrupt was generated by the particular SoC error aggregator. The answer in query block 547 is “YES” if the processor 150 decides to clear the error. Otherwise, the answer in query block 547 is “NO”. The answer in query block 547 may be “YES” if the corrective action(s) taken by processor 150 corrected the error or the error was generated by a corrected error (e.g., by one of the Logic blocks LB(1) - LB(N) corrected errors). As another non-limiting example, the answer in query block 547 may be “YES” if processor 150 receives a mailbox interrupt from processor 140 indicating that processor 140 has corrected the error. If the answer in query block 547 is "NO", the processor 150 takes no further action on the particular interrupt in block 548. However, if the answer in query block 547 is “YES”, the processor 150 deletes the error from the respective SoC error aggregator in block 549. Processor 150 may notify processor 140 that the error has been cleared from the particular SoC error aggregator. Then the procedure 540 ends.

5C is a flowchart showing a method 550 that includes the SI 110 (see 1 , 2 , 4 , 8th and 10 ) according to some embodiments of the present disclosure to process the signals of corrected and uncorrected errors. As described herein, each block of method 550 includes: 5C a computing method that can be performed with any combination of hardware, firmware and/or software. For example, various functions can be performed by a processor (e.g. the one in the 1 , 2 and 4 processor 140 shown) are executed, the instructions (e.g. those in the 1 , 2 and 4 instructions 149 shown) which are stored in a memory (e.g. that in the 1 , 2 and 4 shown volatile memory 146) are stored. At least portions of the method 550 may be in the form of computer-usable, computer-stored memory be designed according to stored instructions. Method 550 may be provided through a standalone application, service, or hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. In addition, the method 550 is exemplified with respect to the vehicle platform 100 of 1 described. However, method 550 may additionally or alternatively be performed by any system or combination of systems, including but not limited to the systems described herein.

For simplicity, the method 550 is described as being performed by the SI error aggregator 142 (see 1 , 2 and 4 ) and the processor 140 (see 1 , 2 and 4 ) is performed. With reference to 5C the SI error aggregator 142 receives the SI 110 (see 1 , 2 , 4 , 8th and 10 ) in the first block 552, the signal of a corrected error that sets the status bit “BT1” and/or the signal of an uncorrected error that sets the status bit “BT2”. When the SI error aggregator 142 receives the corrected error signal on the corrected error signal conductor 410, the SI error 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 about the corrected error(s).

In query block 556, processor 140 (see 1 , 2 and 4 ) determines whether a mailbox interrupt is received from processor 150 (see 1 and 4 ) has been received via the mailbox interrupt signal conductor 416. When the mailbox interrupt is received, the mailbox interrupt displays the severity of the error that has been corrected. The answer in query block 556 is “YES” if the processor 140 has received the mailbox interrupt. Otherwise, the answer in query block 556 is “NO”. If the answer in query block 556 is "NO", the processor 140 waits in block 558 for receipt of either the mailbox interrupt or the SoC fault aggregator signal. If the answer in query block 556 is “YES”, the processor 140 proceeds to query block 560.

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

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

In query block 568, processor 140 determines (see 1 , 2 and 4 ), whether a mailbox interrupt from the processor 150 (see 1 and 4 ) has been received via the mailbox interrupt signal conductor 416. When the mailbox interrupt is received, the mailbox interrupt displays the severity of the uncorrected error. The answer in query block 568 is “YES” if the processor 140 has received the mailbox interrupt. Otherwise, the answer in query block 568 is “NO”. If the answer in query block 568 is "NO", the processor 140 waits in block 558 for receipt of either the mailbox interrupt or the SoC fault aggregator signal. If the answer in query block 568 is “YES”, the processor 140 proceeds to query block 570.

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

In query block 573, processor 140 decides whether one or more corrective actions should be taken. If the answer in query block 573 is "YES", the processor 140 takes the corrective action(s) in block 574, such as: B. the operation of the vehicle brakes. Then processor 140 proceeds to query block 575.

If the answer in query block 573 is “NO”, the processor 140 proceeds to query block 575. In query block 575, processor 140 decides whether to notify external system 404. If the answer in query block 575 is "YES", the processor 140 notifies the external system 404 in block 576 and proceeds to block 578. If the answer in query 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 resetting the status bit "BT2". Optionally, the processor 140 can write error information to the mailbox(es) 156. The processor 140 may wait for the processor 150 to be notified that the error corresponding to the uncorrected error has been cleared from the particular SoC error aggregator before the processor 140 clears the uncorrected error from the SI error aggregator 142. Then the procedure 550 is ended. The mailbox interrupt is received by processor 150 and can occur at response block 547 (see 5B) be used to decide whether the processor 150 should clear the error corresponding to the uncorrected error. The processor 150 may optionally read the error information written to the mailbox(es) 156 by the processor 140 before making this decision or response.

5D is a flowchart showing a method 580 that includes the SI 110 (see 1 , 2 , 4 , 8th and 10 ) may be used to process the SoC error aggregator signal according to some embodiments of the present disclosure. As described herein, each block of method 580 includes: 5D a computing method that can be performed with any combination of hardware, firmware and/or software. For example, various functions can be performed by a processor (e.g. the one in the 1 , 2 and 4 processor 140 shown) are executed, the instructions (e.g. those in the 1 , 2 and 4 instructions 149 shown) which are stored in a memory (e.g. that in the 1 , 2 and 4 shown volatile memory 146) are stored. At least portions of method 580 may be embodied as computer-usable instructions stored on computer storage media. Method 580 may be provided through a standalone application, service, or hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. In addition, the method 580 is exemplified with respect to the vehicle platform 100 of 1 described. However, method 580 may additionally or alternatively be performed by any system or combination of systems, including but not limited to the systems described herein.

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

As indicated by an arrow with a dashed line in it 5D is shown, if the SoC error aggregator 142 (see 1 , 2 and 4 ) receives the SoC error aggregator signal, the SoC error handling circuit 422 (see 4 ) the SI 110 automatically proceeds to block 584 and automatically sends a SoC error signal indicating a SoC error over connection 406 (see 4 ) to the external system 404 (see 4 ) send. Alternatively, the SoC error handling circuit 422 may proceed to block 586 and start an SoC error timer 424 (see 4 ). The SoC error timer 424 may cause a delay between receipt of the SoC error aggregator signal and notification to the external system 404. While the SoC error timer 424 is running, the processor 140 may take one or more corrective actions. If the corrective action(s) is successful, the processor 140 may clear the uncorrected error(s) by resetting the "BT2" status bit and clear the SoC error aggregator error by resetting the "BT3" status bit. Clearing the SoC error aggregator error stops the SoC error timer 424. The processor 140 may wait for notification from the processor 150 that the error(s) corresponding to the uncorrected error(s) will be cleared by the respective SoC error aggregator, before the processor 140 clears the uncorrected error(s) from the SI error aggregator 142.

After the SoC error timer 424 is started, the SoC error handling circuit 422 determines in query block 588 whether the SoC error timer 424 indicates that a fourth predetermined period of time has elapsed. The decision or answer in response block 588 is “YES” if the SoC error timer 424 indicates that the fourth predetermined period of time has elapsed and the SoC error aggregator error has not been cleared. On the other hand, the answer in query block 588 is "NO" if the SoC error aggregator error has been cleared before the SoC error timer 424 indicates that the fourth predetermined time period has elapsed.

If the answer in query block 588 is "NO", then in block 590 the SoC error handling circuit 422 waits for the SoC error timer 424 to indicate that the fourth predetermined period of time has elapsed. On the other hand, if the answer in query block 588 is "YES", then in block 584 the SoC error handling circuit 422 transmits the SoC error signal indicating the SoC error over connection 406 (see 4 ) to the external system 404 (see 4 ), indicating that the first uncorrected error has not been cleared and the SoC error aggregator error applies. The SoC error timer 424 is automatically paused and/or reset when the SoC error is sent. Alternatively, the SoC error handling circuit 422 may reset the SoC error timer 424 or the SoC error timer 424 may simply expire without the SoC error handling circuit 422 taking any action.

After the SI error aggregator 142 (see 1 , 2 and 4 ) has received the SoC error aggregator signal, the SI error aggregator 142 may send an interrupt to the processor 140 in block 592. In block 594, processor 140 evaluates the first uncorrected error. In query block or decision block 595, processor 140 decides whether one or more corrective actions should be taken. The answer in response block 595 is “YES” if the processor 140 decides to take one or more corrective actions. Otherwise, the answer in query block 595 is “NO”. If the answer in query block 595 is “NO,” processor 140 proceeds to block 596 and takes no action. However, if the answer in query 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 error aggregator error, for example by resetting the status bit "BT3", and the uncorrected error(s). Resetting the status bit “BT2”. Clearing the SoC error aggregator error stops the SoC error 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 implemented the corrective action(s). Block 597 carried out. Optionally, the processor 140 can write error information to the mailbox(es) 156. The processor 140 may wait for notification from the processor 150 that the error(s) corresponding to the uncorrected error(s) have been cleared by the particular SoC error aggregator before the processor 140 detects the SoC error aggregator error and deletes the uncorrected error(s) from the SI error aggregator 142. Then the procedure 580 ends. The mailbox interrupt is received by processor 150, which can clear the error corresponding to the uncorrected error. Processor 150 may optionally read the error information written to mailbox(es) 156 by processor 140 before clearing the error.

In the 5A-5D the vehicle SoC 104 has the processor 150. In at least some embodiments, processor 150 may be omitted. In such embodiments, method 540 is not performed. For each error, the respective SoC error aggregator generates the SoC error aggregator error (blocks 518 and 532) and sends it to the SI error aggregator 142. Since the processor 150 is not present, the mailbox interrupts are not sent to the interrupt controller 141 transmitted so that the processor 140 waits for the SoC error aggregator signal (block 558 in 5C ) before processor 140 takes action. Then when the SoC error aggregator error is received (block 582 of 5D ), the SI 110 dares to approach the other components 160 to carry out an evaluation (block 594 of 5D ) for each corrected and uncorrected error received in method 550 (see 5C ). If the evaluation is successful, the processor 140 carries out the corrective action(s) (block 597 of 5D ). However, if the evaluation is not successful, the processor 140 takes no action (block 596 of 5D ), which causes the SoC error handling circuit 422 to expire after the SoC error timer 424 (block 584 of 5D ) to send the SoC error (without any software intervention). The SoC error notifies 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), which allows the external system 404 to control the vehicle platform 100 (see 1 ) to a safe state.

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

Line 612A represents the uncorrected error signal transmitted from the uncorrected error signal conductor 412 (see 4 ) is routed to the SI error aggregator 142. A portion 622A of line 612A represents the occurrence of the uncorrected error. After receiving the uncorrected error signal (e.g., block 552 of 5C ), the SI error aggregator 142 sends an interrupt to the processor 140 (e.g., block 566 of 5C ).

In 6A the interrupt controller 141 then receives a mailbox interrupt (the response in query block 568 from 5C is “YES”). A portion 626A of line 614A represents the mailbox interrupt (sent from processor 150) indicating the severity of the uncorrected error. Since the mailbox interrupt indicates that the particular error is of low severity, the processor 140 decides to access the mailbox(es) 156 (e.g., the response is in query block 570 of 5C “YES”) and to read the contents of the mailbox(es) 156 (e.g. block 572 of 5C ). If the mailbox(es) 156 have error information (created by the processor 150) indicating that the particular error has been cleared, the processor 140 clears the particular error in the SI error aggregator 142 (e.g., block 578 of 5C ). If this occurs before the corrected error timer 420U expires, the SoC error aggregator(s) 152 will not report the SoC error aggregator error (e.g., block 529 of 5A) .

On the other hand, if the contents of the mailbox(es) 156 do not indicate that the processor 150 has cleared the particular error, the processor 140 may decide to take one or more corrective actions (e.g., the answer in query block 573 is 5C "YES"). If the corrective action(s) (e.g. in block 574 of 5C ) is successful, processor 140 may notify processor 150 to clear the error (or clear the error). For example, processor 140 may send a mailbox interrupt to processor 150 and/or write error information to 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 in the Mailbox(es) 156 stored error information). After receiving this notification, the processor 140 may clear the error, e.g. B. by resetting the status bit “BT2” (e.g. block 578 of 5C ). A portion 624A of line 612A represents a rollback of the uncorrected error after the processor 140 has read the mailbox(es) 156 and taken corrective action. A curved arrow 628A represents a delay between the time the processor 140 received the mailbox interrupt and the time the processor 140 rolled back the error (or cleared the error).

If the corrective action(s) were successful, the processor 140 may send a mailbox interrupt to the mailbox(es) 156 indicating that the processor 140 has cleared the particular error (e.g., block 578 of 5C ). Optionally, the processor 140 can write error information to the mailbox(es) 156. The processor 150 receives the mailbox interrupt, determines that the particular error has been corrected by the processor 140 (e.g., the answer in query block 547 is “YES”), and clears the particular error from the SoC error aggregator(s). (en) 152 (e.g. Block 549 of 5B) . If this occurs before the uncorrected error timer 420U expires, the SoC error aggregator(s) 152 does not report the SoC error aggregator error (e.g., block 529 of 5A) . Thus, the SoC error aggregator(s) 152 monitors the particular error to ensure that it has been handled by one of the processors 140 and 150, and if the particular error has not been corrected, before the uncorrected error timer 420U expires , the SoC fault aggregator(s) 152 notifies the SoC fault handling circuitry 422. As noted above, after clearing the error, processor 150 notifies processor 140 that the error has been cleared (e.g., via the uncorrected error signal, a mailbox interrupt, and/or in the error information stored in the mailbox(es) 156), and the processor 140 may clear the error in the SI error aggregator 142.

Line 616A represents the SoC error aggregation signal and indicates that the SoC error aggregation error was not reported. Thus, the uncorrected error(s) were cleared before the uncorrected error timer 420U expired.

Line 618A represents an SoC error signal that may be sent over connection 406 to external system 404 (e.g., optional external controller 106, one or more external microcontrollers, one or more external agents, and the like). Because the uncorrected error(s) have been handled and the SoC error aggregation error has not been reported, line 618A indicates that the SI 110 is not notifying the external system 404 of the uncorrected error(s) (e.g., the answer in query block 575 is “NO”).

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

Line 612B represents the uncorrected error signal transmitted from the uncorrected error signal conductor 412 (see 4 ) is routed to the SI error aggregator 142. A portion 622B of line 612B represents reporting an uncorrected error. After receiving the uncorrected error signal (e.g., block 552 of 5C ), the SI error aggregator 142 sends an interrupt to the processor 140 (e.g., block 566 of 5C ).

In 6B then the interrupt controller 141 receives the mailbox interrupt (e.g. the response is in query block 568 from 5C "YES"). A portion 624B of line 614B represents the mailbox interrupt indicating that the first uncorrected error is of high severity (e.g., seven). Because the mailbox interrupt indicates that the particular error is of high severity, the processor 140 decides not to access the mailbox(es) 156 (e.g., the response in query block 570 is from 5C "NO"). For example, the processor 140 may determine that it is too risky to access the other components 160 of the vehicle SoC 104 and that doing so could harm the SI 110. In 6B the processor 140 also decides not to take any corrective action(s) (e.g. the answer in query block 573 is from 5C "NO"). In 6B the uncorrected error is not reversed because the SI 110 is unable to carry out one or more corrective actions.

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. the response is in query block 575 of 5C "YES"). The processor 140 then sends the SoC error signal (e.g., block 576 of 5C ). So if in 6B If the severity of the error is high (e.g., the maximum value), the SI 110 may decide not to access the vehicle SoC 104, not to take corrective action, and instead notify the external system 404. Line 618B represents the SoC error signal sent from the SI 110 to the external system 404, and a portion 626B of line 618B represents the reporting of the SoC error. Line 616B represents the SoC error aggregation signal and does not indicate that a SoC error aggregation error has already been reported. Therefore, the SI 110 recognized that the uncorrected error had not been handled and decided to notify the external system 404 before reporting the SoC error aggregation error.

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

Line 612C represents the uncorrected error signal transmitted from the uncorrected error signal conductor 412 (see 4 ) is routed to the SI error aggregator 142. A portion 622C of line 612C represents an uncorrected error message. After receiving the uncorrected error signal (e.g., block 552 of 5C ), the SI error 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. So in this example, the interrupt controller 141 does not receive the mailbox interrupt (e.g. the answer in query block 568 is from 5C "NO"). This can e.g. This may be the case, for example, if the processor 150 has not completed the evaluation of the uncorrected error (e.g. block 542 of 5B) , which leads to (response in query block 543 of 5C is "YES") that the processor 150 does not send the mailbox interrupt (e.g. block 544 of 5B) . Therefore, the processor 140 waits to receive either the mailbox interrupt or the SoC error aggregator error, whichever occurs first (e.g., block 558 of 5C ).

A line 628C represents the third predetermined period of time and indicates that the uncorrected error timer 420U has expired. Since neither processor 140 nor processor 150 were able to clear the first uncorrected error, uncorrected error timer 420U expires (e.g., response in query block 530 of 5A is "YES"), which causes a particular one of the SoC error aggregators 152 that sent the uncorrected error signal to the SI 110 and the interrupt to the processor 150 to send the SoC error aggregator signal to the SI via the SoC error aggregator signal conductor 414 -Error aggregator 142 to be transmitted (e.g. in block 532 of 5A) . The SI error aggregator 142 receives the SoC error aggregator signal (e.g., in block 582 of 5D ). A portion 624C of line 616C represents the SI error aggregator error sent to the SI 110 from the respective SoC error aggregator. A curved arrow 630C represents a delay between the time the uncorrected error was received from the SI 110 and the time the SI error aggregator error was received from the SI 110.

After receiving the SI error aggregator signal (e.g., block 582 of 5D ), the SI error aggregator 142 sends an interrupt to the processor 140 (e.g., block 592 of 5D ). Then the processor 140 can evaluate the first uncorrected error (e.g. block 594 of 5D ) and decide whether corrective action needs to be taken. If the processor 140 is unable to take any corrective action (e.g., the answer in query block 595 is 5D “NO”), the SoC error handling circuit 422 sends the SoC error signal to the external system 404 (e.g., block 584 of 5C ). A portion 626C of line 612C represents the SoC error sent to the external system 404. In embodiments that use the SoC error timer 424, the SoC error is sent when the SoC error timer 424 expires. In 6C a line 632C indicates that the fourth predetermined time period has expired, meaning that the SoC error timer 424 has expired. A curved arrow 634C represents a delay between the time the SI 110 receives the SI error aggregator error and the time the SI 110 reports the SoC error. In this way, hardware in the SI 110 notifies the external system 404 that which will attempt to place the vehicle platform 100 in a safe state.

As already related to 2 As mentioned above, the SI 110 and the other components 160 of the vehicle 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 vehicle SoC 104 may operate within a lower second risk classification level . For example, the SI 110 may operate on ASIL-D, but the other components of the vehicle 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 on ASIL-B work.

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

The SI 110 includes an error detection block 272 that includes hardware located between other components of the SI 110 and the carve-out 250. Thus, error detection block 272 may be implemented as a component of volatile memory interface 200A. Alternatively, the error detection block 272 may be located 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 the processor 140 and the volatile memory interface 200A, respectively.

The hardware of the error detection block 272 may include a code generation sub-block 273 (see 8th ). The code generation subblock 273 may be implemented using a cyclic redundancy check (“CRC”) code generation circuit that generates a CRC code. Alternatively, error detection block 272 may include other types of code generation circuits that generate different types of error detection codes, such as: B. an error correction code (“ECC”). The error detection block 272 hardware 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 that passes through the error detection block 272. The error detection code can be calculated based on the byte and a data address in the carve-out 250 where the byte is to be stored. For example, Equation 1 below can be used to determine the error detection code for a particular byte of data to be written to carve-out 250: $${\text{crc\_out}}_{\text{Byte x}}=\text{CRC}\left(\text{Byte address}\text{, byte data}\right)$$

In Equation 1 above, a variable “crc_out _{byte x} ” represents the error detection code based on the byte represented by a variable “byte data” and the data address represented by a variable “byte address”. is calculated. 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_out _{byte x} ”. The output of the “CRC” function can be at least partially achieved by the code generation sub-block 273 (see 8th ) will be calculated if available.

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 can be used to determine the error detection code for a particular byte of data to be written to carve-out 250. $$\text{crc\_out\_address}=\text{Write address}+\text{fixed\_offset}$$

In Equation 2 above, the variable “crc_out_address” represents the code address that is calculated based on the data address of the byte, represented by the variable “write address,” and an offset represented by the variable “fixed_offset.” . As mentioned above, the carve-out 250 can be divided into subsections, with the first subsection 252 (see 8th ) the data and the second subsection 254 (see 8th ) stores the error detection codes. Thus, the data address represented by the "Byte Address" variable in Equation 1 above may be in the first subsection 252, and the code address represented by the "Write Address" variable in Equation 2 above may be in the second Subsection 254 is located. In such embodiments, the value of the fixed_offset variable may be equal to the size of the first subsection 252 of the carve-out 250 to ensure that the error detection codes are stored in the second subsection 254. In this way, address-based separation is used to separate the data from the error detection codes so that an error occurring in the first or second subsections 252 and 254, respectively, cannot affect the other.

The error detection block 272 introduces a delay (e.g., a few clock cycles) between storing the data at the data address(es) and storing the error detection code at the code address(es). This delay reduces the chance that an event (such as a transient event) that negatively impacts the data will also negatively impact the error detection code. In other words, the delay contributes to immunity against general errors and transient errors, which in turn provides protection against problems such as clock glitches. The error detection block 272 may buffer two or more bytes of data and the corresponding error detection codes before being stored in the carve-out 250. Then the error detection block 272 can the data bytes (e.g. 16 bytes) in the first subsection Store 252 followed by the delay. Next, the error detection block 272 may store the corresponding error detection codes (e.g., 16 bytes) in the second subsection 254.

Now with reference to 7 Each block of method 700, as described herein, includes a step that may be performed with any combination of hardware, firmware, and/or software. For example, method 700 may be performed by the hardware of error detection block 272 (see 2 , 8th and 10 ). As another non-limiting example, one or more functions may be provided by a processor (e.g., the one described in Figures 1 and 2). 1 , 2 and 4 processor 140 shown) are executed, the instructions (e.g. those in the 1 , 2 and 4 instructions 149 shown) which are stored in a memory (e.g. that in the 1 , 2 and 4 shown volatile memory 146) are stored. In such embodiments, at least portions of the method 700 may be embodied as computer-usable instructions stored on computer storage media. Method 700 may be provided through a standalone application, service, or hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. In addition, the method 700 is exemplary for the vehicle platform 100 of 1 described. However, method 700 may additionally or alternatively be performed by any system or combination of systems, including but not limited to the systems described herein.

7 is a flowchart showing the method 700 for writing data into the cutout or carve-out 250 (see 2 , 8th and 10 ) according to some embodiments of the present disclosure. For ease of illustration, method 700 is described as if it were from error detection block 272 (see 2 , 8th and 10 ) carried out. Before method 700 begins, an initiator (e.g., processor 140, DMA engine 402, or the like) operating in the SI area passes a first write instruction containing data and data address(es) to the Error detection block 272 continues. The initiator can write data of a predetermined size (e.g. 16 bytes) to the carve-out 250.

According to 7 the error detection block 272 receives (see 2 , 8th and 10 ) in the first block 702, the first write instruction containing the data and data address(es) from the initiator. In block 704, 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, 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 have only a single data address (e.g., a first address). Subsequent data addresses may be determined based on this 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 a portion of the data.

Then, in block 706, error detection block 272 determines an error detection code for the portion of data selected in block 704 (eg, using Equation 1 above). Next, 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 subsection 252 (see 8th and 10 ) of the Carve-Out 250 (see 2 , 8th and 10 ) further. According to the first write instruction, the carve-out 250 stores the section in the corresponding data address in the first subsection 252.

In the next block 710, the error detection block 272 determines (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., a few clock cycles) to send the error detection code to the first subsection 252 (see 8th and 10 ) of the Carve-Out 250 (see 2 , 8th and 10 ) to store it in the code address. Thus, in block 712, the error detection block 272 introduces a delay between storing the data at the data address and storing the error detection code at the code address. The error detection block 272 may include a write delay timer (not shown) that is 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 carve-out 250 for storage at the code address. Next, in block 714, the error detection block 272 directs a second write instruction having the error detection code determined in block 706 and the code address determined in block 710 to the second subsection 254 (see 8th and 10 ) of the Carve-Out 250 (see 2 , 8th and 10 ) further. The error takes effect in order to save the data Detection block 272 therefore accesses the carve-out 250 twice, once each in blocks 708 and 714. According to the second write instruction, the carve-out 250 stores the error detection code in the code address in the second subsection 254.

The error detection block 272 then determines (see 2 , 8th and 10 ) in the query block or decision block 716 whether any data has not been saved. The answer in query block 716 is “YES” if error detection block 272 determines that at least some of the data was not saved. Otherwise, the answer in query block 516 is “NO”. If the answer in query block 716 is “YES,” error detection block 272 returns to block 704 to select a new portion of the data. On the other hand, if the answer in query block 716 is "NO", error detection block 272 returns to block 702 to receive new data and new data address(es).

As noted above, error detection block 272 may buffer two or more bytes of data and their corresponding error detection codes before being stored in carve-out 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, error detection block 272 may perform block 706 on two or more bytes of data before sending the first write instruction to carve-out 250 in block 708 along with the data bytes and the corresponding data addresses. For example, the error detection block 272 may send the data bytes to the first subsection 252 along with a first data address. The first subsection 252 may write the data bytes to successive memory addresses starting with the first data address. Subsequently, 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 data bytes and writing the error detection codes to the carve-out 250. Then, in block 714, the error detection block 272 forwards the second write instruction, which includes the error detection codes and the code addresses, to the second subsection 254. The second subsection 254 writes the error detection codes into the code addresses. Depending on the implementation details, the second write instruction may have only a first code address, and the second subsection 254 may write the error detection codes to successive memory addresses starting with the first code address.

8th shows an example of the error detection block 272 that carries out the method 700 (see 7 ). The SI 110 may have one or more initiators 800, such as. B. the processor 140, the DMA engine 402 and the like, each operating within the SI range. In 8th the initiator(s) 800 includes an initiator 802 (e.g., processor 140). The initiator 802 (e.g., processor 140) may write data of a predetermined size (e.g., 16 bytes) to the carve-out 250. In the in 8th In the example shown, the initiator 802 sends 16 bytes of data and a first data address to the error detection block 272. The data is in 8th stored or represented by an array of 128 bits called "wdata_in[127:0]", and the first data address is in 8th stored or represented by an array of 40 bits called “Address_0[39:0]”. However, depending on the implementation details, the data may be of a different size, with 128 bits given as a non-limiting example. Similarly, the first data address can have other sizes; As a non-limiting example, 40 bits are given. The first byte of data can be stored at the first data address, then a next data address can be identified for a second byte of data by adding a byte to the first data address, and so on. 8th shows how the initiator 802 sends a first write instruction 804 over a security island connection 808 in a signal 806 to the error detection block 272. As mentioned above, the first write instruction 804 includes the data and the first data address. The security island connection 808 can be implemented as a bus or the like.

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

Next, code generation subblock 273 determines an error detection code for each byte of the data (e.g., block 706 of 7 ). In 8th are the signals that enable error detection codes, and a signal 838 carrying the responses of the carve-out 250 with respect to the error detection codes, shown by dashed line arrows. Thus, code generation subblock 273 outputs the data bytes in signals 812-0 to 812-15 and the corresponding error detection codes in signals 814-0 to 814-15. The (data) signals 812-0 to 812-15 are passed to the first subsection 252 for storage, and the (code) signals 814-0 to 814-15 are passed to the second subsection 254 for storage.

The error detection block 272 sends the data and the first data address (eg, in signals 812-0 to 812-15) over the volatile memory interface 200A (see 2 ) at a first point in time (e.g. in 8th referred to as “Time=TO”) to the first subsection 252 of the carve-out 250. In other words, the error detection block 272 sends the first write instruction to the first subsection 252 of the carve-out 250 (e.g., block 708 of 7 ). The volatile memory interface 200A communicates the first write instruction to the carve-out 250 via a data backbone and storage subsystem 826 of the vehicle SoC 104 (see 1 , 2 and 4 ). In 8th the first write instruction is sent by the error detection block 272 in a signal 824 to the first subsection 252.

The first subsection 252 writes the data into memory by writing the first byte (in 8th shown as “Data0”) at the first data address (in 8th shown as “Address_0”) and writes the subsequent bytes to the data addresses following the first data address. This writing process occurs for the first time, which is in 8th is shown as “Time=TO”. Then, the first subsection 252 sends a response signal 828 to the initiator 802 confirming that the data has been saved. The response signal 828 is sent from the first subsection 252 to the data backbone and storage subsystem 826, which forwards 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 carve-out 250. For example, error detection block 272 may include a pair of write instructions A and B (e.g., in the first write instruction specified in block 708 of 7 is sent) to the carve-out 250, with the write instruction B being sent by the error detection block 272 after the write instruction A. After the carve-out 250 writes the data contained in the write instructions A and B, the carve-out 250 sends a first and a second data write completion response to the error detection block 272. However, the second data write completion response received for the write instruction B may occur before the first data write completion response for the write instruction A arrives at the error detection block 272. In this case, 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 as it arrives, and sends the second data write completion response after the first data write completion response. Thus, the first (data) buffer 820 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 security island connection 808, which forwards the response signal 828 to the initiator 802. At this point, in this example, the data (e.g., 16 bytes) has been written to the first subsection 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 of 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 have other sizes, and 16 MB is given as an example only. Additionally, the storage location of the first code address may be determined by other methods and/or calculations.

The error detection block 272 waits (e.g. block 712 of 7 ) until the second point in time (e.g. in 8th referred to as “Time=T1”). The first and second points in time 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 to the second subsection 254 of the carve-out 250 (see 2 ). In other words, the error detection block 272 sends the second write instruction to the second subsection 254 of the carve-out 250 (e.g., block 714 of 7 ). The volatile memory interface 200A communicates the second write instruction to the carve-out 250 via the data backbone and storage subsystem 826 of the vehicle SoC 104 (see 1 , 2 and 4 ). In 8th the second write instruction is sent by the error detection block 272 in a signal 834 to the second subsection 254.

The second subsection 254 writes the error detection codes into memory by writing the first error detection code (in 8th shown as “CRC0”) at the first code address (in 8th shown as “Address_1”) and writes the subsequent error detection codes to the code addresses following the first code address. Then the second subsection 254 sends a response signal 838 to the initiator 802 confirming that the error detection codes have been stored. In the in 8th In the illustrated embodiment, the response signal 838 is sent from the second subsection 254 to the data backbone and storage subsystem 826, which forwards 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 carve-out 250. For example, error detection block 272 determines first and second error detection codes for the data contained in write instructions A and B, respectively, and sends the first and second error detection codes to carve-out 250 (e.g., in the second write instruction). After the carve-out 250 writes the first and second error detection codes into memory, it sends the first and second code write completion responses, respectively, to the second (code) buffer 822. The second code write completion response received for the second error detection code can however, arrive at the error detection block 272 before the first code write completion response for the first error detection code. In this case, 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 as it arrives, and sends the second code write completion response after the first code write completion response .

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

The volatile memory interface 200A may include two parallel and optionally dedicated interfaces that connect the error detection block 272 to the volatile memory 126. The data may be sent to the first data address via the first interface and the error detection code(s) may be sent to the first code address via the second interface. 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 subsection 252 over the first interface, while the error detection block 272 simultaneously sends the second write instruction, which includes the Error detection code(s) and the first code address (e.g. in signal 834) are sent via the second interface to the second subsection 254. In addition, the (data) response signal 828 and the (code) response signal 838 may be simultaneously transmitted to the first and second buffers 820 and 822 via the first and second interfaces, respectively.

When the initiator 802 (e.g., processor 140) of the SI 110 wants to read the data from the carve-out 250, the SI 110 receives both the data and the error detection code(s) from the carve-out 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 chance that an event that negatively impacts the data will also negatively impact 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 with the check code. This comparison can be represented by Equation 3 below: $$\begin{array}{l}\text{CRC\_gen}\left(\text{requested address}\text{, retrieved data}\right)\\ =={\text{crc\_in}}_{\text{Byte x}}\left(\text{CRC address}\right)\end{array}$$

In Equation 3, an operator “==” indicates that an expression to the left of the operator “==” is equal to an expression to the right of the operator “==”. A "retrieved data" variable represents at least a portion (e.g., byte x) of the data received in block 906, a "requested address" variable represents the data address of that portion of the data, and a "CRC address" variable represents for the code address determined based on the data address of the portion (e.g. byte x) of the data. A CRC_gen function takes the values of the retrieved data and requested address variables as inputs, and the CRC_gen function outputs the verification code for the section (e.g., byte x). The “CRC_gen” function can be identical to the “CRC” function of Equation 1 above. The output of the “CRC_gen” function can be at least partially controlled by the code generation subblock 273 (see 8th ) be calculated if it exists. An expression “crc_in _{byte x} (CRC address)” represents the error detection code obtained from the code address determined for the section (e.g. byte x) based on its data address. Thus, Equation 3 determines whether the check code is equal to or matches the error detection code. The error detection block 272 may generate a match error if the check code does not match the error detection code. The error detection block 272 may send a match error to the initiator 802 and the SI error aggregator 142 so that the match error can be cleared by the security software implemented by the instructions 149 and executed by the processor 140.

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

9 is a flowchart showing the method 900 for reading data from the carve-out 250 (see 2 , 8th and 10 ) according to some embodiments of the present disclosure. For ease of illustration, method 900 is described as if it were from error detection block 272 (see 2 , 8th and 10 ) carried out. Before the process 900 begins, the initiator 802 (see 8th ) a first read instruction that has one or more data addresses to the error detection block 272. As a non-limiting example, the first read instruction may only have a first data address. Like it in 9 As shown, in the first block 902, the error detection block 272 receives the first read instruction containing the data address(es) from the initiator 802. In block 904, the error detection block 272 forwards the first read instruction to the first subsection 252, which is the one under the requests data stored at the data address(es). If the first read instruction has only the first data address, the first subsection 252 may read a predetermined amount of data (e.g., 16 bytes) from consecutive memory addresses starting with the first data address. In block 906, the error detection block 272 receives the data stored at the data address(es) from the first subsection 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) can be calculated by adding the offset (the value of the fixed_offset variable) to a corresponding data address (the value of the write_address variable). Depending on the details of the implementation, the error detection block 272 may only determine 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. Therefore, 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) that is 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 subsection 254.

After waiting, in the next block 912, the error detection block 272 sends a second read instruction to the second subsection 254, which has the code address(es) determined in block 908 and the error detection code(s) stored at that code address(es). ) requests. Error detection is used to read the data block 272 accesses the carve-out 250 twice, once each in blocks 904 and 912. If the second read instruction only has the first code address, the second subsection 254 can output a predetermined number of error detection codes (e.g. 16 bytes). consecutive memory addresses, starting with 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 subsection 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).

In decision block 918, the error detection block 272 determines, for each of the error detection codes, whether the error detection code matches the check code that corresponds 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 the corresponding check code. Otherwise, the decision in decision block 918 is “NO”. If the decision in the decision block 918 is “YES”, the error detection block 272 forwards 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", error detection block 272 generates a match error in block 922 and sends it to initiator 802 and SI error aggregator 142 (see 1 , 2 and 4 ), so that the match error can be cleared by the security software implemented by the instructions 149 and executed by the processor 140. Optionally, in block 922, the error detection block 272 may attempt to correct the mismatch if the error detection code (e.g., implemented as ECC) has information (e.g., bits) that can be used to recover the data. If the error detection block 272 is able to correct the error, the error detection block 272 may omit generating the match error in block 922. After block 920, the error detection block 272 proceeds to block 920 and forwards the data to the initiator 802. Then procedure 900 ends.

The error detection block 272 can read two or more bytes of data and their corresponding error detection codes from the carve-out 250 at once. For example, blocks 904-914 can 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 subsection 252 and request two or more bytes of data from a first data address. The first subsection 252 may read the data bytes from successive memory addresses starting with the first data address and send the data bytes to the error detection block 272, which the error detection block 272 receives in block 906. Then, in block 908, the error detection block 272 may determine the code address(es) based on the data address(es). Depending on the implementation details, the error detection block 272 may only determine 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 data bytes and reading the error detection codes from the carve-out 250. Next, the error detection block 272 may request the error detection codes stored in the carve-out 250 for the data bytes received in block 906. For example, the error detection block 272 may send the first code address to the second subsection 254. The second subsection 254 may read the error detection codes from successive 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. Then the method 900 continues with block 916.

10 shows an example of how the method 900 is performed by the error detection block 272. In this example, the processor 140 reads 16 bytes of data from the carve-out 250 which is in the in 8th shown example can be saved. In 10 the read data is stored or represented in an array of 128 bits called "rdata_in[127:0]", and the data is stored from the first data address, which is in an array of 40 bits called "Address_0[39: 0]” is stored or displayed. 10 shows how the initiator 802 (e.g., the processor 140) sends a first read instruction 1004 to the error detection block 272 over the security island connection 808. The safety island connection 808 provides the first read instruction 1004 to the error detection block 272 (e.g., block 902 of 9 ).

The error detection block 272 sends the first data address over the volatile memory interface 200A (see 2 ) at a third time (e.g. in 10 referred to as “Time=T3”) to the first subsection 252 of the carve-out 250. In other words, the error detection block 272 forwards the first read instruction to the first subsection 252 of the carve-out 250 (e.g., block 904 of 9 ). The interface 200A for The volatile memory transmits the first read instruction via the data backbone and memory subsystem 826 of the vehicle SoC 104 to the carve-out 250. In 10 the first read instruction is sent to the first subsection 252 by the error detection block 272 in a signal 1010.

The first subsection 252 reads the data from memory starting with the first byte (“Byte 0”) at the first data address and reads the subsequent bytes of data addresses following the first data address. The SI 110 can read data with a specified size (e.g. 16 bytes) from the Carve-Out 250. The first subsection 252 then sends a response signal 1012 to the initiator 802, which includes the read data. The response signal 1012 is sent from the first subsection 252 to the data backbone and storage subsystem 826, which forwards the response signal 1012 to the volatile memory interface 200A (see 2 ). When the volatile memory interface 200A is enabled, the volatile memory interface 200A forwards the response signal 1012 to the first (data) buffer 820 (e.g., at block 906 of 9 ). The read data, which includes the response signal 1012, automatically indicates the completion of data reading and can therefore be referred to as a data read completion response. Just as the first (data) buffer 820 handles the data write completion responses, the first (data) buffer 820 can place the data read completion responses into the response signal 1012 in an expected order. At this point, in this example, the data (eg, 16 bytes) has been read from the first subsection 252 in a first single read operation and arranged from the first (data) buffer 820 in the expected order.

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

Next, error detection block 272 waits (e.g., at block 910 of 9 ) up to a fourth point in time (e.g. in 10 referred to 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) in the second subsection 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 subsection 254 of the carve-out 250 (e.g., at block 912 of 9 ). The volatile memory interface 200A communicates the second read instruction to the carve-out 250 via the data backbone and memory subsystem 826 of the vehicle SoC 104. In 10 the second read instruction is sent by the error detection block 272 in a signal 1014 to the second subsection 254.

The second subsection 254 reads the error detection codes from memory by reading the first error detection code (for "Byte 0") at the first code address and reading subsequent error detection codes from the code addresses subsequent to the first code address. In the example of the 8th and 10 The error detection codes are each one byte in size. Then, the second subsection 254 sends a response signal 1016 to the initiator 802 that includes the error detection code(s) read from memory. In 10 the signals with the error detection codes and the signal 1014 are shown by arrows with dashed lines. In the in 10 In the illustrated embodiment, the response signal 1016 is sent from the second subsection 254 to the data backbone and storage subsystem 826, which forwards 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 the second (code) buffer 822 (e.g., at block 914 of 9 ). The error detection codes that have been read and included in the response signal 1016 automatically indicate code read completions and therefore may be referred to as code read completion responses. Similar to how the second (code) buffer 822 handles the code write completion responses, the second (code) buffer 822 can place the code read completion responses in the response signal 1016 in an expected order. At this point, in this example, the error detection codes (e.g., 16 bytes) have been read from the second subsection 254 in a second single read operation and arranged by the second (code) buffer 822 in the expected order.

If the error detection block 272 waits (e.g. at block 910 of 9 ) until the fourth point in time (e.g. in 10 referred to as “Time=T4”), the error detection block 272 merely introduces a time interval between the first and second read instructions. The error detection block 272 may request the error detection code(s) from the second subsection 254 after the error detection block 272 receives the data in the response signal 1012. Alternatively, 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 subsection 254. In other words, the fourth time may be determined based on the time at which the first read instruction is sent, rather than based on the time at which the response signal 1012 is received.

As mentioned above, the first (data) buffer 820 may reorder the bytes because the bytes in the response signal 1012 may not be in the correct order. Similarly, the second (code) buffer 822 may reorder the error detection codes if the error detection codes in the response signal 1016 are not in the correct order. The first (data) buffer 820 outputs signals 1022-0 to 1022-15, each containing one of the data bytes, and the second (code) buffer 822 outputs signals 1024-0 to 1024-15, each containing one of the Error detection codes included. The signals 1022-0 to 1022-15 correspond to the signals 1024-0 to 1024-15. The first and second buffers 820 and 822 may route or reorder signals 1022-0 to 1022-15 and 1024-0 to 1024-15, respectively, to assign each byte of data to a known location with respect to the error detection code generated for the byte position. At the in 10 In the embodiment shown, the bytes transmitted by signals 1022-0 to 1022-15 are interleaved with the error detection codes transmitted by signals 1024-0 to 1024-15. Become like that, as in 10 , the data bytes are placed at locations represented by shaded blocks b0-b15, and the error detection code(s) are placed at locations represented by blocks c0-c15.

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

For each of the error detection codes, the error detection block 272 determines whether the error detection code matches the check code that corresponds to the error detection code (e.g., at decision block 918 of 9 ). The error detection block 272 indicates the match in a pass signal 1030, which is passed along with a data signal 1032 comprising the data byte to a logic component 1034 which is in 10 is shown 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 (having only data bytes) and passes the checked data signal 1036 to the initiator 802 further. Conversely, if the pass signal 1030 indicates a mismatch, the logic component 1034 does not pass the byte in the tested 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 exists. As a non-limiting example, the bits of the byte that caused the mismatch may be set to zero. The tested data signal 1036 is forwarded to the initiator 802 (e.g. at block 920 of 9 ). The error detection block 272 may generate a match error and send it to the initiator 802 if the error detection code does not match the check code corresponding to the error detection code (e.g., at block 922 of 9 ). In other words, if the pass signal 1030 indicates one or more mismatches, the error detection block 272 may generate a match error and send it to the initiator 802. Alternatively or additionally, the error detection block 272 may send the match error to the SI error aggregator 142 as an uncorrected error. In this way, any error that occurs in the data or the error detection code(s) during storage in the carve-out 250 and/or retrieval from the carve-out 250 can be detected and (e.g., as uncorrected error) can be reported.

As previously mentioned, the volatile memory interface 200A may include the two parallel and optionally dedicated interfaces that connect 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 signal 1010) to the first subsection 252 via the first interface, while the error detection block 272 may send the second read instruction including the first code address (e.g., in signal 1014) via the second interface to the second subsection 254 sends. In addition, the data read from the first subsection 252 (and, for example, transmitted in the response signal 1012) and the error detection code(s) read from the second subsection 254 (and, for example, transmitted in the response signal 1016) can be transmitted simultaneously via the first or second interface to the first and second buffers 820 and 822, respectively.

With reference to 2 The error detection block 272 may include or be associated with at least one transaction timer, such as. B. the output and input timers 274 and 276, which limit the amount of time available to the error detection block 272 to read data from and/or write data to the carve-out 250. The exit timer 274 and/or the entry timer 276 start automatically when an access passes the error detection block 272. For example, the input timer 276 may start whenever data is transferred between the error detection block 272 and the initiator 802 (e.g., the processor 140), and the output timer 274 may start whenever data is transferred between the error detection block 272 and the SoC area (e.g. the Carve-Out 250). The input timer 276 may help monitor the functioning of the error detection block 272 and/or provide backup functionality for the output timer 274 (e.g., if the output timer 274 is not functioning properly).

During a write operation, the input timer 276 may start when the initiator 802 passes data to the error detection block 272 to be written into the carve-out 250 (e.g., in block 702 of 7 ). Then the exit timer 274 may begin when this data leaves the error detection block 272 and/or the SI area (e.g. in block 708 of 7 ). The output timer 274 may be stopped or reset when the error detection block 272 receives the response (e.g., the in 8th response signal 828 shown) is received from the carve-out 250. Then the input timer 276 can be paused or reset when the response (e.g. the in 8th response signal 828 shown) through the error detection block 272 to the initiator 802 (see 8th ) is transferred. If the exit timer 274 indicates that more than a first time threshold has elapsed and the error detection block 272 has not received the response, which means that the initiator 802 has not received a response from the carve-out 250 (e.g., the in 8th response signal 828 (illustrated) is received, the initiator 802 (e.g., processor 140) generates an output timeout error. If the input timer 276 indicates that more than a second time threshold 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 the response from the carve-out 250, generated the initiator 802 receives an input timeout error.

During a read operation, the input timer 276 may begin when the error detection block 272 receives the read request from the initiator 802 (e.g., in block 902 of 9 ). Then, the output timer 274 may begin when the error detection block 272 requests the data stored at the first data address from the carve-out 250 (e.g., in block 904 of 9 ). The output timer 274 may be paused or reset when the data from the carve-out 250 is received by the error detection block 272 (e.g., in block 906 of 9 ). Thereafter, the input timer 276 may be paused or reset when the data is transmitted to the initiator 802 through the error detection block 272 (e.g., in block 920 of 9 ). If the exit timer 274 indicates that the first threshold time has elapsed and the error detection block 272 has not received the data from the carve-out 250, which means that the initiator 802 will not receive the data from the error detection block 272 (e.g .in which in 10 checked data signal 1036 shown), the initiator 802 generates the output timeout error. If the input timer 276 indicates that more than the second threshold time has elapsed and the error detection block 272 has not sent the data to the initiator 802, which means that the initiator 802 has not received the data from the carve-out 250, generated the initiator 802 receives the input timeout error.

11 is a representation 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, according to some embodiments, the output and input timers 274 and 276 (see 2 ) has or is associated with it. In 11 the initiator sends 802 (see 8th and 10 ) a signal 1102, which is either the first write instruction 804 (see 8th ) or the first read instruction 1004 (see 10 ). 272 requests the data stored at the first data address from the carve-out 250 during a read operation. Block 1104 indicates that the exit timer 274 has expired. For example, the output timer 274 may expire if the error detection block 272 does not receive a response from the carve-out 250 (e.g., the in 8th response signal 828 shown) and more than the first threshold time has elapsed. As another non-limiting example, the output timer 274 may time out when the error detection block 272 the data from the error detection block 272 (e.g. in the in 10 response signal 1012 shown) has not been received during a read operation and more than the first threshold time has elapsed. When the exit timer 274 expires, the initiator 802 (e.g., processor 140) generates an exit timeout error 1106 and passes the exit timeout error 1106 to an error store 1108. On the other hand, if the exit timer 274 has not expired, the exit timer 274 may be stopped or reset. This can occur when error detection block 272 either receives the response (e.g., response signal 828) from carve-out 250 during a write operation or the data (e.g., in response signal 1012) from carve-out 250 during a read operation receives before the first threshold time has elapsed.

As noted above, the input timer 276 may start when the initiator 802 passes data to the error detection block 272 during a write operation to be written into the carve-out 250 (e.g., in block 702 of 7 ), or the input timer 276 may start when the error detection block 272 receives the read request from the initiator 802 during a read operation (e.g., in block 902 of 9 ). So the input timer 276 (see 2 ) start when signal 1102 completes the first write operation 804 (see 8th ) or the first read operation 1004 (see 10 ) and this instruction is received by the error detection block 272 (see 2 , 8th and 10 ). Block 1114 indicates that the input timer 276 has expired. For example, the input timer 276 may expire if more than the second threshold time has elapsed and the initiator 802 (see 8th ) during a write operation, no response from the Carve-Out 250 (e.g. the in 8th response signal 828 shown). As another non-limiting example, the input timer 276 may expire if more than the second threshold time has elapsed and the initiator 802 receives the data (e.g., the in 10 (illustrated test data signal 1036) from the carve-out 250 was not received during a read operation. When the input timer 276 expires, the initiator 802 generates an input timeout error 1116 and forwards the input timeout error 1116 to the error memory 1108. However, if the input timer 276 has not expired, the input timer 276 may be stopped or reset. This can occur when the error detection block 272 transmits the response (e.g., the response signal 828) to the initiator 802 during a write operation, or when the error detection block 272 transmits the data (e.g., the checked data signal 1036) to the initiator 802 during a read operation Initiator 802 transmits.

Block 1124 indicates that code generation subblock 273 (see 2 , 8th and 10 ) of the error detection block 272 (see 2 , 8th and 10 ) may generate a code generation/verification error 1126 indicating that an error occurred during generation of an error detection code or a verification code. In some embodiments, code generation/verification error 1126 may be used to indicate that a mismatch has occurred. By way of non-limiting example, if signal 1102 includes first write instruction 804, code generation subblock 273 may generate a code generation error while generating the error detection code(s). For example, if the signal 1102 includes the first read instruction 1004, the error detection block 272 may generate a matching error and/or a code generation error while generating the check code(s) referred to as the code generation/verification error(s) 1126 is/are forwarded to error memory 1108.

The error store 1108 can function as an error aggregator that aggregates errors 1106, 1116 and 1126 into an error message 1130 that the error store 1108 sends to the SI error aggregator 142.

When the vehicle SoC 104 first boots up, the processor 140 of the SI 110 may attempt to pre-fetch data from the carve-out 250. A prefetch may be characterized as a type of non-intentional reading of data from the carve-out 250. At this time, because shared volatile memory 126 is volatile, carve-out 250 may store uninitialized data that is not error detection codes or is associated with mismatched error detection codes. To prevent the error detection block 272 from generating matching 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 into the carve-out 250 for the data that the processor 140 will or could fetch in advance. As a non-limiting example, the SI 110 may write initial data into the carve-out 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 can cause the carve-out 250 to store each error detection code in its associated code address. Thus correspond during a prefetching or pre-fetching operation tion, the error detection codes stored in the second subsection 254 correspond to the data stored in the first subsection 252, and the error detection block 272 produces no matching errors.

With reference to 2 The SI 110 can use the code generation subblock 273 (see 2 , 8th and 10 ) and/or turn off the error detection block 272 (e.g. by writing to a software register) if the vehicle platform 100 (see 1 ) the Carve-Out 250 is not needed. For example, the SI 110 may turn off the code generation subblock 273 and/or the error detection block 272 when the volatile memory 126 is operating at a risk level that is sufficient for the vehicle platform 100.

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

EXAMPLE OF AN AUTONOMOUS VEHICLE

12 is an illustration of an example of an autonomous vehicle 1200, according to some embodiments of the present disclosure. The autonomous vehicle 1200 (alternatively referred to herein as “vehicle 1200”) may, without limitation, be a passenger vehicle, such as a passenger vehicle. B. a car, a truck, a bus, a first responder vehicle, a shuttle bus, an electric or motorized bicycle, a motorcycle, a fire engine, a police vehicle, an ambulance, a boat, a construction vehicle, an underwater vehicle, a drone and / or a other type of vehicle (e.g. that is unmanned and/or carries one or more passengers). Autonomous vehicles are generally described in terms of levels of automation as 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” (Standard No. J3016-201806, published June 15, 2018, Standard No. J3016-201609, published September 30, 2016, and previous and future versions of this standard). The vehicle 1200 may be capable of performing functions in accordance with one or more of Levels 2 through 5 of the autonomous driving levels as defined by the SAE. For example, depending on the embodiment, the vehicle 1200 may be capable of performing partial driving automation (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 have a propulsion system 1250, such as. B. an internal combustion engine, a hybrid electric power plant, a pure electric motor and / or another type of drive system. The propulsion system 1250 may be connected to a powertrain of the vehicle 1200, which may include a transmission to enable propulsion of the vehicle 1200. The propulsion system 1250 may be controlled in response to receiving signals from the throttle/accelerator 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 in operation (e.g., when the vehicle is in movement is). The steering system 1254 may receive signals from a steering actuator 1256. The steering wheel can optionally be used for full automation (level 5).

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

A controller(s) 1236 that includes one or more system-on-chips (SoCs) 1204 ( 14 ) and/or GPU(s), may provide signals (e.g., representing commands) to one or more 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, to actuate the propulsion system 1250 via one or more throttle/ Acceleration actuators 1252 to operate. The Controller(s) 1236 may include one or more built-in (e.g., integrated) 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 driving 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 (e.g., computer vision) functions, a fourth controller 1236 for infotainment -Functions, a fifth controller 1236 for redundancy under emergency conditions and/or other controllers. In some examples, a single controller 1236 may perform two or more of the above functions, two or more controllers 1236 may perform a single function, and/or any combination thereof.

The controller(s) 1236 may provide the 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, for example and without limitation, from a global navigation satellite system sensor(s) 1258 (e.g., Global Positioning System sensor(s)), RADAR sensor(s) 1260, ultrasonic sensor(s) 1262, LIDAR -Sensor(s) 1264, inertial sensor(s) (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-angle camera(s) 1270 (e.g., fisheye cameras), infrared camera(s) 1272, surround camera(s) 1274 (e.g., 360-degree cameras), long-distance and/or mid-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) (e.g. as Part of the brake sensor system 1246) and/or other sensor types are received.

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 outputs (e.g., represented by output data, display data, etc.) via a human-machine interface (HMI). -Display 1234, an audible detector, a loudspeaker and/or via other components of the vehicle 1200. The outputs can include information such as vehicle speed, RPM, time, map data (e.g. the HD map 1222 from 14 ), location data (e.g., the location of the vehicle 1200, e.g., on a map), direction, the location of other vehicles (e.g., an occupancy grid), information about objects and the status of objects, as determined by the / the control(s) 1236 perceived, etc. For example, the HMI display 1234 may display information about the presence of one or more objects (e.g., a street sign, a warning sign, a changing traffic light, etc.) and/or information about driving maneuvers that the vehicle has performed, is currently performing or will perform (e.g. change lanes now, take exit 34B in two miles, etc.).

The vehicle 1200 further includes a network interface 1224 that may use one or more wireless antennas 1226 and/or modems to communicate over one or more networks. For example, the network interface 1224 may be capable of communicating via 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 networks such as Bluetooth, Bluetooth LE, Z-Wave, ZigBee etc. and/or low power wide area networks (LPWANs) such as LoRaWAN, SigFox etc. are used.

As noted above, in at least one embodiment, the vehicle platform 100 (see 1 ) may be a component of the autonomous vehicle 1200. In such embodiments, the controller(s) 1236 includes the vehicle SoC 104.

13 is an example of camera locations and fields of view for the example autonomous vehicle 1200 from 12 , according to some embodiments of the present disclosure. The cameras and respective fields of view are an example of an embodiment and are not intended as a limitation. For example, additional and/or alternative cameras may be provided and/or the cameras may be located at other locations on the vehicle 1200.

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

In some examples, one or more of the cameras 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 can be installed that provides functions that include lane departure warning, traffic sign assist and intelligent headlight control. One or more of the camera(s) (e.g. all cameras) can simultaneously record and provide image data (e.g. video).

One or more of the cameras can be in a mounting arrangement, such as. B. a custom-designed (3-D printed) assembly, to eliminate stray light and reflections from the vehicle interior (e.g. reflections from the dashboard reflected in the windshield mirrors) that can affect the camera's image data capture capabilities . When mounting exterior mirrors, the exterior mirrors can be customized three-dimensionally printed so that the camera mounting plate matches the shape of the exterior mirror. In some examples, the cameras can be integrated into the exterior mirror. For side cameras, the cameras can also be integrated into the four pillars at each corner of the passenger compartment.

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 environmental viewing to help identify and assist in identifying forward-facing paths and obstacles One or more controllers 1236 and/or control SoCs provide information critical to generating an occupancy grid and/or determining preferred vehicle paths. Forward-facing cameras can be used to perform many of the same ADAS functions as LIDAR, including emergency braking, pedestrian detection and collision avoidance. Forward-facing cameras can also be used for ADAS features and systems such as Lane Departure Warnings (LDW), Autonomous Cruise Control (ACC), and/or other features such as Recognition of traffic signs can be used.

A variety of cameras can be used in a front-facing configuration, such as: B. a monocular camera platform that has a color image converter of the CMOS (Complementary Metal Oxide Semiconductor) type. Another example is one or more wide-angle cameras 1270 that can be used to detect objects coming into view from the periphery (e.g., pedestrians, crossing traffic, or bicycles). Although in 13 Only one wide-angle camera is shown, any number of wide-angle cameras 1270 can be located on the vehicle 1200. Additionally, long-range camera(s) 1298 (e.g., a long-range 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 1298 long range camera(s) can also be used for object detection and classification as well as basic object tracking.

One or more stereo cameras 1268 may also be included in a front-facing configuration. The stereo camera(s) 1268 may include an integrated control unit that includes a scalable processing unit that can provide programmable logic (e.g., FPGA) and a multicore microprocessor with an integrated CAN or Ethernet interface on a single chip. Such a unit can be used to generate a 3-D map of the vehicle's surroundings, including a distance estimate for all points in the image. An alternative stereo camera(s) 1268 may include a compact stereo vision sensor(s) that includes two camera lenses (one on the left and one on the right) and an image processing chip that determines the distance between the vehicle and the Measure target object and use the generated information (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 alternative to those described herein.

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

Cameras with a field of view that include portions of the environment behind the vehicle 1200 (e.g., rearview cameras) may be used for parking assistance, an environmental view, rear collision warnings, and generating and updating the occupancy grid. A wide variety of cameras may be used, including, but not limited to, cameras that also function as front-facing camera(s) (e.g., long-range and/or mid-range camera(s) 1298, stereo camera(s) 1268 , infrared camera(s) 1272, etc.) as described here.

14 is a block diagram of an example system architecture for the example autonomous vehicle 1200 of 12 , according to some embodiments of the present disclosure. It should be understood that these and other arrangements described herein are presented as examples only. Other arrangements and elements (e.g., machines, interfaces, functions, sequences, groupings of functions, etc.) may be used in addition to or instead of those shown, and some elements may be omitted entirely. Additionally, 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 that are performed by devices may be performed by hardware, firmware, and/or software. For example, various functions can be performed by a processor executing instructions stored in memory.

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

Although bus 1202 is described here as a CAN bus, this should not be construed as a limitation. For example, FlexRay and/or Ethernet can also be used in addition to or as an alternative to the CAN bus. Although a single line is used to represent bus 1202, this should not be construed as 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 with 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 a collision avoidance function and a second bus 1202 may be used for actuation control. In any example, each bus 1202 may communicate with any of the components of the 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 within the vehicle may have access to the same input data (e.g., inputs from sensors of the vehicle 1200) and may be connected to a common bus, such as the CAN bus be.

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

The vehicle 1200 may include one or more System on Chip (SoC) 1204. The SoC 1204 can have CPU(s) 1206, GPU(s) 1208, Processor(s) 1210, Cache(s) 1212, Accelerator 1214, data storage 1216 and/or other components and features not shown. 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 may be combined in a system (e.g., the system of the vehicle 1200) with an HD card 1222 that provides map refreshes and/or map updates via a network interface 1224 from one or more servers (e.g. server(s) 1278 from 15 ) can be received.

The CPU(s) 1206 may include a CPU cluster or CPU complex (alternatively referred to herein as “CCPLEX”). The CPU(s) 1206 may contain multiple cores and/or L2 caches. For example, in some embodiments, 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, each cluster having a dedicated L2 cache (e.g., a 2 MB L2 cache). The CPU(s) 1206 (e.g., the CCPLEX) may be configured to support concurrent cluster operation, allowing any combination of clusters of the CPU(s) 1206 to be active at any given time .

The CPU(s) 1206 may implement power management functions that include one or more of the following features: individual hardware blocks may be automatically clock limited when idle to conserve dynamic power; each core clock can be limited when the core is not actively executing instructions due to the execution of WFI/WFE instructions; each core can be independently current limited; each core cluster can be independently clock limited if all cores are clock limited or power limited; and/or each core cluster may be independently power limited if all cores are power limited. The CPU(s) 1206 may also implement an advanced power state management algorithm in which allowable power states and expected wake-up times are set and the hardware/microcode determines the best power state to use for the core, cluster, and CCPLEX is to be taken. The processor cores can support simplified power state entry sequences in software, offloading the work to 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 an L1 cache (e.g., an L1 cache with at least 96 KB of storage capacity) and two or more of the streaming -Microprocessors can share an L2 cache (e.g. an L2 cache with 512 KB of memory capacity). 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) for calculations. Additionally, the GPU(s) 1208 may use one or more parallel computing platforms and/or programming models (e.g., NVIDIA's CUDA).

The GPU(s) 1208 may be power optimized for best 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 should not be construed as a limitation, and the GPU(s) 1208 may also be manufactured using other semiconductor manufacturing methods. Each streaming microprocessor can contain a number of mixed-precision computing cores divided into several blocks. For example, 64 PF32 cores and 32 PF64 cores can be divided into four processing blocks, but are not limited to this. In such an example, each processing block can have 16 FP32 cores, 8 FP64 cores, 16 INT32 cores, two mixed precision NVIDIA TENSOR COREs for deep learning matrix arithmetic, an LO instruction cache, a warp scheduler, a dispatch unit and/or a 64 KB register file can be assigned. Additionally, the streaming microprocessors can include independent parallel integer and floating point data paths to provide efficient execution of workloads with a mix of computations and addressing computations. The streaming microprocessors can have independent thread scheduling capability to enable fine-grained synchronization and collaboration between parallel threads. The streaming microprocessors can include a combined L1 data cache and shared memory unit 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, in some examples, a peak memory bandwidth of approximately 900 GB/ Second to provide. In some examples In addition or as an alternative to the HBM memory, a synchronous graphics random access memory (SGRAM) can be used, e.g. B. a synchronous graphics dual data rate random access memory type 5 (GDDR5).

The GPU(s) 1208 may include unified memory technology with access counters to enable more accurate migration of memory pages to the processor that accesses them most frequently, thereby improving the efficiency of memory areas used by the Processors are shared. In some examples, Address Translation Services (ATS) support may be used to enable GPU(s) 1208 to directly access the page tables of CPU(s) 1206. In such examples, if the memory management unit (MMU) of the GPU(s) 1208 detects an error, an address translation request may be transmitted to the CPU(s) 1206. In response, the CPU(s) 1206 may look up the virtual physical mapping for the address in its page tables and transmit the translation back to the GPU(s) 1208. As such, unified memory technology may enable a single unified virtual address space for the memory of both CPU(s) 1206 and GPU(s) 1208, thereby facilitating programming of GPU(s) 1208 and porting of applications to the GPU(s) 1208 is simplified.

Additionally, the GPU(s) 1208 may include an access counter that may track the frequency of accesses of the GPU(s) 1208 to the memory of other processors. The access counter can help move memory pages into physical memory by 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, cache(s) 1212 may include an L3 cache that is available to both CPU(s) 1206 and GPU(s) 1208 (e.g., which is connected to both the CPU(s) 1206 and the GPU(s) 1208). The cache(s) 1212 may include a write-back cache that can track the states of lines, e.g. B. by using a cache coherence protocol (e.g. MEI, MESI, MSI, etc.). The L3 cache can be 4 MB or larger depending on the embodiment, although smaller cache sizes can also be used.

The SoC(s) 1204 may include an arithmetic logic unit(s) (ALU(s)) used in performing processing related to any variety of tasks or operations of the vehicle 1200 - such as processing DNNs - can be used effectively. Additionally, the SoC(s) 1204 may include a floating point unit(s) (FPU(s)) - or other mathematical coprocessors or numerical coprocessor types - for performing mathematical operations within the system. For example, the SoC(s) 504 may include one or more FPUs integrated as execution units into 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 large on-chip memory. The large on-chip memory (e.g. 4MB SRAM) can enable the hardware acceleration cluster to accelerate neural networks and other calculations. The hardware acceleration cluster may be used to supplement the GPU(s) 1208 and to offload some tasks of the GPU(s) 1208 (e.g., freeing more cycles of the GPU(s) 1208 to perform other tasks). For 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 accelerated. 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., as used for object detection).

The accelerator(s) 1214 (e.g., the hardware acceleration cluster) may include a deep learning accelerator (DLA). The DLA(s) may include one or more Tensor Processing Units (TPUs), which may be configured to provide an additional ten trillion operations per second for deep learning applications and inferencing. The TPUs can be accelerators configured and optimized to perform image processing functions (e.g. for CNNs, RCNNs, etc.). The DLA(s) may also be optimized for a particular set of neural network types and floating point operations, as well as for inferencing. The design of the DLA(s) can deliver more performance per millimeter than a general-purpose GPU and far exceeds the performance of a CPU. The TPU(s) can perform multiple functions, including a single-instance convolution radio tion, which e.g. B. INT8, INT16 and FP16 data types supported for both features and weights, as well as post-processing functions.

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

The DLA(s) can perform any function of the GPU(s) 1208, and by using an inference accelerator, for example, a developer can use either the DLA(s) or the GPU(s) 1208 for any one Use function. For example, the developer may concentrate the processing of CNNs and floating point operations on the DLA(s) and leave other functions to the GPU(s) 1208 and/or other accelerator(s) 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 computer vision accelerator. The PVA(s) may be designed and configured to implement computer vision algorithms for advanced driver assistance systems (ADAS), autonomous driving and/or augmented reality (AR) and/or virtual reality ( VR) to accelerate applications. The PVA(s) can provide a balance between performance and flexibility. For example, each PVA may include, for example and without limitation, any number of reduced instruction set computing (RISC), direct memory access (DMA), and/or any number of vector processors.

The RISC cores may interact with image sensors (e.g., the image sensors of one of the cameras described herein), image signal processors, and/or the like. Each of the RISC cores can have any amount of memory. The RISC cores can use any number of protocols depending on the embodiment. In some examples, the RISC cores may run a real-time operating system (RTOS). The RISC cores may be implemented with one or more integrated circuit devices, application specific integrated circuit devices (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 functions used to optimize the PVA, including, but not limited to, support for multidimensional 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 stepping, vertical block stepping, and/or depth stepping.

The vector processors may be programmable processors that may be designed to efficiently and flexibly execute programming for computer vision algorithms and to 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 unit 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, e.g. B. a digital signal processor with a single instruction for multiple data (“Single Instruction, Multiple Data”, SIMD) and very long instruction words (“Very Long Instruction Word”, VLlW). The combination of SIMD and VLIW can increase throughput and speed.

Each of the vector processors may have an instruction cache and be connected to dedicated memory. As a result, in some examples, each of the vector processors may be configured to operate independently of the other vector processors. In other examples, the vector processors included in a particular PVA may be configured to use 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 given PVA can simultaneously run different computer vision algorithms on the same image, or even different ones Run algorithms on consecutive images or sections of an image. Among other things, any number of PVAs may be present 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 have an additional error correcting code (ECC) memory to increase the security of the overall system.

The accelerator(s) 1214 (e.g., hardware acceleration cluster) may include an on-chip computer vision network and SRAM to provide high-bandwidth, low-latency SRAM for 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 that may be accessible to 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 storage can be used. The PVA and the DLA can access the memory over a backbone that provides the PVA and the DLA with high-speed access to the memory. The backbone may include an on-chip computer vision network connecting the PVA and DLA to the memory (e.g. using the APB).

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

In some examples, the SoC(s) 1204 may include a real-time ray tracing hardware accelerator, as described in the filing on August 10, 2018 US Patent Application No. 16/101,232 is described. The real-time ray tracing hardware accelerator can 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 or analysis, for simulation of SONAR systems, for general wave propagation simulation, for comparison with LIDAR data for the purpose of localization and/or other functions and/or for other uses. 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) has a wide range of applications for autonomous driving. The PVA can be a programmable image processing accelerator that can be used for key processing stages in ADAS and autonomous vehicles. PVA's capabilities are well suited to algorithmic domains that require predictable, low-power, low-latency processing. In other words, the PVA is well suited for semi-dense or dense regular computations, even on small datasets that require predictable runtimes with low latency and low power consumption. Thus, in the context of autonomous vehicle platforms, the PVAs are designed to execute classic computer vision algorithms because they are efficient at object detection and work with integer mathematics.

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

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

The DLA can be used to power any type of network to improve control and driving safety, including, for example, a neural network designed for each Object detection provides a measure of trust. Such a confidence value can be interpreted as a probability, or as a relative “weight” for each detection compared to other detections. This confidence value allows the system to make further decisions regarding which detections should be considered true positive detections and which should be considered false positive detections. For example, the system may set a confidence threshold and only consider detections that exceed this 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 trusted detections should be considered as triggers for AEB. The DLA can use a neural network to regression the trust value. The neural network can use as input at least a subset of parameters, such as: B. dimensions of a bounding box, an estimate of the ground plane obtained (e.g. from another subsystem), an output of an inertial measurement unit (IMU) 1266 that correlates with the orientation of the vehicle 1200, a distance, an estimate of the 3D position of the object 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 one or more data memories 1216 (e.g., memory). The data memory(s) 1216 may be on-chip memory of the SoC(s) 1204, which may store neural networks running on the GPU and/or the DLA . In some examples, the capacity of the data store(s) 1216 may be large enough to store multiple instances of neural networks for redundancy and security. The data store(s) 1212 may include L2 or L3 cache(s) 1212. A reference to the data memory(s) 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 boot and power management processor, which may be a dedicated processor and subsystem to handle the boot power and management functions and associated security enforcement. The boot and power management processor may be part of a boot sequence of the SoC(s) 1204 and may provide runtime power management services. The boot power and management processor may provide clock and voltage programming, support for system transitions to a low power state, management of temperatures and temperature sensors of SoC(s) 1204, and/or management of power states of 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 the ring oscillators to determine temperatures of the CPU(s) 1206, GPU(s) 1208 and/or or accelerator 1214 to capture. If temperatures are determined to exceed a threshold, the boot and power management processor may enter a temperature error routine and place the SoC(s) 1204 into a lower power state and/or place the vehicle 1200 into a chauffeur mode. put into 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 across multiple interfaces and 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 also include an “always on” processor engine that provides the necessary hardware functions to support low power sensor management and wake-up use cases. The always-on processor machine may include a processor core, tightly coupled RAM, supporting peripherals (e.g., timers and interrupt control), various I/O control peripherals, and routing logic.

The processor(s) 1210 may also include a security cluster machine that has a dedicated processor subsystem for security management of automotive applications. The security cluster machine 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 can operate in a lockstep mode and function as a single core with comparison logic to to capture any differences between their operations.

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

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

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 produce the final image for the Create playback window. The video image compositor may perform lens distortion correction on the wide-angle camera(s) 1270, the surround camera(s) 1274, and/or on the in-vehicle surveillance camera sensors. The surveillance camera sensor in the passenger compartment is preferably monitored by a neural network running on another instance of the advanced SoC, which is designed to detect events in the passenger compartment and respond accordingly. A system in the passenger compartment can perform lip reading to activate cellular service and make a call, dictate email, change the vehicle's destination, activate or change the vehicle's infotainment system and settings, or provide voice-controlled Internet surfing make possible. Certain features are only available to the driver when the vehicle is operating in an autonomous mode and are disabled otherwise.

The video image compositor may have improved temporal noise reduction for both spatial and temporal noise reduction. For example, when motion occurs in a video, noise reduction weights the spatial information accordingly and reduces the weight of the information provided by neighboring frames. When an image or part of an image has no motion, temporal noise reduction performed by the video image compositor can use information from the previous image to reduce noise in the current image.

The video image compositor may also be configured to perform stereo rectification on input stereo frames. The video image compositor can also be used for user interface design when the operating system desktop is in use and the GPU(s) 1208 are not needed to continually render new interfaces. Even when the graphics processor(s) 1208 is turned on and actively performing 3D rendering, the video image compositor can be used to offload the graphics processor(s) 1208 to improve performance and responsiveness.

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

The SoC(s) 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 transmit 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 have their own DMA engines, and which may be used to offload the CPU(s) 1206 from routine data management tasks.

The SoC(s) 1204 may be an end-to-end platform with a flexible architecture that spans automation levels 3-5, thereby providing a comprehensive functional safety architecture that incorporates computer vision and ADAS techniques for diversity and redundancy uses, provides a platform for a flexible, reliable driving software stack together with tools for deep learning and uses them efficiently. The SoC(s) 1204 can be faster, more reliable and even more energy and space efficient than traditional systems. For example, the accelerator(s) 1214, when connected to the CPU(s) 1206, may The GPU(s) 1208 and the data storage(s) 1216 are combined to form a fast, efficient platform for Level 3-5 autonomous vehicles.

The technology therefore offers possibilities and functions that cannot be achieved with conventional systems. For example, computer vision algorithms can run on CPUs that can be configured using high-level programming languages, such as the C programming language, to execute a variety of processing algorithms on a variety of visual data. However, CPUs are often unable to meet the performance requirements of many computer vision applications, such as: B. in terms of execution time and power consumption. In particular, many CPUs are unable to execute complex object detection algorithms in real time, which is a requirement for in-vehicle ADAS applications and a requirement for practical Level 3-5 autonomous vehicles.

Unlike traditional systems, the technology described here, by providing a CPU complex, a GPU complex and a hardware acceleration cluster, allows multiple neural networks to run simultaneously and/or sequentially and the results to be combined together to provide autonomous driving functions to enable levels 3-5. For example, a CNN running on the DLA or dGPU (e.g., GPU(s) 1220) may include text and word recognition that allows the supercomputer to read and understand traffic signs, including signs , for which the neural network has not been specifically trained. The DLA may further include a neural network capable of identifying, interpreting and providing a semantic understanding of the character and passing this semantic understanding to the path planning modules running on the CPU complex.

As another example, multiple neural networks may be running simultaneously as required for level 3, 4, or 5 driving. For example, a warning sign that reads “Caution: Flashing lights indicate slippery ice” along with an electric light can be interpreted independently or jointly by multiple neural networks. The sign itself can be identified as a traffic sign by a first deployed neural network (e.g. a neural network that has been trained), the text “Flashing lights indicate slippery ice” can be interpreted by a second deployed neural network tells the vehicle's path planning software (preferably running on the CPU complex) that if flashing lights are detected, there is slippery ice. The flashing light can be identified by operating a third neural network over multiple frames, which informs the vehicle's path planning software of the presence (or absence) of flashing lights. All three neural networks can run simultaneously, e.g. B. 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 identify the presence of an authorized driver and/or owner 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 turn on the lights, and, in security mode, to disarm the vehicle when the owner exits the vehicle. In this way the SoC(s) 1204 ensures security against theft and/or vehicle hijacking.

In another example, an emergency vehicle detection and identification CNN may use data from microphones 1296 to detect and identify emergency vehicle sirens. Unlike traditional systems that use general classifiers to detect sirens and manually extract features, the SoC(s) 1204 leverages the CNN to classify environmental and urban sounds as well as classify visual data. In a preferred embodiment, the CNN running on the DLA is trained to detect the relative approach speed of the emergency vehicle (e.g., using the Doppler effect). The CNN can also be trained to identify emergency vehicles specific to the local area in which the vehicle is operating, as identified by GNSS sensor(s) 1258. For example, in Europe, CNN will attempt to identify European sirens, while in the United States it 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, slowing the vehicle, pulling to the side of the road, parking the vehicle, and/or idling the vehicle using ultrasonic sensors 1262 until the emergency vehicle(s) have passed.

The vehicle may include a CPU(s) 1218 (e.g., discrete CPU(s) or dCPU(s)) that may be coupled to the SoC(s) 1204 via a high-speed connection (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 reconciling potentially inconsistent results between ADAS sensors and the SoC(s) 1204 and/or monitoring status and condition the controller(s) 1236 and/or the infotainment SoC 1230, for example.

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

The vehicle 1200 may further include the network interface 1224, which may include one or more wireless antennas 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 provide a wireless connection over the Internet to the cloud (e.g., to the server(s) 1278 and/or other network devices), to other vehicles, and/or to computing devices (e.g., B. client devices of the passengers). In order to communicate with other vehicles, a direct connection between the two vehicles and/or an indirect connection can be established (e.g. via networks and via the Internet). Direct connections can be made via a vehicle-to-vehicle communication link. The 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, next to, and/or behind the vehicle 1200). This function may be part of a cooperative adaptive cruise control function of the vehicle 1200.

The network interface 1224 may include an SoC that provides modulation and demodulation and allows the controller 1236 to communicate over wireless networks. The network interface 1224 may include a radio frequency front end for up-conversion from baseband to radio frequency and down conversion from radio frequency to baseband. The frequency conversions can be carried out by known processes and/or by super-heterodyne processes. In some examples, the radio frequency front-end function may be provided by a separate chip. The network interface may include wireless functions for communication via 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 1228, which may also include off-chip memory (e.g., off-the-SoC 1204). The data memories 1228 may include one or more storage 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 also include one or more GNSS sensors 1258 (e.g., GPS and/or assisted GPS sensors) to assist in mapping, sensing, occupancy grid generation, and/or path planning. Any number of GNSS sensors 1258 can be used, including e.g. B. a GPS device that uses a USB port with an Ethernet-to-serial bridge (RS-232).

The vehicle 1200 may also include one or more RADAR sensors 1260. The RADAR sensor 1260 can be used by the vehicle 1200 for remote vehicle detection, even in darkness and/or severe weather. The functional safety levels of the RADAR can be ASIL B. The RADAR sensor 1260 may use the CAN and/or the bus 1202 (e.g., to transmit the data generated by the RADAR sensor 1260) to control and access data for object tracking, which may be accessed via Ethernet in some examples to access raw data. A variety of RADAR sensor types can be used. For example, the RADAR sensors 1260 can be used without restrictions as front, rear and side RADAR. In some examples, Pulse Doppler RADAR sensors are used.

The RADAR sensors 1260 can include various configurations, e.g. 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, long-range RADAR systems can provide a wide field of view obtained by two or more independent scans, e.g. B. is realized within a range of 250 m. The RADAR sensors 1260 can help distinguish between static and moving objects and ADAS systems can be used for emergency braking support and collision warning. Long-range, long-range RADAR sensors may include monostatic multimodal 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 central four antennas may produce a focused beam pattern designed to record 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 leaving the path of vehicle 1200.

For example, medium-range RADAR systems can include a range of up to 160 m (front) or 80 m (rear) and a field of view of up to 42 degrees (front) or 150 degrees (rear). Short range RADAR systems may include, without limitation, RADAR sensors that may be installed at either end of the rear bumper. When installed at both ends of the rear bumper, such a RADAR sensor system can produce two beams that constantly monitor the blind spot in the rear and alongside 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 also include ultrasonic sensors 1262. The ultrasonic sensors 1262, which may be located at the front, rear, and/or sides of the vehicle 1200, may be used for parking and/or for creating and updating an occupancy grid. A variety of ultrasonic sensors 1262 and different ultrasonic sensors 1262 for different detection ranges (e.g. 2.5 m, 4 m) can be used. The 1262 ultrasonic sensors can work with functional safety level ASIL B.

The vehicle 1200 may include LIDAR sensors 1264. The LIDAR sensors 1264 can be used for object and pedestrian detection, emergency braking, collision avoidance and/or other functions. The 1264 LIDAR sensors can meet the ASIL B functional safety level. 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 sensors 1264 may provide a list of objects and their distances for a 360 degree field of view. Commercially available LIDAR sensors 1264 may have an advertised range of approximately 1200 m, an accuracy of 2 cm to 3 cm, and, for example, 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 sensors 1264 may be implemented as a small device that may be embedded in the front, rear, side, and/or corners of the vehicle 1200. In such examples, the LIDAR sensors 1264 can provide up to 120 degrees horizontal and 35 degrees vertical field of view with a range of 200 m, even for objects with low reflection. Front-mounted LIDAR sensors 1264 can 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 transmission source to illuminate the vehicle surroundings up to approximately 200 m. A LIDAR flash unit contains a receptor that detects the transmission time of the laser pulse and the reflected light on each pixel, which in turn corresponds to the range from the vehicle to the objects. Flash LIDAR can enable the creation of highly accurate and distortion-free images of the environment with each laser flash. In some examples, four LIDAR lightning sensors may 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 can use a Class I (eye-safe) laser pulse at 5 nanoseconds per image and capture the reflected laser light in the form of 3D 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 1264 LIDAR sensor may be less susceptible to motion blur, vibration and/or shock.

The vehicle may also include IMU sensors 1266. The IMU sensors 1266 may be located in the center of the rear axle of the vehicle 1200 in some examples. The IMU sensors 1266 can e.g. B. include one or more accelerometers, magnetometers, gyroscopes, magnetic compasses and / or other types of sensors. In some examples, such as For example, in six-axis applications, the IMU sensors may include 1266 accelerometers and gyroscopes, while in nine-axis applications The IMU sensors may include 1266 accelerometers, gyroscopes and magnetometers.

In some embodiments, the IMU sensors 1266 may be implemented as a miniature GPS-Aided Inertial Navigation System (GPS/INS) that includes micro-electro-mechanical systems (MEMS) inertial sensors, a highly sensitive GPS receiver, and advanced Kalman sensors. Filtering algorithms combined to provide estimates of position, velocity and inclination. In some examples, the IMU sensors 1266 may enable the vehicle 1200 to estimate heading without input from a magnetic sensor by observing and correlating the speed changes from GPS directly on the IMU sensors 1266. In some examples, IMU sensors 1266 and GNSS sensors 1258 may be combined into a single integrated unit.

The vehicle may be equipped with microphones 1296 placed in and/or around the vehicle 1200. The microphones 1296 can be used, among other things, to detect and identify emergency vehicles.

The vehicle may also include any number of camera types, including stereo cameras 1268, wide-angle cameras 1270, infrared cameras 1272, surround cameras 1274, long-range and mid-range cameras 1298, and/or other camera types. The cameras can be used to capture image data around an entire periphery of the vehicle 1200. The types of cameras used depend on the embodiments and requirements for the vehicle 1200, and any combination of camera types can be used to provide the required coverage around the vehicle 1200. In addition, 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. For example, and without limitation, the cameras may support Gigabit Multimedia Serial Link (GMSL) and/or Gigabit Ethernet. Each camera is referred to in this document 12 and 13 described.

The vehicle 1200 may also include vibration sensors 1242. The vibration sensors 1242 can measure vibrations of components of the vehicle, such as the axles. Changes in vibrations can, for example, indicate a change in the road surface. In another example, when using two or more vibration sensors 1242, the differences between the vibrations can be used to determine the friction or slip of the road surface (e.g., if the difference in vibration is between an electrically powered and a freely rotating axle).

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

The ACC systems may use RADAR sensors 1260, LIDAR sensors 1264 and/or cameras. The ACC systems may include longitudinal ACC and/or lateral ACC. The longitudinal ACC monitors and controls the distance to the vehicle immediately in front of the vehicle 1200 and automatically adjusts the vehicle speed to maintain a safe distance from the vehicles in front. The lateral ACC carries out the distance measurement and advises the vehicle 1200 to change lanes if necessary. The lateral ACC is related to other ADAS applications such as LC and CWS.

CACC uses information from other vehicles that can be received via network interface 1224 and/or wireless antenna(s) 1226 from other vehicles via a wireless connection or indirectly via a network connection (e.g., via the Internet). Direct connections can be provided via a V2V (Vehicle-to-Vehicle) communication link, while indirect connections can be I2V (Infrastructure-to-Vehicle) communication links. The V2V communication concept usually provides information about the vehicles immediately ahead (e.g. vehicles immediately in front of and on the same road as vehicle 1200), while the 12V communication concept provides information about the traffic further ahead. CACC systems can contain one or both 12V and V2V information sources. Given the information about the vehicles in front of vehicle 1200, CACC could be more reliable and have the potential to improve traffic flows and reduce road congestion.

FCW systems are designed to alert the driver to a hazard so the driver can take corrective action. FCW systems use a forward-facing camera and/or RADAR sensors 1260 coupled to a dedicated processor, DSP, FPGA and/or ASIC that is electrically coupled to driver feedback, e.g. B. a display, speakers and / or a vibrating component. FCW systems can issue a warning, e.g. B. in the form of a sound, a visual warning, a vibration and / or a quick braking pulse.

AEB systems detect an impending collision with another vehicle or object and can automatically apply the brakes if the driver does not take corrective action within a certain time or distance parameter. AEB systems may use forward-facing cameras and/or RADAR sensors 1260 coupled to a dedicated processor, DSP, FPGA and/or ASIC. When the AEB system detects a danger, it usually first warns the driver to take corrective action to avoid the collision. If the driver does not take corrective action, the AEB system can automatically apply the brakes to prevent, or at least mitigate, the effects of the predicted collision. AEB systems may include techniques such as dynamic brake support and/or emergency braking.

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

LKA systems are a variant of LDW systems. LKA systems provide steering inputs or braking to correct the vehicle 1200 when the vehicle 1200 leaves the roadway.

BSW systems detect and warn the driver of vehicles in an automobile's blind spot. BSW systems can provide a visual, audible and/or tactile alarm indicating that merging or changing lanes is unsafe. The system can provide an additional warning if the driver uses a turn signal. BSW systems may use rear-facing cameras and/or RADAR sensors 1260 coupled with a dedicated processor, DSP, FPGA and/or ASIC electrically coupled to driver feedback, e.g. B. a display, a speaker and / or a vibrating component.

RCTW systems can provide visual, audible and/or tactile notifications when an object is detected outside the range of the rearview camera when the vehicle 1200 is reversing. Some RCTW systems have AEB to ensure that the vehicle's brakes are activated to avoid an accident. 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, e.g. B. a display, a speaker and / or a vibrating component.

Traditional ADAS systems can be prone to false positives, which can be disruptive and distracting to the driver, but are usually not catastrophic because the ADAS systems alert the driver and allow the driver to decide whether a safety condition actually exists exists and to act accordingly. However, in the case of an autonomous vehicle 1200, when there are conflicting results, the vehicle 1200 itself must decide whether the result of a primary or a secondary computer (e.g., a first controller 1236 or a second controller 1236) should be taken into account. For example, in some embodiments, the ADAS system 1238 may be a backup and/or secondary computer to provide perception information to a rationality module of the backup computer. The backup computer rationality monitor can run redundant, diverse software on hardware components to detect perception errors and dynamic driving tasks. Outputs from the ADAS system 1238 may be provided to a higher level MCU. When outputs from the primary computer and the secondary computer conflict, the parent MCU must determine how to reconcile the conflict to ensure safe operation.

In some examples, the primary computer may be configured to provide the parent MCU with a confidence value indicating the primary computer's confidence in the selected result. If the confidence value exceeds a threshold, the parent MCU can follow the direction of the primary computer regardless of whether the secondary Com computer produces a contradictory or inconsistent result. If the confidence value does not reach the threshold and the primary and secondary computers show different results (such as the conflict), the higher-level MCU can decide between the computers to determine the appropriate result.

The higher-level MCU may be configured to run a neural network trained and configured to determine conditions under which the secondary computer issues false alarms based on the outputs of the primary computer and the secondary computer. This allows the neural networks in the parent MCU to learn when the output of the secondary computer is trustworthy and when it is not. For example, if the secondary computer is a RADAR-based FCW system, neural networks in the parent MCU can detect when the FCW system identifies metallic objects that actually do not pose threats, such as: B. a drainage grate or a manhole cover that triggers an alarm. If the secondary computer is a camera-based LDW system, a neural network in the parent MCU can learn to override the LDW when cyclists or pedestrians are present and changing lanes is actually the safest maneuver. In embodiments that include a neural network running on the parent MCU, the parent MCU may include at least one DLA or GPU capable of operating the neural network with associated memory. In preferred embodiments, the higher-level MCU may be included and/or incorporated as part of the SoC 1204.

In other examples, the ADAS system 1238 may include a secondary computer that performs the ADAS functionality using conventional computer vision rules. Therefore, the secondary computer can use classic computer vision rules (if-then), and the presence of a neural network in the parent MCU can improve reliability, security and performance. For example, diverse implementation and intentional non-identity make the overall system more fault-tolerant, especially to errors caused by the functionality of the software (or software-hardware interface). For example, if there is a software error or error in the software on the primary computer and the non-identical software code on the secondary computer produces the same overall result, the parent MCU may have more confidence in the overall result and the error in the software or hardware provided by that primary computer does not cause a significant error.

In some examples, the output of the ADAS system 1238 may be fed into the primary computer's perception block and/or the primary computer's dynamic driving task block. For example, if the ADAS system 1238 displays a 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 trained neural network, reducing the risk of false positives, as described here.

The vehicle 1200 may also include the infotainment SoC 1230 (e.g., an in-vehicle infotainment (IVI) system). Although the infotainment system is shown and described as an SoC, it may not be an SoC and may contain two or more separate 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.), telephone (e.g. hands-free), network connectivity (e.g. LTE, Wi-Fi, etc.) and/or information services (e.g. navigation systems, rear parking sensors, a wireless data system , vehicle-related information such as fuel level, total distance traveled, brake fluid level, oil level, door open/close, air filter information, etc.). For example, the infotainment SoC 1230 can support radios, CD players, navigation systems, video players, USB and Bluetooth connectivity, carputers, in-car entertainment, Wi-Fi, steering wheel audio controls, hands-free voice controls, a heads-up system. Display (HUD), an HMI display 1234, a telematics device, a control panel (e.g., for controlling and/or interacting with various components, functions and/or systems), and/or other components. The infotainment SoC 1230 may also be used to provide information (e.g., visual and/or audible) to users of the vehicle, e.g. B. information from the ADAS system 1238, autonomous driving information such as planned vehicle maneuvers, trajectories, environmental data (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 can be connected via the bus 1202 (e.g. CAN bus, Ether net, etc.) communicate with other devices, systems and/or components of the vehicle 1200. In some examples, the infotainment SoC 1230 may be coupled to a higher-level MCU so that the infotainment system's GPU can perform some self-driving functions if the primary controller 1236 (e.g., the vehicle's primary and/or backup computer 1200) fails. In such an example, the infotainment SoC 1230 may place the vehicle 1200 into safe stop mode, as described herein.

The vehicle 1200 may also 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 supercomputers (e.g., a discrete controller or supercomputer). The 1232 instrument cluster can display a variety of instruments such as speedometer, fuel level, oil pressure, tachometer, odometer, turn signals, shift position indicator, seat belt warning light(s), parking brake warning light(s), engine malfunction indicator(s), airbag (SRS) system information, lighting controls, controls the security system, 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 can be included as part of the infotainment SoC 1230 or vice versa.

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

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

The servers 1278 may receive image data over the networks 1290 and from the vehicles, representing images showing unexpected or changing road conditions, such as: E.g. recently started road works. The servers 1278 may transmit, over the networks 1290 and to the vehicles, neural networks 1292, updated neural networks 1292 and/or map information 1294, including information about traffic and road conditions. The updates to the map information 1294 may include updates to the HD map 1222, such as: B. Information about construction sites, potholes, detours, floods and/or other obstacles. In some examples, the neural networks 1292, the updated neural networks 1292, and/or the map information 1294 may result from new training and/or experiences represented in data from any number of vehicles in the environment, and/or based on training provided be performed in a data center (e.g. using servers 1278 and/or other servers).

The servers 1278 can be used to train machine learning models (e.g., neural networks) based on training data. The training data can be generated by the vehicles and/or generated in a simulation (e.g. with a game engine). In some examples, the training data is marked (e.g., when the neural network benefits from supervised learning) and/or undergoes other preprocessing, while in other examples, the training data is not marked and/or preprocessed (e.g., when the neural network network does not require supervised learning). Training can be conducted according to one or more classes of machine learning techniques, including but not limited to courses such as: supervised training, semi-supervised training, unsupervised training, self-learning, reinforcement learning, federated learning, transfer learning, feature learning (including principal components - and cluster analyses), multilinear subspace learning, manifold learning, representation learning (including surrogate dictionary learning), rule-based machine all learning, anomaly detection and any variants 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 1290) and/or the machine learning models may be transmitted from the servers 1278 Remote monitoring of vehicles can be used.

In some examples, the server 1278 may receive data from the vehicles and apply the data to current real-time neural networks to enable intelligent real-time inferences. The servers 1278 may include deep learning supercomputers and/or dedicated AI computers with GPUs 1284, such as: B. DGX and DGX station machines developed by NVIDIA. However, in some examples, servers 1278 may contain deep learning infrastructure that uses only CPU-powered data centers.

The deep learning infrastructure of the servers 1278 may enable rapid, real-time inference and use this capability to assess and verify the health of the processors, software, and/or associated hardware in the vehicle 1200. For example, the deep learning infrastructure may receive regular updates from the vehicle 1200, such as: B. a sequence of images and/or objects that the vehicle 1200 has located in that sequence of images (e.g., through computer vision and/or other machine learning object classification techniques). The deep learning infrastructure can operate its own neural network to identify the objects and compare them with the objects identified by the vehicle 1200. If the results do not agree and the infrastructure concludes that the AI in the vehicle 1200 is defective, the server 1278 may send a signal to the vehicle 1200 instructing a fail-safe computer of the vehicle 1200 to take control of the passengers to notify and carry out a safe parking maneuver.

For inferencing, the servers 1278 may include the GPUs 1284 and one or more programmable inference accelerators (e.g., NVIDIA TensorRT). The combination of GPU-based servers and inference acceleration can enable real-time responsiveness. In other examples, e.g. For example, when performance is less critical, servers with CPUs, FPGAs and other processors can be used for inference.

EXEMPLARY COMPUTING DEVICE

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

Although the various blocks of the 16 are shown as connected to lines via the connection system 1602, this is not intended to be limiting and is for convenience only. For example, in some embodiments, a presentation component 1618, such as. B. a display device, can be considered an I/O component 1614 (e.g. if the display is a touchscreen). As another example, 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 GPUs 1608, CPUs 1606, and/or other components). In other words, the computing device is off 16 merely illustrative. It does not distinguish between categories such as "workstation", "server", "laptop", "desktop", "tablet", "client device", "mobile device", "handheld device", "game console", "electronic control device ( electronic control unit - ECU)", "virtual reality system", an "augmented reality system" and/or other types of devices or systems, as they are all within the scope of the computing device 16 be seen.

The connection system 1602 may represent one or more connections or buses, e.g. B. an address bus, a data bus, a control bus or a combination thereof. The connection system 1602 may include one or more types of buses or connections, e.g. B. an ISA bus (Industry Standard Architecture), an EISA bus (Extended Industry Standard Architecture), a VESA bus (Video Electronics Standards Association), a PCI bus (Peripheral Component Interconnect), a PCIe bus (Peripheral Component Interconnect Express) and/or another bus or connection type. In some embodiments, there are direct connections between components. As an example, CPU 1606 can be connected directly to memory 1604. In addition, the CPU 1606 can be connected directly to the GPU 1608. For direct or point-to-point connection between components, the connection system 1602 may include a PCIe connection to perform the connection. In the In these examples, no PCI bus needs to be included in the computing device 1600.

Memory 1604 may include a variety of computer-readable media. The computer-readable media can be any available media that the computing device 1600 can access. 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 communication media.

The computer storage medium may include both volatile and non-volatile media 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 types of data. Memory 1604 may, for example, store computer-readable instructions (e.g., representing one or more programs and/or program elements, e.g. an operating system). Storage media for computers include, but are 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 on which the computing device 1600. As used here, the storage media for computers do not have signals per se.

The computer's storage media may contain computer-readable instructions, data structures, program modules, and/or other types of data in a modulated data signal, such as: B. a carrier wave or other transport mechanism, and include all information media. The term “modulated data signal” can refer to a signal that has one or more of its properties adjusted or changed to encode information in the signal. By way of example, and not limitation, the computer's storage media may include wired media, such as a wired network or direct wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of the above should also be included within the scope of computer-readable media.

The CPUs 1606 may be configured to execute at least some of the computer-readable instructions to control one or more components of the computer 1600 to perform one or more of the methods and/or processes described herein. The CPUs 1606 may each include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of processing a plurality of software threads simultaneously. The CPUs 1606 may include any type of processor and may include different types of processors depending on the type of computing device 1600 being implemented (e.g., processors with fewer cores for mobile devices and processors with more cores for servers). Depending on the computing device 1600, it can be, for example, an Advanced RISC Machine (ARM) processor with reduced instruction set computing (RISC) or an x86 processor with complex instruction set computing (CISC). The computing device 1600 may in addition to one or more microprocessors or additional coprocessors, such as. B. mathematical coprocessors, one or more CPUs 1606 included.

The GPUs 1608 may further or alternatively be configured by the CPUs 1606 to execute at least some computer-readable instructions to control one or more components of the computer 1600 to perform one or more of the methods and/or processes described herein. One or more GPUs 1608 may be an integrated GPU (e.g., with one or more CPUs 1606) and/or one or more GPUs 1608 may be a separate GPU. In embodiments, one or more GPUs 1608 may be a coprocessor of one or more CPUs 1606. The GPUs 1608 may be used by the computing device 1600 to render graphics (e.g., 3D graphics) or perform general calculations. For example, the GPUs 1608 can be used for general-purpose computing on GPUs (GPGPU). The GPUs 1608 can contain hundreds or thousands of cores that can process hundreds or thousands of software threads simultaneously. The GPUs 1608 may generate pixel data for output images in response to rendering commands (e.g., rendering commands from the CPUs 1606 received via a host interface). The GPUs 1608 can support graphics memory such as: B. Display memory, for storing pixel data or other suitable data, such as GPGPU data. Display memory may be included as part of memory 1604. The GPUs 1608 may include two or more GPUs operating in parallel (e.g., over an interconnect). The connection can connect the GPUs directly (e.g. via NVLINK) or connect the GPUs via a switch (e.g. via NVSwitch). When combined together, each GPU 1608 can generate pixel data or GPGPU data for different parts 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 share memory with other GPUs.

The logic units 1620 may further or alternatively be configured by the CPUs 1606 and/or the GPUs 1608 to execute at least some computer-readable instructions to control one or more components of the computer 1600 to perform one or more of the methods and/or described herein Execute processes. In embodiments, the CPUs 1606, the GPUs 1608, and/or the logic units 1620 may discretely 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 one or more CPUs 1606 and/or GPUs 1608 and/or one or more of the logic units 1620 may be discrete components or otherwise external to the CPUs 1606 and/or the GPUs 1608. In embodiments, one or more logic units 1620 may be a coprocessor of one or more CPUs 1606 and/or one or more GPUs 1608.

Examples of the logic units 1620 include one or more processor cores and/or components thereof, such as Tensor Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs) , Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Tree Traversal Units (TTUs), Artificial Intelligence (AIAS), Accelerators (AIAS) Deep Learning Accelerators (DLAs), Arithmetic-Logic Units (ALUs), Application -Specific Integrated Circuits (ASICs), Floating Point Units (FPUs), input/output (I/O) elements, Peripheral Component Interconnect (PCI) or Peripheral Component Interconnect Express (PCIe) elements and/or similar.

The communications 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 communications network, including wired and/or wireless communications. The communication interface 1610 may include components and functions that enable communication over a number of different networks, such as: B. wireless networks (e.g. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g. communication via 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 are built into the computing device 1600 (e.g. integrated). The I/O components 1614 include a microphone, mouse, keyboard, joystick, gamepad, game controller, satellite dish, scanner, printer, wireless device, etc. The I/O components 1614 may have a natural user interface interface (NUI) that processes air gestures, voice, or other physiological input generated by a user. In some cases, inputs can be transferred to an appropriate network element for further processing. A NUI can implement any combination of voice recognition, tactile recognition, facial recognition, biometric recognition, both on-screen and near-screen gesture recognition, air gestures, head and eye tracking, and touch recognition (as further described below) using a Display of the computing device 1600 is connected. 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. In addition, 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 from the computing device 1600 may be used to display immersive augmented reality or virtual reality.

The power supply 1616 may 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 display components 1618 may include a display (e.g., a monitor, a touch screen, a television screen, a heads-up display (HUD), other display types, or a combination thereof), speakers, and/or other display components. The presentation components 1618 may receive data from other components (e.g., GPUs 1608, CPUs 1606, etc.). and output the data (e.g. as image, video, sound, 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 that are executed by a computer or other machine such as a personal data assistant or other handheld device. In general, program modules including routines, programs, objects, components, data structures, etc. refer to code that performs specific tasks or implements specific abstract data types. The disclosure may be embodied in a variety of system configurations, including handheld devices, consumer electronics, general purpose computers, more specialized computing devices, etc. The disclosure may also be embodied in distributed computing environments in which tasks are performed by remote processing devices connected via a communications network .

1. 1. Integrierte Schaltung, umfassend:
   • einen ersten Takt;
   • einen zweiten Takt, der von dem ersten Takt isoliert ist;
   • einen ersten Stromanschluss;
   • einen zweiten Stromanschluss, der von dem ersten Stromanschluss isoliert ist; einen ersten Abschnitt, um Strom mittels des ersten Stromanschlusses und ein erstes Taktsignal mittels des ersten Takts zu empfangen; und einen zweiten Abschnitt, um Strom mittels des zweiten Stromanschlusses und ein zweites Taktsignal mittels des zweiten Takts zu empfangen, wobei der zweite Abschnitt eine Schnittstelle zur Kommunikation mit dem ersten Abschnitt, eine Schnittstellensteuerung und einen Prozessor zum Sperren und Entsperren der Schnittstellensteuerung umfasst, wobei die Schnittstellensteuerung eine Kommunikation über die Schnittstelle verhindert, wenn die Schnittstellensteuerung gesperrt ist, und wobei die Schnittstellensteuerung eine Kommunikation über die Schnittstelle zulässt, wenn die Schnittstellensteuerung entsperrt ist.
2. 2. Integrierte Schaltung nach Satz 1,
   • wobei der erste Abschnitt einen ersten Fehleraggregator umfasst, um an den zweiten Abschnitt Hinweise zu übermitteln, die einem oder mehreren Fehlern entsprechen, die in dem ersten Abschnitt auftreten,
   • wobei der zweite Abschnitt einen zweiten Fehleraggregator umfasst, um die dem einen oder den mehreren Fehlern entsprechenden Hinweise zu empfangen und zu speichern,
   • wobei die integrierte Schaltung eine Fehlerschnittstelle umfasst, die den ersten und den zweiten Fehleraggregator verbindet,
   • wobei die Fehlerschnittstelle von der Schnittstelle getrennt ist, und wobei der Prozessor die Schnittstellensteuerung nur dann entsperrt, wenn der zweite Fehleraggregator keine Hinweise speichert, die irgendwelchen Fehlern entsprechen.
3. 3. Integrierte Schaltung nach Satz 1 oder 2, wobei der zweite Abschnitt einen Timer umfasst, der startet, wenn der Prozessor eine Kommunikation mit dem ersten Abschnitt über die Schnittstelle einleitet, und wobei der Timer einen Hinweis auf einen Fehler erzeugt, wenn der Timer anzeigt, dass mehr als eine vorbestimmte Zeitspanne verstrichen ist und der erste Abschnitt nicht auf die Kommunikation geantwortet hat.
4. 4. Integrierte Schaltung nach Satz 3, wobei der Timer zurückgesetzt wird, wenn der erste Abschnitt auf die Kommunikation antwortet, bevor der Timer anzeigt, dass mehr als die vorgegebene Zeitspanne verstrichen ist, und wobei der Prozessor die Schnittstelle sperrt, nachdem der Prozessor die Kommunikation mit dem ersten Abschnitt beendet hat.
5. 5. Integrierte Schaltung nach einem der Sätze 1-4, die darüber hinaus umfasst:
   • einen nichtflüchtigen Speicher, der von dem ersten und dem zweiten Abschnitt gemeinsam genutzt wird, wobei der zweite Abschnitt einen lokalen Speicher umfasst, wobei der Prozessor Anweisungen von dem nichtflüchtigen Speicher in den lokalen Speicher kopiert, wenn die integrierte Schaltung bootet, wobei die Anweisungen von dem Prozessor auszuführen sind, wenn die Schnittstelle gesperrt ist.
6. 6. Integrierte Schaltung nach einem der Sätze 1-5, wobei der erste Abschnitt einen flüchtigen Speicher umfasst, und wobei der zweite Abschnitt mit dem flüchtigen Speicher über die Schnittstelle kommuniziert.
7. 7. Integrierte Schaltung nach einem der Sätze 1-6, die sich auf einem zusammenhängenden Stück Halbleitermaterial befindet.
8. 8. Integrierte Schaltung nach einem der Sätze 1-7, die einen Abschnitt eines System on a Chip („SoC“) für Fahrzeuge implementiert.
9. 9. Integrierte Schaltung nach einem der Sätze 1-8, wobei der erste Abschnitt auf einer ersten Risikoklassifizierungsstufe arbeitet, wobei der zweite Abschnitt auf einer zweiten Risikoklassifizierungsstufe arbeitet, und wobei die zweite Risikoklassifizierungsstufe höher ist als die erste Risikoklassifizierungsstufe.
10. 10. Verfahren umfassend:
    • Bestimmen, durch einen ersten Abschnitt einer integrierten Schaltung, ob ein Fehleraggregator in dem ersten Abschnitt Daten enthält, die auf mindestens eine vorbestimmte Anzahl von Fehlern hinweisen;
    • Entsperren einer Schnittstelle mit einem zweiten Abschnitt der integrierten Schaltung durch den ersten Abschnitt, wenn der erste Abschnitt feststellt, dass der Fehleraggregator keine Daten enthält, die auf zumindest die vorbestimmte Anzahl von Fehlern hinweisen;
    • Einleiten eines Zugriffs auf den zweiten Abschnitt durch den ersten Abschnitt über die entsperrte Schnittstelle; und
    • Sperren der Schnittstelle durch den ersten Abschnitt, nachdem der Zugriff eingeleitet wurde.
11. 11. Verfahren nach Satz 10, wobei das Einleiten des Zugriffs einen Zugriffs-Timer startet, und wobei der erste Abschnitt die Schnittstelle sperrt, nachdem ein Erfassen des Zugriffs-Timers anzeigt, dass mehr als eine vorbestimmte Zeitspanne seit dem Start des Zugriffs-Timers verstrichen ist und eine Antwort von dem zweiten Abschnitt nicht empfangen worden ist.
12. 12. Verfahren nach Satz 11, wobei der erste Abschnitt einen neuen Fehler erzeugt, nachdem ein Erfassen des Zugriffs-Timers anzeigt, dass mehr als eine vorbestimmte Zeitspanne seit dem Start des Zugriffs-Timers verstrichen ist und eine Antwort von dem zweiten Abschnitt nicht empfangen worden ist.
13. 13. Verfahren nach einem der Sätze 10-12, wobei das Einleiten des Zugriffs einen Zugriffs-Timer startet und das Verfahren darüber hinaus umfasst: Empfangen einer Antwort von dem zweiten Abschnitt durch den ersten Abschnitt, bevor der Zugriffs-Timer anzeigt, dass mehr als eine vorbestimmte Zeitspanne seit dem Start des Zugriffs-Timers verstrichen ist, wobei das Empfangen der Antwort den Zugriffs-Timer stoppt, wobei der erste Abschnitt die Schnittstelle nach Beendigung des Zugriffs sperrt.
14. 14. Verfahren nach einem der Sätze 10-13, das darüber hinaus umfasst: Durchführen einer oder mehrerer Korrekturmaßnahmen durch den ersten Abschnitt, wenn der erste Abschnitt feststellt, dass der Fehleraggregator Daten enthält, die auf zumindest die vorbestimmte Anzahl von Fehlern hinweisen.
15. 15. Verfahren nach Satz 14, wobei die integrierte Schaltung einen Abschnitt eines System on a Chip („SoC“) für Fahrzeuge implementiert, und wobei die eine oder die mehreren Korrekturmaßnahmen ausgestaltet sind, um ein autonomes Fahrzeug in einen sicheren Zustand zu versetzen.
16. 16. Verfahren nach einem der Sätze 10-15, wobei die integrierte Schaltung einen Abschnitt eines System on a Chip, „SoC“, für Fahrzeuge implementiert, wobei der erste Abschnitt Sicherheitsfunktionen für ein autonomes Fahrzeug durchführt, während das autonome Fahrzeug fährt, und wobei der zweite Abschnitt autonome Fahrfunktionen während des Fahrens des autonomen Fahrzeugs ausführt.
17. 17. Verfahren nach einem der Sätze 10-16, wobei die Schnittstelle den ersten Abschnitt mit einem flüchtigen Speicher oder einem Steuer-Backbone des zweiten Abschnitts verbindet.
18. 18. Verfahren nach einem der Sätze 10-17, wobei der erste Abschnitt in einem ersten Taktbereich arbeitet, wobei der zweite Abschnitt in einem zweiten Taktbereich arbeitet, der sich von dem ersten Taktbereich unterscheidet, und wobei die Schnittstelle eine Phasensynchronisationsschaltung umfasst, die ein von dem zweiten Abschnitt empfangenes Signal in den ersten Taktbereich konvertiert.
19. 19. Integrierte Schaltung, umfassend:
    • einen ersten Abschnitt, der mit einer ersten Risikostufe innerhalb eines ersten Bereichs arbeitet; und
    • einen zweiten Abschnitt, der mit einer zweiten Risikostufe innerhalb eines zweiten Bereichs arbeitet, wobei die zweite Risikostufe größer als die erste Risikostufe ist,
    • wobei der zweite Abschnitt einen Prozessor und eine Schnittstelle, die den ersten und den zweiten Abschnitt verbindet, umfasst, wobei der Prozessor die Schnittstelle selektiv sperrt, um eine Kommunikation über die Schnittstelle zu verhindern, wobei der Prozessor die Schnittstelle selektiv entsperrt, um eine Kommunikation über die Schnittstelle zu ermöglichen.
20. 20. Integrierte Schaltung nach Satz 19, die darüber hinaus umfasst:
    • einen ersten Stromanschluss, der den ersten Bereich mit Strom versorgt; und
    • einen zweiten Stromanschluss, der von dem ersten Stromanschluss elektrisch isoliert ist und den zweiten Bereich mit Strom versorgt, wobei die Schnittstelle mindestens einen Spannungsschieber zum Einstellen einer Spannung für jegliche Kommunikation über die Schnittstelle umfasst.
21. 21. Integrierte Schaltung nach Satz 19 oder 20, die darüber hinaus umfasst:
    • einen ersten Takt, der den ersten Bereich mit einem ersten Taktsignal versorgt; und
    • einen zweiten Takt, der von dem ersten Takt isoliert ist und den zweiten Bereich mit einem zweiten Taktsignal versorgt, wobei die Schnittstelle eine Phasensynchronisationsschaltung zum Einstellen einer Phase jeglicher Kommunikation über die Schnittstelle umfasst.
22. 22. Integrierte Schaltung nach einem der Sätze 19-21, wobei die Schnittstelle eine Firewall umfasst, die eine oder mehrere Sicherheitsregeln implementiert, und wobei die Firewall eine Kommunikation über die Schnittstelle auf der Grundlage der einen oder der mehreren Sicherheitsregeln erlaubt oder blockiert.
23. 23. Integrierte Schaltung nach einem der Sätze 19-22, wobei der erste Abschnitt einen ersten Fehleraggregator umfasst, um Daten, die einen in dem ersten Abschnitt auftretenden Fehler anzeigen, an den zweiten Abschnitt zu übermitteln, wobei der zweite Abschnitt einen zweiten Fehleraggregator umfasst, um die den Fehler anzeigende Daten zu empfangen und die den Fehler anzeigende Daten zu speichern, bis der Fehler durch den Prozessor gelöscht wird, wobei die integrierte Schaltung eine Fehlerschnittstelle umfasst, die den ersten und den zweiten Fehleraggregator verbindet, wobei die Fehlerschnittstelle von der Schnittstelle getrennt ist, und wobei der Prozessor die Schnittstelle erst dann entsperrt, wenn Fehler, die den Daten entsprechen, die auf irgendwelche von dem zweiten Fehleraggregator gespeicherten Fehler hinweisen, von dem Prozessor gelöscht worden sind.
24. 24. Integrierte Schaltung nach einem der Sätze 19-23, wobei der zweite Abschnitt einen Timer umfasst, der startet, wenn der Prozessor die Schnittstelle entsperrt, und wobei der Timer einen neuen Fehler erzeugt, wenn der Timer anzeigt, dass mehr als eine vorbestimmte Zeitspanne verstrichen ist und der erste Abschnitt nicht auf eine an den ersten Abschnitt über die Schnittstelle gesendete Kommunikation geantwortet hat.
25. 25. Integrierte Schaltung nach Satz 24, wobei der Timer zurückgesetzt wird, wenn der erste Abschnitt auf die Kommunikation antwortet, bevor der Timer anzeigt, dass mehr als die vorbestimmte Zeitspanne verstrichen ist, und wobei der Prozessor die Schnittstelle sperrt, nachdem der Prozessor die Kommunikation mit dem ersten Abschnitt beendet hat.
26. 26. Integrierte Schaltung nach einem der Sätze 19-25, wobei der erste Abschnitt einen nichtflüchtigen Speicher umfasst, der von dem ersten und dem zweiten Abschnitt gemeinsam genutzt wird, wobei der zweite Abschnitt einen lokalen Speicher umfasst, wobei der Prozessor Anweisungen von dem nichtflüchtigen Speicher in den lokalen Speicher kopiert, wenn die integrierte Schaltung bootet, und wobei die Anweisungen von dem Prozessor ausgeführt werden, wenn die Schnittstelle gesperrt ist.
27. 27. Integrierte Schaltung nach einem der Sätze 19-26, wobei der erste Abschnitt einen flüchtigen Speicher umfasst, und wobei der zweite Abschnitt mit dem flüchtigen Speicher über die Schnittstelle kommuniziert.
28. 28. Integrierte Schaltung nach einem der Sätze 19-27, wobei der erste Abschnitt ein Steuer-Backbone umfasst, wobei die Schnittstelle mit dem Steuer-Backbone verbunden ist, und wobei der zweite Abschnitt mit mindestens einem Teil des ersten Abschnitts über die Schnittstelle und das Steuer-Backbone kommuniziert.
29. 29. Integrierte Schaltung nach einem der Sätze 19-28, die sich auf einem zusammenhängenden Stück Halbleitermaterial befindet.
30. 30. Integrierte Schaltung nach einem der Sätze 19-29, die einen Abschnitt eines System on a Chip, „SoC“, für Kraftfahrzeuge implementiert.
31. 31. Integrierte Schaltung nach einem der Sätze 19-30, wobei der zweite Abschnitt eine Vielzahl von Schnittstellen umfasst, die die Schnittstelle umfassen, wobei jede der Vielzahl von Schnittstellen den zweiten Abschnitt mit einem entsprechenden Teil des ersten Abschnitts verbindet, wobei der Prozessor selektiv eine bestimmte der Vielzahl von Schnittstellen entsperrt, um eine Kommunikation über die bestimmte Schnittstelle mit dem entsprechenden Teil des ersten Abschnitts zu ermöglichen.
32. 32. Integrierte Schaltung nach Satz 31, wobei der Prozessor selektiv eine beliebige der Vielzahl von Schnittstellen, die entsperrt ist, sperrt, um eine Kommunikation über die Vielzahl von Schnittstellen mit dem ersten Abschnitt zu verhindern.

At least one embodiment of the disclosure can be described with reference to the following sentences.

1. 1. Integrated circuit comprising:
   • a first bar;
   • a second clock isolated from the first clock;
   • a first power connection;
   • a second power terminal isolated from the first power terminal; a first section for receiving power via the first power terminal and a first clock signal via the first clock; and a second section for receiving power via the second power terminal and a second clock signal via the second clock, the second section comprising an interface for communicating with the first section, an interface controller and a processor for locking and unlocking the interface controller, the Interface control prevents communication over the interface when the interface control is locked, and wherein the interface control allows communication over the interface when the interface control is unlocked.
2. 2. Integrated circuit according to sentence 1,
   • wherein the first section includes a first error aggregator for transmitting to the second section indications corresponding to one or more errors occurring in the first section,
   • wherein the second section includes a second error aggregator to receive and store the indications corresponding to the one or more errors,
   • wherein the integrated circuit includes a fault interface connecting the first and second fault aggregators,
   • wherein the error interface is separate from the interface, and wherein the processor unlocks the interface control only if the second error aggregator does not store indications corresponding to any errors.
3. 3. Integrated circuit according to sentence 1 or 2, wherein the second section comprises a timer that starts when the processor initiates communication with the first section via the interface, and wherein the timer generates an indication of an error when the timer indicates , that more than a predetermined amount of time has passed and the first section has not responded to the communication.
4. 4. Integrated circuit according to sentence 3, wherein the timer is reset if the first section responds to the communication before the timer indicates that more than the predetermined amount of time has elapsed, and wherein the processor blocks the interface after the processor has completed the communication finished with the first section.
5. 5. Integrated circuit according to one of sentences 1-4, which also includes:
   • a non-volatile memory shared by the first and second sections, the second section comprising a local memory, the processor copying instructions from the non-volatile memory to the local memory when the integrated circuit boots, the instructions from the Processor must be executed when the interface is blocked.
6. 6. The integrated circuit of any one of sentences 1-5, wherein the first portion comprises a volatile memory, and wherein the second portion communicates with the volatile memory via the interface.
7. 7. Integrated circuit according to one of sentences 1-6, which is located on a continuous piece of semiconductor material.
8. 8. Integrated circuit according to one of sentences 1-7, which implements a portion of a system on a chip (“SoC”) for vehicles.
9. 9. Integrated circuit according to one of sentences 1-8, wherein the first section operates at a first risk classification level, the second section operates at a second risk classification level, and wherein the second risk classification level is higher than the first risk classification level.
10. 10. Procedure comprising:
    • determining, by a first section of an integrated circuit, whether a fault aggregator in the first section contains data indicative of at least a predetermined number of faults;
    • unlocking an interface with a second portion of the integrated circuit by the first portion when the first portion determines that the error aggregator does not contain data indicative of at least the predetermined number of errors;
    • Initiating access to the second section by the first section via the unlocked interface; and
    • Locking the interface through the first section after access is initiated.
11. 11. The method of sentence 10, wherein initiating access starts an access timer, and wherein the first section disables the interface after detection of the access timer indicates that more than a predetermined amount of time has elapsed since the start of the access timer and a response from the second section has not been received.
12. 12. The method of sentence 11, wherein the first section generates a new error after a detection of the access timer indicates that more than a predetermined period of time has elapsed since the start of the access timer and a response from the second section has not been received is.
13. 13. The method of any of sentences 10-12, wherein initiating access starts an access timer and the method further comprises: receiving a response from the second section by the first section before the access timer indicates that more than a predetermined period of time has elapsed since the start of the access timer, receiving the response stops the access timer, the first section locking the interface after the access is completed.
14. 14. The method of any of sentences 10-13, further comprising: performing one or more corrective actions by the first section when the first section determines that the error aggregator contains data indicating at least the predetermined number of errors.
15. 15. The method according to sentence 14, wherein the integrated circuit implements a portion of a system on a chip (“SoC”) for vehicles, and wherein the one or more corrective measures are designed to place an autonomous vehicle in a safe state.
16. 16. The method of any of sentences 10-15, wherein the integrated circuit implements a portion of a system on a chip, “SoC,” for vehicles, the first portion performing safety functions for an autonomous vehicle while the autonomous vehicle is driving, and wherein the second section carries out autonomous driving functions while driving the autonomous vehicle.
17. 17. The method of any of sentences 10-16, wherein the interface connects the first section to a volatile memory or a control backbone of the second section.
18. 18. The method of any of sentences 10-17, wherein the first section operates in a first clock range, the second section operates in a second clock range different from the first clock range, and wherein the interface comprises a phase synchronization circuit that includes one of The signal received in the second section is converted into the first clock range.
19. 19. Integrated circuit comprising:
    • a first section operating at a first level of risk within a first range; and
    • a second section that operates with a second risk level within a second range, the second risk level being greater than the first risk level,
    • wherein the second section includes a processor and an interface connecting the first and second sections, the processor selectively disabling the interface to prevent communication via the interface, the processor selectively unlocking the interface to enable communication via to enable the interface.
20. 20. Integrated circuit according to sentence 19, which also includes:
    • a first power connector that supplies power to the first region; and
    • a second power port that is electrically isolated from the first power port and supplies power to the second region, the interface comprising at least one voltage slider for setting a voltage for any communication via the interface.
21. 21. Integrated circuit according to sentence 19 or 20, which also includes:
    • a first clock that supplies the first area with a first clock signal; and
    • a second clock isolated from the first clock and providing the second region with a second clock signal, the interface comprising a phase synchronization circuit for adjusting a phase of any communication via the interface.
22. 22. The integrated circuit of any of sentences 19-21, wherein the interface includes a firewall that implements one or more security rules, and wherein the firewall allows or blocks communication over the interface based on the one or more security rules.
23. 23. Integrated circuit according to one of sentences 19-22, wherein the first section comprises a first error aggregator for transmitting data indicative of an error occurring in the first section to the second section, the second section comprising a second error aggregator, to receive the data indicating the error and to store the data indicating the error until the error is cleared by the processor, the integrated circuit comprising an error interface connecting the first and second error aggregators, the error interface being separate from the interface and wherein the processor unlocks the interface only after errors corresponding to the data indicative of any errors stored by the second error aggregator have been cleared by the processor.
24. 24. The integrated circuit of any of sentences 19-23, wherein the second portion comprises a timer that starts when the processor unlocks the interface, and wherein the timer generates a new error if the timer indicates that more than a predetermined period of time has elapsed and the first section has not responded to a communication sent to the first section via the interface.
25. 25. The integrated circuit of sentence 24, wherein the timer is reset if the first section responds to the communication before the timer indicates that more than the predetermined amount of time has elapsed, and wherein the processor disables the interface after the processor completes the communication finished with the first section.
26. 26. The integrated circuit of any of sentences 19-25, wherein the first section comprises a non-volatile memory shared by the first and second sections, the second section comprising a local memory, the processor receiving instructions from the non-volatile memory copied to local memory when the integrated circuit boots, and the instructions are executed by the processor when the interface is locked.
27. 27. The integrated circuit of any of sentences 19-26, wherein the first portion includes a volatile memory, and wherein the second portion communicates with the volatile memory via the interface.
28. 28. Integrated circuit according to one of sentences 19-27, wherein the first section comprises a control backbone, the interface being connected to the control backbone, and wherein the second section is connected to at least a portion of the first section via the interface and the Control backbone communicates.
29. 29. Integrated circuit according to one of sentences 19-28, which is located on a continuous piece of semiconductor material.
30. 30. Integrated circuit according to any of sentences 19-29, which implements a portion of a system on a chip, “SoC”, for motor vehicles.
31. 31. The integrated circuit of any one of sentences 19-30, wherein the second section comprises a plurality of interfaces comprising the interface, each of the plurality of interfaces connecting the second section to a corresponding part of the first section, the processor selectively one certain of the plurality of interfaces are unlocked to enable communication via the particular interface with the corresponding part of the first section.
32. 32. The integrated circuit of sentence 31, wherein the processor selectively disables any of the plurality of interfaces that is unlocked to prevent communication via the plurality of interfaces with the first section.

The use of the terms "a", "an" and "an and "the", "the" and "the" and similar terms in connection with the description of disclosed embodiments (particularly in connection with the following claims) are to be construed as meaning that it includes both the singular and the plural unless otherwise stated herein or clearly contradicted by the context and is not to be construed as a definition of a term. The terms “comprising,” “comprising,” “including,” and “containing” are intended to be open terms (i.e., “including, but not limited to”) unless otherwise specified. The term "connected", when left unchanged and referring to physical connections, is to be understood as being partly or wholly contained in, attached to or connected to a part, even if there is something in between. The enumeration of value ranges is intended solely as a shorthand to refer individually to each individual value falling within the range unless otherwise specified herein, and each individual value is included in the specification as if it were individually listed here. In at least one embodiment, use of the term "set" or "set" (e.g., "a set of items") or "subset" is intended to mean a non-empty collection unless otherwise indicated or contradicted by the context understand that includes one or more elements. Furthermore, unless otherwise noted or contradicted by the context, the term "subset" of a corresponding set does not necessarily mean a true subset of the corresponding set, but the subset and the corresponding set may be the same.

When speaking of “and/or” in reference to two or more elements, this should be understood as meaning only one element or a combination of elements. For example, "Element A, Element B and/or Element C" can only contain element A, only element B, only element C, only element A and element B, element A and element C, element B and element C or the elements A, B and include C.

Subjunctival expressions, such as B. Sentences of the form “at least one of A, B, and C” or “at least one of A, B and C”, unless expressly stated otherwise or clearly contradicted by the context, are generally understood in the context to mean that a Element, a term, etc., can be either A or B or C or any non-empty subset of the set of A and B and C. For example, in the illustrative example of a set with three members, the conjunctive expressions “at least one of A, B, and C” and “at least one of A, B, and C” refer to one of the following sets: {A}, {B }, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Such conjunctival formulations are therefore not generally to be understood as meaning that in certain embodiments at least one of A, at least one of B and at least one of C must be present. Unless otherwise noted or contradicted by context, the term “plurality” or “multiplicity” refers to a state of plurality (e.g., “a plurality of items” refers to multiple items). In at least one embodiment, the number of items in a plurality is at least two, but may be more if indicated either explicitly or by the context. In addition, unless otherwise stated or otherwise clear from the context, “based on” means “based at least in part on” and not “based solely on.”

The operations of the methods described herein may be performed in any appropriate order unless otherwise specified herein or as is clear from the context. In at least one embodiment, a method as described herein (or variations and/or combinations thereof) is performed under the control of one or more computer systems configured with executable instructions and as code (e.g., executable instructions). or multiple computer programs or one or more applications) that are executed together on one or more processors, by hardware, or combinations thereof. In at least one embodiment, the code is stored on a computer-readable storage medium. In at least one embodiment, in the form of a computer program that includes a plurality of instructions that can be executed 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 volatile signals (e.g., propagating transient electrical or electromagnetic transmission) but excludes non-volatile data storage circuits (e.g., buffers, cache, and queues). within the transceiver of volatile signals. In at least one embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-transitory, computer-readable storage media on which executables Instructions (or other memory for storing executable instructions) are stored that, when executed by one or more processors of a computer system (ie, as a result of execution), cause the computer system to perform the operations described herein. In at least one embodiment, a set of non-transitory computer-readable storage media includes a plurality of non-transitory computer-readable storage media, wherein one or more of the individual non-transitory storage media of a plurality of non-transitory computer-readable storage media is missing all of the code while a plurality of non-transitory storage media are missing all code The entire code is stored together on computer-readable storage media. In at least one embodiment, 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 main 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, according to at least one embodiment, computer systems are designed to implement one or more services that individually or collectively perform operations of the methods described herein, and such computer systems are designed with appropriate hardware and/or software that enable the operations to be performed. Furthermore, a computer system that implements 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 that a single one Facility does not perform all operations.

The use of examples or exemplary language (e.g., “such as.”) is intended solely to better illustrate embodiments of the disclosure and does not constitute a limitation on the scope of the disclosure, unless otherwise claimed. No language in the specification should be construed to deem any unclaimed element essential to the practice of the disclosure.

All 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 expressly stated to be incorporated by reference and reproduced herein in their entirety.

The terms “coupled” and “connected” and their derivatives may be used in the description and claims. It is clear that these terms are not to be understood as synonyms for each other. Rather, in certain examples, “connected” or “coupled” may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with one another. “Coupled” can also mean that two or more elements are not in direct contact with each other, but still work together or interact with each other.

Unless expressly stated otherwise, terms such as “processing”, “computing”, “computing”, “determining” or the like throughout the specification refer to actions and/or procedures of a computer or a computing system or similar electronic computing device, the data that is physical, e.g. B. electronic, quantities are represented in the registers and / or memories of the computing system, manipulate and / or convert them into other data, which are similarly represented as physical quantities in the memories, registers or other such devices for storing, transmitting or displaying information of the computing system can be displayed.

Similarly, the term “processor” may refer to a device or part 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. The term “software” processes or “software” methods may, in at least one embodiment, include software and/or hardware entities that perform work over time, such as: B. Tasks, threads and intelligent agents. Each method may also refer to multiple methods to execute instructions sequentially or in parallel, continuously or intermittently. The terms “system” and “procedure” are used interchangeably herein in that a system may include one or more procedures and procedures can be considered 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 switching components such as semiconductor transistors arranged to form logic gates. In at least one embodiment, an arithmetic logic unit may operate internally as a state-dependent 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 held in an associated register set. In at least one embodiment, an arithmetic logic unit is used by a processor 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 a memory location.

In at least one embodiment, as a result of processing an instruction fetched by the processor, the processor passes 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 an instruction code , which is 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 an instruction executed by the processor. In at least one embodiment, the 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, a memory location, an output device, or an output storage location on the output bus such that the clocking of the processor causes the results produced by the ALU to be sent to the desired location.

This document may refer to obtaining, acquiring, receiving or inputting analog or digital data into a subsystem, computer system or computer-implemented machine. In at least one embodiment, the method of obtaining, acquiring, receiving, or inputting analog and digital data may be accomplished in various ways, e.g. B. by receiving data as a parameter of a function call or a call to an application programming interface. In some implementations, the method of obtaining, acquiring, receiving, or inputting analog or digital data may be performed by transmitting data over a serial or parallel interface. In another implementation, the method of obtaining, capturing, receiving or inputting analog or digital data may be performed by transmitting data over a computer network from the providing entity to the acquiring entity. It may also refer to providing, outputting, transmitting, sending or presenting analog or digital data. In various examples, the method of providing, outputting, transmitting, sending, or displaying analog or digital data may be performed by transmitting data as an input or output parameter of a function call, an application programming interface parameter, or an interprocess communication mechanism.

Although the above discussion sets forth example implementations of the described methods, other architectures may be used to implement the described functionality and are also intended to be within the scope of this disclosure. In addition, although specific distributions of responsibilities are defined above for discussion purposes, different functions and responsibilities may be distributed and divided in different ways depending on the circumstances.

Although the subject matter has been described in language referring to structural features and/or method-specific actions, it is to be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or actions or operations described. Rather, certain features and actions are disclosed as exemplary forms of implementing the claims.

The subject matter of the present disclosure is described here in sufficient detail to meet legal requirements. However, the description itself is not intended to limit the scope of this disclosure. Rather, the inventors have considered that the claimed subject matter also exists in other embodiments may be designed to include other steps or combinations of steps similar to those described in this document in conjunction with other current or future technologies. Although the terms "step" and/or "block" may be used herein to refer to various elements of the methods employed, the terms should not be construed to imply any particular order among or between the various steps disclosed herein unless the sequence of the individual steps is expressly described.

Other variations are within the meaning of the present disclosure. While the methods disclosed are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been shown in the drawings and described in detail above. It should be understood, however, that the disclosure is not intended to be limited to any particular form or forms, but on the contrary is intended to cover all modifications, alternative constructions and equivalents that fall 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 assumes no liability for any errors or omissions.

Cited patent literature

• US 17/477214 [0001]
• US 16101232 [0194]

Claims (32)

Integrated circuit comprising: a first bar; a second clock isolated from the first clock; a first power connection; a second power terminal isolated from the first power terminal; a first section for receiving power via the first power terminal and a first clock signal via the first clock; and a second section for receiving power via the second power terminal and a second clock signal via the second clock, the second section comprising an interface for communicating with the first section, an interface controller and a processor for locking and unlocking the interface controller, the interface controller preventing communication over the interface when the interface control is locked, and wherein the interface control allows communication over the interface when the interface control is unlocked. Integrated circuit according to Claim 1 , wherein the first section comprises a first error aggregator for communicating to the second section indications corresponding to one or more errors occurring in the first section, the second section comprising a second error aggregator for communicating the one or more errors to receive and store corresponding notices, wherein the integrated circuit includes a fault interface connecting the first and second fault aggregators, the fault interface being separate from the interface, and wherein the processor unlocks the interface control only when the second fault aggregator does not provide notices stores that correspond to any errors. Integrated circuit according to Claim 1 , wherein the second section includes a timer that starts when the processor initiates communication with the first section via the interface, and wherein the timer generates an indication of an error when the timer indicates that more than a predetermined amount of time has elapsed and the first section did not respond to communications. Integrated circuit according to Claim 3 , wherein the timer is reset if the first section responds to the communication before the timer indicates that more than the predetermined amount of time has elapsed, and wherein the processor locks the interface after the processor completes communication with the first section. Integrated circuit according to Claim 1 , further comprising: a non-volatile memory shared by the first and second sections, the second section comprising local memory, the processor copying instructions from the non-volatile memory to the local memory when the integrated circuit boots , where the instructions are to be executed by the processor when the interface is blocked. Integrated circuit according to Claim 1 , wherein the first section comprises a volatile memory, and wherein the second section communicates with the volatile memory via the interface. Integrated circuit according to Claim 1 , which is located on a continuous piece of semiconductor material. Integrated circuit according to Claim 1 , which implements a section of a System on a Chip, “SoC,” for vehicles. Integrated circuit according to Claim 1 , wherein the first section operates at a first risk classification level, the second section operates at a second risk classification level, and wherein the second risk classification level is higher than the first risk classification level. Procedure comprising: determining, by a first section of an integrated circuit, whether a fault aggregator in the first section contains data indicative of at least a predetermined number of faults; unlocking an interface with a second portion of the integrated circuit by the first portion when the first portion determines that the error aggregator does not contain data indicative of at least the predetermined number of errors; Initiating access to the second section by the first section via the unlocked interface; and Locking the interface through the first section after access is initiated. Procedure according to Claim 10 , where initiating access starts an access timer, and wherein the first section locks the interface after detecting the access timer indicates that more than a predetermined period of time has elapsed since the start of the access timer and a response from the second section has not been received. Procedure according to Claim 11 , wherein the first section generates a new error after detecting the access timer indicates that more than a predetermined period of time has elapsed since the start of the access timer and a response from the second section has not been received. Procedure according to Claim 10 , wherein initiating access starts an access timer and the method further comprises: receiving a response from the second section by the first section before the access timer indicates that more than a predetermined amount of time has passed since the start of the access timer has elapsed, receiving the response stops the access timer, the first section locking the interface upon completion of the access. Procedure according to Claim 10 , further comprising: performing one or more corrective actions by the first section when the first section determines that the error aggregator contains data indicative of at least the predetermined number of errors. Procedure according to Claim 14 , wherein the integrated circuit implements a portion of a system on a chip, “SoC,” for vehicles, and wherein the one or more corrective actions are designed to place an autonomous vehicle in a safe state. Procedure according to Claim 10 , wherein the integrated circuit implements a portion of a system on a chip, “SoC,” for vehicles, wherein the first portion performs safety functions for an autonomous vehicle while the autonomous vehicle is driving, and wherein the second portion performs autonomous driving functions while driving the autonomous vehicle vehicle executes. Procedure according to Claim 10 , wherein the interface connects the first section to a volatile memory or a control backbone of the second section. Procedure according to Claim 10 , wherein the first section operates in a first clock range, the second section operates in a second clock range that is different from the first clock range, and wherein the interface comprises a phase synchronization circuit that converts a signal received from the second section into the first clock range . Integrated circuit comprising: a first section operating at a first level of risk within a first range; and a second section that operates with a second risk level within a second range, the second risk level being greater than the first risk level, wherein the second section includes a processor and an interface connecting the first and second sections, the processor selectively disabling the interface to prevent communication via the interface, the processor selectively unlocking the interface to enable communication via to enable the interface. Integrated circuit according to Claim 19 , further comprising: a first power connector that supplies power to the first area; and a second power port that is electrically isolated from the first power port and supplies power to the second region, the interface comprising at least one voltage shifter for setting a voltage for any communication via the interface. Integrated circuit according to Claim 19 , which further comprises: a first clock that supplies the first area with a first clock signal; and a second clock isolated from the first clock and providing the second region with a second clock signal, the interface comprising a phase synchronization circuit for adjusting a phase of any communication over the interface. Integrated circuit according to Claim 19 , wherein the interface includes a firewall that implements one or more security rules, and wherein the firewall allows or blocks communication over the interface based on the one or more security rules. Integrated circuit according to Claim 19 , wherein the first section comprises a first error aggregator for transmitting data indicative of an error occurring in the first section to the second section, the second section comprising a second error aggregator for communicating the error indicating the error Receive data and store the data indicating the error until the error is cleared by the processor, the integrated circuit comprising an error interface connecting the first and second error aggregators, the error interface being separate from the interface, and wherein the Processor unlocks the interface only when errors corresponding to data indicative of any errors stored by the second error aggregator have been cleared by the processor. Integrated circuit according to Claim 19 , wherein the second section includes a timer that starts when the processor unlocks the interface, and wherein the timer generates a new error if the timer indicates that more than a predetermined period of time has elapsed and the first section does not respond to a first section of communication sent over the interface. Integrated circuit according to Claim 24 , wherein the timer is reset if the first section responds to the communication before the timer indicates that more than the predetermined amount of time has elapsed, and wherein the processor locks the interface after the processor completes communication with the first section. Integrated circuit according to Claim 19 , wherein the first section comprises a non-volatile memory shared by the first and second sections, the second section comprising local memory, the processor copying instructions from the non-volatile memory to the local memory when the integrated circuit boots , and wherein the instructions are executed by the processor when the interface is locked. Integrated circuit according to Claim 19 , wherein the first section comprises a volatile memory, and wherein the second section communicates with the volatile memory via the interface. Integrated circuit according to Claim 19 , wherein the first section comprises a control backbone, the interface being connected to the control backbone, and wherein the second section communicates with at least a portion of the first section via the interface and the control backbone. Integrated circuit according to Claim 19 , which is located on a continuous piece of semiconductor material. Integrated circuit according to Claim 19 , which implements a portion of a system on a chip, “SoC,” for automobiles. Integrated circuit according to Claim 19 , wherein the second section includes a plurality of interfaces comprising the interface, each of the plurality of interfaces connecting the second section to a corresponding part of the first section, the processor selectively unlocking a particular one of the plurality of interfaces to communicate via to enable the specific interface with the corresponding part of the first section. Integrated circuit according to Claim 31 , wherein the processor selectively disables any one of the plurality of interfaces that is unlocked to prevent communication via the plurality of interfaces with the first section.

Images