Heterogeneous Chiplet Power Management

Abstract

The disclosed device includes heterogeneous chiplets that can communicate when each of the heterogeneous chiplets locally reaches an idle state. Upon receiving an idle state confirmation from each of the heterogeneous chiplets, the chiplets can complete their entry into a low-power state. Various other methods, systems, and computer-readable media are also disclosed.

Description

Background Art

[0001] Power management for processor architectures such as system-on-chip (SOC) often involves putting the SOC into a low-power state. To put the SOC into a low-power state, various components within the SOC will synchronize to reach an idle state (e.g., a state of low activity or no activity) to enable power gating. In the case of a monolithic SOC or an SOC with a homogeneous chiplet architecture, getting the various chiplets to reach an idle state can follow a similar process. However, in the case of a heterogeneous chiplet architecture that may include a mix of chiplets with real-time traffic and other types of chiplets, it can be difficult to coordinate the chiplets.

[0002] The accompanying drawings illustrate several exemplary embodiments and are part of this specification. Together with the following description, these drawings demonstrate and explain the various principles of the present disclosure.

Brief Description of the Drawings

[0003] [Figure 1] It is a block diagram of an exemplary system for heterogeneous chiplet power management. [Figure 2] It is a block diagram of an exemplary architecture of heterogeneous chiplets. [Figure 3A] It is a block diagram of an exemplary workflow for heterogeneous chiplet power management. [Figure 3B] It is a block diagram of an exemplary workflow for heterogeneous chiplet power management. [Figure 3C] It is a block diagram of an exemplary workflow for heterogeneous chiplet power management. [Figure 4] It is a flowchart of another exemplary workflow for heterogeneous chiplet power management. [Figure 5] It is a flowchart of an exemplary method for heterogeneous chiplet power management. [Modes for carrying out the invention]

[0004] Throughout the drawings, the same reference numerals and designations indicate elements that are similar but not necessarily identical. The exemplary embodiments described herein are open to various modifications and alternative forms, but specific embodiments are shown in the drawings as examples and are described in detail herein. However, the exemplary embodiments described herein are not intended to limit to any particular form disclosed. Rather, this disclosure covers all modifications, equivalents and alternative forms that fall within the appended claims.

[0005] This disclosure generally pertains to heterogeneous chiplet power management. As will be described in more detail below, embodiments of this disclosure instruct heterogeneous chiplets to individually and locally reach an idle state in response to initiating an entry into a low-power state. After confirming that each chiplet is idle, the transition to the low-power state can be completed. Advantageously, this allows stutter clients (e.g., chiplets that can run in bursts of activity / data) to coordinate with other chiplets for low-power and / or partially low-power states, enabling improved power management for heterogeneous chiplet architectures.

[0006] In one embodiment, a device for heterogeneous chiplet power management includes a plurality of heterogeneous chiplets. A first chiplet of the plurality of heterogeneous chiplets is configured to report to a second chiplet of the plurality of heterogeneous chiplets that it has locally reached an idle state in response to receiving an indicator that the device is initiating an entry into a low-power state, and to locally complete the entry into the low-power state in response to receiving confirmation of the idle state from the second chiplet.

[0007] In some examples, the first chiplet corresponds to a stutter client chiplet with an activity buffer, and locally reaching an idle state involves filling the activity buffer based on a buffer threshold. In some examples, the buffer threshold corresponds to the minimum idle period before at least one chiplet wakes up and replenishes the activity buffer. In some examples, the stutter client chiplet corresponds to a display engine, and the activity buffer corresponds to a display buffer. In some examples, the stutter client chiplet corresponds to a multimedia engine, and the activity buffer corresponds to a multimedia buffer.

[0008] In some examples, a stutter client chiplet is configured to receive an indicator that the device is transitioning to a partial power state, which allows a subset of the stutter client chiplet's logical components to be active and to fill the activity buffer, while the other chiplets among several heterogeneous chiplets remain idle. In some examples, several heterogeneous chiplets are configured to refrain from transitioning to a partial power state while the stutter client chiplet is filling the activity buffer, in response to at least one of the several heterogeneous chiplets broadcasting an active state.

[0009] In some examples, reaching an idle state locally involves at least one of the following: saving the state, disabling write burst accumulation, or flushing remaining writes. In some examples, multiple heterogeneous chiplets are configured to abort entry into a low-power state in response to at least one of the multiple heterogeneous chiplets broadcasting an active state.

[0010] In one embodiment, a system for heterogeneous chiplet power management includes a plurality of heterogeneous chiplets, each including a stutter client having an activity buffer, and a control circuit configured to confirm that each of the plurality of heterogeneous chiplets has locally reached an idle state in response to the system initiating an entry into a low-power state, to instruct the stutter client to fill the activity buffer to a buffer threshold in response to receiving confirmation of the idle state from each of the plurality of heterogeneous chiplets, and to complete the entry into the low-power state in response to the stutter client filling the activity buffer.

[0011] In some examples, the buffer threshold corresponds to the minimum idle period before the stutter client wakes up and replenishes the activity buffer. In some examples, replenishing the activity buffer further includes accessing system memory. In some examples, the stutter client corresponds to the display engine, and the activity buffer corresponds to the display buffer. In some examples, the stutter client corresponds to the multimedia engine, and the activity buffer corresponds to the multimedia buffer.

