Patent Application
20250224789
The technology discussed below relates generally to power management of a system-on-chip (SoC), and more particularly, to power management based on a safe designation of an electronic control unit on an SoC.
System-on-chip (SoC) technology has emerged as a key component in vehicles. SoC technology integrates multiple electronic control units (ECUs) (e.g., central processing units (CPUs), graphic processing units (GPUs), neural signal processors (NSPs), digital signal processors (DSPs), Double Data Rate Synchronous Dynamic Random-Access Memory (DDR SDRAM), hardware accelerators, fixed function accelerators, etc.) onto a single chip. Each of the ECUs may be configured at any one time to run a respective vehicle workload, such as Advanced Driver Assistance System (ADAS), In-vehicle Infotainment (IVI) (e.g., gaming system, dashboard display, audio processing), Light Detection and Ranging (LIDAR), Radio Detection and Ranging (RADAR), and other suitable vehicle workloads. Thus, SoCs can efficiently process data from various sensors in real time to enhance the speed, accuracy, and reliability of safety systems.
Safety and power management on SoCs have traditionally been treated as mutually exclusive such that each SoC supported a static configuration of either all safety critical ECUs or all non-safety critical ECUs. Examples of safety critical ECUs include ADAS NSPs, CPUs, and GPUs. Examples of non-safety critical ECUs include IVI CPUs and other infrastructure. The latest generation SoC technology supports a flex operation that can serve both safety critical and non-safety critical ECUs on the same SoC. However, the current software architecture does not support the distinction of safety critical and non-safety critical ECUs under the flex operation. In addition, the current software architecture does not support the re-classification of ECUs at the boundary between drive modes (e.g., parked, stopped, driving) or SoC operation stages (e.g., boot, sleep/wake, run, power-down).
The following presents a summary of one or more aspects of the present disclosure, in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated features of the disclosure, and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in a form as a prelude to the more detailed description that is presented later.
In one example an apparatus is provided including a plurality of electronic control units (ECUs) on a system-on-chip (SoC) of a vehicle and a controller configured to identify a respective safe designation for each of the plurality of ECUs. The respective safe designation for each of the plurality of ECUs includes a safety critical designation or a non-safety critical designation. The controller is further configured to load a respective configuration of at least one power feature, at least one limit feature, or a combination of the at least one power feature and the at least one limit feature into each of the plurality of ECUs based on the respective safe designation including the safety critical designation or the non-safety critical designation.
Another example provides a method of safe designation on a system-on-chip (SoC). The method includes identifying a respective safe designation for each of a plurality of electronic control units (ECUs) on the SoC of a vehicle. The respective safe designation for each of the plurality of ECUs includes a safety critical designation or a non-safety critical designation. The method further includes loading a respective configuration of at least one power feature, at least one limit feature, or a combination of the at least one power feature and the at least one limit feature into each of the plurality of ECUs based on the respective safe designation including the safety critical designation or the non-safety critical designation.
Another example provides a system-on-chip including means for identifying a respective safe designation for each of a plurality of electronic control units (ECUs) on the SoC of a vehicle. The respective safe designation for each of the plurality of ECUs includes a safety critical designation or a non-safety critical designation. The SoC further includes means for loading a respective configuration of at least one power feature, at least one limit feature, or a combination of the at least one power feature and the at least one limit feature into each of the plurality of ECUs based on the respective safe designation including the safety critical designation or the non-safety critical designation.
These and other aspects will become more fully understood upon a review of the detailed description, which follows. Other aspects, features, and examples will become apparent to those of ordinary skill in the art upon reviewing the following description of specific exemplary aspects in conjunction with the accompanying figures. While features may be discussed relative to certain examples and figures below, all examples can include one or more of the features discussed herein. In other words, while one or more examples may be discussed as having certain features, one or more of such features may also be used in accordance with the various examples discussed herein. Similarly, while examples may be discussed below as device, system, or method examples, it should be understood that such examples can be implemented in various devices, systems, and methods.
The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
Several aspects of the invention will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, computer software, firmware, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
While aspects and examples are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases may come about in many different arrangements and scenarios. Innovations described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, and packaging arrangements. For example, aspects and/or uses may come about via integrated chip examples and other non-module-component-based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail/purchasing devices, medical devices, artificial intelligence (AI)-enabled devices, etc.). While some examples may or may not be specifically directed to use cases or applications, a wide assortment of applicability of described innovations may occur. Implementations may range in spectrum from chip-level or modular components to non-modular, non-chip-level implementations and further to aggregate, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more aspects of the described innovations. In some practical settings, devices incorporating described aspects and features may also necessarily include additional components and features for the implementation and practice of described examples. It is intended that innovations described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, end-user devices, etc., of varying sizes, shapes, and constitution.
Each electronic control unit (ECU) (e.g., CPU, GPU, NSP, DSP, DDR SDRAM, etc.) on a system-on-chip (SoC) of a vehicle may be dynamically configured to run a respective vehicle workload, such as ADAS, IVI, LIDAR, RADAR, and other suitable vehicle workloads. Each of the vehicle workloads may be classified as safe (safety critical) or non-safe (non-safety critical). For example, ADAS may be classified as safety critical, whereas IVI may be classified as non-safety critical. The latest generation SoC technology supports a flex operation that can support both safety critical and non-safety critical ECUs (e.g., a first ECU running a safety critical workload and a second ECU running a non-safety critical workload) on the same SoC.
The SoC technology flex operation can serve both safety critical and non-safety critical power management functionality for ECUs on the same SoC to exploit differentiated low power/performance of safety critical and non-safety critical ECUs. For example, macro-level power features may be made safe (e.g., software performance states, as defined by the voltage level and clock frequency, and interframe power gating) for both safety critical and non-safety critical ECUs. Additional micro-level and limits power management features may further be available to ECUs designated as non-safety critical. Non-safety critical ECUs may further compete for a fixed allocation of thermal design power (TDP) budget left over from the safety critical ECU workloads. However, the current software architecture does not support the distinction of safe and non-safe ECUs under the flex operation. In addition, at the boundary between drive modes (e.g., parked, stopped, driving) or SoC operation stages (e.g., boot, sleep/wake, run, power-down), it may be useful to allocate an ECU as safe or non-safe and configure it accordingly, so that correspondent SoC power and/or limit management features may be configured to maximize the power saving and performance under the constraints.
In various aspects of the disclosure, a software architecture that supports the distinction of safety critical and non-safety critical ECUs under the flex operation utilizes a safe power framework that begins with a designation of each of the ECUs on an SoC as either safety critical or non-safety critical resources based on the original equipment manufacturers (OEMs) high-level safe software architecture and ECU policies, such as drive-mode policies, park-mode policies, application policies, SoC operation stage policies, vehicle occupant interaction, and TDP budget distribution. In one example, the OEM of an ECU may statically specify the safe designation for each vehicle drive mode (e.g., vehicle operation status, such as parked with air-conditioning on or off, driving on local roads or a highway, stopped at a traffic light, etc.) or SoC operation stage (e.g., boot-up, sleep/wake-up, run, power-down, etc.). The software can then load the appropriate safe designation configuration into the ECU based on the current vehicle drive mode or SoC operation stage. For example, the configuration may include one or more power features (e.g., dynamic clock voltage scaling (DCVS), low power management, etc.) and/or limit features (power limit, temperature limit, current limit, TDP limit, etc.). In another example, the appropriate safe designation and associated configuration can be dynamically extracted and loaded into the ECU at runtime based on the workloads (e.g., safety critical or non-safety critical workloads) scheduled for the ECU at the boundary between two different drive modes and/or based on the SoC operation stage.
In an example, an application layer of the SoC may designate each ECU as safety critical or non-safety critical and a processing device on the SoC may load the configuration of the safe designation into each ECU. In addition, a secure channel may be provided to pass the safe designation from the application layer to the processing device. By enabling the SoC flex operation with the software architecture described herein, costs of computation may be reduced and power efficiency may be maximized by reducing the TDP budget spent on leakage power and increasing the TDP budget spent on workloads.
The ECUs 104 may be organized in close proximity to one another (e.g., on a single substrate, die, integrated chip, etc.) so that they may operate at a much higher frequency/clock-rate than would be possible if the signals were to travel off-chip. The proximity of the processors/cores may also allow for the sharing of on-chip memory and resources (e.g., voltage rail), as well as for more coordinated cooperation between processors/cores. In some examples, one or more of the ECUs 104 may include a cluster of ECUs of the same type. For example, an ECU 104 may include a cluster of multiple (e.g., two or more) CPU cores with rail-sharing among the CPU cores. As another example, an ECU 104 may include an NSP core with multiple (e.g., two or more) threads.
The processing system 120 is interconnected with one or more controllers 108, one or more input/output (I/O) module(s) 112, one or more memories 110, and one or more resource management unit(s) (RMUs) 114 via a bus 106, which may include an array of reconfigurable logic gates and/or implement a bus architecture (e.g., CoreConnect, advanced microcontroller bus architecture (AMBA), etc.). The bus 106 communications may be provided by advanced interconnects, such as high performance networks on chip (NoCs). The bus 106 may include or provide a bus mastering system configured to grant SoC components (e.g., processors, peripherals, etc.) exclusive control of the bus (e.g., to transfer data in burst mode, block transfer mode, etc.) for a set duration, number of operations, number of bytes, etc. The bus 106 may include a multi-level bus system including, for example, one or more aggregate NoCs serving a plurality of clients (e.g., a plurality of ECUs 104), and one or more main NoCs serving the aggregate NoCs and one or more clients.
The controller 108 may be configured to manage the flow of data to and from the memory 110, an ECU memory 104, or a memory device located off-chip (e.g., a flash memory device). In some examples, the memory 110 may include a universal flash storage (UFS) host device configured to receive various memory commands from multiple masters, and address and communicate the memory commands to a memory device. The multiple masters may include ECUs 104, and/or multiple applications running on one or more of the ECUs 104. The controller 108 may include one or more processors configured to perform operations disclosed herein. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure.
In some examples, the controller 108 is an application processor that may be controlled by an operating system (e.g., a high-level operating system (HLOS)) that is loaded from internal or external storage as data and instructions that are executable by the controller 108. In some examples, the controller 108 may further be configured to execute a hypervisor software application to provide a supervisory capability over several operating systems (OSs), manage access to the ECUs 104, manage access to peripherals (e.g., via the I/O module 112), and manage inter-OS communication and security.
The memory 110 may, for example, maintain software, operational parameters and other information used to configure and operate the SoC 102. The memory 110 may be implemented, for example, as a set of registers, or may be implemented in a database module, flash memory, magnetic media, non-volatile or persistent storage, optical media, a smart card, a flash memory device, a random access memory (RAM), a read only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), and/or any other suitable medium for storing software and/or instructions that may be accessed and read by the controller 108 and/or ECUs 104. In some examples, the memory 110 may include a cache memory to provide temporary storage of information to enhance the processing speed of the SoC 102.
The SoC may also be coupled to internal and/or external devices, such as a display, camera, operator controls (e.g., buttons and a keypad), cooling unit, navigation system, external memory device, and/or other peripheral devices and components via the input/output module 112. For example, the I/O module 112 may include an input/output interface (e.g., a bus architecture or interconnect) or a hardware design for performing I/O operations.
The RMU 114 is configured to manage voltages (e.g., retention, nominal, or off) on one or more core logic voltage rails (e.g., voltage rails configured to provide power to one or more ECUs 104 of the processing system 120 and the bus 106) and memory voltage rails (e.g., power rails configured to provide power to the controller 108 and the memory 110). The RMU 114 may also be configured to manage one or more clock sources configured to generate clock signals for one or more ECUs 104 of the processing system 120 and the bus 106. As such, the RMU 114 may be configured to manage components such as voltage rails, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, system controllers, access ports, timers, and other similar components used to support the processors and software clients running on the SoC 102, or external to the SoC 102. Thus, the RMU contains both power and limit controls and may be implemented by a combination of hardware and firmware. In some examples, the RMU 114 can be off-chip and external to the SoC 102.
In various aspects of the disclosure, the RMU 114 may be configured to operate together with the controller 108 to maximize power savings of each of the ECUs 104 without impacting safety and to maximize performance of each of the ECUs 104 within a constrained TDP budget based on a respective safe designation of each of the ECUs 104. As an example, an ECU 104 may have different safe designations based on various states associated with the SoC (e.g., drive mode states, SoC operation stage states, etc.). As another example, virtual machines (VMs) associated with the different workloads running on the ECUs 104 may have different safety criticality levels (e.g., different safe designations). In various aspects of the software architecture described herein, the safe designations may be managed by the controller 108 via a hypervisor running on the controller 108. For example, the safety critical/non-safety critical ECU configurations for each of the ECUs (e.g., based on ECU mode and/or the workload scheduled by the VM) may be generated, for example, by application layer software (e.g., HLOS or application layer subsystem (APSS)) and loaded onto the respective ECUs 104 via the hypervisor. Thus, the hypervisor may map VMs to physical SoC hardware (e.g., ECUs 104) and load the respective safety critical/non-safety critical configurations associated with each of the VMs into the appropriate ECUs 104. Those safety critical/non-safety critical ECU configurations may include, for example, power features and/or limit features that may be facilitated by the ECUs 104 in coordination with the RMU 114.
In some examples, the safe designation of an ECU 104 is statically configured by the OEM of the ECU for each SoC state (e.g., each drive mode state or SoC operation stage state). In this example, the controller 108 (e.g., an APSS running on the controller) may generate the respective safe designation configurations for each SoC state during compilation time (e.g., offline) and load the respective configuration associated with a current SoC state into the ECU via the hypervisor. Although this example may be easy to implement, the safe designation configuration may be inconsistent with the actual workload running on the ECU. In other examples, the safe designation of an ECU 104 may be dynamically configured based on the workload process running on (or scheduled to) the ECU 104. In this example, the controller 108 (e.g., an APSS running on the controller) may generate the respective safe designation configuration for each ECU at runtime after workloads are loaded on the boundary between ECU states (drive mode or SoC operation stage states). For example, the APSS may loop through each workload process running on each virtual ECU (e.g., vCPU) cluster for the requesting VMs, generate the appropriate configuration for each ECU based on the safe designation of the VM/workload, map the vECU with the physical ECU, and update/load the respective safe designation configuration into the respective ECU via the hypervisor. Although this example may be more computationally intensive, the safe designation configuration is guaranteed to match with the OEMs recommended configuration based on the workload.
In the flex operation, both safety and non-safety critical ECUs are supported on a single SoC (e.g., SoC 102). Using the software architecture and framework described herein, the safe designation (e.g., safety critical or non-safety critical) and associated ECU configurations may be flexible for different ECUs based on ECU policies (e.g., drive-mode policies, park-mode policies, application policies, SoC operation stage policies, vehicle occupant interaction, and TDP budget distribution) provided by the OEM of the ECU. In addition, the safe designations (e.g., safety critical and non-safety critical) and associated ECU configurations may be flexible for different workloads running on the ECUs. In some examples, pure safety critical or pure non-safety critical configurations (e.g., all safety critical ECUs or all non-safety critical ECUs) may be supported on the SoC 102 in the flex operation using the framework and software architecture described herein.
In some examples, the safe designation of each ECU may be based on the Functional Safety (FuSA) standard defined in International Organization for Standardization (ISO) 26262.
In addition, the Safe-Perf 302 and NonSafe-Perf 306 designations may each include performance requirements related to run-time deadlines. For example, each of the Safe-Perf 302 and NonSafe-Perf 306 designations may have fixed run-time deadlines. By contrast, the Safe-NonPerf 304 and NonSafe-NonPerf 308 designations do not include performance requirements, and as a result, some performance variability is acceptable.
Examples of Safe-Perf 302 workloads/ECUs include, but are not limited to, ADAS perception and decision processing on cameras, NSPs, CPUs, and GPUs. An example of a Safe-NonPerf 304 workload/ECU includes hypervisor services on a mobile phone operating system pinned CPU cluster. Examples of NonSafe-Perf 306 workloads/ECUs include, but are not limited to, IVI display or personal camera, snapshot processing on an image processor. An example of a NonSafe-NonPerf 308 workload/ECU includes a gaming application on a GPU.
In some examples, the safe designation of an ECU may be based on the workload running on the ECU. The workload safety criticality may be derived, for example, from an initialized VM that scheduled the workload. For example, workloads scheduled by a primary virtual machine (PVM) (e.g., HLOS or APSS) may be designated safety critical workloads, whereas workloads scheduled by a guest virtual machine (GVM) (e.g., mobile phone operating system) may be designated non-safety critical workloads. Each safe designation for an ECU may have a respective ECU configuration associated therewith that specifies one or more power features and/or limit features. The respective ECU configuration associated with each safe designation may be defined, for example, by the OEM of the ECU based on the FuSa qualifications of the ECU.
In some examples, the respective ECU configurations 404/410 of one or more power features 402 and/or limit features 408 may be loaded into an ECU based on the respective safe designation 406/412 associated with the ECU. For example, one or more power features 402 (e.g., DCVS) and/or limit features 408 (e.g., change in current/voltage limits) may be associated with the Safe-Perf designation 406/412. When the safe designation of the ECU is determined to be Safe-Perf, the ECU configurations 404/410 of each of the Safe-Perf power/limit features 402/408 may then be loaded into the ECU. As another example, one or more power features 402 (e.g., low power sleep) and/or limit features (e.g., power limits) may be associated with the Non-Safe-Perf designation 406/412 and may be loaded into the ECU when the safe designation of the ECU is determined to be Non-Safe-Perf.
In some examples, the safe designation 406/412 may be determined based on the ECU policies (e.g., drive-mode policies, park-mode policies, application policies, SoC operation stage policies, vehicle occupant interaction, and TDP budget distribution) specified for the ECU by the OEM. For example, the ECU policies may statically define a safe designation based on a drive mode state or SoC operation stage state. In some examples, the safe designation 406/412 may further be determined, for example, based on the workload running on the ECU. For example, the safe designation may be dynamically determined based on the workload scheduled at a boundary between two different drive mode states and/or two different SoC operation stage states.
The second drive mode 502b (e.g., Drive Mode 2) may correspond to a parked mode of the vehicle. In this second drive mode 502b, a larger portion of the TDP budget may be allocated to non-safety critical workloads 504b than safety critical workloads 508b. In addition, a portion of the TDP budget in the second drive mode 502b is also spent on leakage 506b. By flexibly allocating the TDP budget to safety critical and non-safety critical workloads based on a drive mode state change 550 between the first drive mode 502a and the second drive mode 502b, the TDP budget may be controlled, leveraging thermal gradients and allowing throttling and limiting where appropriate (e.g., for discretionary workloads). For example, the TDP budget may first be allocated to the safety critical workloads 508a/508b, and then the remaining TDP budget may be shared among the non-safety critical workloads 504a/504b with corresponding power and limit features applied. As a result, SoC performance and power efficiency may be enhanced.
To enable the flexible allocation of TDP budget, the different ECUs may be re-assigned or re-classified to different workloads at the boundary between drive mode states. In an example, in the second drive mode 502b, a CPU cluster may be allocated to a gaming workload (IVI CPU), which is a non-safety critical workload 504b. When the vehicle is put into drive (e.g., at the boundary between Drive Mode 2 and Drive Mode 1), the CPU cluster may be re-allocated to support an ADAS workload (ADAS CPU), which is a safety critical workload 508a. As a result of the re-allocation of the CPU cluster, the power and limits features configuration applied to the CPU cluster may change. In some examples, leakage power (e.g., leakage 520/522) is non-linear with temperature, and as a result, power management features that allow for more aggressive management of temperature for safe designated ECUs than non-safe designated ECUs may result in improved system performance under a constrained power budget for safe designated ECUs. Prior to activating the CPU cluster for safe power management, while still in non-safety operation, the software (e.g., APSS) may generate and configure the updated power and limits features for the CPU cluster. The updated configuration may then be loaded into the CPU cluster.
In another example, in the first drive mode 502a, a GPU cluster may be allocated to an ADAS/multi-media workload, which is a safety critical workload 508a. When the vehicle is put into park (e.g., at the boundary between Drive Mode 1 and Drive Mode 2), the GPU cluster may be re-allocated to support a gaming workload (IVI GPU), which is a non-safety critical workload 504a. As a result of the re-allocation of the GPU cluster, the power and limits features configuration applied to the GPU cluster may change. Prior to activating the GPU cluster for non-safety power management, while still in safety operation, the software (e.g., APSS) may generate and configure the updated power and limits features for the GPU cluster (e.g., power budget control (TDP limit) and any resulting throttling and limiting configuration). The updated configuration may then be loaded into the GPU cluster.
A third drive mode 602c (e.g., Drive Mode 3) may correspond to a standby mode of the vehicle with active cooling of the vehicle. In this third drive mode 602c, the TDP budget is allocated equally to safety critical (mission critical) workloads 608c and non-safety critical (discretionary) workloads 604c, while a portion is still spent on leakage 606c. However, not all of the TDP budget is needed for the running workloads and therefore, not all of the TDP budget is allocated. A fourth drive mode 602d (e.g., Drive Mode 4) may correspond to a parked mode of the vehicle with active cooling of the vehicle. In this fourth drive mode 602d, a larger portion of the TDP budget may be allocated to non-safety critical workloads 604d than safety critical workloads 608d with a portion of the TDP budget being spent on leakage 606d.
A fifth drive mode 602e (e.g., Drive Mode 5) may correspond to a parked mode of the vehicle without active cooling. In this fifth drive mode 602e, a larger portion is spent on leakage 606e without the active cooling. A sixth drive mode 602f may correspond to a deep sleep mode of the vehicle with the surveillance mode activated. In this sixth drive mode 602f, the TDP budget allocated to safety critical (mission critical) workloads 608f and non-safety critical (discretionary) workloads 604f are greatly reduced, with a relative larger portion spent on leakage 606f for the surveillance mode. However, not all of the TDP budget is needed for the running workloads and therefore, not all of the TDP budget is allocated. A seventh drive mode 602g (e.g., Drive Mode 7) may correspond to a deep sleep mode of the vehicle without the surveillance mode being activated. In this seventh drive mode 602g, no TDP budget is allocated to safety/non-safety critical workloads. Instead, a small portion is spent on leakage 606g.
At the boundary between each drive mode state change, the TDP budget may first be allocated to the safety critical workloads, and then the remaining TDP budget may be shared among the non-safety critical workloads with corresponding power and limit features applied. In this way, the TDP power budget may be controlled, thereby maximizing performance within a constrained TDP budget of the SoC.
The APSS 802 may include a HLOS that communicates with one or more virtual machines (e.g., primary virtual machine (PVM) 804 and guest virtual machine (GVM) 806) via a hypervisor 808. The hypervisor 808 may map VMs 804 and 806 to physical SoC hardware (e.g., ECUs 814a, 814b, and 814c). The VMs 804 and 806 may then schedule workloads to be run on the mapped ECUs 814a, 814b, 814c.
The APSS/HLOS 802 may further be configured to identify a respective safe designation for each ECU 814a, 814b, and 814c and generate a respective configuration 816a-816c of one or more power features and/or one or more limit features for each of the ECUs 814a, 814b, and 814c based on respective ECU policies and hardware constraints. For example, the APSS/HLOS 802 may determine the power and limit features for a particular ECU 814a based on the safe designation of that ECU 814a, where those power and limit features may be constrained by the hardware FuSa qualifications of the ECU 814a.
In some examples, the APSS/HLOS 802 may identify the respective safe designation for each of the ECUs 814a-814c based on a drive mode of a vehicle containing the SoC 800 and/or an SoC operation stage of the SoC 800. For example, the APSS/HLOS 802 may access respective ECU policies (e.g., which may be stored, for example, in memory 110 shown in
In other examples, the APSS/HLOS 802 may identify a respective safe designation for each of the ECUs based on the respective workload associated with (scheduled/running on) each of the ECUs 814a-814c and respective ECU policies. For example, the safe designation of a workload may be identified based on the safe designation of the VM that scheduled the workload. The workload safe designation may then be applied to the ECU (e.g., ECU 814a) running that workload in accordance with ECU policies that allow that safe designation. The APSS/HLOS 802 may further generate a respective configuration of power features and/or limit features for each of the ECUs 814a-814c based on respective ECU policies and the identified respective safe designations. At the boundary between drive modes and/or SoC operation stages, the hypervisor 808 may re-allocate an ECU (e.g., ECU 814a) to a different workload/VM 804/806. The APSS/HLOS 802 may then update the safe designation of the ECU 814a based on the different workload and ECU policies and generate a new configuration of power and/or limit features for the ECU 814a based on the updated safe designation and ECU policies.
The APSS/HLOS 802 may then provide the respective safe designation and associated configuration 816a-816c for each of the ECUs 814a-814c to the processing device 812 via software communication interface 822. The processing device 812 may then load the respective safe designations and corresponding configurations 816a-816c into the appropriate ECUs 814a-814c via respective software communication interfaces 824a-824c. The processing device 812 may further be configured to calculate the redistribution of the TDP budget to each of the ECUs 814a-814c based on the respective safe designations and associated configurations of each of the ECUs 814a-814c. For example, the processing device 812 may distribute the respective TDP limits to each of the ECUs 814a-814c via the same software communication interfaces 824a-824c used to provide the safe designations and corresponding configurations. In some examples, the APSS/HLOS 802 may load the respective safe designations and corresponding configurations 816a-816c directly into each of the ECUs 814a-814c without first providing the safe designations and corresponding configurations to the processing device 812.
In some examples, the APSS/HLOS 802 may distribute the respective safe designations and associated configurations to each of the ECUs 814a-814c through the hypervisor 808 via a secure channel 810. The secure channel 810 may be configured to prevent hacking of the safe designations and associated configurations, which could lead to an SoC crash due to performance or thermal implications. The secure channel 810 may be implemented using any suitable secure design.
The APSS/HLOS 802 may further manage power to each of the ECUs 814a-814c via respective power management software communication interfaces 826a-826c. For example, the APSS/HLOS 802 may configure the RMU 114 shown in
The application layer 902 further includes a selection and loading module 920 (e.g., software module) that is configured to receive a current drive mode and/or SoC operation stage (e.g., Drive Mode 1) 922 of the vehicle/SoC. Based on the current drive mode (Drive Mode 1) 922, the selection and loading module 920 may access the table 910 to retrieve the respective safe designation 916 and corresponding configuration 918 for each of the ECUs 912 for the current drive mode 922. The selection and loading module 920 may then be configured to load the respective safe designation 916 and corresponding configuration 918 into each of the ECUs 904.
The application layer 1002 further includes generating and loading modules 1008a, 1008b, . . . , 1008N (e.g., software modules) that are configured to receive the respective safe designations 1016a, 1016b, . . . , 1016N of each of the ECUs 1004. The generate and loading modules 1008a, 1008b, . . . , 1008N are further configured to generate a respective ECU configuration 1018a, 1018b, . . . , 1018N for each of the ECUs 1004 based on respective ECU policies 1014a, 1014b, . . . , 1014N for each of the ECUs 1004. Each respective ECU configuration 1018a, 1018b, . . . , 1018N may include a respective configuration of one or more power features and/or one or more limit features. The generate and loading modules 1008a, 1008b, . . . , 1008N are further configured to load the respective safe designations 1016a, 1016b, . . . , 1016N and corresponding configurations 1018a, 1018b, . . . , 1018N into each of the ECUs 1004.
At block 1102, the process begins with identifying a respective safe designation for each of a plurality of electronic control units (ECUs) on an SoC of a vehicle. The respective safe designation may be one of a safety critical designation or a non-safety critical designation. In some examples, a first ECU of the plurality of ECUs on the SoC is configured to run a first workload with the safety critical designation and a second ECU of the plurality of ECUs on the SoC is configured to run a second workload with the non-safety critical designation. In some examples, at least one of the safety critical designation or the non-safety critical designation includes performance requirements related to run-time deadlines. In some examples, an ECU of the plurality of ECUs includes a cluster of multiple ECUs of a same type. For example, the controller 108 and memory 110 shown and described above in connection with
At block 1104, the process continues with loading a respective configuration of at least one of a power feature or a limit feature into each of the plurality of ECUs based on the respective safe designation. In some examples, the respective configuration is based on a respective original equipment manufacturer (OEM) configuration for each of the safety critical designation and the non-safety critical designation for each of the plurality of ECUs. In some examples, the power feature includes one or more of an active power feature or an idle power feature, and the limit feature includes one or more of a temperature limit, a power limit, a current limit, a voltage limit, or a thermal design power (TDP) limit. For example, the controller 108 and memory 110 shown and described above in connection with
At block 1202, the process begins with identifying a respective safe designation for each of a plurality of electronic control units (ECUs) on an SoC of a vehicle. The respective safe designation may be one of a safety critical designation or a non-safety critical designation. In some examples, a first ECU of the plurality of ECUs on the SoC is configured to run a first workload with the safety critical designation and a second ECU of the plurality of ECUs on the SoC is configured to run a second workload with the non-safety critical designation. In some examples, at least one of the safety critical designation or the non-safety critical designation includes performance requirements related to run-time deadlines. In some examples, an ECU of the plurality of ECUs includes a cluster of multiple ECUs of a same type. For example, the controller 108 and memory 110 shown and described above in connection with
At block 1204, the process continues with modifying the respective safe designation of at least one ECU of the plurality of ECUs in response to a change of at least one of a vehicle drive mode of the vehicle or an SoC operation stage. In some examples, the SoC operation stage includes one of a boot stage, a run stage, a sleep stage, or a power-down stage. In some examples, the vehicle drive mode includes one of a parked mode, a stopped mode, or a driving mode, each associated with cooling or without cooling of the vehicle. For example, the controller 108 and memory 110 shown and described above in connection with
At block 1206, the process continues with generating a respective configuration of at least one of a power feature or a limit feature for each of the plurality of ECUs based on the respective safe designation associated with at least one of the vehicle drive mode or the SoC operation stage. In some examples, the respective configuration for each of the plurality of ECUs may be statically generated based on a respective original equipment manufacturer (OEM) safe designation associated with at least one of the vehicle drive mode or the SoC operation stage for each of the ECUs. In some examples, the respective configuration for each of the plurality of ECUs may be dynamically generated a respective workload running on each of the plurality of ECUs at a boundary between respective SoC operation stages or respective vehicle drive modes, the respective workload being associated with one of the safety critical designation or the non-safety critical designation.
In some examples, the respective configuration is based on a respective original equipment manufacturer (OEM) configuration for each of the safety critical designation and the non-safety critical designation for each of the plurality of ECUs. In some examples, the power feature includes one or more of an active power feature or an idle power feature, and the limit feature includes one or more of a temperature limit, a power limit, a current limit, a voltage limit, or a thermal design power (TDP) limit. For example, the controller 108 and memory 110 shown and described above in connection with
At block 1208, the process continues with loading the respective configuration into each of the plurality of ECUs. In some examples, the respective configuration for each of the plurality of ECUs is distributed from an application layer to the plurality of ECUs via a secure channel. In some examples, a processing device may receive the respective safe designation and the respective configuration for each of the plurality of ECUs and load the respective safe designation and the respective configuration into each of the plurality of ECUs. In addition, the processing device may allocate a respective thermal design power (TDP) budget to each of the plurality of ECUs based on the respective configuration for each of the plurality of ECUs. For example, the controller 108 and memory 110 shown and described above in connection with
In one configuration, an apparatus includes means for identifying a respective safe designation for each of a plurality of electronic control units (ECUs) on an SoC of a vehicle, the respective safe designation being a safety critical designation or a non-safety critical designation, and means for loading a respective configuration of at least one of a power feature or a limit feature into each of the plurality of ECUs based on the respective safe designation. In one aspect, the aforementioned means may be the controller 108 and memory 110 shown in
Of course, in the above examples, the controller is merely provided as an example, and other means for carrying out the described functions may be included within various aspects of the present disclosure, including any other suitable apparatus or means described in any one of the
The following provides an overview of aspects of the present disclosure:
Within the present disclosure, the word “exemplary” is used to mean “serving as an example, instance, or illustration.” Any implementation or aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects of the disclosure. Likewise, the term “aspects” does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation. The term “coupled” is used herein to refer to the direct or indirect coupling between two objects. For example, if object A physically touches object B, and object B touches object C, then objects A and C may still be considered coupled to one another-even if they do not directly physically touch each other. For instance, a first object may be coupled to a second object even though the first object is never directly physically in contact with the second object. The terms “circuit” and “circuitry” are used broadly, and intended to include both hardware implementations of electrical devices and conductors that, when connected and configured, enable the performance of the functions described in the present disclosure, without limitation as to the type of electronic circuits, as well as software implementations of information and instructions that, when executed by a processor, enable the performance of the functions described in the present disclosure.
One or more of the components, steps, features and/or functions illustrated in
Any reference to an element herein using a designation e.g., “first,” “second,” and so forth does not generally limit the quantity or order of those elements. Rather, these designations are used herein as a convenient way of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements can be employed, or that the first element must precede the second element.
It is to be understood that the specific order or hierarchy of steps in the methods disclosed is an illustration of exemplary processes. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the methods may be rearranged. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented unless specifically recited therein.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. A phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a; b; c; a and b; a and c; b and c; and a, b and c. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.”
