Power sequencer for power state management

Abstract

A method, system, and apparatus for handling applications in a peripheral computing system, one of the apparatuses including a plurality of devices arranged in a plurality of power blocks, each device of the plurality of devices belonging to one of the plurality of power blocks, one of the apparatuses further including a plurality of local power managers, each local power manager programmable to execute a respective set of instruction sequences for a respective power block to effect power state transitions for one or more devices in the respective power block.

Description

Background Art

[0001] Background This specification relates to a system having an integrated circuit device.

[0002] A system-on-chip (SoC) is an integrated circuit that integrates different components of a mobile computing device, including a central processing unit (CPU), memory, input / output ports, cellular radio, secondary storage, etc. In contrast to the conventional motherboard-based PC architecture where a motherboard houses and connects removable or replaceable components, an SoC integrates all these components into a single integrated circuit. SoCs are generally used in mobile computing, edge computing, and embedded systems such as smartphones, tablet computers, WiFi routers, Internet of Things (IoT) devices, etc.

[0003] An SoC can include multiple devices that require power management. Power management manages the power state transitions for each device to optimize power consumption and utilization, such as achieving a longer battery life and reducing power consumption. For example, when the CPU is in an idle state, the system can change the power state of the CPU to a low-power state (e.g., switch to a lower voltage) to reduce power consumption. Power management can include turning power on / off, controlling voltage or frequency, and switching to a low-power state when inactive.

[0004] Power management for a SoC is generally performed by using a state machine or a microcontroller. A state machine is a hardware-based solution that implements power state transitions in hardware. A state machine-based solution provides fast state transitions and occupies less silicon area, but a state machine-based solution limits the ability to make changes and debug problems after the chip has been manufactured. A microcontroller-based solution uses a general-purpose microcontroller and implements power state transitions in software. A microcontroller-based solution provides better flexibility for modification and debugging, but a microcontroller-based solution takes a longer time for power state transitions. In addition, since a microcontroller-based solution uses a general microcontroller with a large instruction memory and a large data memory along with a debug / trace infrastructure, this often limits the number of instances of microcontrollers in one SoC, and the SoC generally has only one microcontroller that manages the power states of all devices in the SoC. SUMMARY OF THE INVENTION

[0005] Summary This specification describes techniques for implementing a local power manager for power state management. Each local power manager is configured to execute custom instructions defined for power management that cause a sequence of hardware transitions required to transition from one power state to the next. Relative to instructions executed by a general-purpose microcontroller, custom instructions are small in size and are specifically defined for power management tasks. A local power manager can respond to a received trigger event and execute custom instructions to effect a power state transition in response to the trigger event.

[0006] The subject matter described in this specification can be implemented in certain embodiments to achieve one or more of the following advantages. By using a dedicated and specially designed instruction sequence for power management, the local power manager provides faster state transitions while also providing flexibility for modification and debugging. That is, the local power manager can achieve the performance / response latency of a hardware-based solution as well as the flexibility and programmability of a microcontroller. In contrast to general computing devices (e.g., microcontrollers) that include a large number of functionalities, the local power manager can maintain a small set of instructions and does not need to include mathematical operations. Unlike microcontroller-based solutions, the local power manager can have direct access to hardware-level signals for debugging. One SoC can integrate multiple local power managers that can independently control the power states of multiple devices or subsystems on the chip. Instead of having one local power manager per device within the SoC, the SoC can include local power managers that manage the power state transitions of multiple devices that are logically part of the same subsystem, thus enabling sharing of common resources and reducing power consumption and silicon area consumption. Thus, the local power manager can achieve the performance of state-machine-based solutions and the flexibility of microcontroller-based solutions while having a similar area consumption to state-machine-based solutions.

[0007] Details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

[0009] Same reference numerals and designations in the various drawings indicate the same components. Detailed Description FIG. 1 is a diagram of an exemplary computing device 100. The computing device 100 can be a system-on-chip (SoC) device installed in a mobile device (e.g., a smartphone or a tablet). The SoC can be an integrated circuit that includes components of each system on one silicon substrate or on multiple interconnected dies using, for example, a silicon interposer, stacked dies, or an interconnect bridge.

[0010] The computing device 100 includes a plurality of devices having different power requirements under different states. For example, when a user launches a camera app on a mobile device, the SoC can turn on the power of an image processor integrated in the SoC. When the camera app is closed, the SoC can turn off the power of the image processor.

