Multiple System-on-Chip Deployment for Vehicle Computing Systems

Abstract

The computing system may include a first system-on-a-chip (SoC) and a second SoC. Each SoC may have memory into which the SoC exposes state information. In the first SoC, the state information may correspond to a set of tasks performed by the first SoC, which executes the set of tasks using multiple computing components. The first SoC may have direct access to its own memory to dynamically read the state information exposed by the first SoC. In a backup role, the second SoC maintains a subset of computing components in a low-power state. If the second SoC detects a trigger while reading the state information exposed in the first memory of the first SoC, the second SoC powers up the subset of computing components and takes over the set of tasks.

Description

Technical Field

[0001] Universal Chiplet Interconnect Express (UCIe) is an open standard for interconnection between multiple chiplets and serial buses, which enables the manufacture of large-scale system-on-chip (SoC) packages mixing components from various semiconductor manufacturers. Autonomous vehicle computing systems may operate using chiplet arrangements that comply with the UCIe standard. One goal of developing such computing systems is to achieve robust safety levels for other critical electrical / electronic (E / E) automotive components of the vehicle.

Summary of the Invention

[0002] This specification describes an in-vehicle computing system that implements a multiple system-on-chip (MSoC) architecture to provide redundancy, increase the lifespan of hardware components, and improve the safety assessment of the computing system. The system may include a first system-on-chip (SoC) having a first memory, the first SoC exposing state information in its memory corresponding to a set of tasks performed by the first SoC. The first SoC may further include a plurality of computing components, which may include various chiplets that perform the set of tasks. The computing system may further include a second SoC having a second memory and a second plurality of computing components. The second SoC may have direct memory access to the first memory of the first SoC in order to dynamically read the state information exposed by the first SoC. In various examples, the second SoC maintains a subset of the second plurality of computing components in a low-power state. When the second SoC detects a trigger while reading state information exposed in the first memory of the first SoC, the second SoC powers up a subset of computing components and takes over the set of tasks.

[0003] In various implementations, the set of tasks may include multiple autonomous driving tasks, such as sensor data processing, inference, scene understanding, object detection and classification, motion prediction of dynamic external agents, and / or motion planning and execution for operating the autonomous vehicle along a route. The state information exposed to memory by the first SoC may generally include all the information necessary for the second SoC to take over the set of autonomous driving tasks. For example, the state information may include statistical information corresponding to the surrounding environment of the vehicle where the computing system resides. It is intended that multiple SoC pairs may be implemented, with each pair performing a subset of the autonomous driving tasks. For example, one SoC pair may be configured to perform an object detection task, a second SoC pair may be configured to perform an object classification task, and a third SoC pair may be configured to perform a motion prediction task, and so on. Thus, the set of tasks for an SoC pair may include a subset of the entire set of tasks necessary for the vehicle to operate autonomously. The implementation of the SoC pair is further intended for use in semi-autonomous driving applications, such as in conjunction with advanced driver assistance systems (ADAS) capable of performing various automated functions. These functions may include collision warning, emergency braking, lane following, lane centering, emergency steering, and automatic parking.

[0004] In various examples, the trigger for the second SoC to take over a set of tasks may correspond to the first SoC experiencing a failure or malfunction (a failure or malfunction occurs in the first SoC). As described herein, the failure or malfunction of the first SoC may correspond to overheating, power surges, and / or errors in the first SoC. Such errors may correspond to hardware errors (e.g., transistor failures) that may affect the performance of the first SoC in performing (completing) the set of tasks. In certain examples, when the second SoC powers up a subset of computing components from a sleep or low-power state and takes over the set of tasks from the first SoC, the first SoC automatically resets or reboots the computing components to attempt to resolve the failure and / or malfunction. During the reset or reboot, the first SoC may take over previous backup tasks of the second SoC. In other words, the first SoC can directly access the memory of the second SoC and continuously read state information corresponding to the second SoC, which is executing a set of autonomous driving tasks. Meanwhile, the second SoC executes a set of autonomous driving tasks and exposes state information corresponding to that set of autonomous driving tasks to memory.

[0005] In certain implementations, the first SoC may be powered by a first power source in the vehicle, and the second SoC may be powered by a second power source in the vehicle that is largely isolated from the first power source. For example, an electric vehicle may include a battery pack that powers an electric motor to propel the vehicle, and an auxiliary battery (e.g., a standard 12-volt battery) that powers auxiliary components of the vehicle such as an electronic control unit (ECU), dashboard functions, power windows, and lights. In such a vehicle, the first SoC may be powered by the battery pack, and the second SoC may be powered by the auxiliary battery. In a further example, the first SoC and the second SoC may be electrically coupled to each other via an interconnection having at least one electrical safety switch (e.g., one or more electronic fuses (eFuses)) to protect the computing system from power surges from either the first or second SoC. Therefore, the first SoC and the second SoC can be electrically insolated from each other (i.e., isolated from power supplies and isolated from power surge damage).

[0006] As described herein, each time the computing system is rebooted, the first SoC and the second SoC may switch between primary and backup roles. Therefore, in normal operation where neither is failing or malfunctioning, if the first SoC performs a set of tasks during a first computing session (e.g., when the vehicle is running), the second SoC will perform a set of tasks during a second computing session (e.g., when the vehicle is returning from running). Regardless of which “primary” SoC is performing a set of tasks during a particular computing session, the “backup” SoC continuously reads from the primary SoC’s memory, with a subset of computing components in a low-power state but warmed up and ready to take over the set of tasks from the primary SoC.

[0007] In further implementations, the primary SoC may continuously read the backup SoC's memory to check if the backup SoC is ready to take over the primary SoC's set of tasks. In scenarios where the primary SoC detects that the backup SoC is not ready (e.g., has failed or malfunctioned), the primary SoC may attempt to resolve the failure or malfunction by causing the backup SoC to reset and / or reboot its computing components.

