Patent Description:
A cache is a device that stores data retrieved from memory or data to be written to memory for one or more different hardware devices in a system. The hardware devices can be different components integrated into a system on a chip (SOC). In this specification, the devices that provide read requests and write requests through caches will be referred to as client devices. Some caches service memory requests for multiple different client devices integrated into a single system, e.g., an SOC, as a last cache before reaching memory. Such caches can be referred to as system-level caches (SLCs).

Caches can be used to reduce power consumption by reducing overall requests to main memory. In addition, as long as client devices can access the data they need in the cache, power can further be saved by placing the main memory as well as data paths to the main memory in a low-power state. Therefore, cache usage is correlated with overall power consumption, and increasing cache usage results in a decrease in overall power consumption. Therefore, devices that rely on battery power, e.g., mobile computing devices, can extend their battery life by increasing cache usage for the integrated client devices.

Some SOC client devices are ambient computing devices that are capable of monitoring and processing sensor inputs while the SOC remains in a low-power state. If the ambient computing device detects a sensor input, e.g., sound arriving at a microphone, the ambient computing device can trigger the SOC to exit the low-power state if additional processing power is needed to handle the sensor input. <CIT> describes an information processing apparatus capable of operating by switching between a first power mode and a second power mode with less power consumption than the first power mode. The described apparatus comprises a plurality of processors and a plurality of memories in correspondence with the plurality of processors, and controls power supplied to the plurality of processors and the corresponding plurality of memories. When operating in the second power mode, each of the plurality of memories stores a program to be loaded by a corresponding processor of the memory, and when one of the plurality of processors and the corresponding memory operate, power supply to processors and memories other than the one processor and the corresponding memory is limited. <CIT> describes a method and system for pre-loading and executing code within a cache. An indication to operate an electronic device in a sleep state is received. At least one instance of code is loaded into a cache memory in response to receiving the indication. The at least one instance of code is for causing the electronic device to operate in said sleep state. <CIT> describes a method for reducing latency in a system that includes one or more processing devices, a system memory, and a cache memory. A pre-fetch command that identifies requested data is received from a requestor device. The requested data is pre-fetched from the system memory into the cache memory in response to the pre-fetch command. A data access request corresponding to the pre-fetch command is then received, and in response to the data access request the data is provided from the cache memory to the requestor device. <CIT> describes a method for improving memory performance and decreasing memory power requirements. A prefetch buffer is added to a memory controller with accompanying prefetch logic. The memory controller first attempts to satisfy memory requests from the prefetch buffer allowing the main memory to stay in a reduced power state until accessing it is required. If the memory controller is unable to satisfy a memory request from the prefetch buffer, the main memory is changed to an active power state and the prefetch logic is invoked. The prefetch logic loads the requested memory, returns the request memory to the requester, and loads memory likely to be requested in the near future into the prefetch buffer. Concurrent with the execution of the prefetch logic, the memory controller returns the requested data. Following the retrieval from main memory, the memory controller may place the main memory into a reduced power state immediately, or after a selected interval, based upon the likelihood of a subsequent memory request miss. <CIT> describes dynamically conserving power in non-uniform cache access (NUCA) caches. There is described a computing device, having one or more processors coupled with one or more NUCA cache elements. The NUCA cache elements may comprise one or more banks of cache memory, wherein ways of the cache are vertically distributed across multiple banks. To conserve power, the computing devices generally turn off groups of banks, in a sequential manner according to different power states, based on the access latencies of the banks. The computing devices may first turn off groups having the greatest access latencies. The computing devices may conserve additional power by turning of more groups of banks according to different power states, continuing to turn off groups with larger access latencies before turning off groups with the smaller access latencies.

Aspects of the disclosed subject matter are as set out in the accompanying claims. This specification describes techniques for an ambient computing device to perform a cache preparation process so that the ambient computing device can operate during a low-power state using only the data stored in the cache. This allows the system to power down other high-power devices during a low-power state in which the ambient computing device can still process sensor inputs. For example, these techniques allow the system to power down the main memory, other larger caches in the cache hierarchy, as well as related data pathways and power domains for these components.

The computing device can process sensor inputs while the device is in a low-power state. While in the low-power state, the computing device can power down one or more of its power consuming components such as RAMs, client devices, data pathways and interfaces between the components and controllers, e.g. memory controllers.

The computing device can include one or more ambient computing devices (ACDs) that are configured to process the sensor inputs during the low-power state of the computing device. The ACD is capable of determining the data and instructions that may be needed to process the inputs while the computing device is in the low-power state. The ACD prefetches such data and instructions into a local cache memory portion before the computing device enters the low-power state. By using the prefetched data and instructions, the ACD can process sensor inputs without waking the memory controller or a memory device, which helps to minimize power consumption during the low-power state.

In addition, the ACD may need only a portion of the local cache memory for processing the inputs during the low-power state. Accordingly, the rest of the local cache memory can be powered down during the low-power state, resulting in even more savings of power consumption.

In case that the ACD needs more resources than the portion of the local cache memory that is dedicated to the ACD operations during the low-power state, the ACD can trigger the computing device to exit the low-power state. Alternatively or in addition, the ACD can determine a particular portion of a memory device that has the resources that the ACD needs and trigger that particular portion of the memory device to exit the low-power state. Accordingly, other components of the computing device can remain in the low-power mode while the ACD fetches the data it needs from the particular portion of the memory.

The subject matter may be provided in the form of a system, method, apparatus or a computer-readable storage medium, such as storing instructions relating to the method.

<FIG> is a diagram of an example system <NUM>. The system <NUM> includes a system on a chip (SOC) <NUM> communicatively coupled to a memory device <NUM>. The SOC <NUM> has an ambient computing device <NUM>, multiple other client devices 110a-n, and a hierarchy of caches <NUM> and <NUM>. The cache <NUM> is a local cache that services only memory requests from the ambient computing device. The cache <NUM> is a system-level cache that services memory requests from all of the client devices including the ACD <NUM>. The techniques described in this specification can also be used for systems having additional layers of caches between the ACD <NUM> and the memory <NUM>.

The SOC <NUM> is an example of a device that can be installed on or integrated into any appropriate computing device, which may be referred to as a host device. Because the techniques described in this specification are particularly suited to saving power consumption for the host device, the SOC <NUM> can be particularly beneficial when installed on a mobile host devices that rely on battery power, e.g., a smart phone, a smart watch or another wearable computing device, a tablet computer, or a laptop computer, to name just a few examples. While in a low-power mode, the SOC <NUM> can receive inputs, such as sensor inputs from integrated sensor of the host device. Examples of such sensors include location sensors, presence sensors, gesture sensors, heart rate sensors, and audio sensors, to name just a few examples.