[0011] Examples of multiple devices include one or more central processing units (CPUs), one or more tensor processing units (TPUs), one or more sensors, one or more displays, and the like. Computing device 100 can include multiple such devices, for example, 10, 50, or 100 devices. The computing device 100 in FIG. 1 is simplified for illustration purposes and includes three devices, namely device A1 (113), device A2 (115), and device B1 (123).

[0012] At any given time, each device is in a specific power state. The power state indicates the level of power consumption of the device (e.g., the range of computing operations). Examples of power states can include active, Run Fast, Run Slow, hibernate, and the like. The power state of a device changes as needed to conserve power consumption. Computing device 100 performs power management to manage the power state transitions for each device and optimize the power consumption of the mobile device.

[0013] The multiple devices in computing device 100 are arranged in multiple power blocks. A power block includes a group of devices, and the power management of the group of devices can be correlated. For example, the group of devices can be powered up or powered down together. Multiple devices in the same power block may be logically dependent and can belong to the same subsystem. For example, computing device 100 includes two power blocks, namely power block A (110) and power block B (120). Device A1 (113) and device A2 (115) belong to power block A (110), and device B1 (123) belongs to power block B (120).

[0014] Computing device 100 includes a plurality of local power managers (LPMs) that operate independently. Each local power manager can be programmed to execute a respective set of instruction sequences for respective power blocks. Each local power manager can manage power state transitions for one or more devices in its respective power block. Each local power manager can control each device in its respective power block to transition from one power state to another.

[0015] For example, the computing device includes a local power manager 112 for power block A (110) and a local power manager 122 for power block B (120). Local power manager 112 can manage power state transitions for devices A1 and A2. Local power manager 122 can manage power state transitions for device B1.

[0016] Rather than having a single microcontroller that controls all devices in computing device 100, computing device 100 includes a plurality of LPMs that each independently control one or more devices. Compared to a microcontroller-based solution, the power sequencer-based solution can reduce latency and delay by using a plurality of local power managers to independently control the power state transitions of multiple devices on the chip.

[0017] Each local power manager can execute a power state transition based on a plurality of power state tables. Each power state table stores possible power state transitions for respective devices. Each power state transition changes the power state from an initial state to the next state. For example, the local power manager 112 can store a power state table A1 (114) and a power state table A2 (116). The power state table A1 stores a plurality of power state transitions for the device A1. The power state table A2 stores a plurality of power state transitions for the device A2. The local power manager 112 can execute a transition sequence generated by the power state table A1 (114) to perform a power state transition of the device A1 (113). The local power manager 112 can execute a transition sequence generated by the power state table A2 (114) to perform a power state transition of the device A2 (113).

[0018] A plurality of different power state tables controlled by the same LPM can interact with each other and can have dependencies. For example, synchronization can be performed among the power states and / or power state transitions of the device A1 and the device A2 controlled by the same LPM112. As another example, the power state transition for the device A1 can depend on a specific power state transition of the device A2.

[0019] Compared with state machine-based solutions, the local power manager can be modified post-silicon, i.e., after the computing device 100 is manufactured. For example, assume that the power management of device A2 (115) depends on the current power state of device A1 (113). After the chip is manufactured and has been operating for a while, if device A1 (113) is no longer in use, the local power manager 112 can be reprogrammed so that the power management logic of device A2 (115) no longer depends on the power state of device A1. Instead of having to remanufacture the entire chip as in the case of state machine-based power management solutions, the power sequencer-based solution can provide flexibility for post-silicon modifications.

[0020] As another example, when an error is found in a power management command during or after manufacturing time, the local power manager can be reprogrammed to remove the error from the command rather than remanufacturing the chip. As another example, if an engineer develops an improvement in power management after the chip is manufactured, the engineer can reprogram the local power manager without having to remanufacture the chip. New power states due to changes in product specifications or other optimizations can be added after the chip is manufactured. For example, after the chip is manufactured, new power states can be identified through optimization experiments in the laboratory, and these new power states can be added by reprogramming the local power manager.

[0021] FIG. 2 is a diagram of an exemplary local power manager (LPM) 200. The local power manager 200 is a configurable power manager for controlling power state transitions for one or more devices in computing device 100, such as devices in a SoC. The local power manager 200 includes trigger logic 204, one or more power state tables 208, and one or more power sequencers 212. The trigger logic 204 is configured to receive event signal 202 as input and output trigger signals 206. The one or more power state tables 208 are configured to store a mapping between trigger signal 206 and power state transitions. The one or more power sequencers 212 are configured to execute respective instruction sequences when a power state transition is triggered by trigger signal 206.