[0012] In some examples, the control circuit receives an indicator of a partial power state where only the components serving the stutter client are active, and in response to the indicator, it is configured to instruct the stutter client and the corresponding link to power on, while the other chiplets among several heterogeneous chiplets remain idle. In some examples, the control circuit is configured to abort the partial power state in response to at least one of several heterogeneous chiplets broadcasting an active state. In some examples, the control circuit is configured to abort entry into a low power state in response to at least one of several heterogeneous chiplets broadcasting an active state.

[0013] In one embodiment, a method for heterogeneous chiplet power management includes (i) transitioning a plurality of heterogeneous chiplets to a new power state corresponding to power-gating an idle chiplet among the plurality of heterogeneous chiplets; (ii) confirming that an idle chiplet has completed the operation to reach an idle state while a stutter client chiplet among the plurality of heterogeneous chiplets is kept at least partially powered on; and (iii) completing the transition to the new power state in response to confirmation from the idle chiplet in the idle state.

[0014] In some examples, the stutter client chiplet has an activity buffer, and the stutter client chiplet is kept at least partially powered on to fill the activity buffer to at least a buffer threshold. In some examples, the method includes aborting the transition to a new power state while the stutter client chiplet is filling the activity buffer. In some examples, the operation includes at least one of the following: verifying that the corresponding local client is idle, saving the state, flushing writes, disabling write burst accumulation, or verifying that the corresponding fabric is idle.

[0015] Features from any of the embodiments described herein can be used in combination with each other in accordance with the general principles described herein. These and other embodiments, features and advantages will be better understood by reading the following detailed description in conjunction with the accompanying drawings and claims.

[0016] The following provides a detailed explanation of heterogeneous chiplet power management with reference to Figures 1 to 5. A detailed description of an exemplary system or architecture is provided in relation to Figures 1 and 2. A detailed description of an exemplary migration for heterogeneous chiplet power management is provided in relation to Figures 3A to 3C. A detailed description of an exemplary workflow for heterogeneous chiplet power management is provided in relation to Figure 4. A detailed description of the corresponding method is also provided in relation to Figure 5.

[0017] Figure 1 is a block diagram of an exemplary system 100 for heterogeneous chiplet power management. System 100 corresponds to computing devices such as desktop computers, laptop computers, servers, tablet devices, mobile devices, smartphones, wearable devices, augmented reality devices, virtual reality devices, network devices, and / or electronic devices. As shown in Figure 1, system 100 includes one or more memory devices, such as memory 120. Memory 120 generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and / or computer-readable instructions. Examples of memory 120 include, but are not limited to, random access memory (RAM), read-only memory (ROM), flash memory, hard disk drive (HDD), solid-state drive (SSD), optical disk drive, cache, one or more variations or combinations thereof, and / or any other suitable storage memory.

[0018] As shown in Figure 1, the exemplary system 100 includes one or more physical processors, such as a processor 110. The processor 110 generally represents any type or form of hardware implementation processing unit capable of interpreting and / or executing computer-readable instructions. In some examples, the processor 110 accesses and / or modifies data and / or instructions stored in memory 120. Examples of processor 110 include, but are not limited to, chiplets (for example, smaller, and in some cases more specialized processing units that can work together as a single chip), microprocessors, microcontrollers, Central Processing Units (CPUs), graphics processing units (GPUs), field-programmable gate arrays (FPGAs) implementing soft-core processors, application-specific integrated circuits (ASICs), system-on-chip (SoCs), digital signal processors (DSPs), neural network engines (NNEs), accelerators, graphics processing units (GPUs), one or more of these, one or more variations or combinations of these, and / or any other suitable physical processors.

[0019] As further shown in Figure 1, the processor 110 includes a control circuit 112, a chiplet 114, and a stutter client chiplet 116. The control circuit 112 generally corresponds to circuits and / or instructions for performing at least certain aspects of power management, such as monitoring power state entry / exit conditions, coordinating or otherwise facilitating communication between components (e.g., chiplet 114 and / or stutter client chiplet 116) for entry / exit, etc. The chiplet 114 generally corresponds to one or more chiplets.

[0020] The stutter client chiplet 116 generally corresponds to one or more chiplets having components or clients that can stutter (e.g., perform specific activities and / or data requests in bursts during stutter or low-activity periods). The stutter client chiplet 116 may include an activity buffer that, when filled with data, allows the stutter client chiplet 116 to operate at low activity for a period (e.g., when the buffer is emptied) without making data requests to memory (e.g., memory 120) or generating new data for the buffer. When the buffer is sufficiently filled (e.g., to a watermark or buffer threshold level), the stutter client chiplet 116 can operate for a minimum idle period before reaching a critical level where the remaining unconsumed data reaches a low watermark specified by the time until underflow (e.g., reaches a blackout state), which requires the buffer to be replenished, for example, by waking up the stutter client chiplet 116. In some examples, the activity buffer can store data generated by I / O devices or internally within the client for writing to memory (e.g., memory 120), with a critical level corresponding to when data not written to memory reaches a high watermark specified by the time until overflow. In some examples, this write activity buffer can be managed actively by messaging (e.g., in response to fabric idle, as further described below) or passively (e.g., as part of a transition from normal idle to active). In some examples, the write activity buffer can store data captured by a camera / webcam for writing to memory.In addition, some non-exclusive examples of the stutter client chiplet 116 include a graphics or display engine (for example, for rendering display frames stored in a display buffer as an activity buffer), and a multimedia engine (for example, for decoding / rendering frames and / or audio stored in a multimedia buffer as an activity buffer).