[0008] The arrangement of SoC pairs, where a backup SoC dynamically reads state information and takes over a set of tasks, is intended to provide redundancy that facilitates the automotive safety integrity level (ASIL) evaluation of the computing system. As described herein, the computing components of each SoC may include chiplets such as one or more computer processing unit (CPU) chiplets, one or more autonomous driving chiplets, one or more machine learning (ML) accelerator chiplets, one or more sensor input chiplets, and / or one or more high-bandwidth memory (HBM) chiplets. As further described herein, the computing components of each SoC may include a FuSa CPU that exposes the state information of its SoC to a functional safety (FuSa) component of its memory. This FuSa memory component contains state information and can be read directly by each SoC. Therefore, while other computing components of the SoC may operate in a low-power state, FuSa components (e.g., a dedicated FuSa CPU) may remain powered up and operational, regardless of whether the SoC is in a primary or backup role. [Brief explanation of the drawing]

[0009] The disclosures herein are illustrative and not limiting, and in the figures of the accompanying drawings, similar reference numbers refer to similar elements. [Figure 1] This block diagram shows an example of a computing system in which an embodiment described herein may be implemented, according to the examples described herein. [Figure 2] This is a block diagram showing an example of a multiple systems-on-a-chip (MSoC) according to the examples described herein. [Figure 3] This is a block diagram showing an example of an SoC with a certain MSoC configuration, as described herein. [Figure 4] This block diagram shows an example of a central chiplet of an SoC that includes a shared memory device for performing replication status and shadowing for multiple SoCs, as described in the examples herein. [Figure 5] This flowchart illustrates how to perform replication status and shadowing for multiple SoCs, as described in the examples provided herein. [Figure 6] This flowchart illustrates how to perform replication status and shadowing for multiple SoCs, as described in the examples provided herein. [Modes for carrying out the invention]

[0010] In experimental and controlled test environments, system redundancy and Automotive Safety Integrity Level (ASIL) assessments of autonomous systems are typically not priority considerations. As autonomous driving capabilities continue to advance (e.g., beyond Level 3 autonomy) and autonomous vehicles become commonplace on public road networks, qualification and certification of E / E components related to the autonomous operation of these vehicles will be advantageous in ensuring their operational safety. Furthermore, novel methods for certifying hardware, software, and / or hardware / software combinations as qualified will also be advantageous in increasing public confidence and assurance that autonomous driving systems are safer than current standards. For example, specific safety standards for autonomous driving systems include safety thresholds corresponding to average human capabilities and attention. However, these statistics include vehicle incidents associated with drivers with reduced driving ability or distracted drivers, and do not take into account certain time windows where the risk of vehicle operation is inherently increased (e.g., bad weather conditions, nighttime driving, winding mountain roads, etc.).

[0011] The Automotive Safety Integrity Level (ASIL) is a risk classification framework defined by ISO 26262 (Functional Safety Standard for Automotive), typically established for the E / E components of a vehicle by conducting a risk analysis of potential hazards. This analysis includes determining the severity (i.e., the degree of injury that the hazard is expected to cause, classified from S0 (no injury) to S3 (life-threatening injury)), the frequency (i.e., the relative expected frequency of operating conditions under which injury may occur, classified from E0 (very unlikely) to E4 (high probability of injury under most operating conditions)), and the avoidability (i.e., the relative likelihood that the driver can act to avoid injury, classified from C0 (generally avoidable) to C3 (difficult or impossible to avoid)). Therefore, any safety objective for any potential hazard event includes a set of ASIL requirements.

[0012] Hazards identified as quality management (QM) do not indicate safety requirements. These QM hazards may be any combination of low frequency of occurrence, low severity of potential injury resulting from the hazard, and high likelihood of avoidance by the driver in preventing the hazard and / or injury. Other hazard events are classified as ASIL-A, ASIL-B, ASIL-C, or ASIL-D depending on the varying levels of severity, frequency, and avoidability corresponding to the potential hazard. ASIL-D events correspond to the highest safety requirements (ASIL requirements) for safety systems or E / E components of safety systems, while ASIL-A includes the lowest integrity requirements. For example, vehicle airbags, anti-lock brakes, and power steering systems typically have an ASIL-D grade, and the risks associated with failure of these components (e.g., the likely severity of injury and lack of vehicle controllability to prevent those injuries) are relatively high.

[0013] As described herein, ASIL relates to both risk and risk-dependent requirements, and various combinations of severity, frequency, and avoidability are quantified to form a representation of the risk (for example, a vehicle airbag system may have a relatively low frequency classification but high values ​​for severity and avoidability). As stated above, the amounts of severity, frequency, and avoidability of a given hazard have traditionally been determined using values ​​for severity (e.g., S0-S3), frequency (e.g., E0-E4), and avoidability (e.g., C0-C3) in the ISO 26262 series, and these values ​​are then used to classify ASIL requirements for components of a particular safety system. As described herein, certain safety systems can implement a variety of mitigation measures, which may range from warnings (e.g., visual, auditory, or tactile warnings) to mild interventions (e.g., brake assistance or steering assistance), severe interventions and / or evasive maneuvers (e.g., taking over control of one or more control mechanisms such as the steering system, acceleration system, or braking system), and fully autonomous control of the vehicle.

[0014] Current fully autonomous driving systems may feature non-deterministic reasoning models in which the system performs one or more perception, object detection, object classification, motion prediction, motion planning, and vehicle control techniques based on, for example, two-dimensional image data, to perform all autonomous driving tasks. In such implementations, it is anticipated that certifying the entire autonomous driving system and assigning an ASIL rating may be difficult or impossible. To address these shortcomings in current implementations, this specification describes an autonomous driving system capable of performing deterministic recursive reasoning operations for a particular hardware configuration, which enables certification and ASIL grading of various components, software configurations of the system, and / or the autonomous driving system itself.

[0015] As illustrated in the examples described herein, the use of a dual SoC configuration in which each SoC in a pair alternates between primary and backup roles can facilitate overall certification and ASIL grading of a vehicle's autonomous driving system. In this configuration, the first and second SoCs utilize isolated power supplies and can be electrically coupled to each other via electronic fuses (e.g., active circuit protection devices having integrated field-effect transistors (FETs) used to limit current and voltage to safe levels during fault conditions), thereby further enhancing the ASIL grading of the configuration. The SoCs may have direct memory access to each other (e.g., via the functional safety components of each SoC), which can facilitate dynamic health monitoring, error checking, and seamless transitions between primary and backup statuses.

