Transferring data between regions of different safety integrity levels in a system on a chip

Abstract

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

Description

[0001] Claiming priority

[0002] This application claims the benefit of Indian Provisional Application No. 202111034491, filed July 30, 2021, entitled “Transmitting Data Between Regions of Varying Safety Integrity Levels in a System on a Chip,” and U.S. Patent Application No. 17 / 477,360, filed September 16, 2021, entitled “Transmitting Data Between Regions of Varying Safety Integrity Levels in a System on a Chip,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] At least one embodiment relates to accessing memory in a second region of the circuit from a first region of the circuit. For example, at least one embodiment relates to an on-chip system implementing the various novel techniques described herein. As another example, at least one embodiment relates to an autonomous vehicle including such an on-chip system. Background Technology

[0004] The Automotive Safety Integrity Level (“ASIL”) is a risk classification system for functional safety of road vehicles defined by the International Organization for Standardization (“ISO”) standard 26262. This risk classification system has four risk levels: ASIL-A, ASIL-B, ASIL-C, and ASIL-D, with ASIL-D being the highest risk level. Therefore, a component designated as ASIL-D has higher safety requirements and may be more expensive than a component designated as having a lower risk level (e.g., ASIL-B). In many automotive platforms, when a specific fault is detected in the System-on-Chip (“SoC”) controlling various driving functions of an autonomous or semi-autonomous vehicle, at least some safety services are performed by an external control unit. Generally, external control units can operate at a higher risk level than the automotive SoC (e.g., ASIL-B) (e.g., ASIL-D). Unfortunately, such external control units introduce latency and can be expensive because they require separate components also present in the automotive SoC, such as DRAM, non-volatile memory, etc., and each separate component occupies space within the automotive platform (e.g., on a circuit board). Attached Figure Description

[0005] The present system and method for isolating regions of the system-on-a-chip are described in detail below with reference to the accompanying drawings, wherein:

[0006] Figure 1 These are illustrations of example vehicle platforms according to some embodiments of the present disclosure;

[0007] Figure 2 This is an illustration of an example interface between a security island integrated into an automotive SoC and other components of the automotive SoC, according to some embodiments of this disclosure;

[0008] Figure 3 This is a flowchart illustrating a method for switching between a safe island and a non-isolated mode, according to some embodiments of the present disclosure.

[0009] Figure 4 This is an illustration of an example fault interface for transmitting faults from other components of an automotive SoC to a safety island, according to some embodiments of this disclosure;

[0010] Figure 5A This is a flowchart illustrating a method for transmitting a fault to a safety island according to some embodiments of the present disclosure;

[0011] Figure 5B This is a flowchart illustrating a method by which a processor can process an interrupt received from a SoC fault aggregator, according to some embodiments of the present disclosure;

[0012] Figure 5C This is a flowchart illustrating a method by which SI 110 can be used to process calibrated and uncalibrated error signals according to some embodiments of this disclosure;

[0013] Figure 5D This is a flowchart illustrating a method by which SI 110 can be used to process SoC fault aggregator signals according to some embodiments of this disclosure;

[0014] Figure 6A Example signal timing diagrams are shown of signals received and transmitted by the processor of the safety island after a low-severity uncorrected error (e.g., minimum value) has been asserted, according to some embodiments of the present disclosure;

[0015] Figure 6B Example signal timing diagrams are shown of signals received and transmitted by the processor of the safety island after a high-severity uncorrected error (e.g., a maximum value) has been asserted, according to some embodiments of the present disclosure;

[0016] Figure 6CExample signal timing diagrams are shown of signals received and transmitted by the processor of the safety island after an uncorrected error (e.g., a maximum value) has been asserted but the safety island has not received a mailbox interruption, according to some embodiments of the present disclosure;

[0017] Figure 7 This is a flowchart illustrating a method for writing data into a carve-out area defined in volatile memory shared by other components of the automotive SoC and the security island, according to some embodiments of the present disclosure;

[0018] Figure 8 Implementation according to some embodiments of this disclosure is illustrated. Figure 7 An example of a method for detecting errors in a safe island;

[0019] Figure 9 This is a flowchart illustrating a method for reading data from a separation according to some embodiments of the present disclosure;

[0020] Figure 10 Implementation according to some embodiments of this disclosure is illustrated. Figure 9 An example of a method for detecting errors in a safe island;

[0021] Figure 11 This is an illustration of a block diagram showing an error notification generated by an error detection block when the error detection block includes or is connected to an exit and entry timer, according to some embodiments of the present disclosure;

[0022] Figure 12 These are illustrations of example autonomous vehicles according to some embodiments of the present disclosure;

[0023] Figure 13 According to some embodiments of this disclosure Figure 12 Examples of camera positions and fields of view for autonomous vehicles;

[0024] Figure 14 According to some embodiments of this disclosure Figure 12 A block diagram of an example system architecture for an example autonomous vehicle;

[0025] Figure 15 This is based on some embodiments of the present disclosure for use in cloud-based communication with one or more servers. Figure 12 Example system diagram of communication between autonomous vehicles; and

[0026] Figure 16 This is a block diagram of an example computing device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0027] The disclosed systems and methods involve isolating circuit regions operating at a higher risk level (e.g., ASIL-D) from other regions of the same circuit operating at a lower risk level (e.g., ASIL-B). For example, a region or “island” dedicated to functional safety may be isolated from other components on the system-on-chip (“SoC”) (e.g., an automotive SoC, for example, communications ground). Figure 1 This is an illustration of an example vehicle platform 100 according to at least one embodiment. The vehicle platform 100 can realize autonomous or semi-autonomous vehicles, such as the example autonomous vehicle 1200 (see...). Figure 12 The vehicle platform 100 includes a vehicle processing system 102 that can achieve 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 can achieve Levels 2 (partial driving automation) to 5 (full driving automation) as defined by SAE. A Level 2 system may be referred to as an Advanced Driver Assistance System (“ADAS”).

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

[0029] To avoid at least some delay and cost introduced by the optional external control unit 106, Figure 1The automotive platform 100 includes a functional safety island or safety island (“SI”) 110 integrated into the automotive SoC 104. The SI 110 can be implemented as a computing cluster operating at and consistent with a higher risk classification level (e.g., ASIL-D) compared to the rest of the automotive SoC 104. The SI 110 can perform at least some of the functions typically performed by an optional external control unit 106. The presence of the SI 110 allows the optional external control unit 106 to be completely omitted or implemented using a less complex and / or lower-cost external control unit. For example, when the optional external control unit 106 is present, it can perform one or more conventional functions, such as providing communication on a controller area network (“CAN” bus) bus, providing a reset controller for the automotive SoC 104, and / or performing onboard voltage monitoring.

[0030] In addition to the automotive SoC 104 and the optional external control unit 106 (when present), the automotive processing system 102 may also include a first (SoC) clock 112 for the automotive SoC 104, a second (SI) clock 114 for SI 110, and a power management integrated circuit (“IC”) 116. Each component of the automotive processing system 102 is implemented at least partially in hardware. The logic components of the automotive processing system 102 (e.g., the automotive SoC 104 and the optional external control unit 106) are typically implemented in hardware logic circuitry within one or more integrated circuit chips. This logic may be hardwired or programmable, or a combination of hardwired and programmable elements. Alternatively, some functions of the automotive processing system 102 may be implemented in software or firmware executed by an embedded microprocessor or microcontroller.

[0031] First and second clocks 112 and 114 provide two separate clock signals to the automotive SoC 104. Specifically, a first clock signal generated by the first (SoC) clock 112 is provided to component 160 of the automotive SoC 104, not SI 110, and a second clock signal generated by the second (SI) clock 114 is provided to SI 110. Therefore, SI 110 and the other components 160 can be characterized as operating within separate clock domains. The clock domain of SI 110 will be referred to as the SI clock domain, and the clock domains of the other components 160 will be referred to as the SoC clock domain. Each of the first and second clocks 112 and 114 can be implemented at least partially as a crystal oscillator. The first (SoC) clock 112 can be connected to each of at least some of the other components 160 of the automotive SoC 104 via a first clock connection (not shown), such as a wire, signal trace, etc. Therefore, the first (SoC) clock 112 can provide a first clock signal to the other components 160 of the automotive SoC 104 via the first clock connection (not shown). The second (SI) clock 114 can be connected to each of at least some components of SI 110 via a second clock connection (not shown), such as a wire, signal trace, etc. Therefore, the second (SI) clock 114 can provide a second clock signal to SI 110 via the second clock connection (not shown).

[0032] Power management IC 116 supplies power to other components of the automotive processing system 102. For example, power rails or connections 118A-118C connect power management IC 116 to other components 160, SI 110, and optional external control unit 106 of the automotive SoC 104, respectively. Power connections 118A-118C facilitate electrical isolation between other components 160, SI 110, and optional external control unit 106 (when present) of the automotive SoC 104. Therefore, SI 110 can operate in a voltage domain separate from the other components 160 and optional external control unit 106 (when present). The voltage domain of SI 110 will be referred to as the SI voltage domain, while the voltage domain of the other components 160 will be referred to as the SoC voltage domain. Power management IC 116 can be implemented as one or more integrated circuits that provide sufficient power to the components of the automotive processing system 102. Each of power connections 118A-118C can be implemented as a conductive element, such as an electrical transmission line, wire, power trace, etc.

[0033] As described above, SI 110 operates in both the SI clock domain and the SI voltage domain. The SI clock domain and SI voltage domain will be collectively referred to as the SI domain. Similarly, other components 160 operate in both the SoC clock domain and the SoC voltage domain. The SoC clock domain and SoC voltage domain will be collectively referred to as the SoC domain.

