Patent Description:
This application also claims priority to <CIT>.

This application relates generally to power management of an electronic device (e.g., having a system on a chip (SoC)), particularly to methods, systems, and non-transitory computer-readable media for monitoring and controlling power consumption and device performance of an SoC-based electronic device.

An electronic device oftentimes integrates a system on a chip (SoC) with a power management integrated circuit (PMIC), communication ports, external memory or storage, and other peripheral function modules on a main logic board. The SoC includes one or more microprocessor or central processing unit (CPU) cores, memory, input/output ports, and secondary storage in a single package. The PMIC is typically disposed adjacent to the SoC on the main logic board and provides multiple direct current (DC) power supply rails to the SoC via conductive wires formed on the main logic board. The PMIC provides a plurality of power rails configured to drive operations of the SoC. Power characteristics (e.g., power consumption, current, and voltage) are monitored and controlled for each power rail and a corresponding portion of the SOC. It would be beneficial to have a more efficient and flexible power management mechanism than the current practice. Attention is drawn to <CIT> describing that a processor comprises: a plurality of cores each to execute instructions; a plurality of thermal sensors, at least one of which is associated with each of the cores; and a power control unit (PCU) coupled to the cores. The PCU includes a thermal control logic to preemptively throttle a first core by a first throttle amount when a temperature of a second core exceeds at least one thermal threshold. Note that this first core may be preemptively throttled independently of a throttling of the second core and may have a temperature of the first core does not exceed any thermal threshold.

To address power management issues of an SoC-based electronic device, it would be highly desirable to provide a semiconductor device or system with a plurality of distributed power sensors and a power management engine in addition to a plurality of processor clusters, cluster memory or cache, PMIC, and system memory. Various implementations of systems, methods and devices within the scope of the appended claims each have several aspects, no single one of which is solely responsible for the attributes described herein. Without limiting the scope of the appended claims, after considering this disclosure, and particularly after considering the section entitled "Detailed Description" one will understand how the aspects of various implementations are used to provide a semiconductor device with a dynamic power management hierarchy configured to control power management of the semiconductor device at a desirable control rate from a firmware level and/or a hardware level. Specifically, the power management engine is configured to collect power samples from the distributed power sensors, generate power profiles and power throttling thresholds from the power samples, implement a global firmware-level power control operation by determining power budgets among different power domains and enabling global and local hardware-level power control operations (e.g., a local throttling action) on the different power domains.

In this application, "power" may broadly refer to any power-related characteristics. For example, power samples include temperatures, power consumptions, current values, or a combination thereof, and power sensors include any of temperature, power consumption, and current sensors. Power profiles can be any of temperature, power consumption, and current profiles. Power control operations are applied to control temperature, power consumption, or current profiles.

In one aspect, a power management method is implemented at a processor system having a plurality of domains. The method includes collecting a plurality of power samples from the plurality of domains over a time duration, wherein each power sample includes at least one of temperature, power consumption, and current values associated with a respective domain. The method further includes combining a subset of the plurality of power samples of the plurality of domains to generate a system temperature profile including a plurality of system temperature values and determining whether the system temperature profile satisfies a first criterion. The method further includes in accordance with a determination that the system temperature profile satisfies the first criterion at a first time, at a predefined controlling frequency, in real time, determining whether a respective system temperature value of the system temperature profile satisfies a second criterion or a third criterion. The method further includes in accordance with a determination that the respective system temperature value satisfies a second criterion, determining power budgets of the plurality of domains on a firmware level and enabling operations of the plurality of domains according to the power budgets. The method further includes in accordance with a determination that the respective system temperature value satisfies a third criterion, selecting a subset of domains and applying a respective power throttling action to each of the subset of domains directly on a hardware level.

In another aspect, a power management method is implemented at a processor system having a plurality of domains. The method includes collecting a plurality of power samples from the plurality of domains over a time duration, and each power sample includes at least one or temperature, power consumption, and current values associated with a respective domain. The method further includes combining a subset of the plurality of power samples of the plurality of domains to generate a system power profile including a plurality of system power values and determining whether the system power profile satisfies a first criterion. The method further includes, in accordance with a determination that the system power profile satisfies the first criterion at a first time, at a predefined controlling frequency, in real time, determining whether a respective system power value of the system power profile satisfies a second criterion or a third criterion. The method further includes, in accordance with a determination that the respective system power value satisfies the second criterion, determining power budgets of the plurality of domains on a firmware level and enabling operations of the plurality of domains according to the power budgets. The method further includes, in accordance with a determination that the respective system power value satisfies the third criterion, selecting a subset of domains and applying a respective power throttling action to each of the subset of domains on a hardware level.

In yet another aspect, an electronic system includes one or more processor clusters, first memory (e.g., a cache <NUM> in <FIG>), power management integrated circuit (PMIC), and second memory (e.g., memory <NUM> in <FIG>). A plurality of power sensors is distributed on the electronic system and configured to collect or preprocess a plurality of power samples from a plurality of power domains. Each power sample includes at least one of temperature, power consumption, and current values associated with a respective power domain. A power management engine is coupled to the plurality of power sensors and configured to receive the plurality of power samples from the plurality of power domains and process the power samples based on locations of the corresponding power sensors to generate one or more power profiles and a plurality of power throttling thresholds. The power management engine is configured to implement a global power control operation having a first rate based on the one or more power profiles by determining power budgets of a plurality of power domains on a firmware level and enabling operations of the plurality of power domains according to the power budgets. The power management engine is also configured to based on the one or more power profiles, enable the plurality of power domains to implement a plurality of local power control operations based on the plurality of power throttling thresholds on a hardware level. The local power control operations have second rates greater than the first rate.

These illustrative embodiments and implementations are mentioned not to limit or define the disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there. Other implementations and advantages may be apparent to those skilled in the art in light of the descriptions and drawings in this specification.

For a better understanding of the various described implementations, reference should be made to the Detailed Description below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures. Like reference numerals refer to corresponding parts throughout the drawings.

Reference will now be made in detail to specific embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting specific details are set forth in order to assist in understanding the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that various alternatives may be used without departing from the scope of claims and the subject matter may be practiced without these specific details.

Various embodiments of this application are directed to a dynamic power management hierarchy configured to control power management of a semiconductor device (e.g., an SoC) at a desirable control rate from a firmware level and/or a hardware level. Specifically, the power management engine is configured to collect power samples from the distributed power sensors, generate power profiles and power throttling thresholds from the power samples, implement a global firmware-level power control operation by determining power budgets among different power domains and enabling global and local hardware-level power control operations (e.g., a local throttling action) on the different power domains. Compared with such a dynamic power management hierarchy, existing solutions monitor and control power characteristics (e.g., power consumption, current, and voltage) for each power rail and a corresponding portion of the SOC. The dynamic power management hierarchy offers a more efficient and flexible power management mechanism.

<FIG> is a block diagram of an example system module <NUM> in a typical electronic device, in accordance with some implementations. System module <NUM> in this electronic device includes at least a system on a chip (SoC) <NUM> having one or more processors, memory modules <NUM> for storing programs, instructions and data, an input/output (I/O) controller <NUM>, one or more communication interfaces such as network interfaces <NUM>, and one or more communication buses <NUM> for interconnecting these components. In some implementations, I/O controller <NUM> allows SoC <NUM> to communicate with an I/O device (e.g., a keyboard, a mouse or a touch screen) via a universal serial bus interface. In some implementations, network interfaces <NUM> include one or more interfaces for Wi-Fi, Ethernet and Bluetooth networks, each allowing the electronic device to exchange data with an external source, e.g., a server or another electronic device. In some implementations, communication buses <NUM> include circuitry (sometimes called a chipset) that interconnects and controls communications among various system components included in system module <NUM>.

In some implementations, memory modules <NUM> include high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices. In some implementations, memory modules <NUM> include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. In some implementations, memory modules <NUM>, or alternatively the non-volatile memory device(s) within memory modules <NUM>, include a non-transitory computer readable storage medium. In some implementations, memory slots are reserved on system module <NUM> for receiving memory modules <NUM>. Once inserted into the memory slots, memory modules <NUM> are integrated into system module <NUM>.

In some implementations, system module <NUM> further includes one or more components selected from:.

It is noted that communication buses <NUM> also interconnect and control communications among various system components including components <NUM>-<NUM>.

One skilled in the art knows that other non-transitory computer readable storage media can be used, as new data storage technologies are developed for storing information in the non-transitory computer readable storage media in the memory modules <NUM> and in SSDs <NUM>. These new non-transitory computer readable storage media include, but are not limited to, those manufactured from biological materials, nanowires, carbon nanotubes and individual molecules, even though the respective data storage technologies are currently under development and yet to be commercialized.

In some implementations, SoC <NUM> is implemented in a semiconductor package including one or more integrated circuits, and each integrated circuit integrates a subset of: one or more microprocessor or CPU cores, memory, input/output ports and secondary storage on a single substrate. PMIC <NUM> is also implemented in a semiconductor package including one or more integrated circuits each of which is formed on a single substrate. SoC <NUM> is configured to receive one or more internal supply voltages (also called rail voltages) provided by PMIC <NUM> via one or more power rails. In some implementations, both SoC <NUM> and PMIC <NUM> are mounted on a main logic board, e.g., on two distinct areas of the main logic board, and electrically coupled to each other via conductive wires formed in the main logic board. This arrangement introduces parasitic effects and electrical noise that could compromise performance of the SoC, e.g., cause a voltage drop at an internal supply voltage. Alternatively, in accordance with various implementations described below, semiconductor dies of SoC <NUM> and PMIC <NUM> are vertically packaged in an integrated semiconductor device <NUM> (e.g., in <FIG>), such that they are electrically coupled to each other via electrical connections that are not formed in the main logic board. Such vertical arrangement of the semiconductor dies of SoC <NUM> and PMIC <NUM> reduces a length of electrical connections between SoC <NUM> and PMIC <NUM> and avoids performance degradation caused by routing conductive wires on the main logic board.