The SOC <NUM> has multiple client devices 110a-n. Each of the client devices 110an can be any appropriate module, device, or functional component that is configured to read and store data in the memory device <NUM> through the SOC fabric <NUM>. For example, a client device can be a CPU, an application-specific integrated circuit or lower-level components of the SOC itself that are capable of initiating communications through the SOC fabric <NUM>.

One or more of the client devices can be an ambient computing device (ACD) <NUM>. An ambient computing device is a component that is configured to perform computing operations while the SOC <NUM> is in a low-power state. The ambient computing device <NUM> is configured to process inputs to the SOC <NUM> while the SOC <NUM> is in the low-power state. In addition, the ambient computing device <NUM> can operate like any other client device during other power states of the SOC <NUM>.

The SOC fabric <NUM> is a communications subsystem of the SOC <NUM>. The SOC fabric <NUM> includes communications pathways that allow the client devices 110a-n to communicate with one another as well as to make requests to read and write data using the memory device <NUM>. The SOC fabric <NUM> can include any appropriate combination of communications hardware, e.g., buses or dedicated interconnect circuitry.

The system <NUM> also includes communications pathway <NUM> that allow communication between the SLC <NUM> and the memory controller <NUM> as well as an interchip communications pathway <NUM> that allows communication between the memory controller <NUM> and the memory device <NUM>.

During a low-power state, the SOC <NUM> can save power by powering down one or more of the communications pathways <NUM> and <NUM>. Alternatively or in addition, SOC <NUM> can power down the memory device <NUM>, the memory controller <NUM>, and/or one or more of the client computing devices 110a-n to further conserve power. As another example, the SOC <NUM> can enter a clock-shut-off mode in which respective clock circuits are powered down for one or more devices.

The caches <NUM> and <NUM> are positioned in the data pathway between the ACD <NUM> and the memory controller <NUM>. The memory controller <NUM> can handle requests to and from the memory device <NUM>. Thus, requests from the ambient computing device <NUM> to read from or write to the memory device <NUM> pass through the caches <NUM> and <NUM>. For example, the ACD <NUM> can make a request to read from the memory device <NUM>, which passes through the local cache <NUM>, the SOC fabric <NUM> and on to the SLC <NUM>. The SLC <NUM> can handle the request before forwarding the request to the memory controller <NUM> for the memory device <NUM>.

The SLC <NUM> can cache read requests, write requests, or both from client devices 110a-n and ambient computing device <NUM>. The SLC <NUM> can cache read requests by responding to the request with data stored in the cache rather than fetching the data from the memory device <NUM>. Similarly, the SLC <NUM> can cache write requests by writing the new data in the cache rather than writing the new data in the memory device <NUM>. The SLC <NUM> can perform a write-back at a later time to store the updated data in the memory device <NUM>.

While the SOC <NUM> is in the low-power state, the ambient computing device <NUM> can process inputs to the SOC <NUM> using only instructions and data stored in one of the caches <NUM> or <NUM>. Therefore, the SOC <NUM> can reduce or remove power to one or more other components of the system or all other components of the system. For example, in some implementations, while in the low-power state, even though the ambient computing device <NUM> is processing inputs, the SOC <NUM> can still power down the memory device <NUM> because the ambient computing device <NUM> does not need to access the memory device <NUM>. For the same reasons, the SOC <NUM> can also power down the memory controller <NUM>.

To prepare to enter the low-power state, the SOC <NUM> can pre-fetch, into one of the caches <NUM> or <NUM>, the instructions and data required to process inputs to the SOC <NUM> during the low-power state. The SOC <NUM> can then enter the low-power state by powering down other components, and the ambient computing device <NUM> can use the instructions and data stored in the cache to process inputs to the SOC <NUM> while the SOC <NUM> is in the low-power state.

<FIG> is a sequence diagram illustrating a sequence of events <NUM> of an example process for transitioning a system-on-a-chip (SOC) into a low-power state. In this example, the low-power state is named SLEEP. The example process <NUM> can be performed by the components of the SOC <NUM>.

The process illustrated in <FIG> is performed by four main components: a software power manager SPM (SPM) <NUM>, an ambient computing device (ACD) <NUM>, a cache <NUM>, and a hardware power manager (HPM) <NUM>. The SPM <NUM> controls one or more voltage rails, each corresponding to a data path between multiple components of the SOC. For example, the ACD <NUM> can be in communication with multiple portions of the cache <NUM> and each portion can be connected to the ACD <NUM> through a data path. When the SPM <NUM> powers down one or more voltage rails, the ACD <NUM> and the cache <NUM> can lose their connection through data paths associated with the one or more voltage rails.

The HPM <NUM> controls the power of the components of the SOC. For example, the HPM <NUM> indicates which components are powered up and which components are powered down.

Before the SOC <NUM> enters a low-power state, the SPM <NUM> sends a notification <NUM> to the ACD <NUM>. Upon receiving the notification <NUM>, the ACD <NUM> prepares for operating during the SOC's low-power state. The ACD <NUM> makes a determination on whether the ACD should use the cache <NUM> during the low-power state (<NUM>). In some implementations, this determination can be based on which of several low-power states the device is entering. For example, the device can support multiple low-power states, and in some of them, the ACD can exclusively use a cache without accessing memory.

As part of this process, the ACD <NUM>, or another component, can determine which cache in a hierarchy of caches should be used for the low-power state. In general, as caches get closer to memory, their speeds decrease and their storage sizes and power consumption increase. Therefore, the ACD <NUM> can determine a size of a low-power procedure to be executed during the particular low-power state and can select the smallest cache that can accommodate the instructions and data needed to execute the low-power procedure during the low-power state.

To prepare the cache <NUM> for use during SOC's low-power state, the ACD <NUM> executes instructions of a prefetch process to prepopulate the cache (<NUM>). The instructions of the prefetch process include prefetch loads and prefetch stores that prepopulate the cache. This prefetch process prepares the cache by ensuring that all instruction reads and data reads that will be needed during the low-power state get stored in the cache. In other words, the ACD <NUM> issues instructions for all reads that will be needed in the low-power state. If any of the reads result in a cache miss, the requested data will be populated into the cache from DRAM or from a larger cache that is lower in the cache hierarchy.

In addition, the prefetch process <NUM> can also prepare the cache by performing writes that are likely to be needed during the low-power state. In other words, the ACD <NUM> executes write instructions so that the corresponding cache lines are preallocated for use by the ACD <NUM> during the low-power state. It is not necessary for the write instructions of the prefetch process to use actual data. Rather, it is only important that the cache allocate a cache line for the write so that future write instructions by the ACD <NUM> in the low-power state will result in a cache hit and will not wake the memory controller, the memory device, or any data pathways to these components. Therefore, the ACD <NUM> can use dummy data values, e.g., all zeros or random values, when performing the prefetch writes.