[0016] In certain implementations, a computing system can perform one or more of the functions described herein using a learning-based approach, such as by running an artificial neural network (e.g., a recurrent neural network, a convolutional neural network, etc.) or one or more machine learning models. Such learning-based approaches can further be adapted to computing systems that store or include one or more machine learning models. In one embodiment, the machine learning models may include unsupervised learning models. In one embodiment, the machine learning models may include neural networks (e.g., deep neural networks) or other types of machine learning models, including nonlinear and / or linear models. The neural networks may include feedforward neural networks, recurrent neural networks (e.g., long-short-term memory recurrent neural networks), convolutional neural networks, or other forms of neural networks. Some exemplary machine learning models may leverage attentional mechanisms such as self-attention. For example, some exemplary machine learning models may include multi-head self-attention models (e.g., transformer models).

[0017] As described herein, “Network” or “one or more networks” may include any type of network or combination of networks that enable communication between devices. In one embodiment, the network may include one or more of the following: a local area network, a wide area network, the Internet, a secure network, a cellular network, a mesh network, a peer-to-peer communication link, or a combination thereof, and may include any number of wired or wireless links. Communication over the network(s) may be achieved via a network interface, for example, using any type of protocol, protection scheme, encoding, format, packaging, etc.

[0018] As further described herein, an “autonomous map” or “autonomous driving map” includes a ground truth map recorded by a mapping vehicle using various sensors (e.g., LiDAR sensors and / or a set of cameras or other imaging devices) and labeled to indicate traffic and / or right-of-way rules at a given location. For example, a given autonomous map may be labeled by a human based on observed traffic signs, traffic signals, and lane markings within the ground truth map. In a further example, reference points or other points of interest may be further labeled on the autonomous map for additional assistance to the autonomous vehicle. The autonomous vehicle or autonomous driving vehicle can then utilize the labeled autonomous map to perform various operations required for localization, attitude determination, change detection, and other operations necessary for autonomous driving on public roads. For example, the autonomous vehicle may refer to the autonomous map to determine traffic rules (e.g., speed limits) at the vehicle’s current location and may dynamically compare live sensor data from its onboard sensor suite with the corresponding autonomous map to safely navigate along the current route.

[0019] Among other advantages, the examples described herein achieve technical benefits such as providing redundancy and functional safety monitoring for MSoCs to improve the safety integrity level of autonomous vehicle computing systems.

[0020] One or more examples described herein provide that methods, techniques, and operations performed by a computing device are performed by a program or as a computer implementation. “By a program,” as used herein, means through the use of code or computer executable instructions. These instructions may be stored in one or more memory resources of the computing device. Steps performed by a program may be automatic or not.

[0021] One or more examples described herein can be implemented using a programmatic module, engine, or component. A programmatic module, engine, or component may include a program, a subroutine, a portion of a program, or a software or hardware component capable of performing one or more defined tasks or functions. Where used herein, a module or component may reside on a hardware component independent of other modules or components. Alternatively, a module or component may be a shared element or shared process of other modules, programs, or machines.

[0022] Some examples described in this specification can generally require the use of computing devices including processing resources and memory resources. For example, one or more examples described in this specification may be implemented wholly or partially using network equipment (e.g., a router) in a computing device such as a server and / or a personal computer. Memory resources, processing resources, and network resources may be used in connection with establishing, using, or implementing any of the examples described herein (including implementing any method or implementing any system).

[0023] Furthermore, one or more examples described in this specification may be implemented via the use of instructions executable by one or more processors. These instructions may be carried (stored) on a non-transitory computer-readable medium. Machinery shown in or described with reference to the various figures below provides examples of processing resources and computer-readable media capable of carrying and / or executing instructions for implementing the examples disclosed herein. In particular, numerous machines shown in connection with examples of the present invention include a processor and various forms of memory for holding data and instructions. Examples of non-transitory computer-readable media include persistent memory storage devices such as hard drives in personal computers or servers. Other examples of computer storage media include portable storage units such as flash memory or magnetic memory. All computers, terminals, and network-enabled devices are examples of machines and devices that utilize instructions stored in processors, memory, and computer-readable media. In addition, examples may be implemented in the form of a computer program, or in the form of a computer-usable carrier medium capable of carrying such a program.

[0024] Example Computing System Figure 1 is a block diagram showing an example computing system 100 in which embodiments described herein may be implemented, according to examples described herein. In one embodiment, the computing system 100 may include one or more control circuits 110, which may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuits (PLCs), or programmable logic / gate arrays (PLAs / PGAs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), system-on-a-chip (SoCs), or any other control circuits. In some implementations, the control circuits 110 and / or the computing system 100 may be part of or form part of a vehicle control unit (also called a vehicle controller) that is embedded in or otherwise located in a vehicle (e.g., a Mercedes-Benz® car, truck, or van). For example, the vehicle controller may be an infotainment system controller (e.g., an infotainment head unit), a telematics control unit (TCU), an electronic control unit (ECU), a central powertrain controller (CPC), a central exterior and interior controller (CEIC), a zone controller, an autonomous vehicle control system, or any other controller (the term "or" is used herein interchangeably with "and / or"), or may include such controllers.

[0025] In one embodiment, the control circuit 110 may be programmed by one or more computer-readable instructions or computer-executable instructions stored in the non-transitory computer-readable medium 120. The non-transitory computer-readable medium 120 may be a memory device, also referred to as a data storage device, and the memory device may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-transitory computer-readable medium 120 may form, for example, a floppy disk, a hard disk drive (HDD), a solid state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), and / or a memory stick. In some cases, the non-transitory computer-readable medium 120 may store computer-executable instructions or computer-readable instructions, such as instructions for performing the methods described below with reference to FIGS. 5 and 6.

[0026] In various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable instructions or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 110 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks on which the control circuit 110 or other hardware components execute the module or computer-readable instructions.

[0027] In further embodiments, the computing system 100 may include a communication interface 140 that enables communication over one or more networks 150 to send and receive data. In various examples, the computing system 100 can use the communication interface 140 to communicate with fleet vehicles over one or more networks 150 to receive sensor data and perform intersection classification as described throughout this disclosure. In certain embodiments, the communication interface 140 may be used to communicate with one or more other systems. The communication interface 140 may include any circuitry, components, software, etc., for communicating over one or more networks 150 (e.g., local area networks, wide area networks, the Internet, secure networks, cellular networks, mesh networks, and / or peer-to-peer communication links). In some implementations, the communication interface 140 may include, for example, one or more of the following for communicating data / information: communication controllers, receivers, transceivers, transmitters, ports, conductors, software, and / or hardware.