In some implementations, a generic PMIC <NUM> is configured to drive different types of SoC <NUM> in different types of electronic devices. Regardless of whether PMIC <NUM> and SoC <NUM> are arranged side by side or vertically, PMIC <NUM> occupies the same footprint with respect to the main circuit board, while SoC <NUM> may have a distinct footprint based on the electronic modules integrated therein. PMIC <NUM> includes a plurality of voltage regulator units that are arranged in a field programmable array. The plurality of voltage regulator units are identical to each other, or includes more than one type of voltage regulator units. In a specific electronic device, control signals are determined based on rail voltages and rail currents of power rails required to power SOC <NUM> and other electronic modules, if any. For each of these power rails, a corresponding control signal is used to select a subset of voltage regulator units in the field programmable array of PMIC <NUM>, and the selected voltage regulator units provide a rail current at a rail voltage to the respective power rail collectively. As such, PMIC <NUM> is reconfigured by these control signals to provide the rail voltages and currents to the power rails of SoC <NUM>, and each voltage regulator unit in a plurality of configurable voltage regulators in PMIC <NUM> is either redundant or selected to drive one of the power rails by one of the control signals.

<FIG> is a block diagram of an example electronic device <NUM> having one or more processing clusters <NUM> (e.g., first processing cluster <NUM>-<NUM>, M-th processing cluster <NUM>-M), in accordance with some implementations. Electronic device <NUM> further includes a cache <NUM> and a memory <NUM> in addition to processing clusters <NUM>. Cache <NUM> is coupled to processing clusters <NUM> on SOC <NUM>, which is further coupled to memory <NUM> that is external to SOC <NUM>. Each processing cluster <NUM> includes one or more processors (also called processing cores) <NUM> and a cluster cache <NUM>. Cluster cache <NUM> is coupled to one or more processors <NUM>, and maintains one or more request queues for one or more processors <NUM>. In some implementations, each processor <NUM> further includes a core cache (not shown in <FIG>) that is optionally split into an instruction cache and a data cache, and core cache stores instructions and data that can be immediately executed by the respective processor <NUM>. In an example, first processing cluster <NUM>-<NUM> includes first processor <NUM>-<NUM>. , N-th processor <NUM>-N, and first cluster cache <NUM>-<NUM>, where N is an integer greater than <NUM>. In some implementations, SOC <NUM> only includes a single processing cluster <NUM>-<NUM>. Alternatively, in some implementations, SOC <NUM> includes at least an additional processing cluster <NUM>, e.g., M-th processing cluster <NUM>-M. M-th processing cluster <NUM>-M includes a first processor,. , an N'-th processor, and an M-th cluster cache, where N' is an integer greater than <NUM>.

In some implementations, the one or more processing clusters <NUM> are configured to provide a central processing unit for an electronic device and are associated with a hierarchy of caches. For example, the hierarchy of caches includes three levels that are distinguished based on their distinct operational speeds and sizes. For the purposes of this application, a reference to "the speed" of a memory (including a cache memory) relates to the time required to write data to or read data from the memory (e.g., a faster memory has shorter write and/or read times than a slower memory), and a reference to "the size" of a memory relates to the storage capacity of the memory (e.g., a smaller memory provides less storage space than a larger memory). The core cache, cluster cache <NUM>, and cache <NUM> correspond to a first level (L1) cache, a second level (L2) cache, and a third level (L3) cache, respectively. Each core cache holds instructions and data to be executed directly by a respective processor <NUM>, and has the fastest operational speed and smallest size among the three levels of memory. For each processing cluster <NUM>, the cluster cache <NUM> is slower operationally than the core cache and bigger in size, and holds data that is more likely to be accessed by processors <NUM> of respective processing cluster <NUM>. The cache <NUM> is shared by the plurality of processing clusters <NUM>, and bigger in size and slower in speed than each core cache and cluster cache <NUM>.

The processing clusters <NUM> issue prefetch requests to extract the instructions and data to be held by each core cache from the cluster cache <NUM>, cache <NUM> or memory <NUM>. If the prefetch requests are satisfied by the cluster cache <NUM>, the cluster cache <NUM> provides the instructions and data to the respective core cache for execution by the processors <NUM>. Conversely, if the prefetch requests are not satisfied by the cluster cache <NUM>, the prefetch requests are sent to the cache <NUM> to extract the instructions and data. If the prefetch requests are satisfied by the cache <NUM>, the cache <NUM> provides the instructions and data to the cluster cache <NUM>, which further passes the instructions and data to the respective core cache for execution by the processors <NUM>. Conversely, if the prefetch requests are not satisfied by the cache <NUM>, the prefetch requests are sent to the memory <NUM> external to the SoC <NUM> to extract the instructions and data. The memory <NUM> provides the instructions and data to the cache <NUM>, which passes the instructions and data to the cluster cache <NUM> and then to the respective core cache.

Additionally, the processing clusters <NUM> issue memory access requests to write data into and read data from the cluster cache <NUM>, cache <NUM> or memory <NUM> during normal operation of each processing cluster. Each memory access request is passed sequentially from the cluster cache <NUM>, cache <NUM>, and memory <NUM>, until the respective memory access request reaches a target cache or memory. A data to be written into the target cache or memory is also passed sequentially from the cluster cache <NUM>, cache <NUM>, and memory <NUM>, until the respective data reach the target cache or memory. In contrast, a data read from the target cache or memory is provided directly to the respective core caches to be used by the processors <NUM>.

In various implementations of this application, operations of the processing clusters <NUM>, PMIC <NUM>, cache <NUM>, and memory <NUM> consume power and create heat on the electronic device <NUM>, and a power management engine <NUM><NUM> is applied to manage power consumptions of the electronic device <NUM> from both a firmware level and a hardware level. Specifically, the power management engine <NUM> is configured to receive the plurality of power samples from a plurality of power sensors distributed on an electronic device <NUM>. The SOC <NUM>, PMIC <NUM>, and memory <NUM> are partitioned to a plurality of power domains. The power samples are processed based on locations of the corresponding power sensors to generate one or more power profiles and a plurality of power throttling thresholds for the individual power domains. Each power profile is optionally a system power profile of the entire electronic device <NUM> or a combination of multiple domains (e.g., a processor cluster <NUM>, an SoC <NUM>) or a local power profile of an individual power domain (e.g., a processor <NUM>). Based on the one or more power profiles, the power management engine <NUM> implements a global power control operation having a first rate by determining power budgets among the plurality of power domains and enabling operations of the plurality of power domains according to the power budgets. Further, based on the local power profiles, the power management engine <NUM> enables a plurality of local power control operations having second rates on the plurality of power domains (e.g., the memory <NUM>, PMIC <NUM>, processing cluster <NUM>-M) based on the plurality of power throttling thresholds. The local power control operations are more direct than the global power control, and each second rate is greater than the first rate. For example, the first rate of the global power control operation is <NUM> and a corresponding thermal response lasts for <NUM>, while the second rate of the local power control operations is <NUM> and a corresponding thermal response lasts for <NUM>. By these means, the electronic device <NUM> enables a hierarchical scheme to manage power consumption from both a firmware level and a hardware level.

In some implementations, the one or more power profiles include a system power profile tracking an average power consumption or an average total current of a subset or all of the plurality of power domains of the electronic system. The power management engine <NUM> is configured to, in accordance with the system power profile, enable the global power control operation and the plurality of local power control operations based on a requirement for a power control rate, the first rate of the global power control operation, and the second rates of the local power control operations. If the requirement for the power control rate is faster than the first rate, then the local power control operations need to be implemented directly to reduce the power consumption or total current, i.e., by a "hard throttling" process implemented directly on the hardware level. If the requirement for the power control rate is less than the first rate, a global power control operation may be taken to adjust the power budgets (e.g., P-states of the power domains) and enable local power control operations based on the power budgets, i.e., by a "soft throttling" process initiated from the firmware level. The requirement for the power control rate is determined with reference to a maximal temperature TMAX, a maximal power consumption PMAX, and a maximal current value IMAX tolerated by the electronic system. By these means, the system power profile is controlled below a predefined upper limit for the subset or all of the plurality of power domains of the electronic system.

In some implementations, the one or more power profiles include a local current profile tracking a current of a first power domain. The power management engine <NUM> is configured to in accordance with the local current profile, enable the global power control operation and a local power control operation focused on the first power domain based on a requirement for a power control rate, the first rate of the global power control operation, and the second rates of the local power control operations. The requirement for the power control rate is determined with reference to a maximal temperature TMAX, a maximal power consumption PMAX, and a maximal current value IMAX tolerated by the first power domain. By these means, the local current profile is controlled below a predefined current limit for the first power domain.