[0021] The idle state can correspond to a low-activity or no-activity state, and in some examples, to a state in which there are no external data requests (e.g., memory access requests to memory 120) so that the corresponding link is unused and can be power-gated. In some embodiments, various chiplets and components of the processor 110 (e.g., chiplet 114 and stutter client chiplet 116) may have various respective local conditions for reaching the idle state. In some examples, reaching the idle state locally may include saving a state, such as chiplet 114 saving its context or state so that it can be restored when the low-power state ends. In some examples, reaching the idle state locally may include accumulating write requests, such as chiplet 114 accumulating write requests to memory 120 or other data storage. In other examples, reaching the idle state locally may include filling the activity buffer to a buffer threshold, such as stutter client chiplet 116 filling its activity buffer.

[0022] In the case of heterogeneous chiplets such as chiplet 114 and stutter client chiplet 116, the processor 110 cannot easily initiate a multi-chiplet idle procedure due to differences in the chiplets (e.g., in reaching an idle state). For example, due to a high difference between the chiplets and components entering an idle state, the stutter client chiplet 116 may enter a blackout state while waiting for the rest of the processor 110 to enter a low-power state, negatively impacting performance and user experience. Therefore, the control circuit 112 can be configured to coordinate heterogeneous chiplets via a messaging protocol, which in some examples involves coordinating and / or initiating messages between chiplets, while in other examples, the chiplets may broadcast messages and await acknowledgments. For example, in response to the processor 110 initiating an entry into a low-power state, the control circuit 112 verifies that each of the heterogeneous chiplets (e.g., chiplet 114 and stutter client chiplet 116) has locally reached an idle state. Subsequently, in response to receiving confirmation of idle status from each of the different chiplets (for example, according to a protocol), the control circuit 112 can complete or facilitate entry into the low-power state.

[0023] FIG. 2 shows the SOC 210 corresponding to the processor 110 having a heterogeneous chiplet architecture. As shown in FIG. 2, the SOC 210 includes chiplets 214A and 214B, each corresponding to iterations of the chiplet 114. The SOC 210 also includes stutter client chiplets 216A and 216B, each corresponding to iterations of the stutter client chiplet 116. Each stutter client can include an activity buffer such as the stutter client chiplet 216A having the buffer 219A and the stutter client chiplet 216B having the buffer 219B. The SOC 210 further includes an input / output (I / O) die 218, and the I / O die can regulate the I / O of various chiplets (e.g., chiplets 214A-214B and stutter client chiplets 216A-216B) via the links 215A, 215B, 217A, and 217B, and each of the links corresponds to a link for transmitting data / signals between a chiplet and the I / O die 218. In some embodiments, the I / O die 218 can incorporate or otherwise communicate with a control circuit such as the control circuit 112.

[0024] The SOC 210 can transition between various power states, such as various degrees of low power states where components of the SOC 210 are in a low power state, partial power states where some components are in low power and / or idle while other components are active, and full power states where components are active. Thus, when the SOC 210 transitions from a current power state to a new power state, based on the end conditions of the current power state and / or the start conditions of the new power state, certain components may be powered off, put into idle, or put into a lower power state, certain components may be powered on, made active, or put into a higher power state, and certain components may remain in the same power state.

[0025] In some examples, the SOC210 can transition to a low-power state, including different types of chiplets such as chiplet 214A and / or chiplet 214B reaching an idle state, together with stutter client chiplet 216A and / or stutter client chiplet 216B. The control circuit can confirm that chiplet 214A and / or chiplet 214B have locally reached an idle state, for example, using a messaging protocol described herein that allows the chiplet to send acknowledgments that the local client and / or the corresponding fabric is idle. In some embodiments, the differences and latencies of entering a low-power state can be reduced to more predictable latencies by waiting for each chiplet to reach a sufficiently idle state. For example, each chiplet can achieve an idle state for its local client and prepare a low-power entry (e.g., save state, disable write burst, flush write) while the corresponding fabric achieves idle. A write may need to wait for fabric idle because it can persist within the fabric without the knowledge of the client that sent the write, either by being posted by the fabric to write to memory after global observability is reached, or if posted to the fabric upon arrival. Upon detecting fabric idle, the control circuit can negotiate the idle state of stutter client chiplets 216A and / or stutter client chiplets 216B by providing an appropriate fill threshold for stutter client chiplet 216A to fill buffer 219A, and / or by providing stutter client chiplet 216B to fill buffer 219B. In some examples, only a single stutter client (e.g., the stutter client of stutter client chiplet 216A) may have an activity buffer that is actively managed in response to fabric idle.In some examples, only the stutter client of a single stutter client chiplet (e.g., the stutter client of stutter client chiplet 216A) can have an activity buffer that is actively managed in response to fabric idle. In some examples, a stutter client chiplet that does not have such an actively managed activity buffer can have a passive activity buffer, which is triggered to be filled when a critical level is reached to force the system to an active state, filled at the normal end of the system from an idle state to an active state, or filled upon a local chiplet transition from active to idle. In some examples, a video codec engine can support a passive activity buffer as described.

