Last level cache access during non-C state self-refresh

Abstract

The data processor includes a data fabric, a memory controller, a last level cache, and a traffic monitor. The data fabric routes requests between a plurality of requesters and a plurality of responders. The memory controller accesses the volatile memory. The last level cache is coupled between the memory controller and the data fabric. The traffic monitor is coupled to the last level cache and is operable to monitor traffic between the last level cache and the memory controller and, based on detection of an idle state in the monitored traffic, cause the memory controller to instruct the volatile memory to enter a self-refresh mode while the last level cache maintains an operating power state and responds to cache hits via the data fabric.

Description

[Background technology]

[0001] Computer systems utilize a variety of peripheral components for different input / output and communication functions. A system-on-a-chip (SOC) combines data processing circuitry, such as a central processing unit (CPU) core and a graphics processing unit (GPU), with peripheral controllers and memory interfaces on a single integrated circuit chip, and is well suited for portable, battery-powered operation. For example, a SOC may incorporate a display controller, an image signal processor (ISP), and other peripheral controllers on the SOC to enable the input and output of information to and from the computer system. In such large, complex SOCs, devices typically transfer data between resources, such as memory, by routing accesses through a large on-chip routing circuitry or "data fabric."

[0002] The diversity of circuits on a typical SOC presents a problem for implementing power saving modes. Many of the peripheral controllers operate in real time, are isochronous, and require a certain amount of bandwidth from the shared memory resource over a period of time. This requirement has prevented the realization of chip-wide low power states. For example, when the CPU cores and GPU are idle, the peripheral controllers may still be active and receiving data that can be stored in buffers, but the data must be sent to memory before the buffers are full.

[0003] On the other hand, CPUs and GPUs tend to have periods of high activity separated by idle periods. If the idle periods are expected to be short, the data fabric, memory controllers and memory will typically remain active and therefore can quickly service requests from peripheral controllers to transfer more data. [Brief description of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram of an Advanced Configuration and Power Interface (ACPI) model for computer system power states as known in the prior art. [Diagram 2] 1 is a block diagram of a data processing system according to some embodiments. [Diagram 3] 3 illustrates a portion of a system-on-chip including an implementation of the last level cache of FIG. 2 in accordance with some embodiments. [Figure 4] 3 is a table showing the correspondence between the idle states of different data fabrics and the states of other components of the SOC of FIG. 2. [Diagram 5] 4 is a flowchart of a process for operating a memory system including a last level cache having a traffic monitor, such as the traffic monitor of FIG. 3, according to some embodiments. [Figure 6] 6 is a flowchart 600 of a process for leaving a self-refresh state while the memory controller is not yet in a C-state, according to some embodiments. [Figure 7] 1 is a flowchart of a process for exiting a C-state in the data fabric, including delayed C-state exit in a memory controller, in accordance with some embodiments. [Figure 8] 1 is a flowchart of a process for entering a data fabric C-state in a memory controller that is in a preemptive C-state according to some embodiments. [Figure 9] 1 is a flowchart of a process for training a successful traffic monitor according to some embodiments. [Figure 10] 1 is a flowchart of a process for handling save / restore traffic from a specified system module in a last level cache according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] In the following description, the use of the same reference numbers in different figures indicates similar or identical items. Unless otherwise noted, the word "coupled" and its related verb forms include both direct and indirect electrical connections by means well known in the art, and unless otherwise noted, any description of a direct connection also refers to alternative embodiments using a suitable form of indirect electrical connection.

[0006] The data processor includes a data fabric, a memory controller, a last level cache, and a traffic monitor. The data fabric routes requests between a plurality of requesters and a plurality of responders. The memory controller is for accessing a volatile memory. The last level cache is coupled between the memory controller and the data fabric. The traffic monitor is coupled to the last level cache and is operable to monitor traffic between the last level cache and the memory controller and, upon detection of an idle state in the monitored traffic, cause the memory controller to instruct the volatile memory to enter a self-refresh mode while the last level cache maintains an operating power state and responds to cache hits via the data fabric.

[0007] The method includes routing requests between a plurality of requesters and a plurality of responders in a data fabric of a data processor. The method includes monitoring traffic to a volatile memory at a last level cache coupled to the data fabric. Based on detecting an idle state in the monitored traffic, the method includes causing a memory controller to instruct the volatile memory to enter a self-refresh mode while the last level cache maintains an operating power state and responds to cache hits via the data fabric.

[0008] A traffic monitor for the last level cache includes a traffic monitor circuit that monitors traffic between the last level cache and a memory controller and, based on detecting an idle state in the monitored traffic, causes the memory controller to instruct the volatile memory to enter a self-refresh mode. The last level cache maintains an operating power state while the volatile memory is in the self-refresh mode and responds to cache hits via the data fabric.

[0009] 1 is a block diagram of an Advanced Configuration and Power Interface (ACPI) model for computer system power states 100 as known in the prior art. The ACPI model 100 is part of the ACPI specification developed by various computer system, software and component vendors to establish an industry standard interface for device configuration and power management of both devices and entire computer systems.