The prefetch process <NUM> may also evict other data and instructions from the cache that will not be used during the low-power state. If the cache <NUM> is a system-level cache, the evicted data can be data that was stored on behalf of the AOC <NUM> or other client devices of the system.

In some implementations, the instructions of the prefetch process can be generated by simulating the behavior of the cache <NUM> in response to the ACD <NUM> executing read and write instructions. Generating the instructions of the prefetch process can then include adding prefetch load and prefetch store instructions to the prefetch process until it is sufficiently likely that an actual load and store performed during the low-power state will not result in a cache miss. This simulation technique can also be used to determine how much of the cache to allocate to the ACD <NUM> during the low-power state. For example, if the simulation indicates that there are likely to be cache misses during the low-power state, the system can increase the cache partition size for the ACD <NUM>.

Other cache partitions that are not used by the ACD <NUM> can be powered off before entering the low-power state. Before being powered off, the state of the cache <NUM> can be saved in order to restore the state of those non-ACD cache partitions after exiting the low-power state.

When the prefetch process (<NUM>) is complete, the ACD <NUM> sends a notification to the SPM <NUM>, notifying the SPM <NUM> that the ACD <NUM> is done prepping for SLEEP (<NUM>). In some implementations, the ACD <NUM> also provides identification information for the portion of the cache <NUM> that will be used during the low-power state. For example, the ACD <NUM> can choose one or more cache ways of the cache <NUM> for operation during the low-power state. In some implementations, the SOC dedicates a default portion of the cache <NUM> for the ACD <NUM> operations during the low-power state.

The SPM <NUM> can configure a data pathway for communications between the ACD <NUM> and the selected cache <NUM> during the low-power state (<NUM>). This process involves determining which data pathways are required for communication between the ACD <NUM> and the selected cache. For example, if the selected cache is local to the ACD <NUM>, the SPM <NUM> may only configure a data pathway between those two components. But if the selected cache is a system-level cache, the SPM <NUM> may need to configure additional pathways through other, smaller caches on the way to the system-level cache.

The SPM <NUM> instructs the cache <NUM> to prepare for the low-power state (<NUM>). In response, the cache <NUM> can perform a cache flush (<NUM>) to write non-ACD partitions of cached data into a memory device that allows for retrieval after the low-power state ends. For example, the memory device can be a nonvolatile memory device or a memory device that will remain in retention mode only during the low-power state. In retention mode, the memory device can save power by maintaining previously stored values, but by not supporting the update of the previously stored values.

The cache <NUM> can thus save a state of the non-ACD partitions of the cache <NUM> before the SOC enters the low-power state. The saved state of the cache <NUM> indicates a state of the cache ways before the SOC enters the low-power state. For example, the saved state of the cache <NUM> can indicate a state of the cache ways before the ACD <NUM> initiates the prefetch process <NUM> to prefetch instructions and data into the cache <NUM>. The cache <NUM> can save the cache state into a non-volatile memory or a memory device that will remain in retention mode. Upon exiting the low-power state, the cache <NUM> can restore the saved cache state and overwrite the cache portions, e.g., the cache ways, allocated to the ACD <NUM> during the low-power state. The cache <NUM> sends a notification <NUM> to the SPM <NUM>, indicating that cache <NUM> is ready for the SOC to enter the low-power state.

In response, SPM <NUM> initiates the low power state. For example, the SPM <NUM> can instruct the cache <NUM> to change its RAM power state (<NUM>). This cache <NUM> can then power down portions of the cache that will not be used by the ACD <NUM> during the low-power state (<NUM>). For example, the cache can power down cache ways or entire partitions that are not used by the ACD <NUM>. The cache <NUM> then informs the SPM <NUM> that the power down process is done (<NUM>).

The SPM <NUM> powers down one or more voltage rails (<NUM>) that are to be powered down during the low-power state. The one or more voltage rails generally do not include the voltage rails that are dedicated to the communications between the ACD <NUM> and the prefetched portion of cache <NUM>.

The cache <NUM> can respond back with a verification message verifying that prepping for sleep entry is done (<NUM>). The system can then enter the low-power state. During the low-power state, the ACD <NUM> can process sensor inputs without waking the memory controller or a memory device. Instead, the ACD <NUM> can process all sensor inputs using only the instructions and data that were prefetched into the cache <NUM>.

The SPM <NUM> can also power down other components having a connection with the ACD <NUM>. For example, if the SPM <NUM> can power down one or more voltage rails associated with devices that will be powered down during the low-power state (<NUM>). The SPM <NUM> can also power down the memory controller associated with the memory device, the memory device itself, and one or more communication interfaces, e.g., DDR PHY interfaces, between the memory controller and the memory device. To do so, the SPM <NUM> can communicate the information of the voltage rails that are powered down or information of the components associated with the respective voltage rail, to the HPM <NUM> so that the HPM <NUM> can power down these respective components.

The SOC can also power down any other caches that are lower in the cache hierarchy than the cache selected for the low-power state. For example, as illustrated in <FIG>, the system can power down the SLC <NUM> if the local cache <NUM> was selected for the low-power state. In that case, the HPM <NUM> can save the SLC state before changing the cache power state. Upon exiting the low-power state, the HPM <NUM> can restore the saved SLC state.

<FIG> is a sequence diagram illustrating a sequence of events <NUM> of an example process for exiting a system on chip (SOC) from a low-power state. The example process <NUM> can be performed by the components of the SOC <NUM>.

The SOC may exit the low-power state in response to receiving a service request that requires more resources than what ACD <NUM> can access or provide using only the cache <NUM>. Examples of such service request can include inputs related to any of the sensors of the device, e.g., receiving a phone call, activation of a power-on sensor, or recognizing a voice command. Accordingly, the ACD <NUM> may trigger the exiting process.

For example, the SOC may be part of a user interactive computing device. The user interactive computing device may enter a sleep mode after being idle for <NUM> seconds. The user interactive computing device may include an ACD capable of voice recognition. Once the ACD detects the voice of a user, the ACD can trigger the computing device to exit the sleep mode.

Referring to <FIG>, before the SOC exits a low-power state, the SPM <NUM> may send a notification <NUM> to the ACD <NUM>. Upon receiving the notification <NUM>, the ACD <NUM> prepares for SOC's exit from the low-power state. The ACD <NUM> may send a notification <NUM> to the SPM <NUM>, indicating that the ACD <NUM> is prepared for the SOC to exit the low-power state.

