Low power state selection based on idle duration history - Patents.com

Abstract

The device (100) comprises a processor (102), a sleep state duration prediction module (404), and a system management unit (316). The sleep state duration prediction module is configured to predict a sleep state duration (416) of a component of the device. The system management unit transitions the component to a selected sleep state from a plurality of sleep states based on a comparison of the predicted sleep state duration to at least one duration threshold. Each sleep state of the plurality of sleep states is a lower power state than a previous sleep state of the plurality of sleep states.

Description

[Background technology]

[0001] Modern computer systems can typically support several power management states. The active system state generally represents a state in which the system is fully available and fully powered. Under some conditions, such as when some or all of the system components are not in use, the power of some or all of the components is reduced by entering a low-power system state from the active state.

[0002] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by reference to the following drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief description of the drawings]

[0003] [Figure 1] 1 is a block diagram of an exemplary processing device according to some embodiments. [Diagram 2] FIG. 2 is a block diagram illustrating additional details of the processing device of FIG. 1 in accordance with some embodiments. [Diagram 3] 1 is a block diagram of an exemplary system-on-chip device according to some embodiments. [Figure 4] FIG. 2 is a block diagram of an exemplary system management unit according to some embodiments. [Diagram 5] FIG. 2 is a flow diagram illustrating a general exemplary method for transitioning components of a processing device directly to a deeper sleep state in accordance with some embodiments. [Figure 6] 5 is a flow diagram illustrating a more detailed method for the duration monitoring process shown in block 502 of FIG. 5, according to some embodiments. [Figure 7] FIG. 2 illustrates an example timing sequence for two different sleep states according to some embodiments. [Figure 8]5 is a flow diagram illustrating a more detailed method for the duration prediction process shown in block 504 of FIG. 5, according to some embodiments. [Figure 9] 5 is a flow diagram illustrating a more detailed method for the sleep state selection process shown in block 506 of FIG. 5 according to some embodiments. [Figure 10] 5 is a flow diagram illustrating a more detailed method for the sleep state promotion process shown in block 510 of FIG. 5 according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] Components within a processing device, such as a central processing unit (CPU), a graphics processing unit (GPU), and an accelerated processing unit (APU), may be operated in different power management states that may deactivate portions of the processing device or operate at a lower operating frequency or voltage. For example, power management states available to a processing device component may include an active state, an idle state, a power-gated state, and the like. In an active state, the component executes instructions and operates at a nominal operating frequency and operating voltage. In an idle state, the component does not execute instructions and may operate at a lower operating frequency or operating voltage. In a power-gated state, the power supply is disconnected from the component, for example, by using a header transistor that cuts off power supplied to the component when a power-gated signal is applied to the gate of the header transistor. The idle and power-gated states may be referred to as sleep states, and multiple levels of sleep states may be implemented by a processing device. In at least some implementations, while in the lowest (lightest) sleep state level, a processing device component consumes less power than if it were operating in an active state, but consumes more power than the next higher (deeper) sleep state level. When a component is placed in the highest (deepest) sleep state level, the component is typically power gated.

[0005] A processing device may save power by transitioning one or more components from an active state to a sleep state when there is no activity performed by the components of the processing device. For example, if a component is idle for a relatively long time, the power supplied to the component may be gated to reduce standby and leakage power consumption. However, transitioning a processing device or its components between different sleep states has a significant impact on the energy consumed by the processing device and the performance of the processing device. For example, transitioning to or from a sleep state from either an active state or a deeper sleep state level imposes a performance cost due to the delay caused by the transition. Energy costs may also be incurred due to operations performed prior to the transition. Performance costs are also incurred for components to return a processor core to an active state from a power-gated deep sleep level state. Thus, a deeper sleep state is more efficient than a lighter sleep state only if the component is placed in the deeper sleep state for a long enough period of time such that the power savings associated with the deeper sleep state exceed the power consumed during entry and exit transitions into and from the deeper sleep state.

[0006] A sleep state management system / algorithm can benefit from determining an appropriate sleep state level based on the break-even cost of energy performance versus sleep duration. However, a priori knowledge of how long the sleep duration will be for a component is typically not available. Thus, many conventional sleep state management systems attempt to filter out sleep durations that are too short by introducing a hysteresis duration before saving the state of the component being put to sleep. Introducing a hysteresis duration usually results in energy inefficiency, as the hysteresis duration is typically too long (e.g., on the order of milliseconds). Sleep durations for many types of workloads are generally in the sub-millisecond range, with occasional longer sleep durations following in the millisecond range. Thus, a long entry hysteresis results in shorter sleep durations (e.g., sub-millisecond) being ignored, resulting in entry into a deeper sleep state per single sleep request (zero entry hysteresis). Additionally, conventional sleep state management systems typically have many tunable parameters, a non-adaptive approach to sleep state entry, lack a framework for future improvements / extensions, and may be controlled by operating system power management algorithms, all of which characteristics further increase the inefficiencies of conventional sleep state management systems.

[0007] This disclosure describes embodiments of systems and methods for improving the energy efficiency of a processing device by transitioning a component directly to a deeper sleep state instead of consuming energy in an entry hysteresis period. As described in more detail below, the sleep state durations of the processing device and its components are monitored and recorded to generate historical sleep state duration information. The historical sleep duration information is used to predict the next sleep state duration of the component. A break-even duration is determined for one or more sleep states available to the component. The break-even duration indicates a sleep state duration for which the benefit of transitioning to a sleep state exceeds the cost of transitioning to a sleep state. The predicted sleep duration is compared to the break-even durations determined for the one or more sleep states, and a sleep state for the component is selected based on the comparison. The component is then transitioned to the selected sleep state. In at least some embodiments, the current sleep state of the component is promoted to a deeper sleep state if the component has been in the current sleep state for a duration that meets one or more sleep state duration thresholds. In at least some embodiments, a decision error feedback mechanism is implemented to adjust the later predicted sleep duration to reduce errors in sleep state selection based thereon. Also, in at least some embodiments, information such as Latency Tolerance Report (LTR) values ​​from input / output devices (e.g., peripheral component interconnect express (PCIe) devices, universal serial bus (USB) devices, etc.) or timer values ​​for Advanced Programmable Interrupt Controller (APIC) interrupts are used in addition to the predicted sleep duration to select a sleep state for a component.