[0010] The ACPI model 100 defines a hierarchy of states for various devices within a computer system organized around a set of global system states including a G0 (S0) state 110, known as a "Working" state, a G1 state 120, known as a "Sleeping" state, a G2 (S5) state 130, known as a "Soft Off" state, and a G3 state 140, known as a "Mechanical Off" state. Additionally, the ACPI model 100 includes a state 150, known as a "Legacy" state, that corresponds to existing Basic Input / Output System (BIOS) power management interfaces that correspond to operation of the BIOS before an ACPI-compatible operating system is loaded. The ACPI model 100 also defines a set of Central Processing Unit (CPU) states 160 and a set of device states or "D" states 170 for devices such as modems, hard disk drives (HDDs), and compact disc read-only memories (CDROMs).

[0011] The ACPI model 100 is well known and most aspects will not be described further, however certain aspects relating to central processing unit power states are relevant to understanding the present disclosure and will be described here.

[0012] In the G0 (S0) state 110, peripheral devices can dynamically change their power states and a user can select various performance and power characteristics of the system through a user interface so that software systems can optimize the computer for desired performance or battery life. In this state, the computer system responds in real time to external events. From the G0 (S0) state, the computer system can transition to the G1 state 120, which includes various power-saving sleep states or "S states," under the control of system firmware, such as the BIOS, and return to an operational state in response to a wake event.

[0013] In the G0(S0) state 110, the CPU can operate in a variety of states including a "C0" state, where the processor executes instructions, and various low power or "idle" states, labeled "C1" through "Cn." In the C0 state, the CPU can operate in various performance states or "P-states," and the operating frequency can be increased or throttled to support the needs of currently running application programs using dynamic voltage and frequency scaling (DVFS). In the idle states C1 through Cn, the CPU is idle and does not execute instructions, but has various combinations of power consumption and wake-up latency, with lower power consumption being traded off for longer wake-up latency. Thus, for example, the C1 state has the highest power consumption but the shortest wake-up latency, while the Cn state has the lowest power consumption but the longest wake-up latency.

[0014] Using ACPI Model 100, each particular computer system can support different combinations of P-states and C-states appropriate to the application environment. Achieving a better tradeoff between reduced power consumption and low latency in ways not specified by ACPI Model 100 remains a desirable goal.

[0015] 2 is a block diagram of a data processing system 200, according to some embodiments. Data processing system 200 includes a data processor in the form of a SOC 210 and external memory in the form of low power double data rate synchronous dynamic random access memories (LPDDRx SDRAMs) 273 and 283. Many other components of an actual data processing system would typically be present, but are not relevant to understanding the present disclosure and are not shown in FIG. 2 for ease of illustration.

[0016] SOC 210 generally includes system management unit (SMU) 211, system management network (SMN) 212, central processing unit (CPU) core complex 220, labeled "CCX", graphics controller 230, labeled "GFX", real-time client subsystem 240, memory / client subsystem 250, data fabric 260, memory channels 270 and 280, peripheral component interface express (PCIe) subsystem 290, and last level cache 300, labeled "LLC". As will be appreciated by those skilled in the art, SOC 210 may not have all of these elements present in all embodiments and may further have additional elements included therein.

[0017] SMU 211 is bidirectionally connected to the major components in SOC 210 via SMN 212. SMN 212 forms the control fabric for SOC 210. SMU 211 is a local controller that controls the operation of resources on SOC 210 and synchronizes communication between them. SMU 211 manages the power-up sequencing of the various processors on SOC 210 and controls multiple off-chip devices via reset, enable, and other signals. SMU 211 includes one or more clock sources (not shown), such as a phase locked loop (PLL), to provide clock signals to each of the components of SOC 210. SMU 211 can also receive measured power consumption values ​​from the CPU cores in CPU core complex 220 and graphics controller 230 to manage power for the various processors and other functional blocks and determine the appropriate state.

[0018] CPU core complex 220 includes a set of CPU cores, each of which is bidirectionally connected to SMU 211 via SMN 212. Each CPU core may be a single core that shares only a last-level cache with the other CPU cores, or may be combined with some, but not all, of the other cores in a cluster.

[0019] Graphics controller 230 is bidirectionally connected to SMU 211 via SMN 212. Graphics controller 230 is a high-performance graphics processing unit capable of performing graphics operations such as vertex processing, fragment processing, shading, and texture blending in a highly integrated and parallel manner. Graphics controller 230 requires periodic access to external memory to perform its operations. In the embodiment shown in FIG. 2, graphics controller 230 shares a common memory subsystem with the CPU cores in CPU core complex 220 in what is known as a unified memory architecture. SOC 210 is also referred to as an accelerated processing unit (APU) because it includes both a CPU and a GPU.

[0020] The real-time client subsystem 240 includes a set of real-time clients, such as representative real-time clients 242 and 243, and a memory management hub 241, labeled "MM HUB." Each real-time client is bidirectionally connected to the SMU 211 via the SMN 212 and to the memory management hub 241. A real-time client may be any type of peripheral controller that requires the periodic movement of data, such as an image signal processor (ISP), an audio coder-decoder (CODEC), a display controller that renders and rasterizes objects generated by the graphics controller 230 for display on a monitor, etc.

[0021] Memory / client subsystem 250 includes a set of memory elements or peripheral controllers, such as representative memory / client devices 252 and 253, and a system and input / output hub, labeled "SYSHUB / IOHUB," 251. Each memory / client device is bidirectionally connected to SMU 211 via SMN 212, and bidirectionally connected to system and input / output hub 251. A memory / client device is a circuit that stores or requires access to data on a non-periodic basis, such as non-volatile memory, static random access memory (SRAM), external disk controllers such as a Serial Advanced Technology Attachment (SATA) interface controller, a Universal Serial Bus (USB) controller, a system management hub, etc.