<FIG> is a cross sectional view of an integrated semiconductor device <NUM>, in accordance with some implementations. Semiconductor device <NUM> integrates at least one SoC die <NUM> and at least one PMIC die <NUM> in a semiconductor package, and includes at least a package substrate <NUM> having a first surface 304A and a second surface 304B that is opposite to first surface 304A. SoC die <NUM> is disposed on first surface 304A of package substrate <NUM>, and PMIC die <NUM> is coupled to second surface 304B of package substrate <NUM>. In some implementations, a first interposer <NUM> is disposed between SoC die <NUM> and first surface 304A of package substrate <NUM>. In some implementations, a second interposer <NUM> is disposed between PMIC die <NUM> and second surface 304B of package substrate <NUM>. In some implementations, the integrated semiconductor device <NUM> is disposed on a printed circuit board (PCB) with memory <NUM> and a power management engine <NUM>. The power management engine <NUM> is configured to manage power consumption of an entire electronic system formed on the PCB on both a firmware level (i.e., a board level) and a hardware level (i.e., on an individual hardware level, such as on an SoC level and on a memory level). In some implementations, the integrated semiconductor device <NUM> includes one or more power domains, and the power management engine <NUM> is configured to manage power consumption of each individual power domain on the hardware level.

Package substrate <NUM> further includes a plurality of first via interconnects <NUM> that pass through a body of package substrate <NUM> and is exposed on both first and second surfaces 304A and 304B, respectively. PMIC die <NUM> is electrically coupled to SoC die <NUM> via the plurality of first via interconnects <NUM> of package substrate <NUM>. Specifically, PMIC die <NUM> includes a plurality of DC connections <NUM> configured to output a plurality of rail voltages, provided to power rails. When PMIC die <NUM> is mounted on second surface 304B of package substrate <NUM>, DC connections <NUM> are electrically coupled to the plurality of first via interconnects <NUM> of package substrate <NUM>. In some implementations, SoC die <NUM> includes a plurality of power connections <NUM> configured to receive the plurality of rail voltages. When SoC die <NUM> is mounted on first surface 304A of package substrate <NUM>, power connections <NUM> are electrically coupled to the plurality of first via interconnects <NUM> of package substrate <NUM>. As such, PMIC die <NUM> is configured to provide DC power (i.e., rail voltages and rail current of power rails) to SoC die <NUM> via DC connections <NUM> of PMIC die <NUM>, power connections <NUM> of SoC die <NUM>, and first via interconnects <NUM> of package substrate <NUM>. Further, by using very low impedance DC connections <NUM>, the quality of the DC power provided PMIC die <NUM> to SoC die <NUM> is substantially improved relative to systems in which PMIC die <NUM> and SoC die <NUM> are separately packaged and positioned side by side on a main circuit board.

In some implementations, a power management interface on PMIC die <NUM> is controlled by a master power management interface of SoC die <NUM>, and configured to receive digital power control signals from SoC die <NUM>. A subset of first via interconnects <NUM> is configured to transfer digital power control signals from SoC die <NUM> to PMIC die <NUM>.

SoC die <NUM> has a first footprint on package substrate <NUM>, and PMIC <NUM> has a second footprint on package substrate <NUM>. The first and second footprints at least partially overlap for the purposes of coupling DC connections <NUM> of PMIC die <NUM> and power connections <NUM> of SoC die <NUM> directly using the plurality of first via interconnects <NUM>. In some situations, the first footprint of SoC die <NUM> is larger than and entirely encloses the second footprint of PMIC die <NUM>. Alternatively, in some situations, the first footprint of SoC die <NUM> is offset from the second footprint of PMIC die <NUM>, but at least partially overlaps the second footprint of PMIC die <NUM>. DC connections <NUM> of PMIC die <NUM>, power connections <NUM> of SoC die <NUM>, and first via interconnects <NUM> of package substrate <NUM> are aligned and enclosed in an overlapped area of the first and second footprints.

In some implementations, integrated semiconductor device <NUM> further includes a cover <NUM> coupled to first surface 304A of package substrate <NUM>. Cover <NUM> is configured to conceal SoC die <NUM> and at least part of first surface 304A of package substrate <NUM>, thereby protecting SoC die <NUM> and at least part of first surface 304A. Further, in some implementations, cover <NUM> is made of an electrically conductive material and configured to be grounded to provide electrostatic shielding for SoC die <NUM> and any other circuit on first surface 304A, if completely concealed by cover <NUM>, or the part of first surface 304A concealed by cover <NUM>, if first surface 304A is only partially concealed by cover <NUM>. In some situations, cover <NUM> is made of a thermally conductive material configured to dissipate heat generated by SoC die <NUM>.

In some implementations, semiconductor device <NUM> further includes a socket substrate <NUM>. Socket substrate <NUM> has a third surface 318A facing second surface 304B of package substrate <NUM>. Package substrate <NUM> is electrically coupled to socket substrate <NUM> via a plurality of electrical connectors <NUM>. Specifically, second surface 304B of package substrate <NUM> includes a first area (e.g., a central area) to which PMIC die <NUM> is mechanically coupled and a second area (e.g., a peripheral area) where the plurality of electrical connectors <NUM> are located. In an example, the second area is adjacent to and surrounds the first area. It is noted that under some circumstances, semiconductor device <NUM> is provided with socket substrate <NUM>. However, under some circumstances, socket substrate <NUM> is fixed on a circuit board of the electronic device in <FIG>, and is not part of integrated semiconductor device <NUM>. Rather, semiconductor device <NUM> is a replaceable part that is provided to offer functions of a combination of PMIC die <NUM> and SoC die <NUM>.

In some implementations, third surface 318A of socket substrate <NUM> is substantially flat, and PMIC die <NUM> is disposed between second surface 304B of package substrate <NUM> and third surface 318A of socket substrate <NUM>. Alternatively, in some implementations, socket substrate <NUM> includes a recessed portion <NUM> that is formed on third surface 318A and configured to receive PMIC die <NUM> when PMIC die <NUM> is mechanically and electrically coupled to second surface 304B of package substrate <NUM>. In some situations, PMIC die <NUM> is suspended in recessed portion <NUM>, i.e., separated from a bottom surface of recessed portion <NUM> by an air gap. Alternatively, in some situations, PMIC die <NUM> comes into contact with the bottom surface of recessed portion <NUM> directly or via an intermediate layer (e.g., an adhesive layer, a thermal spreader layer, or a layer that is both adhesive and a thermal spreader).

In some implementations, semiconductor device <NUM> further includes one or more discrete electronic modules <NUM> (e.g., resistor, capacitor, inductor, transistors, and logic chip). Discrete electronic modules <NUM> may be electrically coupled in an input/output interface circuit of SoC die <NUM> to control input/output coupling for SoC die <NUM>. Optionally, a subset of discrete electronic modules <NUM> (e.g., components 330A) is disposed on first surface 304A of package substrate <NUM>. Each component 330A may be contained within cover <NUM> or located outside cover <NUM>. Optionally, a subset of discrete electronic modules <NUM> (e.g., components 330B) is mechanically coupled to second surface 304B of package substrate <NUM>. If a respective component 330B has a low profile (e.g., thinner than a length of electrical connectors <NUM>), component 330B may fit into a gap between second surface 304B of package substrate <NUM> and third surface 318A of socket substrate <NUM>. Otherwise, if component 330B does not have a low profile (e.g., thicker than the length of electrical connectors <NUM>), a respective component 330B can be received by recessed portion <NUM> of socket substrate <NUM> and disposed adjacent to PMIC die <NUM>.

SoC die <NUM> and PMIC die <NUM> are vertically arranged in semiconductor device <NUM>. Power connections <NUM> of SoC die <NUM> and DC connections <NUM> of PMIC die <NUM> are aligned and positioned in proximity to each other, thereby reducing parasitic resistance and capacitance coupled to each power rail that provides a rail voltage to SoC die <NUM>. It is noted that in some implementations, a plurality of PMIC dies <NUM> can be disposed in recessed portion <NUM> of socket substrate <NUM> and electrically coupled to one or more SoC dies <NUM> disposed on first surface 304A of package substrate <NUM>. For example, two PMIC die <NUM> are disposed in recessed portion <NUM> of socket substrate <NUM> to power four SoC dies <NUM> collectively. One of SoC dies <NUM> optionally corresponds to a microprocessor or CPU core or a cluster of microprocessor or CPU cores.

Additionally, in some implementations of this application, PMIC die <NUM> includes a field programmable array of voltage regulators that is configurable by control signals to drive different types of SoC dies <NUM>. In some situations, the same PMIC die <NUM>, package substrate <NUM>, and socket substrate <NUM> are used to support the different types of SoC dies <NUM>. Recessed portion <NUM> formed on socket substrate <NUM> has a fixed size to accommodate the same PMIC die <NUM>, and first via interconnects <NUM> that pass through the body of package substrate <NUM> have fixed locations. Alternatively, in some situations, while footprint sizes of package substrate <NUM> and socket substrate <NUM> are varied for the different types of SoC dies, the same PMIC die <NUM> allows recessed portion <NUM> and first via interconnects <NUM> of package substrate <NUM> to remain unchanged, thereby avoiding custom designing PMIC die <NUM> and the entire package for each individual type of SoC die <NUM>. As such, application of the field programmable array of voltage regulators in PMIC die <NUM> simplifies an assembly process and enhances cost efficiency of the semiconductor device <NUM>.