[0028] As an example of one embodiment, the control circuit 110 of the computing system 100 may include a dual SoC arrangement that facilitates the various methods and techniques described throughout this disclosure. In various examples, the SoC may perform a set of tasks in a primary SoC and backup SoC arrangement, where the primary SoC performs the set of tasks and the backup SoC maintains a standby state and monitors the status and / or state of the primary SoC. In various implementations, the set of tasks may include a set of autonomous driving tasks, such as perception, object detection and classification, grid occupancy determination, sensor data fusion and processing, motion prediction (e.g., of dynamic external entities), motion planning, and vehicle control tasks, for autonomously operating a vehicle along a route. Multiple dual SoC arrangements may be implemented to perform these tasks as described herein, each SoC pair configured in a manner described in detail below.

[0029] System Description Figure 2 is a block diagram showing an example computing system 200 implementing multiple systems-on-a-chip (MSoC) according to the examples described herein. In various examples, the computing system 200 may include a first SoC 210 having a first memory 215 and a second SoC 220 having a second memory 225, connected by an interconnection 240 (e.g., an ASIL-D evaluation interconnection), which allows each of the first SoC 210 and the second SoC 220 to read each other's memories 215 and 225. During a given session, the first SoC 210 and the second SoC 220 can alternately switch roles as primary and backup SoCs. As described herein, the primary SoC can perform various autonomous driving tasks such as perception, object detection and classification, grid occupancy determination, sensor data fusion and processing, motion prediction (e.g., of dynamic external entities), motion planning, and vehicle control tasks. The backup SoC maintains a set of computing components (e.g., CPU, ML accelerator, and / or memory chiplets) in a low-power state and can continuously or periodically read from the primary SoC's memory.

[0030] For example, if the first SoC210 is the primary SoC and the second SoC220 is the backup SoC, the first SoC210 executes a set of autonomous driving tasks and exposes state information corresponding to these tasks to the first memory 215. The second SoC220 reads the exposed state information from the first memory 215 and continuously checks whether the first SoC210 is operating within nominal thresholds (e.g., temperature threshold, bandwidth and / or memory threshold) and whether the first SoC210 is properly performing the set of autonomous driving tasks. Thus, the second SoC220 performs health monitoring and error management tasks for the first SoC210 and takes over control of the set of autonomous driving tasks when trigger conditions are met. As described herein, trigger conditions may correspond to failures, malfunctions, or other errors suffered by the first SoC210 that may affect the performance of the set of tasks performed by the first SoC210.

[0031] In various implementations, the second SoC220 may expose state information corresponding to the fact that the computing components are being kept in a standby state (for example, a low-power state in which the second SoC220 maintains preparation for taking over a set of tasks from the first SoC210). In such examples, the first SoC210 may also perform health check monitoring and error management for the second SoC220 by continuously or periodically reading the second SoC220's memory 225 to monitor the second SoC220's state information. For example, if the first SoC210 detects a fault, failure, or other error in the second SoC220, the first SoC210 may trigger the second SoC220 to perform a system reset or reboot.

[0032] In certain examples, the first SoC210 and the second SoC220 may each include a functional safety (FuSa) component that performs health monitoring and error management tasks. The FuSa component can be kept powered on for each SoC, regardless of whether the SoC operates in primary or backup mode. Thus, the backup SoC may keep other components in a low-power state while the FuSa component is powered up and performing the health monitoring and error management tasks described herein.

[0033] In various embodiments, when the first SoC210 operates as a primary SoC, the state information exposed in the first memory 215 may correspond to a set of tasks performed by the first SoC210. ​​For example, the first SoC210 may expose any information corresponding to the vehicle's surrounding environment (e.g., external entities identified by the first SoC210, their locations and predicted trajectories, and detected objects such as traffic signals, signs, lane markings, and crosswalks). The state information may further include the operating temperature of the computing components of the first SoC210, the bandwidth usage and available memory of the chiplets of the first SoC210, and / or faults or errors in these components, or information indicating faults or errors.

[0034] In a further embodiment, when the second SoC220 operates as a backup SoC, the state information exposed in the second memory 225 may correspond to the state of each computing component of the second SoC220. In particular, these components may operate in a low-power state in which they are ready to take over the set of tasks being performed by the first SoC210. ​​The state information may include whether the components are operating within a nominal temperature and other nominal ranges (e.g., available bandwidth, power, memory, etc.).

[0035] As described throughout this disclosure, the first SoC210 and the second SoC220 can switch between operating as primary SoCs and backup SoCs (for example, each time the system 200 is rebooted). For example, in a computing session following a session in which the first SoC210 operated as the primary SoC and the second SoC220 operated as the backup SoC, the second SoC220 may assume the role of the primary SoC and the first SoC210 may assume the role of the backup SoC. This process of switching roles between the two SoCs is intended to cause the hardware components of each SoC to degrade substantially evenly, thereby extending the overall lifespan of the computing system 200.

[0036] According to the embodiment, the first SoC 210 may be powered by a first power supply 205, and the second SoC 220 may be powered by a second power supply 235 that is independent of or isolated from the first power supply 205. For example, in an electric vehicle, the first power supply 205 may comprise a battery pack used to propel the vehicle's electric motor, and the second power supply 235 may comprise an auxiliary power supply for the vehicle (e.g., a 12-volt battery). In other implementations, the first power supply 205 and the second power supply 235 may comprise other types of power supplies, such as dedicated batteries for each SoC 210, 220, or other power supplies that are electrically isolated from each other or otherwise independent of each other.