In response, the SPM <NUM> identifies the voltage rails that are to be powered up for exiting the low-power state. In some implementations, the SPM <NUM> restores a record of the voltage rails that were powered down at <NUM> when the SOC entered the low-power state. The SPM <NUM> powers up all or part of the voltage rails whose information were restored from the record.

In some implementations, the ACD <NUM> can provide an identification information of the cache portions that the ACD <NUM> used for prefetching at <NUM> or used during the low-power state of the SOC. Using this identification information, the SPM <NUM> can identify the cache portions that were powered down during the low-power state and can power up one or more voltage rails associated with such cache portions.

In some implementations, the SPM <NUM> powers up all voltage rails associated with the SOC components that need to be operative while the SOC is not in the low-power mode, regardless of the identification information of the components that were operative during the low-power state.

In either case, the SPM <NUM> sends a notification <NUM> to the HPM <NUM>, notifying the HPM <NUM> that the SOC is to be powered up. In response, the HPM <NUM> powers up the respective components. The HPM <NUM> can send a notification <NUM> to the SPM <NUM>, notifying the SPM <NUM> that HPM <NUM> is done with powering up or restoring power of the respective SOC components.

In some implementations, the HPM <NUM> restores the cache power state (<NUM>) that was saved at <NUM>, before the SOC entering the low-power state. In these implementations, if one or more cache ways of the cache <NUM> had no power before the SOC entered the low-power state, the HPM <NUM> keeps the power of these one or more cache ways down when the SOC exits the low-power state.

In addition to the voltage rails, the SPM <NUM> can determine the SOC components that were powered down during the low-power state. For example, the SPM <NUM> may have stored a list of the memory controllers and communication interfaces, e.g., DDR PHY, that were powered down when the SOC entered the low-power state and trigger the HPM <NUM> to power up the respective memory controllers and communication interfaces.

The SPM <NUM> can trigger the cache <NUM> to exit the low-power state, for example, by sending a message to the cache <NUM>. To exit the low-power mode, the cache <NUM> powers up cache RAM(s) (<NUM>).

Upon powering up the respected components, the SOC exits the low-power state and the SOC can process the input that caused exiting of the SOC from the low-power state. The input may be a request submitted by a client device. The SPM <NUM> can notify the client device (<NUM>) that the SOC is ready to process the request.

In some implementations, the cache <NUM> powers up all cache RAM when the SOC exits the low-power state. In some implementations, the cache <NUM> restores a record of the cache RAM that were operative before the SOC entered the low-power state and powers up only the respective cache RAM. For example, the cache <NUM> may have stored such a record in a non-volatile memory before entering the low-power state.

As noted above, in some implementations, the cache <NUM> can save a state of the cache <NUM> before the SOC enters the low-power state. Upon exiting the low-power state, the cache <NUM> can restore the saved state and overwrite the cache portions, e.g., cache ways, allocated to the ACD <NUM> during the low-power state.

When the SOC exits the low-power state, the cache <NUM> can start operating as it was operating before the SOC entered the low-power state. For example, the cache <NUM> can perform a cache allocation algorithm (<NUM>) in order to allocate cache partitions for servicing memory requests after exiting the low-power state.

Similarly, other components of the SOC can start operating as they were operating before the SOC entered the low-power state. For example, the cache <NUM> can start communicating with a memory device, e.g., the memory device <NUM>, to service memory requests (<NUM>) submitted by one or more client devices.

The SOC may exit the low-power state in response to receiving an input that requires using more resources than what the ACD <NUM> and the prefetched portion of the cache <NUM> can provide. The ACD <NUM> may determine that the prefetched information in the cache <NUM> is not sufficient to process a particular input. For example, the ACD <NUM> may receive a fingerprint input from a fingerprint sensor. The ACD <NUM> may determine that the fingerprint does not match any fingerprint patterns stored in the prefetched cache portion. Accordingly, the ACD <NUM> may trigger the SOC to exit from the low-power mode to access a memory that has stored more fingerprint patterns.

In some implementations, there may be no need to exit the whole SOC from the low-power mode; rather, powering up just a portion of the SOC may be enough for processing a particular input that requires more resources than the ACD <NUM> and the prefetched cache portion. In these implementations, the SOC performs a transition in the low-power state, where some, but not all, of the SOC components are powered up for the purpose of processing the particular input.

In the example above, the SOC may determine that providing access to more fingerprint patterns can give the ACD <NUM> the information it needs. Accordingly, the SOC may determine a portion of the cache <NUM> or a non-volatile memory device that has stored the fingerprint patterns, and power up only the respective SLC portion or path to the non-volatile memory device to provide the ACD <NUM> the information that the ACD <NUM> needs for processing the received fingerprint input.

<FIG> is a sequence diagram illustrating a sequence of events <NUM> of an example process for performing a partial power transition from a low-power state of a SOC. The example process <NUM> can be performed by the components of the SOC <NUM>. The SOC performs the transition by powering up one or more additional components of the SOC without fully powering up the entire system. The one or more components are powered up to provide the resources that the ACD <NUM> needs for processing a particular input that the ACD <NUM> cannot process by only using the information prefetched in the cache <NUM>.

While the ACD <NUM> processes inputs to the SOC during the SOC's low-power state (<NUM>), the ACD <NUM> may determine that it needs particular information that the ACD <NUM> did not prefetch into the cache <NUM> before the SOC entered the low-power state. For example, the ACD <NUM> may determine that processing a particular sensor input requires non-prefetched information. The required information can be stored in a downstream cache in the cache hierarchy or in RAM. Thus, the system can power up additional components necessary to obtain the information in order for the ACD <NUM> to continuing processing without waking the entire system.

The ACD <NUM> sends a request to the SPM <NUM>, requesting that the SPM <NUM> enable the data path needed to access to the particular information. The ACD <NUM> can determine the location of the information and request that the data path to the location is enabled (<NUM>).

The SPM <NUM> powers on the data path to the determined location (<NUM>). For example, the SPM <NUM> can power up voltage rails on the required data path. The SPM <NUM> can also communicate with an HPM to power up the respective downstream cache or memory device includes the particular information. The SPM <NUM> can send a confirmation message <NUM> to the ACD <NUM>, acknowledging that the data path and memory portion are powered up.

As part of this process, the ACD <NUM> can make use of the cache <NUM>. Thus, the ACD <NUM> can enable an ACD partition of the cache (<NUM>). This allows the required information to be fetched from the cache <NUM> if it is already stored there or cached if it needs to be fetched from other downstream caches or memory. Enabling the ACD partition can cause the cache <NUM> to perform a partitioning algorithm to determine how many and which cache ways to allocate to the ACD <NUM>. During this time, the ACD can poll the cache <NUM> for completion of the partitioning algorithm (<NUM>).