[0022] The local power manager 200 receives event signal 202 as input and uses trigger logic 204 to generate one or more trigger signals 206. The event signal can include one or more input signals that can be logically combined to trigger a power state transition. The event signal 202 can include multiple event signals for multiple events. The events of event signal 202 can include external events or software events that trigger power state transitions. Examples of external events include inputs from general purpose input / output (GPIO), system timers, requests from other LPMs, interrupts, core logic related to power transitions (e.g., reducing power consumption when there is no activity), data obtained from one or more sensors of computing device 100, etc. An event signal that includes a logical value can be in an on state or an off state. In some implementations, each event signal can be enabled or disabled via a control and status register (CSR). In some implementations, it can be assumed that the event signal is active high when the event signal is common, and if the event signal received by the LPM is active low, it can be inverted to active high via the CSR.

[0023] The trigger logic 204 can include a sequence of operators, such as AND operators, OR operators, etc., interconnected to perform a sequence of logic operations on the plurality of event signals 202 and generate one or more trigger signals 206. In some implementations, the last operator of the sequence of operators can include an "AND or OR selection" operator that determines the trigger signal 206. For example, if one or more events request a higher power state, it is desirable to generate a trigger signal for the higher power state by using an OR selection. As another example, if none of the events request a higher power state, it is desirable to generate a trigger signal for the lower power state by using an AND selection.

[0024] The trigger logic 204 can be configured to generate a flexible number of trigger signals 206 depending on the number of trigger signals defined in the power state table 208. For example, the event signals 202 for N events can be used to generate M trigger signals 206.

[0025] The LPM 200 includes one or more power state tables 208 that define power state transitions for a plurality of devices controlled by the LPM 200. Each power state table 208 is configured to store a mapping between the trigger signal 206 and the power state transition. Each power state table 208 defines possible power states and a power state transition from the current state 214 to the next state for the devices managed by the LPM. The current power state 214 can be obtained from the GPIO 216 input by the power sequencer 212.

[0026] For example, as shown in FIG. 1, the power state table A1 (114) defines the power state and power state transitions for device A1 (113). The power state table 208 receives the trigger signal 206 and the current power state 214 as inputs and generates the sequence address 210 as an output. The sequence address 210 is the address of an instruction sequence that can be used by the power sequencer 212 to execute the power state transition corresponding to the received trigger signal 206.

[0027] FIG. 3 is a diagram of an exemplary power state transition diagram 300. The device (e.g., device A1 in FIG. 1) has four power states, namely PS0 (high-speed operation), PS1 (low-speed operation), PS2 (auto Clk gate), and PS3 (auto power gate). The power states PS0 and PS1 are active states that operate at different frequencies. The power states PS2 and PS3 are low-power states. That is, PS0 is the highest power state and PS3 is the lowest power state. There are eight different triggers T0 to T8 that can be activated using an external event via the trigger logic 204. For example, trigger T0 can be generated in response to an idle condition of a predetermined length, and trigger T0 can be used to generate a power state transition from the active power state (PS0) to the low-power state (PS2). In some implementations, the trigger can cause the device to change to a different power state or remain in the same power state.

[0028] Table 1 shows an example of the power state table 208. The power state table 208 represents the power state transition diagram in tabular form. For example, the power state table in Table 1 represents the power state transition diagram shown in FIG. 3. The power state table includes a plurality of rows, and each row corresponds to the current power state. For example, the power state table in Table 1 includes four possible current power states, namely PS0, PS1, PS2, and PS3. The power state table also includes a plurality of triggers that can trigger a power state transition from the current power state to the next power state. The power state table can define a predetermined number of triggers for each power state. For example, the power state table in Table 1 allows a maximum of four triggers for each power state. When the device is currently in state PS0, in response to the trigger signal T0, the power state of the device transitions from PS0 to PS2, and in response to the trigger signal T1, the power state of the device transitions from PS0 to PS1.

[0029]

Table 1

[0030] Referring again to FIG. 2, the LPM200 can include one or more power state tables to control the power states of a plurality of devices that are logically part of the same subsystem. For example, the LPM200 in FIG. 2 can include two power state tables configured to control the power states of two devices. Grouping the power state management of a plurality of devices can reduce the power consumption and area consumption associated with the LPM. Instead of having multiple LPMs, one LPM can better combine common resources such as sharing the same instruction memory, sharing the same data memory, etc.