[0026] When chiplet 214A locally reaches an idle state, chiplet 214A can communicate that it has reached the idle state by sending a confirmation to the control circuit. Similarly, stutter client chiplet 216A can communicate that it has reached the idle state by sending a confirmation to the control circuit. In response to receiving all confirmations (e.g., confirmations expected in response to commands sent), the control circuit can complete entry into a low power state, which can include various power downs of other components of SOC210 such as link 215A (when chiplet 214A is in an idle state) and link 217A (when stutter client chiplet 216A is in an idle state), as well as other actions regarding multiple chiplets, common or shared resources / components across SOC210, corresponding portions of the data fabric and other interfaces. Although not shown in FIG. 2, additional actions can include power gating, clock gating, etc., as needed.

[0027] In some cases, SOC210 can transition to a partial power state. For example, stutter client chiplet 216A may be powered on from a low power state to replenish buffer 219A after it has been depleted or nearly depleted, while chiplet 214A may remain idle. Thus, the control circuit, together with link 217A, can instruct stutter client chiplet 216A to power on again and become active. In other cases, one or more chiplets (e.g., one or more of chiplets 214A-214B and / or stutter client chiplets 216A-216B) may transition to a partial power state in which a subset of the chiplet's logical components / clients is powered on. For example, logical components that provide services to stutter clients may be powered on, while components (e.g., additional interfaces, crossbars, links, probe filters, shadow tag management components for other flushed caches, private caches for other clients, and other components not used by stutter clients) may remain powered off.

[0028] In yet another example, the SOC210 can transition between power states using a control circuit that commands local actions for each chiplet / component, receives confirmation of completion of the local action, and completes the transition for the action across the SOC210, thereby commanding the components to power on or off in parallel as needed. In yet another example, instead of having a control circuit, the chiplets can transmit and respond to each other with respect to indicators / communications, as further described with reference to Figures 3A-3C.

[0029] Figures 3A to 3C show charts 300, 301, and 302, respectively, which include a display engine 316 corresponding to stutter client chiplet 216A (and / or stutter client chiplet 116), a root die 318 corresponding to I / O die 218 (and / or another root die), and a non-root die 314 corresponding to chiplet 214A (and / or chiplet 114 or any other non-root or leaf die). Figures 3A to 3C show a simplified example, and other examples may further include additional chiplets, chiplet levels, and / or interfaces / fabrics. In addition, Figures 3A to 3C show chiplets with underlying state machines for transitioning between various illustrated states, and in some examples, the underlying state machines may be similar or identical across chiplets.

[0030] Figure 3A illustrates the low-power entry across heterogeneous chiplets. Since the display controller (e.g., display engine 316) may require separate negotiation to transition to stutter mode and then to idle, reaching the idle state (e.g., for a local client) may exclude the display controller. Therefore, the non-root die 314 may begin by broadcasting local client idle 330A, followed by saved state 331A. The root die 318 receives the metric for local client idle 330A and may reach local client idle 330B along with saved state 331B. In some examples, local client idle 330A and / or local client idle 330B may be distinguished from a direct entry to a partially powered stutter level for a stutter client. The root die 318 may proceed with flash write / write burst accumulation invalidation 332B (e.g., flushing writes in the fabric and memory controller and invalidating write burst accumulation in the memory controller), and its completion is broadcast to the non-root die 314, while the non-root die 314 may proceed with flash write / write burst accumulation invalidation 332A (e.g., including a corresponding action similar to flash write / write burst accumulation invalidation 332B). After the non-root die 314 completes flash write / write burst accumulation invalidation 332A, the non-root die 314 may send a fabric idle acknowledgment 334A to the root die 318 indicating that it has locally reached its idle state (e.g., putting its local client into an idle state and putting the corresponding fabric into an idle state without sustaining writes). The root die 318 may send a fabric idle acknowledgment 334B to the display engine 316 indicating that it has locally reached its idle state (indicating that the root die 318 and the non-root die 314 have locally reached an idle state).The display engine 316 can start a fill buffer 335 to fill its display buffer based on a buffer threshold, threshold conformance (336). The display engine 316 can start a power down 337B by broadcasting the threshold conformance 336 to the root die 318 (for example, indicating that it has locally reached an idle state), and the power down may include power gating and other related processes (e.g., power / clock gating of the fabric and memory controllers, low power state of the DRAM, low current state of the voltage regulator, power down of the chiplet link, power down of the phase-locked loop (PLL), and / or, for example, clock tree frequency reduction via bypass to a slower reference clock or clock tree gating). The root die 318 can further broadcast the power down 337B to the non-root die 314 to start a power down 337A (for example, having a corresponding action similar to power down 337B) to complete the entry into the low power state.

