Portable communication devices (e.g., cellular telephones, smart phones, tablet computers, portable game consoles, wearable devices, and other battery-powered devices) and other computing devices continue to offer an ever-expanding array of features and services, and provide users with unprecedented levels of access to information, resources, and communications. To keep pace with these service enhancements, such devices have become more powerful and more complex. Portable communication devices now commonly include a system on chip (SoC) comprising a plurality of processing devices embedded on a single substrate, which may read data from and store data in an off-chip or external system memory comprising volatile memory (e.g., double data rate (DDR) dynamic random access memory (DRAM)) via a high-speed bus.
A significant factor in the success of SoC designs is the ability to deliver efficient access to the external system memory, which is typically shared and services the SoC processing devices with varying bandwidth and latency requirements. In addition to providing data to the on-chip memory clients, there is considerable demand to manage large amounts of data while operating in a power efficient manner. To minimize power consumption, such devices may implement micro-idle power management techniques. The term “micro idle” refers to a transient timing window in which all the SoC memory clients are idle and do not require memory bandwidth. In conventional portable communication devices, the micro idle window may range from approximately 1 to hundreds of microseconds (us).
As known in the art, the micro idle window may occur during intra-frame processing and, therefore, presents in many operational use cases, such as, for example, audio playback, video decode, voice calls, static display, etc. The micro idle window presents an opportunity to save DDR controller, physical layer (PHY), and DRAM power consumption. Existing solutions for providing micro-idle power management typically employ one or two levels of firmware (e.g., SoC power management microcontroller firmware, DDR subsystem (DDRSS) local microcontroller firmware). Firmware-based solutions may result in high entry/exit overhead due to the various handshakes with software/hardware associated with each of the SoC memory clients, which may significantly limit the opportunities to save micro-idle power consumption in certain use cases.
Accordingly, there is a need for improved systems and methods for providing micro-idle power consumption.
Systems and methods are disclosed for providing micro-idle memory power management. One embodiment of a method comprises receiving and storing an exit latency vote from each of a plurality of memory subsystems on a system on chip electrically coupled to a system memory. In response to a micro-idle memory state in which each of the memory subsystems are idle, a minimum exit latency value from the plurality of exit latency votes is determined. One of a plurality of system memory modes is selected which has a micro-idle sleep time that meets the minimum exit latency value while minimizing system memory power consumption. The selected system memory mode is initiated.
An embodiment of a micro-idle memory power management system comprises a double data rate (DDR) memory electrically coupled to a system on chip (SoC). The SoC comprises a plurality of memory subsystems, a DDR memory controller, and a micro-idle power management hardware module. The micro-idle power management hardware module comprises one or more hardware registers, a comparator, and a finite state machine. The one or more hardware registers are configured to receive and store an exit latency vote from each of the plurality of memory subsystems. The comparator is in communication with the one or more hardware registers and configured to determine, in response to a micro-idle memory state in which each of the plurality of memory subsystems are idle, a minimum exit latency value from the plurality of exit latency votes. The finite state machine comprises a plurality of memory states and is configured to receive the minimum exit latency and, in response, select one of the plurality of memory states having a micro-idle sleep time that meets the minimum exit latency value while minimizing DDR memory power consumption.
In the Figures, like reference numerals refer to like parts throughout the various views unless otherwise indicated. For reference numerals with letter character designations such as “102A” or “102B”, the letter character designations may differentiate two like parts or elements present in the same Figure. Letter character designations for reference numerals may be omitted when it is intended that a reference numeral to encompass all parts having the same reference numeral in all Figures.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.
In this description, the term “application” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, an “application” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
The term “content” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, “content” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
As used in this description, the terms “component,” “database,” “module,” “system,” and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device may be a component. One or more components may reside within a process and/or thread of execution, and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components may execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).
In this description, the terms “communication device,” “wireless device,” “wireless telephone”, “wireless communication device,” and “wireless handset” are used interchangeably. With the advent of third generation (“3G”), fourth generation (“4G”), fifth generation (“5G”) and other wireless technology, greater bandwidth availability has enabled more portable computing devices with a greater variety of wireless capabilities.
As illustrated in
Power controller 112 is electrically coupled to a power supply 106 via a power control bus, which comprises a power monitor 124 configured to measure energy usage associated with the SoC 102 and the DRAM 104 and, thereby, monitor device power consumption.
Clock controller 111 is responsible for generation, control and distribution of clocks to all the SoC subsystems and blocks. In an exemplary embodiment, clock controller 111 comprises shared Phase Locked Loops (PLLs) and Glitch-Free Clock Mux/Gate for each clock branch.
DDR controller 118 is configured to manage communication between SoC 102 and DRAM 104, including read and/or write transactions from memory subsystems 1-n residing on SoC 102.
As further illustrated in
In the embodiment of
Exit latency vote aggregator hardware module 128 comprises the hardware logic for receiving data related to the ongoing exit latency or micro-idle sleep time requirements of memory subsystems 1-n during operation of system 100. Exit latency vote aggregator hardware module 128 is configured to compute a minimum value (MIN) of the plurality of exit latency votes programmed in the respective CSRs for each memory subsystem. In an exemplary embodiment, exit latency vote aggregator hardware module 128 may be implemented in hardware with one or more comparators and multiplexers.
Finite state machine 120 comprises combinational logic for supporting a plurality of memory power states or modes for controlling operation of the off-chip system memory (e.g., DRAM 104) during a micro-idle window. When client active aggregator hardware module 126 determines a micro-idle window in which memory subsystems 1-n are all inactive, micro-idle power manager hardware system 120 selects the lowest available memory power state based on the current exit latency or micro-idle sleep time requirements of memory subsystems 1-n. For example, micro-idle power manager hardware system 120 may determine the deepest power state possible for DDR controller 118, associated DDR physical layer (PHY), and DRAM 104 that minimizes power consumption while meeting a minimum exit latency requirement of the most aggressive memory subsystem 1-n.
Micro-idle power manager hardware system 120 may send a DDR ready signal to memory subsystems 108 and 110, via interfaces 424 and 428, respectively, to indicate when DDR controller 118 and PHY 414 are out of a sleep state. Micro-idle power manager hardware system 120 may send a root clock_gate_enable signal to clock controller 111, via hardware interface 432, indicating that root clock gating is enabled to gate off DDR controller 118 and PHY 414 clock branches. Handshake signals used for controlling power switches (e.g., pg_en/ack) may be sent to power controller 112, via hardware interface 436, indicating that micro-idle power manager hardware system 120 is in an Always ON domain.
DDR controller 118 may be electrically coupled to micro-idle power manager hardware system 120 via hardware interfaces 438, 440, and 442. Hardware interface 438 comprises a control and status register (CSR) programming bus for enabling the system 100 to enter one of a plurality of power states that meets the selected minimum exit latency value of the memory subsystems 1-n. As illustrated in
DDR PHY 414 may be electrically coupled to micro-idle power manager hardware system 120 via hardware interfaces 444, 446, and 448. It should be appreciated that interfaces 444, 446, and 448 may drive low power post controller handshake and EL values. For example, interface 444 may enable micro-idle power manager hardware system 120 to send a low power request signal (lp req) to PHY power manager 416. Interface 448 may enable micro-idle power manager hardware system 120 to receive acknowledge signal(s) (lp_ack) from PHY power manager 416. Interface 446 may enable micro-idle power manager hardware system 120 to send a low power wake-up signal (lp wakeup) to PHY power manager 416.
As mentioned above, micro-idle power manager hardware system 120 is configured to receive ongoing client-specific exit latency values or votes from each of the memory subsystems. In the embodiment of
Referring to
Modem subsystem 704 may comprise one or more client drivers 714 for enabling modem programs or clients to provide exit latency votes to an exit latency driver 718. Modem subsystem 704 may further comprise one or more client sleep drivers 708 and a subsystem power manager module 720 for communicating with client active aggregator hardware module 126 in micro-idle power manager hardware system 120.
Having described the hardware and/or software components of
At block 721, one or more clients associated with CPU subsystem 702 may generate exit latency vote(s) according to their particular latency requirements, tolerances, etc. As illustrated in
At block 723, one or more modem clients associated with modem subsystem 704 may generate exit latency vote(s) according to their particular latency requirements, tolerances, etc. The modem client exit latency votes may be generated and/or provided by client driver(s) 714 to exit latency driver 718. At block 724, the modem client exit latencies may be aggregated by exit latency driver 718 and programmed to, for example, another hardware register residing in micro-idle power manager hardware system 120. By way of example, the exit latency vote from modem subsystem 704 may comprise the second exit latency vote (EL1) comprises the value “01”, which is mapped to a high performance mode with marginal power savings (
At block 725, modem subsystem 704 may go idle, in which case sleep driver 716 updates exit latency requests according to a next wake time. It should be appreciated that this may enable a correct exit latency update in the absence of client votes, as well as in the case where a client exit latency is relatively high but the sleep time is lower. At block 726, exit latency driver 718 in modem subsystem 704 may check whether a current sleep vote is different than a last sleep vote. If the current sleep vote is different than the last sleep vote, exit latency driver 718 may send a new aggregated vote to micro-idle power manager hardware system 120.
At block 727, CPU subsystem 702 may go idle, in which case sleep driver 708 updates exit latency requests according to a next wake time, in a similar manner as modem subsystem 704. At block 728, exit latency driver 710 in CPU subsystem 702 may check whether a current sleep vote is different than a last sleep vote. If the current sleep vote is different than the last sleep vote, exit latency driver 710 may send a new aggregated vote to micro-idle power manager hardware system 120.
At block 729, modem subsystem 704 may go to sleep. For example, subsystem power manager 720 may send a DDR_vote having a value “0” to client active aggregator hardware module 726. At block 730, CPU subsystem 702 may go to sleep. Subsystem power manager 712 may send a DDR_vote having a value “0” to client active aggregator hardware module 726.
In response to the above step(s), all of the clients associated with CPU subsystem 702 and modem subsystem 704 may be in a sleep mode. At block 731, exit latency vote aggregator hardware module 128 may check the aggregated exit latency values and determine the minimum exit latency. In this example, the exit latency vote from modem subsystem 704 comprises the fourth exit latency vote (EL4) having the value “11”, which is mapped to a power optimized mode. The exit latency vote from CPU subsystem 702 comprises the third exit latency vote (EL3) having the value “10”, which is mapped to the power friendly mode. In this particular example, exit latency vote aggregator hardware module 128 may read these values and determine that the exit latency value of “10” comprises a minimum exit latency. Because the minimum exit latency value of “10” corresponds to the power friendly mode, at block 732, micro-idle power manager hardware system 120 programs DDR controller 118 and DDR PHY 414 to enter the power friendly mode.
As mentioned above, the system 100 may be incorporated into any desirable computing system.
A display controller 828 and a touch screen controller 830 may be coupled to the CPU 802. In turn, the touch screen display 806 external to the on-chip system 822 may be coupled to the display controller 828 and the touch screen controller 830.
Further, as shown in
A stereo audio coder-decoder (CODEC) 850 may be coupled to the multicore CPU 802. Moreover, an audio amplifier 852 may be coupled to the stereo audio CODEC 850. In an exemplary aspect, a first stereo speaker 854 and a second stereo speaker 856 are coupled to the audio amplifier 852.
As depicted in
It should be appreciated that one or more of the method steps described herein may be stored in the memory as computer program instructions, such as the modules described above. These instructions may be executed by any suitable processor in combination or in concert with the corresponding module to perform the methods described herein.
Certain steps in the processes or process flows described in this specification naturally precede others for the invention to function as described. However, the invention is not limited to the order of the steps described if such order or sequence does not alter the functionality of the invention. That is, it is recognized that some steps may performed before, after, or parallel (substantially simultaneously with) other steps without departing from the scope and spirit of the invention. In some instances, certain steps may be omitted or not performed without departing from the invention. Further, words such as “thereafter”, “then”, “next”, etc. are not intended to limit the order of the steps. These words are simply used to guide the reader through the description of the exemplary method.
Additionally, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example.
Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the Figures which may illustrate various process flows.
In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, NAND flash, NOR flash, M-RAM, P-RAM, R-RAM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer.
Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL”), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
Disk and disc, as used herein, includes compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
Alternative embodiments will become apparent to one of ordinary skill in the art to which the invention pertains without departing from its spirit and scope. Therefore, although selected aspects have been illustrated and described in detail, it will be understood that various substitutions and alterations may be made therein without departing from the spirit and scope of the present invention, as defined by the following claims.