[0031] The LPM200 includes one or more power sequencers 212. The one or more power sequencers 212 are configured to execute respective instruction sequences when a power state transition is triggered by the trigger logic 204. Each power sequencer corresponds to a respective power state table 208 that defines the power state transitions for a respective device. If there are multiple power state tables 208 in the LPM, the number of power sequencers 212 is the same as the number of power state tables 208. For example, the LPM200 includes two power sequencers 212 and two power state tables 208, and each power sequencer corresponds to a respective power state table.

[0032] The power sequencer 212 defines a plurality of instruction sequences, and each instruction sequence includes custom instructions defined for power state management. That is, each instruction sequence is a computer program that can be executed to perform a power state transition from one power state to the next power state. The instructions in the instruction sequence can include several categories, such as toggling an output, waiting for an input value with a predetermined timeout period, and branching instructions. In some implementations, the instruction sequence can drive and test the GPIO to perform multiple actions such as handshake, protocol, and control.

[0033] The GPIO216 output includes the instruction sequence defined by the sequence address 210 for the power state transition. Each power sequencer 212 controls a respective device via its respective GPIO216. For example, the LPM200 in FIG. 2 includes two power sequencers 212 and two GPIO216s, and each power sequencer can have its own GPIO.

[0034] In some implementations, the instructions can include features for debugging power state transitions, such as single-step debugging, breakpoint debugging, etc. Compared to state machine-based solutions where low-level signals are not available, in power sequencer-based solutions, the signals in the power state transition process can be exposed and accessible by a software program. Different from microcontroller-based solutions that do not have access to low-level signals, the local power manager can have direct access to hardware-level signals for debugging. For example, the current state of the signal can be acquired and used for debugging. In some implementations, an application programming interface (API) for testing and using these signals can be defined. Hardware designers can use the API for debugging. In some implementations, the same API can be defined for multiple LPMs in computing device 100. Hardware designers can use the same API to perform debugging based on signals from different LPMs.

[0035] In some implementations, the LPM can be configured to execute conditional instructions, and the LPM can perform arithmetic operations without using hardware. For example, the LPM can control the movement of data by operating on GPIO inputs and GPIO outputs, achieving real-time response and reducing latency. As another example, the LPM may lack hardware for performing mathematical operations such as addition operations. Thus, the instruction set in the LPM can have a small size, resulting in improved performance.

[0036] The LPM200 can be pre - set with trigger logic 204, a power state table 208, and an instruction sequence defined at design time. In some implementations, these components of the LPM200 can be implemented in the CSR. For example, the trigger logic 204 can be implemented in CSR218, the power state table 208 can be implemented in CSR220, and the power sequencer can include a data memory implemented in CSR224 and an instruction memory implemented in CSR222.

[0037] The greater the number of power states and the number of power state tables, the more complex the power state management of the computing device 100 may become. Therefore, the trigger logic, the power state table, and the instruction sequence need to be updated or modified as needed. One or more of the trigger logic 204, the power state table 208, and the power sequencer 212 (e.g., the instruction sequence) can be modified as needed if an update is required post - silicon (i.e., after the computing device 100 has been manufactured). The trigger logic, the power state table, and the instruction sequence can be reprogrammed independently.

[0038] In some implementations, the LPM can be preconfigured or modified using a toolchain. The toolchain provides an application programming interface (API) to define variables and operations for power management, such as trigger logic, power states, and transitions between power states. The toolchain's API provides a software interface similar to high-level programming languages that use natural language elements (e.g., python®, Java®, C#, etc.). Instead of programming in a low-level programming language (e.g., assembly-level programming that involves manipulating binary values and register locations), hardware designers can conveniently design the LPM and generate updates to the LPM using the API defined by the toolchain. For example, the LPM can be updated using the API to increase the standby time, change the order of the sequence of operations, skip steps in the sequence of steps, etc. The toolchain can convert a software program into binary values representing a new instruction sequence. The binary values can be uploaded and set in the chip so that the LPM can operate on the new instruction sequence.

[0039] In some implementations, updates to these components can be made via CSR programming using the LPM toolchain. Post-silicon updates to the CSR can be implemented by updating the LPM toolchain input and running the toolchain to generate new values for the CSR. The new values for the CSR can be written to the CSR by incorporating the new values in the software that writes to the CSR.

