Execution of workloads in deterministic pipelines

Abstract

The computing system includes a sensor data input chiplet for acquiring sensor data from a vehicle's sensor system, and one or more workload processing chiplets that execute workloads in a set of independent pipelines based on that sensor data.

Description

Background Art

[0001] Universal Chiplet Interconnect Express (UCIe) is an open standard for interconnection and serial bus between multiple chiplets that enables the manufacture of large-scale system-on-chip (SoC) packages with components from various semiconductor manufacturers. Autonomous vehicle computing systems may operate using a chiplet arrangement that complies with the UCIe standard. One goal in creating such computing systems is to achieve a robust safety integrity level (SIL) for other important electrical and electronic (E / E) automotive components of the vehicle.

Summary of the Invention

Means for Solving the Problems

[0002] A computing system can include a sensor data input chiplet for obtaining sensor data from a vehicle's sensor system and one or more workload processing chiplets that execute a workload within a set of independent pipelines based on the sensor data. In various implementations, the workload processing chiplets can execute multiple workloads in multiple independent pipelines to perform a set of tasks for autonomously operating the vehicle. The set of tasks can include any combination such as image stitching tasks, sensor fusion tasks, machine learning inference tasks, object detection tasks, object classification tasks, scene understanding tasks, motion prediction tasks, and the like.

[0003] In various embodiments, one or more workload processing chiplets can provide the output of a set of independent pipelines to an application program for autonomously operating a vehicle. In particular, the application program may also be executed by a workload processing chiplet to perform motion planning and / or vehicle control tasks based on an inferred sensor view of the vehicle's surrounding environment, and this inferred sensor view is output by a set of independent pipelines. For example, the independent pipelines can execute workloads in a deterministic manner based on the workload dependencies set by a scheduling program. The workload processing chiplet can monitor and update a reservation table that includes a cache address for the workload data to execute the target workload and a workload entry containing dependency information that should be resolved before executing the target workload.

[0004] In particular, a sensor data input chiplet can acquire sensor data and store that sensor data (e.g., image data, LiDAR data, radar data, ultrasonic data, etc.) in the computing system's cache memory. According to the examples described herein, a sensor data input chiplet can generate an identifier for the sensor data (e.g., an identifier for each image acquired from various cameras in a vehicle's sensor system) and indicate the address of the sensor data in the cache memory. The sensor data identifiers and addresses can be referenced in a reserved table, which includes workload identifiers, dependency information for each workload, and addresses of data required to perform a particular workload. The computing system may include a shared memory containing its reserved table, which can be referenced by the computing system's workload processing chiplets to perform workloads.

[0005] In various examples, a workload processing chiplet can execute workloads in a non-sequential workload manner. For example, when a workload is completed by a chiplet, dependency information for additional workloads in the reservation table may be updated to indicate this, and when the dependencies cease to exist, the additional workloads may become executable in the reservation table. In certain examples, a chiplet can monitor the reservation table by constructing a workload window and instruction pointers, in which case each entry in the reservation table is sequentially analyzed by the workload processing chiplet along the workload window. When a particular workload is ready to be executed (e.g., all dependencies have been resolved), the workload processing chiplet can execute the workload accordingly. Thus, the reservation table is implemented as a non-sequential buffer where workloads are held until all dependencies (e.g., other workloads) have been resolved. Therefore, a chiplet can perform non-sequential execution of workloads in a set of independent pipelines, which can be determined based on the deterministic nature of the pipelines. The disclosures herein are illustrative and not limiting, and in the figures of the accompanying drawings, similar reference numbers refer to similar elements. [Brief explanation of the drawing]