[0037] In various implementations, the first SoC210 and the second SoC220 may be electrically "insulated" from each other via a set of one or more electronic fuses 232, 234, which can be triggered, for example, when a power surge occurs within the system 200. Electronic fuses 232 and 234 may include physical fuses (e.g., micro-fuse places in a computer chip), logical fuses consisting of computer programs that trip when current and / or voltage exceed specified thresholds, or a combination of physical and logical fuses. In one example scenario, if SoC220 is subjected to a power surge, electronic fuse 234 will trip to prevent the same power surge from affecting SoC210. ​​Conversely, if SoC210 is subjected to a power surge, electronic fuse 232 will trip to prevent the same power surge from affecting SoC220. Therefore, in the event of a power surge, at least one of the SoCs will remain operational (and, for example, operate as the primary SoC), while the SoC that was affected by the power surge may reboot or reset and / or operate as the backup SoC.

[0038] The aim is to improve the safety integrity level (e.g., ASIL rating) of the computing system 200 and the overall autonomous driving system of the vehicle by providing an MSoC configuration of the computing system 200. As described herein, the autonomous driving system may include any number of dual SoC configurations, each capable of performing a set of autonomous driving tasks. In this configuration, the backup SoC dynamically monitors the health of the primary SoC according to a set of functional safety operations, so that when a failure, malfunction, or other error is detected, the backup SoC can immediately power up its components and take over the set of tasks from the primary SoC. A further description of the SoCs and their computing components is provided below with reference to Figure 3.

[0039] System-on-a-chip example Figure 3 is a block diagram showing an example of an SoC300 according to the examples described herein. The SoC300 may comprise either a first SoC210 or a second SoC220, as illustrated and described in relation to Figure 2. Furthermore, the system-on-chip example 300 shown in Figure 3 may include additional components, and the components of the system-on-chip 300 may be arranged in various alternative configurations other than those shown. Accordingly, the system-on-chip 300 in Figure 3 is described herein as an example arrangement for illustrative purposes and is not intended to limit the scope of this disclosure in any way.

[0040] Referring to Figure 3, the sensor data input chiplet 310 of the system-on-chip 300 can receive sensor data from various vehicle sensors 305 of the vehicle. These vehicle sensors 305 may include any combination of image sensors (e.g., single camera, binocular camera, fisheye lens camera, etc.), LIDAR sensors, radar sensors, ultrasonic sensors, proximity sensors, etc. The sensor data input chiplet 310 may automatically dump the sensor data when the received sensor data is received in the cache memory 331 of the central chiplet 320. The sensor data input chiplet 310 may also include an image signal processor (ISP) responsible for capturing, processing, and improving images acquired from the various vehicle sensors 305. The ISP acquires raw image data and performs a series of complex image processing operations such as color, contrast, and brightness correction, noise reduction, and image enhancement to produce higher quality images ready for further processing or analysis by other chiplets of the SoC 300. The ISP may also include features such as autofocus, image stabilization, and advanced scene recognition to further improve the quality of the captured images. The ISP may then store its high-quality images in the cache memory 331.

[0041] In some embodiments, the sensor data input chiplet 310 exposes identification information for each item of sensor data (e.g., image, point cloud map, etc.) to the shared memory 330 of the central chiplet 320, which functions as a central mailbox for synchronizing the workloads of various chiplets. The identification information may include details such as the address where the data is stored in the cache memory 331, the type of sensor data, which sensor captured the data, and the timestamp when the data was captured.

[0042] To communicate with the central chiplet 320, the sensor data input chiplet 310 transmits data through interconnect 311a. Interconnections 311a to 311f each represent a die-to-die (D2D) interface between chiplets of the SoC 300. In some embodiments, the interconnect includes a high-bandwidth data path used for general data to the cache memory 331 and a high-reliability data path for transmitting functional safety and scheduler information to the shared memory 330. Depending on bandwidth requirements, the interconnect may include two or more die-to-die interfaces. For example, interconnect 311a may include two interfaces to support relatively high-bandwidth communication between the sensor data input chiplet 310 and the central chiplet 320.

[0043] In one embodiment, interconnects 311a-f implement the Universal Chiplet Interconnect Express (UCIe) standard and communicate via indirect mode, allowing each of the chiplet's host processors to access remote memory as if it were local memory. This is achieved by using a dedicated Network on Chip (NoC) Network Interface Unit (NIU) that provides hardware-level support for remote direct memory access (RDMA) operation (enabling interference freedom between network-connected devices). In UCIe indirect mode, the host processor sends a request to the NIU, which then accesses the remote memory and returns the data to the host processor. This approach enables efficient, low-latency access to remote memory, which can be particularly useful in distributed computing and data-intensive applications. Furthermore, UCIe indirect mode can be used with a wide range of different network topologies and protocols, providing a high degree of flexibility.

[0044] In various examples, the system-on-chip 300 may include additional chiplets capable of storing, modifying, or otherwise processing sensor data cached by the sensor data input chiplet 310. The system-on-chip 300 may also include an autonomous driving chiplet 340 capable of performing autonomous vehicle perception, sensor fusion, trajectory prediction, and / or other autonomous driving algorithms. The autonomous driving chiplet 340 may be connected to a dedicated HBM-RAM chiplet 335, to which the autonomous driving chiplet 340 may expose all status information, variables, statistics, and / or processed sensor data processed by the autonomous driving chiplet 340.

[0045] In various applications, the System-on-Chip 300 is a machine learning (ML) accelerator chiplet specifically designed to accelerate AI workloads such as image inference or other sensor inference using machine learning, achieving high performance and low power consumption. 350 This may further include: ML accelerator chiplet 350 This may include an engine designed to efficiently handle graph-based data structures commonly used in AI workloads, and highly parallel processors that enable efficient processing of large amounts of data. ML Accelerator Chiplets 350 This may also include dedicated hardware accelerators for common AI operations such as matrix multiplication and convolution, as well as memory hierarchies designed to optimize memory access for AI workloads that often have complex memory access patterns.

[0046] The general-purpose computing chiplet 345 may provide general-purpose computing for the system-on-chip 300. For example, the general-purpose computing chiplet 345 may include a high-power central processing unit and / or a graphical processing unit, which may support the computing tasks of the central chiplet 320, the autonomous driving chiplet 340, and / or the ML accelerator chiplet 350.