<FIG> is a block diagram of a processor system <NUM> of an electronic device including a plurality of distributed power sensors <NUM> and a power management engine <NUM>, in accordance with some implementations. The processor system <NUM> includes at least an SoC <NUM> and a power management engine <NUM>. The SoC <NUM> has at least one or more processing clusters <NUM>, system cache <NUM>, and one or more Peripheral Component Interconnects (PCIs) and socket-to-socket controller <NUM>. The SoC <NUM> is powered by one or more power rails that are powered by the PMIC <NUM>. Power consumptions of the SoC <NUM> can be directly monitored by the power sensors <NUM> and reported to the power management engine <NUM>.

The SoC <NUM> is optionally coupled to one or more additional components that include, but are not limited to, memory <NUM> external to the processing clusters <NUM>, PMIC <NUM> that is optionally integrated with the SoC <NUM>, a system control, manageability and debug (CMD) component, a security processor, and an input/output (I/O) controller <NUM> (see <FIG>, not depicted in <FIG>). In some implementations, these components of the processor system <NUM> are mounted on a circuit board. These components in the processor system <NUM> are also powered by a plurality of power rails provided by the PMIC <NUM>. Specifically, the PMIC <NUM> receives one or more input supply voltage and generates a plurality of power supply voltages to drive the plurality of power rails of the SoC <NUM>, memory <NUM>, PMIC <NUM>, PCIs <NUM>, and any other components in the processor system <NUM>. As such, the power management engine <NUM> may monitor power consumptions of the components of the processor system <NUM> directly from the power rails driven by the PMIC <NUM>.

The plurality of power sensors <NUM> are distributed on a subset of the processor system <NUM>, i.e., on one or more of the SoC <NUM>, memory <NUM>, PMIC <NUM>, PCIs <NUM>, system CMD component, security processor, I/O controller <NUM> (see <FIG>, not depicted in <FIG>), and the like. In some implementations, the power sensors <NUM> include a set of activity monitor units <NUM> (AMUs, also called telemetry sources) and a set of temperature sensors <NUM>. The AMUs <NUM> are configured to measure power consumptions, current values, or both associated with different power rails. In some embodiments, the AMUs <NUM> are configured to measure activity levels of the corresponding subset of the processor system <NUM>, and the activity levels are used to estimate the power consumptions and/or current values of the corresponding subset of the processor system <NUM>. The temperature sensors <NUM> are configured to measure temperature values locally at the domains wherein the temperature sensors are disposed. For example, in <FIG>, the SoC <NUM> includes three processing clusters 202A, 202B, and 202C, a system cache <NUM>, and a PCI or socket-to-socket controller <NUM>. Each of the processing clusters <NUM>, system cache <NUM>, and PCI or socket-to-socket controller <NUM> is coupled to one or more AMUs <NUM> configured to measure the power consumptions and/or current values of one or more power rails of the respective component and one or more temperature sensors <NUM> configured to measure the temperature values of the respective component.

In some implementations, a subset of AMUs <NUM> are adjacent to each other. One of the subset of AMUs <NUM> is a regional AMU (R-AMU) <NUM>, while other AMUs <NUM> in the subset are local AMUs <NUM>. The regional AMU <NUM> collects power samples from the local AMUs <NUM>, and optionally preprocess the collected power samples. For example, in the SoC <NUM>, the AMU 406B coupled to a power rail of the second processing cluster 202B acts as a regional AMU of the subset of AMUs 406A-406E that are distributed on the SoC <NUM>. The power samples collected from the subset of AMUs 406A-406E are optionally consolidated by the regional AMU 406B and sent to the power management engine <NUM>. In some implementations, a subset of temperature sensors <NUM> are adjacent to each other and subject to control of one of temperature sensors <NUM>, and the one of the subset of temperature sensors <NUM> is a temperature sensor hub <NUM>. For example, in the SoC <NUM>, the temperature sensor 408C coupled to the third processing cluster 202C acts as a temperature sensor hub of the subset of temperature sensors 408A-408E that are distributed on the SoC <NUM>. The temperature samples collected from the subset of temperature sensors 408A-408E are optionally consolidated by the temperature sensor hub 408C and sent to the power management engine <NUM>. In some situations, the temperature sensor hub 408C also collects and/or consolidates power samples from the AMUs <NUM> around the hub 408C, and the regional AMU 406B also collects and/or consolidates power samples from the temperature sensors <NUM> around the regional AMU 406B.

In some implementations, each processing cluster <NUM> includes a plurality of processors 204A-204D (also called processor cores <NUM>) and cluster cache <NUM>. A number of temperature sensors <NUM> are distributed on the processors <NUM> and cluster cache <NUM>. For example, each processor <NUM> has two temperature sensors <NUM>, and each cluster cache <NUM> has a single temperature sensor <NUM>. A temperature sensor hub <NUM> includes two controllers and is configured to consolidate the temperature samples collected by the temperature sensors <NUM> of the entire processing cluster <NUM>.

In some implementations, power samples (e.g., power consumption, current values, and temperature values) measured by the AMUs <NUM> or temperature sensors <NUM> are applied locally on the hardware level to control power consumption or current level of a corresponding processor <NUM> or a processing cluster <NUM>. For example, the power samples are compared directly with a current throttling threshold ITRT to disable operation of a processor <NUM> or vary a power performance state (P-state) of the processor <NUM> (e.g., switch among a set of different predefined P-states). The power samples may be averaged over a time window or across two or more distinct AMUs to obtain an averaged power sample. The averaged power sample is compared with the current throttle threshold ITRT to disable operation of the processor <NUM> or vary the P-state of the processor <NUM>. Such a local hardware-level power control operation is implemented on individual processors <NUM>, processor clusters <NUM>, and SoC <NUM>, except that the current throttle threshold ITRT may be predetermined by the power management engine.

The components coupled to the power management engine <NUM> are partitioned into a plurality of power domains. For example, an SoC <NUM><NUM>, a single processing cluster <NUM>, or a processor <NUM> is one of the domains. Each power domain has a respective set of power sensors <NUM> including one or more AMUs <NUM> and one or more temperature sensors <NUM>. In some implementations, both the one or more AMUs <NUM> and one or more temperature sensors <NUM> are physically located at the respective power domain. In some implementations, the one or more temperature sensors <NUM> are physically located at the respective power domain, while the one or more AMUs <NUM> are located at a portion of the PMIC <NUM> configured to provide the power rails to the respective power domain, and electrically coupled to the power rails on the PMIC <NUM>. In some implementations, the power samples collected from each power domain are pooled and sent to the power management engine <NUM> by a regional AMU <NUM> or a temperature sensor hub <NUM> according to a global pooling frequency.

The power management engine <NUM> includes an aggregator <NUM> and a throttle policy controller <NUM>. The aggregator <NUM> is configured to collect the power samples collected by the distributed power sensors <NUM> or power samples consolidated from the collected power samples. In some implementations, the aggregator <NUM> generates a system power profile indicating overall power performance of the entire processor system <NUM> or a combination of multiple power domains. An example of the system power profile is a system temperature profile (e.g., curve <NUM> in <FIG>) indicating a temporal variation of an average temperature of an entire SoC <NUM>. In some implementations, the aggregator <NUM> generates one or more local power profiles each indicating local power performance of an individual domain. For example, a local temperature profile of a processor <NUM> (e.g., curve <NUM> in <FIG>) indicates a temporal variation of an average temperature determined from all of the temperature sensors <NUM> of the processor 204A in <FIG>. In some implementations, the aggregator <NUM> defines and/or adjusts a plurality of power throttling thresholds for the plurality of domains. The throttle policy controller <NUM> is configured to provide each of the power throttling thresholds to a respective domain or a respective subset of domains to control power consumption of the respective domain or subset of domains.

In some implementations, each processor cluster <NUM> includes a global module <NUM> coupled to the one or more processors <NUM>, cluster cache <NUM>, and the plurality of power sensors <NUM>. The global module <NUM> is configured to collect the power samples measured by the power sensors <NUM> and/or the power samples consolidated by the temperature sensor hub <NUM> or regional AMU <NUM> and send the collected power samples to the aggregator <NUM> of the power management engine <NUM>. The global module <NUM> is also configured to receive the plurality of power throttling thresholds and control signals from the throttle policy controller <NUM> of the power management engine <NUM> and enable local power control operations including architecture throttling, clock throttling, performance point throttling, and activation of different predefined P-states. It is noted that, in some embodiments, throttling actions in each domain are controlled by the PDP <NUM> during a global power control operation and by the global module <NUM> during a local power control operation.

For clarification, in some embodiments, the global power control operations are implemented by the entire SoC <NUM> or by a processor cluster <NUM>, and involve the power management engine <NUM>. The local power control operations are implemented locally in each processor cluster <NUM> or each processor <NUM> of the processing cluster <NUM>, without involving the power management engine <NUM>. Alternatively, a regional power control operation refers to power control operations associated with a subset (not all) of adjacent power domains (e.g., each processor cluster <NUM> in <FIG>), and the local power control operations are limited to each individual domain (e.g., processor <NUM>).

<FIG> are block diagrams of power management systems <NUM> and <NUM> configured to manage power of an SoC-based electronic device on a firmware level and a hardware level, in accordance with some implementations, respectively. <FIG> illustrates a comprehensive power management scheme <NUM> in which power of an SoC-based electronic device <NUM> is managed on both a firmware level and a hardware level, in accordance with some implementations. As explained above with reference to <FIG>, the power management engine <NUM> is configured to enable both firmware-level and hardware-level power management tasks. Specifically, the power management engine <NUM> collects a plurality of power samples from a plurality of power domains <NUM> and generates one or more power profiles and a plurality of power throttling thresholds for the individual power domains <NUM>, and each power profile is optionally a system power profile of the entire electronic device <NUM> or a combination of multiple domains (e.g., a processor cluster <NUM>, an SoC <NUM>) or a local power profile of an individual power domain (e.g., a processor <NUM>). The plurality of power samples is measured by a plurality of power sensors <NUM> distributed across the domains or preprocessed from raw power samples measured by the power sensors <NUM>.