[0031] Figure 3B illustrates the case of a display stutter spanning heterogeneous chiplets, for example, in a low-power state. The display engine 316 can detect buffer exhaustion 340 (for example, that its activity buffer is exhausted and the stutter needs to be terminated) which is broadcast to the root die 318. The root die 318 can locally initiate stutter termination 341B, which includes powering up the stutter logic 342B and reporting stutter termination 343B. The root die 318 can also broadcast stutter termination 341B to a non-root die 314 to locally initiate stutter termination 341A, which includes powering up the stutter logic 342A and reporting stutter termination 343A. The non-root die 314 can broadcast a reported stutter termination 343A to the root die 318, which can then broadcast a reported stutter termination 343B to the display engine 316. The display engine 316 can access memory 344, for example, to replenish its buffer in the display stutter 345. The non-root die 314 can also prepare a local client idle 347A (e.g., corresponding to local client idle 330A), which is broadcast to the root die 318 to prepare a local client idle 347B (e.g., corresponding to local client idle 330B). The local client idle states (e.g., local client idle 347A and local client idle 347B) can indicate that the local chiplet is idle except for display and is therefore ready to negotiate a watermark (e.g., for the buffer) with the display engine 316. The root die 318 can then proceed to power down 348B, and the non-root die 314 can proceed to power down 348A.The display engine 316 can continue until the buffer is filled (346), which is then broadcast to the root die 318 to initiate powerdown 348B, which includes various actions for powerdown (similar to powerdown 337B, for example). The root die 318 can also broadcast powerdown 348B to the non-root die 314 to initiate powerdown 348A, which includes various actions for powerdown (similar to powerdown 337A, for example).

[0032] Power-on stutter logic (e.g., power-on stutter logic 342A and / or power-on stutter logic 342B) can be configured to signal partial power states for power-efficient stuttering. For example, a display stutter (e.g., display stutter 345) may only need to power on the portion of the data fabric responsible for display, which in some cases may exclude certain controllers, interface logic (e.g., for non-stutter clients), links (e.g., statically assigned links to other clients, links that can be selectively powered off depending on the power-off of related components), and / or clocks used by non-stutter clients, and / or power gates (registered trademark) for non-stutter clients.

[0033] Figure 3C illustrates stutter termination across heterogeneous chiplets, which can be upgraded to low-power termination. The display engine 316 is located on the display stutter 350 (e.g., display stutter 345), the root die 318 is on the local client idle 351B (e.g., local client idle 330B and / or local client idle 347B), and the non-root die 314 may be on the local client idle 351A (e.g., local client idle 330A and / or local client idle 347A). An incoming event on the non-root die 314 can trigger an active broadcast 352A, which is sent to the root die 318 as an active broadcast 352B and further propagated to the display engine 316 to terminate the stutter 353. In the exemplary scenario represented by Figure 3C, the active broadcast 352A and / or active broadcast 352B can be triggered by various events. For example, an active broadcast 352A may be triggered when a non-root die 314 becomes active while the root die 318 remains idle. In another example, an active broadcast 352B may be triggered by the root die 318 becoming active while the non-root die 314 remains idle, in which case the active broadcast 352B may be sent to the non-root die 314. In yet another example, both the root die 318 and the non-root die 314 may become idle simultaneously or nearly simultaneously, resulting in their respective active broadcast messages being sent to each other.

[0034] The display engine 316 can proceed to buffer fill abandonment 354, during which time it is no longer necessary to have the display engine 316 fill its activity buffer, as this is due to the low-power termination. For example, the display engine 316 can receive normal access to memory until the next low-power entry, when the requirement to fill the activity buffer can be restored. Meanwhile, the root die 318 can proceed to power on the remaining logic 355B, which may include powering on the components for a complete low-power termination, since the stutter logic has already been powered on earlier (for example, to enable the display stutter 350 during local client idle 351B). The non-root die 314 can similarly power on the remaining logic 355A, which may similarly include powering on the remaining components for a complete low-power termination. After powering on the remaining logic 355B, the root die 318 can continue to enable the write burst storage 356B, and the non-root die 314 can continue to enable the write burst storage 356A. The non-root die 314 can proceed to restore state 357A, and the root die 318 can proceed to restore state 357B and complete the termination of the low-power state.

[0035] As shown in Figure 3C, any further (non-stutter) low-power termination conditions observed may signal "active," leading to all remaining logic terminating at low power. In some embodiments, multiple stutter levels may be implemented. In some embodiments, multimedia terminations may be distinguished from display stutters and indicated to enter different partially powered states (e.g., instead of stutter termination 341B and / or stutter termination 341A). Terminations can then transition from deeper to shallower states, for example, from low power to display stutter, multimedia stutter, low-power termination, directly from low power to multimedia, low-power termination, and / or directly from low power to low-power termination, as well as other transitions between deeper and shallower states.

[0036] Figures 3A–3C illustrate a simplified communication flow between the display engine 316, root die 318, and non-root die 314 in a simplified exemplary architecture. In some examples, specific actions may be modified as needed using additional iterations / variations of the non-root die 314, root die 318, and / or display engine 316, particularly including an additional level of non-root die 314 branching from root die 318. For example, a specific report may be bypassed via a specific die (e.g., if a specific non-root die 314 exists along a branch that has completed its activity and does not require further adjustment), and / or a control circuit may receive a specific report directly.