[0022] Data fabric 260 is the interconnect that controls the flow of traffic in SOC 210. Data fabric 260 is bidirectionally connected to SMU 211 via SMN 212, and bidirectionally connected to CPU core complex 220, graphics controller 230, memory management hub 241, and system and I / O hub 251. Data fabric 260 includes a crossbar switch for routing memory mapped access requests and responses between any of the various devices in SOC 210. Data fabric also includes a system memory map defined by the basic input / output system (BIOS) and buffers for each virtual connection to determine the destination of memory accesses based on the system configuration.

[0023] Memory channels 270 and 280 are circuits that control the transfer of data between external memories 273 and 283. Memory channel 270 is formed by memory controller 271 and physical interface circuit 272, labeled "PHY", connected to external memory 273. Memory controller 271 is bidirectionally connected to SMU 211 via SMN 212 and has an upstream port and a downstream port. Physical interface circuit 272 has an upstream port bidirectionally connected to memory controller 271 and a downstream port bidirectionally connected to external memory 273. Similarly, memory channel 280 is formed by memory controller 281 and physical interface circuit 282 connected to external memory 283. Memory controller 281 is bidirectionally connected to SMU 211 via SMN 212 and has an upstream port bidirectionally connected to data fabric 260 and a downstream port. The physical interface circuit 282 has an upstream port that is bidirectionally connected to the memory controller 281 , and a downstream port that is bidirectionally connected to the external memory 283 .

[0024] Peripheral Component Interface Express (PCIe) subsystem 290 includes PCIe controller 291 and PCIe physical interface circuit 292. PCIe controller 291 is bidirectionally connected to SMU 211 via SMN 212 and has an upstream port bidirectionally connected to system and input / output hub 251 and a downstream port. PCIe physical interface circuit 292 has an upstream port bidirectionally connected to PCIe controller 291 and a downstream port bidirectionally connected to a PCIe fabric, not shown in FIG. 2. The PCIe controller can form a PCIe root complex of a PCIe system for connection to a PCIe network including PCIe switches, routers and devices.

[0025] LLC 300 is connected between data fabric 260 and memory controller 271. LLC 300 has an upstream port bidirectionally connected to data fabric 260 and a downstream port bidirectionally connected to memory controller 271.

[0026] Figure 3 illustrates a portion of a SOC including an embodiment of the last level cache 300 of Figure 2 in accordance with some embodiments. LLC 300 generally includes coherent slave port interface 302, coherent master port 304, SRAM memory 310, response scheduler 312, multiplexer 313, transaction queue and scheduler 316, write data buffer 318, OR gate 320, OR gate 321, multiplexer 322, response data port 324, multiplexer 326, and victim queue 328. Also shown are traffic monitor 330 and local C-state controller 340 of data fabric 260.

[0027] Coherent slave port interface 302 is bidirectionally connected to a coherent slave controller in data fabric 260 , which receives memory access requests and write data from data fabric 260 and provides memory access responses and read data to data fabric 260 .

[0028] Write data buffer 318 has an input connected to coherent slave port 302, a first output connected to multiplexer 314, a second output connected to multiplexer 322, a third output connected to coherent master port 302, a third output connected to OR gate 320, and a fourth output connected to OR gate 321. Write data buffer 318 receives and stores data from data fabric 260 via coherent slave port 302 and holds the data until the data is sent to SRAM 310 via multiplexer 322 as part of a cache entry, the data is sent to main memory via master port 304 to the memory controller, or the data is returned via multiplexer 314, through coherent slave port 302, and through data fabric 260 to the agent accessing the memory. Data buffer 318 also asserts a signal to the input of OR gate 320 if data buffer 318 has LLC cacheable traffic to volatile memory, and asserts a signal to the input of OR gate 321 if data buffer 318 has LLC 330 non-cacheable traffic to volatile memory, as described further below.

[0029] Response data port 324 has an input connected to coherent master port 302, a first output connected to multiplexer 314, and a second output connected to multiplexer 322. Response data port 324 receives and stores data from memory controller 271 via master port 304, where the data is held until the data is transmitted as part of a cache entry via multiplexer 322 to SRAM 310 and / or until the specifically accessed portion of the data is transmitted via multiplexer 314 through coherent slave port 302 to data fabric 260 to the agent accessing the data.

[0030] Response scheduler 312 has a first input connected to coherent master port 304, a second input connected to transaction queue and scheduler 316, and an output connected to coherent slave port 302. Response scheduler 312 is used to forward responses received from memory controller 271 via master port 304 to the agent accessing the data via coherent slave port 302 through data fabric 260, and is used to interface to transaction queue / scheduler 316 to receive cache-assigned reads.