[0006] [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 system-on-a-chip (SoC) in which the examples described herein may be implemented. [Figure 3] This block diagram shows an example of a central chiplet in an SoC configuration for executing a workload in an independent deterministic pipeline, as illustrated in the examples described herein. [Figure 4A]This figure shows workloads running in a set of independent pipelines, as illustrated in the examples described herein. [Figure 4B] This figure shows a functional safety (FuSa) pipeline capable of operating to compare and verify the outputs of independent pipelines, as illustrated in the examples described herein. [Figure 5] This flowchart illustrates how to run workloads in independent pipelines, as shown in the examples provided herein. [Figure 6] This flowchart illustrates how to run workloads in independent pipelines, as shown in the examples provided herein. [Modes for carrying out the invention]

[0007] In certain autonomous vehicle implementations, the vehicle computing system processes sensor data (e.g., images, LiDAR data, etc.) as it becomes available in real time. In other words, these forms of autonomous vehicle implementations perform various perception, object detection and classification, scene understanding, motion prediction, and / or ML inference tasks on the sensor data in a non-deterministic manner. For example, an on-board computing system that implements a neural network to perform ML inference on two-dimensional image data would perform it sequentially for each image generated by the vehicle's cameras.

[0008] As illustrated by the examples described herein, a computing system can execute workloads for autonomous driving tasks in multiple independent deterministic pipelines. For example, the computing system may comprise a set of workload processing chiplets that execute workloads using dynamic scheduling in a deterministic pipeline, and a reservation table implemented in the computing system's shared memory. In various embodiments, the computing system may comprise a single-SoC or multiple-SoC configuration, each SoC comprising multiple chiplets for performing autonomous driving tasks. The SoC may include a central chiplet comprising shared memory and a reservation table into which information corresponding to workloads (e.g., workload entries) is input. The SoC may include a sensor data input chiplet that acquires sensor data from a vehicle sensor system, which may include any combination of cameras, LiDAR sensors, radar sensors, ultrasonic sensors, proximity sensors, etc.

[0009] Upon acquiring each item of sensor data (e.g., individual images, point clouds, radar pulses, etc.), the sensor data input chiplet can indicate that the sensor data is available in the reservation table, store the sensor data in a cache, and indicate the address of the sensor data in the cache. Through the execution of workloads according to a set of independent pipelines, a set of workload processing chiplets can monitor the reservation table for available workloads. As described herein, initial raw sensor data can be referenced in the reservation table and processed through the execution of an initial set of workloads by the workload processing chiplets. As an example, this initial processing may include stitching images together to create a 360° sensor view of the vehicle's surrounding environment, which allows the chiplets to perform additional workloads on the sensor view (e.g., object detection and classification tasks).

[0010] When a workload is completed by a chiplet, dependency information for additional workloads in the reservation table may be updated to reflect this, and once the dependencies are gone, the additional workloads may become executable in the reservation table. In certain examples, a chiplet can monitor the reservation table by constructing a workload window and instruction pointers, in which case each entry in the reservation table is sequentially analyzed along the workload window by the workload processing chiplet. If a particular workload is ready to run (e.g., all dependencies have been resolved), the workload processing chiplet can execute the workload accordingly.

[0011] The execution of workloads in a deterministic pipeline is intended to facilitate the verification and certification of autonomous driving systems (e.g., by road safety authorities). For example, a functional safety (FuSa) program operates to compare and verify the outputs of each pipeline to ensure consistency in ML inference operations and other situational understanding tasks.

[0012] In experimental and controlled test environments, system redundancy and Automotive Safety 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, certain 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.). The Automotive Safety 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.

[0013] 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.

[0014] 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.

[0015] Current fully autonomous driving systems can 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 expected that certifying the entire autonomous driving system and assigning an ASIL rating will be difficult or impossible. To address these shortcomings in current implementations, this specification describes an autonomous driving system capable of performing deterministic immediate reasoning operations for a specific hardware configuration, which will enable certification and ASIL grading of various components, software configurations of the system, and / or the autonomous driving system itself.

[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.

[0017] Such learning-based methods 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. Neural networks may include feedforward neural networks, recurrent neural networks (e.g., long-term-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).

[0018] 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.

[0019] One or more examples described herein provide that methods, techniques, and operations performed by a computing device are implemented by a program or performed as computer-implemented methods. As used herein, "by a program" means via the use of code or computer-executable instructions. These instructions can be stored in one or more memory resources of a computing device. Steps performed by a program may be automatic or not.

[0020] One or more examples described herein can be implemented using program-based modules, engines, or components. Program-based modules, engines, or components can include software components or hardware components that can perform a program, subroutine, part of a program, or one or more defined tasks or functions. As used herein, a module or component can exist on a hardware component independent of other modules or components. Alternatively, a module or component can be a shared element or shared process of other modules, programs, or machines.

[0021] Some examples described herein can generally require the use of a computing device that includes processing resources and memory resources. For example, one or more examples described herein may be implemented in whole or in part using network devices (e.g., routers) 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 the establishment, use, or performance of any example described herein (including the performance of any method or the implementation of any system).

[0022] Furthermore, one or more examples described herein may be implemented through the use of instructions executable by one or more processors. These instructions may be carried on non-temporary computer-readable media. The machines shown in or described using the following figures provide examples of processing resources and computer-readable media capable of carrying and / or executing instructions for implementing the examples disclosed herein. In particular, many of the machines shown with the examples of the present invention include processors and various forms of memory for holding data and instructions. Examples of non-temporary 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. Computers, terminals, and network-enabled devices are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable media. In addition, examples may be implemented in the form of computer programs or in the form of computer-usable carrier media capable of carrying such programs.

[0023] Examples of computing systems FIG. 1 is a block diagram showing an example of a computing system 100 in which embodiments described herein may be implemented according to an example described herein. In one embodiment, 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 arrays / gate arrays (PLAs / PGAs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), system on chips (SoCs), or any other control circuits. In some implementations, control circuit 110 and / or computing system 100 may be or form part of a vehicle control unit (also referred to as a vehicle controller) embedded in or otherwise disposed in a vehicle (e.g., a Mercedes-Benz® vehicle, 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 interchangeably herein with “and / or”), or may include them.

[0024] In one embodiment, the control circuit 110 may be programmed by one or more computer-readable instructions or computer-executable instructions stored in a non-temporary computer-readable medium 120. The non-temporary computer-readable medium 120 may be a memory device, also called a data storage device, and the memory device may include electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any preferred combination thereof. The non-temporary computer-readable medium 120 may, for example, form 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), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), and / or memory stick. In some cases, the non-temporary computer-readable medium 120 may store computer-executable instructions or computer-readable instructions, such as instructions that perform the methods described below in relation to Figure 4.