On the firmware level, the power management engine <NUM> implements a global power control operation having a first rate based on the one or more power profiles, e.g., by distributing (<NUM>) power budgets <NUM> among the plurality of power domains <NUM> and enabling operations of the plurality of power domains <NUM> according to the power budgets. Temporal lengths <NUM> of power management physical control loops (i.e., long control loops) range from tens of nanoseconds to several milliseconds. Typical temporal lengths <NUM> are in a range of <NUM> to <NUM>. In some implementations, the global power control operation is implemented jointly by the power management engine <NUM> and each domain's Power and Debug Processor (PDP) <NUM>. The global power control operation is implemented periodically according to a first loop period <NUM>, e.g., every <NUM> or faster for an event associated with the PDP <NUM>. In some implementations, the global power control operation includes selecting one of a plurality of predefined power performance states (P-states) <NUM> for each of a plurality of processors. Each of the P-states corresponds to predefined set of power and performance settings of the processors. The power budgets are distributed among the plurality of domains according to the predefined power and performance settings of the selected P-state <NUM> of each processor. In some implementations, the global power control operation includes determining what throttling operations to take on individual domains. The power management engine <NUM> provides the plurality of power throttling thresholds <NUM> to different power domains <NUM> and enables the domains to implement such throttling operations.

It is noted that in some implementations, the global power control operation is implemented in response to a local event occurring to a local power profile of a specific domain. The event may not be so critical that the response time associated with the global power control operation is sufficient to address the event. For example, an event occurring to a local power profile of a processor cluster <NUM> is associated with a PDP <NUM> of the processor cluster <NUM>, and can be resolved by the global power control operation that is implemented with a loop period corresponding to <NUM>.

On the hardware level, the individual domains <NUM> pre-load (<NUM>) the plurality of power throttling thresholds <NUM> set by the power management engine <NUM>, and implement the local power control operations (e.g., the throttling actions) without involving extended firmware-level operations in real time. Referring to <FIG>, the different power domains <NUM> monitored and controlled include two processing clusters 202A and 202B, a logic portion of the SoC <NUM>, memory <NUM>, and a socket-to-socket connector <NUM> (more specifically, a power rail VDD of the connector <NUM>). The power management engine <NUM> or an individual power domain <NUM> monitors a local power profile and enables one or more local power control operations having second rates on the individual power domain <NUM> (e.g., the memory <NUM>, PMIC <NUM>, processing cluster <NUM>-M) based on an associated power throttling threshold <NUM>. For example, a current of the processing cluster <NUM> is monitored to exceed a predefined high peak current IMAXH (e.g., <NUM> A) for a duration longer than a predefined short burst time tBS (e.g., <NUM>). A current control signal is generated for the individual power domain <NUM> or the PMIC <NUM><NUM> to request reduction of the current of the processing cluster <NUM>. The power throttling thresholds <NUM> (e.g., IMAXH) are predetermined for the local power control operations and can be applied to the individual domains <NUM> directly. No firmware-level power budget redistribution is needed in real time. In an example, a local power control operation is implemented periodically according to a second loop period <NUM>, e.g., every <NUM>, and temporal lengths <NUM> of corresponding power management control loops are approximately <NUM>. As such, individual domains' local power control operations respond more promptly on the hardware level than the global power control operation implemented on the firmware level.

In some implementations, for each domain <NUM>, a local power control operation includes a throttling action selected from architecture throttling, power rail scaling, and clock throttling. Architecture throttling is applied to periodically block traffic to the respective domain including DRAM or suppress high current spikes in the respective domain including a processor. Clock throttling is applied to reduce a clock frequency of the respective domain. Performance point throttling is applied to adjust the clock frequency and power supply voltages of the respective domain jointly. In some situations, voltage regulators coupled to respective power rails of the respective domain are adjusted to vary power supply voltages and associated current injected into the respective power rails.

Referring to <FIG>, in some implementations, the global power control operation and local power control operations are applied jointly and correspond to different priorities in different situations. Global power control operation typically requires total budget calculation, subdomain budget partition, or budget reallocation. In some situations, when operations of the plurality of power domains <NUM> are enabled according to the power budgets, domain specific control loops are optionally applied with higher level algorithms having long control loops and complex computation. The power management engine <NUM> is involved to control the domain specific control loops on the firmware level. This also explains why the first rate of the global power control operation is less than the second rates of the local power control operations. Alternatively, in some situations, when operations of the plurality of power domains <NUM> are enabled according to the power budgets, the power throttling thresholds <NUM> applied in the local power control operations are applied or predefined P-states <NUM> are loaded according to predefined operation condition policies, which can effectively enhance the first rate of the global power control operation.

In some implementations, a plurality of power samples are collected from a plurality of domains <NUM> according to a local sampling rate (e.g., <NUM> sample every <NUM>). Each local power profile includes a temporal sequence of local power samples, and each local power sample is combined from a respective subset of collected power samples of a respective domain according to a pooling rate. For example, each local power sample is an average of the respective subset of current samples measured for a current of a power rail of a processing processor <NUM>, and averaged over a time window having a predefined temporal length (e.g., <NUM>). Such data collection and averaging are implemented on the hardware level, i.e., by individual domains <NUM>, before or after the local power samples of each local power profile are reported to the power management engine <NUM>. Thus, in some implementations, the power management engine <NUM> has a period of a predefined controlling frequency that does not exceed the predefined temporal length. Local power control operations that are based on comparisons with power throttling thresholds have local controlling frequencies, and the local controlling frequencies do not exceed the predefined temporal length of the time window. The power management engine <NUM> is not directly involved in continuous periodic loops of local power value evaluation and power control on individual power domains, except that the power throttling thresholds <NUM> used in the local power control operation are predetermined by the power management engine <NUM> on the firmware level.

In some situations, a loop control time constant of the firmware's long control loop or the hardware's short control loop is dynamically adjusted. For example, when an SoC <NUM> temperature has risen close to a maximal temperature TMAX, the loop control time constant is reduced to enable close monitoring. If the loop control time constant is too short for the global power control operation, primary control is passed to the local power control operations by individual domains. More details on an example temperature control process are described below with reference to <FIG>. In some situations, the power management engine <NUM> reduces the power throttling thresholds <NUM> of individual domains <NUM> to capture excursions first. In some situations, power control windows are shorted to allow less generous opportunistic performance boosts in place of more stringent limits enforcement. In some situations, the power management engine <NUM> uses throttle levels and event monitoring to detect excessive throttling activation by individual domains <NUM> and modify power throttling thresholds under its purview to attain a more efficient operations.

Firmware-level power management control (<FIG>) by the power management engine <NUM> corresponds to a long control loop. Hardware-level power management control (<FIG>) by the individual domains corresponds to a short control loop. In the long control loop, hardware-level throttling mechanisms (e.g., implemented by the local power control operations) act as backup and fallback for the firmware-level power management control, thereby ensuring the plurality of domains <NUM> to comply with respective power limits, particularly, when the power management engine <NUM> has skipped a beat or when the long control loop has not properly identified an error size. In the short control loop, the hardware-level throttling mechanisms (e.g., implemented by the local power control operations) act as primary control agents and provide short time-duration loop enforcement and fast responses. For example, a multi-level throttling mechanism is applied to implement a level of hysteresis and complements the firmware-level power management control.

In some situations, power management is tasked with maximizing the electronic device's performance on an incoming instruction stream, based on a given set of operating system (OS) performance directives, under a given set of external constraints. The incoming instruction stream varies greatly per domain, among processing cores <NUM>, and even during execution from one program phase to another. The performance directives satisfy the OS performance level requirements and expectation. In some cases, the performance directives also satisfy performance and power preferences for each processing core <NUM> and/or cluster <NUM>. Constraints may vary (e.g., correspond to different time windows) among different devices and domains (e.g., SoC, memory <NUM>). Particularly, in an example, a processing core constraint has a time window that is too short to implement on a firmware level via the power management engine <NUM>, and the time window can only be accomplished by applying the processing core constraint directly on a corresponding processing core. As such, power management of an SoC-based electronic device requires a combination of hardware and firmware policies, tracking physical constraints, OS requirements and directives, and instruction stream characteristics to optimize performance and power tradeoffs.

In some implementations, an operating system uses a collaborative processor performance control (CPPC) infrastructure for requesting SoC performance changes. For example, the operating system and processors <NUM> of the SoC <NUM> can optimize power consumption through different p-states (power performance states), and the processors <NUM> are operated at different frequencies. A high-performance mode of a processor <NUM> reflects an absolute maximum performance the processor <NUM> may reach, assuming ideal conditions. This performance level does not sustain for long durations and may only be achievable by forcing other processors <NUM> or memory <NUM> into a specific state (e.g., an idle state). A nominal performance of a processor <NUM> reflects a maximum sustained performance level of the processor <NUM>, assuming ideal operating conditions. In the absence of an external constraint (power, thermal, etc.), this is the performance level that the SoC-based electronic device maintains continuously. In some implementations, all processors <NUM> sustain their nominal performance mode simultaneously. A guaranteed performance mode of a processor <NUM> reflects a current maximum sustained performance level of the processor <NUM>, taking into account all known external constraints (power budgeting, thermal constraints, DC or AC power source, etc.). In some implementations, all processors sustain their guaranteed performance levels simultaneously. The guaranteed performance level is required to fall in a performance range between a lowest performance level and a nominal performance level that corresponds to the nominal performance mode, inclusive. In some situations, the guaranteed performance mode is updated once per second to reflect thermal and power constraints.