[0040] Figure 4 is a diagram of an exemplary power sequencer 400. The power sequencer 400 receives a sequence address 418 and GPIO inputs 402 as inputs and generates GPIO outputs 406. The power sequencer 400 generates the GPIO outputs 406 based on instructions 424 stored in an instruction memory 412 and data stored in a data memory 410. In some implementations, the power sequencer 400 can generate an idle or break 408 as an output. All inputs and outputs are registered and synchronous with respect to a clock 404.

[0041] The power sequencer 400 can obtain data 422 by accessing the data memory 410 using the sequence address 418. The power sequencer 400 can obtain instructions 424 by accessing the instruction memory 412 using the sequence address 418. Both the data memory 410 and the instruction memory 412 can have zero-cycle latency from the addresses to the data and instructions, and thus, the power sequencer 400 can achieve rapid power state transitions. The power sequencer decodes the instructions 424 obtained from indexing the instruction memory 412 and executes the decoded instructions to perform power state transitions.

[0042] For example, the power sequencer 400 can obtain a set of instructions 424 for a power state transition from PS0 (high-speed operation) to PS1 (low-speed operation) in response to a trigger signal T1 as shown in FIG. 3. Examples of instructions 424 can include the following. q-ch wait_or() if accept wait() halt(PS1) else if deny wait() halt(PS0). In some implementations, when the LPM includes multiple power sequencers, the power sequencers can share common resources such as the data memory 410 and the instruction memory 412. This helps to reduce the area consumption required by the LPM, i.e., the LPM occupies a smaller silicon area. For example, the two power sequencers 400 shown in FIG. 4 can share the same data memory 410 and the same instruction memory 412. This can be useful when two or more devices share the same power state but operate independently. For example, two CPUs can share the same power state and two CPUs can operate independently. Each of the two CPUs can have its own power sequencer, and the two power sequencers can share the same data memory and the same instruction memory.

[0043] When not operating actively, the power sequencer 400 can be in an idle state and wait for a start pulse 416 to start executing the instruction 424. When the power sequencer 400 receives the start pulse 416, the power sequencer 400 can receive the sequence address 418 and start executing the instruction 424. In some implementations, when the power sequencer receives a HALT instruction, the power sequencer enters an idle state and stops executing the instruction.

[0044] The local power manager can define a predetermined number of general inputs and general outputs, i.e., GPIO inputs 402 and GPIO outputs 406. That is, the LPM can define 64 general inputs and 64 general outputs.

[0045] In some implementations, when the LPM includes multiple power sequencers, the power sequencers can execute their respective instructions independently. Each power sequencer can have its own dedicated GPIO inputs 402 and GPIO outputs 406. For example, if there are multiple power sequencers within one LPM, there will be more than 64 general inputs and more than 64 general outputs.

[0046] Command 424 can include a computer program specifically designed for power state management. The LPM can define a predetermined number of instructions, for example, a total of 20 instructions. Command 424 can be specifically designed to perform various operations for controlling the power state of a device, such as putting the power to sleep, turning the power on, turning the power off, clamping the power, toggling one or more outputs (e.g., toggling a GPIO), waiting for one or more inputs (e.g., waiting for an acknowledgement from a clock controller), and taking an action based on an input. In some implementations, Command 424 can be designed to take a branch action depending on the value of an input and the ability to time out if a failure or error condition is met.

[0047] In some implementations, Command 424 can have a variable length. Some instructions can be encoded based on a major opcode, for example, based on the size of an operand, while some instructions can be encoded based on a minor opcode, for example, based on the actual size of the instruction. For example, simple instructions can be encoded based on a 16-bit size, while more complex instructions can be 32 bits in size. In some implementations, Command 424 can include one or more operands representing the value of an event signal 202 received by trigger logic 204. The event signal 202 can include input and output signals that interface with the system and can control the power state transition of the system. For example, an event input signal can trigger the execution of an instruction sequence. The instruction sequence can operate on a set of input or output signals to implement various protocols for controlling the power state transition.

[0048] In some implementations, instruction 424 can provide a debug function for debugging power state transitions. For example, instruction 424 can provide functions such as adding breakpoints and performing single-step debugging.

[0049] LPM200 is programmable and can be updated post-silicon by connecting to a software program through the Advanced Peripheral Bus (APB) port 420. The software program can be generated using APIs defined in the LPM toolchain. The software program can access the CSRs in LPM through the ABP port 420. For example, the software program can access, through the ABP port 420, CSR218 for trigger logic 204, CSR220 for the power state table 208, the CSR for data memory 224, and the CSR for instruction memory 222, and the data stored in these CSRs can be updated or modified by the software program.