[0025] 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.

[0026] 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 implement the methods 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.

[0027] As an example of one embodiment, the control circuit 110 of the computing system 100 may include an SoC arrangement that facilitates the various methods and techniques described throughout this disclosure.

[0028] In various examples, an SoC may include a set of chiplets, which may include a central chiplet with shared memory where a reservation table is used to run various autonomous driving workloads in an independent deterministic pipeline, as described herein.

[0029] System-on-a-chip example Figure 2 is a block diagram showing an example of an SoC 200 as described herein. The example SoC 200 shown in Figure 2 may include additional components, and the components of the system-on-chip 200 may be arranged in various alternative configurations other than those shown. Therefore, the system-on-chip 200 in Figure 2 is described herein as an example arrangement for illustrative purposes and is not intended to limit the scope of this disclosure in any way.

[0030] Referring to Figure 2, the sensor data input chiplet 210 of the system-on-chip 200 can receive sensor data from various vehicle sensors 205 of the vehicle. These vehicle sensors 205 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. Simultaneously with receiving the sensor data, the sensor data input chiplet 210 may automatically dump the sensor data into the cache memory 231 of the central chiplet 220. The sensor data input chiplet 210 may also include an image signal processor (ISP) responsible for capturing, processing, and improving images acquired from the various vehicle sensors 205. 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 SoC200. 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 can then store the high-quality images in the cache memory 231.

[0031] In some embodiments, the sensor data input chiplet 210 exposes identification information for each item of sensor data (e.g., image, point cloud map, etc.) to the shared memory 230 of the central chiplet 220, 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 231, the type of sensor data, which sensor captured the data, and a timestamp when the data was captured.

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

[0033] In one embodiment, interconnects 211a-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.

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

[0035] In various applications, the system-on-chip 200 may further include a machine learning (ML) accelerator chiplet 240, specifically designed to accelerate AI workloads such as image inference or other sensor inference using machine learning to achieve high performance and low power consumption. The ML accelerator chiplet 240 may include an engine designed to efficiently process graph-based data structures commonly used in AI workloads, and a highly parallel processor that enables efficient processing of large amounts of data. The ML accelerator chiplet 240 may also include a dedicated hardware accelerator for common AI operations such as matrix multiplication and convolution, as well as a memory hierarchy designed to optimize memory access for AI workloads that often have complex memory access patterns.

[0036] The general-purpose computing chiplet 245 may provide general-purpose computing for the system-on-chip 200. For example, the general-purpose computing chiplet 245 may include a high-power central processing unit and / or a graphical processing unit, which may support the computing tasks of the central chiplet 220, the autonomous driving chiplet 240, and / or the ML accelerator chiplet 250.

[0037] In various implementations, the shared memory 230 may store programs and instructions for performing autonomous driving tasks. The shared memory 230 of the central chiplet 220 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 230 in the context of the dual SoC configuration described herein is provided below with reference to Figure 4. The central chiplet 220 also includes a large cache memory 231 that supports invalidation and flashing of stored data.

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

[0039] As described herein, the shared memory 230 can accommodate a mailbox architecture in which an immediate program containing a set of instructions is used to execute workloads by the central chiplet 220, the general-purpose compute chiplet 245, and / or the autonomous operation chiplet 240. In certain examples, the central chiplet 220 may further execute a functional safety (FuSa) program that operates to compare and verify the outputs of each pipeline to ensure consistency in ML inference operations. In further examples, the central chiplet 220 may execute a thermal management program to ensure that various components of the SoC 200 operate within a normal temperature range. A further explanation of the shared memory 230 in the context of out-of-order workload execution in independent pipelines is provided below with reference to Figure 3.

[0040] Run workloads in any order Figure 3 is a block diagram showing an example of a central chiplet 300 in an SoC configuration for implementing unordered workload execution in an independent deterministic pipeline, as described herein. The central chiplet 300 shown in Figure 3 may correspond to the central chiplet 220 of the SoC 200 shown in Figure 2. Furthermore, the sensor data input chiplet 310 in Figure 3 may correspond to the sensor data input chiplet 210 shown in Figure 2, and the workload processing chiplet 320 shown in Figure 3 may correspond to the general-purpose computing chiplet 245, the ML accelerator chiplet 250, and / or the autonomous driving chiplet 240 shown in Figure 2.

[0041] Referring to Figure 3, the central chiplet 300 may include a shared memory 360 for storing an immediate response program 330 and an application program 335. As described herein, the immediate response program 330 may include a set of instructions for executing immediate response workloads in multiple independent pipelines. Immediate response workloads may include sensor data acquisition, sensor fusion, and inference tasks, which facilitate the understanding of the vehicle's surrounding environment.