A processor system is configured to monitor the throttling actions controlled by the power management engine <NUM> over time and collaborate with the power management engine <NUM> in real time to maximize performance of the entire processor system while keeping temperature/power usage of its power domains within predefined operating ranges. In some implementations, if the processor system determines that the power management engine <NUM> is taking excessive throttling actions (e.g., in excess of a predefined percentage over a time duration), the processor system may reassign processes to different clusters <NUM> and/or processors <NUM> or bring on-line additional clusters <NUM> and/or SOCs <NUM> to reduce globally excessive workloads. For example, in some implementations, such a situation is determined to exist if a substantial percentage of the processing clusters <NUM> have one or more domains with a measured temperate that is consistently above a predefined threshold temperature TSET.

<FIG> is a temporal diagram of device temperatures <NUM> of an electronic device including an SoC <NUM>, in accordance with some implementations. The electronic device is configured to monitor system temperature profiles <NUM> and <NUM> of an SoC <NUM> and a local temperature profile <NUM> of a processor <NUM>. Global and local power control operations are applied to adjust power consumptions and thermal responses of the SoC <NUM> or processor <NUM> under different conditions. When the SoC <NUM> operates at a predefined operation frequency (e.g., <NUM>), the temperature of the SoC <NUM> is configured to stabilize at a first threshold temperature TSET (e.g., <NUM>-<NUM>). In some implementations, temperature-based power control is applied to achieve stable performance close to the predefined operation frequency.

In some situations (e.g., associated with the profile <NUM>), the processors <NUM> of the SoC <NUM> are allowed to exceed power limits for short durations of time. The PMIC <NUM> can enhance a nominal current (e.g., ICC,nom) for a predefined time window (e.g., <NUM>ICC,nom for <NUM>-<NUM>, <NUM>ICC,nom for <NUM>). A maximal current tolerance ICC,MAX is disabled from limiting this enhanced current within the predefined time window. The temperature of the SoC <NUM> slowly increases towards a maximal temperature TMAX until a local power control operation <NUM> is applied to reduce a temperature increase rate. In some situations (e.g., associated with the profile <NUM>), bursts of instruction sequences occur and cause a sudden increase of power consumption and a sudden temperature increase. Such bursts of instruction sequences normally settle and return to normal processing levels within a duration of time, e.g., <NUM>-<NUM>. The temperature or power increase is monitored over a predefined window size LW corresponding to the duration of time. If the temperature or power increase exceeds a predefined limit, the increase is determined as excessive, and throttling actions are taken to suppress the temperature or power increase.

Specifically, a processor system (e.g., an SoC <NUM>) includes one or more processing clusters <NUM> each of which includes one or more processors <NUM>. The processors <NUM> of the SoC <NUM> are associated with a plurality of domains <NUM>. A plurality of power samples are measured for the plurality of domains <NUM>. In some embodiments, the plurality of power samples are averaged according to a global pooling rate at a local temperature sensor hub <NUM> or regional AMU <NUM>. The measured or averaged power samples are sent to a power management engine <NUM>. The power management engine <NUM> further processes the power samples associated with the plurality of domains to generate a system temperature profile <NUM>. The system temperature profile <NUM> tracks a temperature level of the SoC <NUM>, and therefore, includes a temporally-ordered sequence of system temperature values.

During normal operation of the SoC <NUM>, the power management engine <NUM> determines whether the system temperature profile <NUM> increases to and beyond the first temperature threshold TSET. If the system temperature profile <NUM> increases to and beyond the first temperature threshold TSET at a first time t<NUM>, the temperature values of the system temperature profile <NUM> are compared with a second temperature threshold TTH or a maximal temperature TMAX at a predefined controlling frequency (e.g., every <NUM>). If the respective system temperature value is between the first temperature threshold TSET and second temperature threshold TTH, a global power control operation is enabled to determine power budgets of the plurality of domains on a firmware level and enable operations of the plurality of domains according to the power budgets. If the respective system temperature value is greater than the second temperature threshold TTH or if the respective system temperature value is greater than the first temperature threshold TSET for longer than a threshold duration of time (e.g., <NUM>), a subset of domains are selected, and a respective power throttling action is applied to each of the subset of domains on a hardware level. By these means, when the respective system temperature value is greater than the second temperature threshold TTH or if the respective system temperature value is greater than the first temperature threshold TSET for longer than a threshold duration of time (e.g., <NUM>), a short power control loop is applied on the hardware level to control the temperature value of the SoC <NUM> below the maximal temperature TMAX.

For the system temperature profile <NUM>, two global power control operations 608A and 608B are applied on the firmware level within the threshold duration of time WT (e.g., <NUM>). The threshold duration of time WT is the longest duration of time allowed at a corresponding enhanced current of the SoC <NUM>. After the threshold duration of time WT, local power control operations <NUM> follow the two global power control operations 608A and 608B to control the temperature value of the SoC <NUM> at a faster rate. The global power control operations 608A and 608B have an example reaction time of <NUM>, and the local power control operations <NUM> have an example reaction time of <NUM>. In some embodiments, the temperature value of the system temperature profile <NUM> increases beyond a hard shutdown temperature THS, and a hard shutdown operation is applied to different power domains of the SoC <NUM> to cool down the SoC <NUM>.

Upon a burst of instructions in the SoC <NUM>, the system temperature profile <NUM> changes to an alternative system temperature profile <NUM> that has a greater temperature increase rate. In an example, the system temperature profiles <NUM> and <NUM> correspond to overall power consumptions of <NUM> W and <NUM> W by the SoC <NUM>, respectively. A predefined temperature increase limit ΔT in the predefined window size LW corresponds to an upper limit for a tolerable burst of instructions. In some implementations, the predefined temperature increase limit ΔT is programmable. Beyond the predefined temperature increase limit ΔT, prompt local power control operations (e.g., throttling actions) need to be applied. Specifically, in some implementations, a first temperature value T<NUM> and a second temperature value T<NUM> correspond to a start and an end of a time window having the predefined window size LW on the system temperature profile <NUM>, respectively. The first temperature value T<NUM> is optionally equal to the first threshold temperature TSET, while the second temperature value T<NUM> is less than the second threshold temperature TTH. A temperature difference between the first and second temperature values T<NUM> and T<NUM> is determined and compared with the predefined temperature increase limit ΔT, indicating whether a power surge occurs. If the temperature difference exceeds the predefined temperature increase limit ΔT, a subset of domains of the SoC <NUM> are selected, and a respective local power control operation (e.g., a power throttling action) is applied to each of the subset of domains on the hardware level. Examples of the respective power throttling action include architecture throttling, clock throttling, and performance point throttling. By these means, when the burst of instructions occurs in the SoC <NUM>, the temperature value of the SoC <NUM> cannot exceed the maximal temperature TMAX, and the local power control operation is applied to bring down the power consumption, e.g., from 900W to 700W.

During both normal operation and the burst of sequences of the SoC <NUM>, the local power control operations correspond to a short power control loop intended to address power bursts. The short power control loop ensures that the temperature value of the SoC <NUM> does not increase beyond the maximal temperature TMAX in the threshold duration of time WT following the first time t<NUM> when the SoC <NUM> reaches the first threshold temperature TSET. The global power control operations correspond to a long power control loop intended to maintain an average power level at a power limit corresponding to the first threshold temperature TSET.

Additionally, in some situations, the burst of instructions occurs to a specific processor <NUM> in a first domain <NUM> as well. A local power profile <NUM> of the first domain <NUM> is obtained based on a first subset of the plurality of power values collected at the first domain <NUM>. A predefined temperature increase limit ΔT' in the predefined window size LW also corresponds to an upper limit for a tolerable burst of instructions of the processor <NUM>. In some implementations, the predefined temperature increase limit ΔT' is programmable. Beyond the predefined temperature increase limit ΔT', prompt local power control operations (e.g., throttling actions) need to be applied to the first domain. In some implementations, a first temperature value T<NUM>' and a second temperature value T<NUM>' are identified on the local power profile <NUM>, and correspond to a start and an end of a time window having the predefined window size LW on the local power profile <NUM>, respectively. The first temperature value T<NUM>' is optionally equal to the first threshold temperature TSET, while the second temperature value T<NUM>' is less than the second threshold temperature TTH. A temperature difference is determined between the first and second temperature values and compared with the predefined temperature increase limit ΔT', indicating whether a power surge occurs to the processor <NUM> on the first domain <NUM>. If the temperature difference exceeds the predefined temperature increase limit, a local power control operation (e.g., a power throttling action) is applied to the processor <NUM> of the first domain on the hardware level.