When the partitioning algorithm is finished, the ACD partition of the cache is ready for use. Thus, the ACD <NUM> can fetch (<NUM>) the required information , which can result in such information being stored in the ACD partition of the cache <NUM>. The ACD use case can then continue in the low-power state (<NUM>). In other words, the system can resume the low-power state without waking all components of the system, e.g., all the client devices. In addition, once the ACD <NUM> is done fetching the particular information, the memory portion from which it was fetched can be powered down again and join the other inactive components of the SOC in the low-power state.

In the present disclosure, any of the notifications or communication messages sent between any two components may be in form of an interrupt or be provided in response to a polling. For example, a first device may send a message to a second device in response to receiving a poll from the second device inquiring whether a job has been performed by the first device. Alternatively, the first device may send the message to the second device once the first device finishes the job, regardless of whether the second device sent a poll.

<FIG> is a diagram of an example computing device <NUM> that includes a low-power, ambient computing system <NUM>. The ambient computing system <NUM> is an example of a system can perform the functionalities of the ambient computing device described above. The functionality described below uses two other example computing systems, a main CPU cluster <NUM> and a main machine learning (ML) engine <NUM>. Each of these two components can function as one of the client devices 110a-n of the SOC <NUM> described above with reference to <FIG>. In other words, the ambient computing system <NUM>, the main CPU cluster <NUM>, and the main ML engine <NUM> can all be integrated into the same SOC and share a same system-level cache, e.g., the SLC <NUM>.

The example device <NUM> can include a system implemented in an any appropriate computing device, e.g., a smart phone, a smart watch, a fitness tracker, a personal digital assistant, an electronic tablet, a laptop, to name just a few examples. The system of computing device <NUM> can be used so that the computing device <NUM> can remain in a low-power state yet continually monitor and respond to inputs from the environment by sequentially waking appropriate processing components of the system. In this specification, the terms wake and activate will be used to mean supplying an increased amount of power to a particular processing component or other electronic circuitry. The system may or may not have been supplying power to a processing component or other circuitry that is being awoken or activated. In other words, a component being awoken or activated may or may not have been completely powered down previously. Waking or activating a processing component can result in the processing component performing a boot process and causing instructions and data for the processing component to be loaded into random-access memory. Alternatively or in addition, waking or activating a processing component can include resuming from a previously suspended state.

The one or more components of the computing device <NUM> can be implemented on a system on a chip (SoC) within the computing device. An SoC can be an integrated circuit that includes each component of the system on a single silicon substrate or on multiple interconnected dies, e.g., using silicon interposers, stacked dies, or interconnect bridges. Other components of the computing device, including a main CPU cluster <NUM>, can be implemented on the same or on a separate die. The computing device <NUM> may include components, including the sensors <NUM>, one or more displays, a battery, and other components, that are separate from and independent of the SoC, and may for example be mounted on a common housing.

Briefly, and as described in further detail below, the device <NUM> includes a number of peripheral sensors <NUM> configured to generate sensor signals based on input from the environment of the computing device. The device <NUM> includes a control subsystem <NUM> for controlling the supply of power and sensor signals to components in the system. And the device <NUM> includes a processing subsystem <NUM> for processing sensor signals and generating outputs.

The device <NUM> also includes a main CPU cluster <NUM>. The main CPU cluster <NUM> is a component of the computing device that includes one or more general-purpose processors that are separate from the devices in the processing subsystem <NUM>. The processors of the main CPU cluster <NUM> generally have more computing power than any of the devices in the processing subsystem <NUM>, and therefore, the processors of the main CPU cluster <NUM> may also consume more power than any of the devices in the processing subsystem <NUM>.

The device <NUM> can also optionally include a main machine learning (ML) engine <NUM>. The main ML engine <NUM> is a special-purpose processing device that is configured to perform inference passes through one or more machine learning models. Each inference pass uses inputs and learned parameter values of a machine learning model to generate one or more outputs predicted by the learned model. The main ML engine <NUM> can include one or more compute tiles. In general, a compute tile is a self-contained computational component configured to execute a set of computations independently. The tiles of the main ML engine <NUM> can be arranged in a network and programmed so that each tile of the main ML engine <NUM> is configured to perform operations of one portion of an inference pass through the machine learning model. For example, if the machine learning model is a neural network, each tile in the main ML engine <NUM> can be configured to compute the computations of one layer of the neural network. A suitable machine learning engine having multiple compute tiles is described in <CIT>. The main ML engine <NUM> also provides higher performance computing power than any of the devices in the processing subsystem <NUM> of the ambient computing system <NUM>. Therefore, the main ML engine <NUM> also consumes more power than any of the devices in the processing subsystem <NUM>.

The processing subsystem <NUM> includes an ambient machine learning engine <NUM>. The ambient ML engine <NUM> is also a special-purpose processing device that is configured to perform inference passes through one or more machine learning models. When the device <NUM> includes both a main ML engine <NUM> and an ambient ML engine <NUM>, the ambient ML engine <NUM> has fewer compute tiles and therefore has less processing power than the main ML engine <NUM> and consumes less power than the main ML engine <NUM>. For example, the ambient ML engine <NUM> can be implemented as one or two tiles, whereas the main ML engine <NUM> can have <NUM>-<NUM> or more interconnected tiles.

Although not depicted, the computing device <NUM> can also include one or more other components commonly found on such computing devices, e.g., a display, a modem, a graphics processing unit, a display processor, or a special-purpose image processor, to name just a few examples. These components can be powered down during the low-power states described below and activated if the system determines that the sensor signals match an application requiring their activation.

The device <NUM> includes a number of peripheral sensors <NUM>. The peripheral sensors <NUM> include one or more audio sensors <NUM>, one or more radar sensors <NUM>, one or more touch sensors <NUM>, a Global Positioning System (GPS) sensor <NUM>, and an accelerometer <NUM>. The system can include additional, fewer, or alternative peripheral sensors. For example, the system can include a Wi-Fi signal detector, a cellular signal detector, a barometer, a thermometer, a magnetometer, or other types of peripheral sensors.