[0042] These tasks may include two-dimensional image processing, sensor fusion data processing (e.g., three-dimensional LiDAR, radar, and image fusion data), neural radiance field (NeRF) scene reconstruction, occupied grid determination, object detection and classification, motion prediction, and other scene understanding tasks for autonomous vehicle operation.

[0043] As further described herein, the application program 335 may include a set of instructions for operating the vehicle controls of an autonomous vehicle based on the output of the immediate workload pipeline. For example, the application program 335 may be executed by one or more processors 340 and / or workload processing chiplets 320 of the central chiplet 300 (e.g., the autonomous driving chiplet 240 in Figure 2) to dynamically generate a vehicle motion plan based on the execution of the immediate workload and to operate the vehicle controls (e.g., acceleration, braking, steering, and signaling systems) to execute the motion plan accordingly.

[0044] In various implementations, the central chiplet 300 may include a set of one or more processors 340 (e.g., transient-tolerant CPUs and general-purpose computing CPUs) capable of executing a scheduling program 342 for the unordered execution of workloads in a set of deterministic pipelines. In certain examples, one or more of the processors 340 may execute an immediate workload according to an immediate program 330 and / or an application workload according to an application program 335. Thus, the processors 340 of the central chiplet 300 can refer to, monitor, and update dependency information in the workload entries of the reservation table 350 as workloads become available and are executed accordingly. For example, when a workload is executed by a particular chiplet, the chiplet updates the dependency information of other workloads in the reservation table 350 to indicate that its workload has been completed. This may involve changing the bitwise operator or binary value representing the workload (e.g., from 0 to 1) to indicate in the reservation table 350 that the workload has been completed. Consequently, the dependency information of all workloads that are dependent on the completed workload is updated accordingly.

[0045] As described herein, the reservation table 350 may include workload entries, each of which includes a workload identifier describing the workload to be performed, the address in the cache memory 315 and / or HBM-RAM of the location of the unprocessed or processed sensor data required to perform the workload, and any dependency information corresponding to dependencies that need to be resolved before the workload is performed. In certain embodiments, dependencies may correspond to other workloads that need to be performed. When a dependency for a particular workload is resolved, the workload entry may be updated (for example, by the chiplet performing the dependent workload or by the processor 240 of the central chiplet 300 through the execution of the scheduling program 342). If no dependency exists for a particular workload when referenced in the reservation table 350, the workload can be performed in the target pipeline by the corresponding workload processing chiplet 320.

[0046] In various implementations, the sensor data input chiplet 310 acquires sensor data from the vehicle's sensor system and stores that sensor data (e.g., image data, LIDAR data, radar data, ultrasonic data, etc.) in the cache 315 of the central chiplet 300. The sensor data input chiplet 310 can generate a workload entry in the reservation table 350, which includes an identifier for the sensor data (e.g., an identifier for each image acquired from various cameras in the vehicle's sensor system), and provide the address of that sensor data in the cache memory 315. An initial set of the workload is executed by the processor 340 of the central chiplet 300 and / or the workload processing chiplet 320 for the unprocessed sensor data, which may update the reservation table 350 to indicate that the initial set of the workload is complete.

[0047] As described herein, the workload processing chiplet 320 monitors the reservation table 350 to determine whether a particular workload in the target pipeline is ready for execution. For example, the workload processing chiplet 320 may continuously monitor the reservation table using a workload window 355 (e.g., an instruction window for multimedia data), in which a pointer can sequentially read each workload entry to determine if the workload has any outstanding dependencies. If a workload entry still has one or more dependencies, the workload is not executed, and the pointer moves on to the next entry. However, if the workload indicates that all dependencies have been resolved (e.g., all workloads to which a particular workload depends have been executed), the associated workload processing chiplet 320 and / or processor 340 of the central chiplet 300 may execute the workload accordingly.

[0048] Thus, the workload is executed in a non-sequential manner, in which certain workloads are buffered until their dependencies are resolved. Therefore, to facilitate non-sequential execution of workloads, the reservation table 350 includes a non-sequential buffer, which allows the workload processing chiplets 320 to execute workloads in an order deterministically governed by the resolution of dependencies. Non-sequential execution of workloads in the manner described herein is intended to improve speed, power efficiency, and reduce the overall complexity of workload execution.

[0049] As described herein, the workload processing chiplet 320 can execute the workload of each pipeline in a deterministic manner, such that the successive workloads of a pipeline are subordinate to the output of the preceding workloads of that pipeline. In various implementations, the processor 340 and the workload processing chiplet 320 can execute multiple independent workload pipelines in parallel, each workload pipeline containing multiple workloads to be executed in a deterministic manner. Each workload pipeline can provide a set of outputs (for example, for other workload pipelines or for processing by the application program 335 to operate the vehicle autonomously). Through the simultaneous execution of responsive workloads in the deterministic pipeline, the application program 335 can autonomously operate the control of the vehicle along the travel route.