[0008] 1 is a block diagram of an example processing device 100 in which the power state management techniques described herein may be implemented. In at least some embodiments, the processing device 100 includes, for example, a computer, a mobile device, a gaming device, a tablet computing device, a wearable computing device, a set-top box, a television, or another type of computing system or device. The device 100, in at least some embodiments, includes a processor 102, a memory 104, a storage device 106, one or more input devices 108, and one or more output devices 110. The processing device 100, in at least some embodiments, also includes an input driver 112 and an output driver 114. It should be understood that the processing device 100 may include additional components not shown in FIG. 1.

[0009] In at least some embodiments, processor 102 includes a central processing unit (CPU), a graphics processing unit (GPU), a CPU and a GPU located on the same die or multiple dies (e.g., using a multi-chip-module (MCM)), or one or more processor cores, each processor core being a CPU or a GPU. Memory 104, in at least some embodiments, is located on the same die as processor 102 or is separate from processor 102. Memory 104 includes volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM (DRAM), cache, etc.).

[0010] Storage 106, in at least some embodiments, comprises fixed or removable storage devices such as a hard disk drive, solid state drive, optical disk, flash drive, etc. Input device 108, in at least some embodiments, comprises, for example, a keyboard, a keypad, a touch screen, a touch pad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, or a network connection (e.g., a wireless local area network card for transmitting / receiving wireless signals), etc. Output device 110, in at least some embodiments, comprises, for example, a display, a speaker, a printer, a haptic feedback device, one or more lights, antennas, or a network connection (e.g., a wireless local area network card for transmitting / receiving wireless signals), etc.

[0011] In at least some embodiments, the input driver 112 communicates with the processor 102 and the input device 108, allowing the processor 102 to receive input from the input device 108. The output driver 114, in at least some embodiments, communicates with the processor 102 and the output device 110, allowing the processor 102 to send output to the output device 110. Note that the processing device 100 operates similarly without the input driver 112 and the output driver 114. The output driver 114, in at least some embodiments, includes an accelerated processing device (APD) 116 coupled to a display device 118. The APD accepts computational and graphics rendering commands from the processor 102, processes the computational and graphics rendering commands, and provides pixel output to the display device 118 for display. As described in more detail below, the APD 116 includes one or more parallel processing units that perform computations according to a single-instruction-multiple-data (SIMD) paradigm. Thus, although various functions are described herein as being performed by or in conjunction with APD 116, in other embodiments, the functions described as being performed by APD 116 are additionally or alternatively performed by other computing devices having similar capabilities that are not driven by a host processor (e.g., processor 102) to provide graphics output to display device 118. For example, in at least some embodiments, any processing system that performs processing tasks according to the SIMD paradigm performs the functions described herein. Alternatively, in at least some embodiments, computing systems that do not perform processing tasks according to the SIMD paradigm perform the functions described herein.

[0012] 2 is a block diagram of the processing device 100 and illustrates additional details regarding the execution of processing tasks on the APD 116. In at least some embodiments, the processor 102 maintains in the memory 104 one or more control logic modules for execution by the processor 102. The control logic modules, in at least some embodiments, include an operating system 202, a kernel mode driver 204, and an application 206. These control logic modules control various aspects of the operation of the processor 102 and the APD 116. For example, the operating system 202 communicates directly with the hardware and provides an interface to the hardware for other software executing on the processor 102. The kernel mode driver 204 controls the operation of the APD 116, for example, by providing an application programming interface (API) for software executing on the processor 102 (e.g., the application 206) to access various features of the APD 116. The kernel mode driver 204 also includes, in at least some embodiments, a just-in-time compiler that compiles programs for execution by processing components of the APD 116 (such as the SIMD unit 210, described in more detail below).

[0013] In at least some embodiments, the APD 116 executes commands and programs for selected functions, such as graphics and non-graphics operations that may be suitable for parallel processing. The APD 116, in at least some embodiments, is used to perform graphics pipeline operations (such as pixel operations, geometry calculations, etc.) and rendering of images to the display device 118 based on commands received from the processor 102. The APD 116 also performs computational operations not directly related to graphics operations, such as operations related to video, physics simulations, computational fluid dynamics, or other tasks, based on commands received from the processor 102.

[0014] The APD 116, in at least some embodiments, comprises computational units 208 (shown as 208-1 through 208-3) that include one or more SIMD units 210 (shown as 210-1 through 210-6) that perform operations at the request of the processor 102 in a parallel manner according to the SIMD paradigm, where multiple processing elements share a single program control flow unit and program counter to execute the same program but with different data. In one example, each SIMD unit 210 comprises 16 lanes, where each lane executes the same instruction simultaneously with other lanes in the SIMD unit 210, but may execute the instruction with different data. Lanes may be switched off with prediction if not all lanes execute a given instruction. Prediction may also be used to execute programs with branching control flows. More specifically, for programs with conditional branches or other instructions where the control flow is based on calculations made by individual lanes, prediction of lanes corresponding to currently not executed control flow paths and serial execution of different control flow paths allows arbitrary control flow.

[0015] In at least some embodiments, the basic unit of execution within the compute units 208 is a work item. Each work item represents a single instantiation of a program that executes in parallel on a particular lane. Work items, in at least some embodiments, can execute simultaneously as a "wavefront" on a single SIMD unit 210. One or more wavefronts are included in a "workgroup," which includes a collection of work items designated to execute the same program. A workgroup is executed by executing each of the wavefronts that make up the workgroup. In some embodiments, these wavefronts execute sequentially on a single SIMD unit 210, or execute partially or fully in parallel on different SIMD units 210. A wavefront, in at least some embodiments, represents the largest collection of work items that can execute simultaneously on a single SIMD unit 210. Thus, if commands received from processor 102 indicate that a particular program is to be parallelized to such an extent that it cannot be executed simultaneously on a single SIMD unit 210, then the program is split into wavefronts that are either parallelized on two or more SIMD units 210 or serialized (or both parallelized and serialized) on the same SIMD unit 210. Scheduler 212 performs operations related to scheduling the various wavefronts on the different compute units 208 and SIMD units 210.