The peripheral sensors <NUM> can be devices configured to generate sensor signals in response to environmental inputs. The one or more audio sensors <NUM>, e.g., microphones, can generate audio signals based on sounds in the environment. For example, the audio sensors <NUM> can generate audio signals corresponding to human speech. The one or more radar sensors <NUM> can detect radar signals based on reflected radio waves emitted by a transmitter of the computing device. Variations in reflected radio waves can indicate movement in the environment. For example, the radar sensors <NUM> can generate radar signals that are received due to being reflected off of the user, e.g., when the user is making gestures in proximity to the computing device. Similarly, the one or more touch sensors <NUM> can generate signals due to touch gestures made by a user of the computing device on a presence-sensitive or pressure-sensitive interface of the device. The GPS sensor <NUM> can generate signals in response to received location data communications. And the accelerometer <NUM> can generate signals due to accelerations experienced by the computing device. In this specification, whenever sensor signals are described as being inputs to other processing components, the inputs can be analog electrical signals generated by the sensors themselves, digital representations of the sensor signals, or processed digital representations of the sensor signals that represent one or more properties of the original signals. The peripheral sensors of the computing device <NUM> can also include an inertial measurement sensor, a barometer, a specific absorption rate proximity sensors, and WiFi network name sensors, to name just a few other examples.

The ambient computing system <NUM> includes one or more peripheral interfaces <NUM>. The peripheral interfaces <NUM> can be a component of the computing device <NUM> that is powered on even when the device is in its lowest power state. The peripheral interfaces <NUM> can include any appropriate peripheral interface for converting inputs received from the peripheral sensors <NUM> into sensor signals to be used by the ambient computing system <NUM>. For example, the peripheral interfaces <NUM> can include a pulse density modulation (PDM) interface, an inter-IC sound (I2S) interface, an inter-integrated circuit (I2C) interface, an I3C interface, a time division multiplexed (TDM) interface, and a serial peripheral interface (SPI), to name just a few examples.

Each of the peripheral interfaces <NUM> is configured to generate a respective interrupt upon detecting an environmental input. In general, each interrupt can identify a source of the sensor data, e.g., an identifier of a peripheral interface or sensor responsible for the interrupt. The interrupts are received and processed by one or more interrupt controllers <NUM>. For example, upon receiving an interrupt, the interrupt controller <NUM> can wake a power control unit (PCU) <NUM>, which includes a power management unit (PMU) <NUM> and a clock control unit <NUM>. The PMU <NUM> can control which components of the device <NUM> receive power and how much power each component receives. The clock control unit <NUM> can control the frequency at which the components of the device <NUM> operate. In some implementations, each processing component has a different clock frequency that is a multiple or a fraction of a base clock frequency. By having a clock frequency that is a multiple or a fraction of a base clock frequency, each processing component can more efficiently exchange signals with other processing components.

Upon receiving an interrupt, the PCU <NUM> can determine based on the source of the interrupt which other components of the ambient computing system <NUM> should be activated in order to further process the sensor signals causing the interrupt. In order to provide processing support for such components, the PCU <NUM> can wake the static random access memory (SRAM) <NUM> and the system communications fabric. The fabric is a communications subsystem that communicatively couples the internal components of the ambient computing system <NUM>, their communications to external components, or some combination of these. The fabric can include any appropriate combination of communications hardware, e.g., buses or dedicated interconnect circuitry.

The static random access memory (SRAM) <NUM> can be a general purpose random-access memory device that can be shared by multiple processing components of the processing subsystem <NUM>. For example, the SRAM <NUM> can store sensor signals, processor instructions and data, system outputs, and other data, e.g., neural network parameters of neural network models that are or will be implemented by the ambient ML engine <NUM>. In general, an SRAM is distinguishable from dynamic random-access memory (DRAM) in that an SRAM need not be periodically refreshed. As described in more detail below, the SRAM <NUM> is accessible to the processing components in the processing subsystem <NUM> directly or through one or more DMA controllers. In some implementations, the SRAM <NUM> includes multiple banks, which can each store substantially similar amounts of data, e.g., <NUM>, <NUM>, or <NUM> MB each. In addition, each individual bank can include multiple blocks that can be individually powered-down when entering the low-power state. By carefully sequencing the order that the blocks are powered-down amongst the four banks, the SRAM address space can remain contiguous.

When the PCU <NUM> wakes the SRAM <NUM>, the PCU <NUM> can wake fewer than all of the blocks or all of the memory banks of the SRAM <NUM>. The PCU <NUM> can instead wake only a number of blocks that is sufficient for the next component of the processing subsystem <NUM> to determine whether to further escalate powering up of components of the device <NUM>.

The PCU <NUM> can also supply different power levels to different blocks of the SRAM <NUM>. For example, in the monitoring power state, the PMU <NUM> can supply a lower, retention voltage to the entire SRAM <NUM> to reduce its power consumption. The PMU <NUM> can also supply the retention voltage to the SRAM <NUM> if no processing components need to access to the SRAM <NUM>. In the processing power state, the PMU <NUM> can provide normal voltage to all or portions of the SRAM <NUM> and lowered or no voltage to other parts of the SRAM <NUM>.

During the process of handling an interrupt, the ambient computing system <NUM> can also wake one or more DMA controllers <NUM>. The DMA controllers <NUM> can manage DMA pathways that allow higher data bandwidth for incoming sensor signals. For example, a DMA controller <NUM> can be used to continuously stream audio data from a microphone into the SRAM <NUM> for access by processing components in the processing subsystem <NUM>. Conversely, a DMA controller can also be used to continuously stream audio data stored in the SRAM <NUM> for output as sound through one or more speakers. The DMA controllers <NUM> can also be used to stream any appropriate sensor data into the SRAM <NUM>, but using programmed IO may be computationally cheaper than activating a DMA controller for small quantities of data. Thus, the ambient computing system <NUM> can activate and use the DMA controllers <NUM> for relatively high-bandwidth sensor data, e.g., audio data and radar data, and can used programmed IO for other types of sensor data.

After preparing the fabric and the SRAM <NUM>, the PCU <NUM> can then use the interrupts to determine which other component of the processing subsystem <NUM> to wake. For example, the PMU <NUM> can control whether power is provided to the low-power CPU <NUM>, the low-power DSP <NUM>, or other components of the processing subsystem <NUM> depending on which of one or more sensors generated an interrupt. In some implementations, the peripheral interfaces <NUM> and the components of the control subsystem <NUM> are the only components of the device <NUM> that are powered on in a monitoring power state, which is a power state in which the system is waiting to receive interrupts due to environmental inputs to the computing device.

The processing components of the processing subsystem <NUM> include a low-power CPU <NUM>, an ambient ML engine <NUM>, a low-power DSP <NUM>, and a high-power DSP <NUM>. In some implementations, the processing subsystem has multiple instances of one or more of these components, e.g., multiple low-power DSPs or multiple high-power DSPs. For example, the processing subsystem <NUM> can have one high-power DSP that is dedicated to processing audio signals and a separate high-power DSP that is dedicated to processing radar signals. Alternatively or in addition, the processing subsystem <NUM> can have a high-power DSP that is dedicated to processing image data.