[0050] As an example, scheduling program 342 can cause processor 340 and workload processing chiplet 320 to perform out-of-order execution of workloads in independent pipelines. In previous implementations, each image generated by the vehicle's camera system is processed or inferred as soon as the image becomes available. The instruction set includes acquiring an image, scheduling inference about the image by the workload processing chiplet, performing inference about the image, acquiring a second image, scheduling inference about the second image by the workload processing chiplet, and performing inference about the second image, across a set of cameras in the vehicle. By reorganizing the order in which workloads are processed, the complexity of the computation is significantly reduced. Specifically, for verifying an autonomous driving system that utilizes out-of-order workload execution as described herein, the number of computational combinations required for verification (e.g., by safety authorities) is significantly reduced.

[0051] As described herein, by using the workload window 355 and the reservation table 350 which references workload dependency information, the workload processing chiplet 320 can operate more efficiently by performing out-of-order execution on workloads. Instead of performing inference on images based on when images are available, the workload processing chiplet 320 can first acquire all images from all cameras and then perform inference on all images together. Thus, when the workload processing chiplet 320 executes workloads, complexity is greatly reduced, speed is improved, and power requirements are lowered.

[0052] In a further example, the shared memory 360 may include a thermal management program 337 that can be executed by one or more processors 340 to manage various temperatures of the SoC 200, operate cooling components, perform hardware throttling, and switch to a backup component (e.g., a backup SoC). In yet another example, the shared memory 360 may include a FuSa program 338 that performs functional safety tasks for the SoC 200, such as monitoring communications within the SoC (e.g., using error correction codes), comparing outputs of different pipelines, and monitoring the hardware performance of the SoC. According to the examples described herein, the thermal management program 337 and the FuSa program 338 can perform their respective tasks in independent pipelines.

[0053] Independent deterministic pipeline Figure 4A shows a workload running in a set of independent pipelines, as illustrated in the examples described herein. Figure 4B shows a functional safety (FuSa) pipeline, as illustrated in the examples described herein, that can operate to compare and verify the outputs of the independent pipelines. In the following description of Figures 4A and 4B, various workloads can be executed by one or more processors 340 of the central chiplet 300 and / or workload processing chiplet 320 in independent deterministic pipelines, through the execution of an immediate response program 330, an application program 335, a thermal management program 337, a FuSa program 338, and / or a scheduling program 342, as shown in Figure 3.

[0054] Referring to Figure 4A, pipelines 400 and 410 are executed in parallel by one or more chiplets of the SoC. Although only pipelines 400 and 410 are shown in Figure 4A, any number of pipelines can be executed in parallel by the central chiplet 300 and / or workload processing chiplet 320 when performing the rapid response and application tasks described throughout this disclosure. As described herein, rapid response and application tasks may include sensor data acquisition, sensor fusion, inference tasks to facilitate situational understanding of the vehicle's surrounding environment, motion prediction, motion planning, and vehicle control tasks to operate the vehicle autonomously. Additional tasks such as power control tasks, thermal management tasks, and health monitoring tasks may also be performed in individual pipelines.

[0055] In various implementations, the scheduling program 342 can deterministically execute workloads represented by workload entries in the reservation table 350 in independent pipelines, so that the order of workload execution in each pipeline is consistent and irreversible.

[0056] Furthermore, since the workloads executed in each pipeline may involve a chain of dependencies, the output of each pipeline is based on the same or similar workloads executed sequentially in each pipeline. In this way, the complexity in the inference operation is greatly reduced, which facilitates the individual certification of each pipeline for autonomous driving purposes.

[0057] For example, pipeline 400 may be tasked with performing inference on two-dimensional image data (e.g., to identify and classify other dynamic entities adjacent to the vehicle in the image). A first workload in pipeline 400 may include acquiring images captured by each camera on the vehicle at a given time. A second workload in pipeline 400 may include stitching the images together to form a 360° ribbon of the vehicle's surrounding environment. A third workload in pipeline 400 may include performing inference on the two-dimensional image data (e.g., pixel analysis to identify dynamic entities). Thus, the output of pipeline 400 may include a two-dimensional ribbon with identified (e.g., using bounding boxes) and / or classified (e.g., as a person riding a bicycle, another vehicle, a pedestrian, etc.) dynamic entities.

[0058] As another example, pipeline 410 may be tasked with performing inferences on three-dimensional sensor fusion data (e.g., including fused data, LiDAR, imagery, and / or radar data). For example, pipeline 410 may also be tasked with identifying external dynamic entities in the three-dimensional data. A first workload in pipeline 410 may include acquiring point clouds generated by the vehicle's LiDAR sensors at a given time and acquiring radar and ultrasonic data from the same time. A second workload in pipeline 410 may include fusing the sensor data to provide a three-dimensional fused sensor view of the vehicle's surrounding environment. A third workload in pipeline 410 may include performing inferences on the three-dimensional sensor fusion data to identify and / or classify external dynamic entities.