[0016] The parallel processing provided by the compute units 208 is, in at least some embodiments, suitable for graphics-related operations such as pixel value calculations, vertex transformations, and other graphics operations. Thus, in some cases, the graphics pipeline 214, which accepts graphics processing commands from the processor 102, provides computational tasks to the compute units 208 for execution in parallel.

[0017] In at least some embodiments, the compute units 208 are used to perform computational tasks that are not related to graphics or that are not performed as part of the "normal" operation of the graphics pipeline 214 (e.g., custom operations performed to supplement the processing performed on the operation of the graphics pipeline 214). Applications 206 or other software executing on the processor 102 send programs defining such computational tasks to the APD 116 for execution.

[0018] 3 is a block diagram illustrating another example of a processing device 300 in which the power management techniques described herein may be implemented. In the example shown in FIG. 3, the processing device 300 is a system-on-a-chip (SoC) device 300. In at least some embodiments, the SoC device 300 includes components such as a data fabric 302, a CPU core complex 304, a GPU 306, a multimedia processing unit (MPU) 308, a display interface 310, an I / O hub 312, a memory controller 314, and a system management unit (SMU) 316. One or more of these and other components are comprised of intellectual property (IP) blocks / cores, which, in at least some embodiments, are reusable units of logic, cells, or integrated circuit (IC) layouts.

[0019] The data fabric 302, in at least one embodiment, includes circuitry for providing communication interconnections between various components of the SoC device 300. Any suitable interconnection hardware may be used in various implementations. In some implementations, from a physical perspective, the data fabric 302 is either implemented in a central location in the SoC device or distributed in multiple hubs throughout the SoC device 300 and interconnected using a suitable communication medium (e.g., a bus). From a logical perspective, the data fabric 302 is at the center of the data flow, and information regarding the idle state of different components (including IP blocks) of the SoC device 300 is centralized (e.g., stored) in the data fabric 302. In some implementations, this information is used by the SMU 316 in determining the appropriate time to transition one or more components of the SoC device 300 into a power management state, such as a sleep state.

[0020] In at least some embodiments, CPU core complex 304 includes one or more suitable CPU cores. In at least some embodiments, each of the cores in the complex includes a private cache and all of the cores in the complex communicate with a shared cache. In at least some embodiments, SoC device 300 includes multiple CPU core complexes. GPU 306, in at least some embodiments, includes any suitable GPU or combination of GPU hardware. MPU 308, in at least some embodiments, includes one or more suitable MPUs, such as an audio co-processor, an image signal processor, a video codec, etc.

[0021] The display interface 310, in at least some embodiments, includes any suitable hardware for driving one or more displays. The I / O hub 312, in at least some embodiments, includes any suitable hardware for interfacing the data fabric 302 with I / O devices 318, in at least some embodiments, includes one or more of a universal serial bus (USB), a peripheral component interconnect express (PCIe) bus, a non-volatile memory host controller interface (NVMe) bus, a serial advanced technology attachment (SATA) bus, a Gigabit Ethernet (xUBE), an inter-integrated circuit (I2C) bus, a secure digital (SD) interface, a general-purpose input / output (GPIO) connection, a sensor fusion I / O connection, and / or any other suitable I / O hardware. Thus, in at least some embodiments, I / O hub 312 may include a USB host controller, a PCIe root complex, an NVMe host controller, a SATA host controller, an xGBE interface, an I2C node, an SD host, a GPIO controller, a sensor fusion controller, and / or any other suitable I / O device interface.

[0022] The memory controller 314, in at least some embodiments, includes any suitable hardware for interfacing with the memory 320. The SMU 316, in at least some embodiments, comprises hardware and firmware for managing and accessing system configuration / status registers and memory, generating clock signals, controlling power rail voltages, and enforcing security access and policies for the SoC device 300. In at least some embodiments, the SMU 316 is interconnected with other blocks of the SoC device 300 using a system management communication network (not shown). The SMU 316 also, in at least some embodiments, manages the thermal and power state of the CPU core complex 304 and other components of the SoC device 300 (including individual IP blocks). Thus, the SMU 316 can control the power supplied to components and sub-components of the SoC device, such as the cores and IP blocks of the CPU core complex 304. In at least some embodiments, the SMU 316 is configured to adjust the operating points of the SoC components (e.g., cores of the CPU core complex 304) by changing the operating frequency or voltage supplied to the components.

[0023] In at least some embodiments, the SMU 316 is configured to transition components of the SoC device 300 into / out of one or more power management states. It should be noted that throughout this description, references to transitioning components of the SoC device 300 into / out of one or more power management states include transitioning the entire SOC device 300, an entire component such as the CPU core complex 304, the GPU 306, the MPU 308, the I / O hub 312, or a subcomponent of a component such as a core or IP block of the CPU core complex 304. Examples of power management states include an active state and one or more sleep states such as an idle state and a power-gated state. A sleep state may also be referred to as a low power state or a lower power state. In an active state, a component executes instructions and operates at a nominal operating frequency and operating voltage. In a sleep state, a component typically does not execute or operate instructions and may operate at a lower operating frequency / voltage. A component may also be power-gated in a sleep state such that power is disconnected from the component. For example, the SMU 316 issues signals or commands to gating logic connected to a power source. In this example, the gating logic controls the power provided to the component and gates the power by opening one or more circuits to block the flow of current to the component. In at least some embodiments, multiple levels of sleep states are implemented. As the sleep state level increases, less power is consumed by the component than the previous sleep state level. The lowest sleep state level may be referred to as the lightest sleep state, and the highest sleep state level may be referred to as the deepest sleep state. The lightest sleep state is a lower power sleep state than the deep (high power) sleep state. By transitioning the component to one or more sleep states, power may be conserved.