When performing the prefetch process describe above with reference to <FIG>, the ambient computing system <NUM> can issue prefetch load and store instructions for any appropriate combination of the devices in the processing subsystem <NUM>. In other words, the ambient computing system <NUM> can prefetch instructions for the low-power CPU, the ambient ML engine <NUM>, the low-power DSP <NUM>, the high-power DSP <NUM>, or some combination of these. In some implementations, the ambient computing system <NUM> only prefetches instructions for components that consume the least amount of power. For example, the ambient computing system <NUM> can prefetch instructions for only the low-power CPU <NUM> and the low-power DSP <NUM>. This will allow the system to process most sensor signals during the low-power state without waking the memory controller or the memory device. If additional processing is needed, the system can fetch such instructions using the DMA controllers <NUM> after waking the memory controller and memory device.

The prefetch process effectively extends the size of memory available to the ambient computing system <NUM> in the low-power state. In other words, instead of only being limited to the amount of internal SRAM <NUM> during the low-power state, the ambient computing system <NUM> can also have access to SRAM of the cache used for the prefetch process. This effective extends the available memory to be at least the same of the internal SRAM <NUM> plus the size of the cache allocated to the ambient computing system <NUM>.

In the monitoring power state, the processing components in the processing subsystem <NUM> can be maintained in a retention mode. The PCU <NUM> can maintain a component in retention mode by reducing or eliminating power that is provided to the component. For example, in the retention mode, the PCU <NUM> can supply a processing component with just enough power to maintain register states, but not enough power to process data in the registers.

The low-power CPU <NUM> can be a general-purpose programmable processor that includes registers, control circuitry, and an arithmetic logic unit (ALU). In general, the low-power CPU <NUM> consumes less power than the main CPU cluster <NUM> of the computing device, and may contain fewer processing cores. In some implementations, the low-power CPU <NUM> is primarily a scalar processor that operates on single instructions and single data inputs.

The low-power CPU <NUM> can receive interrupts and sensor signals when the system enters the processing power state. Based on the type of sensor signals the lower-power CPU <NUM> receives and based on the properties of those sensor signals, the low-power CPU <NUM> can determine that other components of the system should be activated, e.g., the communications fabric, the DMA controllers <NUM>, the SRAM <NUM>, or some combination of these. After activating these components, the low-power CPU <NUM> can optionally return to a non-operational state.

The low-power CPU <NUM> can provide the sensor signals, or a processed version thereof, to the ambient ML engine <NUM> for further interpretation. For example, if the low-power CPU <NUM> receives sensor signals corresponding to accelerometer input, the low-power CPU <NUM> can determine that the ambient ML engine <NUM> should further process the sensor signals. For example, the ambient ML engine <NUM> can then further process the sensor signals to determine that the signals represent walking, jogging, biking, falling, or traveling in a car.

The low-power CPU <NUM> can also bypass the ambient ML engine <NUM> for some signals. If, for example, the low-power CPU <NUM> receives a sensor signal corresponding to a simple touch input on a touch interface of the computing device, the low-power CPU <NUM> can process the touch input without the aid of other processing components, e.g., by causing the display of the computing device to be turned on by the main CPU cluster <NUM> or a graphics processor. The low-power CPU <NUM> can also determine that the main CPU cluster <NUM> of the computing device, or another component of the computing device outside of the device <NUM>, should further process certain sensor signals. The low-power CPU <NUM> can make such a determination, for example, if it determines that no other processing components in the device <NUM> can properly process the sensor signals.

One task of the ambient ML engine <NUM> is to use sensor signals to perform an inference pass over a model to generate an output that may trigger waking other processing components to further process the sensor signals. In other words, the ambient ML engine <NUM> can receive sensor signals, or a processed version thereof generated by the low-power CPU <NUM> or another processing component, and the ambient ML engine <NUM> can generate an output that represents which other processing components should further process the sensor signals. The output generated by the ambient ML engine <NUM> can explicitly specify a combination of processing component IDs or an identifier of an enumerated power state or the output can be a representation of a power state that is interpreted by a low-power processing component, e.g., the low-power CPU or the low-power DSP, in order to identify other higher-power processing components that should process the sensor signals. As part of this process, the low-power processing component can explicitly or implicitly determine whether any other processing is required. For example, the low-power processing component can determine, based on the output of the machine learning engine, that no further processing is required and that the system can transition back to the monitoring power state.

In the lowest-level monitoring power state, the PCU <NUM> can keep the ambient ML engine <NUM> in a low-power state or powered down completely. In the processing power state, the PCU <NUM> may or may not provide power to the ambient ML engine <NUM> depending on what sensor signals are available at the peripheral interfaces <NUM> and how the low-power CPU <NUM> or the low-power DSP <NUM> interpret the signals. In some implementations, the low-power DSP <NUM> or the low-power CPU <NUM> interpret the signals to instruct the PCU <NUM> to provide power for an additional, intermediate power state, in which the ambient ML engine <NUM> is also powered on for the inference pass, but no other high-power processing components are yet powered on.

The ambient ML engine <NUM> can also implement other machine learning models for processing sensor signals. For example, the ambient ML engine <NUM> can implement a simplified speech recognition model that allows the ambient ML engine <NUM> to recognize some voice-based commands. Because the model may be installed on a mobile computing device with limited memory capacity, the number of recognized commands may be smaller than for online voice recognition processes.

The ambient ML engine <NUM> can alternatively or in addition implement a machine learning model that provides on-chip automatic speech recognition. In other words, the ambient ML engine <NUM> can perform inference passes through the model in order to generate a live transcription of speech captured in the audio signals.

As another example, the ambient ML engine <NUM> can implement a text-to-speech model that generates audio output signals from particular text inputs, in which the audio output signals can be interpreted as human speech in a particular language by users. In some implementations, the device <NUM> can use a speech recognition model and the text-to-speech model in tandem to provide a low-power dialogue engine. For example, after the ambient ML engine <NUM> recognizes a particular command, the low-power CPU <NUM> can take particular actions to effectuate the command and also to provide a particular text response back to the ambient ML engine <NUM>. The ambient ML engine <NUM> can then use the text-to-speech model to generate an audio output representing a response to the initial command. In some implementations, the entire data flow of speech recognition, action execution, and text-to-speech response can be performed without ever waking up the main CPU cluster <NUM> of the device.

For example, if a user provides the voice command, "louder," the ambient ML engine <NUM> can generate an output representing that the audio signals corresponding to a voice command to increase the volume of music being played by the device. The machine-learning engine <NUM> can provide the output to the low-power CPU <NUM>, which can effectuate the command by issuing a signal to one or more integrated speaker subsystems. The low-power CPU <NUM> can then provide a text response, "volume at level <NUM>," to the ambient ML engine <NUM>. The ambient ML engine <NUM> can then process the text response with the text-to-speech model to generate an audio output, which the device can play over the one or more integrated speaker subsystems. Thus, the ambient computing system <NUM> process the entire dialogue sequence without waking up the main CPU of the device.