[0031] Transaction queue and scheduler 316 has an input connected to coherent slave port 302, a first output connected to response scheduler 312, a second output connected to victim queue 328, a third output connected to multiplexer 326, a fourth output connected to OR gate 320, and a fifth output connected to OR gate 321. Transaction queue and scheduler 316 generally coordinates memory access requests in cache 300. In this embodiment, transaction queue and scheduler 316 is implemented as a shifting-collapsing queue that handles most of the requests handled by cache 300. Memory access requests coming in from data fabric 260 via coherent slave port 302, or internal requests such as victim requests, flushed data, and rinsed data, allocate new entries in transaction queue / scheduler 316. Transaction queue / scheduler 316 has several different engines that scan for operations to select every cycle. For example, there are two victim line pickers that look for the least recently used (LRU) cache line and stage the memory location using victim queue 328 to write back to main memory via multiplexer 326 and coherent master port 304. There is a tag read and lookup picker that selects tag read and tag lookup operations to SRAM 310. Similarly, there is a tag write and lookup picker that selects tag write operations to SRAM 310. A data read picker and a data write picker select data reads or data writes of SRAM 310, respectively. Finally, a memory controller picker selects reads and writes of memory controller 271 via the master port. Transaction queue / scheduler 316 supports up to two allocations and up to two deallocations per internal clock cycle.Transaction queue / scheduler 316 also asserts a signal to the input of OR gate 320 when transaction queue / scheduler 316 has LLC cacheable traffic to volatile memory, and asserts a signal to the input of OR gate 321 when transaction queue / scheduler 316 has LLC 330 non-cacheable traffic to volatile memory, as described further below.

[0032] Victim queue 328 has an input connected to transaction queue / scheduler 316, an output connected to OR gate 320, and an output connected to OR gate 321. Traffic monitor 300 is generally connected to LLC 300 to monitor traffic directed to coherent master port 304 to memory controller 271 and its connected volatile memory, such as LPDDRx SDRAM 273. Traffic directed to master port 304 is monitored in this embodiment at each of data buffer 318, transaction queue / scheduler 316, and victim queue 328. In other embodiments, traffic may be monitored elsewhere, such as at an output buffer of master port 304. This monitoring is used to provide a power saving feature that allows the volatile memory to be placed into a self-refresh state when traffic to the volatile memory is idle, even while data fabric 260 is not in a C-state or idle state. OR gate 320 asserts the "LLCClientWake" signal whenever any of data buffer 318, transaction queue / scheduler 316, and victim queue 328 signal at their respective outputs that they have last level cache client traffic to volatile memory. "Non-LLC stuttering clients" are stuttering client traffic that is not serviced by the last level cache. OR gate 321 asserts the "NonLLCStutterClientWake" signal whenever any of data buffer 318, transaction queue / scheduler 316, and victim queue 328 signal at their respective outputs that they have non-LC stuttering client traffic that is not serviced by the last level cache in volatile memory.

[0033] Traffic monitor 300 has a first input for receiving the LLCClientWake signal from OR gate 320 and an output connected to local C-state controller 340. Another input (not shown) may be included for receiving C-state configuration information from local C-state controller 340.

[0034] Local C-state controller 340 in data fabric 260 controls the C-states of data fabric 260 and includes various port monitors and control outputs, not shown. Local C-state controller 340 has an input connected to traffic monitor 340, an input that receives the LLCClientWake signal from OR gate 320, an input that receives the NonLLCStutterClientWake signal from OR gate 321, an output that provides signal "DstateSel" to the memory controller power state manager, and an output that provides signal "FcStateSel" to the memory controller power state manager.

[0035] In operation, the traffic monitor 330, based on detection of an idle state in the monitored traffic, sends a signal to the local C-state controller 340 to cause the memory controller to instruct the volatile memory to leave self-refresh mode in response to a cache miss or eviction in the last level cache 330. The signal NonLLCStutterClientWake is used to indicate to the local C-state controller 340 that traffic from a stuttering client that is not cached in the LLC 300 requires access to the volatile memory via the coherent master port 304, and the signal LLCClientWake is used to indicate to the traffic monitor 330 and the local C-state controller 340 that traffic from a non-stuttering (normal) memory client requires access to the volatile memory. In this embodiment, the traffic monitor 330 is trained and operates by only monitoring traffic from LLC clients in this embodiment. Some stuttering clients may have their traffic cached in the LLC 300, and therefore traffic from such clients will not cause the signal NonLLCStutterClientWake to be asserted. A non-stuttering client is one that attempts to empty its output buffers and / or fill its input buffers as soon as an entry exists. For example, CCX 220 is a non-stuttering client. A stuttering client, on the other hand, is one that attempts to collect a number of memory access requests and then send them in one burst. The most common stuttering clients are display controllers or other multimedia clients, which may be embodied as RT clients 242 and 243 (FIG. 2). Before the data fabric enters a C-state or the memory controller enters a preemptive C-state, a stuttering client has full access to memory and is free to generate traffic.When the memory controller enters a C-state, non-LLC cacheable stuttering clients must enter a stutter mode in which they accumulate memory traffic and send it in bursts. When the data fabric is in a C-state, buffers in the stuttering clients are filled and then drained to a watermark level by requesting the data fabric to restore access to memory.

[0036] To detect an idle traffic condition based on its input signals, traffic monitor 330 further employs a success monitor circuit 332 that detects an idle condition in response to either traffic to volatile memory via coherent master port 304 being idle for a period determined by hysteresis timer 331 or a prediction that the next traffic idle period will last longer than a specified threshold. Success monitor circuit 342 operates in conjunction with burst filter 333 to filter "noisy" traffic that lasts for only a short duration after traffic resumes, thereby avoiding distortion of the next traffic idle prediction. In some embodiments, the success monitor circuit is trained to make predictions using only non-stuttering traffic between the last level cache and the memory controller.