[0050] FIG. 5 is a flowchart of an exemplary process for power management using a power sequencer. For convenience, the process is described as being performed by a system that includes one or more local power managers in computing device 100. The system can include the components described with reference to FIG. 1, including one or more devices, one or more power state tables, trigger logic, one or more power sequencers, or any combination thereof.

[0051] The system monitors (510) a trigger signal obtained by a local power manager. The system can monitor the trigger signal at a predetermined interval. For example, the system can enter a main loop that checks the event signal received by the LPM every 5 milliseconds. The system can receive one or more event signals 202, and the system can generate one or more trigger signals 206 using trigger logic 204 in the LPM200.

[0052] The system determines (520) whether the trigger signal is a trigger signal for a power state transition for a device in the system. The system can determine whether the trigger signal is a trigger signal for a power state transition based on the power state table 208 of the device and the current power state 214 of the device. In some implementations, the system can monitor the power state transition needs for a plurality of devices in the computing device 100. The system can determine whether the trigger signal triggers a power state transition for each device based on the respective power state table 208 of each device and the respective current power state 214 of each device. For example, based on the power state table in Table 1, if the current power state of the device is PS0, the system can determine that the trigger signal T1 is a trigger signal for a power state transition from PS0 (high-speed operation) to PS1 (low-speed operation).

[0053] When the system determines that the trigger signal is not a trigger signal for a power state transition, the system continues to monitor future trigger signals obtained by the local power manager (510).

[0054] When the system determines that the trigger signal is a trigger signal for a power state transition, the system executes a command sequence for the power state transition (530). The system can generate a sequence address 210 of the command sequence based on the power state table 208. The system can use a power sequencer to determine a command 424 for the command sequence by indexing the command memory 412 using the sequence address 210. The power sequencer can generate a GPIO output 406 based on the command 424, and the GPIO output 406 can be used to perform a power state transition of the device. In some implementations, the system can include a respective power sequencer and a respective power state table for each of a plurality of devices within the computing device 100. The system can generate a respective GPIO output for each of the plurality of devices.

[0055] Embodiments of the subject matter and the operations and operations described in this specification can be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or one or more combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., as one or more modules of computer program instructions encoded in a tangible non-transitory storage medium for execution by, or to control the operation of, a data processing apparatus. Alternatively or additionally, the program instructions can be encoded in an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal generated to encode information for transmission to a suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or part of, a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or one or more combinations thereof. A computer storage medium is not a propagated signal.

[0056] A computer program, which may also be referred to as or described as a program, software, software application, app, module, software module, engine, script, or code, can be written in any form of programming language, including a compiled or interpreted language, or a declarative or procedural language. A computer program can be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, which may include one or more computers interconnected by one or more data communication networks at one or more locations.

[0057] A computer program may or may not correspond to a file in a file system. A computer program can be stored in a part of a file that holds other programs or data, such as one or more scripts stored in a markup language document, a single file dedicated to the program in question, or multiple coordinated files, such as files that hold one or more modules, subprograms, or portions of code.

[0058] To provide interaction with a user, embodiments of the subject matter described herein can be implemented on or configured to communicate with a computer that has a display device for displaying information to a user, such as an LCD (Liquid Crystal Display) monitor, and an input device by which the user can provide input to the computer, such as a keyboard, and a pointing device, such as a mouse, trackball, or touchpad. Other types of devices can also be used to provide interaction with the user. For example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback. Input from the user can be received in any form, including acoustic, voice, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from the devices used by the user, such as by sending a web page to a web browser on the user's device in response to a request received from the web browser, or by interacting with an app running on a user device, such as a smartphone or electronic tablet. Also, the computer can interact with the user by sending a text message or other form of message to a personal device, such as a smartphone running a messaging application, and conversely receiving a response message from the user.

[0059] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes, for example, backend components as a data server, or includes middleware components, such as an application server, or includes frontend components such as a graphical user interface, a web browser, or a client device having an app through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more backend, middleware, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication, such as by a communication network. Examples of communication networks include local area networks (LANs) and wide area networks (WANs), such as the Internet.

[0060] A computing system can include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data, such as an HTML page, to a user device for the purpose of receiving user input from a user interacting with the device, which acts as a client to display the data. Data generated at the user device, such as the result of user interaction, can be received at the server from the device.

