PATENT DOCUMENT

Publication Number: US-9928115-B2
Application Number: US-201514844212-A
Country: US
Kind Code: B2

Title: Hardware migration between dissimilar cores

Abstract:
In an embodiment, an integrated circuit may include one or more processors. Each processor may include multiple processor cores, and each core has a different design/implementation and performance level. The processor may support multiple processor states (PStates). Each PState may specify an operating point (e.g. a combination of supply voltage magnitude and clock frequency), and each PState may be mapped to one of the processor cores. During operation, one of the cores is active: the core to which the current PState is mapped. If a new PState is selected and is mapped to a different core, the processor may automatically context switch the processor state to the newly-selected core and may begin execution on that core. The context switch may be performed using a special purpose register (SPR) interconnect. Each processor core in a given processor may be coupled to the SPR interconnect to permit access to the external SPRs.

Claims:
What is claimed is: 
     
       1. An apparatus comprising:
 a processor having a plurality of power states comprising:
 a first processor core, wherein a first subset of the plurality of power states map to the first processor core; and 
 a second processor core, wherein a second subset of the plurality of power states map to the second processor core, and wherein the first subset and the second subset are non-overlapping; 
 
 a special purpose register interconnect coupled to the first processor core and the second processor core, the special purpose register interconnect providing access to a plurality of special purpose registers; and 
 a control circuit configured to control migration of processor state between the first processor core and the second processor core responsive to a change between a first processor state in the first subset and a second processor state in the second subset, wherein the control circuit is configured to cause transfer of register state, including a general purpose register state, from a source core of the first processor core and the second processor core to a target core of the first processor core and the second processor core over the special purpose register interconnect, and wherein, during a second time period prior to a first time period in which the transfer of register state is occurring, the source core is configured to access a first special purpose register on the special purpose register interconnect responsive to executing a first special purpose register instruction that specifies the first special purpose register. 
 
     
     
       2. The apparatus as recited in  claim 1 , wherein the special purpose interconnect is a ring interconnect coupling the first processor core, the second processor core, and one or more additional circuits that includes special purpose registers. 
     
     
       3. The apparatus as recited in  claim 1 , wherein the control circuit is configured to detect a plurality of write operations to a predetermined special purpose register address as a migration of register state and to route write data associated with the plurality of write operations for the source core to the target core over the special purpose register interconnect. 
     
     
       4. The apparatus as recited in  claim 3 , wherein the control circuit is configured to transmit instructions to the source core to write general purpose registers of the source core to the predetermined special purpose register address. 
     
     
       5. The apparatus as recited in  claim 4 , wherein the control circuit is configured to transmit instructions to the target core to read general purpose registers from the predetermined special purpose register address, wherein an order of the general purpose registers read by the target core is the same as an order of the general purpose registers written by the source core. 
     
     
       6. The apparatus as recited in  claim 4 , wherein the control circuit is configured to transfer special purpose register contents from the source core to the target core. 
     
     
       7. The apparatus as recited in  claim 6 , wherein the control circuit is configured to transmit read operations to read the special purpose registers in the source core, and wherein read responses from the source core are modified into write responses to the target core, the write responses including the special purpose register contents. 
     
     
       8. The apparatus as recited in  claim 6 , wherein a subset of the special purpose registers within the source core, excluding at least one special purpose register within the source core, is transferred to the target core. 
     
     
       9. The apparatus as recited in  claim 1 , wherein, subsequent to the transfer of the register state from the source core to the target core, the control circuit is configured to ensure that other processor state is retained. 
     
     
       10. The apparatus as recited in  claim 9 , wherein the other processor state comprises a wait for event state. 
     
     
       11. The apparatus as recited in  claim 9 , wherein the other processor state comprises debug state. 
     
     
       12. The apparatus as recited in  claim 9 , wherein the other processor state includes interrupt state. 
     
     
       13. The apparatus as recited in  claim 1 , wherein the first processor core has a first plurality of efficiency/performance characteristics that differ from a second plurality of efficiency/performance characteristics of the second processor core. 
     
     
       14. A method comprising:
 detecting a change from a first power state mapped to a first processor core of a processor to a second power state mapped to a second processor core of the processor; 
 transferring register state, including a general purpose register state, from the first processor core to the second processor core responsive to detecting the change, the transferring performed during a first time period over a special purpose register interconnect; and 
 during a second time period prior to the first time period, the first processor core executing a first special purpose register instruction and accessing a first special purpose register specified by the first special purpose register instruction on the special purpose register interconnect. 
 
     
     
       15. The method as recited in  claim 14 , wherein transferring the register state comprises:
 injecting a plurality of instructions into the first processor core to write a plurality of registers to a predetermined special purpose register address; 
 injecting a second plurality of instructions into the second processor core to read a second plurality of registers from the predetermined special purpose register address in a same order as the registers are written by the first processor core; and 
 routing data written to the predetermined special purpose address over the special purpose register interconnect to the second processor core. 
 
     
     
       16. A method comprising:
 detecting a change from a first power state mapped to a first processor core of a processor to a second power state mapped to a second processor core of the processor; 
 transferring register state from the first processor core to the second processor core responsive to detecting the change, the transferring performed over a special purpose register interconnect that is used by the first and second processor cores to access special purpose registers; 
 transmitting read operations to the first processor core to read special purpose registers; 
 converting read responses generated for the special purpose register reads into write responses; and 
 routing the write responses to the second processor core. 
 
     
     
       17. The method as recited in  claim 16  wherein transferring the register state comprises:
 injecting instructions into the first processor core to write registers to a predetermined special purpose register address; 
 injecting instructions into the second processor core to read registers from the predetermined special purpose register address in a same order as the registers are written by the first processor core; and 
 routing data written to the predetermined special purpose address over the special purpose register interconnect to the second processor core. 
 
     
     
       18. The method as recited in  claim 16 , further comprising ensuring that a wait for event state from the first processor core is retained in the second processor core. 
     
     
       19. The method as recited in  claim 16 , further comprising ensuring that interrupt state from the first processor core is retained in the second processor core. 
     
     
       20. The method as recited in  claim 16 , further comprising ensuring that debug state from the first processor core is retained in the second processor core.