[0037] In this embodiment, in addition to entering a self-refresh state in the volatile memory, the local C-state controller 340 is further operable to cause the memory controller to enter a selected C-state based on the traffic monitor 330 detecting an idle state. The selected C-state includes the data fabric and the last level cache maintaining an operational power state, as described further below. The signals DstateSel and FcStateSel are used to cause the memory controller to instruct the volatile memory to enter a self-refresh mode, while the last level cache maintains an operational power state and responds to cache hits via the data fabric, based on the traffic monitor 330 detecting an idle state in the monitored traffic. In particular, the signal DstateSel is used to select a memory controller power state, including a lightweight normal C-state as described with respect to FIG. 4, which may be one of two "preemptive" C-states that include the memory controller 271 being in a C-state with the volatile memory in a self-refresh mode while the data fabric has not yet been placed in a C-state. The signal FcStateSel is used to set the clock power state of the memory controller operational clock.

[0038] The victim queue 328 can assert an LLCClientWake signal via OR gate 320 to signal the traffic monitor 330 and local C-state controller 340 that access to the client's volatile memory is required to be cacheable in the LLC 330. The victim queue 328 can also assert a NonLLCStutterClientWake signal via OR gate 321 to signal the local C-state controller 340 that access is not cacheable in the LLC 330. In this embodiment, the victim queue 328 includes a high / low watermark function that is used to arbitrate traffic from the victim queue 328 and the transaction queue / scheduler 316 to the volatile memory via the coherent master port 304. In order for the self-refresh control provided by the traffic monitor 330 to work more efficiently with the watermark function, a process is needed to flush the victim queue 328 when there are no pending reads to avoid unnecessarily long LLCClientWake assertions from victims sitting in the queue waiting to reach the watermark. When victim queue 328 is flushed, it deasserts LLCClientWake, allowing traffic monitor 330 to detect traffic idle conditions on coherent master port 304 so that if the traffic is sufficiently idle, traffic monitor 330 can initiate a preemptive self-refresh entry. If the transaction queue of transaction queue and scheduler 316 is truly idle, victim queue 328 is drained immediately regardless of its watermark level and occupancy. However, if there are transactions in the transaction queue, victim queue 328 follows the transaction queue and accumulates pending transactions until its occupancy reaches the watermark.To handle such pending transactions, when the volatile memory is not in self-refresh, the victim queue 328 asserts the LLCClientWake signal each time it is entered, and the last level cache 300 ignores the threshold scheme and opportunistically flushes the victim queue 328 when no reads are pending. When the volatile memory is in self-refresh, the victim queue 328 asserts LLCClientWake only when the same threshold is reached to allow the victim queue to buffer victims evicted by write allocations and thereby extend the duration of self-refresh. This behavior allows the last level cache 300 to delay exiting from self-refresh mode by performing a certain number of eviction operations without forcing the volatile memory to exit self-refresh mode, and instead use available space in the victim queue until it is necessary to exit self-refresh and drain the victim queue 328. As described further below, this function serves to delay exit from self-refresh mode whenever self-refresh mode is active, whether it was entered preemptively or based on a normal entry process directed by local C-state controller 240 of data fabric 260.

[0039] In some embodiments, a similar watermark function may be used in conjunction with the data buffer 318 to delay exit from self-refresh mode.

[0040] In this embodiment, the last level cache 300 has multiple operating modes to improve the overall power savings achievable by the self-refresh feature. Specifically, the last level cache 300 is controllable to operate in a first high performance mode or a second low performance mode in which at least one feature is disabled to increase the likelihood that the traffic monitor will detect an idle state. Features that may be disabled in the second low performance mode include prefetch, speculative memory reads, and conditional write through / rinse features.

[0041] Figure 4 shows a table 400 illustrating the correspondence between different data fabric idle states and the states of other components of SOC 210 of Figure 2. Table 400 includes a first row describing a "lightweight" C-state 410 of data fabric 260 labeled "DFC1", a second row describing a "conventional" C-state 420 of data fabric 260 labeled "DFC2", a third row describing a "preemptive lightweight" C-state 430 of memory controller 271 labeled only "UMC-preemptive C1", and a fourth row describing a "preemptive conventional" C-state of memory controller 271 labeled only "UMC-preemptive C2". Chart 400 includes seven columns, including a "C-state" column, a memory controller column labeled "UMC," a physical interface controller column labeled "PHY," a volatile memory column labeled "DRAM," a memory controller clock column labeled "UMC CLK" (UMC CLK refers to the memory controller clock source), and a data fabric clock column labeled "DF CLK" (DF CLK refers to the data fabric clock source).

[0042] DFC2 corresponds to a conventional C-state in which both power and clock are gated to data fabric 260. Because DFC2 requires significant wake-up latency to data fabric 260, DFC2 performs power and clock gating to the data fabric and memory controller, and also places the memory PHY in a state designated LP2, which is a low-power state with its PLL turned off. However, before power-gating and clock-gating these components, the memory goes into self-refresh mode to preserve its contents during the expected long residency in DFC2. In addition, the PLLs of the data fabric and memory controller are powered down and the outputs are bypassed to the reference clock REFCLK. UMC Preemptive C1 corresponds to a lightweight C-state of the memory controller in which the memory controller is in the same conditions as DFC1 while the data fabric (including the last level cache) is operational, and UMC Preemptive C2 corresponds to a conventional C-state of the memory controller in which the memory controller is in the same conditions as DFC2 while the data fabric (including the last level cache) is operational.