[0059] As described herein, workload processing chiplets (e.g., workload processing chiplets 320 and central chiplet 300 in Figure 3) can execute their respective workloads in various other deterministic pipelines (e.g., according to the ready program 330 and / or application program 335 shown in Figure 3). For example, a first pipeline may be dedicated to identifying traffic signals in two-dimensional image data, a second pipeline may be dedicated to identifying traffic signals in three-dimensional sensor fusion data, a third pipeline may be dedicated to identifying and classifying lane markings, a fourth pipeline may be dedicated to generating an occupied grid map from sensor data, a fifth pipeline may be dedicated to predicting the motion of external dynamic entities, a sixth pipeline may be dedicated to planning the motion of a vehicle based on inferences from other pipelines, a seventh pipeline may be dedicated to controlling the vehicle's control system to execute the motion plan generated by the sixth pipeline, and so on.

[0060] Various examples show that the workloads or tasks performed in each pipeline are deterministically ordered (e.g., by scheduling program 342 in Figure 3), which significantly reduces the complexity of certifying an autonomous driving system. For example, a single inference mechanism for an autonomous driving system that performs naturally ordered processing using image data may not be certifiable due to the complexity and randomness of workload execution, as well as the possibility of outliers in a single inference mechanism (e.g., confusion about certain detected objects and lack of comparison between multiple inference mechanisms). These outliers can lead to stalling or collisions in the autonomous vehicle. By using deterministic pipelines that execute workloads independently, outliers arising from one pipeline can be mitigated or overcome by comparison and confirmation mechanisms from other pipelines.

[0061] As shown in Figure 4A, various workloads in pipelines 400 and 410 can be run as runnable on one or more processors of one or more chiplets of the SoC 200. In certain cases, transient-tolerant CPUs (e.g., of the central chiplet 220 and / or general-purpose compute chiplet 245) can run workloads within pipelines 400 and 410. The use of robust transient-tolerant CPUs (e.g., ASIL-D rated CPUs) to run workloads in independent deterministic pipelines is intended to further enhance the overall ASIL rating of the autonomous driving system. These transient-tolerant CPUs may be manufactured to be robust in terms of reliability and resistance to heat, cold, radiation, wear, aging, vibration, shock, etc. It is further assumed that transient-tolerant CPUs may not have the computing power of modern non-transient-tolerant CPUs (e.g., those with an ASIL-B rating) designed and manufactured to maximize bandwidth and processing speed.

[0062] As shown in Figure 4A, the workloads in pipelines 400 and 410 can be run as runners on multiple CPUs and / or multiple chiplets of the SoC200. For example, a transient-tolerant CPU can run the workload in each pipeline 400, 410, and be backed up by one or more modern technology CPUs running the same workload in each pipeline 400, 410. The transient-tolerant CPU can run the workload in each pipeline 400, 410 at a lower frequency than the other CPUs. For example, the transient-tolerant CPU can run the workload in each pipeline 400, 410 and provide output on the order of microseconds, while the other CPUs can provide output to each pipeline 400, 410 on the order of nanoseconds.

[0063] In one example, a transient-tolerant CPU can execute a workload within a deterministic pipeline 400 and identify external dynamic objects (e.g., other vehicles, cyclists, pedestrians, etc.) in two-dimensional image data every few microseconds. Other CPUs can execute the same workload within the deterministic pipeline 400 and identify the same external dynamic entities every few nanoseconds (e.g., or as frequently as the image is generated by the camera). Thus, the output of the transient-tolerant CPU can be verified or confirmed by the output of other CPUs in their respective deterministic pipelines. This process can occur for each independent pipeline performing inference operations (e.g., the immediate response program 330) and can also be utilized for the application program 335, the thermal management program 337, and / or the FuSa program 338.

[0064] In certain embodiments, the workloads of pipelines 400 and 410 can be executed by one or more CPUs of the central chiplet 220 and / or one or more CPUs of the general-purpose computing chiplet 245. Figure 4B shows an exemplary FuSa pipeline 420 that dynamically compares and verifies the outputs of runnables in each pipeline 400, 410 in various examples. In certain implementation forms, FuSa pipeline 420 can compare the outputs of multiple runnables executed by different CPUs within each pipeline 400, 410, and can also compare the output of pipeline 400 with the output of pipeline 410. In an example of identifying and classifying dynamic external entities, the two-dimensional output from pipeline 400 may lack precise distance information to each entity in the image data, while the three-dimensional output from pipeline 410 may lack information such as color and edge details that facilitate the classification of external entities. Furthermore, the sensor fusion data processed in pipeline 410 may include radar data and / or ultrasonic data, which can provide detailed proximity and / or velocity difference information of external entities.

[0065] Thus, the outputs of pipeline 400 and pipeline 410 have different outliers, which, when viewed individually, can affect the accuracy of the autonomous driving system's capabilities. As described herein, various workload processing chiplets (e.g., chiplet 320 and central chiplet 300 in Figure 3) can execute workloads in any number of pipelines, each pipeline having different outliers based on the sensor data being processed. As further described herein, the output of a certain pipeline can be compared to the output of other pipelines through the execution of one or more FuSa pipelines 420, which dynamically verify the output of each of the different independent pipelines.