[0024] Although deeper sleep states may save more power than lighter sleep states, deeper sleep states typically impose performance and power penalties in transition duration. For example, assume a set of sleep states S={S1, S2, S3, ..., Sn}, where Sn is the deepest sleep state supported by the platform. For a component to enter the third sleep state S3, the component typically first enters the first sleep state S1, then transitions to the second sleep state S2, and then enters the third sleep state S3, according to a logical sequence of powering down the component and its subcomponents. Similarly, to transition from the third sleep state S3 to the active state, the component typically sequentially transitions from the third sleep state S3 to the second sleep state S2, then from the second sleep state S2 to the first sleep state S1, and then enters the active state. Entering each of these sequential sleep states consumes both time and power. More specifically, transitions into and out of each sleep state involve various actions taken by the SMU 316 that require extra time and power for such transitions. Deeper sleep states require more (or more resource intensive) actions for entry and exit than lighter sleep states. Deeper sleep states also typically take longer to recover to an active / working state than lighter sleep states, and therefore incur a larger latency penalty.

[0025] In at least some embodiments, the SMU 316 implements a fast sleep state transition mode for transitioning components to a sleep state. As described in more detail below, the SMU 316 selects a sleep state for a component of the SoC device 300 based on a predicted sleep state duration and a determined break-even duration where the benefit of transitioning to a sleep state exceeds (or at least equals) the cost of transitioning to a sleep state. The SMU 316 compares the predicted sleep duration to the break-even duration for one or more sleep states. Based on this comparison, the SMU 316 determines whether the component is placed in a deeper sleep state for a sufficiently long time such that the power savings associated with the deeper sleep state exceeds (or at least equals) the power consumed during entry and exit transitions to and from the deeper sleep state. If the predicted sleep duration meets the determined break-even duration for the deeper sleep state, the SMU 316 transitions the component to the deeper sleep state. However, if the predicted sleep duration does not meet the determined break-even duration of the deeper sleep state, the SMU 316 transitions the component to a lighter sleep state.

[0026] Thus, the fast sleep state mode of the SMU 316 improves the energy efficiency of the device because the SMU 316 can transition components directly to a deeper sleep state instead of consuming energy in an entry hysteresis period. In at least some embodiments, the fast sleep state transition mode can be enabled or disabled by hardware or software components of the SoC device 300 or another device coupled to the SoC device 300. If the fast sleep state transition mode is disabled, conventional power state management operations can be performed by the SMU 316. In at least some embodiments, a bit can be stored in a register, such as a model-specific register (MSR), to inform other hardware, software, or an operating system whether the fast sleep state transition mode is enabled or disabled.

[0027] 4 is a block diagram illustrating a more detailed view of the SMU 316 according to at least some embodiments. Although the SMU 316 is described herein as being implemented by the SoC device 300, it should be noted that the SMU 316 may be implemented by the processing device 100 of FIG. 1. In the example shown in FIG. 4, the SMU 316 comprises a monitoring module 402, a sleep duration prediction module 404, a sleep state selection module 406, a sleep state promotion module 408, a decision error feedback module 410, and one or more storage devices 412. It should be noted that in at least some embodiments, one or more of these components are implemented in another component of the SoC device 300 (or processing device 100) different from the SMU 316, such as a central microcontroller, an individual IP management controller, etc.

[0028] The monitoring module 402, in at least some embodiments, monitors and records the sleep state durations of the components of the SoC device 300. In at least some embodiments, the sleep state duration (τ) of a component is defined as the time (duration) between the SMU 316 receiving an interrupt for the lowest level sleep state (e.g., sleep state S0) and receiving any wake event for the component. In other words, the sleep state duration of a component is the time between the start of a first transition (which may include an entry hysteresis) in which the component is transitioned from an active state to a sleep state, and the start of a second transition in which the component is transitioned from the sleep state back to an active state. Note that in other embodiments, the sleep state duration is defined using different parameters. In at least some embodiments, the monitoring module 402 records the sleep state durations of the components using one or more internal timers.

[0029] The monitoring module 402, in at least some embodiments, records / stores the sleep state durations as history duration information 414 in one or more storage devices 412. In at least some embodiments, the one or more storage devices 412 are located locally in the SMU 316, remote from the SMU 316, or a combination thereof. The history duration information 414, in at least some embodiments, is stored at a device level, a component level, a sub-component level, a combination thereof, and the like. If the history duration information 414 is recorded and stored at the device level, entries are stored for the past n sleep state durations across all components of the SoC device 300. For example, if n=32, the history duration information 414 comprises entries for the previous 32 sleep state durations associated with any of the components of the SoC device 300 in this example. If the history duration information 414 is recorded and stored at the component or sub-component level, each component or sub-component is associated with its own history duration entry. For example, if n=32, then the history duration information 414 in this example comprises an entry for the first component's 32 previous sleep durations, an entry for the second component's 32 previous sleep state durations, etc. In at least some embodiments, each component or subcomponent is associated with a separate data structure that has associated therewith history duration information 414. In at least some embodiments, the number of previous sleep state durations recorded by the monitoring module 402 is configurable.

[0030] The sleep duration prediction module 404, in at least some embodiments, utilizes the historical duration information 414 to predict the duration of the next sleep state. For example, if the SMU 316 determines that a given component is idle, the sleep duration prediction module 404 processes the historical duration information 414 to predict the duration of the component's next sleep state. In at least some embodiments, the sleep duration prediction module 404 stores the predicted sleep state duration 416 in one or more storage devices 412.

[0031] The sleep state selection module 406, in at least some embodiments, determines an appropriate sleep state for a component of the SoC device 300. In at least some embodiments, the sleep state selection module 406 selects a sleep state from a plurality of sleep states that results in the least amount of energy consumed and the least impact on performance (referred to herein as a selection criterion). The sleep state selection module 406, in at least some embodiments, identifies a sleep state that meets the selection criterion based on a predicted sleep state duration 416 and a sleep state break-even duration 418, also referred to as a break-even duration 418 or a break-even threshold 418. The sleep state break-even duration 418 indicates an amount of time that a component should remain in a sleep state such that the energy saved by being placed in the sleep state is at least equal to the energy cost of transitioning in and out of the sleep state. For example, the break-even duration 418 of the sleep state S2 indicates an amount of time that a component should remain in the sleep state S2 such that the energy saved by being placed in the sleep state S2 is at least equal to the energy cost of transitioning in and out of the sleep state S2.