[0043] As described above, data fabric 260 includes a lightweight C-state DFC1. To reduce wake-up latency to accommodate, for example, real-time peripherals, DFC1 only clock-gates the clock sources of data fabric 260 and the memory controller, keeping the data fabric and memory controller PLLs locked and the memory PHYs powered on. However, prior to clock-gating these components, the memory is placed in a self-refresh mode to preserve its contents during its indeterminate residency in DFC1, and the data fabric and memory controller PLLs are placed in a lower latency deep sleep mode rather than powered off. Thus, the data fabric provides a lightweight idle state DFC1 that provides lower latency to enable the ability of real-time peripherals, such as image sensor processors, to periodically access the memory system. The traffic monitor 300 of FIG. 3 operates in conjunction with the illustrated scheme to allow volatile memory (typically DRAM) to save additional power by entering a self-refresh state (in a preferred example, one of two preemptive C-states in rows 430 and 440) even when a data fabric C-state is not active, as will be further described below.

[0044] FIG. 5 illustrates a flowchart 500 of a process for operating a memory system including a last level cache with a traffic monitor, such as traffic monitor 300 of FIG. 3, according to some embodiments. The illustrated process is suitable for use with the last level cache and traffic monitor of FIG. 3 or other suitable embodiments. The process begins at block 502, where the process monitors traffic between the last level cache and a volatile memory controller to detect an idle state, for example, by using the monitoring signals and circuitry of FIG. 3. The detected idle state applies only to an idle state of client traffic of the last level cache, as described above, and non-LLC stuttering client traffic to the DRAM is expected to be present at this time. At block 504, in response to detecting an idle state, the process causes the memory controller to instruct the volatile memory to enter a self-refresh mode, while the last level cache maintains an operational power state and responds to cache hits via the data fabric. In this embodiment, the process signals the memory controller with a signal DstateSel indicating a desired power state selected from one of the two preemptive C-states of FIG. 4, and signals the memory controller with a signal FcStateSel indicating a desired clock low power state. The desired future state is preferably set by the data fabric power state controller to match the C-states expected to be used in the data fabric. For example, if the data fabric was most recently in the DFC1 power state, that state may be the state expected to be next used in the data fabric, and thus the desired power state for a preemptive C-state in the memory controller is the UMC preemptive C1 power state, which contains the same conditions in the memory controller.

[0045] At block 506, the non-LLC serviced stuttering clients are placed in stutter mode, and the last level cache can then continue to service memory access requests from the remaining clients through the data fabric while the memory controller is in the preemptive C-state and the volatile memory is in self-refresh mode. (As will be further explained with respect to FIG. 6 and FIG. 7, any operation that causes an access to the volatile memory at this point in the process will cause an exit from self-refresh mode.) In general, before the data fabric enters a C-state or the memory controller enters a preemptive C-state, the stuttering clients have full access to the memory and are free to generate traffic. When the memory controller enters a C-state at block 504, the non-LLC cacheable stuttering clients must enter stutter mode where they accumulate memory traffic and send it in bursts. When the data fabric is in a C-state, the stuttering clients' buffers fill up and are then drained to the watermark level by requesting the data fabric to restore access to the memory. This feature is also used in combination with the preemptive memory controller C-state entered at 504. Stuttering clients are placed into stutter mode even if the data fabric is not already in C state.

[0046] In the illustrated scenario, at block 508, a C-state of a specified type is prepared to be entered, e.g., any of the C-states shown in FIG. 4. At block 510, the process determines whether the C-state entered by the data fabric matches a C-state already specified for the memory controller or is a lighter C-state than the C-state specified for the memory controller. Under most operating conditions, the states match. However, they may not match if traffic conditions change in the data fabric. If the memory controller's C-state matches or is deeper than the data fabric, the memory controller has already incurred the delay of entering a state of minimum depth required, and the process proceeds to block 514. At block 510, if the memory controller's C-state is lighter than the C-state of the data fabric 260 (the data fabric C-state is deeper), the process proceeds to block 512, where the memory controller leaves the current C-state that includes the volatile memory leaving the self-refresh state and re-enters the self-refresh state if the memory controller enters a C-state used by the data fabric. If the specified low power state in the memory controller matches that required by the data fabric C-state, the process proceeds to block 514, where the memory controller enters the specified C-state without causing the memory to leave the self-refresh state. Because the non-LLC stuttering clients were already placed in stutter mode earlier (block 504), the data fabric C-state entry does not need to place these clients in stutter mode individually, as it would normally do when entering a data fabric C-state from an active state instead of a preemptive memory controller C-state.

[0047] The illustrated process has the advantage of allowing the use of small and efficient finite state machine logic in the memory controller's power state controller, while still allowing variability in both the memory controller C-state states and the memory PHY C-state states, along with more frequent memory cell refresh states controlled by traffic monitor 300.