[0037] Figure 4 is a flowchart of an exemplary workflow 400 for heterogeneous chiplet power management. In some embodiments, a Quality of Service (QoS) protocol maintains assurance that real-time stutter clients can manage their activity buffers. Figure 4 shows another example of managing a real-time stutter client (e.g., stutter client chiplet 116). In 402, with respect to a real-time stutter client, it can be determined that all other clients no longer have outstanding requests (e.g., local client idle 330A and local client idle 330B) in such a way that all reads for which read responses and writes have been received satisfy global observability as defined by a coherence protocol (e.g., the corresponding data fabric or other interface to ensure the data is not stale) or will be posted to the relevant network. In some examples, using multiple chiplets, 402 can be executed using a protocol that designates idles for the root die where the real-time stutter client resides via hierarchical propagation.

[0038] A 404 error can disconnect other clients from generating new requests. In some cases, 404s may be distributed / executed across each die when 402 messaging is being performed.

[0039] In 406, write burst storage is disabled (e.g., 332B and 332A, which disable flash write / write burst storage), and the remaining writes are flushed to DRAM such as memory 120 in the data fabric and / or memory controller (e.g., exceeding global observability or being posted to the network) (e.g., 332B and 332A, which disable flash write / write burst storage). In some examples, 406 can be initiated by a protocol that triggers a multichiplet low-power attempt after the root die has received messaging from all other dies (e.g., in 402) while it is locally idle in a non-stutter client. In some examples, this results in leaf-to-root propagation indicating completion (e.g., fabric idle acknowledgments 334B and 334A).

[0040] At 408, negotiation with the real-time stutter client allows the stutter client to fill its activity buffer to a watermark level where it completes any outstanding requests and stops generating new requests (e.g., fill buffer 335 and threshold-fitted 336). In addition, 408 allows the entire fabric on multiple chiplets to suspend reads and writes from other clients (e.g., due to messaging), thereby allowing the activity buffer to be filled with the best possible QoS without traffic from other clients (e.g., as on a monolithic die), maximizing the utilization efficiency of the activity buffer. Furthermore, once the real-time stutter client completes all outstanding requests with the best possible service, the entire fabric and memory controller can become completely idle, with all traffic pre-flushed and the fastest possible low-power entry. Thus, the watermark or threshold (e.g., threshold-fitted 336) buffer level required to initiate power-off can accommodate idle fabric low-power entry and exit latency (e.g., similar to that required on a monolithic die). In other words, the protocols defined herein can hide multi-chiplet and chiplet-cross traffic with distributed clients from stutter clients so that activity buffer management is performed in the same way as on a monolithic die.

[0041] In 410, entering a low-power state (e.g., power-down 337B and power-down 337A) may include powering off idle data fabric components and memory controllers, and putting the DRAM into a low-power state (e.g., self-refresh). In some examples, entering a low-power state may further include powering down the chiplet links and other components as described herein.

[0042] Furthermore, as described herein, the messaging process across chiplets may, in some examples, involve an unspecified amount of latency. For example, filling an activity buffer may take as long as flushing in other chiplets. For QoS reasons, multi-chiplet messaging may, in some examples, detect a request from any client in any chiplet to return to an active state without having to wait for the entire entry to complete and terminate, and abort the sequence using the messaging protocol. This messaging can be done by inverting the “local idle” so that any chiplet wishing to abort can send / broadcast “active” to other chiplets (e.g., active broadcast 352B and active broadcast 352A) to return all chiplets to an active state at any time before an actual irreversible power-down (e.g., power-down 337B and power-down 337A). Once aborted, a 404 (e.g., client disconnected) can be reversed so that any client can generate new traffic. Changes made before the abort, such as write burst storage disabled, may also be reversed.

[0043] Figure 5 is a flowchart of an exemplary method 500 for heterogeneous chiplet power management. The steps shown in Figure 5 can be performed by any suitable circuit and / or system, including the systems shown in Figure 1 and / or Figure 2. In one example, each of the steps shown in Figure 5 has a structure that includes multiple sub-steps and / or represents an algorithm represented thereby, an example of which is provided in more detail below.

[0044] As shown in Figure 5, in step 502, one or more of the systems described herein transitions a plurality of heterogeneous chiplets to a new power state corresponding to power-gating an idle chiplet among the plurality of heterogeneous chiplets. For example, the control circuit 112 can facilitate the system 100 initiating and / or otherwise enabling the processor 110 to transition to a new power state, such as a partial power state corresponding to power-gating a specific chiplet (e.g., chiplet 114).

[0045] The systems described herein can perform step 502 in various ways. In one example, the new power state corresponds to a low-power state with an idle chiplet containing multiple heterogeneous chiplets. In another example, the new power state corresponds to a full-power state with an active chiplet containing multiple heterogeneous chiplets. In yet another example, the new power state corresponds to a partial-power state where a specific client (e.g., a stutter client) and its corresponding logical component can be kept powered on, while other chiplets can be power-gated.