[0032] The sleep state selection module 406, in at least some embodiments, stores the break-even duration 418 in one or more storage devices 412. In at least some embodiments, the sleep state selection module 406 uses latency tolerance information 420 associated with one or more I / O devices 318 (e.g., PCIe devices, USB devices, etc.), APIC interrupt timer values, or combinations thereof, to select a sleep state for the component. The latency tolerance information 420, in at least some embodiments, indicates a busy level of the I / O devices 318. The APIC interrupt timer value indicates the time until the next APIC interrupt. Once a sleep state is selected, the SMU 316 proceeds to transition the component to the selected sleep state by performing one or more operations (e.g., flushing caches, gating clocks, powering down voltage rails, etc.).

[0033] The sleep state promotion module 408, in at least some embodiments, takes corrective action if it determines that an incorrect (less efficient) sleep state has been selected by the sleep state selection module 406. For example, the sleep state promotion module 408 monitors the component while in the selected sleep state to determine whether the component has been in the selected sleep state longer than a predefined threshold. If so, the sleep state promotion module 408, in at least some embodiments, transitions the component to the next deeper sleep state.

[0034] The decision error feedback module 410, in at least some embodiments, monitors the sleep state decisions made by the sleep state selection module 406 to detect errors. Examples of detected errors include selecting a lighter sleep state when a deeper sleep state should have been selected, or selecting a deeper sleep state when a lighter sleep state should have been selected. An incorrect sleep state selection is the result of, for example, an incorrect sleep duration prediction. Thus, in at least some embodiments, the decision error feedback module 410 provides input to the sleep duration prediction module 404 such that the sleep duration prediction module 404 adjusts its subsequent sleep duration predictions to reduce sleep state selection errors.

[0035] 5 is a flow chart outlining one exemplary method 500 for improving energy efficiency of a processing device by transitioning components directly to a deeper sleep state instead of consuming energy during an entry hysteresis period. The monitoring module 402 monitors sleep state durations of components of the SoC device 300, at block 502. The sleep duration prediction module 404 predicts a sleep duration for which the components of the SoC device 300 will be transitioned to a sleep state, at block 504. The sleep state selection module 406 selects a sleep state for the components based on the predicted sleep duration, at block 506. The SMU 316 transitions the components to the selected sleep state, at block 508. In at least some embodiments, the sleep state promotion module 408 promotes the current sleep state of the components to a deeper sleep state, at block 510.

[0036] FIG. 6 is a flow chart illustrating an example of a more detailed method 600 for the sleep state duration monitoring process shown in block 502 of FIG. 5. In at least some embodiments, the monitoring module 402 is invoked based on a determination being made in block 602 that a component of the SoC device 300 should be transitioned to a sleep state. For example, the SMU 316 receives or detects an interrupt indicating that one or more components of the SoC device 300 are idle. In block 604, based on the determination that the component should be transitioned to a sleep state, one or more timers are initialized. In block 606, a determination is made whether a wake event has been detected / received for the component. If a wake event has not been detected, the monitoring module 402 maintains the timer until a wake event is detected. If a wake event is detected for the component, the timer is stopped in block 608. In at least some embodiments, the recorded time between the SMU 316 receiving a sleep state request interrupt and receiving a wake event for the component is referred to as the sleep state duration of the component. However, other configurations for the sleep duration are equally applicable.

[0037] In at least some embodiments, if the sleep state of a component is a deeper sleep state, the sleep state duration includes not only the duration of time the component was placed in the deeper sleep state, but also the time spent transitioning the component through the lighter sleep states. For example, assume a list of sleep states S=(S1, S2, ..., Sn), where Sn is the deepest sleep state supported by the components of the SoC device 300. A component typically enters a first sleep state S1 and then a deeper sleep state S2 by a logical sequence of powering down the component or its sub-components. Thus, if sleep state S2 is selected for a component, the sleep state duration of the component includes the time the component was placed in sleep state S2 and the time spent transitioning the component from the active state to each lighter state. In at least some embodiments, the sleep states are associated with an entry hysteresis. In these embodiments, the sleep state duration of a component also includes the hysteresis latency of the sleep state.

[0038] FIG. 7 shows an illustrative example of timing for transitioning components of the SoC device 300 to a first sleep state (SLEEP1) and a deeper second sleep state (SLEEP2). In particular, FIG. 7 shows a first timing sequence 702 for transitioning the components to the first sleep state and a second timing sequence 704 for transitioning the components to the deeper second sleep state. In the example shown in FIG. 7, H corresponds to an entry hysteresis latency, which is a delay period before transitioning the components from an active state to a target sleep state. T corresponds to an entry latency and an exit latency, which is the time it takes to transition the components from one state to another, and S corresponds to the duration of time the components are placed in the target sleep state. In the example shown in FIG. 7, the timing sequence 702 for the first sleep state SLEEP1 includes an entry hysteresis latency 706 (H SLEEP1 ), Entry Latency 708(TSLEEP1,entry ), Sleep duration 710(S SLEEP1,sleep ), and exit latency 712(T SLEEP1,exit ) Thus, in this example, the sleep state duration τ of the first sleep state is defined as follows: (Formula 1) τ=H sleep1 +T sleep1,entry +S sleep1,sleep

[0039] The timing sequence 704 for the second sleep state SLEEP2 includes an entry hysteresis latency 706 (H Sleep1 ), the entry latency of the first sleep state 708 (T Sleep1,entry ), the entry latency of the second sleep state 714 (T Sleep2,entry ), the sleep duration 716 of the second sleep state (S Sleep2,sleep ), and the exit latency of the second sleep state is 718 (T Sleep2,exit ), and the exit latency 712 (T Sleep1,exit ) Thus, in this example, the sleep state duration τ of the second sleep state is defined as: (Formula 2) τ=H sleep1 +T sleep1,entry +T sleep2,entry +S sleep2,sleep