[0048] FIG. 6 illustrates a flowchart 600 of a process for leaving a self-refresh state while the memory controller is in a C-state, according to some embodiments. The illustrated process is suitable for use with the last level cache and traffic monitor of FIG. 3 or other suitable embodiments. At block 602, the process detects traffic to volatile memory in the last level cache during the self-refresh state, and the memory controller is in a preemptive C-state, such as any of the two preemptive C-states in FIG. 4, and the data fabric and last level cache are operational. Such traffic may be caused by last level cache clients that previously only hit the cache, or by non-LLC stuttering clients reaching their stutter watermark level and requesting access to the volatile memory to fill or flush their data buffers. At block 604, the process signals the traffic monitor with either a NonLLCStutterClientWake signal or an LLCClientWake signal, depending on the type of traffic involved. At block 606, the traffic monitor signals the power state controller of the memory controller to exit the C-state and take the volatile memory out of the self-refresh state. At block 608, volatile memory traffic is sent from the last level cache to the memory controller and processed by the memory controller.

[0049] Figure 7 illustrates a flowchart 700 of a process for exiting a C-state in the data fabric, including delayed C-state exit in a memory controller, according to some embodiments. The illustrated process is suitable for use with the traffic monitor of Figure 3 and other suitable traffic monitor circuitry used with a last level cache. The process begins at block 702, where the data fabric and memory controller are in a C-state or low power state, such as either state DFC1 or DFC2 of Figure 4. Volatile memory traffic is detected in the data fabric, typically by a separate traffic monitor monitoring the master ports that connect the data fabric to various system clients, such as CPUs, GPUs, and real-time clients.

[0050] At block 704, the process determines whether the traffic is from a client that is not caching in the last level cache, referred to as non-LLC serviceable traffic. If so, the process proceeds to block 704 and exits the C-state in the data fabric and the memory controller, including exiting self-refresh mode in the volatile memory. If not, the process proceeds to block 706 and exits the C-state in the data fabric. For example, for an embodiment that supports C-states as shown in FIG. 4, this block proceeds from either C-state 410 or 420 to either C-state 430 or 440. As shown in block 708, the C-state in the data fabric is maintained, including maintaining the self-refresh state in the volatile memory. At block 710, this state continues with cacheable traffic being serviced by the LLC until access to volatile memory is required or the data fabric becomes idle again and a C-state is entered. As shown, a cache miss or eviction in the last level cache requires access to volatile memory. As can be appreciated, this illustrated process has the advantage of delaying the memory controller from leaving its C-state until a memory request occurs that requires access to volatile memory, allowing the last level cache to service all memory requests that it is capable of. The illustrated process also allows the data fabric to leave and re-enter its C-state without the memory controller leaving its C-state if a scenario occurs where there is no traffic that requires access to volatile memory and all traffic can be serviced by the LLC. Both of these scenarios provide significant power savings by avoiding exiting the memory controller C-state and memory cell refresh states until absolutely necessary.

[0051] FIG. 8 illustrates a flowchart 800 of a process for entering a C-state in the data fabric with the memory controller in a preemptive C-state, according to some embodiments. The illustrated process is suitable for use with the traffic monitor of FIG. 3 and other suitable traffic monitor circuitry used with the last level cache. The process begins at block 802 with the data fabric becoming idle while the memory controller is in a C-state and the volatile memory is in a self-refresh state. For example, in an embodiment that supports the C-states of FIG. 4, the memory controller is in either of preemptive C-states 430 or 440. Next, at block 804, the process maintains the C-states in the memory controller, including the self-refresh state in the volatile memory. If the C-state in the memory controller is lighter than the desired C-state for the data fabric, this block includes placing the memory controller in a deeper C-state, which may include exiting the current state and re-entering the deeper C-state, as described with respect to FIG. 5. At block 806, the data fabric enters the desired C-state. This process represents a change from either state 430 or 440 to either state 410 or 420 (FIG. 4).

[0052] FIG. 9 illustrates a flowchart 900 of a process for training a success monitor of a traffic monitor, according to some embodiments. The illustrated process is suitable for use with the traffic monitor of FIG. 3 and other suitable traffic monitor circuitry used with a last level cache. The process begins training the success monitor at block 902. Traffic periods having non-stuttering traffic to volatile memory via the memory controller are used for training based on the LLCClientWake signal, and traffic from non-LLC serviceable stuttering traffic is not used for training. If the data fabric becomes idle and is placed in a C-state at block 904, the process proceeds to block 905 where the training of the traffic monitor is paused. If the data fabric is not idle, regardless of whether the memory controller is in a preemptive C-state, the process continues to block 906, where the process trains the success monitor to make a prediction of whether the current idle traffic period will last longer than the desired value of the hysteresis timer. As can be appreciated, although the flowchart shows a series of steps, the training process may be ongoing and may be controlled in an event-driven manner where stutter traffic interrupts the training.

[0053] 3, stuttering traffic is not cached in the last level cache 300 and, due to the nature of its duration, is not useful for training the success monitor 332. However, in other embodiments, caching of stuttering traffic may be enabled in the last level cache 300. In such embodiments, training may be performed on stuttering traffic if the traffic is provided for caching in the last level cache.

[0054] FIG. 10 illustrates a flowchart 1000 of a process for processing save / restore traffic from a designated subsystem in a last level cache, according to some embodiments. The illustrated process is suitable for use with the traffic monitor of FIG. 3 and other suitable traffic monitor circuitry used with a last level cache. At block 1002, the process designates the save / restore traffic for a particular subsystem power state change as cacheable in the LLC. Preferably, this designation is done by setting the memory address range used for the save / restore traffic as cacheable by the LLC. Such designated save / restore traffic may be, for example, traffic for transitioning the data fabric into and out of a sleep state or C-state as described above. Traffic for transitioning any other subsystem or module into and out of a sleep state may be designated as cacheable by the LLC in some embodiments.