The system temperature profiles <NUM> and <NUM> and local temperature profile <NUM> do not reflect real-time power consumption performance of a corresponding processor system, because a temperature response is always delayed from a power consumption or current experienced by and measured from the processor system. In some implementations not shown in <FIG>, a system power profile is generated to monitor power consumption or current values of an SoC over a time duration directly, and a local power profile is generated to monitor power consumption or current values of a first domain (e.g., a processor <NUM>) over a time duration directly. A power consumption or current increase (e.g., from P<NUM> to P<NUM>, from I<NUM> to I<NUM>) is monitored within the predefined window size LW to determine whether to initiate local power control operations (e.g., hard throttling) on a subset of domains or the first domain. Also, second and third criteria that are based on temperature are adjusted to be based on power consumption and current levels indicated by the system power profile. The second criterion is not as critical as the third criterion, and the corresponding power consumption and current levels allow "soft" throttling initiated from the firmware level. In contrast, the third criterion triggers "hard" throttling on the hardware level, thereby controlling the power consumption and current levels below an upper limit at a much faster rate than "soft" throttling.

In some situations, prior to the first time t<NUM>, the temperature value of the system temperature profile is compared with the first threshold temperature TSET constantly according to a temperature monitoring frequency. After the first time t<NUM>, such a comparison at the temperature monitoring frequency is suspended, while a comparison with the second threshold temperature TTH occurs with the predefined controlling frequency. In some implementations, when the respective system temperature value drops below the first temperature threshold TTH, the comparison operation is resumed, i.e., the temperature value of the system temperature profile is compared again with the first threshold temperature TSET constantly according to the temperature monitoring frequency. Also, when the respective system temperature value is below the first temperature threshold TTH, the temperature value of the system temperature profile is not compared with the second threshold temperature TTH according to the predefined controlling frequency.

It is noted that the plurality of power samples are collected from the first domain according to a local sampling rate (e.g., every <NUM>). Each system temperature value is combined from a respective subset of power samples of the plurality of domains according to a global pooling rate (e.g., every <NUM>). The local sampling rate is greater than the global pooling rate, and the global pooling rate is greater than the predefined controlling frequency (e.g., every <NUM>).

<FIG> is a flow diagram of a method <NUM> of managing power consumption of an SoC-based electronic device, in accordance with some implementations. The method <NUM> is implemented at a processor system having a plurality of domains. In some implementations, the processor system includes a plurality of processor units, one or more memory units, and power management integrated circuit (PMIC), and each of the plurality of domains includes a distinct subset of the processor system. A plurality of power samples are collected (<NUM>) from the plurality of domains over a time duration. Each power sample includes at least one of a temperature, power consumption, and current value associated with a respective domain. In an example, each power sample includes all of a temperature, power consumption, current value associated with a processor <NUM> at a specific time. Optionally, these power samples are measured by power sensors located at the plurality of domains and sent to a power management engine <NUM>. Optionally, power samples measured by power sensors are preprocessed at the domains, a hub (e.g., a regional AMU 406B and a temperature sensor hub 408C in <FIG>), or a global module <NUM>, and the preprocessed power samples are sent to the power management engine <NUM>. Optionally, a subset of the power samples are estimated, e.g., based on a set of power samples measured concurrently from adjacent power sensors or a history of power samples.

A subset of the plurality of power samples of the plurality of domains are combined (<NUM>) to generate a system temperature profile <NUM> including a plurality of system temperature values. The power management engine <NUM> determines (<NUM>) whether the system temperature profile <NUM> satisfies a first criterion. In accordance with a determination (<NUM>) that the system temperature profile <NUM> satisfies the first criterion at a first time t<NUM>, at a predefined controlling frequency, the power management engine <NUM> determines (<NUM>) whether a respective system temperature value of the system temperature profile <NUM> satisfies a second criterion or a third criterion in real time. In some implementations, the respective system temperature value belongs to a temporally-ordered sequence of system temperature values that are monitored subsequently to the first time t<NUM> on the system temperature profile <NUM> according to the predefined controlling frequency.

In accordance with a determination that the respective system temperature value satisfies a second criterion, the power management engine <NUM> determines (<NUM>) power budgets of the plurality of domains on a firmware level and enabling operations of the plurality of domains according to the power budgets. In some implementations, these operations include power throttling actions implemented on individual domains, and however, are initiated on the firmware level and correspond to long control loops, e.g., in a global power control operation 608A or 608B in <FIG>. In accordance with a determination that the respective system temperature value satisfies a third criterion, the power management engine <NUM> selects (<NUM>) a subset of domains and enables a respective power throttling action to each of the subset of domains directly on a hardware level. This power throttling action is initiated directly on the hardware level and correspond to a short control loop, e.g., in a local power control operation <NUM> in <FIG>. Specifically, in some implementations, for each of the subset of domains, the respective throttling action includes (<NUM>) one or more of: architecture throttling, power rail scaling, and clock throttling. Architecture throttling is applied to periodically block traffic to the respective domain including DRAM or suppress high current spikes in the respective domain including a processor unit. Clock throttling is applied to reduce a clock frequency of the respective domain. Performance point throttling is applied to adjust the clock frequency and power supply voltages of the respective domain jointly.

In some implementations, a first temperature value T<NUM> and a second temperature value T<NUM> are identified on the system temperature profile <NUM>, and correspond to a start and an end of a time window having a predefined window size LW, respectively. The power management engine <NUM> determines a temperature difference between the first and second temperature values and whether the temperature difference exceeds a predefined temperature increase limit. In some implementations, the predefined temperature increase limit is programmable. In accordance with a determination that the temperature difference exceeds the predefined temperature increase limit, which is optionally programmable, the subset of domains are selected to apply the respective power throttling action directly on the hardware level. The short control loops are applied to suppress the temperature increase, thereby ensuring that the temperature value does not cross a maximal temperature TMAX within threshold duration of time WT subsequent to the first time t<NUM>.

Alternatively, in some implementations, a first power value P<NUM> or I<NUM> and a second power value P<NUM> or I<NUM> are identified on a system power profile of power consumption or current values of the processor system (e.g., an SoC <NUM>), and correspond to a start and an end of a time window having a predefined window size LW, respectively. The power management engine <NUM> determines a power difference between the first and second power values and whether the power difference exceeds a predefined power increase limit, which is optionally programmable. In accordance with a determination that the power difference exceeds the predefined power increase limit, the subset of domains are selected to apply the respective power throttling action directly on the hardware level. The short control loops are applied to suppress a power or current burst, thereby ensuring that the power consumption or current value does not cross a maximal power PMAX or IMAX within a threshold duration of time WT subsequent to the first time t<NUM>.

In some implementations, a local power profile <NUM> is generated for a first domain (e.g., a processor <NUM>) based on a first subset of the plurality of power values collected at the first domain. A first temperature value T<NUM>' and a second temperature value T<NUM>' are identified on the local power profile <NUM>, and correspond to a start and an end of a time window having a predefined window size, respectively. A temperature difference is determined between the first and second temperature values T<NUM>' and T<NUM>' and compared with a predefined temperature increase limit. In some implementations, the predefined temperature increase limit is programmable. In accordance with a determination that the temperature difference exceeds the predefined temperature increase limit, a power throttling action is applied to the first domain directly on the hardware level. The short control loops are applied to suppress the temperature increase. Alternatively, in some implementations, the local power profile <NUM> is related to power consumption and current values of the first domain. A first power value P<NUM>' or I<NUM>' and a second power value P<NUM>' or I<NUM>' are identified on the local power profile <NUM>, and correspond to a start and an end of a time window having a predefined window size, respectively. A power difference is determined between the first and second power values and compared with a predefined power increase limit, which is optionally programmable. In accordance with a determination that the power difference exceeds the predefined power increase limit, a power throttling action is applied to the first domain directly on the hardware level. The short control loops are applied to suppress the power consumption or current increase.

In some implementations, for each of the subset of domains, the respective throttling action is associated with a throttling threshold for a subset of power values corresponding to the respective domain. In accordance with a predefined power management policy, the power management engine <NUM> determines the throttling threshold associated with the respective throttling action of the respective domain on the firmware level. In accordance with a determination that the subset of power values of the respective domain exceeds the throttling threshold, the respective domain implements the respective throttling action on the hardware level.

In some implementations, the power management engine <NUM> determines a total power budget for the entire processor system and dynamically assigns a respective portion of the total power budget to each of the plurality of domains. The power budgets of the domains are redistributed based on activity levels of the domains on the firmware level, and each domain is instructed to adjust its operation locally on the hardware level according to the assigned portion of the total power budget.

In some implementations, based on the respective system temperature value, one of a plurality of predefined power performance states (P-states) is selected for each of a plurality of processors, and each of the P-states corresponds to a predefined set of power and performance settings of the processors. The power budgets are redistributed among the plurality of domains according to the predefined set of power and performance settings of the selected P-state for each of the plurality of processors.

In some implementations, the first criterion requires that the system temperature profile increases to and beyond a first temperature threshold TSET at a corresponding time. The second criterion requires that a system temperature value at a corresponding time is between the first temperature threshold TSET and a second temperature threshold TTH. The third criterion requires that a system temperature value at a corresponding time is greater than the second temperature threshold TTH or that the system temperature value stays above the first temperature threshold TSET for an extended time longer than a threshold duration of time. The first temperature threshold TSET is less than the second temperature threshold TTH, the second temperature threshold TTH less than a maximal temperature TMAX below which the processor system is controlled.

In some implementations, prior to the first time t<NUM>, whether the system temperature profile satisfies the first criterion is monitored according to a temperature monitoring frequency. After the first time t<NUM>, the power management engine <NUM> suspends determining whether the system temperature profile satisfies the first criterion according to the temperature monitoring frequency. In accordance with a determination that the respective system temperature value is below the first temperature threshold TTH, the power management engine <NUM> resumes determining whether the system temperature profile satisfies the first criterion according to the temperature monitoring frequency, and aborts determining whether the respective system temperature value satisfies the second and third criteria according to the predefined controlling frequency.