[0040] 6, the monitoring module 402, at block 610, records the determined sleep state durations for the components as historical duration information 414. As discussed above, the historical duration information 414, in at least some embodiments, is stored at the device level, the component level, the sub-component level, combinations thereof, and the like. In at least some embodiments, if the historical duration information 414 is recorded per component or sub-component, the components or sub-components communicate their busy / idle status to the SMU 316. By recording the duration information 414 per component, the SMU 316 can optimize power for clusters of components, such as multimedia cores, based on idle patterns.

[0041] FIG. 8 is a flow chart illustrating an example of a more detailed method 800 for the sleep state duration prediction process shown in block 504 of FIG. 5. In at least some embodiments, the sleep duration prediction module 404 is invoked based on a determination made in block 802 that a component of the SoC device 300 should be transitioned to a sleep state. In block 804, historical duration information 414 is obtained. In at least some embodiments, the historical duration information 414 is obtained for the SoC device 300 as a whole, while in other embodiments, the historical duration information 414 is obtained for the component. The historical duration information 414 is processed in block 806 using one or more techniques, such as a median calculation, a moving average metric or other statistical metric, machine learning, a combination thereof, etc. Then, in block 808, a next sleep state duration 416 of the component is predicted based on processing the historical sleep state duration information. For example, assume a historical duration D={D1, D2, D3, ..., DL}. where Di represents the duration of the i-th sleep in seconds, and L is the total number of recorded sleep durations. In this example, the sleep duration prediction module 404 predicts the component's next sleep state duration 416 by calculating D_median=median(D) and sends it to the sleep state selection block 506 to determine the appropriate sleep state. The predicted sleep state duration 416 is then stored or sent, for example, for use by or to the sleep state selection module 406.

[0042] In at least some embodiments, the SMU 316 implements an error feedback module 410 that provides input to the sleep duration prediction module 404. In these embodiments, the sleep duration prediction module 404 uses feedback input from the error feedback module 410 in addition to the historical duration information 414 to predict the component's next sleep state duration 416. The error feedback module 410, in at least some embodiments, monitors the number of incorrect sleep state selections made by the sleep state selection module 406 based on the predicted sleep state duration 416. In one example, a sleep state selection is determined to be incorrect if a deeper sleep state is selected but the component's actual sleep state duration indicates that a lighter sleep state should have been selected. In another example, a sleep state selection is incorrect if a lighter sleep state is selected but the component's actual sleep state duration indicates that a deeper sleep state should have been selected. The error feedback module 410 implements one or more mechanisms, such as a proportional-integral-derivative (PID) controller, to provide input, such as a correction, to the sleep duration prediction module 404. The sleep duration prediction module 404 implements the input received from the error feedback module 410 to adjust its prediction operation to provide a more accurate predicted sleep state duration 416. For example, the sleep duration prediction module 404 uses the feedback input to adjust one or more parameters for predicting the sleep state duration of the components of the SoC device 300.

[0043] FIG. 9 is a flow chart illustrating an example of a more detailed method 900 for the sleep state selection process shown in block 506 of FIG. 5. In the method 900, at block 902, a break-even duration 418 is determined for one or more sleep states available to a component of the SoC device 300. As described above, the break-even duration 418 of a given sleep state is the amount of time that a component should remain in a sleep state such that the energy saved by being placed in the sleep state is at least equal to the energy consumed by only transitioning to and remaining in a lighter sleep state. The energy of a given sleep state is determined, in at least some embodiments, based not only on the given sleep state but also on any lower level sleep states. For example, consider a list of sleep states S=(S1, S2, ..., Sn), where Sn is the deepest sleep state supported by the component of the SoC device 300. As described above, a component typically enters a first sleep state S1 and then enters a sleep state S2 according to a logical sequence for powering the component or its sub-components. Thus, in this example, the energy for sleep state S2 is calculated based on (1) the energy required to enter sleep states S1 and S2, (2) the energy required to remain in sleep states S1 and S2, and (3) the energy required to exit sleep states S1 and S2.

[0044] For example, referring back to FIG. 7, the sleep state selection module 406 determines the energy (E) for the sleep states SLEEP1 sequence 702 and SLEEP2 sequence 704 for a given (predicted) sleep state duration τ as follows: (Formula 3) E sleep1 =(H sleep1 P sleep0 )+(T sleep1,entry P sleep1,entry )+((τ-(H sleep1 +T sleep1,entry ))·P sleep1 )+(Tsleep1,exit P sleep1,exit ) Here, P sleep is the power consumed when placed in the corresponding sleep state, and P entry is the power consumed during entry into the sleep state, and P exit is the power consumed during exit from a sleep state. (Formula 4) E sleep2 =(H sleep1 P sleep0 )+(T sleep1,entry P sleep1,entry )+(T sleep2,entry P sleep2,entry )+(τ-(H sleep1 +T sleep1,entry +T sleep2,entry ))·P sleep2 +(T sleep2,exit P sleep2,exit )+(T sleep1,exit P sleep1,exit )

[0045] The sleep state selection module 406 determines the break-even duration 418 for a given sleep state based on the calculated energy E for the sleep state and one or more lighter sleep states. For example, in at least some embodiments, the sleep state selection module 406 determines the break-even duration 418 for a given sleep state if the energy E of the sleep state is equal to the energy of one or more previous sleep states. * Thus, in the present example, the sleep state selection module 406 determines the break-even duration 418 of a given sleep state as a value of E sleep1 =E sleep2, If so, the break-even duration of the sleep state SLEEP2 (τ * ) 418 to τ * The value is calculated according to the following formula:

[0046]

number