[0047] In various implementations, the shared memory 330 can store programs and instructions for performing autonomous driving tasks. The shared memory 330 of the central chiplet 320 may further include a reservation table that provides various chiplets with the information necessary to perform individual tasks (e.g., sensor data items and their locations in memory). A further description of the shared memory 330 in the context of the dual SoC configuration described herein is provided below with reference to Figure 4. The central chiplet 320 also includes a large cache memory 331 that supports invalidation and flashing of stored data.

[0048] Cache misses and evicting from the cache memory 331 are transmitted by a high-bandwidth memory (HBM) RAM chiplet 355 connected to the central chiplet 320. The HBM-RAM chiplet 355 may contain status information, variables, statistics, and / or sensor data for all other chiplets. In a particular example, the information stored in the HBM-RAM chiplet 355 may be stored for a predetermined period (e.g., 10 seconds), after which the data is deleted or flushed separately. For example, if an autonomous vehicle experiences a failure, the information stored in the HBM-RAM chiplet 355 may contain all the information necessary to diagnose and resolve the failure. The cache memory 331 holds new data that is available with lower latency and lower power consumption compared to accessing data from the HBM-RAM chiplet 355.

[0049] In various implementations, the shared memory 330 may contain programs and instructions for performing autonomous driving tasks. The shared memory 330 of the central chiplet 320 may further include a reservation table that provides various chiplets with the information necessary to perform individual tasks (e.g., sensor data items and their locations in memory). A further explanation of the shared memory 330 in the context of the dual SoC configuration described herein is provided below with reference to Figure 4.

[0050] Figure 4 is a block diagram showing an example of a central chiplet 402 of an SoC 400, including a shared memory 405 for performing replication status and shadowing for multiple SoCs, according to the examples described herein. The central chiplet 402 shown in Figure 4 may correspond to the central chiplet 320 of the SoC 300 shown and described with respect to Figure 3. Furthermore, an additional chiplet 450 shown with respect to Figure 4 may correspond to one or more of the sensor data input chiplet 310, autonomous driving chiplet 340, general-purpose computing chiplet 345, or ML accelerator chiplet 350 in Figure 3.

[0051] Referring to Figure 4, the central chiplet 402 of the primary SoC 400 may include a shared memory 405 that stores state information 410 exposed by the set of processors 430 of the central chiplet 402 and other chiplets 450 of the SoC 400. In various examples, the set of processors 430 and the additional chiplets 450 execute a set of tasks (e.g., autonomous driving tasks) and expose the state information 410 corresponding to those tasks into the shared memory 405 of the central chiplet 402. Additionally or alternatively, the set of processors 430 and the additional chiplets 450 may expose the state information 410 corresponding to the set of tasks into the cache 404 of the central chiplet. As described herein, the state information 410 may include any information necessary for the backup SoC 460 to take over the set of tasks. This may include statistical information corresponding to the vehicle's surrounding environment (e.g., the last (most recent, latest) image from the camera, the last data set from other sensors, classified objects, their locations, vehicle positioning information, etc.) as well as performance data of the primary SoC400's hardware components (e.g., bandwidth, temperature, memory information). The backup SoC460 may access the central chiplet 402's shared memory 405 and cache 404 to obtain state information 410 and the data set necessary to seamlessly take over autonomous driving tasks from the primary SoC400. In a further example, the backup SoC460 may include a sensor data input chiplet that has direct data access to the vehicle's sensor system. When the backup SoC460 takes over the primary role from the SoC400, the sensor data input chiplet is activated to acquire real-time sensor data from the vehicle sensors and continue autonomous driving operations.

[0052] In various examples, shared memory 405 may include a FuSa program 420 that performs health monitoring and error management operations for the primary SoC 40 and the backup SoC 460. Similarly, the backup SoC 460 may also include a set of chiplets and a central chiplet having shared memory (or cache) from which the components of the backup SoC 460 expose state information. The central chiplet of the backup SoC 460 may further include a FuSa component to perform health monitoring and error management tasks for the backup SoC 460 and to have direct memory access to the state information 410 of the primary SoC 400. In certain examples, the FuSa component may include a dedicated FuSa processor 435 that executes the FuSa program 420 and performs the health monitoring and error management functions described throughout this disclosure.

[0053] In various implementations, the FuSa program 420 of the primary SoC400 may access the shared memory of the backup SoC460 to dynamically read the state information of the backup SoC460. In further implementations, the FuSa program of the backup SoC460 may access and dynamically read the state information 410 in the shared memory 405 of the primary SoC400. When a trigger event (e.g., failure or malfunction) occurs, and this is detected by the FuSa program of the backup SoC460 in the state information 410, the backup SoC460 can take over the set of tasks being performed by the primary SoC400. The SoC400 may then reboot or reset the faulty component, or it may reboot or reset the SoC400 itself, and the backup SoC 460 To take on the role.

[0054] In this case, SoC400 can power down the processor 430 of chiplet 450 and / or central chiplet 402, while FuSa processor 435 can maintain a powered-up state to execute FuSa program 420 and monitor state information exposed to its own shared memory or cache by SoC460. Therefore, in an application example of autonomous driving, when a trigger event in the state information 410 is detected by the backup SoC460, the autonomous driving task previously performed by the primary SoC400 can be seamlessly transferred to the backup SoC460.

[0055] In further embodiments, each time the SoCs 400 and 460 are rebooted, they may switch between the roles of primary and backup SoCs to ensure that the hardware components of each SoC 400 and 460 degrade substantially evenly. The configurations shown with respect to Figures 2, 3, and 4 are intended to provide redundancy to increase the lifespan of the SoCs and increase reliability when performing a set of tasks, and thus enhance the safety rating (e.g., ASIL rating) for the SoC configuration and the autonomous driving system of the vehicle. Furthermore, an ASIL-D rating may be required for the autonomous driving system to operate on public roads, and the configurations and embodiments described throughout this disclosure are intended to advance the autonomous driving system in terms of safety and integrity to facilitate achieving this rating.

[0056] methodology Figures 5 and 6 are flowcharts illustrating a method for performing replication status and shadowing for multiple SoCs according to the examples described herein. In the following description of the method in Figures 5 and 6, reference symbols representing specific features described with respect to the system diagrams in Figures 1 and 4 may be referenced. Furthermore, the steps described with reference to the flowcharts in Figures 5 and 6 may be performed by computing systems 100, 200, and MSoC configurations illustrated and described with respect to Figures 1 to 4. Moreover, the specific steps described with reference to the flowcharts in Figures 5 and 6 may be performed before any of the other steps, simultaneously with any of the other steps, or after any of the other steps, and do not need to be performed in the respective illustrated order.