[0066] As shown in Figure 4B, the FuSa pipeline 420 can acquire the outputs of pipelines 400 and 410, and compare and verify those outputs. As described herein, the outputs can correspond to any inference operations related to processing sensor data from the vehicle's sensor system. In various examples, the runnable of FuSa pipeline 420 can run on a dedicated CPU (for example, on the central chiplet 220 in an SoC200 configuration).

[0067] In the example shown in Figure 4B, FuSa pipeline 420 acquires the two-dimensional output of pipeline 400 and the three-dimensional output of pipeline 410. FuSa pipeline 420 then compares the two-dimensional and three-dimensional outputs to determine if they match. In the case of inference involving the identification and / or classification of external dynamic entities, FuSa pipeline 420 verifies whether both pipeline 400 and pipeline 410 separately identified and / or classified the same external dynamic entities in the vehicle's surrounding environment using different sensor data and / or techniques with different outliers.

[0068] The examples shown in Figures 4A and 4B illustrate pipelines containing different types of sensor data, but numerous other deterministic pipelines are envisioned where the FuSa pipeline is used to compare and dynamically verify outputs. For example, this could include a FuSa pipeline comparing the outputs of multiple pipelines tasked with identifying traffic signals and traffic signal states, the output of a motion prediction pipeline tasked with predicting the motion of external dynamic entities, and equivalent outputs of other deterministic pipelines that facilitate the autonomous operation of a vehicle. In this way, any problems occurring in any of the pipelines can be easily detected and flagged by the FuSa pipeline. The combination of using transient-tolerant CPUs with support from general-purpose computing CPUs, running workloads in verifiable deterministic pipelines, and using the FuSa pipeline to dynamically compare and verify outputs from deterministic pipelines is intended to provide improved ASIL ratings (e.g., ASIL-D ratings) for autonomous driving systems of vehicles.

[0069] methodology Figures 5 and 6 are flowcharts illustrating a method for executing a workload in an independent pipeline, as described herein. In the following description of the method in Figures 5 and 6, reference symbols representing certain features described in relation to the system diagrams of Figures 1 to 4B may be referenced. Furthermore, the steps described with reference to the flowcharts of Figures 5 and 6 may be performed by the workload processing chiplets 320 and central chiplet 300 of the computing system 100, and / or system-on-chip 200, as illustrated and described in relation to Figures 1 to 3. Moreover, certain steps described with reference to the flowcharts of 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 necessarily have to be performed in the respective illustrated order.

[0070] Referring to Figure 5, in block 500, the computing system 100 can acquire sensor data from a sensor system (e.g., a LiDAR sensor, radar sensor, camera, ultrasonic sensor, etc.). In block 505, the computing system 100 can store the sensor data in cache memory. In block 510, the computing system 100 can then execute workloads based on the sensor data in a set of independent deterministic pipelines. As described throughout this disclosure, executing multimedia workloads in deterministic pipelines can reduce the complexity of various applications, particularly those that may require certification by security or safety authorities.

[0071] Figure 6 is another flow illustrating how a workload is executed in an independent deterministic pipeline in the field of autonomous driving, according to the example described herein. Referring to Figure 6, in block 600, the sensor data input chiplet 310 can acquire sensor data from a set of vehicle sensors 205. As described herein, the sensor data from the vehicle sensors 205 may include any combination of LIDAR data in block 602, image data in block 603, radar data in block 604, and / or other forms of sensor data (e.g., ultrasonic data, IR data, etc.). In certain implementations, in block 605, the sensor data input chiplet 310 can generate workload entries corresponding to the sensor data in a reservation table 350 contained in the shared memory 360 of the central chiplet 300.

[0072] In block 610, a set of workload processing chiplets (e.g., processing chiplet 320 and / or central chiplet 300) can execute workloads corresponding to workload entries in a set consisting of independent deterministic pipelines. In particular, the scheduling program 342 of the central chiplet 300 can schedule a given set of workloads to be executed deterministically in independent pipelines. For example, the scheduling program 342 can assign dependency information to a workload entry so that the workload entry is not executed until the dependency information is resolved. This dependency information may include other workloads that need to be executed before that particular workload. In a further example, a workload processing chiplet can deterministically execute workloads in a set consisting of independent pipelines by using the reservation table 350 as an unordered buffer (e.g., by sequentially analyzing workload entries in the workload window 355 using instruction pointers for multimedia content).

[0073] As described herein, the workload processing chiplet can execute multiple workloads in a set of independent pipelines to perform a set of tasks for operating a vehicle. In various examples, the set of tasks may include multiple image stitching tasks, sensor fusion tasks, machine learning inference tasks, object detection tasks, object classification tasks, scene understanding tasks, motion prediction tasks, and so on. These tasks may include inference operations to process the vehicle's surrounding environment so that the application program 335 can successfully operate the vehicle along a travel route. Thus, the set of independent pipelines can provide the application program 335 with output (e.g., an inferred sensor view of the surrounding environment) to operate the vehicle autonomously.