[0047] Returning now to FIG. 9 , in block 904, the predicted sleep state duration 416 of the component is compared to the break-even duration 418 determined for one or more of the sleep states available to the component. In block 906, a sleep state is selected based on this comparison. In at least some embodiments, the deepest sleep state is selected such that the predicted sleep state duration 416 of the component meets the break-even duration 418 of the selected sleep state. For example, consider a first sleep state and a deeper second sleep state. In this example, the break-even duration / threshold 418 of the second sleep state is 1.5 ms. Thus, if the predicted sleep state duration 416 of the component is equal to 1.5 ms, or in other embodiments is greater than 1.5 ms, the sleep state selection module 406 selects the deeper second sleep state for the component. However, if the predicted sleep state duration 416 of the component is less than 1.5 milliseconds, and in other embodiments is less than 1.5 milliseconds, the sleep state selection module 406 selects a first, lighter sleep state for the component. Once a sleep state is selected for the component, control proceeds to block 508 of FIG. 5, where the component is transitioned to the selected sleep state.

[0048] In at least some embodiments, the sleep state selection module 406 uses the latency tolerance information 420 of the I / O device 318 when selecting a sleep state for the component. The latency tolerance information 420, in at least some embodiments, includes a value that indicates the busy level of the associated I / O device 318. In one example, a long value indicates idle and a short value indicates that the I / O device 318 is active. In some embodiments, the latency tolerance information 420 is exposed to the sleep state selection module 406 via one or more registers. In addition to the latency tolerance information 420, in at least some embodiments, an advanced programmable interrupt controller (APIC) value is used by the sleep state selection module 406 when making the sleep state selection. There are multiple APIC timers that, upon expiration, issue an interrupt to wake the processor. The APIC timer value made available to the sleep state selection module 406 indicates the time until the next APIC interrupt. Thus, the sleep state selection module 406, in at least some embodiments, monitors the next required timer interrupt to determine whether the initial sleep state selection should be updated. For example, if the sleep state selection module 406 initially selects a deeper sleep state, but the latency tolerance information 420 indicates an active I / O device 318 or the APIC value indicates that an interrupt will be issued within a predefined time threshold, the sleep state selection module 406 updates the sleep state selection to a lighter sleep state.

[0049] FIG. 10 is a flow chart illustrating an example of a more detailed method 1000 for the sleep state promotion process shown in block 510 of FIG. 5. In the method 1000, at block 1002, one or more sleep state promotion attributes are determined for the sleep state of the component. For example, the amount of time that the component has been in the selected sleep state (current sleep state duration) is determined. In at least some embodiments, the sleep state promotion module 408 uses one or more timers to determine the current sleep state duration of the component. In another example, a percentage or number of long sleep durations in the historical duration information 414 are identified. A long sleep duration, in at least some embodiments, is a sleep duration that exceeds a predetermined sleep duration threshold. The one or more sleep state promotion attributes are compared to a sleep state promotion criterion at block 1004. At block 1006, a determination is made whether the one or more sleep state promotion attributes meet the sleep state promotion criterion. For example, a determination is made whether the current sleep state duration of the component is equal to or greater than a threshold amount of time. In another example, a first determination is made whether the component's current sleep state duration is greater than or equal to a threshold amount of time, and a second determination is made whether the percentage / number of long sleep durations is greater than or equal to a threshold percentage / number.

[0050] If one or more sleep state promotion attributes do not meet the sleep state promotion criteria, then at block 1008 the current sleep state is maintained (i.e., the sleep state is not promoted). Control then passes to block 1012. However, if one or more sleep state promotion attributes meet the sleep state promotion criteria, then at block 1010 the component is transitioned from the current sleep state to at least the next deepest sleep state. At block 1012, a determination is made whether a wake event has been detected for the component. If a wake event has not been detected for the component, control flow returns to block 1002. However, if a wake event has been detected, then at block 1014 the component exits sleep state promotion mode.

[0051] The power management techniques described herein improve the energy efficiency of processing devices by transitioning components directly into deeper sleep states instead of consuming energy during an entry hysteresis period. Various embodiments described herein implement fewer tunable parameters to reduce post-silicon ramp-up time / complexity, provide improved performance across a range of workloads by being workload adaptive, enable future expansion / improvements by making the sleep state prediction system / algorithm modular, and decouple the prediction system / algorithm from operating system hints.

[0052] In some embodiments, the above apparatus and techniques are implemented in a system that includes one or more integrated circuit (IC) devices (also referred to as integrated circuit packages or microchips). In at least some embodiments, electronic design automation (EDA) and computer aided design (CAD) software tools can be used to design and manufacture these IC devices. These design tools are typically represented as one or more software programs. The one or more software programs include code executable by a computer system to operate the computer system to operate on code representing circuits of one or more IC devices to perform at least a portion of a process for designing or adapting a manufacturing system to manufacture the circuits. This code may include instructions, data, or a combination of instructions and data. The software instructions representing the design tool or manufacturing tool are typically stored in a computer readable storage medium accessible to the computing system. Similarly, code representing one or more stages of the design or manufacture of the IC device is stored in and accessed from the same computer readable storage medium or a different computer readable storage medium.

[0053] In at least some embodiments, a computer-readable storage medium includes any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media can include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical systems (MEMS) based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.

[0054] In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied in a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by the one or more processors, operate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device such as a flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s), etc. The executable instructions stored in the non-transitory computer-readable storage medium may be implemented as source code, assembly language code, object code, or other form of instructions that can be interpreted or otherwise executed by one or more processors.

[0055] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, some of the specific activities or devices may not be required, one or more additional activities may be performed, and one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will appreciate that various changes and modifications can be made without departing from the scope of the invention as set forth in the claims. Thus, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the invention.

[0056] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and features by which any benefit, advantage, or solution may occur or be manifested are not to be construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, as the disclosed invention may be modified and practiced in different but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as set forth in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and all such variations are considered to be within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

Claims

1. 1. A method comprising: predicting sleep state durations for components of the processing device based on feedback associated with one or more previous selections of the sleep state; transitioning the component to a selected sleep state from a plurality of sleep states based on a comparison of the predicted sleep state duration to at least one duration threshold, each sleep state of the plurality of sleep states being a lower power state than a previous sleep state of the plurality of sleep states. method.

2. transitioning the component to the selected sleep state includes transitioning the component without an entry hysteresis delay.

2. The method of claim 1.

3. the sleep state duration is predicted based on historical sleep state duration information; 2. The method of claim 1.