[0046] In step 504, one or more of the systems described herein confirm that an idle chiplet has completed its operations to reach an idle state while at least partially powered on among a plurality of heterogeneous chiplets, including a stutter client chiplet. For example, the control circuit 112 may confirm that chiplet 114 has completed its high-latency heterogeneous operations while stutter client chiplet 116 is at least partially powered on (e.g., confirming that the corresponding local client is idle, saving the state, flushing writes, disabling write burst accumulation, and / or confirming that the corresponding fabric is idle).

[0047] The systems described herein can perform step 504 in various ways. In some examples, the multiple heterogeneous chiplets include a stutter client chiplet (e.g., stutter client chiplet 116) having an activity buffer, which is kept at least partially powered on to fill the activity buffer to at least a buffer threshold. In some examples, the transition to a new power state while the stutter client chiplet is filling the activity buffer may be aborted (e.g., in response to the chiplet becoming active / broadcasting).

[0048] In step 506, one or more of the systems described herein complete the transition to a new power state in response to confirmation from an idle chiplet in an idle state. For example, the control circuit 112 may complete the transition to a new power state after receiving confirmation from chiplet 114 and stutter client chiplet 116 that they have reached an idle state, respectively.

[0049] Low-power state management schemes for multi-socket or multi-chiplet SoCs often do not cover real-time client traffic crossing from one die to another. As described above, the systems and methods provided herein enable the construction of an SOC with heterogeneous chiplets, including real-time traffic clients, that can send traffic across any number of die hops to remote memory to support system-wide states, while maintaining the full stutter functionality enjoyed by a monolithic SOC. As described herein, in stutter mode, chiplets can burst (fill buffers), become idle (empty buffers), and enable low-power states during idle states. In heterogeneous chiplet architectures, system-wide low-power states require coordination across various chiplets, which may include real-time traffic clients. Due to differences between dies, coordination may require protocols.

[0050] In other words, the messaging protocols described herein enable high-latency differential operations (e.g., non-display chiplets) to be completed before display buffer filling operations, in order to provide good QoS services and fast, low-power entries that can significantly improve activity buffer efficiency.

[0051] The systems and methods provided herein include, for example, messaging protocols, chiplet link power-off, and fabric low-power state transitions, enabling the generation of multiple clock and power-gating domains within a chiplet and their optimization for low-power stutter operation, and allowing multiple chiplets to coordinate partial low-power transitions between a normal operating mode and a stutter mode in which logic not used by these stutter clients, even within remote chiplets, can be powered off.

[0052] The messaging protocol may be designed with hard real-time clients in mind, so that chiplet messaging can be overlaid on low-power entry and exit sequences. Entry latency differences across multiple chiplets, such as state saving, write burst disabling, and write flushing latency, are not passed to the memory blackout watermark of real-time stutter clients. In addition, power transitions may be parallelized across chiplets to minimize blackouts.

[0053] The protocol described herein enables coordination across all dies. When entering a low-power state, each die can locally perform high-differentiation actions (e.g., save state, burst out if necessary) to quickly reach the idle point for all dies. When complete, the dies communicate and enter the low-power state together with other entry components (clock gating, power gating, clock tree gating, self-refresh, etc.). When terminating, this protocol allows for partial power-on of the stutter client (e.g., burst again), enabling necessary components such as displays, multimedia, interfaces, etc. Termination conditions can be upgraded to higher termination conditions (e.g., full system-wide power-on) or downgraded to low power (e.g., shutting down the stutter client).

[0054] As stated above, the circuits, devices and systems described and / or shown herein broadly represent any type or form of computing device or system capable of executing computer-readable instructions, such as those contained within the modules described herein. In their most basic configurations, each of these computing devices includes at least one memory device and at least one physical processor.

[0055] In some instances, the term “memory device” generally refers to any type or form of volatile or non-volatile storage device or medium capable of storing data and / or computer-readable instructions. In one example, a memory device stores, loads, and / or maintains one or more modules and / or circuits described herein. Examples of memory devices include, but are not limited to, random-access memory (RAM), read-only memory (ROM), flash memory, hard disk drives (HDDs), solid-state drives (SSDs), optical disk drives, caches, one or more variations or combinations thereof, or any other suitable storage memory.

[0056] In some cases, the term “physical processor” generally refers to any type or form of hardware implementation processing unit capable of interpreting and / or executing computer-readable instructions. In one example, a physical processor accesses and / or modifies one or more modules stored in the memory devices described above. Examples of physical processors include, but are not limited to, microprocessors, microcontrollers, central processing units (CPUs), field-programmable gate arrays (FPGAs) implementing soft-core processors, application-specific integrated circuits (ASICs), systems-on-a-chip (SoCs), digital signal processors (DSPs), neural network engines (NNEs), accelerators, graphics processing units (GPUs), one or more of these, one or more variations or combinations of these, or any other suitable physical processor.

[0057] In some embodiments, the term “computer-readable medium” generally refers to any form of device, carrier, or medium capable of storing or carrying computer-readable instructions. Examples of computer-readable mediums include, but are not limited to, transmission media such as carrier waves, as well as magnetic storage media (e.g., hard disk drives, tape drives, floppy disks), optical storage media (e.g., compact disks (CDs), digital video disks (DVDs), Blu-ray discs), electronic storage media (e.g., solid-state drives and flash media), and non-transient media such as other distribution systems.