[0061] In addition to the embodiments described above, the following embodiments are also innovative. Embodiment 1 includes a plurality of devices disposed in a plurality of power blocks, each device of the plurality of devices belonging to one of the plurality of power blocks, A computing device that further includes a plurality of local power managers, each local power manager being programmable to execute respective sets of instruction sequences for respective power blocks to cause power state transitions for one or more devices in each power block.

[0062] Embodiment 2 is the computing device of Embodiment 1, wherein each local power manager includes trigger logic configured to receive an event signal input and output a trigger signal, a power state table configured to store a mapping between the trigger signal and the power state transition, and one or more hardware sequencers configured to execute respective instruction sequences when the power state transition is triggered by the trigger logic. and includes.

[0063] Embodiment 3 is the computing device of Embodiment 2, wherein the power state table, the trigger logic, and the instruction sequences are modifiable after the computing device is manufactured.

[0064] Embodiment 4 is the computing device of Embodiment 2, wherein the hardware sequencer includes a breakpoint and a single-step function for debugging.

[0065] Embodiment 5 is the computing device of Embodiment 2, wherein the instruction sequences include instructions having one or more operands representing values of the event signal input received by the trigger logic, and the event signal input controls the power state transition.

[0066] Embodiment 6 is the computing device of Embodiment 1, wherein each local power manager is configured to execute conditional instructions but lacks hardware for performing arithmetic operations.

[0067] Embodiment 7 is a computing device according to Embodiment 1, wherein each local power manager is configured to execute a transition sequence for a plurality of power state tables of a plurality of respective devices.

[0068] Embodiment 8 is a method executed by a computer, including monitoring a trigger signal obtained by a local power manager, a plurality of devices in a computing device are arranged in a plurality of power blocks, each device of the plurality of devices belongs to one of the plurality of power blocks, and each of the plurality of local power managers is programmable to execute a respective set of instruction sequences for a respective power block, the method further includes determining whether a trigger signal for a power state transition has been received, in response to determining that a trigger signal for a power state transition has been received, executing an instruction sequence for a power state transition for one or more devices in each power block, and further includes.

[0069] Embodiment 9 is a method executed by a computer according to Embodiment 8, wherein each local power manager includes trigger logic configured to receive an event signal input and output a trigger signal, a power state table configured to store a mapping between the trigger signal and a power state transition, and one or more hardware sequencers configured to execute a respective instruction sequence when a power state transition is triggered by the trigger logic. and includes.

[0070] Embodiment 10 is a method executed by a computer according to Embodiment 9, wherein the power state table, the trigger logic, and the instruction sequence are modifiable after the computing device is manufactured.

[0071] Embodiment 11 is a method executed by the computer of Embodiment 9, wherein the hardware sequencer includes a single-step function for breakpoints and debugging.

[0072] Embodiment 12 is a method executed by the computer of Embodiment 9, wherein the instruction sequence includes an instruction having one or more operands representing the value of an event signal input received by trigger logic, and the event signal input controls the power state transition.

[0073] Embodiment 13 is a method executed by the computer of Embodiment 8, wherein each local power manager is configured to execute conditional instructions but lacks hardware for performing arithmetic operations.

[0074] Embodiment 14 is a method executed by the computer of Embodiment 8, wherein each local power manager is configured to execute a transition sequence for a plurality of power state tables of a plurality of respective devices.

[0075] Embodiment 15 is one or more non-transitory storage media encoded with instructions that, when executed by one or more local power managers of a computing device disposed in a plurality of power blocks, cause the one or more local power managers to effect power state transitions for a plurality of devices in each respective power block of the computing device, wherein each of the plurality of devices belongs to one of the plurality of power blocks.

[0076] Embodiment 16 is the non-transitory storage media of Embodiment 15, wherein each local power manager trigger logic configured to receive an event signal input and output a trigger signal, and a power state table configured to store a mapping between the trigger signal and the power state transition. One or more hardware sequencers configured to execute respective instructions when a power state transition is triggered by trigger logic including.

[0077] Embodiment 17 is the non-transitory storage medium of Embodiment 16, wherein the power state table, trigger logic, and instructions are modifiable after the computing device is manufactured.

[0078] Embodiment 18 is the non-transitory storage medium of Embodiment 16, wherein the hardware sequencer includes a single-step function for breakpoints and debugging.