In some implementations, the plurality of power samples are collected from the plurality of domains according to a local sampling rate. Each system temperature value is combined from a respective subset of power samples of the plurality of domains according to a global pooling rate. The local sampling rate is greater than the global pooling rate, and the global pooling rate is greater than the predefined controlling frequency.

In some implementations, each domain is powered by one or more power rails that are driven by PMIC. For each power rail, a respective set of current values are collected for each power rail. In accordance with a determination that the respective set of current values have been greater than a first threshold current for a first duration of time (e.g., <NUM>ICC,nom for <NUM>-<NUM>) greater than a second threshold current for a second duration of time (e.g., <NUM>ICC,nom for <NUM>), a power throttling action is implemented on the respective power rail of the respective domain. The first threshold current is greater than the second threshold current, and the first duration of time is shorter than the second duration of time.

Temperature profiles do not reflect real-time power consumption or current performance of a processor system, because a temperature response is delayed from power consumption or current values experienced by and measured from the processor system. In some situations, a power management method is implemented to manage power of a processor system having a plurality of domains based on a system power profile directly. The system power profile includes a plurality of system power values that are not limited to temperature values and may be current values or power consumption values. A plurality of power samples are collected from the plurality of domains over a time duration. Each power sample includes at least one of temperature, power consumption, and current value associated with a respective domain. A subset of the plurality of power samples of the plurality of domains are combined to generate a system power profile including a plurality of system power values (power consumptions or current values). A power management engine determines whether the system power profile satisfies a first criterion. In accordance with a determination that the system power profile satisfies the first criterion at a first time t<NUM>, the power management engine determines, at a predefined controlling frequency and in real time, whether a respective system power value of the system power profile satisfies a second criterion or a third criterion. In accordance with a determination that the respective system power value satisfies the second criterion, the power management engine determines power budgets of the plurality of domains on a firmware level, and enables operations of the plurality of domains according to the power budgets. In some embodiments, such operations my include throttling actions. In accordance with a determination that the respective system power value satisfies the third criterion, the power management engine determines selects a subset of domains and applies a respective power throttling action to each of the subset of domains on a hardware level.

The first criterion is associated with initiation of a critical performance regime in which power performance of the processor system needs to be closely monitored. Both the second and second criteria are more critical than the first criterion, while the second criterion is not as critical as the third criterion. When the second criterion is satisfied, head room from a performance limit (e.g., a maximal temperature TMAX, a largest power burst) is still available, allowing the power management engine <NUM> to apply the global power control operation to control the power performance of the processor system using "soft" throttling from the firmware level. In contrast, when the third criterion is satisfied, the head room from the performance limit is limited, and "hard" throttling actions have to be taken directly in the hardware level to reduce temperature, power consumption or current values immediately on individual domains. The first rate of firmware-level "soft" throttling (e.g., ~ <NUM>) is not as fast as the second rates of the hardware-level "hard" throttling actions (e.g., ~ <NUM>-<NUM>). As such, "soft" or "hard" throttling actions can be applied based on an urgency level of a power condition of the processor system as indicated by the system power profile (e.g., the system temperature profile <NUM> and <NUM>).

Different types of temperature, power consumption, and current profiles can be monitored jointly to control temperature, power consumption, and/or current performance of individual domains, a region of domains, or a processor system. In some implementations, referring to <FIG>, a system or local temperature profile is monitored to control temperature, power consumption, and/or current performance of a processor system (e.g., an SoC <NUM>) or a domain (e.g., a processor <NUM>), respectively. In some implementations, a power consumption or current profile is monitored for the processor system or individual domain to control power consumption and current performance of the processor system or individual. Optionally, a power consumption profile is monitored to control the power consumption performance of the processor system or individual domain directly and without involving monitoring of temperature or current values. Optionally, a current profile is monitored to control the current performance of the processor system or individual domain directly and without involving monitoring of temperature or power consumption.

<FIG> is a flow diagram of a method <NUM> of managing power consumption of an SoC-based electronic device, in accordance with some implementations. The method <NUM> is implemented at a power management engine of an electronic system. In some implementations, the processor system includes a plurality of processor units, one or more memory units, and power management integrated circuit (PMIC), and each of the plurality of domains includes a distinct subset of the processor system. A plurality of power samples are received (<NUM>) from the plurality of domains over a time duration. Each power sample includes at least one of a temperature, power consumption, and current value associated with a respective domain. In an example, each power sample includes all of a temperature, power consumption, current value associated with a processor <NUM> at a specific time. Optionally, these power samples are measured by power sensors located at the plurality of domains and sent to a power management engine <NUM>. Optionally, power samples measured by power sensors are preprocessed at the domains, a hub (e.g., a regional AMU 406B and a temperature sensor hub 408C in <FIG>), or a global module <NUM>, and the preprocessed power samples are sent to the power management engine <NUM>. Optionally, a subset of the power samples are estimated, e.g., based on a set of power samples measured concurrently from adjacent power sensors or a history of power samples.

The power samples are processed (<NUM>) based on locations of the corresponding power sensors to generate one or more power profiles (e.g., profiles <NUM>-<NUM> in <FIG>) and a plurality of power throttling thresholds. Based on the one or more power profiles, a global power control operation having a first rate is implemented (<NUM>) by determining power budgets of a plurality of power domains on a firmware level and enabling operations of the plurality of power domains according to the power budgets. Based on the one or more power profiles, the plurality of power domains are enabled (<NUM>) to implement a plurality of local power control operations based on the plurality of power throttling thresholds on a hardware level. The local power control operations have second rates greater than the first rate.

In some implementations, each processor cluster <NUM> includes one or more respective processors <NUM> and a cluster cache <NUM>. The first memory <NUM> is coupled to the one or more processing clusters to receive data access requests from the one or more processor clusters <NUM>. The PMIC is configured to provide a plurality of power rails to the one or more processor clusters <NUM> and second memory <NUM>. The second memory <NUM> is configured to receive data retrieval requests from the plurality of processing clusters <NUM> to the first memory <NUM> that are not satisfied by the first memory <NUM>. The plurality of power sensors <NUM> include a plurality of temperature sensors for measuring temperature values and a plurality of activity monitor units (AMUs) <NUM> for measuring power consumption and current values.

In some implementations, each of the power domains includes a distinct subset of the one or more processor clusters <NUM>, first memory <NUM>, PMIC <NUM>, and second memory <NUM>, Each local power control operation is configured to be implemented on a respective power domain based on a corresponding local power profile generated from a subset of power samples collected by a subset of power sensors disposed on the respective power domain. The respective power domain is configured to receive a respective power throttling threshold from the power management engine <NUM>. The one or more power profiles include the corresponding local power profile.

In some implementations, the one or more processor clusters <NUM> and first memory <NUM> are integrated on a system on a chip (SoC) <NUM>, and the SoC <NUM> is integrated with the PMIC <NUM> in an integrated semiconductor device <NUM>.

In some implementations, each domain is driven by one or more power rails. For each power rail, a respective set of current values is collected. In accordance with a determination that the respective set of current values have been greater than a first threshold current for a first duration of time or greater than a second threshold current for a second duration of time, a power throttling action is enabled on the respective power rail of the respective domain. The first threshold current is greater than the second threshold current, and the first duration of time is shorter than the second duration of time.

It should be understood that the particular order in which the operations in <FIG> and <FIG> have been described are merely exemplary and are not intended to indicate that the described order is the only order in which the operations could be performed. One of ordinary skill in the art would recognize various ways to manage power consumption of an SoC-based electronic device <NUM> as described herein. Additionally, it should be noted that details of other processes described above with respect to <FIG> are also applicable in an analogous manner to method <NUM> or <NUM> described above with respect to <FIG> or <FIG>. For brevity, these details are not repeated here.

The terminology used in the description of the various described implementations herein is for the purpose of describing particular implementations only and is not intended to be limiting. As used in the description of the various described implementations and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises," and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Additionally, it will be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the claims to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain principles of operation and practical applications, to thereby enable others skilled in the art.

Claim 1:
A power management method (<NUM>), comprising, at a processor system having a plurality of domains:
collecting (<NUM>) a plurality of power samples from the plurality of domains over a time duration, each power sample including temperature, power consumption, and current values associated with a respective domain;
combining (<NUM>) a subset of the plurality of power samples of the plurality of domains to generate a system power profile including a plurality of system temperature, power consumption, and current values;
determining (<NUM>) whether the system power profile satisfies a first criterion; and
in accordance (<NUM>) with a determination that the system power profile satisfies the first criterion at a first time t<NUM>, at a predefined controlling frequency:
in real time, determining (<NUM>) whether a respective system temperature, power consumption, and/or current value of the system power profile satisfies a second criterion or a third criterion;
in accordance (<NUM>) with a determination that the respective system temperature, power consumption, and/or current value satisfies the second criterion, determining, on a firmware level, power budgets of the plurality of domains and enabling, on the firmware level, operations of the plurality of domains according to the power budgets; and
in accordance (<NUM>) with a determination that the respective system temperature, power consumption, and/or current value satisfies the third criterion, selecting a subset of domains and applying a respective power throttling action to each of the subset of domains directly on a hardware level.