[0058] The process parameters and steps described and / or illustrated herein are given only as examples and may be changed as desired. For example, the steps illustrated and / or described herein are illustrated or described in a particular order, but these steps do not necessarily have to be performed in the illustrated or described order. Various exemplary methods described and / or illustrated herein may omit one or more of the steps described or illustrated herein, or may include additional steps in addition to those disclosed.

[0059] The above description is provided to enable those skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to limit to any specific form disclosed. Many modifications and variations are possible without departing from the spirit and scope of this disclosure. The embodiments disclosed herein should be considered in all respects to be exemplary and not restrictive. In determining the scope of this disclosure, the appended claims and their equivalents should be referenced.

[0060] Unless otherwise stated, the terms “connected” and “joined” (and their derivatives) as used herein and in the claims should be interpreted to allow both direct and indirect connections (i.e., through other elements or components). In addition, the terms “a” or “an” as used herein and in the claims should be interpreted to mean “at least one of.” Finally, for ease of use, the terms “including” and “having” (and their derivatives) as used herein and in the claims are interchangeable with the term “comprising” and have the same meaning.

Claims

1. It is a device, Equipped with multiple different types of chiplets, Of the aforementioned multiple different types of chiplets, the first chiplet is Upon receiving an indicator that the device has begun to enter a low-power state, the second chiplet among the plurality of heterogeneous chiplets reports that it has locally reached an idle state. Upon receiving confirmation of the idle state from the second chiplet, the entry into the low-power state is completed locally. It is configured to do, device.

2. The first chiplet corresponds to a stutter client chiplet having an activity buffer, Locally reaching the idle state includes filling the activity buffer based on a buffer threshold. The device according to claim 1.

3. The buffer threshold corresponds to the minimum idle period before the stutter client chiplet wakes up to fill the activity buffer. The device according to claim 2.

4. The stutter client chiplet corresponds to the display engine, and the activity buffer corresponds to the display buffer. The device according to claim 2.

5. The stutter client chiplet corresponds to the multimedia engine, and the activity buffer corresponds to the multimedia buffer. The device according to claim 2.

6. The stutter client chiplet is configured to receive an indicator that the device is transitioning to a partial power state in which a subset of the logical components of the stutter client chiplet is active and which allows the activity buffer to be filled, while the other chiplets among the plurality of heterogeneous chiplets remain idle. The device according to claim 2.

7. The plurality of heterogeneous chiplets are configured such that, in response to at least one of the plurality of heterogeneous chiplets broadcasting an active state, the stutter client chiplet ceases to transition to the partial power state while filling the activity buffer. The device according to claim 6.

8. Locally reaching the aforementioned idle state includes at least one of saving the state, disabling write burst accumulation, or flushing the remaining writes. The device according to claim 1.

9. The plurality of heterogeneous chiplets are configured to abort entry into the low-power state in response to at least one of the plurality of heterogeneous chiplets broadcasting an active state. The device according to claim 1.

10. It is a system, Multiple heterogeneous chiplets, including a stutter client with an activity buffer, Equipped with a control circuit, The aforementioned control circuit is In response to the system initiating an entry into a low-power state, it is confirmed that each of the multiple heterogeneous chiplets has locally reached an idle state, Upon receiving confirmation of the idle state from each of the multiple different chiplets, the stutter client is instructed to fill the activity buffer up to the buffer threshold. In response to the stutter client filling the activity buffer, the entry into the low-power state is completed, It is configured to do, system.

11. The buffer threshold corresponds to the minimum idle period before the stutter client wakes up to fill the activity buffer. The system according to claim 10.

12. Filling the activity buffer includes accessing the system's memory. The system according to claim 11.

13. The stutter client corresponds to the display engine, and the activity buffer corresponds to the display buffer. The system according to claim 10.

14. The aforementioned controller, Receiving an indicator of a partial power state in which only the components providing the service to the stutter client are active, The method involves commanding the stutter client and the corresponding link to power on according to the aforementioned indicator, wherein the other chiplets among the plurality of heterogeneous chiplets remain idle. It is configured to do, The system according to claim 10.

15. The control circuit is configured to terminate the partial power state in response to at least one of the plurality of heterogeneous chiplets broadcasting an active state. The system according to claim 14.

16. The control circuit is configured to cancel entry into the low-power state in response to at least one of the plurality of heterogeneous chiplets broadcasting an active state. The system according to claim 10.

17. It is a method, Transitioning multiple different chiplets to a new power state corresponding to power-gating the idle chiplet among the multiple different chiplets, While the stutter client chiplet among the multiple heterogeneous chiplets is kept powered on at least partially, it is confirmed that the idle chiplet has completed the operation required to reach an idle state. The process includes completing the transition to the new power state in response to confirmation of the idle state from the idle chiplet, method.

18. The stutter client chiplet has an activity buffer, and the stutter client chiplet is kept at least partially powered on to fill the activity buffer to at least a buffer threshold. The method according to claim 17.

19. The stutter client chiplet includes suspending the transition to the new power state while it fills the activity buffer, The method of claim 18.

20. The aforementioned operation includes at least one of the following: confirming that the corresponding local client is idle, saving the state, flushing the write, disabling write burst accumulation, or confirming that the corresponding fabric is idle. The method according to claim 17.

Images