[0055] At block 1004, the memory controller is in a preemptive C-state as described above. In such a state, the LLC can service save / restore traffic designated as cacheable in the LLC at block 1006. Use of the illustrated process has the advantage of saving power by avoiding taking the memory controller out of C-states and taking volatile memory out of self-refresh to service selected save and restore traffic.

[0056] The SOC 210 of FIG. 2 or any portion thereof, such as the last level cache 300 and the traffic monitor 330, may be described or represented by a computer accessible data structure in the form of a database or other data structure that may be read by a program and used directly or indirectly to manufacture an integrated circuit. For example, the data structure may be a behavioral level description or a register transfer level (RTL) description of the hardware functionality in a high level design language (HDL) such as Verilog or VHDL. The description may be read by a synthesis tool that may synthesize the description to generate a netlist that includes a list of gates from a synthesis library. The netlist includes a set of gates that also represent the functionality of the hardware that comprises the integrated circuit. The netlist may then be placed and routed to generate a data set that describes the geometric shapes to be applied to a mask. The mask may then be used in various semiconductor manufacturing processes to manufacture the integrated circuit. Alternatively, the database on the computer accessible storage medium may be a netlist (with or without a synthesis library) or a data set, or Graphic Data System (GDS) II data, if desired.

[0057] Although specific embodiments have been described, various modifications to these embodiments will be apparent to those skilled in the art. The various techniques used in conjunction with the low power state retention for probe filters disclosed herein may be used independently or in conjunction with other techniques. Furthermore, different techniques and circuits may be used to detect the condition for entering the low power state retention.

[0058] Therefore, the appended claims are intended to cover all modifications of the disclosed embodiments that fall within the scope of the disclosed embodiments.

Claims

1. 1. A data processor, comprising: a data fabric that routes requests between multiple requesters and multiple responders; a memory controller for accessing the volatile memory; a last level cache coupled between the memory controller and the data fabric; a traffic monitor coupled to the last level cache and operable to monitor traffic between the last level cache and the memory controller, and causing the memory controller to instruct the volatile memory to enter a self-refresh mode upon detection of an idle state in the monitored traffic; Data processor.

2. the last level cache maintains an operating power state while the volatile memory is in the self-refresh mode caused by the traffic monitor and responds to cache hits via the data fabric.

10. The data processor of claim 1.

3. the traffic monitor is operable to cause the memory controller to instruct the volatile memory to leave the self-refresh mode in response to a cache miss or an eviction in the last level cache.

10. The data processor of claim 1.

4. The traffic monitor a hysteresis timer; a success monitor circuit coupled to the hysteresis timer, the success monitor circuit detecting the idle state based on idle traffic between the last level cache and the memory controller until expiration of the hysteresis timer or a prediction that a next traffic idle period will last longer than a threshold; 10. The data processor of claim 1.

5. the success monitor circuit is trained to make the prediction using only traffic that can be processed by the last level cache; 4. The data processor of claim 3.

6. the last level cache selectively operates in a high performance mode and a low performance mode in which at least one function is disabled to increase the likelihood that the traffic monitor will detect the idle state; 10. The data processor of claim 1.

7. the last level cache includes a victim queue; the last level cache operates to opportunistically flush the victim queue when the volatile memory is not in the self-refresh mode; the last level cache is operative to allow the victim queue to fill to a specified threshold when the volatile memory is in the self-refresh mode to delay exit from the self-refresh mode; 10. The data processor of claim 1.

8. the traffic monitor is operable to cause the memory controller to enter a selected C-state based on detecting the idle state by sending a signal to a local power state controller in the data fabric to indicate that the memory controller is idle, the selected C-state including the data fabric and last level cache remaining in an operational power state; 10. The data processor of claim 1.

9. the last level cache sending a first signal to the traffic monitor indicating that non-stuttering traffic requires access to the volatile memory; the last level cache sending the first signal and a second signal indicating stuttering traffic requiring access to the volatile memory to the power state controller of the data fabric; 8. The data processor of claim 7.

10. Routing requests between a plurality of requesters and a plurality of responders in a data fabric of a data processor; monitoring traffic to a volatile memory at a last level cache coupled to the data fabric; and instructing a memory controller to cause the volatile memory to enter a self-refresh mode based on detecting an idle state in the monitored traffic. method.

11. maintaining an operating power state of the last level cache to respond to cache hits via the data fabric while the volatile memory is in the self-refresh mode. The method of claim 10.

12. instructing the volatile memory to leave the self-refresh mode in response to a cache miss or eviction in the last level cache. The method of claim 10.

13. detecting the idle state based on idle traffic between the last level cache and the memory controller until expiration of a hysteresis timer or a prediction that a next traffic idle period will last longer than a threshold. The method of claim 10.

14. training a success monitor circuit to make said prediction using only traffic that can be handled by said last level cache; 14. The method of claim 13.

15. designating save / restore traffic of at least one subsystem of the data processor as cacheable in the last level cache; and processing save / restore traffic of the at least one subsystem in the last level cache while the volatile memory is in the self-refresh state. The method of claim 10.

Images