The ambient ML engine <NUM> can also implement any of a variety of other models. The ambient ML engine <NUM> can also implement a gesture recognition model that interprets features of hand gestures made by a user of the computing device. For example, the inputs to the model can be processed radar signals received by the computing device, and the output of the model can be predictions of gestures that the user has made. Each hand gesture can correspond to a particular command, and the ambient ML engine <NUM> can provide the output to the low-power CPU <NUM>, or another processing component, for further action.

The ambient ML engine <NUM> can include one or more memory banks for storing model parameters and other model configuration information. For example, the machine-learning engine <NUM> can store data representing neural network connections and neural network parameters. The ambient ML engine <NUM> can include one or more multiply accumulate (MAC) units and one or more sum registers for computing neural network activations or other neural network layer outputs, and a controller for controlling data exchange between the memory banks and the MAC units. The ambient ML engine <NUM> can also include instruction memory, direct memory access paths, registers, and other processing components. In some implementations, the ambient ML engine <NUM> is a machine learning compute tile that is configured to accelerate the computation of machine learning inference passes.

The low-power DSP <NUM> and the high-power DSP <NUM> are special-purpose processors configured for efficient decoding and processing of highly-vectorized signals. The processing subsystem <NUM> can include a variety of DSPs that are designed for different purposes. For example, the processing subsystem <NUM> can include a DSP that is configured to process radar signals, a DSP that is configured to process audio signals, a DSP that is configured to perform dataplane algorithms, a DSP that is configured to process wireless communications signals, and a DSP that is configured to process GPS signals, to name just a few examples.

As described above, the low-power DSP <NUM> can perform the initial interpretation of sensor signals from the control subsystem <NUM>. The low-power DSP <NUM> can also perform other signal processing tasks as well. In general, high-power DSPs consume higher levels of power than low-power DSPs because they have more active registers, they access and process more data in parallel, because they rely more heavily on memory operations, or some combination of these.

The control subsystem <NUM> can also include a timer <NUM>, which is an electronic timer that can detect system malfunctions and resolve those malfunctions. During normal operation, the system can regularly reset the timer <NUM> to prevent the timer <NUM> from timing out. If, e.g., due to a hardware fault or a program error, the system fails to reset a timer, the timer will elapse and generate a timeout signal. The timeout signal can be used to initiate one or more corrective actions. A corrective action can include placing the system in a safe state and restoring normal system operation.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification.

The present embodiments in includes systems and methods to enter the system in a low-power state. The system includes multiple integrated client devices, including an ambient computing device that is configured to control operation of the system while the system is in a low-power state, a memory controller configured to read data from a memory device for consumption by the client devices, and a cache configured to cache data requests to the memory controller issued by the ambient computing device. The system is configured to enter the low-power state by performing operations including performing, by the ambient computing device, a prefetch process that populates the cache with prefetched instructions and data required for the ambient computing device to process inputs to the system while in the low-power state, and entering the low-power state. In the low-power state, the ambient computing device is configured to process inputs to the system using the prefetched instructions and data stored in the cache.

In some embodiments, the cache is a system-level cache configured to cache data requests to the memory controller for each of the multiple integrated client devices. In some embodiments, is a local cache that is configured to service memory requests only for the ambient computing device and not for any of the other integrated client devices.

Performing the prefetch process can increase an amount of SRAM memory available to the ambient computing device during the low-power state. In some embodiments, the memory available to the ambient computing device during the low-power state includes an internal SRAM of the ambient computing device and SRAM of the cache.

In some embodiments, in the low-power state, the ambient computing device is configured to process the inputs to the computing device using the prefetched instructions and data without waking the memory device or waking the memory controller.

Performing the prefetch process can include issuing prefetch store memory requests that allocate cache lines in the cache for data that the ambient computing device will be store during the low-power state. The prefetch may store memory requests each write dummy data to the cache.

In some embodiments, the system includes a hierarchy of multiple caches including a system-level cache configured to cache data requests to the memory controller for each of the multiple integrated client devices. Entering the low-power state can include determining a memory size for a low-power procedure to be executed by the ambient computing device in the low-power state, determining, based on the memory size for the low-power procedure to be executed by the ambient computing device in the low-power state, which cache in the hierarchy of multiple caches should be used to store the prefetched instructions and data required for the ambient computing device to process inputs to the system while in the low-power state, and selecting the cache from among the multiple caches in the hierarchy based on the determination.

Entering the low-power state can include powering down all caches that are lower in the hierarchy of caches than the selected cache. Entering the low-power state can include powering down all data paths to the caches that are lower in the hierarchy of caches than the selected cache. Powering down all caches that are lower in the hierarchy of caches than the selected cache can include powering down the system-level cache.

A computer program which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

The processes and logic flows described in this specification can be performed by special purpose logic circuitry, e.g., an FPGA or an ASIC, or by a combination of special purpose logic circuitry and one or more programmed computers.

Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magnetooptical disks; and CD-ROM and DVD-ROM disks.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a host device having a display device, e.g., an electronic display, for displaying information to the user and a keyboard and pointing device, e.g., a mouse, trackball, or a presence sensitive display or other surface by which the user can provide input to the host device. In addition, a host device can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's device in response to requests received from the web browser. Also, a host device can interact with a user by sending text messages or other forms of message to a personal device, e.g., a smartphone, running a messaging application, and receiving responsive messages from the user in return.

Claim 1:
A system comprising:
multiple integrated client devices (110a-n), including an ambient computing device (<NUM>) that is configured to control operation of the system while the system is in a low-power state;
a memory controller (<NUM>) configured to read data from a memory device (<NUM>) for consumption by the client devices; and
a cache (<NUM>) configured to cache data requests to the memory controller issued by the ambient computing device, wherein the cache is a system-level cache configured to cache data requests to the memory controller for each of the multiple integrated client devices,
wherein the system is configured to enter the low-power state by performing operations comprising:
performing, by the ambient computing device, a prefetch process that populates the cache with prefetched instructions and data required for the ambient computing device to process inputs to the system while in the low-power state, wherein performing the prefetch process comprises issuing prefetch store memory requests that allocate cache lines in the cache for data that the ambient computing device will store during the low-power state, wherein the prefetch store memory requests each write dummy data to the cache; and
entering the low-power state, wherein in the low-power state, the ambient computing device is configured to process inputs to the system using the prefetched instructions and data stored in the cache.