[0034] Other components 160 of the automotive SoC 104 may include a main central processing unit (“CPU”) complex 120, an auxiliary security unit 122, circuitry 124 for performing automotive SoC functions, volatile data memory or memory 126 (e.g., dynamic random access memory (“DRAM”)) and 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 automotive SoC 104 may operate under multiple or mixed ASILs, as SI 110 may operate under a higher level of ASIL (e.g., ASIL-D). As a non-limiting example, circuitry 124 may include hardware implementing one or more displays, one or more automotive input / output (“I / O”) controllers, one or more memory controllers, one or more interconnects, etc. In the illustrated embodiment, circuitry 124 is depicted as including or implementing multiple logic blocks LB(1)-LB(N), which are generally referred to individually as intellectual property (IP). Logic blocks LB(1)-LB(N) may be implemented in autonomous vehicles (e.g., Figure 12 The autonomous vehicle 1200 shown in the diagram performs various functions.

[0035] Optional external control unit 106 may include controller 130, fault aggregator 132, volatile data memory or memory 136 (e.g., DRAM), and non-volatile data memory or memory 138. Optional external control unit 106 may also include one or more logic blocks (not shown) that implement those safety functions performed by optional external control unit 106. Controller 130 may be implemented as one or more processors (e.g., microcontrollers) operating under ASIL-D. Controller 130 executes instructions stored in non-volatile memory 138, such as instructions conforming to one or more Automotive Open System Architecture (“AUTOSAR”) software standards. These instructions may instruct controller 130 to take appropriate action when fault aggregator 132 receives a fault from automotive SoC 104.

[0036] In one or more embodiments, SI 110 includes a processor 140, an interrupt controller 141, an SI fault aggregator 142, volatile data memory or memory 146 (e.g., static random access memory (“SRAM”),) and one or more logic blocks 148. The processor 140 may be implemented as a processor cluster, such as a highly rated ASIL-D safety processor. The processor 140 executes instructions 149, such as AUTOSAR-compliant software standard instructions, which are retrieved from non-volatile memory 128 and stored in volatile memory 146 at startup. Instructions 149 may instruct the processor 140 to take appropriate action when the SI fault aggregator 142 receives a fault from other components 160 of the automotive SoC 104. Logic blocks 148 may help implement those safety functions performed by SI 110.

[0037] 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 risk classification level or a higher risk classification level as other components within the SoC domain. The auxiliary security unit 122 includes a processor 150, one or more SoC fault aggregators 152, an interrupt controller 154, and one or more logic blocks, which will be referred to as one or more mailboxes 156. SI fault aggregators 142 and fault aggregators 132 (when present) may each receive faults from SoC fault aggregator 152. Therefore, SoC fault aggregator 152 may be connected to fault aggregator 132 via one or more fault interfaces 170, and connected to SI fault aggregator 142 via one or more fault interfaces 172. Each of the fault interfaces 170 and 172 includes connections, such as wires, signal traces, etc., that physically connect each SoC fault aggregator 152 to a corresponding aggregator in fault aggregator 132 or SI fault aggregator 142.

[0038] One or more mailboxes 156 may include a first mailbox to which processor 150 writes and which processor 140 reads, and a second mailbox to which processor 140 writes and which processor 150 reads. One or more mailboxes 156 may be used by processor 150 (e.g., a central processing unit (“CPU”) rated at ASIL-B or higher) to report mailbox interrupts to and receive interrupts from interrupt controller 141. Therefore, fault interface 172 includes at least one signal conductor connecting one or more mailboxes 156 to interrupt controller 141. Each mailbox interrupt includes a severity identifier indicating the severity of the error. As a non-limiting example, the severity identifier may be a numerical value ranging from a minimum (e.g., zero) to a maximum (e.g., seven). As another non-limiting example, the interrupt may have an interrupt number that is a priori encoded to indicate severity. Processor 140 and / or processor 150 may write fault information into mailboxes 156. The fault information includes information about the error that caused the fault (e.g., the name of the logic block where the fault occurred), a logic block diagnostic identifier, the nature of the fault, the severity identifier, etc.

[0039] Integrating SI 110 into the automotive SoC 104 allows for the omission of several individual components (e.g., volatile memory 136 and non-volatile memory 138) from the automotive processing system 102, if the optional external control unit 106 is also omitted. However, SI 110 must be isolated from other components 160 of the automotive SoC 104 (e.g., main CPU complex 120, auxiliary safety unit 122, circuitry 124, volatile memory 126, and non-volatile memory 128) so that potential problems arising in one or more of the other components 160 do not negatively impact SI 110. For example, this isolation can help prevent SI 110 from being affected by outages occurring in one or more of the other components 160 of the automotive SoC 104. Non-limiting examples of the types of outages that may occur in one or more of the other components 160 include random failures, clock problems, power supply problems, and / or voltage problems. Due to their proximity in space and the fact that SI 110 shares one or more interfaces 200 with other components 160 of the automotive SoC 104 (see...), Figure 2 Such interrupts could migrate to SI 110 and prevent SI 110 from performing rollbacks and / or fault protection functions integrated into the automotive SoC 104. Therefore, the automotive processing system 102 isolates SI 110 from other components 160 of the automotive SoC 104 to achieve isolation equivalent to that between the automotive SoC 104 and optional external control units 106. This isolation can be achieved by first and second clocks 112 and 114, first and second power connections 118A and 118B, and interface 200.

[0040] The first (SoC) clock 112 is separated from the second (SI) clock 114 (e.g., including a separate reference crystal), which helps to isolate SI 110 from the other components 160 of the automotive SoC 104. Similarly, the first power connection 118A is isolated from the second power connection 118B, which helps to isolate SI 110 from the other components 160 of the automotive SoC 104. As described above, SI 110 can operate in a separate SI voltage domain from the other components 160 of the automotive SoC 104. However, even with a separate second (SI) clock 114 and a separate second power connection 118B, SI 110 is isolated via interface 200 (see...). Figure 2 It communicates with other components 160 of the automotive SoC 104.

[0041] One or more logic blocks 148 include clock and reset circuitry 230 connected to a dedicated second (SI) clock 114 (see...). Figure 2 A dedicated second (SI) clock 114 can be used as a reference clock for clock and reset circuitry 230. For example, clock and reset circuitry 230 may include an internal dedicated phase-locked loop (“PLL”) for deriving additional functional and debug clocks for SI 110. As a non-limiting example, clock and reset circuitry 230 may provide debug and test clock signals derived from the PLL. Clock and reset circuitry 230 may generate all clock and reset signals used within SI 110. In other words, clock and reset circuitry 230 may generate clock signals and resets used within the SI domain. Additionally or alternatively, second (SI) clock 114 may be used directly as a functional clock for one or more logic blocks in logic block 148. In this way, SI 110 uses locally generated clock signals and resets and / or clock signals provided by second (SI) clock 114. Clock signals or resets from other components 160 are not used in SI 110. The clock and reset circuit 230 helps ensure that no interference from logic-generated resets (e.g., reset blocks) will reach the components of SI 110 within other components 160.

[0042] Figure 2 This is an illustration of one or more interfaces 200 that connect SI 110 to other components 160 of automotive SoC 104 according to at least one embodiment. See also Figure 2One or more interfaces 200 provide logical isolation for the circuitry and logic of the SI 110 in the automotive SoC 104. In the illustrated embodiment, one or more interfaces 200 include one or more fault interfaces 172, a volatile memory interface 200A, a first control backbone interface 200B, a second control backbone interface 200C, a security content interface 200D, a debug interface 200E, and a test interface 200F. One or more fault interfaces 172 may not be logically isolated from one or more SoC fault aggregators 152, but may each include or be connected to one or more voltage level shifters 240, each voltage level shifter 240 providing electrical isolation between the SI voltage domain and the SoC voltage domain. While each voltage level shifter 240 provides electrical isolation, it may not provide sufficient isolation for certain types of faults, such as interrupt storms, fault storms, and / or continuous assertions. The SI fault aggregator 142 may include one or more status bits 242, which receive fault information via one or more fault interfaces 172 and provide notification of such faults to instructions 149 executed by the processor 140. In the illustrated embodiment, status bits 242 include status bits “BT1”, “BT2”, and “BT3” (see... Figure 4 Instruction 149 instructs processor 140 to use the notification to mitigate an interrupt occurring on one or more faulty interfaces 172.

[0043] The volatile memory interface 200A is an interface between the processor 140 and the volatile memory 126 of the automotive SoC 104. The volatile memory interface 200A allows the processor 140 to write information to and read information from the volatile memory 126. The volatile memory interface 200A includes one or more connections to the volatile memory 126, such as wires, signal traces, etc. The volatile memory interface 200A may include a logic isolation control 220, an access timer 222, and a domain synchronization circuit 224. The logic isolation control 220 includes a gate or locking mechanism that can be selectively locked and unlocked by the processor 140. The access timer 222 allows access attempts initiated by the processor 140 to time out.

[0044] Domain synchronization circuit 224 includes a phase synchronization circuit and a voltage level shifter. The phase synchronization circuit helps synchronize the phase of signals transmitted across the SI and SoC domains, which are transmitted using separate first and second clocks 112 and 114 (see...). Figure 1The reset generated by clock and reset circuit 230 can be used by any component spanning the SI and SoC voltage and clock domains, such as a phase synchronization circuit. The phase synchronization circuit has an SoC section and an SI section, each of which can be used as a separate synthesis top. The SoC section is physically located in the SoC domain, while the SI section is physically located in the SI domain. The logic of both the SI and SoC sections uses the reset generated by clock and reset circuit 230. Therefore, the reset generated by SI 110 can be used by the logic of automotive SoC 104, which can operate below the ASIL of SI 110, but the reset generated by automotive SoC 104 is not passed to SI 110 and cannot be used by SI 110. As a non-limiting example, the phase synchronization circuit can be implemented as a separate first-in-first-out (“FIFO”), etc. The voltage level shifter of domain synchronization circuit 224 can be substantially the same as voltage level shifter 240 and adjusts the voltage of signals transmitted across the SI and SoC voltage domains to allow safe signal transmission across the SI and SoC domains. When access timer 222 indicates that access to processor 140 has timed out, the request can be removed from domain synchronization circuit 224 (e.g., popped from a separate first-in-first-out).

[0045] When the volatile memory interface 200A is unlocked, the processor 140 can access the volatile memory 126, which starts the access timer 222. When the access timer 222 indicates that more than a first predetermined amount of time has elapsed and no response has been received from the volatile memory 126, the processor 140 indicates a security fault, uses the logic isolation control 220 to lock the volatile memory interface 200A, optionally locks any unlocked interface 200, and optionally takes measures configured to place the vehicle platform 100 (see...) Figure 1 One or more actions to return to a safe state. On the other hand, when a response is received before the access timer 222 indicates that a first predetermined amount of time has elapsed, the access timer 222 resets itself, the processor 140 completes the access, and the processor 140 locks the volatile memory interface 200A after the access is complete. Therefore, whenever the processor 140 is not accessing the volatile memory 126, the volatile memory interface 200A remains locked, which helps protect SI 110 from faults and / or interrupts propagating from the volatile memory 126 to SI 110.

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

[0047] 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 a logic isolation control 220, an access timer 222, a domain synchronization circuit 224, and a firewall 226. The logic isolation control 220 of the first control backbone interface 200B is substantially the same as and functionally similar to the logic isolation control 220 of the volatile memory interface 200A. Therefore, the logic isolation control 220 of the first control backbone interface 200B 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 access attempts initiated by the processor 140 to time out. The domain synchronization circuit 224 of the first control backbone interface 200B is substantially the same as and functionally similar to the domain synchronization circuit 224 of the volatile memory interface 200A. The firewall 226 of the first control backbone interface 200B implements one or more security rules and allows or blocks each communication based on these rules.

[0048] 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 a logic isolation control 220, a domain synchronization circuit 224, and a firewall 226. The logic isolation control 220 of the second control backbone interface 200C is substantially the same as and functionally similar to the logic isolation control 220 of the volatile memory interface 200A. Therefore, the logic isolation control 220 of the second control backbone interface 200C allows the processor 140 to lock and unlock the second control backbone interface 200C. The domain synchronization circuit 224 of the second control backbone interface 200C is substantially the same as and functionally similar to the domain 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 each communication based on these rules.

[0049] The secure content interface 200D is an interface between the processor 140 and the secure content circuitry 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 circuitry 212. The secure content interface 200D may include a logic isolation control 220 and a domain synchronization circuitry 224. The logic isolation control 220 of the secure content interface 200D is substantially the same as and functionally similar to the logic isolation control 220 of the volatile memory interface 200A. Therefore, the logic isolation control 220 of the secure content interface 200D allows the processor 140 to lock and unlock the secure content interface 200D. The domain synchronization circuitry 224 of the secure content interface 200D is substantially the same as and functionally similar to the domain synchronization circuitry 224 of the volatile memory interface 200A.

[0050] Debug interface 200E is the interface between processor 140 and debug circuitry 214. Debug interface 200E allows processor 140 to receive instructions and / or information from debug circuitry 214. Debug interface 200E may include logic isolation control 220 and domain synchronization circuitry 224. The logic isolation control 220 of debug interface 200E is substantially the same as and functionally substantially the same as the logic isolation control 220 of volatile memory interface 200A. Therefore, the logic isolation control 220 of debug interface 200E allows processor 140 to lock and unlock debug interface 200E. The domain synchronization circuitry 224 of debug interface 200E is substantially the same as and functionally substantially the same as the domain synchronization circuitry 224 of volatile memory interface 200A. As described above, SI 110 and other components 160 operate in separate clock domains. In one or more embodiments, no external clock signal from one or more other components 160 of automotive SoC 104 (e.g., debug circuitry 214) is fed to SI 110. The debug function executed by the automotive SoC 104 receives a debug clock signal via domain synchronization circuitry 224 of debug interface 200E, which switches or transforms the debug function executed by the automotive SoC 104 to use the debug clock signal generated by SI 110 and / or second (SI) clock 114. Because debug logic is not used when SI 110 is in task mode (e.g., when the vehicle is in motion), SI 110 includes a first clock gate on the debug clock to prevent any interference that may be caused by the debug clock signal. As a non-limiting example, the first clock gate may be a component of clock and reset circuitry 230. The first clock gate may be controlled (e.g., selectively turned on and off) using a first configuration bit set by processor 140.

[0051] Test interface 200F is the interface between processor 140 and test circuit 216. Test interface 200F allows processor 140 to receive instructions and / or information from test circuit 216. Test interface 200F may include logic isolation control 220 and domain synchronization circuit 224. The logic isolation control 220 of test interface 200F is substantially the same as and functionally similar to the logic isolation control 220 of volatile memory interface 200A. Therefore, the logic isolation control 220 of test interface 200F allows processor 140 to lock and unlock test interface 200F. The domain synchronization circuit 224 of test interface 200F is substantially the same as and functionally similar to the domain synchronization circuit 224 of volatile memory interface 200A. As described above, external signals from one or more other components 160 of automotive SoC 104 (e.g., test circuit 216) are prevented from being fed into SI 110 through this configuration. The test functions performed by the automotive SoC 104 receive a test clock signal via the domain synchronization circuit 224 of the debug interface 200E, which switches or converts the test functions performed by the automotive SoC 104 to use a test clock signal generated by SI 110 and / or the second (SI) clock 114. Because test logic is not used when SI 110 is in task mode (e.g., when the vehicle is in motion), SI 110 includes a second clock gate on the test clock to prevent any interference that may be caused by the test clock signal. As a non-limiting example, the second clock gate may be a component of the clock and reset circuit 230. The second clock gate can be controlled (e.g., selectively turned on and off) using a second configuration bit set by the processor 140.

[0052] SI 110 can have at least two operating modes: isolated or cocoon mode and non-isolated mode. When SI 110 operates in cocoon mode, the only information from the automotive SoC 104 allowed to enter SI 110 is fault information, which enters SI 110 via fault interface 172. In this way, SI fault aggregator 142 maintains the cumulative health state of automotive SoC 104 and SI 110. On the other hand, when SI 110 operates in non-isolated mode, information can enter SI 110 via one or more interfaces 200. Whether SI 110 operates in cocoon mode or non-isolated mode is determined at least in part by instruction 149 executed by processor 140 and at least in part by interface 200.

[0053] To help prevent potential safety-critical issues originating from other components 160 of the automotive SoC 104 from reaching the SI 110 via one or more interfaces 200, each interface 200 includes a separate logical isolation control 220, which is selectively locked and unlocked by the processor 140. When the locking mechanism of the logical isolation control 220 is locked by the processor 140, the locking mechanism prevents all communication between the automotive SoC 104 and the SI 110 via that locked interface. On the other hand, the interface can be unlocked by the processor 140 to allow such communication via that unlocked interface. Therefore, the processor 140 selectively places the SI 110 into cocoon mode or non-isolated mode. Whenever all interfaces 200 are locked, the processor 140 cannot access the volatile memory 126 or the non-volatile memory 128 and execute instructions 149 stored in the volatile memory 146 (e.g., SRAM) residing in the SI 110.

[0054] Now for reference Figure 3 Each block of the method 300 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be performed by a processor (e.g., Figure 1 , Figure 2 and Figure 4 The processor 140 shown executes functions stored in memory (e.g., Figure 1 , Figure 2 and Figure 4 Instructions in the volatile memory 146 shown (e.g., Figure 1 , Figure 2 and Figure 4 Method 300 can also be executed as computer-usable instructions stored on a computer storage medium. Method 300 can be provided by a standalone application, service, or managed service (independently or in combination with another managed service), or as a plug-in to another product, to name a few. Furthermore, as an example, Method 300 relates to… Figure 1 The vehicle platform 100 is described. However, method 300 may be performed additionally or alternatively by any system or any combination of systems, including but not limited to those described herein.

[0055] Figure 3 This is a flowchart illustrating a method 300 for switching SI110 between cocoon mode and non-isolation mode according to some embodiments of the present disclosure. For ease of illustration, method 300 will be described as being executed by processor 140 (see [link to documentation]). Figure 1 , Figure 2 and Figure 4 ). refer to Figure 3 In the first block 302, the processor 140 determines that it needs to work with the other components 160 of the automotive SoC 104 (see...). Figure 1and Figure 2 Communication can occur via either the volatile memory interface 200A or the first control backbone interface 200B, each allowing SI 110 to initiate communication with other components 160 of the automotive SoC 104. Alternatively, communication can occur via the second control backbone interface 200C, the secure content interface 200D, the debug interface 200E, or the test interface 200F, each allowing SI 110 to receive communication initiated by other components 160 of the automotive SoC 104. As described above, communication occurs on the fault interface 172, regardless of whether SI 110 is in cocoon mode or non-isolated mode (see [link]). Figure 2 ).

[0056] Whenever processor 140 needs to communicate with a specific component among the other components 160 of the automotive SoC 104, processor 140 determines that communicating with that specific component is safe before attempting to do so. To make this determination, in block 304, processor 140 may check the contents of SI fault aggregator 142, which is connected via one or more fault interfaces 172 (see [link to documentation]). Figure 2 Fault information is received from one or more SoC fault aggregators 152 located outside SI 110. As described above, one or more fault interfaces 172 are not logically isolated from one or more SoC fault aggregators 152, but each provides electrical isolation between the SI and SoC voltage domains via or including a voltage level shifter 240.

[0057] In decision block 306, processor 140 determines whether any fault has been detected in SI fault aggregator 142. When at least one fault is detected, meaning a fault identified for one or more other components 160 has been reported to SI fault aggregator 142 by SoC fault aggregator 152, the decision in decision block 306 is "Yes". Processor 140 can detect faults using status bit 242 within SI fault aggregator 142. Status bit 242 can be characterized as tracking the health status of the automotive SoC 104. Alternatively, SI fault aggregator 142 can notify processor 140 of the fault by sending an interrupt to processor 140. Otherwise, when no fault is detected, the decision in decision block 306 is "No".

[0058] When the decision in decision box 306 is "yes", in box 308, processor 140 may take one or more corrective actions. These corrective actions can help bring the vehicle into a safe state. As a non-limiting example, such corrective actions may include applying the vehicle's brakes, reducing the vehicle's speed, guiding the vehicle to the shoulder, etc. Processor 140 can then return to box 304.

[0059] When the decision in decision box 306 is "No", in box 310, processor 140 unlocks the locking mechanism of the logical isolation control 220 of one or more interfaces 200 connected to a specific component, if the locking mechanism of the specific interface is locked. In other words, when the SI fault aggregator 142 does not store any faults, processor 140 can determine that it is safe to access the specific component of the automotive SoC 104 via the specific interface. Therefore, processor 140 unlocks the specific interface in box 310.

[0060] Then, in block 312, processor 140 can send or receive communication to a specific component via the unlocked specific interface, which automatically starts an access timer 222 for that specific interface. When the specific interface is unlocked, processor 140 can initiate one or more strong sequential accesses (one at a time) to the automotive SoC 104. Access timer 222 starts automatically on a per-access basis. Therefore, access timer 222 can begin counting down as soon as processor 140 initiates a specific access.

[0061] In decision block 314, processor 140 determines whether a timeout has occurred. The decision in decision block 314 is "yes" if access timer 222 indicates that more than a first predetermined amount of time has elapsed and no response has been received from the specific component. Otherwise, the decision in decision block 314 is "no" if a response is received from the specific component before access timer 222 indicates that more than the first predetermined amount of time has elapsed.

[0062] When the decision in decision box 314 is "yes", in box 316, processor 140 indicates that a safety fault has occurred. Then, in box 318, processor 140 locks the locking mechanism of the logical isolation control 220 of a specific interface, optionally locks the locking mechanism of the logical isolation control 220 of any other unlocked interface, and optionally takes one or more actions configured to return the vehicle platform 100 to a safe state.

[0063] On the other hand, when the decision in decision block 314 is "no", in block 320, processor 140 completes communication. Access timer 222 is automatically reset. Then, in block 318, processor 140 locks the locking mechanism of the specific interface. Therefore, method 300 ensures that interface 200 remains locked whenever processor 140 does not access one of the other components 160 of the automotive SoC 104. Then, method 300 terminates.

[0064] SI 110 can avoid accessing shared non-volatile memory 128 by copying instruction 149 (e.g., a critical instruction to put the system into a safe state) from shared non-volatile memory 128 to its internal volatile memory 146 when the automotive SoC 104 is booted. Processor 140 can authenticate and verify instruction 149 before SI 110 enters task mode, which enables vehicle driving cycles. SI 110 can operate simultaneously in task mode and cocoon mode or non-isolated mode. Instruction 149 is retained in volatile memory 146, which allows processor 140 to avoid accessing shared non-volatile memory 128. An internal direct memory access (“DMA”) engine 402 included in SI 110 (see [link to relevant documentation]) can be used. Figure 4 The processor 140 retrieves non-critical data, such as application code and fused data, from the shared volatile memory 126. The DMA engine 402 may optionally be a component of the processor 140. A failure of the DMA engine 402 will not negatively affect the processor 140 because even if the DMA engine 402 fails to paging data retrieved from the shared volatile memory 126, the processor 140 will continue to execute instructions 149 stored in the volatile memory 146.

[0065] Figure 4 This is an illustration of one or more fault interfaces 172 according to some embodiments of the present disclosure. Reference Figure 4 The logic blocks LB(1) to LB(N) of the automotive SoC 104 can be associated with first fault aggregators 260-1 to 260-N, respectively. The first fault aggregators 260-1 to 260-N aggregate faults generated by logic blocks LB(1) to LB(N) and send the first aggregated fault signals to the auxiliary safety unit 122 of the automotive SoC 104. The auxiliary safety unit 122 implements a second SoC fault aggregator 152, which aggregates the first aggregated fault signals received from the first fault aggregators 260-1 to 260-N and sends one or more second aggregated fault signals to an optional external control unit 106 (see...). Figure 1 When the optional external control unit 106 is notified of a fault by the second aggregated fault signal, the optional external control unit 106 may take one or more of several possible actions. First, the optional external control unit 106 may clear the fault. Second, the optional external control unit 106 may take corrective action. Third, the optional external control unit 106 may notify an external system (e.g., one or more external microcontrollers, one or more external agents, etc.). However, as mentioned above, in some embodiments, the optional external control unit 106 may be omitted.

[0066] refer to Figure 1As described above, although SI 110 is isolated from the other components 160 of the automotive SoC 104, at least some communication between SI 110 and the other components 160 of the automotive SoC 104 must be enabled. Specifically, faults occurring in logic blocks LB(1) to LB(N) of the automotive SoC 104 must be transmitted to SI 110 via fault interface 172. One way to provide this communication is to have first fault aggregators 260-1 to 260-N (see...) Figure 4 The first aggregated fault signal is sent directly to SI110. This requires fault interface 172 to include separate transmission lines or signal conductors between SI110 and each of the first fault aggregators 260-1 to 260-N, which is complicated by the isolation of SI110 from the other components 160 of the automotive SoC 104. For example, refer to... Figure 2 The voltage level shifter 240 must include a separate voltage level shifter for each signal conductor. Furthermore, the greater the number of signal conductors between SI 110 and the other components 160 of the automotive SoC 104, the more susceptible SI 110 is to interference originating from the automotive SoC 104.

[0067] Conversely, refer to Figure 4 Each SoC fault aggregator 152 can be connected to SI 110 via three signal conductors: (1) a corrected error signal conductor 410; (2) an uncorrected error signal conductor 412; and (3) an SoC fault aggregator signal conductor 414. This arrangement allows fault interface 172 to report faults from logic blocks LB(1) to LB(N) to SI 110 without fault interface 172 including so many conductors (which would cause electrical interference) and without making fault interface 172 so large that it causes congestion in automotive SoC 104 and / or SI 110. Signal conductors 410, 412, and 414 can be set with status bits “BT1”, “BT2”, and “BT3”, respectively, and each status bit can be subsequently cleared by processor 140 after being set.

[0068] One or more mailboxes 156 can be connected to the interrupt controller 141 of SI 110 via mailbox interrupt signal conductors 416. Signal conductors 410-416 can each be implemented as wires, signal traces, etc.

[0069] Figure 5A This is an illustration of some embodiments of the present disclosure for transmitting a fault to SI 110 (see [reference]). Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 The flowchart for method 500 is shown below. Refer to it now. Figure 5AEach block of the method 500 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be performed by a processor (e.g., Figure 1 and Figure 4 The processor 150 shown executes instructions stored in memory. At least a portion of method 500 may be embodied as computer-usable instructions stored on a computer storage medium. Method 500 may be provided by a standalone application, service, or managed service (independently or in combination with another managed service) or plug-in to another product, to name a few. Furthermore, by way of example, regarding... Figure 1 The vehicle platform 100 describes method 500. However, method 500 may be additionally or alternatively performed by any system or any combination of systems, including but not limited to those described herein.

[0070] For ease of illustration, method 500 will be described as consisting of one or more SoC fault aggregators 152 (see [link to documentation]). Figure 1 , Figure 2 and Figure 4 This is executed by a specific SoC fault aggregator within the system. In other words, method 500 can be executed by hardware. (See reference...) Figure 5A At the first box 502, specific SoC fault aggregators range from the first fault aggregator 260-1 to 260-N (see...). Figure 2 and Figure 4 At least a portion of the signal receives the first aggregated fault signal.

[0071] In block 506, the specific SoC fault aggregator aggregates those first aggregated fault signals that identify faults caused by errors that have been corrected to corrected error signals. Then, in block 508, the specific SoC fault aggregator connects via the corrected error signal conductor 410 (see Corrected Error Signal Conductor 410). Figure 4 The corrected error signal is sent to SI 110 (see...). Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 In box 510, the specific SoC fault aggregator directs each corrected error to interrupt control 154 (see...). Figure 1 and Figure 4 An interrupt is sent, and the interrupt control 154 forwards one or more interrupts to the auxiliary security unit 122 (see...). Figure 1 and Figure 4 The processor 150 (see) Figure 1 and Figure 4 Each interrupt notifies the processor 150 of the corrected error associated with the interrupt.

[0072] In box 512, a specific SoC fault aggregator initiates a corrected error timer 420C for the first corrected error identified in the corrected error signal (see [link]). Figure 4 ).

[0073] In decision block 514, the specific SoC fault aggregator determines whether the first corrected error has been cleared from the specific SoC fault aggregator. This is done during the corrected error timer 420C (see...). Figure 4 If the first corrected error has been cleared more than a second predetermined time period, the decision in decision box 514 is "Yes". Otherwise, the decision in decision box 514 is "No". When the decision in decision box 514 is "Yes", the specific SoC fault aggregator does not take any action in box 515. On the other hand, when the decision in decision box 514 is "No", the specific SoC fault aggregator proceeds to decision box 516.

[0074] In decision block 516, processor 150 determines the calibrated error timer 420C (see [reference]). Figure 4 The decision box 516 determines whether more than a second predetermined time has elapsed, meaning the corrected error timer 420C has timed out or expired. If the second predetermined time has elapsed, the decision in decision box 516 is "Yes". Otherwise, the decision in decision box 516 is "No". If the decision in decision box 516 is "Yes", the specific SoC fault aggregator proceeds to box 518. Otherwise, if the decision in decision box 516 is "No", the specific SoC fault aggregator returns to decision box 514 to wait for the processor 150 to clear the first corrected error. Therefore, the specific SoC fault 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 specific SoC fault aggregator takes no action in box 515. On the other hand, if the corrected error timer 420C expires before the first corrected error is cleared, the specific SoC fault aggregator proceeds to box 518. In box 518, a specific SoC fault aggregator is connected via SoC fault aggregator signal conductor 414 (see [link]). Figure 4 Send the SoC fault aggregator signal to SI 110 (see...) Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 ).

[0075] In block 520, the specific SoC fault aggregator identifies those first aggregated fault signals received in block 502 that are faults caused by errors that have not yet been corrected to uncorrected error signals. Then, in block 522, the specific SoC fault aggregator transmits the signals via uncorrected error signal conductor 412 (see Uncorrected Error Signal Conductor 412). Figure 4 The uncorrected error signal is sent to SI 110 (see...). Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 In box 524, the specific SoC fault aggregator directs each uncorrected error to interrupt control 154 (see [link]). Figure 1 and Figure 4 An interrupt is sent, and the interrupt control 154 forwards one or more interrupts to the auxiliary security unit 122 (see...). Figure 1 and Figure 4 The processor 150 (see) Figure 1 and Figure 4 Each interrupt notifies the processor 150 of the uncorrected error associated with that interrupt.

[0076] In box 526, the specific SoC fault aggregator starts the uncorrected error timer 420U for the first uncorrected error identified in the uncorrected error signal (see [link]). Figure 4 ).

[0077] In decision block 528, the specific SoC fault aggregator determines whether the first uncorrected error has been cleared from the specific SoC fault aggregator. This is done when the uncorrected error timer 420U (see...) is active. Figure 4 If the first uncorrected error has been cleared before more than a third predetermined time has elapsed, the decision in decision box 528 is "Yes". Otherwise, the decision in decision box 528 is "No". When the decision in decision box 528 is "Yes", the specific SoC fault aggregator does not take any action in box 529. When the decision in decision box 528 is "No", the specific SoC fault aggregator proceeds to decision box 530.

[0078] In decision block 530, processor 150 determines whether the uncorrected error timer 420U indicates that more than a third predetermined amount of time has elapsed, which means that the uncorrected error timer 420U (see [reference]) Figure 4The timeout or expiration has occurred. When the third predetermined time has elapsed, the decision in decision box 530 is "yes". Otherwise, the decision in decision box 530 is "no". When the decision in decision box 530 is "yes", the specific SoC fault aggregator proceeds to box 532. On the other hand, when the decision in decision box 530 is "no", the specific SoC fault aggregator returns to decision box 528 to wait for the first uncorrected error to be cleared by processor 150. Therefore, the specific SoC fault aggregator continues to monitor whether the first uncorrected error has been 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 specific SoC fault aggregator does not take any action in box 529. On the other hand, if the uncorrected error timer 420U expires before the first uncorrected error is cleared, the specific SoC fault aggregator proceeds to box 532. In box 532, the specific SoC fault aggregator proceeds via SoC fault aggregator signal conductor 414 (see... Figure 4 Send the SoC fault aggregator signal to SI 110 (see...) Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 At this point, method 500 terminates.

[0079] Figure 5B This illustrates a processor 150 according to some embodiments of the present disclosure (see [link]). Figure 1 and Figure 4 ) can be used to handle faults from the SoC fault aggregator 152 (see Figure 1 , Figure 2 and Figure 4 The flowchart for receiving interrupt method 540 is shown below. Refer to [link / reference] now. Figure 5B Each block of method 540 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be performed by a processor (e.g., processor 150) executing instructions stored in memory. At least a portion of method 540 can be embodied as computer-usable instructions stored on a computer storage medium. Method 540 can be provided by a standalone application, service, or managed service (independently or in combination with another managed service) or plug-in to another product, to name a few. Furthermore, as an example, method 540 is about... Figure 1 The vehicle platform 100 is described. However, method 540 may be performed additionally or alternatively by any system or any combination of systems, including but not limited to those described herein.

[0080] For ease of explanation, method 540 will be described as being performed by processor 150 (see [link]). Figure 1 and Figure 4 ) Execution. Reference Figure 5B In the first block 541, the processor 150 receives a specific interrupt from a specific SoC fault aggregator in one or more SoC fault aggregators 152. Then, in block 542, the processor 150 classifies one or more errors identified in the specific interrupt and may take one or more corrective actions to resolve the errors.

[0081] If a problem occurs in the processor 150's classification of one or more errors and / or initiation of one or more corrective actions, the processor 150 may be unable to continue processing the specific interrupt. When this occurs, the decision in decision block 543 is "yes," and in block 544, the processor 150 takes no further action on the specific interrupt. On the other hand, if the processor 150 is able to classify the specific interrupt and optionally take corrective actions, the decision in decision block 543 is "no." When the decision in decision block 543 is "no," in block 545, the processor 150 writes information related to the specific interrupt to one or more mailboxes 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 via mailbox interrupt signal conductor 416. The mailbox interrupt indicates the severity of the error identified in the interrupt received in block 541.

[0082] Then, in decision block 547, processor 150 determines whether it should clear a fault for a specific interrupt generated from a specific SoC fault aggregator. When processor 150 determines to clear the fault, the decision in decision block 547 is "yes". Otherwise, the decision in decision block 547 is "no". The decision in decision block 547 can be "yes" when one or more corrective actions taken by processor 150 can resolve the error or when the fault was caused by a corrected error (e.g., an error corrected by one of logic blocks LB(1)–LB(N)). As another non-limiting example, the decision in decision block 547 can be "yes" when processor 150 receives a mailbox interrupt from processor 140 instructing processor 140 to clear the error. When the decision in decision block 547 is "no", in block 548, processor 150 does not take further action on the specific interrupt. On the other hand, when the decision in decision block 547 is "yes", in block 549, processor 150 clears the fault from the specific SoC fault aggregator. Processor 150 can notify processor 140 that the fault has been cleared from the specific SoC fault aggregator. Then, method 540 terminates.

[0083] Figure 5C SI 110 is shown as an embodiment of this disclosure (see SI 110). Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 A flowchart of method 550, which can be used to process calibrated and uncalibrated error signals, is provided. Refer now to... Figure 5C Each block of the method 550 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be performed by a processor (e.g., Figure 1 , Figure 2 and Figure 4 The processor 140 shown executes functions stored in memory (e.g., Figure 1 , Figure 2 and Figure 4 Instructions in the volatile memory 146 shown (e.g.) Figure 1 , Figure 2 and Figure 4 The method 550 is executed by the instruction 149 shown. At least a portion of the method 550 may be embodied as computer-usable instructions stored on a computer storage medium. The method 550 may be provided by a standalone application, service, or managed service (independently or in combination with another managed service), or a plug-in to another product, to name a few. Furthermore, as an example, the method 550 relates to… Figure 1 The vehicle platform 100 is described. However, method 550 may be performed additionally or alternatively by any system or any combination of systems, including but not limited to those described herein.

[0084] For ease of explanation, method 550 will be described as being performed by SI fault aggregator 142 (see [link]). Figure 1 , Figure 2 and Figure 4 ) and processor 140 (see Figure 1 , Figure 2 and Figure 4 ) Execution. Reference Figure 5C At the first box 552, SI 110's SI fault aggregator 142 (see...) Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 The SI fault aggregator 142 receives a corrected error signal with the status bit "BT1" set, and / or an uncorrected error signal with the status bit "BT2" set. When the SI fault aggregator 142 receives a corrected error signal on the corrected error signal conductor 410, in block 554, the SI fault aggregator 142 sends a signal to the interrupt controller 141 of the processor 140 (see [link]). Figure 1 , Figure 2 and Figure 4 An interrupt was sent. This interrupt notifies processor 140 of the corrected error.

[0085] In decision box 556, processor 140 (see...) Figure 1 , Figure 2 and Figure 4 Determine whether interrupt signal has been received from processor 150 via mailbox interrupt conductor 416 (see [link]). Figure 1 and Figure 4 A mailbox interrupt is received. When a mailbox interrupt is received, the mailbox interrupt indicates the severity of the corrected error. When processor 140 has received a mailbox interrupt, the decision in decision box 556 is "yes". Otherwise, the decision in decision box 556 is "no". When the decision in decision box 556 is "no", in box 558, processor 140 waits to receive a mailbox interrupt or SoC fault aggregator signal. When the decision in decision box 556 is "yes", processor 140 proceeds to decision box 560.

[0086] In decision box 560, processor 140 (see...) Figure 1 , Figure 2 and Figure 4 The processor 140 determines whether to read mailbox 156. This determination may be based at least in part on the severity of the corrected error transmitted to the processor 140 via the mailbox interrupt. For example, if the severity of the corrected error is equal to or higher than a threshold (e.g., 7), the processor 140 may determine not to read mailbox 156, and if the severity of the corrected error reaches or exceeds the threshold, the processor 140 may determine to read mailbox 156. When the determination in decision box 560 is "yes", the processor 140 reads mailbox 156 in box 562. The processor 140 then proceeds to box 564, where the processor 140 clears the corrected error, for example, by desetting the status bit "BT1". When the determination in decision box 560 is "no", the processor 140 proceeds to box 564 and clears the corrected error, for example, by desetting the status bit "BT1". Before the processor 140 clears the corrected error from SI fault aggregator 142, the processor 140 may wait for notification from processor 150 that the fault corresponding to the corrected error has been cleared from the specific SoC fault aggregator. However, since the error has already been corrected, in some embodiments, the processor 140 can simply clear the corrected error without first receiving such a notification.

[0087] When SI fault aggregator 142 receives an uncorrected error signal on uncorrected error signal conductor 412, in block 566, SI fault aggregator 142 sends an interrupt to interrupt controller 141 of processor 140 (see [link]). Figure 1 , Figure 2 and Figure 4 The interrupt notifies the processor 140 of the uncorrected error.

[0088] In decision box 568, processor 140 (see...) Figure 1 , Figure 2 and Figure 4Determine whether interrupt signal has been received from processor 150 via mailbox interrupt conductor 416 (see [link]). Figure 1 and Figure 4 A mailbox interrupt is received. When a mailbox interrupt is received, the mailbox interrupt indicates the severity of the uncorrected error. When processor 140 has received a mailbox interrupt, the decision in decision box 568 is "yes". Otherwise, the decision in decision box 568 is "no". When the decision in decision box 568 is "no", in box 558, processor 140 waits to receive a mailbox interrupt or SoC fault aggregator signal. When the decision in decision box 568 is "yes", processor 140 proceeds to decision box 570.

[0089] In decision box 570, processor 140 (see...) Figure 1 , Figure 2 and Figure 4 The processor 140 determines whether to read mailbox 156. This determination may be based at least in part on the severity of the uncorrected error. For example, if the severity of the uncorrected error is equal to or higher than a threshold (e.g., 7), the processor 140 may determine not to read mailbox 156, and if the severity of the corrected error is lower than the threshold, the processor 140 may determine to read mailbox 156. When the determination in decision box 570 is "yes", the processor 140 reads mailbox 156 in box 572. Then, the processor 140 proceeds to decision box 573. When the determination in decision box 570 is "no", the processor 140 proceeds to box 573.

[0090] In decision block 573, processor 140 determines whether to take one or more corrective actions. When the determination in decision block 573 is "yes", in block 574, processor 140 takes one or more corrective actions, such as applying the vehicle's brakes. Then, processor 140 proceeds to decision block 575.

[0091] When the decision in decision box 573 is "No", processor 140 proceeds to decision box 575. In decision box 575, processor 140 determines whether to notify external system 404. When the decision in decision box 575 is "Yes", in box 576, processor 140 notifies external system 404 and proceeds to box 578. When the decision in decision box 575 is "No", processor 140 proceeds to box 578.

[0092] In box 578, processor 140 sends a mailbox interrupt to mailbox 156 and / or clears uncorrected errors, for example, by unsetting the status bit "BT2". Optionally, processor 140 may write fault information to mailbox 156. Processor 140 may wait for notification from processor 150 that the fault corresponding to the uncorrected error has been cleared from the specific SoC fault aggregator before processor 140 clears the uncorrected error from SI fault aggregator 142. Then, method 550 terminates. The mailbox interrupt is received by processor 150 and may be determined in decision box 547 (see [link to decision box]) when determining whether processor 150 should clear the fault corresponding to the uncorrected error. Figure 5B The processor 150 may optionally read fault information written to the mailbox 156 by the processor 140 before making this determination.

[0093] Figure 5D SI 110 is shown as an embodiment of this disclosure (see SI 110). Figure 1 , Figure 2 , Figure 4 , Figure 8 and Figure 10 A flowchart of method 580, which can be used to handle SoC fault aggregator signals, is provided. Refer to [link / reference] now. Figure 5D Each block of the method 580 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be performed by a processor (e.g., Figure 1 , Figure 2 and Figure 4 The processor 140 shown executes functions stored in memory (e.g., Figure 1 , Figure 2 and Figure 4 Instructions in the volatile memory 146 shown (e.g.) Figure 1 , Figure 2 and Figure 4 The method 580 is executed by the instruction 149 shown. At least a portion of the method 580 may be embodied as computer-usable instructions stored on a computer storage medium. The method 580 may be provided by a standalone application, service, or managed service (independently or in combination with another managed service), or a plug-in to another product, to name a few. Furthermore, as an example, the method 580 relates to… Figure 1 The vehicle platform 100 is described. However, method 580 may be performed additionally or alternatively by any system or any combination of systems, including but not limited to those described herein.

[0094] For ease of explanation, method 580 will be described as being performed by SI fault aggregator 142 (see [link to documentation]). Figure 1 , Figure 2 and Figure 4 ), processor 140 (see Figure 1, Figure 2 and Figure 4 ) and SoC error handling circuit 422 (see Figure 4 ) Execution. The SoC error handling circuit 422 can be implemented as a component of the SI fault aggregator 142. Reference Figure 5D At the first box 582, SI fault aggregator 142 (see Figure 1 , Figure 2 and Figure 4 ) Receive the SoC fault aggregator signal with the status bit "BT3" set.

[0095] like Figure 5D As shown by the dashed arrow in the image, when the SI fault aggregator 142 (see...) Figure 1 , Figure 2 and Figure 4 When the SoC fault aggregator signal is received, the SoC error handling circuit 422 of SI 110 (see...) Figure 4 It can automatically advance to box 584 and via connection 406 (see...) Figure 4 ) to external system 404 (see Figure 4 Automatically send a SoC error signal including SoC errors. Alternatively, the SoC error handling circuit 422 can advance to block 586 and start the SoC fault timer 424 (see [link]). Figure 4 The SoC fault timer 424 may introduce a delay between receiving the SoC fault aggregator signal and notifying the external system 404. While the SoC fault timer 424 is running, the processor 140 may take one or more corrective actions. If the corrective action is successful, the processor 140 may clear uncorrected errors by desetting status bit "BT2" and clear SoC fault aggregator errors by desetting status bit "BT3". Clearing SoC fault aggregator errors stops the SoC fault timer 424. The processor 140 may wait for notification from the processor 150 that a fault corresponding to one or more uncorrected errors has been cleared from a specific SoC fault aggregator before the processor 140 clears one or more uncorrected errors from the SI fault aggregator 142.

[0096] After the SoC fault timer 424 has started, in decision block 588, the SoC error handling circuit 422 determines whether the SoC fault timer 424 indicates that more than a fourth predetermined time has elapsed. If the SoC fault timer 424 indicates that more than a fourth predetermined time has elapsed and the SoC fault aggregator error has not yet been cleared, the decision in decision block 588 is "yes". On the other hand, if the SoC fault aggregator error has been cleared before the SoC fault timer 424 indicates that more than a fourth predetermined time has elapsed, the decision in decision block 588 is "no".

[0097] When the decision in decision box 588 is "No", in box 590, the SoC error handling circuit 422 waits for the SoC fault timer 424 to indicate that more than a fourth predetermined time has elapsed. On the other hand, when the decision in decision box 588 is "Yes", in box 584, the SoC error handling circuit 422 connects to connection 406 (see...). Figure 4 ) will send a SoC error signal, including SoC errors, to an external system 404 (see Figure 4 This indicates that the first uncorrected error has not been cleared and the SoC fault aggregator error has been asserted. When an SoC error is sent, the SoC fault timer 424 automatically stops and / or resets. Alternatively, the SoC fault handling circuitry 422 may reset the SoC fault timer 424, or the SoC fault timer 424 may simply expire without any action being taken by the SoC fault handling circuitry 422.

[0098] In SI fault aggregator 142 (see Figure 1 , Figure 2 and Figure 4 Upon receiving the SoC fault aggregator signal, in block 592, the SoC fault aggregator 142 may send an interrupt to the processor 140. In block 594, the processor 140 classifies the first uncorrected error. In decision block 595, the processor 140 determines whether to take one or more corrective actions. When the processor 140 determines to take one or more corrective actions, the decision in decision block 595 is "yes". Otherwise, the decision in decision block 595 is "no". When the decision in decision block 595 is "no", the processor 140 proceeds to block 596 and takes no action. On the other hand, when the decision in decision block 595 is "yes", in block 597, the processor 140 takes corrective actions.

[0099] Then, in box 598, processor 140 sends a mailbox interrupt to mailbox 156 and / or, for example, clears SoC fault aggregator errors by desetting status bit "BT3" and clears uncorrected errors by desetting status bit "BT2". Clearing SoC fault aggregator errors causes SoC fault timer 424 to stop. The mailbox interrupt sent to mailbox 156 may indicate that uncorrected errors have been cleared and / or that processor 140 has taken corrective action in box 597. Optionally, processor 140 may write fault information to mailbox 156. Processor 140 may wait for notification from processor 150 that the fault corresponding to the uncorrected error has been cleared from the specific SoC fault aggregator before processor 140 clears SoC fault aggregator errors and uncorrected errors from SI fault aggregator 142. Then, method 580 terminates. A mailbox interrupt is received by processor 150, which may clear the fault corresponding to the uncorrected error. Before clearing the fault, processor 150 may optionally read the fault information written to mailbox 156 by processor 140.

[0100] exist Figures 5A-5D In the automotive SoC 104, a processor 150 is included. In at least some embodiments, the processor 150 may be omitted. In such embodiments, method 540 will not be executed. For each fault, a specific SoC fault aggregator will generate an SoC fault aggregator error (boxes 518 and 532) and send it to the SI fault aggregator 142. Because the processor 150 is absent, the mailbox interrupt will not be sent to the interrupt controller 141, and therefore the processor 140 will wait before taking action. Figure 5C (Box 558) SoC fault aggregator signal. Then, when an SoC fault aggregator error is received ( Figure 5D In box 582), SI 110 will venture into other components 160 to target method 550 (see box 582). Figure 5C Each corrected and uncorrected error received in the process is classified ( Figure 5D (Box 594). If classification is successful, processor 140 takes corrective action ( Figure 5D (Box 597). On the other hand, if classification fails, processor 140 takes no action. Figure 5D (box 596), which causes the SoC error handling circuit 422 to expire at the SoC fault timer 424 ( Figure 5D After box 584), a SoC error is sent (without any software intervention). The SoC error notification to external system 404 (e.g., optional external control unit 106, one or more external microcontrollers, one or more external agents, etc.) allows external system 404 to enable vehicle platform 100 (see [link to documentation]). Figure 1 Return to a safe state.

[0101] Figures 6A-6C Example actions that SI 110 may take when SI 110 is notified of a specific fault by at least one of a calibrated error signal, an uncalibrated error signal, or a SoC fault aggregator signal are shown. Figure 6A Example signal timing diagrams are shown of signals received and transmitted by processor 140 after a low-severity uncorrected error (e.g., minimum value) has been asserted, according to some embodiments of the present disclosure. Figure 6A Lines 612A-618A represent the uncorrected error signal, mailbox interrupt signal, SoC fault aggregate signal, and SoC error signal, respectively. The uncorrected error signal, mailbox interrupt signal, SoC fault aggregate signal, and SoC error signal are synchronized with the clock signal represented by line 610A. The clock signal represented by line 610A is based on the second (SI) clock 114 in the SI field (see...). Figure 1 Generated by ).

[0102] Line 612A indicates the presence of an uncorrected error signal conductor 412 (see [link]). Figure 4 The uncorrected error signal is transmitted to the SI fault aggregator 142. A portion 622A of line 612A represents an assertion of the uncorrected error. After receiving the uncorrected error signal (e.g., Figure 5C (in box 552), SI fault aggregator 142 sends an interrupt to processor 140 (e.g., Figure 5C (frame 566).

[0103] Then, in Figure 6A In the middle, the interrupt controller 141 receives the mailbox interrupt ( Figure 5C The decision in decision box 568 is "Yes". A portion 626A of line 614A represents a mailbox interrupt (sent by processor 150), indicating the severity of an uncorrected error. Because a mailbox interrupt indicates a specific fault has low severity, processor 140 determines to access mailbox 156 (e.g., Figure 5C The decision box 570 is set to "Yes") and the contents of one or more mailboxes 156 are read (for example, Figure 5C (Box 572). If mailbox 156 includes fault information (created by processor 150) indicating that a specific fault has been cleared, then processor 140 clears the specific fault in SI fault aggregator 142 (e.g., Figure 5C (Box 578). If this occurs before the calibrated error timer 420U expires, the SoC fault aggregator 152 will not assert an SoC fault aggregator error (e.g., Figure 5A (Frame 529).

[0104] On the other hand, if the contents of mailbox 156 do not indicate that processor 150 has cleared a specific fault, processor 140 may determine to take one or more corrective actions (e.g., in...). Figure 5C The decision in decision box 573 is "Yes". If the correction action (e.g., in) Figure 5C If the assertion in box 574 is successful, processor 140 can notify processor 150 to de-assert the error (or clear the fault). For example, processor 140 can send a mailbox interrupt to processor 150 and / or write fault information to mailbox 156. After processor 150 receives the notification and de-asserts the error, processor 150 notifies processor 140 that the error has been de-asserted (e.g., via an uncorrected error signal, a mailbox interrupt, and / or fault information stored in mailbox 156). After receiving the notification, processor 140 can clear the error, for example, by unsetting the status bit "BT2" (e.g., ...). Figure 5C (Box 578). Section 624A of line 612A indicates the release assertion of an uncorrected error and the taking of corrective action after processor 140 reads mailbox 156. The curved arrow 628A indicates the delay between processor 140 receiving the mailbox interrupt and processor 140 releasing the assertion of the error (or clearing the fault).

[0105] When the correction is successful, the processor 140 can send a mailbox interrupt to the mailbox 156, indicating that the processor 140 has cleared a specific fault (e.g., Figure 5C (See box 578). Optionally, processor 140 can write fault information to mailbox 156. Processor 150 receives a mailbox interrupt, determines that a specific fault has been corrected by processor 140 (e.g., the decision in decision box 547 is "yes"), and clears the specific fault from SoC fault aggregator 152 (e.g., ...). Figure 5B (Box 549). If this occurs before the uncorrected error timer 420U expires, the SoC fault aggregator 152 will not assert an SoC fault aggregator error (e.g., Figure 5A (See box 529). Therefore, the SoC fault aggregator 152 monitors for a specific fault to ensure it has been processed by one of the processors 140 and 150, and if the specific fault has not been cleared before the uncorrected error timer 420U expires, the SoC fault aggregator 152 notifies the SoC error handling circuitry 422. As described above, after the processor 150 deasserts the error, the processor 150 notifies the processor 140 that the error has been deassertified (e.g., via an uncorrected error signal, mailbox interrupt, and / or fault information stored in mailbox 156), and the processor 140 can clear the error in the SoC fault aggregator 142.

[0106] Line 616A represents the SoC fault aggregation signal and indicates an unasserted SoC fault aggregation error. Therefore, the uncorrected fault is cleared before the uncorrected fault timer 420U expires.

[0107] Line 618A indicates a SoC error signal that can be sent to external system 404 (e.g., optional external control unit 106, one or more external microcontrollers, one or more external agents, etc.) via connection 406. Because the uncorrected error has been processed and the SoC fault aggregation error has not been asserted, line 618A indicates that SI 110 did not notify external system 404 of the uncorrected error (e.g., the decision in decision block 575 is "No").

[0108] Figure 6B Example signal timing diagrams are shown of signals received and transmitted by processor 140 after a high severity uncorrected error (e.g., maximum value) has been asserted, according to some embodiments of the present disclosure. Figure 6B Lines 612B-618B represent the uncorrected error signal, mailbox interrupt signal, SoC fault aggregate signal, and SoC error signal, respectively. The uncorrected error signal, mailbox interrupt signal, SoC fault aggregate signal, and SoC error signal are synchronized with the clock signal represented by line 610B. The clock signal represented by line 610B is based on the second (SI) clock 114 in the SI field (see...). Figure 1 Generated by ).

[0109] Line 612B indicates the presence of an uncorrected error signal conductor 412 (see [link]). Figure 4 The uncorrected error signal is transmitted to the SI fault aggregator 142. A portion 622B of line 612B represents an assertion of the uncorrected error. After receiving the uncorrected error signal (e.g., Figure 5C (in box 552), SI fault aggregator 142 sends an interrupt to processor 140 (e.g., Figure 5C (frame 566).

[0110] Then, in Figure 6B In the middle, the interrupt controller 141 receives a mailbox interrupt (e.g., Figure 5C The decision in decision box 568 is "yes". A portion of line 614B, 624B, indicates a mailbox interruption, which indicates that the first uncorrected error has high severity (e.g., seven). Because a mailbox interruption indicates that a specific fault has high severity, processor 140 determines not to access mailbox 156 (e.g., ...). Figure 5C (The decision in decision box 570 is "No"). For example, processor 140 may determine that accessing other components 160 of the automotive SoC 104 is too risky and doing so could harm SI 110. Figure 6BIn addition, processor 140 also determines not to take one or more corrective actions (e.g., Figure 5C The decision in decision box 573 is "No". Figure 6B In this case, because SI 110 cannot perform one or more correction actions, the uncorrected error is not removed from the assertion.

[0111] However, processor 140 determines to notify external system 404 of a SoC error by sending a SoC error signal (see [link]). Figure 4 )(For example, Figure 5C The decision in decision box 575 is "yes". Then, processor 140 sends a SoC error signal (e.g., Figure 5C (Box 576). Therefore, in Figure 6B In this scenario, when the severity of the fault is high (e.g., maximum), SI 110 may determine not to access the automotive SoC 104, take no corrective action, and instead notify the external system 404. Line 618B represents the SoC error signal sent by SI 110 to the external system 404, and a portion 626B of line 618B represents an assertion of the SoC error. Line 616B represents the SoC fault aggregation signal and does not indicate that the SoC fault aggregation error has been asserted. Therefore, SI 110 recognizes that an uncorrected error has not been processed and determines to notify the external system 404 before the SoC fault aggregation error is asserted.

[0112] Figure 6C Example signal timing diagrams are shown of signals received and transmitted by processor 140 after an uncorrected error (e.g., maximum value) has been asserted but SI 110 has not received a mailbox interrupt, according to some embodiments of the present disclosure. Figure 6C Lines 612C-618C represent the uncorrected error signal, mailbox interrupt signal, SoC fault aggregate signal, and SoC error signal, respectively. The uncorrected error signal, mailbox interrupt signal, SoC fault aggregate signal, and SoC error signal are synchronized with the clock signal represented by line 610C. The clock signal represented by line 610C is based on the second (SI) clock 114 in the SI field (see...). Figure 1 Generated by ).

[0113] Line 612C indicates the presence of an uncorrected error signal conductor 412 (see [link]). Figure 4 The uncorrected error signal is transmitted to the SI fault aggregator 142. A portion 622C of line 612C represents an assertion of the uncorrected error. After receiving the uncorrected error signal (e.g., Figure 5C (in box 552), SI fault aggregator 142 sends an interrupt to processor 140 (e.g., Figure 5C (frame 566).

[0114] exist Figure 6C In this example, line 614C does not indicate that a mailbox interrupt has been received. Therefore, in this example, interrupt controller 141 does not receive a mailbox interrupt (e.g., Figure 5C The decision in decision box 568 is "No". For example, this might happen when processor 150 fails to classify uncorrected errors (e.g., Figure 5B (box 542), which leads to ( Figure 5C The processor 150 failed to send a mailbox interruption (e.g., the judgment in the decision box 543 is "yes") Figure 5B (Box 544). Therefore, processor 140 waits to receive either a mailbox interrupt or a SoC fault aggregator error, whichever occurs first (e.g., Figure 5C (frame 558).

[0115] Line 628C indicates the third predetermined time amount and shows the expiration of the uncorrected error timer 420U. Because neither processor 140 nor processor 150 can clear the first uncorrected error, the uncorrected error timer 420U is allowed to expire (e.g., Figure 5A If the decision in decision box 530 is "yes", this causes a specific SoC fault aggregator in SoC fault aggregator 152 to send an uncorrected error signal to SI 110 and send an interrupt to processor 150, so as to transmit the SoC fault aggregator signal via SoC fault aggregator signal conductor 414 (e.g., in Figure 5A (In box 532) is sent to SI fault aggregator 142. SI fault aggregator 142 receives SoC fault aggregator signals (e.g., in...) Figure 5D (In box 582). Section 624C of line 616C represents an SI fault aggregator error sent to SI 110 by a specific SoC fault aggregator. The curved arrow 630C represents the delay between SI 110 receiving an uncorrected error and SI 110 receiving an SI fault aggregator error.

[0116] After receiving the SI fault aggregator signal (e.g., Figure 5D (in box 582), SI fault aggregator 142 sends an interrupt to processor 140 (e.g., Figure 5D (box 592). Then, processor 140 can classify the first uncorrected error (e.g., Figure 5D The processor 140 then determines whether to take any corrective action. If the processor 140 cannot take any corrective action (e.g., ...), Figure 5D If the decision in decision box 595 is "No", then the SoC error handling circuit 422 will send an SoC error signal to the external system 404 (e.g., Figure 5C(See box 584). Section 626C of line 612C indicates a SoC error sent to external system 404. In embodiments using SoC fault timer 424, the SoC error is sent when the SoC fault timer 424 expires. Figure 6C In the diagram, line 632C indicates that more than the fourth predetermined time has elapsed, meaning that the SoC fault timer 424 has expired. The curved arrow 634C represents the delay between SI 110 receiving the SI fault aggregator error and SI 110 asserting an SoC error. Therefore, the hardware in SI 110 notifies external system 404, which will attempt to return the vehicle platform 100 to a safe state.

[0117] refer to Figure 2 As described above, SI 110 and other components 160 of the automotive SoC 104 share volatile memory 126. However, SI 110 operates within a first risk classification level, and the other components 160 of the automotive SoC 104 can operate within a lower second risk classification level. For example, SI 110 can operate under ASIL-D, but other components of the automotive SoC, including volatile memory 126 and the communication paths between SI 110 and volatile memory 126 (e.g., interconnects, memory controllers, etc.), can operate under ASIL-B.

[0118] To allow SI 110 to share volatile memory 126 with other components 160 of the automotive SoC 104, a separate dedicated memory region (referred to as a “reserved area” 250) is created within volatile memory 126 for exclusive use by SI 110. Reserved area 250 may be accessible to the main CPU complex 120 (see [link to main CPU complex]). Figure 1 The memory management software being executed (e.g., Rich-OS memory management software) is not visible. Reserved area 250 can be created and configured at boot time and can remain dedicated to SI 110 for a given boot cycle. For example, the size of reserved area 250 can be determined by user-editable software parameters used by software (e.g., executed by the main CPU complex 120) to configure reserved area 250. Reserved area 250 can be divided into a first sub-section 252 (see...). Figure 8 ) and the second sub-part 254 (see Figure 8 SI 110 can access the reserved area 250 via a communication path operating under the first risk classification level, and any access to the reserved area 250 by SI 110 via the communication path is subject to security permission checks, such as those described below.

[0119] SI 110 includes an error detection block 272, which comprises hardware located between SI 110 and the reserved area 250. Therefore, the error detection block 272 can be implemented as a component of the volatile memory interface 200A. Alternatively, the error detection block 272 can be located between the processor 140 and the volatile memory interface 200A. In such an embodiment, one or more signal conductors (e.g., wires, signal traces, etc.) can connect the error detection block 272 to each of the processor 140 and the volatile memory interface 200A.

[0120] The hardware for error detection block 272 may include code generation subblock 273 (see...) Figure 8 Code generation subblock 273 can be implemented using CRC code generation circuitry that generates cyclic redundancy check (“CRC”) codes. Alternatively, error detection block 272 may include other types of code generation circuitry that generate different types of error detection codes, such as error correction codes (“ECC”). The hardware of error detection block 272 determines one or more error detection codes (e.g., CRC codes) for the data passing through error detection block 272. For example, error detection block 272 can determine a separate error detection code for each data byte passing through error detection block 272. The error detection code can be calculated based on the byte and the data address in reserved area 250 where the byte is to be stored. For example, Equation 1 below can be used to determine the error detection code for a specific data byte to be written to reserved area 250:

[0121] crc_out Byte x =CRC(Byte Address,Byte Data) Equation 1

[0122] In equation 1 above, the variable "crc_out" Byte x This indicates an error detection code calculated based on the byte represented by the variable "Byte Data" and the data address represented by the variable "Byte Address". In Equation 1, the function "CRC" uses the values ​​of the variables "Byte Data" and "Byte Address" as inputs and outputs the variable "crc_out". Byte x The value of "". When present, the output of the function "CRC" can be at least partially generated by the code to produce sub-block 273 (see [link]). Figure 8 )calculate.

[0123] After determining the error detection code, error detection block 272 determines (for example, using an offset) the code address of the error detection code. For example, Equation 2 below can be used to determine the error detection code for a specific byte of data to be written to reserved area 250.

[0124] crc_out_address=write_address+fixed_offset Equation 2

[0125] In Equation 2 above, the variable "crc_out_address" represents the code address calculated based on the data address represented by the variable "write_address" and the offset represented by the variable "fixed_offset". As mentioned above, reserved area 250 can be divided into multiple sub-parts, where the first sub-part 252 (see...) Figure 8 ) Store data and the second sub-part 254 (see Figure 8 The error detection code is stored in the second sub-part 254. Therefore, the data address represented by the variable "ByteAddress" in Equation 1 above can be located in the first sub-part 252, while the code address represented by the variable "write_address" in Equation 2 above can be located in the second sub-part 254. In such an embodiment, the value of the variable "fixed_offset" can be equal to the size of the first sub-part 252 of the reserved area 250 to ensure that the error detection code will be stored in the second sub-part 254. In this way, address-based separation is used to separate data from the error detection code, so that a fault occurring in one of the first and second sub-parts 252 and 254 will not affect the other.

[0126] Error detection block 272 introduces a delay (e.g., several clock cycles) between storing data at the data address and storing the error detection code at the code address. This delay reduces the likelihood that events that negatively affect the data (e.g., transient events) will also negatively affect the error detection code. In other words, the delay helps provide immunity to common-cause and transient faults, which helps prevent problems such as clock glitches. Error detection block 272 can buffer two or more bytes of data and their corresponding error detection codes before storing them in reserved area 250. Then, error detection block 272 can store the data bytes (e.g., 16 bytes) in the first sub-section 252, followed by the delay. Next, error detection block 272 can store the corresponding error detection code (e.g., 16 bytes) in the second sub-section 254.

[0127] Now for reference Figure 7 Each block of the method 700 described herein includes a process that can be performed using any combination of hardware, firmware, and / or software. For example, method 700 can be comprised of error detection block 272 (see [link to documentation]). Figure 2 , Figure 8 and Figure 10 The functions can be executed by the hardware of a processor (e.g., ...). As another non-limiting example, one or more functions can be executed by the processor (e.g., ...). Figure 1 , Figure 2 and Figure 4 The processor 140 shown executes functions stored in memory (e.g., Figure 1 , Figure 2 and Figure 4 Instructions in the volatile memory 146 shown (e.g., Figure 1 , Figure 2 and Figure 4 The method 700 is executed by instructions 149 shown in the figure. In such an embodiment, at least a portion of the method 700 may be embodied as computer-usable instructions stored on a computer storage medium. The method 700 may be provided by a standalone application, service, or managed service (independently or in combination with another managed service) or a plug-in to another product, to name just a few. Furthermore, as an example, the method 700 relates to... Figure 1 The vehicle platform 100 is described herein. However, method 700 may be additionally or alternatively performed by any system or any combination of systems, including but not limited to those described herein.

[0128] Figure 7 This illustrates an embodiment of the present disclosure for writing data to a reserved area 250 (see [link]). Figure 2 , Figure 8 and Figure 10 The flowchart of method 700 is shown. For ease of illustration, method 700 will be described as being executed by error detection block 272 (see [link to flowchart]). Figure 2 , Figure 8 and Figure 10 Before method 700 begins, the initiator operating in the SI domain (e.g., processor 140, DMA engine 402, etc.) forwards a first write instruction, including data and a data address, to error detection block 272. The initiator can then write data of a predetermined size (e.g., 16 bytes) to reserved area 250.

[0129] refer to Figure 7 At the first frame 702, error detection block 272 (see...) Figure 2 , Figure 8 and Figure 10 The system receives a first write instruction from the initiator, which includes data and a data address. In block 704, error detection block 272 selects a portion of the data and one of the data addresses corresponding to that portion. As a non-limiting example, error detection block 272 may select bytes of data and the data address corresponding to the selected byte in block 704. In some embodiments, the first write instruction may include only a single data address (e.g., a first address). Subsequent data addresses may be determined based on this single address (e.g., by adding a predetermined data size to the single data address). Therefore, in some embodiments, data addresses may be calculated for at least some data in block 704.

[0130] Then, in box 706, error detection block 272 determines an error detection code for the data portion selected in box 704 (e.g., using Equation 1 above). Next, in box 708, error detection block 272 forwards a first write instruction, including the data portion selected in box 704 and its corresponding data address, to reserved area 250 (see...). Figure 2 , Figure 8 and Figure 10 The first sub-part 252 (see) Figure 8 and 10 According to the first write instruction, reserved area 250 stores this portion in the corresponding data address in the first sub-part 252.

[0131] In the next box 710, error detection block 272 (see...) Figure 2 , Figure 8 and Figure 10 The code address of the error detection code determined in box 706 is determined (e.g., using Equation 2 above). In box 712, error detection block 272 waits (e.g., several clock cycles) to send the error detection code to reserve area 250 (see...). Figure 2 , Figure 8 and Figure 10 The first sub-part 252 (see) Figure 8 and Figure 10 Therefore, in block 712, error detection block 272 introduces a delay between the storage of data in the data address and the storage of the error detection code in the code address. Error detection block 272 may include a write delay timer (not shown) for determining how long error detection block 272 waits in block 712. Therefore, error detection block 272 may wait a fifth predetermined amount of time before sending the error detection code to the reservation area 250 for storage in the code address. Next, in block 714, error detection block 272 forwards a second write instruction including the error detection code determined in block 706 and the code address determined in block 710 to the reservation area 250 (see...). Figure 2 , Figure 8 and Figure 10 The second sub-part 254 (see) Figure 8 and Figure 10 Therefore, in order to store the data, the error detection block 272 accesses the reserved area 250 twice, once in box 708 and once in box 714. According to the second write instruction, the reserved area 250 stores the error detection code at the code address in the second sub-section 254.

[0132] Then, in decision box 716, error detection block 272 (see...) Figure 2 , Figure 8 and Figure 10The error detection block 272 determines whether any data has not yet been stored. If the error detection block 272 determines that at least some data has not been stored, the decision in decision box 716 is "yes". Otherwise, the decision in decision box 716 is "no". When the decision in decision box 716 is "yes", the error detection block 272 returns to box 704 to select a new data portion. Conversely, when the decision in decision box 716 is "no", the error detection block 272 returns to box 702 to receive new data and a new data address.

[0133] As described above, error detection block 272 can cache two or more bytes of data and their corresponding error detection codes before storing them in reserve area 250. For example, each of blocks 706-714 can be executed for multiple data blocks (e.g., selected in block 704). As a non-limiting example, error detection block 272 can execute block 706 for the byte of data before sending the first write instruction along with two or more bytes of data and their corresponding data addresses to reserve area 250 in block 708. For example, error detection block 272 can send the byte of data along with the first data address to first sub-section 252. First sub-section 252 can write the byte of data into a contiguous memory address starting from the first data address. Then, in block 710, error detection block 272 can determine the code addresses of the two or more error detection codes determined in block 706. In block 712, error detection block 272 introduces a delay between writing the byte of data and writing the error detection codes to reserve area 250. Then, in block 714, error detection block 272 forwards a second write instruction, including the error detection code and the code address, to second sub-section 254. Second sub-section 254 writes the error detection code to the code address. Depending on the implementation details, the second write instruction may only include the first code address, and second sub-section 254 may write the error detection code to a consecutive memory address starting from the first code address.

[0134] Figure 8 Execution method 700 is shown (see Figure 7 Example of error detection block 272. SI 110 may include one or more initiators 800, such as processor 140, DMA engine 402, etc., each initiator 800 operating within the SI domain. Figure 8 In this context, initiator 800 includes initiator 802 (e.g., processor 140). Initiator 802 (e.g., processor 140) can write data of a predetermined size (e.g., 16 bytes) to reserved area 250. Figure 8 In the example shown, initiator 802 sends 16 bytes of data and a first data address to error detection block 272. The data is stored or represented in a 128-bit array named "wdata_in[127:0]". Figure 8The first data address is stored or represented in a 40-bit array named "Address_0[39:0]". Figure 8 However, depending on implementation details, the data can have other sizes, and 128 bits is provided as a non-limiting example. Similarly, the first data address can have other sizes, and 40 bits is provided as a non-limiting example. The first byte of data can be stored in the first data address, and the next data address for the second byte of data can be identified by adding a byte to the first data address, and so on. Figure 8 The diagram depicts the initiator 802 sending a first write instruction 804 to the error detection block 272 via a security island interconnect 808 in signal 806. As described above, the first write instruction 804 includes data and a first data address. The security island interconnect 808 can be implemented as a bus, etc.

[0135] The security island interconnect 808 transmits the first write instruction 804 to the error detection block 272 (e.g., Figure 7 (Block 702). In the illustrated embodiment, the security island interconnect 808 transmits a first write instruction 804 in signals 810-0 to 810-15, each signal including a first data address and one of the byte data. In this embodiment, error detection block 272 generates an error detection code for each byte of data, and the generated error detection code is a CRC code. When a byte is received in signals 810-0 to 810-15, error detection block 272 can begin processing those bytes (e.g., Figure 7 (frame 704).

[0136] Next, code generation sub-block 273 determines the error detection code for each byte of data (e.g., Figure 7 (Box 706). Figure 8 In the diagram, the signal carrying the error detection code and the signal 838 carrying the response from the reserved area 250 associated with the error detection code are shown by dashed arrows. Therefore, the code generation sub-block 273 outputs data bytes in signals 812-0 to 812-15 and corresponding error detection codes in signals 814-0 to 814-15. (Data) signals 812-0 to 812-15 are routed to the first sub-section 252 for storage, and (code) signals 814-0 to 814-15 are routed to the second sub-section 254 for storage.

[0137] Error detection block 272 at the first time (e.g., in Figure 8 The identifier is "Time=T0" in the middle, which is transmitted via the volatile memory interface 200A (see...). Figure 2The error detection block 272 sends the data and a first data address (e.g., in signals 812-0 to 812-15) to the first sub-section 252 of the reservation area 250. In other words, the error detection block 272 sends the first write instruction to the first sub-section 252 of the reservation area 250 (e.g., ...). Figure 7 (See box 708). The volatile memory interface 200A transmits the first write instruction to the reserved area 250 via the data backbone and memory subsystem 826 of the automotive SoC 104 (see box 708). Figure 1 , Figure 2 and Figure 4 ).exist Figure 8 In the first write instruction, the error detection block 272 sends the first write instruction to the first sub-part 252 in signal 824.

[0138] The first sub-part 252 passes the first byte (in...) Figure 8 (represented as "Data0") is stored at the first data address (in Figure 8 The data is written to memory by writing subsequent bytes to the address following the first data address (represented as "Address_0"). This writing occurs at the first moment, which is... Figure 8 This is represented as "Time = T0". Then, the first sub-part 252 sends a response signal 828 to the initiator 802, acknowledging that the data has been stored. The response signal 828 is sent by the first sub-part 252 to the data backbone and memory subsystem 826, which forwards the response signal 828 to the volatile memory interface 200A (see...). Figure 2 When the volatile memory interface 200A is unlocked, the volatile memory interface 200A sends a response signal 828 to the first (data) buffer 820.

[0139] The first (data) buffer 820 reorders the "data write complete response" received in the response signal 828 from the reservation area 250. For example, the error detection block 272 can reorder a pair of write instructions A and B (e.g., in...) Figure 7The first write instruction (B) sent in block 708 is sent to the reserve area 250. Write instruction B is sent by error detection block 272 after write instruction A. After the data included in write instructions A and B is written in the reserve area 250, the reserve area 250 sends the first and second data write complete responses to error detection block 272. However, the received second data write complete response for write instruction B may arrive at error detection block 272 before the first data write complete response for write instruction A. When this happens, the first (data) buffer 820 stores the second data write complete response, waits for the first data write complete response, sends the first data write complete response when it arrives, and sends the second data write complete response after the first data write complete response. Therefore, the first (data) buffer 820 places the data write complete responses in the response signal 828 in the desired order.

[0140] The first (data) buffer 820 forwards the response signal 828 to the security island interconnect 808, which in turn forwards the response signal 828 to the initiator 802. At this point, in this example, data (e.g., 16 bytes) has already been written to the first sub-part 252 in the first single write operation.

[0141] Error detection block 272 also determines the first code address based on the first data address (e.g., Figure 7 (Frame 710). Figure 8 In this example, the first code address is calculated by adding 16 megabytes (“MB”) to the first data address. However, depending on implementation details, the offset can have other sizes, and 16MB is provided as an example. Furthermore, other methods and / or calculations can be used to determine the location of the first code address.

[0142] Error detection block 272 waits (e.g., Figure 7 (box 712), until the second moment (e.g., in Figure 8 (Identified as "Time=T1"). The first and second time points are different. In the second time point, the error detection block 272 is transmitted via the volatile memory interface 200A (see...). Figure 2 The error detection block 272 sends the error detection code and the first code address to the second sub-section 254 of the reserved area 250. In other words, the error detection block 272 sends the second write instruction to the second sub-section 254 of the reserved area 250 (e.g., Figure 7 (See box 714). The volatile memory interface 200A transmits the second write command to the reserved area 250 via the data backbone and memory subsystem 826 of the automotive SoC 104 (see box 714). Figure 1 , Figure 2 and Figure 4 ).exist Figure 8 In the second write instruction, the error detection block 272 sends the second write instruction to the second sub-section 254 via signal 834.

[0143] The second sub-part 254 passes the first error detection code (in... Figure 8 The CRC0 value is stored at the first code address (in...). Figure 8 The error detection code (represented as "Address_1") is written to the memory by writing the subsequent error detection code to the address following the first code address. Then, the second sub-part 254 sends a response signal 838 to the initiator 802, confirming that the error detection code has been stored. Figure 8 In the illustrated embodiment, response signal 838 is sent from second sub-part 254 to data backbone and memory subsystem 826, which forwards response signal 838 to volatile memory interface 200A (see...). Figure 2 When the volatile memory interface 200A is unlocked, it forwards a response signal 838 to the second (code) buffer 822. The second (code) buffer 822 reorders the "code write complete responses" received from the reservation area 250 in the response signal 838. For example, the error detection block 272 determines first and second error detection codes for the data included in write instructions A and B, respectively, and sends these codes to the reservation area 250 (e.g., in a second write instruction). After the reservation area 250 writes the first and second error detection codes to memory, it sends the first and second code write complete responses to the second (code) buffer 822, respectively. However, the received second code write complete response for the second error detection code may arrive at the error detection block 272 before the first code write complete response for the first error detection code. When this occurs, the second (code) buffer 822 stores the second code write complete response, waits for the first code write complete response, sends the first code write complete response when it arrives, and sends the second code write complete response after the first code write complete response.

[0144] The second (code) buffer 822 can discard the response signal 838. Alternatively, the second (code) buffer 822 can forward the response signal 838 to the security island interconnect 808, which can then forward the response signal 838 to the initiator 802. In this example, the error detection code (e.g., 16 bytes) has already been written to the second sub-part 254 in the second single write operation.

[0145] The volatile memory interface 200A may include two parallel and optionally dedicated interfaces connecting the error detection block 272 to the volatile memory 126. Data can be sent to a first data address via the first interface, and error detection codes can be sent to a first code address via the second interface. In such an embodiment, the error detection block 272 can send a first write instruction (e.g., in signal 824) including data and the first data address to a first sub-section 252 via the first interface, while simultaneously sending a second write instruction (e.g., in signal 834) including an error detection code and the first code address to a second sub-section 254 via the second interface. Furthermore, the (data) response signal 828 and the (code) response signal 838 can be simultaneously transmitted to the first and second buffers 820 and 822 via the first and second interfaces, respectively.

[0146] When the initiator 802 of SI 110 (e.g., processor 140) wants to read data from the reserved area 250, SI 110 receives both the data and the error detection code from the reserved area 250. SI 110 introduces a delay between reading data from the data address and reading the error detection code from the code address. This delay reduces the likelihood that events that negatively affect the data will also negatively affect the error detection code. SI 110 passes the read data through error detection block 272, which determines the checksum for the read data and compares the error detection code with the checksum. This comparison can be represented by the following Equation 3:

[0147] CRC_gen(Requested address, Fetched Data)==crc_in Byte x (CRC_address) Equation 3

[0148] In Equation 3, the operator "==" indicates whether the expression on the left side of the operator "==" is equal to the expression on the right side of the operator "==". The variable "Fetched Data" represents at least a portion of the data obtained in box 906 (e.g., byte x), the variable "Requested address" represents the data address of that data portion, and the variable "CRC_address" represents the code address determined based on the data address of the data portion (e.g., byte x). The function "CRC_gen" takes the values ​​of the variables "Fetched Data" and "Requested address" as input, and the function "CRC_gen" outputs the checksum of that portion (e.g., byte x). The function "CRC_gen" can be the same as the function "CRC" in Equation 1 above. When present, the output of the function "CRC_gen" can be at least partially generated by the code generation sub-block 273 (see...). Figure 8 ) Calculation. The expression "crc_inByte x "(CRC_address)" represents the error detection code obtained from the code address determined using its data address as that part (e.g., byte x). Therefore, Equation 3 determines whether the check code is equal to or matches the error detection code. When the check code does not match the error detection code, the error detection block 272 can generate a mismatch error. The error detection block 272 can send the mismatch error to the initiator 802 and the SI fault aggregator 142, so that the mismatch error can be cleared by security software implemented by instruction 149 and executed by processor 140.

[0149] Now for reference Figure 9 Each block of the method 900 described herein includes a process that can be performed using any combination of hardware, firmware, and / or software. For example, method 900 can be comprised of error detection block 272 (see [link to documentation]). Figure 2 , Figure 8 and Figure 10 The functions can be executed by the hardware of a processor (e.g., a processor ... Figure 1 , Figure 2 and Figure 4 The processor 140 shown executes functions stored in memory (e.g., Figure 1 , Figure 2 and Figure 4 Instructions in the volatile memory 146 shown (e.g., Figure 1 , Figure 2 and Figure 4 The method 900 is executed by instruction 149 shown. At least a portion of the method 900 may be embodied as computer-usable instructions stored on a computer storage medium. The method 900 may be provided by a standalone application, service, or managed service (alone or in combination with another managed service) or a plug-in to another product, to name a few. Furthermore, by way of example, the method 900 relates to Figure 1 The method 900 is described in relation to the automotive platform 100. However, the method 900 may be performed additionally or alternatively by any system or any combination of systems, including but not limited to those described herein.

[0150] Figure 9 This illustrates some embodiments of the present disclosure for use from the reserved area 250 (see [link]). Figure 2 , Figure 8 and Figure 10 A flowchart of method 900 for reading data. For ease of illustration, method 900 will be described as being executed by error detection block 272 (see...). Figure 2 , Figure 8 and Figure 10 Before method 900 begins, initiator 802 (see...). Figure 8The first read instruction, which includes one or more data addresses, is forwarded to error detection block 272. As a non-limiting example, the first read instruction may include only the first data address. (See reference...) Figure 9 In block 902, error detection block 272 receives a first read instruction, including a data address, from initiator 802. In block 904, error detection block 272 forwards the first read instruction to first sub-section 252, which requests data stored at that data address. If the first read instruction only includes the first data address, first sub-section 252 can read a predetermined amount of data (e.g., 16 bytes) from a contiguous memory address starting at the first data address. In block 906, error detection block 272 receives the data stored at that data address from first sub-section 252.

[0151] Then, in box 908, error detection block 272 determines the code address corresponding to the error detection code of the data (e.g., using Equation 2 above). As a non-limiting example, the code address can be determined at least partially based on the data address. For example, according to Equation 2 above, each code address can be calculated by adding an offset (the value of the variable "fixed_offset") to the corresponding data address (the value of the variable "write_address") in that data address. Depending on the implementation details, error detection block 272 may identify only the first code address based on the first data address. Then, in box 910, error detection block 272 waits (e.g., several clock cycles) to request the error detection code stored at the code address determined in box 908. Therefore, in box 910, error detection block 272 introduces a delay between reading the error detection code from the code address and reading the data. Error detection block 272 may include a read delay timer (not shown) for determining how long error detection block 272 waits at box 910. Therefore, the error detection block 272 can wait for a sixth predetermined amount of time before requesting the error detection code from the second sub-part 254.

[0152] After waiting, in the next block 912, error detection block 272 sends a second read instruction to a second sub-part 254 that includes the code addresses determined in block 908 and requests the error detection codes stored at those code addresses. Therefore, to read data, error detection block 272 accesses reserved area 250 twice, once in block 904 and once in block 912. If the second read instruction only includes the first code address, the second sub-part 254 can read a predetermined number of error detection codes (e.g., 16 bytes) from a contiguous memory address starting at the first code address. In block 914, error detection block 272 receives the error detection codes stored at that code address from the second sub-part 254. In block 916, error detection block 272 determines a checksum for each error detection code obtained in block 914 (e.g., using Equation 1 above).

[0153] In decision box 918, for each error detection code, error detection block 272 determines whether the error detection code matches the corresponding check code (e.g., using Equation 3 above). When the error detection code matches its corresponding check code, the decision in decision box 918 is "yes". Otherwise, the decision in decision box 918 is "no". When the decision in decision box 918 is "yes", in box 920, error detection block 272 forwards the data corresponding to the error detection code to initiator 802 (see...). Figure 8 When the decision in decision box 918 is "No", in box 922, error detection block 272 generates a mismatch error and sends it to initiator 802 and SI fault aggregator 142 (see...). Figure 1 , Figure 2 and Figure 4 This allows mismatch errors to be cleared by security software implemented by instruction 149 and executed by processor 140. Optionally, in block 922, if the error detection code (e.g., implemented as ECC) includes information (e.g., bits) that can be used to recover the data, error detection block 272 may attempt to correct the mismatch. If error detection block 272 is able to correct the error, then generating the mismatch error in block 922 may be omitted. After block 920, error detection block 272 proceeds to block 920 and forwards the data to initiator 802. Then, method 900 terminates.

[0154] Error detection block 272 can read two or more bytes of data and their corresponding error detection codes from reserved area 250 at a time. For example, each of blocks 904-914 can be executed for multiple data blocks. As a non-limiting example, in block 904, error detection block 272 can send a first read instruction to a first sub-part 252 requesting two or more bytes of data from a first data address. The first sub-part 252 can read data bytes from a contiguous memory address starting at the first data address and send the data bytes to error detection block 272, which receives these data bytes in block 906. Then, in block 908, error detection block 272 can determine the code address based on the data address. Depending on implementation details, error detection block 272 can identify only the first code address based on the first data address. Then, in block 910, error detection block 272 introduces a delay between reading the data bytes and reading the error detection codes from reserved area 250. Next, error detection block 272 can request the error detection codes stored in reserved area 250 for the data bytes obtained in block 906. For example, error detection block 272 can send the first code address to the second sub-part 254. The second sub-part 254 can read the error detection code from a contiguous memory address starting at the first code address and send the error detection code to error detection block 272, which receives the error detection code in box 914. Then, method 900 continues to box 916.

[0155] Figure 10An example of error detection block 272 in execution method 900 is shown. In this example, processor 140 from Figure 8 The example shown reads 16 bytes of data from reserved area 250. Figure 10 In the process, the read data is stored in or represented by a 128-bit array named "rdata_in[127:0]", and the data is stored starting from the first data address, which is stored in or represented by a 40-bit array named "Address_0[39:0]". Figure 10 An initiator 802 (e.g., processor 140) is depicted, which sends a first read instruction 1004 to an error detection block 272 via a security island interconnect 808. The security island interconnect 808 passes the first read instruction 1004 to the error detection block 272 (e.g., Figure 9 (frame 902).

[0156] Error detection block 272 at the third time (e.g., at) Figure 8 The identifier "Time = T3" is used via the volatile memory interface 200A (see [link]). Figure 2 The error detection block 272 forwards the first read instruction to the first sub-section 252 of the reserved area 250. In other words, the error detection block 272 forwards the first read instruction to the first sub-section 252 of the reserved area 250 (e.g., ...). Figure 9 (Box 904). The volatile memory interface 200A transmits the first read command to the reserved area 250 via the data backbone and memory subsystem 826 of the automotive SoC 104. Figure 10 In the first read instruction, the error detection block 272 sends the first read instruction to the first sub-section 252 in signal 1010.

[0157] The first sub-part 252 reads data from memory starting with the first byte (“byte 0”) at the first data address, and reads subsequent bytes from subsequent data addresses after the first data address. SI110 can read data of a predetermined size (e.g., 16 bytes) from the reserved area 250. The first sub-part 252 then sends a response signal 1012 to the initiator 802, which includes the data that has been read. The response signal 1012 is sent by the first sub-part 252 to the data backbone and memory subsystem 826, which forwards the response signal 1012 to the volatile memory interface 200A (see...). Figure 2 When the volatile memory interface 200A is unlocked, the volatile memory interface 200A forwards the response signal 1012 to the first (data) buffer 820 (e.g., Figure 9(See box 906). The data that has been read and included in the response signal 1012 automatically indicates that the data read is complete, and can therefore be characterized as a data read complete response. Similar to what the first (data) buffer 820 does for a data write complete response, the first (data) buffer 820 can place the data read complete response in the response signal 1012 in the expected order. In this example, data (e.g., 16 bytes) has already been read from the first sub-part 252 in the first single read operation and placed by the first (data) buffer 820 in the expected order.

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

[0159] Next, error detection block 272 waits (for example, Figure 9 (in box 910) until the fourth moment (e.g., in Figure 10 The error detection block 272 is identified as "Time=T4" in the middle. At the fourth time, the error detection block 272 is transmitted via the volatile memory interface 200A (see...). Figure 2 The error detection block 272 requests the error detection code stored at the first code address within the second sub-section 254. In other words, the error detection block 272 sends the second read instruction to the second sub-section 254 of the reserved area 250 (e.g., Figure 9 (Box 912). The volatile memory interface 200A transmits the second read command to the reserved area 250 via the data backbone and memory subsystem 826 of the automotive SoC 104. Figure 10 In the middle, the second read instruction is sent by the error detection block 272 to the second sub-section 254 in signal 1014.

[0160] The second sub-part 254 reads the error detection code from memory by reading the first error detection code at the first code address (for "byte0") and subsequent error detection codes from subsequent code addresses after the first code address. In such cases... Figure 8 and Figure 10 In the example shown, the error detection code is one byte in size. Then, the second sub-part 254 sends a response signal 1016 to the initiator 802, which includes the error detection code read from memory. Figure 10 In the diagram, signals carrying error detection codes and signal 1014 are indicated by dashed arrows. Figure 10 In the illustrated embodiment, response signal 1016 is sent from second sub-part 254 to data backbone and memory subsystem 826, which forwards response signal 1016 to volatile memory interface 200A (see...). Figure 2When 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., Figure 9 (See box 914). The error detection code that has been read and included in the response signal 1016 automatically indicates that the code read is complete, and can therefore be characterized as a code read complete response. Similar to what the second (code) buffer 822 does for a code write complete response, the second (code) buffer 822 can place the code read complete response in the response signal 1016 in the expected order. In this example, the error detection code (e.g., 16 bytes) has already been read from the second sub-part 254 in the second single read operation and placed by the second (code) buffer 822 in the expected order.

[0161] When error detection block 272 waits (for example, ...), Figure 9 (in box 910) until the fourth moment (e.g., in Figure 10 When the time is marked as "Time = T4", the error detection block 272 only separates the first and second read instructions by time. After receiving the data in the response signal 1012, the error detection block 272 can request an error detection code from the second sub-part 254. Alternatively, the error detection block 272 may not wait to receive the data in the response signal 1012 before requesting the error detection code from the second sub-part 254. In other words, the fourth time can be determined based on when the first read instruction is sent rather than when the response signal 1012 is received.

[0162] As described above, because the bytes in response signal 1012 may be out of order, the first (data) buffer 820 can reorder the bytes. Similarly, when the error detection code is out of order in response signal 1016, the second (code) buffer 822 can reorder the error detection code. The first (data) buffer 820 outputs signals 1022-0 to 1022-15, each carrying one data byte, while the second (code) buffer 822 outputs signals 1024-0 to 1024-15, each carrying one error detection code. Signals 1022-0 to 1022-15 correspond to signals 1024-0 to 1024-15, respectively. The first and second buffers 820 and 822 can route or reorder signals 1022-0 to 1022-15 and 1024-0 to 1024-15 to position each data byte at a known position relative to the error detection code created for that byte. Figure 10 In the illustrated embodiment, the bytes carried by signals 1022-0 to 1022-15 are interleaved with the error detection codes carried by signals 1024-0 to 1024-15. Therefore, as... Figure 10 As shown, the data bytes are placed in the positions indicated by the shaded blocks b0-b15, and the error detection code is placed in the positions indicated by the blocks c0-c15.

[0163] Then, code generation sub-block 273 determines (e.g., using Equation 1 above) the checksum for each data byte (e.g., Figure 9 (See box 916). Therefore, the code generation sub-block 273 receives the data bytes from signals 1022-0 to 1022-15 and the corresponding error detection codes from signals 1024-0 to 1024-15 as input.

[0164] For each error detection code, error detection block 272 determines whether the error detection code matches the check code corresponding to the error detection code (e.g., Figure 9 The decision block 918). Error detection block 272 indicates whether they match in the pass signal 1030, which is forwarded to the logic component 1034 along with the data signal 1032 including the data bytes, such as... Figure 10 As shown, the logic component is implemented as an AND gate. If the pass signal 1030 indicates that the error detection code stored for the byte matches the check code created for the byte, the logic component 1034 outputs the byte in the check data signal 1036 (which only includes data bytes) and forwards the check data signal 1036 to the initiator 802. On the other hand, if the pass signal 1030 indicates a mismatch, the logic component 1034 does not forward the byte in the check data signal 1036 to the initiator 802. Instead, the error detection block 272 may discard the byte and / or replace it with information indicating that a mismatch has occurred (e.g., zero). As a non-limiting example, the bit of the byte that caused the mismatch may be set to zero. The check data signal 1036 is forwarded to the initiator 802 (e.g., Figure 9 (Box 920). When the error detection code does not match the check code corresponding to the error detection code, the error detection block 272 can generate a mismatch error and send it to the initiator 802 (e.g., box 920). Figure 9 (See box 922). In other words, if the transmission signal 1030 indicates one or more mismatches, the error detection block 272 can generate a mismatch error and send it to the initiator 802. Optionally or additionally, the error detection block 272 can send the mismatch error to the SI error aggregator 142 as an uncorrected error. Therefore, any errors that occur in data or error detection codes during storage in and / or retrieval from the retention area 250 can be detected and reported (e.g., as uncorrected errors).

[0165] As described above, the volatile memory interface 200A may include two parallel and optionally dedicated interfaces connecting the error detection block 272 to the volatile memory 126. In such an embodiment, the error detection block 272 may send a first read instruction (e.g., in signal 1010) including a first data address to the first sub-part 252 via the first interface, while simultaneously sending a second read instruction including a first code address to the second sub-part 254 via the second interface (e.g., in signal 1014). Furthermore, data read from the first sub-part 252 (e.g., transmitted in response signal 1012) and error detection codes read from the second sub-part 254 (e.g., transmitted in response signal 1016) may be simultaneously transmitted to the first and second buffers 820 and 822 via the first and second interfaces, respectively.

[0166] refer to Figure 2 Error detection block 272 may include or be connected to at least one transaction timer, such as exit and entry timers 274 and 276, which limit the amount of time error detection block 272 must read data from and / or write data to reservation area 250. Exit timer 274 and / or entry timer 276 are automatically started whenever an access pass through error detection block 272. For example, entry timer 276 may start whenever data is transferred between error detection block 272 and initiator 802 (e.g., processor 140), and exit timer 274 may start whenever data is transferred between error detection block 272 and SoC domain (e.g., reservation area 250). Entry timer 276 can help monitor the functionality of error detection block 272 and / or can help provide backup functionality for exit timer 274 (e.g., if exit timer 274 malfunctions).

[0167] During a write operation, when the initiator 802 passes data to the error detection block 272 to write to the reserved area 250, the entry timer 276 can be started (e.g., in...). Figure 7 (box 702). Then, when the data exits the error detection block 272 and / or the SI field, the exit timer 274 can be started (e.g., in box 702). Figure 7 (Box 708). When error detection block 272 receives a response from reserve area 250 (e.g., Figure 8 When the response signal 828 shown is received, the output timer 274 can be stopped or reset. Then, when the response (e.g., Figure 8 The response signal 828 shown is transmitted by the error detection block 272 to the initiator 802 (see [link]). Figure 8 The entry timer 276 can be stopped or reset when the timeout timer 274 indicates that more than a first threshold amount of time has elapsed and the error detection block 272 has not received a response, which means that the initiator 802 has not received a response from the reservation area 250 (e.g., Figure 8If the response signal 828 shown in the figure is received, the initiator 802 (e.g., processor 140) generates an exit timeout error. If the entry timer 276 indicates that more than the second threshold amount of time has elapsed and the error detection block 272 does not send a response to the initiator 802, which means that the initiator 802 has not received a response from the reservation area 250, the initiator 802 generates an entry timeout error.

[0168] During a read operation, the entry timer 276 can be started when the error detection block 272 receives a read request from the initiator 802 (e.g., in...). Figure 9 (Box 902). Then, the exit timer 274 can be activated when the error detection block 272 requests data stored at the first data address from the reservation area 250 (e.g., in...). Figure 9 The error detection block 272 is activated when it receives data from the reservation area 250 (e.g., in [the context of the error detection block 904]). Figure 9 In box 906), the exit timer 274 can be stopped or reset. Then, when the error detection block 272 transmits data to the initiator 802 (e.g., in...), Figure 9 (in box 920), the ingress timer 276 can be stopped or reset. If the egress timer 274 indicates that a first threshold time has elapsed and the error detection block 272 has not yet received data from the retention area 250, this means that the initiator 802 has not yet received data from the error detection block 272 (e.g., in...). Figure 10 If the verification data signal 1036 shown is not received, the initiator 802 generates an exit timeout error. If the entry timer 276 indicates that more than the second threshold time has elapsed and the error detection block 272 has not sent data to the initiator 802, which means that the initiator 802 has not received data from the reservation area 250, the initiator 802 generates an entry timeout error.

[0169] Figure 11 It is shown according to some embodiments when the error detection block 272 includes or is connected to the exit and entry timers 274 and 276 (see [reference]). Figure 2 When the error is detected by error detection block 272 (see...) Figure 2 , Figure 8 and Figure 10 A diagram illustrating the generated error notification. (e.g.) Figure 11 As shown, the starter 802 (see Figure 8 and Figure 10 Send the first write instruction 804 (see error detection block 272) to the error detection block 272. Figure 8 ) or first read instruction 1004 (see Figure 10Signal 1102. As described above, the exit timer 274 can be started when data exits the error detection block 272 and / or the SI field during a write operation, and the exit timer 274 can be started when the error detection block 272 requests data stored at the first data address from the reservation area 250 during a read operation. Box 1104 indicates that the exit timer 274 has timed out. For example, when the error detection block 272 does not receive a response from the reservation area 250 during a write operation (e.g., Figure 8 The exit timer 274 may time out when the response signal 828 shown in the diagram has elapsed for more than the first threshold time. As another non-limiting example, when the error detection block 272 has not received data during a read operation (e.g., in...), the exit timer 274 may time out. Figure 10 The exit timer 274 may time out when more than a first threshold time has elapsed (as shown in response signal 1012). When the exit timer 274 has timed out, the initiator 802 (e.g., processor 140) generates an exit timeout error 1106 and forwards it to the error logger 1108. Alternatively, if the exit timer 274 has not timed out, it may be stopped or reset. This could occur if the error detection block 272 receives a response (e.g., response signal 828) from the reservation area 250 during a write operation or receives data from the reservation area 250 during a read operation (e.g., as shown in response signal 1012) before the first threshold time has elapsed.

[0170] As described above, the entry timer 276 can pass data to the error detection block 272 during a write operation by the initiator 802 for writing to the reserved area 250 (e.g., in...). Figure 7 The entry timer 276 can be started when the error detection block 272 receives a read request from the initiator 802 during a read operation (e.g., in block 702), or the entry timer 276 can be started when the error detection block 272 receives a read request from the initiator 802 during a read operation (e.g., in block 702). Figure 9 The signal is activated when frame 902 is included. Therefore, when signal 1102 includes the first read instruction 804 (see frame 902), the read operation begins. Figure 8 ) or first read instruction 1004 (see Figure 10 And the instruction is checked by error detection block 272 (see...) Figure 2 , Figure 8 and Figure 10 When received, the entry timer 276 (see...) Figure 2 It can be started. Box 1114 indicates that the entry timer 276 has timed out. For example, when more than the second threshold time has elapsed and the starter 802 (see...) Figure 8 No response was received from reserve 250 during the write operation (e.g., Figure 8When the response signal 828 shown is received, the entry timer 276 may time out. As another non-limiting example, when more than a second threshold amount of time has elapsed and the initiator 802 has not received data from the reservation area 250 during the read operation (e.g., ...), Figure 10 When the check data signal 1036 is shown, the entry timer 276 may time out. When the entry timer 276 times out, the initiator 802 generates an entry timeout error 1116 and forwards the entry timeout error 1116 to the error logger 1108. On the other hand, if the entry timer 276 has not yet timed out, the entry timer 276 may be stopped or reset. This may occur when the error detection block 272 transmits a response (e.g., response signal 828) to the initiator 802 during a write operation, or when the error detection block 272 transmits data (e.g., check data signal 1036) to the initiator 802 during a read operation.

[0171] Box 1124 indicates error detection block 272 (see...) Figure 2 , Figure 8 and Figure 10 Code generation sub-block 273 (see code 273) Figure 2 , Figure 8 and Figure 10 The code generation / verification error 1126 can be generated, indicating that an error occurred during the generation of an error detection code or a check code. In some embodiments, the code generation / verification error 1126 can be used to indicate that a mismatch has occurred. As a non-limiting example, when signal 1102 includes a first write instruction 804, the code generation sub-block 273 can generate a code generation error while generating an error detection code. As another non-limiting example, when signal 1102 includes a first read instruction 1004, the error detection block 272 can generate a mismatch error and / or a code generation error while generating a check code, and the check code is forwarded to the error logger 1108 as code generation / verification error 1126.

[0172] Error logger 1108 can be used as a fault aggregator to aggregate errors 1106, 1116 and 1126 into error notification 1130, which is then sent to SI fault aggregator 142.

[0173] When the automotive SoC 104 is first booted, the processor 140 of SI 110 may attempt to prefetch data from the reserved area 250. Prefetching can be characterized as a type of unintentional read of data from the reserved area 250. Since the shared volatile memory 126 is volatile, at this point, the reserved area 250 may be storing uninitialized data that lacks error detection codes or is associated with mismatched error detection codes. To prevent mismatch errors from occurring in the error detection block 272, SI 110 (e.g., processor 140, DMA engine 402, and / or the like) may write one or more error detection codes to the reserved area 250 for the data that the processor 140 will or may prefetch. As a non-limiting example, SI 110 may write initial data to the reserved area 250, causing the hardware of the error detection block 272 to determine one or more error detection codes for the initial data, each error detection code associated with a code address. SI 110 may then cause the reserved area 250 to store each error detection code at its associated code address. Therefore, during the prefetch operation, the error detection code stored in the second sub-part 254 will correspond to the data stored in the first sub-part 252, and the error detection block 272 will not generate a mismatch error.

[0174] refer to Figure 2 If the vehicle platform is 100 (see...) Figure 1 No reserved area 250 is required; SI 110 can generate code into sub-block 273 (see...). Figure 2 , Figure 8 and Figure 10 The code generation subblock 273 and / or error detection block 272 may be disabled (e.g., by using software registration writes). For example, when the volatile memory 126 is operating to meet the risk level of the automotive platform 100, SI 110 may disable the code generation subblock 273 and / or error detection block 272.

[0175] It should be understood that these and other arrangements described herein are merely illustrative examples. Other arrangements and elements (e.g., machines, interfaces, functions, sequences, functional groups, etc.) may be used in addition to or in place of those shown, and some elements may be omitted. Furthermore, many of the elements described herein are functional entities that can be implemented as discrete or distributed components or in combination with other components, and in any suitable combination and location. The various functions described herein as being performed by entities can be performed by hardware, firmware, and / or software. For example, various functions can be performed by a processor executing instructions stored in memory.

[0176] Example autonomous vehicles

[0177] Figure 12This is an illustration of an example autonomous vehicle 1200 according to some embodiments of the present disclosure. The autonomous vehicle 1200 (which may alternatively be referred to herein as “vehicle 1200”) may include, but is not limited to, passenger vehicles such as cars, trucks, buses, first-response vehicles, shuttles, electric or motorized bicycles, motorcycles, fire trucks, police vehicles, ambulances, boats, construction vehicles, underwater vessels, drones, and / or other types of vehicles (e.g., drones and / or vehicles accommodating one or more passengers). Autonomous vehicles are generally described according to levels of automation defined by the National Highway Traffic Safety Administration (NHTSA), the U.S. Department of Transportation, and the Society of Automotive Engineers (SAE) in “Classification and Definition of Terms Related to Driving Automation Systems for Road Motor Vehicles” (published June 15, 2018, Standard No. J3016-201806, published September 30, 2016, Standard No. J3016-201609, and previous and future versions of this standard). Vehicle 1200 is capable of having one or more of the functions of Level 2 to Level 5 of autonomous driving levels as defined by SAE. For example, depending on the embodiment, vehicle 1200 is capable of having partial driving automation (Level 2), conditional automation (Level 3), high automation (Level 4), and / or full automation (Level 5).

[0178] Vehicle 1200 may include components such as chassis, body, wheels (e.g., 2, 4, 6, 8, 18, etc.), tires, axles, and other vehicle parts. Vehicle 1200 may include a propulsion system 1250, such as an internal combustion engine, a hybrid electric power station, an all-electric motor, and / or another propulsion system type. Propulsion system 1250 may be connected to the drivetrain of vehicle 1200, which may include a transmission to enable propulsion of vehicle 1200. Propulsion system 1250 may be controlled in response to signals received from throttle / accelerator 1252.

[0179] When the propulsion system 1250 is operational (e.g., when the vehicle is in motion), 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). The steering system 1254 may receive signals from the steering actuator 1256. The steering wheel may be optional for fully automated (Level 5) functionality.

[0180] The brake sensor system 1246 can be used to operate the vehicle brakes in response to receiving signals from the brake actuator 1248 and / or the brake sensor.

[0181] It may include one or more CPUs, System-on-a-Chip (SoC) 1204 ( Figure 14The controller 1236 of the GPU and / or the sensor can provide signals (e.g., signals representing commands) to one or more components and / or systems of the vehicle 1200. For example, one or more controllers can send signals to operate vehicle braking via one or more brake actuators 1248, to operate steering system 1254 via one or more steering actuators 1256, and / or to operate propulsion system 1250 via one or more throttles / accelerators 1252. The controller 1236 may include one or more onboard (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals and output operating commands (e.g., signals representing commands) to enable autonomous driving and / or assist human drivers in driving the vehicle 1200. The controller 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 functions (e.g., computer vision), a fourth controller 1236 for infotainment functions, a fifth controller 1236 for redundancy in emergency situations, and / or other controllers. In some examples, a single controller 1236 can handle two or more of the above functions, two or more controllers 1236 can handle a single function, and / or any combination thereof.

[0182] The controller 1236 may provide signals for controlling one or more components and / or systems of the vehicle 1200 in response to sensor data (e.g., sensor inputs) received from one or more sensors. Sensor data may be received from, for example, but not limited to, a global navigation satellite system sensor 1258 (e.g., a Global Positioning System sensor), one or more RADAR sensors 1260, one or more ultrasonic sensors 1262, one or more LIDAR sensors 1264, one or more inertial measurement unit (IMU) sensors 1266 (e.g., one or more accelerometers, one or more gyroscopes, one or more magnetic compasses, one or more magnetometers, etc.), one or more microphones 1296, one or more stereo phase-detection sensors, etc. The sensor 1268, one or more wide-angle cameras 1270 (e.g., fisheye cameras), one or more infrared cameras 1272, one or more surround cameras 1274 (e.g., 360-degree cameras), one or more long-range and / or mid-range cameras 1298, one or more speed sensors 1244 (e.g., for measuring the speed of vehicle 1200), one or more vibration sensors 1242, steering sensor 1240, brake sensor 1246 (e.g., as part of brake sensor system 1246), and / or other sensor types.

[0183] One or more of the controllers 1236 may receive input (e.g., represented by input data) from the instrument panel 1232 of the vehicle 1200 and provide output (e.g., represented by output data, display data, etc.) via a human-machine interface (HMI) display 1234, audible signals, speakers, and / or other components of the vehicle 1200. Outputs may include, for example, vehicle speed, velocity, time, map data (e.g., ...). Figure 14 Information such as the HD mapping 1222, location data (e.g., the location of vehicle 1200, such as on a map), direction, the location of other vehicles (e.g., occupying a grid), information about objects such as those perceived by controller 1236 and the state of those objects, etc. For example, HMI display 1234 may display information about the presence of one or more objects (e.g., street signs, warning signs, traffic light changes, etc.), and / or information about driving maneuvers that the vehicle has performed, is performing, or will perform (e.g., changing lanes now, exiting exit 34B within two miles, etc.).

[0184] Vehicle 1200 further includes a network interface 1224 that can communicate over one or more networks using one or more wireless antennas 1226 and / or a modem. For example, network interface 1224 may be able to communicate via LTE, WCDMA, UMTS, GSM, CDMA2000, etc. Wireless antenna 1226 may also use 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.) to enable communication between objects in the environment (e.g., vehicles, mobile devices, etc.).

[0185] As mentioned above, in at least some embodiments, the vehicle platform 100 (see...) Figure 1 This can be a component of an autonomous vehicle 1200. In such an embodiment, one or more controllers 1236 include an automotive SoC 104.

[0186] Figure 13 According to some embodiments of the present invention Figure 12 This is an example of the camera position and field of view of an autonomous vehicle 1200. The camera and corresponding field of view are an exemplary embodiment and are not intended to be limiting. For example, additional and / or alternative cameras may be included and / or the cameras may be located at different positions on the vehicle 1200.

[0187] The camera type may include, but is not limited to, a digital camera suitable for use with components and / or systems of vehicle 1200. The camera may operate at Automotive Safety Integrity Level (ASIL) B and / or another ASIL. Depending on the embodiment, the camera type may have any image capture rate, such as 60 frames per second (fps), 120 fps, 240 fps, etc. The camera may be able to use a rolling shutter, a global shutter, another type of shutter, or a combination thereof. In some examples, the color filter array may include a red transparent transparent (RCCC) color filter array, a red transparent blue (RCCB) color filter array, a red blue green transparent (RBGC) color filter array, a Foveon X3 color filter array, a Bayer sensor (RGGB) color filter array, a monochrome sensor color filter array, and / or another type of color filter array. In some embodiments, a transparent pixel camera (such as a camera with RCCC, RCCB, and / or RBGC color filter arrays) may be used to increase photosensitivity.

[0188] In some examples, one or more cameras can be used to perform advanced driver assistance system (ADAS) functions (e.g., as part of a redundant or fail-safe design). For example, a multi-functional single camera can be installed to provide functions including lane departure warning, traffic sign assistance, and intelligent headlight control. One or more cameras (e.g., all cameras) can simultaneously record and provide image data (e.g., video).

[0189] One or more cameras can be mounted in mounting components such as custom-designed (3D-printed) components to reduce stray light and reflections from inside the vehicle (e.g., reflections from the dashboard in the windshield mirror) that could interfere with the camera's image data capture capabilities. Referring to wing mirror mounting components, wing mirror components can be custom-3D printed so that the camera mounting plate matches the shape of the wing mirror. In some examples, one or more cameras can be integrated into the wing mirror. For side-view cameras, the cameras can also be integrated into four pillars at each corner of the cockpit.

[0190] A camera with a field of view encompassing a portion of the environment in front of the vehicle 1200 (e.g., a forward-facing camera) can be used for surround view, aiding in the identification of forward-facing paths and obstacles with the assistance of one or more controllers 1236 and / or control SoCs, and providing information crucial for generating an occupancy grid and / or determining a preferred vehicle path. The front-facing camera can be used to perform many of the same ADAS functions as LiDAR, including emergency braking, pedestrian detection, and collision avoidance. The front-facing camera can also be used in ADAS functions and systems, including Lane Departure Warning (LDW), Autonomous Cruise Control (ACC), and / or other functions such as traffic sign recognition.

[0191] Various cameras can be used in forward-facing configurations, including, for example, monocular camera platforms including CMOS (Complementary Metal-Oxide-Semiconductor) color imagers. Another example could be a wide-angle camera 1270 used to perceive objects entering the view from the periphery (e.g., pedestrians, cross traffic, or bicycles). Although in Figure 13 Only one wide-angle camera is shown, but any number of wide-angle cameras 1270 may be present on vehicle 1200. Additionally, one or more remote cameras 1298 (e.g., a long-view stereo camera pair) can be used for depth-based object detection, especially for objects for which the neural network has not yet been trained. The remote camera 1298 can also be used for object detection and classification, as well as basic object tracking.

[0192] One or more stereo cameras 1268 may also be included in a forward-facing configuration. The stereo camera 1268 may include an integrated control unit containing a scalable processing unit that provides programmable logic (e.g., an FPGA) and a multi-core microprocessor with an integrated CAN or Ethernet interface on a single chip. This unit can be used to generate a 3D map of the vehicle environment, including distance estimates for all points in the image. Alternative stereo cameras 1268 may include a compact stereo vision sensor and an image processing chip. The compact stereo vision sensor may include two camera lenses (each on the left and right sides), and the image processing chip can measure the distance from the vehicle to a target object and use the generated information (e.g., metadata) to activate autonomous emergency braking and lane departure warning functions. Other types of stereo cameras 1268 may be used in addition to or in place of the stereo cameras described herein.

[0193] Cameras with a field of view including a portion of the environment on the side of vehicle 1200 (e.g., side-view cameras) can be used for surrounding view, providing information for creating and updating occupancy grids, and generating side impact collision warnings. For example, one or more surround cameras 1274 (e.g., such as...) Figure 13 The four surround cameras 1274 shown can be positioned around the vehicle 1200. The surround cameras 1274 may include a wide-angle camera 1270, a fisheye camera, a 360-degree camera, and / or the like. For example, four fisheye cameras may be located at the front, rear, and sides of the vehicle. In an alternative arrangement, the vehicle may use three surround cameras 1274 (e.g., left, right, and rear), and may utilize one or more other cameras (e.g., forward-facing cameras) as a fourth surround-view camera.

[0194] A camera having a field of view that includes a portion of the environment behind the vehicle 1200 (e.g., a rear-view camera) can be used for parking assistance, surround view, rear collision warning, and creating and updating occupancy grids. A wide variety of cameras can be used, including but not limited to those also suitable as one or more front-facing cameras (e.g., one or more long-range and / or mid-range cameras 1298, one or more stereo cameras 1268, one or more infrared cameras 1272, etc.), as described herein.

[0195] Figure 14 According to some embodiments of this disclosure Figure 12 The example autonomous vehicle 1200 is illustrated in the block diagram of an example system architecture. It should be understood that this and other arrangements are illustrated by way of example only. Other arrangements and elements (e.g., machines, interfaces, functions, sequences, functional groupings, etc.) may be used in addition to or in place of those shown, and some elements may be omitted together. Furthermore, many of the elements described herein are functional entities that can be implemented as discrete or distributed components or in combination with other components, and implemented in any suitable combination and location. The different functions described herein as being performed by entities can be performed by hardware, firmware, and / or software. For example, different functions can be performed by a processor executing instructions stored in memory.

[0196] Figure 14 Each component, feature, and system of vehicle 1200 is shown connected via bus 1202. Bus 1202 may include a Controller Area Network (CAN) data interface (which may alternatively be referred to herein as the "CAN bus"). CAN may be a network within vehicle 1200 used to help control various features and functions of vehicle 1200, such as brake actuation, acceleration, braking, steering, windshield wipers, etc. The CAN bus may be configured to have dozens or even hundreds of nodes, each with its own unique identifier (e.g., CAN ID). The CAN bus can be read to find steering wheel angle, ground speed, engine revolutions per minute (RPM), button positions, and / or other vehicle status indicators. The CAN bus may be ASIL B compliant.

[0197] Although bus 1202 is described herein as a CAN bus, this is not intended to be limiting. For example, FlexRay and / or Ethernet may be used as a complement or alternative to the CAN bus. Furthermore, although a single line is used to represent bus 1202, this is not intended to be limiting. For example, any number of buses 1202 may exist, which may include one or more CAN buses, one or more FlexRay buses, one or more Ethernet buses, and / or one or more other types of buses using different protocols. In some examples, two or more buses 1202 may be used to perform different functions and / or 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 component of vehicle 1200, and two or more buses 1202 may communicate with the same component. In some examples, each SoC 1204, each controller 1236, and / or each computer within the vehicle may access the same input data (e.g., input from sensors of vehicle 1200) and may be connected to a common bus, such as a CAN bus.

[0198] Vehicle 1200 may include one or more controllers 1236, such as those described herein. Figure 12 The controller 1236 can be used for a variety of functions. The controller 1236 can be coupled to any of the various other components and systems of the vehicle 1200, and can be used to control the vehicle 1200, the artificial intelligence of the vehicle 1200, the infotainment of the vehicle 1200, etc.

[0199] Vehicle 1200 may include a system-on-a-chip (SoC) 1204. SoC 1204 may include one or more CPUs 1206, one or more GPUs 1208, one or more processors 1210, one or more caches 1212, one or more accelerators 1214, one or more data storage 1216, and / or other components and features not shown. One or more SoCs 1204 can be used to control vehicle 1200 in various platforms and systems. For example, one or more SoCs 1204 may be combined with an HD mapping 1222 in a system (e.g., the system of vehicle 1200), the HD mapping 1222 being accessible via a network interface 1224 from one or more servers (e.g., [server name missing]). Figure 15 One or more servers (1278) receive map refresh and / or updates.

[0200] One or more CPUs 1206 may include CPU clusters or CPU complexes (alternatively referred to herein as “CCPLEX”). CPUs 1206 may include multiple cores and / or L2 cache. For example, in some embodiments, one or more CPUs 1206 may include eight cores in a consistent multiprocessor configuration. In some embodiments, one or more CPUs 1206 may include four dual-core clusters, each with a dedicated L2 cache (e.g., 2MB L2 cache). CPUs 1206 (e.g., CCPLEX) may be configured to support simultaneous cluster operation, thereby enabling any combination of clusters of CPUs 1206 to be active at any given time.

[0201] The CPU 1206 implements power management capabilities including one or more of the following features: individual hardware blocks can be automatically clock-gated when idle to conserve dynamic power; each core clock can be gated when a core is not actively executing instructions due to the execution of WFI / WFE instructions; each core can be independently power-gated; each core cluster can be independently clock-gated when all cores are clock-gated or power-gated; and / or each core cluster can be independently power-gated when all cores are power-gated. The CPU 1206 also implements enhanced algorithms for managing power states, specifying allowed power states and desired wake-up times, and the hardware / microcode determines the optimal power state to enter for each core, cluster, and CCPLEX. The processing core can support simplified power state entry sequences in software offloaded to the microcode.

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

[0203] The GPU 1208 can be power-optimized for optimal performance in automotive and embedded applications. For example, the GPU 1208 can be fabricated on FinFETs. However, this is not intended to be limiting, and other semiconductor manufacturing processes can be used to fabricate the GPU 1208. Each streaming microprocessor can combine multiple mixed-precision processing cores that are divided into multiple blocks. For example, but not limited to, 64 PF32 cores and 32 PF64 cores can be divided into four processing blocks. In this example, each processing block can be allocated 16 FP32 cores, 8 FP64 cores, 16 INT32 cores, two mixed-precision NVIDIA TENSOR COREs for deep learning matrix operations, LO instruction cache, a twisted scheduler, dispatch units, and / or a 64KB register file. Furthermore, the streaming microprocessor can include independent parallel integer and floating-point data paths to leverage the mix of computation and addressing computations for efficient workload execution. The streaming microprocessor can include independent thread scheduling capabilities to enable finer-grained synchronization and cooperation between parallel threads. Streaming microprocessors can include a combination of L1 data cache and shared memory units to improve performance while simplifying programming.

[0204] The GPU 1208 may include High Bandwidth Memory (HBM) and / or a 16GB HBM2 memory subsystem to provide peak memory bandwidth of approximately 900GB / s in some examples. In some examples, synchronous graphics random access memory (SGRAM), such as Graphics Double Data Rate Type 5 Synchronous Random Access Memory (GDDR5), may be used as a supplement to or alternative to HBM memory.

[0205] The GPU 1208 may incorporate unified memory technology, which includes access counters to allow memory pages to be more accurately migrated to the processor that accesses those pages most frequently, thereby improving the efficiency of shared memory ranges between processors. In some examples, Address Translation Service (ATS) support may be used to allow the GPU 1208 to directly access the CPU 1206 page tables. In these examples, when the GPU 1208 Memory Management Unit (MMU) experiences a miss, an address translation request may be issued to the CPU 1206. In response, the CPU 1206 can look up the virtual-to-physical mapping of the address in its page tables and transfer the translation back to the GPU 1208. Thus, unified memory technology can allow a single unified virtual address space to be used for the memory of one or more CPUs 1206 and one or more GPUs 1208, thereby simplifying application programming and porting from one or more GPUs 1208 to one or more GPUs 1208.

[0206] Additionally, the GPU 1208 may include an access counter that tracks the frequency with which the GPU 1208 accesses the memory of other processors. The access counter helps ensure that memory pages are moved to the physical memory of the processor that accesses those pages most frequently.

[0207] One or more SoCs 1204 may include any number of one or more caches 1212, including those described herein. For example, one or more caches 1212 may include an L3 cache that can be used by both one or more CPUs 1206 and one or more GPUs 1208 (e.g., connected to both one or more CPUs 1206 and one or more GPUs 1208). Cache 1212 may include a write-back cache that can track the state of rows, such as by using a cache coherence protocol (e.g., MEI, MESI, MSI, etc.). Depending on the embodiment, the L3 cache may include 4 MB or more, although a smaller cache size may be used.

[0208] One or more SoCs 1204 may include one or more arithmetic logic units (ALUs) that can be utilized in processing of any task or operation (such as processing a DNN) in various tasks or operations related to the vehicle 1200. Furthermore, one or more SoCs 1204 may include one or more floating-point units (FPUs) (or other mathematical coprocessors or digital coprocessor types) for performing mathematical operations within the system. For example, one or more SoCs 1204 may include one or more FPUs integrated into one or more CPUs 1206 and / or one or more GPUs 1208.

[0209] SoC 1204 may include one or more accelerators 1214 (e.g., hardware accelerators, software accelerators, or a combination thereof). For example, one or more SoCs 1204 may include a hardware acceleration cluster that may include optimized hardware accelerators and / or large on-chip memory. Large on-chip memory (e.g., 4MB of SRAM) enables the hardware acceleration cluster to accelerate neural networks and other computations. The hardware acceleration cluster may be used to supplement GPU 1208 and offload some tasks from GPU 1208 (e.g., freeing up more cycles of GPU 1208 to perform other tasks). As an example, one or more accelerators 1214 may be used for target workloads that are sufficiently stable to be easily accelerated (e.g., perceptual, convolutional neural networks (CNNs), etc.). As used herein, the term "CNN" may include all types of CNNs, including region-based or region-specific convolutional neural networks (RCNNs) and fast RCNNs (e.g., for object detection).

[0210] Accelerator 1214 (e.g., a hardware acceleration cluster) may include a Deep Learning Accelerator (DLA). The DLA may include one or more Tensor Processing Units (TPUs) configured to provide an additional 10 trillion operations per second for deep learning applications and inference. The TPU may be an accelerator configured to perform image processing functions (e.g., for CNNs, R-CNNs, etc.) and optimized for performing image processing functions (e.g., for CNNs, R-CNNs, etc.). The DLA may be further optimized for specific neural network types and sets of floating-point operations, as well as inference. The DLA is designed to provide more performance per millimeter than a general-purpose GPU and significantly outperforms the performance of a CPU. The TPU may perform several functions, including single-example convolution functions, support for data types such as INT8, INT16, and FP16 for features and weights, and post-processor functions.

[0211] DLA can quickly and efficiently execute neural networks, especially CNNs, on processed or unprocessed data for any of a variety of functions, including, but not limited to: CNNs for object recognition and detection using data from camera sensors; CNNs for distance estimation using data from camera sensors; CNNs for emergency vehicle detection and recognition using data from microphones; CNNs for facial recognition and vehicle owner identification using data from camera sensors; and / or CNNs for safety and / or safety-related events.

[0212] The DLA can perform any function of the GPU 1208, and by using, for example, an inference accelerator, the designer can target either the DLA or the GPU 1208 for any function. For example, the designer can focus the processing of CNNs and floating-point operations on the DLA, leaving other functions to the GPU 1208 and / or other accelerators 1214.

[0213] Accelerator 1214 (e.g., a hardware acceleration cluster) may include a programmable vision accelerator (PVA), which may alternatively be referred to herein as a computer vision accelerator. The PVA may be designed and configured to accelerate computer vision algorithms for advanced driver assistance systems (ADAS), autonomous driving, and / or augmented reality (AR) and / or virtual reality (VR) applications. The PVA can provide a balance between performance and flexibility. For example, each PVA may include, but is not limited to, any number of reduced instruction set computer (RISC) cores, direct memory access (DMA), and / or any number of vector processors.

[0214] RISC cores can interact with image sensors (e.g., the image sensor of any camera described herein), image signal processors, etc. Each RISC core can include any amount of memory. Depending on the embodiment, the RISC core can use any of a variety of protocols. In some examples, the RISC core can execute a real-time operating system (RTOS). RISC cores can be implemented using one or more integrated circuit devices, application-specific integrated circuits (ASICs), and / or memory devices. For example, a RISC core may include an instruction cache and / or tightly coupled RAM.

[0215] DMA enables PVA components to access system memory independently of the CPU 1206. DMA can support any number of features used to provide optimizations to the PVA, including but not limited to support for multidimensional addressing and / or circular addressing. In some examples, DMA can support up to six or more addressing dimensions, which may include block width, block height, block depth, horizontal block step, vertical block step, and / or depth step.

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

[0217] Each vector processor may include an instruction cache and may be coupled to dedicated memory. Therefore, in some examples, each vector processor may be configured to execute independently of other vector processors. In other examples, vector processors included in a particular PVA may be configured to employ data parallelism. For example, in some embodiments, multiple vector processors included in a single PVA may execute the same computer vision algorithm, but on different regions of an image. In other examples, vector processors included in a particular PVA may execute different computer vision algorithms simultaneously on the same image, or even execute different algorithms on consecutive images or portions of an image. Among other things, any number of PVAs may be included in a hardware-accelerated cluster, and any number of vector processors may be included in each PVA. Additionally, one or more PVAs may include additional error-correcting code (ECC) memory to enhance overall system security.

[0218] Accelerator 1214 (e.g., a hardware acceleration cluster) may include an on-chip computer vision network and SRAM for providing high-bandwidth, low-latency SRAM to accelerator 1214. In some examples, the on-chip memory may include at least 4 MB of SRAM consisting of, for example but not limited to, eight field-configurable memory blocks accessible by both PVA and DLA. Each pair of memory blocks may include an Advanced Peripheral Bus (APB) interface, configuration circuitry, a controller, and a multiplexer. Any type of memory may be used. PVA and DLA may access the memory via a backbone that provides high-speed access to the memory for PVA and DLA. The backbone may include an on-chip computer vision network that interconnects PVA and DLA to the memory (e.g., using an APB).

[0219] Computer vision networks-on-a-chip (COPCs) may include an interface that determines the readiness and validity of both the PVA and DLA before transmitting any control signals / addresses / data. This interface can provide phase and channel reservations for transmitting control signals / addresses / data, as well as burst communication for continuous data transmission. This type of interface may conform to ISO 26262 or IEC 61508 standards, although other standards and protocols may be used.

[0220] In some examples, one or more SoCs 1204 may include a real-time ray tracing hardware accelerator, as described in U.S. Patent Application No. 16 / 101,232, filed August 10, 2018. The real-time ray tracing hardware accelerator can be used to rapidly and efficiently determine the location and extent of an object (e.g., within a world model), generate real-time visualization simulations for RADAR signal interpretation, for sound propagation synthesis and / or analysis, for SONAR system simulation, for general wave propagation simulation, for comparison with LiDAR data for localization and / or other functional purposes, 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.

[0221] Accelerator 1214 (e.g., a hardware accelerator cluster) has a wide array of applications for autonomous driving. PVAs can be programmable vision accelerators that can be used in critical processing stages in ADAS and autonomous vehicles. The capabilities of PVAs are well-matched to algorithmic domains requiring predictable processing at low power and low latency. In other words, PVAs perform well for semi-dense or intensive rule computation, and even for small datasets that require predictable runtimes with low latency and low power. Therefore, in the context of autonomous vehicle platforms, PVAs are designed to run classical computer vision algorithms because they are efficient in object detection and operate on integer mathematics.

[0222] For example, according to one embodiment of this technology, a PVA is used to perform computer stereo vision. In some examples, a semi-global matching-based algorithm may be used, but this is not intended to be limiting. Many applications for Level 3 autonomous driving require in-flight motion estimation / stereo matching (e.g., structures from motion, pedestrian recognition, lane detection, etc.). A PVA can perform computer stereo vision functions on input from two monocular cameras.

[0223] In some examples, PVA can be used to perform dense optical flow. For instance, PVA can be used to process raw RADAR data (e.g., using 4D Fast Fourier Transform) to provide a processed RADAR signal before the next RADAR pulse is emitted. In other examples, PVA is used for time-of-flight depth processing, such as by processing raw time-of-flight data to provide processed time-of-flight data.

[0224] DLA can be used to run any type of network to enhance control and driving safety, including, for example, neural networks that output a confidence measure for each object detection. This confidence value can be interpreted as a probability or as providing a relative “weight” for each detection compared to other detections. This confidence value allows the system to make further decisions about which detections should be considered true positives rather than false positives. For example, the system can set a confidence threshold and only consider detections exceeding the threshold as true positives. In an Automatic Emergency Braking (AEB) system, false positives would cause the vehicle to automatically perform emergency braking, which is clearly undesirable. Therefore, only the most confident detection should be considered a trigger for AEB. DLA can run neural networks to regress the confidence value. The neural network can take at least some subset of parameters such as bounding box dimensions as its input, ground plane estimation (e.g., obtained from another subsystem), output of inertial measurement unit (IMU) sensor 1266 related to the orientation of vehicle 1200, distance, 3D position estimation of objects obtained from the neural network and / or other sensors (e.g., LiDAR sensor 1264 or RADAR sensor 1260), among others.

[0225] One or more SoCs 1204 may include one or more data storage units 1216 (e.g., memory). The one or more data storage units 1216 may be on-chip memory of one or more SoCs 1204, which may store neural networks to be executed on the GPU and / or DLA. In some examples, the capacity of the one or more data storage units 1216 may be large enough to store multiple examples of the neural network for redundancy and security. The data storage units 1216 may include L2 or L3 cache memory 1212. References to the data storage units 1216 may include references to memories associated with the PVA, DLA, and / or other accelerators 1214, as described herein.

[0226] SoC 1204 may include one or more processors 1210 (e.g., embedded processors). Processor 1210 may include a boot and power management processor, which may be a dedicated processor and subsystem for handling boot power and management functions and related safety implementations. The boot and power management processor may be part of the SoC 1204 boot sequence and may provide runtime power management services. The boot power and management processor may provide clock and voltage programming, assistance with system low-power state transitions, management of SoC 1204 thermal and temperature sensors, and / or management of SoC 1204 power states. Each temperature sensor may be implemented as a ring oscillator whose output frequency is proportional to temperature, and SoC 1204 may use the ring oscillator to detect the temperature of CPU 1206, GPU 1208, and / or accelerator 1214. If it is determined that the temperature exceeds a threshold, the boot and power management processor may enter a temperature fault routine and place SoC 1204 into a lower power state and / or place vehicle 1200 into a queued-to-safe-stop mode (e.g., safely stop vehicle 1200).

[0227] The processor 1210 may further include a set of embedded processors that can be used 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 of a digital signal processor with dedicated RAM.

[0228] The processor 1210 may further include an always-on processor engine, which provides the necessary hardware features to support low-power sensor management and wake-up usage. The always-on processor engine may include a processor core, tightly coupled RAM, support for peripherals (e.g., timers and interrupt controllers), various I / O controller peripherals, and routing logic.

[0229] The processor 1210 may further include a secure cluster engine, which includes a dedicated processor subsystem for handling security management for automotive applications. The secure cluster engine may include two or more processor cores, tightly coupled RAM, support for peripheral devices (e.g., timers, interrupt controllers, etc.), and / or routing logic. In secure mode, the two or more cores may operate in lockstep mode and act as a single core with comparison logic to detect any differences between their operations.

[0230] The processor 1210 may further include a real-time camera engine, which may include a dedicated processor subsystem for handling real-time camera management.

[0231] The processor 1210 may further include a high dynamic range signal processor, which may include an image signal processor of a hardware engine as part of the camera processing pipeline.

[0232] Processor 1210 may include a video image synthesizer, which may be a processing block (e.g., implemented on a microprocessor) that implements the video post-processing functions required for video playback applications to produce the final image of the player window. The video image synthesizer may perform lens distortion correction on the wide-angle camera 1270, the surrounding camera 1274, and / or the in-cabin surveillance camera sensor. The in-cabin surveillance camera sensor is preferably monitored by a neural network running on another example of an advanced SoC, configured to recognize in-cabin events and respond accordingly. The in-cabin system may perform lip readings to activate cellular service and initiate phone calls, instruct emails, change the vehicle's destination, activate or change the vehicle's infotainment system and settings, or provide voice-activated web browsing. Some functions are only available to the driver when the vehicle is operating in autonomous mode; otherwise, they are disabled.

[0233] Video image synthesizers may include enhanced temporal noise reduction for both spatial and temporal noise reduction. For example, in the case of motion in the video, noise reduction appropriately weights spatial information, thereby reducing the weight of information provided by adjacent frames. In cases where the image or part of the image does not contain motion, temporal noise reduction performed by the video image synthesizer can use information from previous images to reduce noise in the current image.

[0234] The video image compositor can also be configured to perform stereoscopic correction on the input stereo lens frames. The video image compositor can further be used for user interface compositing during operating system desktop use, without requiring the GPU 1208 to continuously reproduce new surfaces. Even when the GPU 1208 is powered on and actively performing 3D rendering, the video image compositor can be used to offload the GPU 1208 to improve performance and responsiveness.

[0235] One or more SoCs 1204 may further include a Mobile Industry Processor Interface (MIPI) camera serial interface, a high-speed interface, and / or a video input block that can be used for camera and associated pixel input functions for receiving video and input from a camera. SoC 1204 may also include an input / output controller, which may be software-controlled and can be used to receive I / O signals not assigned to a specific role.

[0236] One or more SoCs 1204 may further include a wide variety of peripheral interfaces to enable communication with peripheral devices, audio codecs, power management, and / or other devices. SoC 1204 can be used to process data from cameras (e.g., via gigabit multimedia serial links and Ethernet connections), sensors (e.g., LIDAR sensor 1264, RADAR sensor 1260, etc., which can be connected via Ethernet), data from bus 1202 (e.g., vehicle 1200 speed, steering wheel position, etc.), and data from GNSS sensor 1258 (e.g., connected via Ethernet or CAN bus). SoC 1204 may also include a dedicated high-performance mass storage controller, which may include its own DMA engine and can be used to free CPU 1206 from routine data management tasks.

[0237] The SoC 1204 can be an end-to-end platform with a flexible architecture spanning Automation Level 35, thereby providing a comprehensive functional safety architecture that fully and effectively leverages computer vision and ADAS technologies for versatility and redundancy, providing a platform for a flexible, reliable driver software stack and deep learning tools. The SoC 1204 can be faster, more reliable, and even more energy-efficient and space-efficient than conventional systems. For example, one or more accelerators 1214, when combined with one or more CPUs 1206, one or more GPUs 1208, and one or more data storage devices 1216, can provide a fast and efficient platform for Level 3–5 autonomous vehicles.

[0238] Therefore, this technology provides capabilities and functionality that conventional systems cannot achieve. For example, computer vision algorithms can be executed on a CPU, which can be configured using a high-level programming language (such as C) to execute a wide variety of processing algorithms across a broad range of visual data. However, CPUs often cannot meet the performance requirements of many computer vision applications, such as those related to execution time and power consumption. In particular, many CPUs cannot execute complex object detection algorithms in real time, which is a requirement in vehicle ADAS applications and for practical Level 3-5 autonomous vehicles.

[0239] In contrast to conventional systems, the techniques described herein, by providing CPU complexes, GPU complexes, and hardware-accelerated clusters, allow multiple neural networks to be executed simultaneously and / or sequentially, and allow the results to be combined to achieve Level 3 autonomous driving capabilities. For example, a CNN executed on a DLA or dGPU (e.g., one or more GPU 1220s) can include text and word recognition, allowing the supercomputer to read and understand traffic signs, including signs for which the neural network has not yet been specifically trained. The DLA can further include a neural network capable of recognizing, interpreting, and providing semantic understanding of the signs, and passing that semantic understanding to a path planning module running on the CPU complex.

[0240] As another example, multiple neural networks can run simultaneously, as required by Level 3, 4, or 5 driving. For instance, a warning sign consisting of "Warning: Flashing lights indicate icing conditions," along with lights, can be interpreted independently or jointly by several neural networks. The sign itself can be identified as a traffic sign by a first deployed neural network (e.g., a trained neural network), and the text "Flashing lights indicate icing conditions" can be interpreted by a second deployed neural network, which informs the vehicle's routing software (preferably executing on a CPU complex) when the flashing lights are detected, indicating the presence of icing conditions. The flashing lights can be identified by a third deployed neural network operating across multiple frames, informing the vehicle's routing software of the presence (or absence) of the flashing lights. All three neural networks can run simultaneously, such as within a DLA and / or on a GPU 1208.

[0241] In some examples, the CNN used for facial recognition and vehicle owner identification can use data from camera sensors to identify the presence of an authorized driver and / or the owner of vehicle 1200. A constant-current sensor processing engine can be used to unlock the vehicle and turn on the lights when the owner approaches the driver's door, and in security mode, to disable the vehicle when the owner leaves. In this way, one or more SoCs 1204 provide security against theft and / or hijacking.

[0242] In another example, the CNN used for emergency vehicle detection and identification can use data from microphone 1296 to detect and identify emergency vehicle sirens. In contrast to conventional systems that use a general classifier to detect sirens and manually extract features, one or more SoCs 1204 use the CNN to classify environmental and urban sounds, as well as visual data. In a preferred embodiment, the CNN running on the DLA is trained to recognize the relative shut-off speed of emergency vehicles (e.g., by using the Doppler effect). The CNN can also be trained to identify emergency vehicles specific to the localized area where the vehicle is operating, such as those identified by GNSS sensor 1258. Thus, for example, when operating in Europe, the CNN will seek to detect European sirens, while when operating in the United States, the CNN will seek to identify only North American sirens. Once an emergency vehicle is detected, control procedures can be used, with the assistance of ultrasonic sensor 1262, to execute emergency vehicle safety routines, slow the vehicle, pull it to the roadside, stop the vehicle, and / or allow the vehicle to idle until the emergency vehicle passes.

[0243] The vehicle may include one or more CPUs 1218 (e.g., one or more discrete CPUs, or one or more dCPUs), which may be coupled to one or more SoCs 1204 via high-speed interconnects (e.g., PCIe). The CPU 1218 may include, for example, an x86 processor. The CPU 1218 may be used to perform any of a variety of functions, including, for example, arbitrating the results of potential inconsistencies between ADAS sensors and SoC 1204, and / or monitoring the status and health of controller 1236 and / or infotainment SoC 1230.

[0244] Vehicle 1200 may include one or more GPUs 1220 (e.g., one or more discrete GPUs or one or more dGPUs) that can be coupled to one or more SoCs 1204 via a high-speed interconnect (e.g., NVIDIA's NVLINK). GPUs 1220 may provide additional artificial intelligence capabilities, such as by executing redundant and / or different neural networks, and may be used to train and / or update neural networks based on inputs from sensors of vehicle 1200 (e.g., sensor data).

[0245] Vehicle 1200 may further include a 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 cellular antennas, Bluetooth antennas, etc.). Network interface 1224 can be used to enable wireless connectivity over the Internet to the cloud (e.g., to server 1278 and / or other network devices), to other vehicles, and / or to computing devices (e.g., a passenger's client device). For communication with other vehicles, a direct link and / or an indirect link (e.g., across a network and over the Internet) can be established between the two vehicles. A vehicle-to-vehicle communication link can be used to provide a direct link. A vehicle-to-vehicle communication link can provide vehicle 1200 with information about vehicles near vehicle 1200 (e.g., vehicles in front, to the side, and / or behind vehicle 1200). This functionality may be part of vehicle 1200's cooperative adaptive cruise control function.

[0246] Network interface 1224 may include a SoC that provides modulation and demodulation functions and enables controller 1236 to communicate via a wireless network. Network interface 1224 may include an RF front-end for up-conversion from baseband to RF and down-conversion from RF to baseband. Frequency conversion may be performed using well-known processes and / or using superheterodyne processes. In some examples, the RF front-end functionality 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.

[0247] Vehicle 1200 may further include data storage 1228, which may include off-chip (e.g., outside of SoC 1204) storage. Data storage 1228 may include one or more storage elements, including RAM, SRAM, DRAM, VRAM, flash memory, hard disk, and / or other components and / or devices capable of storing at least one data bit.

[0248] Vehicle 1200 may further include GNSS sensors 1258 (e.g., GPS and / or auxiliary GPS sensors) to aid in mapping, sensing, occupancy grid generation, and / or path planning functions. Any number of GNSS sensors 1258 may be used, including, for example, but not limited to, GPS sensors using a USB connector with an Ethernet-to-serial (RS 232) bridge.

[0249] Vehicle 1200 may also include a RADAR sensor 1260. Vehicle 1200 can use the RADAR sensor 1260 for long-range vehicle detection, even in dark and / or inclement weather conditions. The RADAR functional safety level can be ASIL B. In some examples, one or more RADAR sensors 1260 can use CAN and / or bus 1202 (e.g., to transmit data generated by one or more RADAR sensors 1260) to control and access object tracking data, with Ethernet access for raw data. A wide variety of RADAR sensor types can be used. For example, but not limited to, one or more RADAR sensors 1260 can be adapted for front, rear, and side use with RADAR. In some examples, a pulse Doppler RADAR sensor is used.

[0250] The RADAR sensor 1260 can include different configurations, such as a long-range RADAR with a narrow field of view, a short-range RADAR with a wide field of view, a short-range side coverage, etc. In some examples, the remote-away RADAR can be used for adaptive cruise control functions. The remote-away RADAR system can provide a wide field of view, such as within 250m, achieved by two or more independent scans. The RADAR sensor 1260 can help distinguish between stationary and moving objects and can be used by ADAS systems for emergency braking assist and forward collision warning. The remote-away RADAR sensor can include a single-site multi-mode RADAR with multiple (e.g., six or more) fixed RADAR antennas and high-speed CAN and FlexRay interfaces. In an example with six antennas, the four central antennas can create a focused beam pattern designed to record the area around vehicle 1200 at a higher speed with minimal interference from traffic from adjacent lanes. The other two antennas extend the field of view, enabling rapid detection of vehicles entering or leaving the lane of vehicle 1200.

[0251] As an example, a mid-range RADAR system may include a range of up to 1260m (front) or 80m (rear) and a field of view of up to 42 degrees (front) or 1250 degrees (rear). A short-range RADAR system may include, but is not limited to, RADAR sensors designed to be mounted at both ends of the rear bumper. When mounted at both ends of the rear bumper, such a RADAR sensor system can generate two beams that continuously monitor blind spots behind and beside the vehicle.

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

[0253] Vehicle 1200 may further include ultrasonic sensors 1262. Ultrasonic sensors 1262, which can be located at the front, rear, and / or sides of vehicle 1200, can be used for parking assistance and / or creating and updating occupancy grids. Various ultrasonic sensors 1262 can be used, and different ultrasonic sensors 1262 can be used for different detection ranges (e.g., 2.5m, 4m). Ultrasonic sensors 1262 operate at the ASILB functional safety level.

[0254] Vehicle 1200 may include a LIDAR sensor 1264. The LIDAR sensor 1264 may be used for object and pedestrian detection, emergency braking, collision avoidance, and / or other functions. One or more LIDAR sensors 1264 may be at functional safety level ASIL B. In some examples, vehicle 1200 may include multiple LIDAR sensors 1264 (e.g., two, four, six, etc.) that can use Ethernet (e.g., to provide data to a gigabit Ethernet switch).

[0255] In some examples, one or more LiDAR sensors 1264 may be able to provide a list of objects and their distances for a 360-degree field of view. Commercially available LiDAR sensors 1264 may have an advertising range of approximately 100m, an accuracy of 2cm-3cm, and support, for example, a 100Mbps Ethernet connection. In some examples, one or more non-protruding LiDAR sensors 1264 may be used. In such examples, one or more LiDAR sensors 1264 may be implemented as small devices that can be embedded in the front, rear, sides, and / or corners of the vehicle 1200. In such examples, one or more LiDAR sensors 1264 may provide a horizontal field of view of up to 120 degrees and a vertical field of view of 35 degrees, even with a range of 200m for low-reflectivity objects. One or more front-mounted LiDAR sensors 1264 may be configured for a horizontal field of view between 45 degrees and 135 degrees.

[0256] In some examples, LiDAR technology such as 3D flash LiDAR can also be used. 3D flash LiDAR uses a laser flash as a transmission source to illuminate the environment around the vehicle up to approximately 200m. A flash LiDAR unit includes a receiver that records the laser pulse transit time and reflected light at each pixel, each pixel corresponding to the distance from the vehicle to the object. Flash LiDAR allows for the generation of highly accurate and distortion-free images of the surrounding environment using each laser flash. In some examples, four flash LiDAR sensors can be deployed, one on each side of the vehicle. Available 3D flash LiDAR systems include solid-state 3D start-up array LiDAR cameras (e.g., non-scanning LiDAR devices) with no moving parts other than a fan. Flash LiDAR devices can use five nanosecond Class I (eye-safe) laser pulses per frame and can capture reflected laser light in the form of a 3D-range point cloud and co-registered intensity data. By using flash LiDAR, and because flash LiDAR is a solid-state device without moving parts, one or more LiDAR sensors 1264 may be less susceptible to motion blur, vibration and / or shock.

[0257] The vehicle may further include IMU sensor 1266. In some examples, one or more IMU sensors 1266 may be located at the center of the rear axle of the vehicle 1200. IMU sensor 1266 may include, for example, but not limited to, accelerometers, magnetometers, gyroscopes, magnetic compasses, and / or other sensor types. In some examples, such as in a six-axis application, IMU sensor 1266 may include accelerometers and gyroscopes, while in a nine-axis application, IMU sensor 1266 may include accelerometers, gyroscopes, and magnetometers.

[0258] In some embodiments, one or more IMU sensors 1266 may be implemented as a miniature, high-performance GPS-assisted inertial navigation system (GPS / INS) that combines a microelectromechanical system (MEMS) inertial sensor, a high-sensitivity GPS receiver, and an advanced Kalman filtering algorithm to provide estimates of position, velocity, and attitude. Thus, in some examples, one or more IMU sensors 1266 can enable vehicle 1200 to estimate heading without input from a magnetic sensor by directly observing and correlating velocity changes from GPS to one or more IMU sensors 1266. In some examples, IMU sensors 1266 and GNSS sensors 1258 may be combined in a single integrated unit.

[0259] The vehicle may include a microphone 1296 placed inside and / or around the vehicle 1200. The microphone 1296 may be used for emergency vehicle detection and identification, etc.

[0260] The vehicle may further include any number of camera types, including stereo camera 1268, wide-angle camera 1270, infrared camera 1272, surround camera 1274, long-range and / or mid-range camera 1298, and / or other camera types. The cameras can be used to capture image data of the entire perimeter of the vehicle 1200. The type of camera used depends on the implementation and requirements of the vehicle 1200, and any combination of camera types can be used to provide the necessary coverage around the vehicle 1200. Additionally, the number of cameras may vary depending on the embodiment. For example, the vehicle may include six cameras, seven cameras, ten cameras, twelve cameras, and / or another number of cameras. By way of example and not limitation, the cameras may support Gigabit Multimedia Serial Link (GMSL) and / or Gigabit Ethernet. Figure 12 and Figure 13 To describe each element in the camera in more detail.

[0261] Vehicle 1200 may further include vibration sensor 1242. Vibration sensor 1242 can measure vibrations of vehicle components, such as axles. For example, changes in vibration can indicate changes in road surface. In another example, when two or more vibration sensors 1242 are used, the difference between vibrations can be used to determine friction or slippage of the road surface (e.g., when the vibration difference is between a driven shaft and a freely rotating shaft).

[0262] Vehicle 1200 may include ADAS system 1238. In some examples, ADAS system 1238 may include SoC. ADAS system 1238 may include autonomous / adaptive / automatic cruise control (ACC), cooperative adaptive cruise control (CACC), forward collision warning (FCW), automatic emergency braking (AEB), lane departure warning (LDW), lane keeping assist (LKA), blind spot warning (BSW), rear cross traffic warning (RCTW), collision warning system (CWS), lane centering (LC) and / or other features and functions.

[0263] The ACC system can use a RADAR sensor 1260, a LIDAR sensor 1264, and / or a camera. The ACC system may include longitudinal ACC and / or lateral ACC. Longitudinal ACC monitors and controls the distance to vehicles directly in front of vehicle 1200 and automatically adjusts the vehicle speed to maintain a safe distance. Lateral ACC performs distance holding and notifies vehicle 1200 to change lanes when necessary. Lateral ACC is relevant to other ADAS applications such as LC and CWS.

[0264] CACC uses information from other vehicles that can be received via network interface 1224 and / or wireless antenna 1226 from other vehicles via a wireless link or indirectly via a network connection (e.g., via the Internet). The direct link can be provided by a vehicle-to-vehicle (V2V) communication link, while the indirect link can be an infrastructure-to-vehicle (I2V) communication link. Typically, the V2V communication concept provides information about vehicles immediately ahead (e.g., vehicles immediately in front of vehicle 1200 and in the same lane as vehicle 1200), while the I2V communication concept provides information about traffic further ahead. A CACC system may include either or both of these I2V and V2V information sources. Given information about vehicles ahead of vehicle 1200, CACC can be more reliable, and it has the potential to improve traffic flow smoothness and reduce congestion on the road.

[0265] The FCW system is designed to warn the driver of danger, enabling the driver to take corrective action. The FCW system uses a front-facing camera and / or RADAR sensor 1260 coupled to a dedicated processor, DSP, FPGA, and / or ASIC, which is electrically coupled to driver feedback, such as a display, speaker, and / or vibration components. The FCW system can provide warnings, such as in the form of audible, visual, haptic, and / or rapid braking pulses.

[0266] The AEB system detects an impending forward collision with another vehicle or other object and can automatically apply the brakes if the driver does not take corrective action within a specified time or distance parameter. The AEB system may use a front-facing camera and / or RADAR sensor 1260 coupled to a dedicated processor, DSP, FPGA, and / or ASIC. When the AEB system detects a hazard, it typically first warns the driver to take corrective action to avoid a collision, and if the driver does not take corrective action, the AEB system may automatically apply the brakes to attempt to prevent or at least mitigate the effects of the predicted collision. The AEB system may include technologies such as dynamic brake support and / or impending collision braking.

[0267] The Lane Departure Warning (LDW) system provides visual, auditory, and / or tactile warnings, such as steering wheel or seat vibrations, to alert the driver when the vehicle crosses a lane marking at 1200 degrees. The LDW system does not activate when the driver indicates intentional lane departure by activating the turn signal. The LDW system may use a front-facing camera coupled to a dedicated processor, DSP, FPGA, and / or ASIC, electrically coupled to actuator feedback, such as a display, speaker, and / or vibration assembly.

[0268] The LKA system is a variant of the LDW system. If the vehicle 1200 begins to leave the lane, the LKA system provides steering input or braking to correct the vehicle 1200.

[0269] The BSW system detects and warns the driver of vehicles in the vehicle's blind spot. The BSW system can provide visual, auditory, and / or tactile alerts to indicate that merging or changing lanes is unsafe. The system can provide additional warnings when the driver uses turn signals. The BSW system may use a rear-facing camera and / or RADAR sensor 1260 coupled to a dedicated processor, DSP, FPGA, and / or ASIC, electrically coupled to driver feedback such as a display, speaker, and / or vibration components.

[0270] When the vehicle 1200 is reversing and detects an object outside the range of the rear-view camera, the RCTW system can provide visual, auditory, and / or tactile notifications. Some RCTW systems include AEB to ensure the application of the vehicle's brakes to avoid a collision. The RCTW system may use one or more rear-view RADAR sensors 1260 coupled to a dedicated processor, DSP, FPGA, and / or ASIC, which are electrically coupled to driver feedback, such as displays, speakers, and / or vibration components.

[0271] Conventional ADAS systems can be prone to false positives, which can be annoying and distracting for the driver, but usually not catastrophic, as the ADAS system warns the driver and allows the driver to determine whether a safe situation truly exists and act accordingly. However, in the autonomous vehicle 1200, in the event of conflicting results, the vehicle 1200 itself must determine whether the result is obtained from the main computer or from a secondary computer (e.g., the first controller 1236 or the second controller 1236). For example, in some embodiments, the ADAS system 1238 may be a backup and / or auxiliary computer for providing perception information to a backup computer rationalization module. The backup computer rationalization monitor may run redundant and diverse software on hardware components to detect faults in perception and dynamic driving tasks. The output of the ADAS system 1238 may be provided to a supervisory MCU. If the outputs from the main computer and the auxiliary computer conflict, the supervisory MCU must determine how to reconcile the conflict to ensure safe operation.

[0272] In some examples, the master computer can be configured to provide a confidence score to the supervisory MCU, indicating the master computer's confidence in the selected outcome. If the confidence score exceeds a threshold, the supervisory MCU can follow the master computer's direction regardless of whether the assistant computer provides conflicting or inconsistent results. When the confidence score does not meet the threshold, and when the master and assistant computers indicate different results (e.g., conflict), the supervisory MCU can arbitrate between the computers to determine the appropriate result.

[0273] The supervisory MCU can be configured to run a neural network trained and configured to determine the conditions under which the secondary computer provides a false alarm based on outputs from both the main and secondary computers. Thus, one or more neural networks in the supervisory MCU can learn when the output of the secondary computer can be trusted and when it cannot. For example, when the secondary computer is a RADAR-based FCW system, one or more neural networks in the supervisory MCU can learn when the FCW system recognizes a metallic object that is not actually dangerous, such as a drain grate or manhole cover that triggers an alarm. Similarly, when the secondary computer is a camera-based LDW system, the neural network in the supervisory MCU can learn to overtake the LDW when a cyclist or pedestrian is present and lane departure is actually the safest maneuver. In embodiments that include a neural network running on the supervisory MCU, the supervisory MCU may include at least one of a DLA or GPU adapted to run a neural network with associated memory. In a preferred embodiment, the supervisory MCU may include and / or include components for a SoC 1204.

[0274] In other examples, ADAS system 1238 may include a secondary computer that performs ADAS functionality using conventional rules of computer vision. Accordingly, the secondary computer can use classical computer vision rules (if so), and the presence of a neural network in the supervisory MCU improves reliability, safety, and performance. For example, different implementations and intentional non-identification make the entire system more fault-tolerant, especially to failures caused by software (or software-hardware interface) functionality. For instance, if a software error or bug exists in the software running on the primary computer, and different software code running on the secondary computer provides the same overall result, the supervisory MCU can have greater confidence that the overall result is correct and that the error in the software or hardware used by the primary computer does not cause material errors.

[0275] In some examples, the output of ADAS system 1238 may be fed into the perception block and / or the dynamic drive task block of the host computer. For example, if ADAS system 1238 indicates a forward collision warning due to an object directly in front, the perception block may use this information when identifying the object. In other examples, the secondary computer may have its own trained neural network, and thus reduce the risk of false alarms, as described herein.

[0276] Vehicle 1200 may further include an infotainment SoC 1230 (e.g., an in-vehicle infotainment system (IVI)). Although shown and described as an SoC, the infotainment system may not be an SoC and may include two or more discrete components. The infotainment SoC 1230 may include a combination of hardware and software that can be used to provide audio (e.g., music, personal digital assistant, navigation instructions, news, radio, etc.), video (e.g., TV, movies, streaming, etc.), telephone (e.g., hands-free calling), network connectivity (e.g., LTE, Wi-Fi, etc.), and / or information services to vehicle 1200 (e.g., navigation system, rear parking assist, radio data system, vehicle-related information such as fuel level, total driving distance, brake fuel level, oil level, door opening / closing, air filter information, etc.). For example, the infotainment SoC 1230 may include a radio, disk player, navigation system, video player, USB and Bluetooth connectivity, automotive entertainment, Wi-Fi, steering wheel audio controls, hands-free voice control, head-up display (HUD), HMI display 1234, telematics device, control panel (e.g., for controlling various components, features and / or systems and / or interacting with various components, features and / or systems), and / or other components. The infotainment SoC 1230 may further be used to provide information to vehicle users (e.g., visual and / or auditory), such as information from ADAS system 1238, autonomous driving information (e.g., planned vehicle handling, trajectory), surrounding environment information (e.g., intersection information, vehicle information, road information, etc.), and / or other information.

[0277] The infotainment SoC 1230 may include GPU functionality. The infotainment SoC 1230 can communicate with other devices, systems, and / or components of the vehicle 1200 via bus 1202 (e.g., CAN bus, Ethernet, etc.). In some examples, the infotainment SoC 1230 may be coupled to a supervisory MCU, allowing the GPU of the infotainment system to perform self-driving functions in the event of a failure of this or these main controllers 1236 (e.g., the primary and / or backup computer of the vehicle 1200). In such an example, the infotainment SoC 1230 may place the vehicle 1200 into a queued-to-safe-stop mode, as described herein.

[0278] Vehicle 1200 may further include instrument panel 1232 (e.g., digital instrument panel, electronic instrument panel, etc.). Instrument panel 1232 may include a controller and / or supercomputer (e.g., a discrete controller or supercomputer). Instrument panel 1232 may include a set of instruments such as speedometer, fuel level, oil pressure, tachometer, odometer, steering indicator, shift position indicator, one or more seatbelt warning lights, one or more parking brake warning lights, one or more engine malfunction lights, airbag (SRS) system information, lighting control, safety system control, navigation information, etc. In some examples, information may be displayed and / or shared between infotainment SoC 1230 and instrument panel 1232. In other words, instrument panel 1232 may be included as part of infotainment SoC 1230, or vice versa.

[0279] As mentioned above, in at least some embodiments, the vehicle platform 100 (see...) Figure 1 The controller 1236 may be a component of the autonomous vehicle 1200. In such an embodiment, one or more controllers 1236 include an automotive SoC 104. For example, the automotive SoC 104 may be implemented as one of the SoCs 1204.

[0280] Figure 15 This is based on some embodiments of the present disclosure for use in cloud-based servers and Figure 12 The following is a system diagram illustrating communication between example autonomous vehicles 1200. System 1276 may include one or more servers 1278, one or more networks 1290, and vehicles including vehicle 1200. Server 1278 may include multiple GPUs 1284(A)-1284(H) (collectively referred to herein as GPU 1284), PCIe switches 1282(A)-1282(H) (collectively referred to herein as PCIe switch 1282), and / or CPUs 1280(A)-1280(B) (collectively referred to herein as CPU 1280). GPU 1284, CPU 1280, and PCIe switches may be interconnected using high-speed interconnects (e.g., but not limited to NVLink interface 1288 and / or PCIe connection 1286 developed by NVIDIA). In some examples, GPU 1284 is connected via NVLink and / or NV Switch SoC, and GPU 1284 and PCIe switch 1282 are connected via PCIe interconnect. Although eight GPUs 1284, two CPUs 1280, and two PCIe switches are shown, this is not intended to be limiting. Depending on the embodiment, each of one or more servers 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.

[0281] One or more servers 1278 may receive image data from vehicles via one or more networks 1290, representing images showing unexpected or changed road conditions (e.g., recently started roadwork). One or more servers 1278 may transmit neural network 1292, updated neural network 1292, and / or map information 1294, including information about traffic and road conditions, to vehicles via one or more networks 1290. Updates to map information 1294 may include updates to HD mapping 1222, such as information about construction sites, potholes, detours, floods, and / or other obstacles. In some examples, neural network 1292, updated neural network 1292, and / or map information 1294 may have been generated from new training and / or experience represented in data received from any number of vehicles in the environment and / or based on training performed at a data center (e.g., using one or more servers 1278 and / or other servers).

[0282] One or more servers 1278 can be used to train machine learning models (e.g., neural networks) based on training data. Training data can be generated by the vehicle and / or generated in a simulation (e.g., using a game engine). In some examples, the training data is labeled (e.g., where the neural network benefits from supervised learning) and / or undergoes other preprocessing, while in other examples, the training data is not labeled and / or preprocessed (e.g., where the neural network does not require supervised learning). Training can be performed according to any one or more categories of machine learning techniques, including but not limited to: supervised training, semi-supervised training, unsupervised training, self-learning, reinforcement learning, joint learning, transfer learning, feature learning (including principal component and cluster analysis), multilinear subspace learning, manifold learning, representation learning (including alternative dictionary learning), rule-based machine learning, anomaly detection, and any variations or combinations thereof. Once the machine learning model is trained, it can be used by the vehicle (e.g., transmitted to the vehicle via network 1290) and / or by the server 1278 to remotely monitor the vehicle.

[0283] In some examples, one or more servers 1278 may receive data from the vehicle and apply the data to state-of-the-art real-time neural networks for real-time intelligent inference. One or more servers 1278 may contain a deep learning supercomputer powered by a GPU 1284 and / or a dedicated AI computer, such as the DGX and DGX Station machines developed by NVIDIA. However, in some examples, one or more servers 1278 may contain a deep learning infrastructure using only a CPU-powered data center.

[0284] The deep learning infrastructure of one or more servers 1278 can be rapidly and in real-time inferred, and can be used to assess and verify the health of the processors, software, and / or associated hardware in vehicle 1200. For example, the deep learning infrastructure may receive periodic updates from vehicle 1200, such as image sequences and / or objects in which vehicle 1200 is located (e.g., via computer vision and / or other machine learning object classification techniques). The deep learning infrastructure can run its own neural network to identify objects and compare them with objects identified by vehicle 1200. If the results do not match and the infrastructure infers that the AI ​​in vehicle 1200 has malfunctioned, one or more servers 1278 may transmit signals to vehicle 1200 instructing its fail-safe computer to take control, notify passengers, and complete a safe parking operation.

[0285] For inference, one or more servers 1278 may include one or more GPUs 1284 and one or more programmable inference accelerators (e.g., NVIDIA's TensorRT). The combination of GPU-powered servers and inference acceleration can enable real-time response. In other examples, such as in less performance-critical scenarios, servers powered by CPUs, FPGAs, and other processors can be used for inference.

[0286] Example computing device

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

[0288] although Figure 16 The various boxes are shown as being connected to lines via interconnect system 1602, but this is not intended to be limiting and is merely for clarity. For example, in some embodiments, presentation component 1618 (such as a display device) may be considered I / O component 1614 (e.g., if the display is a touchscreen). As another example, CPU 1606 and / or GPU 1608 may include memory (e.g., memory 1604 may represent a storage device other than the memory of GPU 1608, CPU 1606, and / or other components). In other words, Figure 16The computing devices described are for illustrative purposes only. No distinction is made between such categories as “workstation,” “server,” “laptop computer,” “desktop computer,” “tablet computer,” “client device,” “mobile device,” “handheld device,” “game console,” “electronic control unit (ECU),” “virtual reality system,” “augmented reality system,” and / or other device or system types, as all categories are considered within the same context. Figure 16 Within the scope of the computing device.

[0289] Interconnect system 1602 may represent one or more links or buses, such as address buses, data buses, control buses, or combinations thereof. Interconnect system 1602 may include one or more bus or link types, such as Industry Standard Architecture (ISA) bus, Extended Industry Standard Architecture (EISA) bus, Video Electronics Standards Association (VESA) bus, Peripheral Component Interconnect (PCI) bus, Fast Peripheral Component Interconnect (PCIe) bus, and / or another type of bus or link. In some embodiments, there is a direct connection between components. As an example, CPU 1606 may be directly connected to memory 1604. Further, CPU 1606 may be directly connected to GPU 1608. In cases where there is a direct or point-to-point connection between components, interconnect system 1602 may include a PCIe link for performing the connection. In these examples, a PCI bus is not required to be included in computing device 1600.

[0290] The memory 1604 may comprise any of a variety of computer-readable media. Computer-readable media can be any available medium accessible by the computing device 1600. Computer-readable media can include volatile and non-volatile media, as well as removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media.

[0291] Computer storage media may include volatile and non-volatile media and / or removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, and / or other data types. For example, memory 1604 may store computer-readable instructions (e.g., representing one or more programs and / or one or more program elements, such as an operating system). Computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, Digital Universal Disc (DVD) or other optical disc storage, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by computing device 1600. As used herein, computer storage media does not include the signal itself.

[0292] Computer storage media may embody computer-readable instructions, data structures, program modules, and / or other data types in modulated data signals such as carrier waves or other transmission mechanisms, and include any information delivery medium. The term "modulated data signal" may refer to a signal whose one or more characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, computer storage media may include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, RF, infrared, and other wireless media). Any combination of the above should also be included within the scope of computer-readable media.

[0293] One or more CPUs 1606 may be configured to execute at least some of computer-readable instructions to control one or more components of computing device 1600 to perform one or more of the methods and / or processes described herein. Each of the one or more CPUs 1606 may include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of processing multiple software threads simultaneously. The one or more CPUs 1606 may comprise any type of processor and may include different types of processors depending on the type of computing device 1600 implemented (e.g., processors with fewer cores for mobile devices and processors with more cores for servers). For example, depending on the type of computing device 1600, the processor may be an advanced RISC machine (ARM) processor implemented using Reduced Instruction Set Computing (RISC) or an x86 processor implemented using Complex Instruction Set Computing (CISC). In addition to one or more microprocessors or supplementary coprocessors (such as math coprocessors), computing device 1600 may include one or more CPUs 1606.

[0294] In addition to or in lieu of one or more CPUs 1606, one or more GPUs 1608 may be configured to execute at least some of computer-readable instructions to control one or more components of computing device 1600 to perform one or more of the methods and / or processes described herein. One or more GPUs 1608 may be integrated GPUs (e.g., with one or more CPUs 1606 and / or one or more GPUs 1608 may be discrete GPUs). In embodiments, one or more GPUs 1608 may be coprocessors of one or more CPUs 1606. One or more GPUs 1608 may be used by computing device 1600 to reproduce graphics (e.g., 3D graphics) or perform general-purpose computing. For example, one or more GPUs 1608 may be used for general-purpose computing on GPUs (GPGPU). One or more GPUs 1608 may include hundreds or thousands of cores capable of processing hundreds or thousands of software threads simultaneously. One or more GPUs 1608 may generate pixel data for an output image in response to a playback command (e.g., a playback command received from one or more CPUs 1606 via a host interface). One or more GPUs 1608 may include graphics memory (e.g., display memory) for storing pixel data or any other suitable data (e.g., GPGPU data). Display memory may be included as part of memory 1604. One or more GPUs 1608 may include two or more GPUs operating in parallel (e.g., via a link). The link may directly connect the GPUs (e.g., using NVLINK) or may connect the GPUs via a switch (e.g., using NVSwitch). When combined, each GPU 1608 may generate pixel data or GPGPU data for a different portion of the output or for different outputs (e.g., a first GPU for a first image and a second GPU for a second image). Each GPU may include its own memory or may share memory with other GPUs.

[0295] In addition to one or more CPUs 1606 and / or one or more GPUs 1608, or as an alternative, one or more logic units 1620 may be configured to execute at least some of computer-readable instructions to control one or more components of computing device 1600 to perform one or more of the methods and / or processes described herein. In embodiments, one or more CPUs 1606, one or more GPUs 1608, and / or one or more logic units 1620 may execute any combination of methods, processes, and / or portions thereof discretely or jointly. One or more logic units 1620 may be one or more of CPUs 1606 and / or GPUs 1608 and / or integrated into one or more of CPUs 1606 and / or GPUs 1608, and / or one or more logic units 1620 may be discrete components or otherwise external to CPUs 1606 and / or GPUs 1608. In an embodiment, one or more logic units in logic unit 1620 may be coprocessors of one or more CPUs in CPU 1606 and / or one or more GPUs in GPU 1608.

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

[0297] Communication interface 1610 may include one or more receivers, transmitters, and / or transceivers that enable computing device 1600 to communicate with other computing devices via electronic communication networks (including wired and / or wireless communications). Communication interface 1610 may include components and functions for enabling communication over any of a plurality of different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., communication over Ethernet or wirelessband), low-power wide area networks (e.g., LoRaWAN, SigFox, etc.), and / or the Internet.

[0298] I / O port 1612 enables computing device 1600 to be logically coupled to other devices including I / O component 1614, one or more presentation components 1618, and / or other components, some of which may be built into (e.g., integrated into) computing device 1600. Illustrative I / O component 1614 includes microphones, mice, keyboards, joysticks, game pads, game controllers, satellite dish antennas, scanners, printers, wireless devices, etc. I / O component 1614 can provide a natural user interface (NUI) that processes air gestures, voice, or other physiological input generated by the user. In some cases, input may be transmitted to appropriate network elements for further processing. The NUI can implement any combination of voice recognition, pen recognition, facial recognition, biometric recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, and touch recognition (as described in more detail below) associated with the display of computing device 1600. Computing device 1600 may include depth cameras for gesture detection and recognition, such as stereo camera systems, infrared camera systems, RGB camera systems, touchscreen technology, and combinations thereof. Additionally, computing device 1600 may include an accelerometer or gyroscope (e.g., as part of an inertial measurement unit (IMU)) that enables motion detection. In some examples, computing device 1600 may use the output of the accelerometer or gyroscope to render immersive augmented reality or virtual reality.

[0299] Power supply 1616 may include hard-wired power supply, battery power supply, or a combination thereof. Power supply 1616 may provide power to computing device 1600 so that the components of computing device 1600 can operate.

[0300] One or more presentation components 1618 may include displays (e.g., monitors, touchscreens, television screens, head-up displays (HUDs), other display types, or combinations thereof), speakers, and / or other presentation components. One or more presentation components 1618 may receive data from other components (e.g., one or more GPUs 1608, one or more CPUs 1606, etc.) and output data (e.g., as images, videos, sounds, etc.).

[0301] This disclosure can 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). Generally, a program module, including routines, programs, objects, components, data structures, etc., refers to code that performs a specific task or implements a specific abstract data type. This disclosure can be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, and more specialized computing devices. This disclosure can also be practiced in distributed computing environments, where tasks are performed by remote processing devices linked via a communication network.

[0302] At least one embodiment of this disclosure may be described in accordance with the following terms:

[0303] 1. A system comprising: a memory operating according to a first risk classification level; and circuitry operating according to a second risk classification level indicating a higher risk classification than the first risk classification level, the circuitry being configured to: determine an error detection code for data to be written to a first memory address within the memory; determine a second memory address within the memory based at least in part on the first memory address; and store the data in the first memory address and store the error detection code in the second memory address.

[0304] 2. The system as described in Clause 1, wherein after the data is stored in the first memory address and the error detection code is stored in the second memory address: the circuitry is configured to: obtain the data from the first memory address, obtain the error detection code from the second memory address, generate a checksum based on the first memory address and the data obtained from the first memory address, and generate a notification when the error detection code indicates that the data contains at least one error.

[0305] 3. The system as described in Clause 2, wherein when the error detection code does not match the check code, the error detection code indicates that the data contains the at least one error.

[0306] 4. The system as described in Clause 2 or 3, wherein the circuitry is configured to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access.

[0307] 5. The system of any one of Clauses 2-4 further comprises: a first interface through which the data is obtained from the first memory address; and a second interface through which the error detection code is obtained from the second memory address in parallel with the data obtained from the first interface, wherein the first interface and the second interface are different.

[0308] 6. The system as described in Clause 4, wherein the circuitry introduces a time delay between the first memory access and the second memory access.

[0309] 7. The system of any one of Clauses 1-6, wherein the memory comprises a first sub-part and a second sub-part, the first sub-part including the first memory address, the second sub-part including the second memory address, and the circuitry for writing a new error detection code to each memory address in the second sub-part during a startup procedure.

[0310] 8. The system of any one of clauses 1-7, wherein the circuitry is configured to determine the error detection code based on the first memory address and the data before writing the data to the first memory address.

[0311] 9. The system of any one of Clauses 1-8, wherein the circuitry comprises a first block and a second block, the first block being configured to transmit a write request including the data and the first memory address to the second block, the second block being configured to: receive the write request, determine the error detection code, determine the second memory address, and store the data in the first memory address and store the error detection code in the second memory address.

[0312] 10. The system as described in Clause 9, wherein the first block includes a write timer that is started when the first block transmits the write request to the second block, and the first block is configured to generate a write error when the write timer indicates that more than a predetermined amount of time has elapsed before the first block receives a response from the memory.

[0313] 11. The system as described in Clause 9 or 10, wherein after the first block sends the write request: the first block is configured to send a read request to the second block for the data stored in the first memory address, and the second block is configured to: receive the read request, obtain the data from the first memory address, obtain the error detection code from the second memory address, and transmit a notification to the first block when the second block determines that the error detection code indicates that the data contains the at least one error.

[0314] 12. The system as described in Clause 11, wherein the first block includes a read timer that is started when the first block sends the read request, and the first block is configured to generate a read error when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.

[0315] 13. The system of any one of clauses 1-12, wherein the circuitry is configured to store the data in the first memory address during a first memory access and to store the error detection code in the second memory address during a second memory access.

[0316] 14. The system as described in Clause 13, wherein the circuitry introduces a first time delay between the first memory access and the second memory access.

[0317] 15. The system as described in any one of Clauses 1-14, wherein it is situated on a continuous semiconductor material.

[0318] 16. The system as described in Clause 15, which implements a part of a system-on-a-chip (“SoC”) corresponding to a motor vehicle.

[0319] 17. The system as described in any one of Clauses 1-16, wherein both the first risk classification level and the second risk classification level are vehicle safety integrity levels (“ASIL”).

[0320] 18. The system of any one of Clauses 1-17, wherein the error detection code is a cyclic redundancy check code or an error correction code.

[0321] 19. A system comprising: a memory for operating within a first risk classification level, the memory including isolated memory regions including a first memory address for storing data and a second memory address for storing an error detection code; and circuitry for operating within a second risk classification level indicating a risk level higher than the first risk classification level, the circuitry being configured to: obtain the data from the first memory address, obtain the error detection code from the second memory address, and generate a notification when the error detection code indicates that the data contains at least one error.

[0322] 20. The system of claim 19, wherein the circuitry is configured to generate a checksum based on the first memory address and the data obtained from the first memory address, wherein the checksum indicates that the data contains the at least one error when the checksum does not match the checksum.

[0323] 21. The system as described in Clause 19 or 20, wherein the circuitry includes a first block and a second block, the first block being configured to send a read request to the second block for the data stored in the first memory address, and the second block being configured to: receive the read request, obtain the data, obtain the error detection code, and generate the notification when the error detection code indicates that the data contains the at least one error.

[0324] 22. The system as described in Clause 21, wherein the first block includes a read timer that is started when the first block sends the read request, and the first block is configured to generate an error when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.

[0325] 23. The system as described in Clause 21 or 22, wherein before the first block sends the read request: the first block is configured to transmit the data and the first memory address to the second block, and the second block is configured to: determine the error detection code, determine the second memory address, store the data in the first memory address, and store the error detection code in the second memory address.

[0326] 24. The system as described in Clause 23, wherein the first block includes a write timer that is started when the first block transmits the data and the first memory address to the second block, and the first block is configured to generate a write error when the write timer indicates that more than a first predetermined amount of time has elapsed before the first block receives a response from the memory.

[0327] 25. The system as described in Clause 24, wherein the first block includes a read timer that is started when the first block sends the read request, and the first block is configured to generate a read error when the read timer indicates that more than a second predetermined amount of time has elapsed before the first block receives the data from the memory.

[0328] 26. The system of any one of clauses 19-25, wherein the circuitry is configured to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access.

[0329] 27. The system as described in Clause 26, wherein the circuitry introduces a time delay between the first memory access and the second memory access.

[0330] 28. The system of any one of clauses 19-27, wherein the circuit writes the error detection code to the second memory address during the startup procedure.

[0331] 29. The system as described in any one of Clauses 19-28, wherein it is situated on a continuous semiconductor material.

[0332] 30. The system as described in Clause 29, which implements a part of a system-on-a-chip (“SoC”) corresponding to a motor vehicle.

[0333] 31. The system as described in any one of Clauses 19-30, wherein both the first risk classification level and the second risk classification level are vehicle safety integrity levels (“ASIL”).

[0334] 32. The system of any one of Clauses 19-31, wherein the error detection code is a cyclic redundancy check code or an error correction code.

[0335] 33. A method performed by circuitry operating at a first risk classification level, the method comprising: determining an error detection code for data to be written to a first memory address in a memory, the memory operating at a second risk classification level indicating a risk level lower than the first risk classification level; determining a second memory address in the memory based at least in part on the first memory address; and storing the data at the first memory address and storing the error detection code at the second memory address.

[0336] 34. The method of Clause 33, further comprising: obtaining the data from the first memory address after the data is stored in the first memory address; obtaining the error detection code from the second memory address after the error detection code is stored in the second memory address; generating a check code based on the first memory address and the data obtained from the first memory address; and generating a notification when the check code indicates that the data contains at least one error.

[0337] 35. The method of Clause 34, wherein the error detection code is generated based on the first memory address and the data before the data is stored in the first memory address, and the check code indicates that the data contains the at least one error when the check code does not match the error detection code.

[0338] 36. The method of any one of clauses 33-35, wherein the memory comprises a first sub-part and a second sub-part, the first sub-part including the first memory address, the second sub-part including the second memory address, and the method further comprising: writing a new error detection code to each memory address in the second sub-part during a startup procedure.

[0339] 37. A method executed by circuitry operating at a first risk classification level, the method comprising: obtaining data from a first memory address of a memory operating at a second risk classification level, the second risk classification level indicating a risk level lower than the first risk classification level; determining a second memory address within the memory based at least in part on the first memory address; obtaining an error detection code from the second memory address; and generating a notification when the error detection code indicates that the data contains at least one error.

[0340] 38. The method of Clause 37, further comprising: generating a check code based on the first memory address and the data obtained from the first memory address; and determining whether the check code matches the error detection code, wherein when the error detection code does not match the check code, the error detection code indicates that the data contains the at least one error.

[0341] 39. The method of claim 37 or 38, wherein the circuit obtains the data from the first memory address during a first memory access, the circuit obtains the error detection code from the second memory address during a second memory access, and the method further comprises: introducing a time delay between the first memory access and the second memory access.

[0342] 40. The method of any one of clauses 37-39, wherein the circuitry comprises a first block and a second block, and the method further comprises: sending a read request from the first block to the second block for the data stored in the first memory address; receiving the read request from the second block, the second block obtaining the data, obtaining the error detection code, and generating the notification when the error detection code indicates that the data contains the at least one error.

[0343] 41. The method of Clause 40, wherein the read timer is started when the first block sends the read request, and the method further comprises: the first block generating a read error when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.

[0344] 42. The method of claim 40 or 41, further comprising: transmitting a write request from the first block to the second block before the first block sends the read request, the write request including the data and the first memory address; determining the error detection code before the first block sends the read request; determining the second memory address before the first block sends the read request; and storing the data in the first memory address and storing the error detection code in the second memory before the first block sends the read request.

[0345] 43. The method of claim 42, wherein the write timer is started when the first block sends the write request, and the method further comprises: generating a write error by the first block when the write timer indicates that more than a first predetermined amount of time has elapsed before the first block receives a response from the memory.

[0346] 44. The method of Clause 43, wherein the read timer is started when the first block sends the read request, and the method further comprises: generating a read error by the first block when the read timer indicates that more than a second predetermined amount of time has elapsed before the first block receives the data.

[0347] 45. The method of any one of clauses 42-44, wherein the second block causes the data to be stored in the first memory address during the first memory access, the second block causes the error detection code to be stored in the second memory address during the second memory access, and the method further comprises: introducing a time delay between the first memory access and the second memory access.

[0348] 46. ​​The method of any one of clauses 37-45, further comprising: writing the error detection code to the second memory address during the startup procedure.

[0349] 47. The method of any one of Clauses 37-46, wherein both the first risk classification level and the second risk classification level are vehicle safety integrity levels (“ASIL”).

[0350] 48. The method of any one of clauses 37-47, wherein the error detection code is a cyclic redundancy check code or an error correction code.

[0351] Unless otherwise stated or obviously contradicted by the context, the terms “a,” “an,” and “the,” and similar references, used in the context of describing the disclosed embodiments (particularly in the context of the appended claims), should be interpreted as encompassing both singular and plural forms, rather than as definitions of the terms. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” should be interpreted as open-ended terms (meaning “including, but not limited to”). The term “connection” (referring to a physical connection where not modified) should be interpreted as partially or wholly contained, attached to, or joined together, even with some intervention. Unless otherwise indicated herein, references to numerical ranges herein are intended only as a way of abbreviating each individual value falling within that range, and each individual value is incorporated into the specification as if it were separately described herein. In at least one embodiment, unless otherwise indicated or contradicted by the context, the use of the terms “set” (e.g., “item set”) or “subset” should be interpreted as a non-empty set comprising one or more members. Furthermore, unless otherwise indicated or contradicted by the context, the term “subset” of the corresponding set does not necessarily mean an appropriate subset of the corresponding set, but rather that the subset and the corresponding set can be equal.

[0352] As used herein, the phrase “and / or” relating to two or more elements should be interpreted as referring to only one element or a combination of elements. For example, “element A, element B and / or element C” could include only element A, only element B, only element C, element A and element B, element A and element C, element B and element C, or element A, B and C.

[0353] Unless otherwise explicitly stated or clearly contradicted by the context, connective phrases such as “at least one of A, B, and C” or “at least one of A, B, and C” are understood in the context to generally refer to items, terms, etc., which can be A or B or C, or any non-empty subset of the set A, B, and C. For example, in an illustrative example of a set with three members, the connective phrases “at least one of A, B, and C” and “at least one of A, B, and C” refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Therefore, such connective language is generally not intended to imply that some embodiments require the presence of at least one of A, at least one of B, and at least one of C. Additionally, unless otherwise stated or contradicted by the context, the term “multiple” indicates a plural state (e.g., “multiple items” means multiple items). In at least one embodiment, the number of items in the multiple items is at least two, but may be more if explicitly indicated or indicated by the context. Furthermore, unless otherwise stated or clearly understood from the context, the phrase “based on” means “at least partially based on” rather than “based on only”.

[0354] Unless otherwise indicated herein or clearly contradicted by the context, the operations of the processes described herein may be performed in any suitable order. In at least one embodiment, processes such as those described herein (or variations thereof and / or combinations thereof) are executed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more application programs) that is executed jointly on one or more processors via hardware or a combination thereof. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transient signals (e.g., propagating transient electrical or electromagnetic transmissions) but includes non-transitory data storage circuitry (e.g., buffers, caches, and queues). In at least one embodiment, code (e.g., executable code or source code) is stored on one or more non-transitory computer-readable storage media (or other memory for storing executable instructions) on which executable instructions are stored, which, when executed by one or more processors of a computer system (i.e., as a result of execution), cause the computer system to perform the operations described herein. In at least one embodiment, the set of non-transitory computer-readable storage media comprises multiple non-transitory computer-readable storage media, and one or more of the individual non-transitory storage media lack all the code, but the multiple non-transitory computer-readable storage media collectively store all the code. In at least one embodiment, the executable instructions are executed such that different instructions are executed by different processors; in at least one embodiment, the non-transitory computer-readable storage media store the instructions, and the main central processing unit (“CPU”) executes some instructions while the graphics processing unit (“GPU”) executes other instructions. In at least one embodiment, different components of the computer system have separate processors, and the different processors execute different subsets of the instructions.

[0355] Therefore, in at least one embodiment, the computer system is configured to implement one or more services that perform the operations of the processes described herein, either individually or collectively, and such a computer system is configured with suitable hardware and / or software to enable the implementation of the operations. Furthermore, the computer system implementing at least one embodiment of this disclosure is a single device, and in another embodiment it is a distributed computer system comprising multiple devices operating in different ways, such that the distributed computer system performs the operations described herein, and that a single device does not perform all the operations.

[0356] The use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended only to better illustrate embodiments of this disclosure and does not constitute a limitation on the scope of the disclosure unless otherwise required. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of the disclosure.

[0357] All references cited in this article, including publications, patent applications and patents, are incorporated herein by reference as if each reference were individually and specifically indicated to be incorporated herein by reference and the entire contents of which are described herein.

[0358] The terms “coupled” and “connected”, and their derivatives, may be used in the specification and claims. It should be understood that these terms may not be intended to be synonyms with 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 each other. “Coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0359] Unless otherwise expressly stated, it will be understood that throughout this specification, terms such as “processing,” “computing,” “determining,” etc., refer to the actions and / or processes of a computer or computing system or similar electronic computing device that process and / or convert data represented as physical quantities (e.g., electrons) in the registers and / or memory of the computing system into other data represented as physical quantities in the memory, registers, or other such information storage, transmission, or display devices of the computing system.

[0360] Similarly, the term "processor" can refer to any device or part of memory that processes electronic data from registers and / or memory and converts that electronic data into other electronic data that can be stored in registers and / or memory. As a non-limiting example, a "processor" can be a CPU or a GPU. A "computing platform" can include one or more processors. As used herein, in at least one embodiment, a "software" process can include software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Likewise, each process can refer to multiple processes that execute instructions sequentially or intermittently, or in parallel. The terms "system" and "method" are used interchangeably herein, provided that a system can embody one or more methods, and a method can be considered a system.

[0361] In at least one embodiment, an arithmetic logic unit is a set of combinational logic circuits that takes one or more inputs to produce a result. In at least one embodiment, a processor uses an arithmetic logic unit to implement 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 is made of physical switching elements, such as semiconductor transistors arranged as logic gates. In at least one embodiment, an arithmetic logic unit may operate internally as a stateful logic circuit with an associated clock. In at least one embodiment, an arithmetic logic unit may be configured as an asynchronous logic circuit having internal state not held in an associated register set. In at least one embodiment, a processor uses an arithmetic logic unit to combine operands stored in one or more registers of the processor and produce an output that can be stored by the processor in another register or memory location.

[0362] In at least one embodiment, as a result of processing instructions retrieved by the processor, the processor presents one or more inputs or operands to the arithmetic logic unit (ALU), causing the ALU to produce a result at least in part based on instruction codes provided to the ALU of the inputs. In at least one embodiment, the instruction codes provided by the processor to the ALU are at least in part based on instructions executed by the processor. In at least one embodiment, combinational logic in the ALU processes the inputs and produces an output placed on the processor's internal bus. In at least one embodiment, the processor selects a destination register, memory location, output device, or output storage location on the output bus to time the processor so that the result produced by the ALU is sent to the desired location.

[0363] In this document, reference may be made 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 process of obtaining, acquiring, receiving, or inputting analog and digital data can be configured in various ways, such as by receiving data as a parameter to a function call or a call to an application programming interface. In some implementations, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data via a serial or parallel interface. In another implementation, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. Reference may also be made to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog or digital data can be implemented by transmitting data as an input or output parameter to a function call, an application programming interface, or an inter-process communication mechanism.

[0364] While the discussion above illustrates example implementations of the described technologies, other architectures can be used to implement the described functionality and are intended to fall within the scope of this disclosure. Furthermore, although specific assignments of responsibilities have been defined above for discussion purposes, various functions and responsibilities can be assigned and divided in different ways depending on the circumstances.

[0365] Furthermore, although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms for implementing the claims.

[0366] This document specifically describes the subject matter of this disclosure to satisfy legal requirements. However, this description itself is not intended to limit the scope of this disclosure. Rather, the inventors have anticipated that the claimed subject matter may also be embodied in other ways, in conjunction with other current or future techniques, to include different steps or combinations of steps similar to those described in this document. Furthermore, although the terms “step” and / or “box” may be used herein to indicate different elements of the method employed, these terms should not be construed as indicating any particular order among or between the various steps disclosed herein, unless the order of the steps is explicitly described.

[0367] Other variations are within the spirit of this disclosure. Therefore, while the disclosed technology is readily adaptable to various modifications and alternative constructions, certain illustrated embodiments are shown in the accompanying drawings and have been described in detail above. However, it should be understood that the disclosure is not intended to be limited to the specific one or more forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure as defined in the appended claims.

Claims

1. A system for transmitting data between areas with different risk classification levels, comprising: A memory operating according to a first risk classification level, wherein the memory includes isolated memory regions, the isolated memory regions including a first memory address and a second memory address; and A circuit operating at a second risk classification level, which is higher than the first risk classification level, exclusively uses the isolated memory region via a communication path operating at the second risk classification level. The circuit is configured to: determine an error detection code for data to be written to a first memory address in the memory; determine a second memory address in the memory based at least in part on the first memory address; and store the data in the first memory address and store the error detection code in the second memory address.

2. The system of claim 1, wherein after the data is stored in the first memory address and the error detection code is stored in the second memory address: The circuit is configured to obtain the data from the first memory address, obtain the error detection code from the second memory address, generate a check code based on the first memory address and the data obtained from the first memory address, and generate a notification when the error detection code indicates that the data contains at least one error.

3. The system of claim 2, wherein when the error detection code does not match the check code, the error detection code indicates that the data contains the at least one error.

4. The system of claim 2, wherein the circuitry is configured to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access.

5. The system of claim 2, further comprising: A first interface is used to obtain the data from the first memory address; as well as The second interface is used to obtain the error detection code from the second memory address in parallel with the data obtained from the first interface. The first interface is different from the second interface.

6. The system of claim 4, wherein the circuitry introduces a time delay between the first memory access and the second memory access.

7. The system of claim 1, wherein the memory comprises a first sub-part and a second sub-part. The first sub-part includes the first memory address. The second sub-part includes the second memory address, and The circuitry is used to write new error detection codes to each memory address in the second sub-section during the startup process.

8. The system of claim 1, wherein the circuitry is configured to determine the error detection code based on the first memory address and the data before writing the data to the first memory address.

9. The system of claim 1, wherein the circuit comprises a first block and a second block. The first block is used to transmit a write request, including the data and the first memory address, to the second block. The second block is used to receive the write request, determine the error detection code, determine the second memory address, and store the data in the first memory address and store the error detection code in the second memory address.

10. The system of claim 9, wherein the first block includes a write timer, the write timer being started when the first block transmits the write request to the second block, and The first block is configured to generate a write error when the write timer indicates that more than a predetermined amount of time has elapsed before the first block receives a response from the memory.

11. The system of claim 9, wherein after the first block sends the write request: The first block is used to send a read request to the second block for the data stored at the first memory address, and The second block is configured to receive the read request, obtain the data from the first memory address, obtain the error detection code from the second memory address, and transmit a notification to the first block when the second block determines that the error detection code indicates that the data contains at least one error.

12. The system of claim 11, wherein the first block includes a read timer, the read timer being started when the first block sends the read request, and The first block is configured to generate a read error when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.

13. The system of claim 1, wherein the circuitry is configured to store the data in the first memory address during a first memory access and to store the error detection code in the second memory address during a second memory access.

14. The system of claim 13, wherein the circuitry introduces a first time delay between the first memory access and the second memory access.

15. The system of claim 1, wherein it is situated on a continuous semiconductor material.

16. The system of claim 15, wherein it is implemented as part of a system-on-chip (SoC) corresponding to a motor vehicle.

17. The system of claim 1, wherein both the first risk classification level and the second risk classification level are Automotive Safety Integrity Levels (ASIL).

18. The system of claim 1, wherein the error detection code is a cyclic redundancy check code or an error correction code.

19. A system for transmitting data between areas with different risk classification levels, comprising: A memory for operation within a first risk classification level, the memory comprising isolated memory regions including a first memory address for storing data and a second memory address for storing error detection codes; as well as A circuit for operating within a second risk classification level that indicates a higher risk level than the first risk classification level, the circuit exclusively using the isolated memory region via a communication path operating at the second risk classification level, the circuit being configured to: obtain the data from the first memory address; obtain the error detection code from the second memory address; and generate a notification when the error detection code indicates that the data contains at least one error.

20. The system of claim 19, wherein the circuitry is configured to generate a checksum based on the first memory address and the data obtained from the first memory address, wherein when the checksum does not match the error detection code, the error detection code indicates that the data contains the at least one error.

21. The system of claim 19, wherein the circuit comprises a first block and a second block. The first block is used to send a read request to the second block for the data stored at the first memory address, and The second block is used to receive the read request, obtain the data, obtain the error detection code, and generate the notification when the error detection code indicates that the data contains at least one error.

22. The system of claim 21, wherein the first block includes a read timer that is started when the first block sends the read request, and the first block is configured to generate an error when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.

23. The system of claim 21, wherein before the first block sends the read request: The first block is used to transfer the data and the first memory address to the second block, and The second block is used to determine the error detection code, determine the second memory address, store the data in the first memory address, and store the error detection code in the second memory address.

24. The system of claim 23, wherein the first block includes a write timer, the write timer being started when the first block transmits the data and the first memory address to the second block, and The first block is configured to generate a write error when the write timer indicates that more than a first predetermined amount of time has elapsed before the first block receives a response from the memory.

25. The system of claim 24, wherein the first block includes a read timer that starts when the first block sends the read request, and the first block is configured to generate a read error when the read timer indicates that more than a second predetermined amount of time has elapsed before the first block receives the data from the memory.

26. The system of claim 19, wherein the circuitry is configured to obtain the data from the first memory address during a first memory access and to obtain the error detection code from the second memory address during a second memory access.

27. The system of claim 26, wherein the circuitry introduces a time delay between the first memory access and the second memory access.

28. The system of claim 19, wherein the circuit writes the error detection code to the second memory address during the startup procedure.

29. The system of claim 19, wherein it is situated on a continuous semiconductor material.

30. The system of claim 29, wherein it is implemented as part of a system-on-chip (SoC) corresponding to a motor vehicle.

31. The system of claim 19, wherein both the first risk classification level and the second risk classification level are Automotive Safety Integrity Levels (ASIL).

32. The system of claim 19, wherein the error detection code is a cyclic redundancy check code or an error correction code.

33. A method performed by a circuit operating under a first risk classification level, the method comprising: An error detection code is determined for data to be written to a first memory address in the memory, the memory operating at a second risk classification level indicating a risk level lower than the first risk classification level, wherein the memory includes an isolated memory region, the isolated memory region including the first memory address and the second memory address, and the circuit exclusively uses the isolated memory region via a communication path operating at the first risk classification level. The second memory address within the memory is determined at least in part based on the first memory address; and The data is stored in the first memory address, and the error detection code is stored in the second memory address.

34. The method of claim 33, further comprising: After the data is stored in the first memory address, the data is obtained from the first memory address; After the error detection code is stored in the second memory address, the error detection code is obtained from the second memory address; A verification code is generated based on the first memory address and the data obtained from the first memory address; as well as A notification is generated when the checksum indicates that the data contains at least one error.

35. The method of claim 34, wherein the error detection code is generated based on the first memory address and the data before the data is stored in the first memory address, and When the check code does not match the error detection code, the check code indicates that the data contains at least one error.

36. The method of claim 33, wherein the memory includes a first sub-part and a second sub-part, the first sub-part including the first memory address, the second sub-part including the second memory address, and the method further includes: During the startup process, a new error detection code is written to each memory address in the second sub-section.

37. A method performed by a circuit operating under a first risk classification level, the method comprising: Data is obtained from a first memory address of a memory operating under a second risk classification level, the second risk classification level indicating a lower risk level than the first risk classification level, wherein the memory includes isolated memory regions including the first memory address and the second memory address, and the circuit exclusively uses the isolated memory regions via a communication path operating under the first risk classification level. The second memory address within the memory is determined at least in part based on the first memory address; Obtain the error detection code from the second memory address; and A notification is generated when the error detection code indicates that the data contains at least one error.

38. The method of claim 37, further comprising: A verification code is generated based on the first memory address and the data obtained from the first memory address; as well as Determine whether the check code matches the error detection code. When the error detection code does not match the check code, the error detection code indicates that the data contains at least one error.

39. The method of claim 37, wherein the circuit obtains the data from the first memory address during a first memory access, the circuit obtains the error detection code from the second memory address during a second memory access, and the method further comprises: A time delay is introduced between the first memory access and the second memory access.

40. The method of claim 37, wherein the circuit comprises a first block and a second block, and the method further comprises: The first block sends a read request for the data stored in the first memory address to the second block; as well as The second block receives the read request, obtains the data, obtains the error detection code, and generates the notification when the error detection code indicates that the data contains at least one error.

41. The method of claim 40, wherein the read timer is started when the first block sends the read request, and the method further comprises: A read error is generated by the first block when the read timer indicates that more than a predetermined amount of time has elapsed before the first block receives the data.

42. The method of claim 40, further comprising: Before the first block sends the read request, the first block transmits a write request to the second block, the write request including the data and the first memory address; The error detection code is determined by the second block before the first block sends the read request; The second memory address is determined by the second block before the first block sends the read request; as well as Before the first block sends the read request, the second block stores the data in the first memory address and stores the error detection code in the second memory.

43. The method of claim 42, wherein the write timer is started when the first block sends the write request, and the method further comprises: A write error is generated by the first block when the write timer indicates that more than a first predetermined amount of time has elapsed before the first block receives a response from the memory.

44. The method of claim 43, wherein the read timer is started when the first block sends the read request, and the method further comprises: A read error is generated by the first block when the read timer indicates that more than a second predetermined amount of time has elapsed before the first block receives the data.

45. The method of claim 42, wherein the second block stores the data in the first memory address during the first memory access, the second block stores the error detection code in the second memory address during the second memory access, and the method further comprises: A time delay is introduced between the first memory access and the second memory access.

46. ​​The method of claim 37, further comprising: The error detection code is written to the second memory address during the startup process.

47. The method of claim 37, wherein both the first risk classification level and the second risk classification level are Automotive Safety Integrity Levels (ASIL).

48. The method of claim 37, wherein the error detection code is a cyclic redundancy check code or an error correction code.

Images