4. the historical sleep state duration information includes durations of previous sleep states associated with the processing device; The method of claim 3.

5. the at least one duration threshold indicates a duration of time for which the component is placed in a sleep state associated with the at least one duration threshold such that energy saved by being placed in the sleep state is at least equal to an energy cost for transitioning the component into and out of the sleep state.

2. The method of claim 1.

6. Selecting the sleep state comprises: determining that the predicted sleep state duration does not meet the at least one duration threshold; selecting a first sleep state of the plurality of sleep states that is a higher power state than at least a second sleep state of the plurality of sleep states in response to the predicted sleep state duration not meeting the at least one duration threshold.

2. The method of claim 1.

7. Selecting the sleep state comprises: determining that the predicted sleep state duration meets the at least one duration threshold; selecting a first sleep state of the plurality of sleep states that is a lower power state than at least a second sleep state of the plurality of sleep states in response to the predicted sleep state duration satisfying the at least one duration threshold.

2. The method of claim 1.

8. The method of claim 7, wherein the feedback indicates that one or more erroneous selections of a sleep state were previously made; and predicting the sleep state duration includes adjusting one or more parameters used to predict the sleep state duration based on the feedback.

2. The method of claim 1.

9. A method comprising: predicting a sleep state duration of a component of a processing device; selecting an initial sleep state from a plurality of sleep states based on a comparison of the predicted sleep state duration to at least one duration threshold, each of the plurality of sleep states being a lower power state than a previous sleep state of the plurality of sleep states; determining that an interrupt associated with the component is issued within a threshold time; selecting a different sleep state from the plurality of sleep states in response to determining that an interrupt associated with the component is issued within the threshold time, the different sleep state being a higher power state than the initial sleep state; transitioning the component to the different sleep state. method.

10. determining a duration for which the component is currently in the selected sleep state; comparing said duration to a threshold time; transitioning the component to a different sleep state based on the duration meeting the threshold time, the different sleep state being a lower power state than the selected sleep state.

2. The method of claim 1.

11. determining a duration for which the component is currently in the selected sleep state; determining a percentage of sleep state durations in a set of historical sleep state durations associated with the processing device that meet a threshold duration; comparing said duration to a threshold time; comparing said sleep state duration percentage to a threshold percentage; transitioning the component to a different sleep state based on the duration meeting the threshold time and the percentage of the sleep state duration meeting the threshold percentage, the different sleep state being a lower power state than the selected sleep state.

2. The method of claim 1.

12. 1. A processing device, comprising: A processor; a sleep state duration prediction module that predicts a sleep state duration of a component of the processing device based on feedback associated with one or more previous selections of a sleep state; a system management unit for transitioning the component to a selected sleep state from a plurality of sleep states based on a comparison of the predicted sleep state duration to at least one duration threshold, each sleep state of the plurality of sleep states being a lower power state than a previous sleep state of the plurality of sleep states. Processing device.

13. the system management unit transitions the component to the selected sleep state without an entry hysteresis delay; The processing device of claim 12.

14. the sleep state duration is predicted based on historical sleep state duration information including durations of previous sleep states associated with the processing device; The processing device of claim 12.

15. A sleep state selection module is provided, The sleep state selection module includes: determining that the predicted sleep state duration does not meet the at least one duration threshold; selecting a first sleep state of the plurality of sleep states that is a higher power state than at least a second sleep state of the plurality of sleep states in response to the predicted sleep state duration not meeting the at least one duration threshold; selecting the sleep state from the plurality of sleep states by The processing device of claim 12.

16. A sleep state selection module is provided, The sleep state selection module includes: determining that the predicted sleep state duration meets the at least one duration threshold; selecting a first sleep state of the plurality of sleep states that is a lower power state than at least a second sleep state of the plurality of sleep states in response to the predicted sleep state duration satisfying the at least one duration threshold; selecting the sleep state from the plurality of sleep states by The processing device of claim 12.

17. a feedback module for providing the feedback to the sleep state duration prediction module, the feedback indicating that one or more erroneous sleep state selections have been made; the sleep state duration prediction module adjusts one or more parameters used to predict the sleep state duration based on the feedback. The processing device of claim 12.

18. Equipped with a sleep state promotion module, The sleep state promotion module includes: determining a duration for which the component is currently in the selected sleep state; comparing said duration to a threshold time; transitioning the component to a different sleep state based on the duration meeting the threshold time, the different sleep state being a lower power state than the selected sleep state; and [0023] The processing device of claim 12.

19. 1. A processing device, comprising: A processor; a monitoring module that monitors a duration of each sleep state of a plurality of sleep states associated with the processing device and stores the durations as historical sleep state durations; a sleep state duration prediction module that predicts a sleep state duration of a component of the processing device based on the historical sleep state duration and feedback associated with one or more previous selections of a sleep state; a system management unit for transitioning the component to a selected sleep state from a plurality of sleep states based on a comparison of the predicted sleep state duration to at least one duration threshold, each sleep state of the plurality of sleep states being a lower power state than a previous sleep state of the plurality of sleep states. Processing device.

20. Equipped with a sleep state promotion module, The sleep state promotion module includes: determining that the duration that the component has currently been in the selected sleep state satisfies a threshold time; transitioning the component to a different sleep state, the different sleep state being a lower power sleep state than the selected sleep state; [0023] 20. The processing device of claim 19.

21. A processing device comprising: A processor; a sleep state duration prediction module for predicting a sleep state duration of a component of the processing device; a sleep state prediction module; A system management unit, The sleep state prediction module includes: selecting an initial sleep state from a plurality of sleep states based on a comparison of the predicted sleep state duration to at least one duration threshold, each of the plurality of sleep states being a lower power state than a previous sleep state of the plurality of sleep states; determining that an interrupt associated with the component is issued within a threshold time; selecting a different sleep state from the plurality of sleep states in response to determining that the interrupt is issued within the threshold time, the different sleep state being a higher power state than the initial sleep state; The device is configured to: The system management unit includes: configured to transition the components to the different sleep states. Processing device.

Images