[0057] Referring to Figure 5, in block 500, a set of computational tasks is performed (executed) on the first SoC 210 in the MSoC configuration. In block 505, the first SoC 210 exposes state information corresponding to the set of tasks in the first SoC 210's memory 215. In some implementations, the set of tasks may include any computer tasks performed by the primary SoC 210 in a dual SoC configuration, such as application-based tasks, enterprise software tasks, or computer security tasks. According to the examples described herein, the set of tasks may include a set of autonomous driving tasks for autonomous or semi-autonomous vehicles. These tasks may include sensor data processing tasks such as perception, reasoning, object detection and / or classification, traffic priority determination, grid occupancy determination, motion prediction, motion planning, and / or vehicle control tasks for autonomous vehicles.

[0058] In block 510, the second SoC 220 in a dual SoC configuration continuously reads the memory 215 of the first SoC 210 to determine the state of the first SoC 210. In block 515, the second SoC 220 may further maintain several computing components in a low-power state. As described herein, several computing components may include various chiplets necessary to perform the set of tasks currently being performed by the first SoC 210. In Figure 3, these chiplets may correspond to one or more of the HBM-RAM chiplet 335, the autonomous driving chiplet 340, the general-purpose computing chiplet 345, the ML accelerator chiplet 350, and the HBM-RAM chiplet 355. In further implementations, certain components of the central chiplet 320 (e.g., one or more CPUs) may also be maintained in a low-power state. As described herein, the low-power state may include a standby state in which the chiplets are warmed up and ready to take over the set of tasks at any given time.

[0059] In block 520, the second SoC220 may detect triggers in the memory 215 of the first SoC210. ​​Triggers can respond to any fault, failure, or other error exposed in memory 215 by the first SoC210, or otherwise detected by the second SoC220 by monitoring the memory 215 of the first SoC210. ​​Such faults, failures, or errors may correspond to hardware failures or malfunctions in the first SoC210, exceeding temperature thresholds, software glitches, or other software failures. Upon detecting a trigger, in block 525, the second SoC220 may power up multiple computing components and take over the set of tasks from the first SoC210.

[0060] Figure 6 is a flowchart illustrating further methods for implementing replication status and shadowing for a dual SoC configuration by the examples described herein. In the following description of Figure 6, SoC300, SoC400, and SoC460 may be referred to as the primary or backup SoC in a dual SoC configuration. Referring to Figure 6, in block 600, the first SoC400 may receive sensor data from a set of vehicle sensors 305. In block 605, the first SoC400 may perform (execute) a set of autonomous driving tasks based on its sensor data. For example, the first SoC400 may include a set of chiplets, as shown in Figure 3, each of which performs one or more autonomous driving tasks, including one or more perception, reasoning, object detection and / or classification, traffic priority determination, occupancy grid determination, motion prediction, motion planning, and / or vehicle control tasks for an autonomous vehicle. In a particular example, the autonomous driving tasks may include sensor data perception and reasoning tasks for autonomously operating the vehicle along a driving route. In block 610, the first SoC400 may further expose state information 410 within the shared memory 405 of the first SoC400.

[0061] It is intended that any multiple SoC configuration can be used to implement the replication status and shadowing techniques described herein. For example, a configuration of three SoCs can be used in a primary, secondary, and tertiary configuration (or a primary SoC and two secondary SoCs), where each SoC has direct memory access to the other SoCs to monitor their status information. In such a configuration, if the primary SoC suffers a failure, malfunction, or error, a secondary SoC may take over autonomous tasks as the primary SoC, and a tertiary SoC may become a secondary SoC. This sequential status change of SoCs in a multiple SoC configuration can be applied to any number of SoCs (e.g., four or more). In a modified example, the secondary and tertiary SoCs (or both secondary SoCs) may implement a voting system to take over autonomous tasks from the primary SoC (e.g., based on hardware degradation). In such a voting system implementation, any number of SoCs can be deployed in any multiple SoC configuration.

[0062] In block 615, the first SoC400 can further continuously read state information of the second SoC460. For example, the state information of the second SoC460 may indicate the operating parameters of various computing components (e.g., chiplets) of the second SoC460 in a low-power state, and further indicate whether these components are operating within those parameters (e.g., whether the components are warmed up and ready to take over a set of autonomous driving tasks). In determination block 620, the first SoC300 can dynamically determine whether a trigger has been detected in the state information of the second SoC460. As described herein, a trigger may correspond to any component of the second SoC460 operating outside of its nominal parameters, or to a failure, malfunction, or error experienced by the second SoC460. If no trigger is detected, the first SoC400 can continue to monitor the state information of the second SoC460. However, if a trigger is detected at any point, in block 625, the first SoC400 may, for example, send a command to the second SoC460 to cause the second SoC460 to perform a system reboot. As described herein, information communicated between the SoC400 and SoC460 may be transmitted via a robust ASIL-D rated interconnect (e.g., interconnect 240 shown in Figure 2) using error correction code (ECC) that provides algorithmic redundancy (e.g., through the use of block code, convolutional code, etc.).

[0063] In block 630, the second SoC460 may maintain several computing components in a low-power state. As described above, these components may include one or more of the chiplets illustrated and described with respect to Figure 3. In block 635, the second SoC460 may continuously read the state information 410 exposed by the first SoC400. In determination block 640, the second SoC460 may determine whether a trigger has been detected in the state information 410. As described herein, a trigger may correspond to the first SoC400 suffering a fault or failure, and such fault or failure may correspond to the first SoC400 suffering performance degradation such as overheating, power surge, or error. If no trigger is detected, the second SoC460 may continue to monitor the state information 410 of the first SoC400. However, if a trigger is detected at some point, in block 645, the second SoC460 can power up its computing components and take over the set of autonomous driving tasks from the first SoC400, while the first SoC400 powers down its components and takes on the role of a backup SoC.