[0074] In block 615, the central chiplet 300 may include a FuSa program that dynamically compares and verifies the outputs of multiple independent pipelines in the FuSa pipeline in a deterministic manner, as shown in FuSa pipeline example 420 in Figure 4B. As described throughout this disclosure, the SoC 200 may include chiplets (e.g., workload processing chiplet 320 and / or central chiplet 300) that include one or more transient-tolerant CPUs that execute workloads in independent pipelines. The use of transient-tolerant CPUs, FuSa pipelines, and deterministic ordering of workload execution can be combined to facilitate improving the ASIL rating of an autonomous driving system in a vehicle.

[0075] In block 620, the execution of workloads in a deterministic pipeline (e.g., via the immediate response program 330) can generate an inferred sensor view of the vehicle's surrounding environment, which can be provided to the application program 335 to enable autonomous vehicle operation. Each independent deterministic pipeline corresponding to the immediate response program 330 is intended to be certified (e.g., by safety authorities for use on public roads). These pipelines may include all inference operations corresponding to perception, object detection and classification, occupancy grid determination, motion prediction and / or planning, and any other scene understanding tasks for enabling autonomous vehicle operation.

[0076] 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 sensor data input chiplet for acquiring sensor data from the vehicle's sensor system, A computing system comprising one or more workload processing chiplets that execute workloads in a set of independent pipelines based on the aforementioned sensor data.

2. The computing system according to claim 1, wherein one or more workload processing chiplets execute the workloads in a set of independent pipelines in order to perform a set of tasks for operating the vehicle.

3. The computing system according to claim 2, wherein the set of tasks includes a plurality of the following: image stitching tasks, sensor fusion tasks, machine learning inference tasks, object detection tasks, object classification tasks, scene understanding tasks, and motion prediction tasks.

4. The computing system according to claim 3, wherein one or more workload processing chiplets provide the output of the set of independent pipelines to an application program for autonomously operating the vehicle.

5. The computing system according to claim 4, wherein the output of the set of independent pipelines includes an inferred sensor view of the surrounding environment of the vehicle in order to facilitate the autonomous operation of the vehicle.

6. The computing system according to claim 1, wherein one or more workload processing chiplets deterministically execute the workloads in the set of independent pipelines, using a reservation table for the workload as an unordered buffer.

7. The computing system according to claim 6, wherein the reservation table includes a workload entry for a target workload, and the workload entry indicates a cache address of workload data for executing the target workload and dependency information for executing the target workload.

8. The computing system according to claim 1, wherein the one or more workload processing chiplets include a central chiplet having at least one transient-tolerant CPU that executes a subset of the workload in a plurality of parallel, independent pipelines to enable autonomous operation of the vehicle.

9. The computing system according to claim 8, wherein the central chiplet dynamically compares and verifies the outputs of the plurality of parallel independent pipelines in a functional safety (FuSa) pipeline.

10. The computing system according to claim 9, wherein the at least one transient-tolerant CPU and the FuSa pipeline are provided to facilitate the Automotive Safety Level (ASIL) grade of the autonomous driving system of the vehicle.

11. The computing system according to claim 1, wherein one or more workload processing chiplets are included in the system-on-chip (SoC) arrangement of the computing system.

12. The computing system according to claim 11, wherein the SoC configuration comprises the sensor data input chiplet, a central chiplet, one or more general-purpose computing chiplets, an autonomous driving chiplet, a machine learning accelerator chiplet, and one or more high-bandwidth memory chiplets.

13. A non-temporary computer-readable medium for storing instructions, wherein when an instruction is executed by one or more processors, the one or more processors... The sensor data input chiplet allows sensor data to be acquired from the vehicle's sensor system. A non-temporary computer-readable medium that causes one or more workload processing chiplets to execute workloads in a set of independent pipelines based on the sensor data.

14. The non-temporary computer-readable medium according to claim 13, wherein one or more workload processing chiplets execute the workloads in a set of independent pipelines to perform a set of tasks for operating the vehicle.

15. The non-temporary computer-readable medium according to claim 14, wherein the set of tasks includes a plurality of the following: image stitching tasks, sensor fusion tasks, machine learning inference tasks, object detection tasks, object classification tasks, scene understanding tasks, and motion prediction tasks.

16. The non-temporary computer-readable medium according to claim 15, wherein one or more workload processing chiplets provide the output of the set of independent pipelines to an application program for autonomously operating the vehicle.

17. The non-temporary computer-readable medium according to claim 16, wherein the output of the set of independent pipelines includes an inferred sensor view of the surrounding environment of the vehicle in order to facilitate the autonomous operation of the vehicle.

18. The non-temporary computer-readable medium according to claim 13, wherein one or more workload processing chiplets deterministically execute the workloads in the set of independent pipelines using a reservation table for the workload as an unordered buffer.

19. The non-temporary computer-readable medium according to claim 18, wherein the reservation table includes a workload entry for the target workload, and the workload entry indicates a cache address of workload data for executing the target workload and dependency information for executing the target workload.

20. A computer implementation method, The sensor data input chiplet acquires sensor data from the vehicle's sensor system, A method comprising using one or more workload processing chiplets to execute workloads in a set of independent pipelines based on the sensor data.

Images