Description:
BACKGROUND 
     Technical Field 
     Embodiments described herein are related to processors and, more particularly, to multiple processor cores forming a processor. 
     Description of the Related Art 
     Various processors are included in electronic systems to execute software providing some amount of user functionality. The processors may include the central processing units (CPUs) in the system, as well as special purpose processors dedicated to specific tasks such as graphics, media processing, etc. Generally, the processors are designed to operate at multiple operating points (settings of supply voltage magnitude and clock frequency). Lower operating points consume less power but also offer limited performance compared to higher operating points. For some workloads, the limited performance is sufficient and the lower operating points can be used. For other workloads, the higher operating points are needed to provide sufficient performance. 
     In some systems, a wide diversity of workloads are experienced. Designing a processor that can provide the performance needed by the most demanding workloads while also supporting the lowest possible operating point that would provide sufficient performance for many frequently-executed workloads has become a challenge. Processors that operate at high operating points may only support a reduction in supply voltage to a certain level before circuitry ceases to function correctly. Compromises must be made, and typically the lowest operating point is increased until the design can meet the desired high end operating point. As the high end operating points continue to increase, more and more workloads are executable at the lowest operating point (and many could be executed at even lower operating points). Power is expended unnecessarily for such workloads, which can be a critical factor in mobile systems that frequently operate on a limited energy source such as a battery. 
     SUMMARY 
     In an embodiment, an integrated circuit may include one or more processors. Each processor may include multiple processor cores, and each core has a different design/implementation and performance level. For example, a core may be implemented for high performance, but may have higher minimum voltage at which it operates correctly. Another core may be implemented at a lower maximum performance, but may be optimized for efficiency and may operate correctly at a lower minimum voltage. The processor may support multiple processor states (PStates). Each PState may specify an operating point (e.g. a combination of supply voltage magnitude and clock frequency), and each PState may be mapped to one of the processor cores. During operation, one of the cores is active: the core to which the current PState is mapped. If a new PState is selected and is mapped to a different core, the processor may automatically context switch the processor state to the newly-selected core and may begin execution on that core. 
     In an embodiment, the context switch may be performed using a special purpose register (SPR) interconnect. The SPR interconnect may be used in normal operating mode to provide access to SPRs that are external to the processor. For example, in an embodiment, one or more processors may be coupled to a level 2 (L2) cache which may have SPRs. There may be a processor power controller external to the processors, and the processor power controller may have SPRs. Each processor core in a given processor may be coupled to the SPR interconnect to permit access to the external SPRs. This interconnect may be used to perform the context switch. In an embodiment, minimal additional hardware may be required to provide the context switch functionality. For example, no additional buffering beyond that included in the SPR interconnect for normal functionality may be required. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The following detailed description makes reference to the accompanying drawings, which are now briefly described. 
         FIG. 1  is a block diagram of one embodiment of a processor cluster. 
         FIG. 2  is a graph illustrating efficiency versus performance for a PCore and an ECore as illustrated in  FIG. 1  for one embodiment. 
         FIG. 3  is a block diagram of one embodiment of a processor cluster shown in greater detail. 
         FIG. 4  is a block diagram of a portion of the embodiment of  FIG. 3  illustrating instruction injection into the processor cores to transfer general purpose register (GPR) state. 
         FIG. 5  is a block diagram of a portion of the embodiment of  FIG. 3  illustrating special purpose register (SPR) transfer. 
         FIG. 6  is a flowchart illustrating operation of one embodiment of a migration control circuit to change processor states. 
         FIG. 7  is a flowchart illustrating operation of one embodiment of the migration control circuit to swap cores. 
         FIG. 8  is a flowchart illustrating operation of one embodiment of the migration control circuit to transfer context between cores. 
         FIG. 9  is a block diagram of one embodiment of a system on a chip (SOC) including one embodiment of the processor cluster shown in  FIG. 1 . 
         FIG. 10  is a block diagram of one embodiment of a system. 
     
    
    
     While embodiments described in this disclosure may be susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including, but not limited to. 
     Various units, circuits, or other components may be described as “configured to” perform a task or tasks. In such contexts, “configured to” is a broad recitation of structure generally meaning “having circuitry that” performs the task or tasks during operation. As such, the unit/circuit/component can be configured to perform the task even when the unit/circuit/component is not currently on. In general, the circuitry that forms the structure corresponding to “configured to” may include hardware circuits and/or memory storing program instructions executable to implement the operation. The memory can include volatile memory such as static or dynamic random access memory and/or nonvolatile memory such as optical or magnetic disk storage, flash memory, programmable read-only memories, etc. The hardware circuits may include any combination of combinatorial logic circuitry, clocked storage devices such as flops, registers, latches, etc., finite state machines, memory such as static random access memory or embedded dynamic random access memory, custom designed circuitry, programmable logic arrays, etc. Similarly, various units/circuits/components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to.” Reciting a unit/circuit/component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) interpretation for that unit/circuit/component. 
     In an embodiment, hardware circuits in accordance with this disclosure may be implemented by coding the description of the circuit in a hardware description language (HDL) such as Verilog or VHDL. The HDL description may be synthesized against a library of cells designed for a given integrated circuit fabrication technology, and may be modified for timing, power, and other reasons to result in a final design database that may be transmitted to a foundry to generate masks and ultimately produce the integrated circuit. Some hardware circuits or portions thereof may also be custom-designed in a schematic editor and captured into the integrated circuit design along with synthesized circuitry. The integrated circuits may include transistors and may further include other circuit elements (e.g. passive elements such as capacitors, resistors, inductors, etc.) and interconnect between the transistors and circuit elements. Some embodiments may implement multiple integrated circuits coupled together to implement the hardware circuits, and/or discrete elements may be used in some embodiments. 
     This specification includes references to “one embodiment” or “an embodiment.” The appearances of the phrases “in one embodiment” or “in an embodiment” do not necessarily refer to the same embodiment, although embodiments that include any combination of the features are generally contemplated, unless expressly disclaimed herein. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure. 
     DETAILED DESCRIPTION OF EMBODIMENTS 
     Processor Overview 
       FIG. 1  is a block diagram of one embodiment of a processor cluster  30 . In the illustrated embodiment, multiple processors  32 A- 32   n  and a shared cache  34  are included. The processors  32 A- 32   n  are coupled to the shared cache  34 , which is further coupled to communicate with other elements of a system that includes the cluster  30 . In the illustrated embodiment, the shared cache  34  includes a processor power manager  36  that includes a PState register  38  storing a PState for the processors  32 A- 32   n . Each processor  32 A- 32   n  may have its own independent PState, groups of processors  32 A- 32   n  may share a PState, or the cluster  30  may have a shared PState for the processors  32 A- 32   n , in various embodiments. Processor  32 A is shown in more detail in  FIG. 1  to include at least two processor cores, a performance core (PCore)  40  and an efficient core (ECore)  42 . Other embodiments may include additional cores. Each core  40  and  42  is coupled to a power supply rail (V P ) through respective power switches  44  and  46 . Thus, each core  40  and  42  may be independently powered up or down. Other processors, such as processors  32 B (not shown) through  32   n , may be similar to the processor  32 A. 
     Each processor  32 A- 32   n  may be an entity to which software executing in the system may assign code to execute. For example, the software may be part of an operating system (OS) that controls the hardware in the system. The software may be a thread or task scheduler which schedules code to be executed. The OS may also assign a PState to the processors  32 A- 32   n , based on the performance demands of the code being executed. The OS may track the behavior of the code to determine PStates, may statically record information for each thread/task to select a PState, etc., or any combination thereof. In addition or alternatively, the PState may be affected by other conditions in the system (thermal limits, battery power available, etc.). 
     Each possible PState may specify an operating point for a processor  32 A- 32   n . For example, the operating point may include a supply voltage magnitude for V P  and a clock frequency for the clocks in the processor  32 A- 32   n . Other embodiments may define the operating point in other fashions, but generally the operating point may indicate the performance and power consumption of the processor. In an embodiment, the PState may be a pair of values that are directly used as the supply voltage magnitude and the clock frequency. In other embodiments, the PState may be a value that is used to obtain the supply voltage magnitude and the clock frequency (e.g. an index into a table of values). 
     As illustrated in  FIG. 1 , the processor  32 A includes the PCore  40  and the ECore  42 . Each PState that is supported by the processor  32 A is mapped to one of the cores  40  and  42 . Each core  40  and  42  may have more than one PState mapped to it. 
     As the code being executed by a processor  32 A- 32   n  changes and/or other system considerations warrant a change in the PState, the PState register  38  may be updated (e.g. by the OS). If the PState is changed from a current PState that is mapped to one of the cores  40  and  42  (the “active core” or the “source core”) to a new PState that is mapped to another one of the cores  40  and  42  (the “target core”), the cluster  30  may automatically, in hardware, transfer the processor context of the processor  32 A from the active core to the target core. The processor context may include general purpose register (GPR) state and/or special purpose register (SPR) state (collectively “register state”). The general purpose registers may be registers that may be specified as operands of arithmetic/logic instructions, load/store instructions, branch instructions, etc. defined in the instruction set architecture (ISA) implemented by the processor  32 A- 32   n . The general purpose registers may include various operand types such as integer, floating point, vector, etc. Special purpose registers may include various registers storing mode controls for the processor  32 A- 32   n , enabling and disabling various programmable features and features that may be optional and/or in addition to ISA-required features, etc. Special purpose registers may generally be read by a specific SPR read instruction and written by a specific SPR write instruction defined in the ISA, and may generally not be specified as operands of other instructions. 
     The target core may be powered off at the time the PState is changed. The process of transferring the context may include powering on the target core, resetting and initializing the target core, transferring the processor context, and powering off the active core (making the target core the active core). Execution may continue on the target core (now active core). Accordingly, switching between cores may be invisible to software. In fact, software may not even be “aware” that there are multiple cores in the processor  32 A- 32   n.    
     In an embodiment, the cores  40  and  42  may have different implementations, but may provide precisely the same program behavior in response to any given instruction stream, including privileged instructions. For example, some instruction set architectures may include features that would uniquely identify a processor in a system. For example, instruction set architectures often have a “CPU ID” instruction that returns a value assigned to the CPU in the system. Each CPU in the system is assigned a unique value. Both cores  40  and  42  may return the same CPU ID value. Another form of the CPU ID instruction may return a value indicating which optional features of the instruction set architecture are implemented by the processor. Both cores  40  and  42  may return the same value for that instruction as well. Various model-specific registers within the SPRs may vary from implementation to implementation. The model-specific register implementation of the cores  40  and  42  may be the same. Thus, the software that executes on the processors  32 A- 32   n , including the operating system software, application software, etc., may operate identically independent of which core  40  or  42  is active. 
     In another embodiment, there may be some differences between the cores  40  and  42 . For example, certain ISA features may be implemented by only one of the cores  40  and  42 . If the active core does not implement an ISA feature that is used in currently-executing code, a context transfer to a target core that does implement the ISA feature may be performed. Alternatively, an exception may be signaled and the operating system may activate the correct core or may terminate the code that was being executed. If an exception is used, then the lack of “awareness” of software to the existence of the cores  40  and  42  may be lost. 
     The PCore  40  and the ECore  42  may be different designs, different implementations of an instruction set architecture (ISA) employed by the processors  32 A- 32   n . Viewed in another way, the PCore  40  and the ECore  42  may implement different microarchitectures. The PCore  40  may be an aggressive design that attempts to maximize performance with power conservation as a less-emphasized design goal. The circuitry in the PCore  40  may be aggressive, which may prevent the minimum supply voltage at which the PCore  40  may operate from being as low as may be desired in some of the PStates. On the other hand, the ECore  42  may implement a more conservative design, and thus may operate correctly at lower minimum voltages than the PCore  40 . The performance of the ECore  42  may be lower than the PCore  40  at a given operating point, and power conservation may be a more highly-emphasized goal for the ECore  42 . The semiconductor area occupied by the ECore  42  may be less than that of the PCore  40  as well. 
     While the example illustrated in  FIG. 1  includes two cores in the processor  32 A, other embodiments may include more than two cores. One core may be the most efficient core operating at the lowest PStates, and other cores may be optimized for other points along the performance/efficiency spectrum until yet another core is the highest performance core of the multiple cores in the processor. Any number of cores may be used in various embodiments. 
     Generally, a processor may be any circuitry configured to implement the ISA. Various ISAs exist and may be used in various embodiments, such as the x86 architecture (also known as APX), the ARM architecture, the MIPS architecture, PowerPC (now simply Power), etc. A variety of microarchitectural techniques may be employed by the processor, including the multiple core approach described above. Each core may implement various microarchitectural techniques as well. Generally, the microarchitecture may refer to the organization of execution units and other circuitry that is used to implement the ISA. Examples may include in-order versus out-of-order execution, speculative execution, branch prediction, superscalar, superpipelined, etc. Embodiments may implement microcoding techniques in addition to various other techniques. 
     The processors  32 A- 32   n  and/or the processor cluster  30  may be used as any processors in a system. For example, the processors may be central processing units (CPU) that execute the OS to control other hardware in the system and schedule application code to be executed. The CPU may execute the application code as well, etc. The processors may be special purpose processors such as graphics processing units (GPU) optimized for graphics manipulations, digital signal processors (DSPs) optimized for signal processing, embedded processors performing software execution in various peripheral components, etc. 
     In an embodiment, at most one of the cores  40  and  42  forming a processor  32 A- 32   n  may be powered on during execution, except for times when the processor context is being transferred. A given processor  32 A- 32   n  may be completely off (all cores powered down). The processor power manager  36  may be configured to control the powering on/up of the processor cores and powering off/down of the processor cores using the power switches  44  and  46 . 
     In some embodiments, the cores  40  and/or  42  may implement data caches that may store modified data (i.e. data that has been written in the cache, e.g. responsive to stores in the processor code being executed, but that has not been written to memory yet such that the data in memory is no longer the correct data). In addition to transferring processor context, the modified data may be flushed from the data cache. Particularly, the data may be flushed to the shared cache  34 , but may remain stored in the shared cache  34  unless normal operation of the shared cache  34  causes the data to be evicted. Once the newly-active core is executing, modified data may be a hit in the shared cache  34  and may be moved into the newly-active core&#39;s cache with relatively low latency. In other embodiments, there may not be a shared cache and the flushed data may be written to main memory and read from main memory by the newly-active core as needed. 
     The processor power manager  36  may be configured to manage PState transitions within the processor cluster  30 . The processor power manager  36  may be configured to communicate supply voltage magnitude transitions to a system level power manager or directly to a power management unit (PMU) that supplies the voltages to the system. The processor power manager  36  may be configured to interact with the clock generation hardware (not shown in  FIG. 1 ) such as a phase lock loop (PLL) or the like. 
     The shared cache  34  may have any capacity and configuration. The shared cache  34  may be inclusive of caches in the processors  32 A- 32   n , exclusive of the caches, or non-inclusive. 
       FIG. 2  is a graph illustrating efficiency versus power for one embodiment of the cores  40  and  42 . The dotted curve corresponds to the ECore  42  and the solid line corresponds to the PCore  40 . Efficiency is graphed on the vertical axis and power on the horizontal axis. Efficiency may be measured in a variety of ways (e.g. performance/watt). The performance portion of the efficiency measurement may be measured using various benchmark programs such as Specint, SpecFlt, Dhrystone, etc. Various PStates for the processor  32 A are illustrated along the curves in  FIG. 2 . PStates that corresponding to higher performance are on the PCore curve, since the PCore is optimized for performance, wherein the PStates corresponding to lower performance/higher energy conservation are on the ECore curve, which is more efficient at lower performance levels but less performant at higher performance levels. 
     Accordingly, in the example of  FIG. 2 , the PStates  1 ,  2 , and  3  are mapped to the ECore  42  and the PStates  4 ,  5 ,  6 , and  7  are mapped to the PCore  40 . Any number of PStates may be supported and any number may be mapped to various cores. In another embodiment, continuous PState settings may be supported. In such an embodiment, a break over point where the curves intersect in  FIG. 2  may be defined at which a core swap may occur. In general, each core may have a subset of the PStates mapped to that core, and the subsets may be non-overlapping. 
       FIG. 3  is a block diagram illustrating the cluster  30  in greater detail for one embodiment. In the illustrated embodiment, each of the PCore  40  and the ECore  42  are illustrated as including various circuits such as an execution units (EXUs)  50 A- 50 B, load/store units (LSUs)  52 A- 52 B, memory management units  54 A- 54 B, and other blocks  56 A- 56 B. The EXU  50 A, the LSU  52 A, the MMU  54 A, and the other blocks  56 A maybe coupled to an SPR interconnect  66 A indicated by the arrows between units  50 A- 56 A in  FIG. 3  along with a control circuit  58 A. In the illustrated embodiment, a ring interconnect is used (or a daisy chain) to pass SPR read/write operations around to the units  50 A- 56 A. Other embodiments may use any interconnect. Generally, the SPR interconnect may be dedicated to SPR communication. Other interconnection among the units  50 A- 56 A may be provided for normal operation (i.e. ISA instruction execution). Such interconnection is not shown in  FIG. 3 . Similarly, the units  50 B- 56 B may be coupled in an SPR interconnect (ring)  66 B with control circuit  58 B. The SPR ring within each core  40  or  42  may be referred to as a local SPR ring within the core. The control circuits  58 A- 58 B may also be coupled to a global SPR ring  66 C via SPR routers  60 A- 60 B in  FIG. 3 , respectively. Other SPR routers  60 C- 60 D may be coupled to the global SPR ring to couple other cores (e.g. cores within the processor  32   n  in  FIG. 1 ). Additionally, components within the shared cache  34  such as an shared cache control circuit  62  and the processor power manager  36  may be coupled to the global SPR ring. The general purpose registers for each core are illustrated as registers  64 A- 64 B, coupled to units that execute instruction operations in the cores  40  and  42 , respectively (e.g. the EXUs  50 A- 50 B, the LSUs  52 A- 52 B, and possibly one or more of the other blocks  56 A- 56 B). 
     Various units in the cores  40  and  42  and the shared cache  32  may include one or more SPRs that control operation of the units. For example, SPRs  68 A are shown in EXU  50 A and SPRs  68 B are shown in MMU  54 A. Similarly, SPRs  68 F are shown in EXU  50 B and SPRs  68 E are shown in MMU  54 B. Other SPRs in the cores  40 - 42  are not explicitly numbered to maintain simplicity in the drawings. The processor power manager  36  and the shared cache control circuit  62  may also include SPRs  68 C- 68 D, accessible by SPR read/write instructions executed by a core  40  or  42  via communication over the local and global SPR rings. Generally, the SPRs in the cluster  30  may be accessible via SPR addresses generated during execution of the SPR read/write instructions. The addresses may be register numbers, similar to the manner in which GPRs are addressed. Alternatively, a larger address space may be assigned to SPRs and the SPR addresses may be allocated in the space as desired. There may be “holes” in the space which do not map to SPRs. 
     An EXU  50 A- 50 B may be configured to execute an SPR read/write operation. The EXU  50 A- 50 B may issue an SPR command on the SPR ring  66 A- 66 B in response to the SPR read/write operation. The SPR command may include the SPR address. Each circuit on the SPR ring  66 A- 66 B may decode the SPR address to determine if the command is targeted at an SPR in the circuit. If an SPR in the circuit is targeted, the circuit may transmit a response in place of the SPR command on the SPR ring  66 A- 66 B. If no SPR in the circuit is targeted, the circuit may forward the SPR command on the SPR ring  66 A- 66 B. The ring control circuits  58 A- 58 B may decode the SPR address to detect SPRs that are external to the cores  40 - 42 , and may forward SPR commands to the SPR ring  66 C when external SPRs are addressed. The SPR routers  60 A- 60 D may detect SPR responses that address SPRs in the cores  40 - 42 , and may route the responses to the ring control circuits  58 A- 58 B in response. 
     The SPRs  68 C- 68 D may be shared among the cores  40  and  42  (i.e. an access to one of the SPRs  68 C- 68 D by either core may result in access to the SPR  68 C- 68 D over the global SPR ring  66 C). However, SPRs in the cores  40  and  42  may need to be migrated from one core to the other as part of a context transfer. Similarly, the registers  64 A- 64 B may need to be migrated from one core to another as part of the context transfer. The SPR interconnect  66 A- 66 C may be used to perform the transfer. More particularly, when a new PState is written to the PState register  38 , a migration control circuit  70  may cause the transfer of GPR state and SPR state from the active core  40  or  42  (the source core for the transfer) and the target core  42  or  40  over the SPR interconnect. 
     In an embodiment, an SPR address that is otherwise not in use may be defined as a “virtual SPR.” The SPR may be a target for writes of each GPR from the source core, causing the register data to be transferred onto the SPR interconnect. The ring control circuits  58 A- 58 B may detect the virtual SPR address as an external address and may route the writes out to the global SPR ring  66 C, so that the register data may be transmitted to the target core. The SPR routers  60 A- 60 D may detect the virtual SPR address and may route the data to the target core as a read response, which may provide the data to the SPR read instructions previously injected into the target core and thus result in the data being written to the register in the target core. 
     In addition to transferring the GPR register state, at least some of the SPR state from the source core may be transferred to the target core. All of the SPR state may be transferred, or a subset of the SPR state that excludes one or more SPRs may be transferred. In an embodiment, SPRs may be identified during the design phase as SPRs to be transferred or not transferred using a “migrate” flag for each SPR. The migration control circuit  70  may be configured to transfer those SPRs indicated by the migrate flag. Alternatively, the subset of SPRs to be transferred may be programmable in the migration control circuit  70 . The SPR state may be transferred, in an embodiment, via external SPR read requests transmitted by the SPR router  60 A- 60 B coupled to the source core to read the SPRs from the source core. The corresponding read responses from the source core may be converted into write responses targeted at the target core, updating the SPRs in the target core with the data from the SPRs in the source core. The migration control circuit  70  may be coupled to the SPR routers  60 A- 60 B and may transmit the SPR read requests to the SPR router  60 A- 60 B associated with the source core. The order of the SPR read requests may be the order of the desired migration. The receiving SPR router  60 A- 60 B may transmit the read requests to the source core, and may capture the corresponding read responses. The receiving SPR router  60 A- 60 B may convert the captured read responses to write responses and transmit them to the SPR router  60 A- 60 B associated with the target core, which may transmit the write responses to the target core. 
     The migration control circuit  70  may thus cause a stream of GPR states and SPR states to be transmitted over the SPR interconnect from the source core to the target core. The transfer may make use of the existing SPR interconnect mechanisms, which may limit the amount of additional hardware circuitry employed to make the transfer. For example, even though the cores  40  and  42  may be asynchronous, no additional buffering other than that already included in the SPR interconnect for SPR access may be required. The stream of register data may be transmitted in a particular order, and the register data may be received in the target core in the same order. For example, in an embodiment, the migration control circuit  70  may be configured to transmit migration instructions to the cores  40  and  42  to cause the migration. The source core may receive source instructions which write the GPRs to the virtual SPR address in a particular order, and the target core may receive target instructions which ready the virtual SPR into the GPRs in the same particular order. 
     In an embodiment, additional interconnect may be provided between the SPR routers  60 A- 60 B to facilitate context transfer (e.g. buses  72  illustrated in  FIG. 3 ). The buses  72  may improve performance of the context transfer, for example in cases in which multiple PCores and ECores are included in a cluster and migration may occur in parallel between different PCores and corresponding ECores. In an embodiment, the buses  72  may also permit the global SPR ring  66 C to be available for external SPR commands to monitor and/or control migration. Additionally, the buses  72  may permit context transfer from the ECore  42  as the source core to the PCore  40  as the target core to proceed over the buses  72  rather than around the global SPR ring  66 C through the cache control circuit  62 , the processor power manager  36 , etc., which may reduce latency. Additional interconnect (not shown in  FIG. 3 ) may also be provided between other SPR routers that are coupled to PCore/ECore pairs (e.g. the SPR routers  60 C- 60 D) to facilitate context transfers in a similar fashion. 
     The various circuit blocks included in the cores  40  and  42 , when taken together, may implement the execution of instructions from the ISA. Any set of circuit blocks may be included, and any number of a given block may be included in a core, in various embodiments. The EXUs  50 A- 50 B may include circuitry to execute various arithmetic/logic operations, for example. There may be different EXUs for different operand types, and there may be different numbers of EXUs for different operand types (e.g. integer, floating point, vector, etc.). The LSU  52 A- 52 B may include circuitry to execute load and store operations, interfacing with cache/memory, enforcing ordering rules, etc. In embodiments that implement address translation, the MMUs  54 A- 54 B may include circuitry to manage the virtual to physical address translations, such as translation lookaside buffers (TLBs), table walk circuitry, etc. The other blocks  56 A- 56 B may implement any other microarchitectural features (e.g. caches, fetch control circuitry, branch prediction circuitry, decoders, etc.). 
     In some embodiments, a given instruction may be decoded into one or more instruction operations, depending on the complexity of the instruction. Particularly complex instructions may be microcoded, in some embodiments. In such embodiments, the microcode routine for the instruction may be coded in instruction operations. In other embodiments, each instruction in the instruction set architecture implemented by the processor  10  may be decoded into a single instruction operation, and thus the instruction operation may be essentially synonymous with instruction (although it may be modified in form by the decoder). The term “instruction operation” may be more briefly referred to herein as “op.” Thus, the EXUs  50 A- 50 B, the LSUs  52 A- 52 B, and various other hardware in the cores  40  and  42  may be configured to execute instruction operations that are derived from the instructions fetched by the cores  40  and  42  (or inserted by the migration control circuit  70 ). 
     The ring control circuits  58 A- 58 B may be configured to manage data flow around the local SPR rings  66 A- 66 B and interfacing with the global SPR ring  66 C via the SPR routers  60 A- 60 B. The ring control circuits  58 A- 58 B may, for example, detect SPR read/write operation on the local SPR ring  66 A- 66 C that access SPRs on the global SPR ring  66 C, and may transmit such operations to the SPR routers  60 A- 60 B. The ring control circuits  58 A- 58 B may also receive SPR read/write operations and responses from the SPR routers  60 A- 60 B and may route such operations to the target SPRs on the local SPR ring  66 A- 66 B. The ring control circuits  58 A- 58 B may also be configured to detect the virtual SPR address for register state transmission and may route the corresponding operations on to the global SPR ring  66 C. 
     The SPR routers  60 A- 60 D, along with the shared cache control circuit  62  and the processor power manager  36 , may form the global SPR ring  66 C. As mentioned above, the SPR routers  60 A- 60 D may be configured to capture SPR operations from the global SPR ring  66 C for routing locally in a core, and may insert operations provided from a core onto the global SPR ring  66 C. The shared cache control circuit  62  may generally include the circuitry for caching data in the shared cache  34 . 
       FIG. 4  is a block diagram illustrating a source core  40  or  42 , a target core  42  or  40 , and the SPR routers  60 A- 60 B performing a transfer of register state for one embodiment. In the illustrated embodiment, instruction sequences for both the source core and the target core provided by the migration control circuit  70  is shown. The instructions may be provided in any fashion. For example, the cores may be triggered to fetch from a given address to which the migration control circuit  70  may respond with the instructions. Alternatively, the migration control circuit  70  may be configured to inject the instructions into the core&#39;s pipelines (e.g. at the output of the instruction cache, at a decode stage, directly into execution units, etc.). 
       FIG. 4  is an example of instruction injection into the cores  40  and  42  to transfer register state. In the illustrated embodiment, the source core&#39;s code sequence includes an SPR write instruction (WrSpr) to the virtual SPR address (V_Spr) for each general purpose register in the core (e.g. R 0 , R 1 , etc.). Since the writes are all to the same SPR, the dependency checking logic of the source core should prevent out of order execution even if the source core is designed to perform out of order execution. Thus, a predictable stream of register values may be provided over the SPR interface to the target core. In response to the SPR write instructions, the source core may transmit SPR write requests (WrReq in  FIG. 4 ) to the SPR  60 A, which may transmit them to the SPR router  60 B. The SPR router  60 B may convert the write requests to read responses (RdRsp in  FIG. 4 ). Alternatively, write requests may be converted to read responses by the SPR router  60 A and then transmitted to the SPR router  60 B. The target core&#39;s instruction sequence includes a series of SPR read instructions (RdSpr), each reading the V_Spr address and writing the result into a GPR. The order of the GPRs in the instructions in the target core may be the same as the order in the source core. Since all the instructions depend on the same source operation V_Spr, each instruction is ready to execute at the same time. Scheduling logic that schedules the oldest instruction first may ensure the instructions stay in order. Each RdSpr instruction may be matched with a corresponding read response from the SPR router  60 B, completing the transfer. Thus, the stream of GPR values may be provided from the source core to the target core. 
     In addition to transmitting instructions to the cores for performing the register state transfer, the migration control circuit  70  may also concurrently transmit a start signal to the source and target cores, so that they start at approximately the same time. There may be a few clock cycles of uncertainty due to synchronization of the start signals into the cores, but there may be enough flexibility in the SPR interconnect to handle the uncertainty since the same uncertainty may exist when reading/writing SPRs  68 C- 68 D from either core  40  or  42 . 
       FIG. 5  is an example of using external SPR read and write requests to transfer SPR state. The migration control circuit may be configured to transmit the SPR read requests to the SPR router  60 A- 60 B coupled to the source core. The SPR router may transmit the read requests to the source core (RdReq Spr 0 , RdReq Spr 1 , etc. in  FIG. 5 ). The source core may read the SPR contents and transmit the data in read responses to the SPR router  60 A- 60 B (RdRsp Spr 0 , RdRsp Spr 1 , etc.). The SPR router  60 A- 60 B coupled to the source core may capture the read responses and convert them to write requests (WrReq in  FIG. 5 ) targeted at the target core. The SPR routers  60 A- 60 B may route the converted write requests to the targeted SPR in the target core. 
     In an embodiment, processor state other than GPRs and SPRs may be migrated as well. After transferring some of the GPRs, but the transferred GPRs in the source core may be used as temporary storage. Instructions may be injected to read the other processor state (e.g. flags, etc.) into the transferred GPR. The data may be transferred to the target core (to one of the GPRs that has not yet been transferred) via the V_Spr mechanism described above. Instructions may be injected in the target core to move the GPR data to the corresponding location in the target core. Remaining GPR state may then be transferred. 
     It is noted that, while the migration control circuit  70  is shown as a single block in the shared cache  34 , the migration control circuit  70  may include circuitry located within each core as well as circuitry outside the cores (e.g. in the shared cache  34  as shown). 
       FIG. 6  is a flowchart illustrating one embodiment of operation of the processor power manager  36  in response to a new PState written to the PState register  38 . While the blocks are shown in a particular order for ease of understanding, other orders may be used. Blocks may be performed in parallel in combinatorial logic in the processor power manager  36 . Blocks, combinations of blocks, and/or the flowchart as a whole may be pipelined over multiple clock cycles. The processor power state manager  36  may be configured to implement the operation shown in  FIG. 6 . 
     The active core may be the core  40 / 42  which is currently executing code. In some embodiments, the active core may be the only core that is powered on during steady state operation at the current PState. If the new PState is not mapped to the active core (decision block  80 , “no” leg), the processor power state manager  36  may perform a “core swap” to the core to which the new PState is mapped (block  82 ). If the new PState is mapped to the active core (decision block  80 , “yes” leg), the active core may remain active and execution may continue while the PState is changed. If the new PState is an increase from the current PState (decision block  84 , “yes” leg), the supply voltage magnitude may be increased first to support the increased frequency. Thus, the processor power state manager  36  may request the voltage increase (block  86 ) and wait for the voltage increase to complete (decision block  88 , “yes” leg). The processor power state manager  36  may determine that voltage increase is complete by waiting for a specified period of time, or may receive a communication that indicates when the voltage increase is complete. In an embodiment, the processor power state manager  36  may transmit the voltage increase request to another power manager (e.g. an SOC level power manager shown in  FIG. 8 , in one embodiment) or may transmit the voltage request directly to a PMU that supplies the voltage. Once the voltage increase is complete, the processor power manager  36  may increase the frequency of the clock (block  90 ). On the other hand, if the new PState is a decrease from the current PState, the current supply voltage may support the new (lower) frequency. Thus (decision block  94 , “no” leg), the processor power manager  36  may update the clock frequency and request the new supply voltage without waiting for the voltage change to complete (block  92 ). 
       FIG. 7  is a flowchart illustrating one embodiment of operation of the processor power manager  36  to perform a core swap (block  82  from  FIG. 6 ). While the blocks are shown in a particular order for ease of understanding, other orders may be used. Blocks may be performed in parallel in combinatorial logic in the processor power manager  36 . Blocks, combinations of blocks, and/or the flowchart as a whole may be pipelined over multiple clock cycles. The processor power state manager  36  may be configured to implement the operation shown in  FIG. 7 . 
     The processor power manager  36  may transition the active core to a “safe” PState (block  100 ). The safe PState may be a state at which both the active core and the target core operate correctly. In this context, the target core may be the core to which the new PState is mapped. In embodiments in which there are more than two cores, the safe PState may be different depending on which cores are the active and target cores. The safe PState need not be a PState that is selectable in the PState register  38 . That is, the combination of supply voltage and frequency may not be one of the supported combinations that are mapped to the cores. For example, the PCore may be capable of running at a higher frequency given the supply voltage magnitude in the safe PState. However, the ECore may not be capable of running at the higher frequency with the given supply voltage magnitude. Thus, a safe PState could include the current supply voltage magnitude but a lower clock frequency. Alternatively, the target core may not support the current supply voltage, and the safe PState may include different supply voltage magnitude and clock frequency. Transitioning to the safe PState may be similar to blocks  84 ,  86 ,  88 ,  90 , and  92  in  FIG. 6 . The processor power manager  36  may also quiesce the active core to stop instruction execution. 
     The processor power manager  36  may power up the target core (block  102 ). For example, in the embodiment of  FIG. 1 , the processor power manager  36  may close the power switches to the target core, allowing power to flow to the target core. The target core may be reset after power has stabilized. In some embodiments, the target core may initialize after reset is complete. Once reset (and initialization, if applicable) is complete (decision block  104 , “yes” leg), the processor power manager  36  may initiate a transfer of the processor context from the active core to the target core (block  106 ). More particularly, the migration control circuit  70  may initiate the transfer of processor state from the source core to the target core. In an embodiment, the cores may include circuitry configured to transmit/receive the processor context. In another embodiment, the circuitry may be in the migration control circuit  70  and/or in instructions transmitted by the migration control circuit  70  to the cores. As mentioned previously, the cores may also be configured to flush the caches during the context transfer. Once the context transfer is complete (decision block  108 , “yes” leg), the processor power manager may power down the (previously) active core and the target core may become the active core (block  110 ). The powering down may be accomplished, e.g. by opening the power switches to the previously active core. The processor power manager  36  may transition the active core to the new PState (block  112 ). Transitioning to the new PState may be similar to blocks  84 ,  86 ,  88 ,  90 , and  92  in  FIG. 6 . 
       FIG. 8  is a flowchart illustrating one embodiment of operation of the migration control circuit  70  and the SPR routers  60 A- 60 D and ring control circuits  58 A- 58 B to transfer processor context or state (block  106  from  FIG. 7 ). While the blocks are shown in a particular order for ease of understanding, other orders may be used. Blocks may be performed in parallel in combinatorial logic in the control circuit  70 , the SPR routers  60 A- 60 D, and/or the ring control circuits  58 A- 58 B. Blocks, combinations of blocks, and/or the flowchart as a whole may be pipelined over multiple clock cycles. The above circuitry may be configured to implement the operation shown in  FIG. 8 . 
     The migration control circuit  70  may generate the instructions for the source core and the target core (block  120 ). At least some of the instructions for the beginning of each sequence (source and target) may be generated, although subsequent instruction generation may overlap the other operations illustrated in  FIG. 8 . Instruction generation may be performed via state machine, reading a table of instructions from a memory such as a read-only memory (ROM), Flash memory, or random access memory (RAM), etc. When at least enough instructions have been generated to keep the cores&#39; pipelines busy, the migration control circuit  70  may signal the cores to start the transfer (block  122 ). The ring control circuit  58 A- 58 B in the source core may detect each write request to the V_Spr address and may route the write request to SPR routers  60 A- 60 B. The SPR routers  60 A- 60 B may convert the write requests to read responses and may transmit the read responses to the target core (decision block  124 , “yes” leg and block  126 ). As discussed above, the SPR routers  60 A- 60 B and/or the ring control circuit  58 A- 58 B in the target core may convert the SPR writes to read responses in the target core, providing the register data to be written to the target registers of the RdSpr operations in the target core. 
     Once the writes to the V_Spr have concluded (and thus the GPR register transfer is complete, decision block  124 , “no” leg), migration control circuit  70  may generate the SPR read requests and transmit them to the SPR router  60 A- 60 B coupled to the source core (the “initiating SPR router” block  127 ). As mentioned previously, in an embodiment, a subset of the SPRs may be migrated and thus the migration control circuit  70  may generate the SPR read requests for migratable SPRs. The initiating SPR router may transmit the SPR read requests to the source core. The ring control circuit  58 A- 58 B in the source core may route each SPR read on the local SPR ring, and may transmit the read response to the initiating SPR router. The initiating SPR router may detect the read response (decision block  128 , “yes” leg). The initiating SPR router may capture the read response from the local SPR ring and convert it to a write request to the target core (block  130 ). The initiating SPR router may route the write request to the target core (via the other SPR router  60 A- 60 B over the buses  72 ). Alternatively, read responses may be converted to write requests by the other SPR router  60 A- 60 B (coupled to the target core). 
     After the SPR transfer is complete (decision block  128 , “no” leg), the migration control circuit  70  may manage any potential “side effects” of the transfer (block  132 ). Side effects may be state of the processor that is not in the GPRs and SPRs, but which may need to be retained to provide the behavior expected by the programmer. For example, if the processor is stopped prior to the transfer (e.g. in a wait for event state such as in response to a wait for interrupt (WFI) or wait for event (WFE) instruction), the target core should be in the same wait for event state. If the processor is in a debug mode prior to the transfer, then the target core should be in debug mode. Interrupt state captured by the processor may be preserved. 
       FIG. 9  is a block diagram of one embodiment of an SOC  10  coupled to a memory  12 . As implied by the name, the components of the SOC  10  may be integrated onto a single semiconductor substrate as an integrated circuit “chip.” In some embodiments, the components may be implemented on two or more discrete chips in a system. However, the SOC  10  will be used as an example herein. In the illustrated embodiment, the components of the SOC  10  include a central processing unit (CPU) complex  14  (which may be implemented by the processor cluster  30  shown in  FIG. 1 ), peripheral components  18 A- 18 B (more briefly, “peripherals”  18 ), a memory controller  22 , an SOC power manager (PMGR)  16 , and a communication fabric  27 . The components  14 ,  16 ,  18 A- 18 B, and  22  may all be coupled to the communication fabric  27 . The memory controller  22  may be coupled to the memory  12  during use. 
     The memory controller  22  may generally include the circuitry for receiving memory operations from the other components of the SOC  10  and for accessing the memory  12  to complete the memory operations. The memory controller  22  may be configured to access any type of memory  12 . For example, the memory  12  may be static random access memory (SRAM), dynamic RAM (DRAM) such as synchronous DRAM (SDRAM) including double data rate (DDR, DDR 2 , DDR 3 , DDR 4 , etc.) DRAM. Low power/mobile versions of the DDR DRAM may be supported (e.g. LPDDR, mDDR, etc.). The memory controller  22  may include queues for memory operations, for ordering (and potentially reordering) the operations and presenting the operations to the memory  12 . The memory controller  22  may further include data buffers to store write data awaiting write to memory and read data awaiting return to the source of the memory operation. In some embodiments, the memory controller  22  may include a memory cache to store recently accessed memory data. In SOC implementations, for example, the memory cache may reduce power consumption in the SOC by avoiding reaccess of data from the memory  12  if it is expected to be accessed again soon. In some cases, the memory cache may also be referred to as a system cache, as opposed to private caches such as the shared cache or caches in the processors, which serve only certain components. Additionally, in some embodiments, a system cache need not be located within the memory controller  22 . 
     The peripherals  18 A- 18 B may be any set of additional hardware functionality included in the SOC  10 . For example, the peripherals  18 A- 18 B may include video peripherals such as an image signal processor configured to process image capture data from a camera or other image sensor, display controllers configured to display video data on one or more display devices, graphics processing units (GPUs), video encoder/decoders, scalers, rotators, blenders, etc. The peripherals may include audio peripherals such as microphones, speakers, interfaces to microphones and speakers, audio processors, digital signal processors, mixers, etc. The peripherals may include interface controllers for various interfaces external to the SOC  10  (e.g. the peripheral  18 B) including interfaces such as Universal Serial Bus (USB), peripheral component interconnect (PCI) including PCI Express (PCIe), serial and parallel ports, etc. The peripherals may include networking peripherals such as media access controllers (MACs). Any set of hardware may be included. 
     The communication fabric  27  may be any communication interconnect and protocol for communicating among the components of the SOC  10 . The communication fabric  27  may be bus-based, including shared bus configurations, cross bar configurations, and hierarchical buses with bridges. The communication fabric  27  may also be packet-based, and may be hierarchical with bridges, cross bar, point-to-point, or other interconnects. 
     The SOC PMGR  16  may be configured to control the supply voltage magnitudes requested from the PMU in the system. There may be multiple supply voltages generated by the PMU for the SOC  10 . For example, the V P  voltage may be generated for the processors  32 A- 32   n  in the CPU complex  14 , and a V SOC  voltage may be generated for other components in the SOC  10 . In an embodiment, V SOC  may serve the memory controller  22 , the peripherals  18 , the SOC PMGR  16 , and the other components of the SOC  10  and power gating may be employed based on power domains. There may be multiple supply voltages for the rest of the SOC  10 , in some embodiments. In some embodiments, there may also be a memory supply voltage for various memory arrays in the CPU complex  14  and/or the SOC  10 . The memory supply voltage may be used with the voltage supplied to the logic circuitry (e.g. V P  or V SOC ), which may have a lower voltage magnitude than that required to ensure robust memory operation. The SOC PMGR  16  may be under direct software control (e.g. software may directly request the power up and/or power down of components) and/or may be configured to monitor the SOC  10  and determine when various components are to be powered up or powered down. For the CPU complex  14 , the voltage requests for V P  may be provided to the SOC PMGR  16 , which may communicate the requests to the PMU to effect the change in supply voltage magnitudes. 
     Generally, a component may be referred to as powered on or powered off. The component may be powered on if it is receiving supply voltage so that it may operate as designed. If the component is powered off, then it is not receiving the supply voltage and is not in operation. The component may also be referred to as powered up if it is powered on, and powered down if it is powered off. Powering up a component may refer to supplying the supply voltage to a component that is powered off, and powering down the component may refer to terminating the supply of the supply voltage to the component. Similarly, any subcomponent and/or the SOC  10  as a whole may be referred to as powered up/down, etc. A component may be a predefined block of circuitry which provides a specified function within the SOC  10  and which has a specific interface to the rest of the SOC  10 . Thus, the peripherals  18 A- 18 B, the CPU complex  14 , the memory controller  22 , and the SOC PMGR  16  may each be examples of a component. 
     It is noted that the number of components of the SOC  10  (and the number of subcomponents for those shown in  FIG. 1 , such as within the CPU complex  14 ) may vary from embodiment to embodiment. There may be more or fewer of each component/subcomponent than the number shown in  FIG. 1 . 
     Turning next to  FIG. 10 , a block diagram of one embodiment of a system  150  is shown. In the illustrated embodiment, the system  150  includes at least one instance of the SOC  10  coupled to one or more peripherals  154  and the external memory  12 . The PMU  156  is provided which supplies the supply voltages to the SOC  10  as well as one or more supply voltages to the memory  12  and/or the peripherals  154 . In some embodiments, more than one instance of the SOC  10  may be included (and more than one memory  12  may be included as well). 
     The PMU  156  may generally include the circuitry to generate supply voltages and to provide those supply voltages to other components of the system such as the SOC  10 , the memory  12 , various off-chip peripheral components  154  such as display devices, image sensors, user interface devices, etc. The PMU  156  may thus include programmable voltage regulators, logic to interface to the SOC  10  and more particularly the SOC PMGR  16  to receive voltage requests, etc. 
     The peripherals  154  may include any desired circuitry, depending on the type of system  150 . For example, in one embodiment, the system  150  may be a mobile device (e.g. personal digital assistant (PDA), smart phone, etc.) and the peripherals  154  may include devices for various types of wireless communication, such as wifi, Bluetooth, cellular, global positioning system, etc. The peripherals  154  may also include additional storage, including RAM storage, solid state storage, or disk storage. The peripherals  154  may include user interface devices such as a display screen, including touch display screens or multitouch display screens, keyboard or other input devices, microphones, speakers, etc. In other embodiments, the system  150  may be any type of computing system (e.g. desktop personal computer, laptop, workstation, net top etc.). 
     The external memory  12  may include any type of memory. For example, the external memory  12  may be SRAM, dynamic RAM (DRAM) such as synchronous DRAM (SDRAM), double data rate (DDR, DDR 2 , DDR 3 , etc.) SDRAM, RAMBUS DRAM, low power versions of the DDR DRAM (e.g. LPDDR, mDDR, etc.), etc. The external memory  12  may include one or more memory modules to which the memory devices are mounted, such as single inline memory modules (SIMMs), dual inline memory modules (DIMMs), etc. Alternatively, the external memory  12  may include one or more memory devices that are mounted on the SOC  10  in a chip-on-chip or package-on-package implementation. 
     Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Metadata:
Filing Date: 20150903
Publication Date: 20180327
Grant Date: 20180327
Priority Date: 20150903
Inventors: HARDAGE, JR. JAMES N.
BECKER DANIEL U.
Tsay Christopher M.
RUSSO RICHARD F.
WEN SHIH-CHIEH R.
LARSON RICHARD H.
Assignee: APPLE INC
CPC Classifications: [{"code": "G06F12/084", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F9/3828", "inventive": true, "first": false, "tree": "[]"}, {"code": "Y02B60/1225", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F9/30101", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F12/0813", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F9/5088", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F12/084", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F2212/1028", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F2212/314", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F2212/314", "inventive": false, "first": false, "tree": "[]"}, {"code": "Y02D10/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F2212/1028", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F2212/1028", "inventive": false, "first": false, "tree": "[]"}, {"code": "Y02D10/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F9/3828", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F12/0813", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F9/30101", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F2212/314", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F12/084", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F9/5088", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F12/0813", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 58190508