[0064] In block 650, the second SoC 460 may continue reading the status information 410 of the first SoC 400. In determination block 660, the second SoC 460 may determine whether the first SoC 400 remains degraded. If so, in block 665, the second SoC 460 may initiate a set of mitigation or emergency (relief) measures. In certain embodiments, these measures may include reducing the vehicle's speed, notifying any occupant in the vehicle (e.g., to take over manual control of the vehicle), autonomously moving the vehicle to a safe location (e.g., stopping the vehicle or driving it to a home position), and / or autonomously moving the vehicle to a service center to resolve the degraded status of the first SoC 400.

[0065] In some examples, at block 670, the second SoC460 may further send a command to the first SoC400 to perform a system reboot. 675 The first SoC400 can then perform backup SoC tasks, such as maintaining a subset of components in a low-power state and dynamically monitoring state information exposed by the primary SoC460. If the primary and secondary SoCs are unable to communicate at any point (for example, if one of the SoCs fails to boot up), the vehicle's autonomous driving system will cease to function. This configuration is intended to provide the redundancy necessary to improve the ASIL rating of the vehicle's autonomous driving system (for example, contributing to an ASIL-D rating).

[0066] In various scenarios, each time the MSoC configuration reboots, the first SoC400 and the second SoC460 can switch between primary and backup roles, ensuring that the MSoC configuration elements, such as various chiplets in each SoC, degrade substantially evenly. Furthermore, the SoCs may be electrically coupled via one or more electronic fuses that protect them from each other (e.g., from voltage or current surges). Along these lines, the first SoC400 and the second SoC460 may be powered by separate power sources, such as a battery pack used for vehicle propulsion and an auxiliary power supply in the vehicle used to power auxiliary components (e.g., ECU, lights, radio, etc.).

[0067] As described herein, the state information monitoring and error management functions performed by the first and second SoCs 400 and 460 may be performed by the functional safety components of each SoC (e.g., FuSa program 420 and FuSa processor 435), as shown in Figure 4. As further provided herein, in the backup SoC, the FuSa components remain powered up to perform functional safety tasks, while the other components are kept in a low-power state and ready to take over primary SoC tasks. The first SoC 400 and second SoC 460, arranged to dynamically read state information and take over the set of tasks of the primary SoC, are intended to provide redundancy that facilitates safety integrity level assessment for autonomous driving computing systems (e.g., achieving an ASIL-D rating).

[0068] It is intended that the examples described herein be extended to the individual elements and concepts described herein, independently of other concepts, ideas, or systems, and that combinations of elements described in any part of this application be included as examples. While examples are described in detail herein with reference to the accompanying drawings, it should be understood that the concepts are not limited to those exact examples. Therefore, many modifications and variations will be apparent to those skilled in the art. Accordingly, the scope of the concepts is intended to be defined by the following claims and their equivalents. Furthermore, specific features described individually or as part of an example are intended to be combined with other features or parts of other examples described individually, even if other features and examples do not refer to those specific features.

Claims

1. A computing system, A first system-on-a-chip (SoC) comprising a first memory and a first plurality of computing components, wherein the first SoC exposes state information corresponding to a set of tasks being executed by the first SoC into the first memory, A second SoC comprising a second memory and a second plurality of computing components, the second SoC having memory access to the first memory of the first SoC to dynamically read the state information exposed by the first SoC, and maintaining a subset of the second plurality of computing components in a low-power state, If the second SoC detects a trigger in the state information while reading the state information exposed in the first memory of the first SoC, the second SoC powers up the subset of the second plurality of computing components to take over the set of tasks. Each time the computing system is rebooted, the first SoC and the second SoC switch between (i) the role of executing the set of tasks and (ii) the role of placing a subset of their respective computing components into the low-power state and dynamically reading the exposed state information from the first SoC or the second SoC. Computing system.

2. The aforementioned set of tasks includes autonomous driving tasks. The computing system according to claim 1.

3. The trigger corresponds to the first SoC suffering a failure or malfunction, and the failure or malfunction corresponds to overheating, power surge, or error in the first SoC. The computing system according to claim 1.

4. The first SoC is powered by the vehicle's first power supply, and the second SoC is powered by the vehicle's second power supply. The computing system according to claim 1.

5. The first SoC and the second SoC are electrically coupled to each other via an interconnection having at least one electrical safety switch in order to protect the computing system from power surges from either the first SoC or the second SoC. The computing system according to claim 1.

6. The first SoC dynamically reads the second memory of the second SoC and determines whether the second SoC is ready to take over the set of tasks being performed by the first SoC. The computing system according to claim 1.

7. The first and second SoCs, which are arranged to dynamically read the state information and take over the set of tasks, provide redundancy that facilitates the evaluation of the Automotive Safety Integrity Level (ASIL) of the computing system. The computing system according to claim 1.

8. The first and second sets of computing components each include chiplets of the first SoC and the second SoC, The computing system according to claim 1.

9. A first system-on-a-chip (SoC) comprising a first memory and a first plurality of computing components, wherein the first SoC exposes state information corresponding to a set of tasks being performed by the first SoC into the first memory, and the state information includes statistical information corresponding to the surrounding environment of a vehicle in which the computing system resides, and the first SoC A second SoC comprising a second memory and a second plurality of computing components, the second SoC having memory access to the first memory of the first SoC to dynamically read the state information exposed by the first SoC, and maintaining a subset of the second plurality of computing components in a low-power state, If the second SoC detects a trigger in the state information while reading the state information exposed in the first memory of the first SoC, the second SoC powers up the subset of the second plurality of computing components to take over the set of tasks. Computing system.

10. A computer implementation method, In a first system-on-a-chip (SoC) comprising a first memory and a first plurality of computing components, the state information corresponding to a set of tasks performed by the first SoC, including statistical information corresponding to the surrounding environment of the vehicle in which the computing system resides, is made public in the first memory. In a second SoC comprising a second memory and a second plurality of computing components, (i) accessing the first memory of the first SoC to dynamically read state information exposed by the first SoC while the second SoC is maintaining a subset of the second plurality of computing components in a low-power state; (ii) detecting a trigger in the state information while reading the state information exposed in the first memory of the first SoC; and (iii) in response to the detection of the trigger, energizing the subset of the second plurality of computing components to take over the set of tasks from the first SoC. Computer implementation method.

Images