[0079] Embodiment 19 is the non-transitory storage medium of Embodiment 16, wherein the instructions include instructions having one or more operands representing the value of an event signal input received by the trigger logic, and the event signal input controls the power state transition.

[0080] Embodiment 20 is the non-transitory storage medium of Embodiment 15, wherein each local power manager is configured to execute conditional instructions but lacks hardware for performing arithmetic operations.

[0081] This specification includes many specific implementation details, but these should not be construed as limitations on the scope of any invention or what is claimed or can be claimed. Rather, they should be construed as descriptions of features that may be specific to particular embodiments of a particular invention. Features described herein in the context of separate embodiments may also be implemented in combination in one embodiment. Conversely, various features described in the context of one embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Further, features may be described above as operating in a certain combination and may even be initially claimed as such, but one or more features from the claimed combination may, in some cases, be excisable from that combination, and the claims may be directed to a sub-combination or variation of a sub-combination.

[0082] Similarly, operations are illustrated and recited in a particular order in the claims, but this should not be understood as requiring that such operations be performed in the particular order shown or sequentially to achieve the desired result, or that all of the illustrated operations be performed. In certain situations, multitasking and parallel processing may be advantageous. Further, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the program components and systems described may generally be integrated into one software product or packaged into multiple software products.

[0083] Specific embodiments of the subject matter are described. Other embodiments are within the scope of the following claims. For example, the acts recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes illustrated in the accompanying figures do not necessarily require the particular order or sequence shown to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous.

Claims

1. including a plurality of devices arranged in a plurality of power blocks, each device of the plurality of devices belongs to one of the plurality of power blocks, further including a plurality of local power managers, each local power manager is programmable to execute a respective set of instruction sequences for the respective power block to cause a power state transition for one or more devices in the respective power block, each local power manager, trigger logic configured to receive an event signal input and output a trigger signal, and one or more hardware sequencers configured to execute the respective instruction sequences when the power state transition is triggered by the trigger logic, a computing device.

2. each local power manager, further including a power state table configured to store a mapping between the trigger signal and the power state transition, the computing device according to claim 1.

3. the power state table, the trigger logic, and the instruction sequences are modifiable after the computing device is manufactured, the computing device according to claim 2.

4. the hardware sequencer includes a breakpoint and a single-step function for debugging, the computing device according to claim 1.

5. the instruction sequence includes instructions having one or more operands representing values of an event signal input received by the trigger logic, the event signal input controlling the power state transition, the computing device according to claim 1.

6. each local power manager is configured to execute conditional instructions but lacks hardware for performing arithmetic operations, the computing device according to claim 1.

7. each local power manager is configured to execute a transition sequence for a plurality of power state tables of a plurality of respective devices, the computing device according to claim 1.

8. a method executed by a computer, comprising monitoring a trigger signal obtained by one of a plurality of local power managers, Multiple devices in a computing device are arranged in a plurality of power blocks, each device of the plurality of devices belongs to one of the plurality of power blocks, and each of the plurality of local power managers is programmable to execute a respective set of instruction sequences for a respective power block. The method determining whether a trigger signal for a power state transition has been received; in response to determining that the trigger signal for the power state transition has been received, executing an instruction sequence for the power state transition for one or more devices in each of the power blocks; further comprising each local power manager includes trigger logic configured to receive an event signal input and output a trigger signal; and one or more hardware sequencers configured to execute respective instruction sequences when a power state transition is triggered by the trigger logic. A method executed by a computer.

9. Each local power manager The method executed by a computer according to claim 8, further comprising a power state table configured to store a mapping between the trigger signal and the power state transition.

10. The method executed by a computer according to claim 9, wherein the power state table, the trigger logic, and the instruction sequence are modifiable after the computing device is manufactured.

11. The method executed by a computer according to claim 8, wherein the hardware sequencer includes a breakpoint and a single-step function for debugging.

12. The method executed by a computer according to claim 8, wherein the instruction sequence includes an instruction having one or more operands representing a value of an event signal input received by the trigger logic, and the event signal input controls the power state transition.

13. The method executed by a computer according to claim 8, wherein each local power manager is configured to execute conditional instructions but lacks hardware for performing arithmetic operations.

14. The method executed by a computer according to claim 8, wherein each local power manager is configured to execute a transition sequence for a plurality of power state tables of a plurality of respective devices. **Claim 15** A program for causing one or more processors of a computing device arranged in a plurality of power blocks to execute the method according to any one of claims 8 to 14.

Images