Memory side transaction background memory interface system and method

Abstract

The present application relates to a memory-side transaction background memory interface system and method. The present invention provides a technique for implementing and / or operating an apparatus, the apparatus comprising a memory system coupled to a processing system via a memory bus. The memory system comprises a hierarchical memory hierarchy and a memory controller. The memory controller receives a memory access request at least in part by receiving an address parameter indicating a memory address associated with a data block from the memory bus during a first clock cycle and receiving a background parameter indicating background information associated with a current targeting of the data block from the memory bus during a second clock cycle, instructs the memory system to output the data block to the memory bus based on the memory address indicated in the address parameter, and predictively controls data storage in the hierarchical memory hierarchy based at least in part on the background information indicated in the background parameter of the memory access request.

Description

Technical Field

[0001] The present disclosure relates generally to computing systems and, more particularly, to memory interfaces implemented in computing systems. Background Art

[0002] In general, a computing system includes a processing subsystem and a memory subsystem, which can store data that can be accessed by processing circuitry of the processing subsystem. For example, to perform an operation, the processing circuitry can execute corresponding instructions retrieved from a memory device implemented in the memory subsystem. In some cases, data inputs for the operation can also be retrieved from the memory device. Additionally or alternatively, data outputs from (e.g., generated from) the operation can be stored in the memory device, e.g., to enable subsequent retrieval. However, at least in some cases, the efficiency of the operation of a computing system can be limited by its architecture, e.g., the architecture governing the sequence of operations performed in the computing system. Summary of the invention

[0003] One aspect relates to an apparatus. The apparatus includes a memory system configured to be communicatively coupled to a processing system via a memory bus, wherein the memory system includes: a plurality of hierarchical memory levels implemented at least in part using one or more memory devices in the memory system; and a memory-side memory controller configured to: receive a first memory access request requesting a first data block targeted by a processing circuit in the processing system to be returned at least in part by: receiving a first address parameter from the memory bus during a first clock cycle indicating a first memory address associated with the first data block; and receiving a first context parameter from the memory bus during a second clock cycle different from the first clock cycle indicating first context information associated with current targeting of the first data block; instructing the memory system to output the first data block to the memory bus based at least in part on the first memory address indicated in the first address parameter of the first memory access request; and predictively controlling data storage in the plurality of hierarchical memory levels of the memory system based at least in part on the first context information indicated in the first context parameter of the first memory access request.

[0004] Another aspect relates to a method of operating a computing system. The method includes: receiving, using memory control circuitry in a memory subsystem of the computing system, a memory access request output to a memory bus coupled between the memory subsystem and a processing subsystem of the computing system, wherein the memory access request includes: an address parameter field for indicating a memory address associated with a first data block targeted by the memory access request; and a context parameter field for indicating context information associated with generation of the first data block, targeting of the first data block, or both; locating, using the memory control circuitry, a memory bus implemented in the memory subsystem based at least in part on the memory address indicated in the address parameter field of the memory access request. the first data block in a plurality of hierarchical memory levels; using the memory control circuitry to instruct the memory subsystem based at least in part on the first data block to output the first data block to the memory bus so that processing circuitry implemented in the processing subsystem can perform a data processing operation; using the memory control circuitry to update historical data access information stored in the memory subsystem based at least in part on the context information indicated in the context parameter field of the memory access request; and using the memory control circuitry to predictively control data storage in the plurality of hierarchical memory levels implemented in the memory subsystem based at least in part on the historical data access information.

[0005] Yet another aspect relates to a computing system including a memory subsystem, wherein the memory subsystem includes: one or more memory-side caches organized to implement a first memory hierarchy in the memory subsystem; one or more memory devices organized to implement a second memory hierarchy in the memory subsystem that is higher than the first memory hierarchy; one or more internal communication buses coupled to the one or more memory-side caches and the one or more memory devices; and a bus interface coupled to the one or more internal communication buses, wherein the bus interface includes a plurality of pins each configured to couple to a corresponding conductor of an external communication bus so that the memory subsystem can perform the following operations: receive a memory access request including an access parameter field and a context parameter field output by a processing subsystem of the computing system to the external communication bus, wherein context information used by the processing subsystem to predictively control storage of data in one or more processor-side caches is indicated in the context parameter field of the memory access request; and provide memory access to the processing subsystem based at least in part on a memory address indicated in the access parameter field of the memory access request. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Various aspects of the present disclosure may be better understood after reading the following detailed description and referring to the accompanying drawings, in which:

[0007] Figure 1 is a block diagram of a computing system including a processing subsystem and a memory subsystem according to an embodiment of the present disclosure;

[0008] Figure 2 According to the embodiment of the present disclosure Figure 1 A block diagram of an example of a processing subsystem;

[0009] Figure 3 According to an embodiment of the present disclosure, Figure 2 A flowchart of an example process of a processing subsystem;

[0010] Figure 4 is a graphical representation of historical data access information organized according to transaction context according to an embodiment of the present disclosure;

[0011] Figure 5 is a method for predictively controlling the Figure 1 A flowchart of an example process for storing data in a computing system;

[0012] Figure 6 According to an embodiment of the present disclosure, a method for requesting access Figure 1 A flowchart of an example process of a memory subsystem of FIG.

[0013] Figure 7 According to the embodiment of the present disclosure, Figure 2 A graphical representation of an example memory access request output by a processing subsystem of;

[0014] Figure 8 According to the embodiment of the present disclosure Figure 2 a graphical representation of an instance request queue implemented in a processing subsystem of;

[0015] Fig. 9 According to the embodiment of the present disclosure Figure 1 A block diagram of an example of a memory subsystem of;

[0016] Fig.10 According to the embodiment of the present disclosure Fig. 9 A block diagram of an example memory array implemented in a memory subsystem of;

[0017] Fig.11 is a graphical representation of an example data object according to an embodiment of the present disclosure, the data object comprising a data block and one or more context parameters indicating a transaction context associated with the data block;

[0018] Fig.12According to the embodiment of the present disclosure Figure 1 A block diagram of an example cache implemented in a computing system of;

[0019] Fig.13 According to an embodiment of the present disclosure, Fig. 9 A flowchart of an example process of a memory subsystem of FIG.

[0020] Fig.14 According to the embodiment of the present disclosure Figure 1 A block diagram of an example memory bus and memory bus interface implemented in a computing system of

[0021] Fig.15 According to the embodiment of the present disclosure Figure 1 A timing diagram of an example communication between a processing subsystem and a memory subsystem. DETAILED DESCRIPTION

[0022] The present disclosure provides techniques for facilitating improved operational efficiency of a computing system, such as by mitigating architectural features that might otherwise limit operational efficiency. In general, a computing system may include various subsystems, such as a processing subsystem and / or a memory subsystem. Specifically, a processing subsystem may include processing circuitry implemented, for example, in one or more processors and / or one or more processor cores. A memory subsystem may include, for example, one or more memory devices (e.g., chips or integrated circuits) implemented on a memory module (e.g., a dual in-line memory module (DIMM)) and / or organized to implement one or more memory arrays (e.g., memory cell arrays).

[0023] Typically, during operation of a computing system, processing circuitry implemented in its processing subsystem may perform various operations by executing corresponding instructions currently stored in one or more of its registers. For example, when an application (e.g., a program) is running in the computing system, the processing circuitry may execute application instructions that perform data processing operations on input data. At least in some cases, data accessible to the processing circuitry in the processing subsystem may be stored in one or more memory devices of a storage subsystem in the computing system. For example, the memory subsystem stores data input to an operation, data output (e.g., results) from an operation, and / or data indicative of executable application instructions via a memory array implemented in one or more of its memory devices. In other words, during operation of the computing system, the processing subsystem may access the memory subsystem, for example, to store (e.g., write) data to the memory subsystem and / or retrieve (e.g., read) data previously stored in the memory subsystem.

[0024] To enable access to the memory subsystem, the processing subsystem may be communicatively coupled to the memory subsystem via one or more communication buses, such as a storage bus and / or a communication network (e.g., Ethernet). Additionally, to access the memory subsystem, in some cases, the processing subsystem may output a memory access request indicating one or more access parameters to be used by the memory subsystem to provide the processing subsystem memory access. For example, to store (e.g., write) a block of data to the memory subsystem, the processing subsystem may output a write memory access request indicating one or more write access parameters, such as a virtual memory address used by the processing circuit to identify the block of data, a physical memory address in the memory subsystem where the block of data is to be stored, a size of the block of data (e.g., a bit count), and / or a write access indicator (e.g., bits). Additionally or alternatively, to retrieve (e.g., read) a block of data from the memory subsystem, the processing subsystem may output a read memory access request that indicates read access parameters, such as a virtual memory address used by the processing circuit to identify the block of data, a physical memory address in the memory subsystem where the block of data is expected to be stored, a size of the block of data (e.g., a bit depth or bit length), and / or a read access indicator (e.g., a bit).

[0025] In response to receiving a read memory access request, the memory subsystem may search for a data block targeted by the read memory access request based at least in part on the read access parameters indicated therein. For example, the memory subsystem may determine a target value of a tag parameter (e.g., metadata) expected to be associated with the target data block based at least in part on the virtual memory address and / or physical memory address indicated in the read memory access request. The memory subsystem may then identify (e.g., find) the target data block by continuously comparing the target tag parameter value with the values ​​of the tag parameters associated with valid data blocks stored therein. Once a match is detected, the memory subsystem may identify the associated data block as the target data block and therefore return the associated data block to the processing subsystem, e.g., for processing and / or execution by its processing circuitry. Therefore, at least in some cases, the operating efficiency of the computing system may depend on the data retrieval latency (e.g., the duration before the target data is returned) provided by its memory subsystem.

[0026] However, data communication between different computing subsystems is typically slower than data communication within a computing subsystem, for example, due to differences in operating timing (e.g., clock domains) of different computing subsystems, data buses coupled between different subsystems shared by other computing subsystems, and / or communication distances between different subsystems. In other words, data communication within (e.g., internally to) a processing subsystem may be faster than data communication between a processing subsystem and a memory subsystem. Therefore, to facilitate improving (e.g., reducing or shortening) data retrieval latency, one or more caches may be implemented in a processing subsystem. For example, a processing subsystem may include a level 1 (L1) cache, a level 2 (L2) cache, and / or a level 3 (L3) cache integrated with its processing circuitry.

[0027] More specifically, in some cases, a cache may be implemented and / or operated to store (e.g., cache) data output from a processing circuit, data requested by (e.g., input to and / or targeted for) a processing circuit, and / or data pre-fetched from a memory array in a memory subsystem. Additionally or alternatively, a computing system may include one or more buffers, such as pre-fetch buffers, that are distinct (e.g., separate) from a cache implemented in the computing system. In some cases, a pre-fetch buffer may be implemented and / or operated to store (e.g., buffer) data pre-fetched from a memory array. Indeed, to facilitate reducing cache pollution, in some cases, for example, a computing system may keep pre-fetched data stored in a pre-fetch buffer rather than transferring the pre-fetched data to a cache.

[0028] To facilitate further improvement (e.g., reduction or shortening) of data retrieval latency, in some cases, the total storage capacity of the memory subsystem may be distributed across multiple hierarchical memory levels (e.g., tiers). Typically, the hierarchical memory subsystem may include a lowest (e.g., first) memory level closest to the processing circuitry and a highest (e.g., last) memory level farthest from the processing circuitry. Additionally, in some cases, the hierarchical memory subsystem may include one or more intermediate memory levels between the lowest memory level and the highest memory level. In other words, the intermediate memory levels may be implemented farther from the processing circuitry than the lowest memory level, and the intermediate memory levels may be implemented closer to the processing circuitry than the highest memory level.

[0029] Typically, the hierarchical memory hierarchy can be implemented so that the lower memory hierarchy provides faster data access (e.g., reading and / or writing) speeds than the higher memory hierarchy, for example, at least in part by implementing the lower memory hierarchy with less (e.g., smaller) storage capacity than the higher memory hierarchy. Thus, to facilitate improved data retrieval latency when setting target (e.g., requesting) data, if the target data results in a miss (e.g., the target tag parameter value does not match any valid tag parameter value), the computing system may attempt to retrieve the target data from the lowest hierarchical memory hierarchy first, and then gradually progress to higher memory hierarchies. For example, the computing system may check whether the target data block is currently stored in the lowest (e.g., first) memory hierarchy. When the target data block results in a miss in the lowest memory hierarchy, the computing system may then check whether the target data block is currently stored in the next lowest (e.g., second) memory hierarchy, and so on.

[0030] Furthermore, in some cases, the computing system may store (e.g., cache and / or buffer) a copy (e.g., instance) of the target data in a lower memory level after retrieval from a higher memory level when the target data is not currently stored in the lower memory level. In fact, at least in some cases, a miss in a lower memory level may actually result in a slower (e.g., higher) data retrieval latency compared to directly retrieving the target data from the higher memory level. In other words, the impact on data retrieval latency, and therefore the efficiency of computing system operation resulting from implementing multiple hierarchical memory levels, may depend in large part on the memory level in which the data is stored when the data is actually targeted.

[0031] Therefore, to facilitate improved operational efficiency of a computing system, the present disclosure provides techniques for implementing and / or operating a computing system to reduce the likelihood that data targeted by its processing circuitry will miss lower memory hierarchies (e.g., tiers). In some embodiments, a computing system may treat caches and / or buffers implemented in its processing subsystem as one or more lower memory hierarchies compared to the memory hierarchies implemented by memory arrays in its memory subsystem. For example, a first (e.g., L1) cache in a processing subsystem may be treated as the lowest memory hierarchy, a second (e.g., L2) cache in the processing subsystem may be treated as the next lowest memory hierarchy, and so on. Additionally or alternatively, when a computing system is implemented and / or operated to keep pre-fetched data stored in a pre-fetch buffer, the cache in the processing subsystem may be treated as a lower memory hierarchy, and the pre-fetch buffer may be treated as a higher memory hierarchy.

[0032] In some embodiments, the computing system may additionally include one or more caches and / or buffers, such as prefetch buffers, implemented in its memory subsystem. In other words, in such embodiments, the computing system may include one or more processor-side caches and one or more memory-side caches that are implemented to provide a higher memory hierarchy compared to the one or more processor-side caches. Additionally or alternatively, the computing system may include a processor-side prefetch buffer and a memory-side prefetch buffer that are implemented to provide a higher memory hierarchy compared to the processor-side prefetch buffer. Furthermore, in some embodiments, one or more memory arrays in the memory subsystem may be implemented to provide a higher memory hierarchy compared to the (e.g., processor-side and / or memory-side) cache memory hierarchy and / or the (e.g., processor-side and / or memory-side) prefetch memory hierarchy. For example, the memory subsystem may include a non-volatile memory array implemented to provide a highest memory hierarchy and a volatile memory array implemented to provide a next-highest memory hierarchy, such as a dynamic random access memory (DRAM) array.

[0033] To facilitate reducing the likelihood of misses in lower memory hierarchies, in some embodiments, a computing system may include one or more memory controllers that are implemented and / or operated to control data storage therein. For example, a computing system may include a first (e.g., processor-side) memory controller that controls data storage in its processing subsystem and a second (e.g., memory-side) memory controller that controls data storage in its memory subsystem. In other words, as used herein, "memory controller" is intended to describe a controller (e.g., control circuitry and / or control logic) that is implemented and / or operated to control data storage in a computing system. In fact, in some embodiments, a memory controller may be implemented using multiple controllers, such as a cache controller that controls data storage in a cache memory hierarchy, a prefetch controller that controls data storage in a prefetch memory hierarchy, and / or a DRAM (e.g., main) memory controller that controls data storage in a DRAM memory hierarchy.

[0034] To facilitate reducing the likelihood of misses to lower memory levels, in some embodiments, the memory controller may predictively control data storage in one or more hierarchical memory levels. In other words, at least in such embodiments, the memory controller may predict data access patterns expected to occur within an upcoming control range (e.g., a time period or one or more clock cycles) and control data storage in one or more hierarchical memory levels accordingly. In practice, because processing circuits often exhibit certain cyclical (e.g., repeating) data access patterns, in some embodiments, the memory controller may predict subsequent data access patterns based at least in part on one or more previous (e.g., historical) data access patterns.

[0035] In some embodiments, the memory controller may determine a previous data access pattern by determining what data was previously accessed (e.g., targeted and / or requested), when the data was previously accessed, and / or the order in which the data was previously accessed. Thus, to facilitate determining a previous data access pattern, in some embodiments, the memory controller may historically track access information (e.g., parameters) associated with data (e.g., memory) accesses, for example, via entries in a historical data access information table. As an illustrative example, when a first data block is accessed (e.g., targeted and / or written), the memory controller may store a first block identifier parameter (e.g., a corresponding tag parameter, a physical memory address, or a virtual memory address) of the first data block in a block identifier field of a first entry in the historical data access information table.

[0036] To facilitate historical tracking, in some embodiments, the memory controller may store indications of data blocks targeted by multiple data accesses in chronological order, for example, via consecutive entries in the historical data access information table. To help illustrate, continuing with the above example, when a second data block is accessed after a first data block, the memory controller may store a second block identifier parameter identifying the second data block in the block identifier field of the second entry in the historical data access information table. Additionally, when a third data block is accessed after the second data block, the memory controller may store a third block identifier parameter identifying the third data block in the block identifier field of the third entry in the historical data access information table.

[0037] Thus, in some embodiments, the memory controller may determine the previous data access pattern at least in part by reading entries of its historical data access information table. For example, by reading the block identifier field of the entry in the historical data access information table, the memory controller may determine that the previous data access pattern accessed the first data block, the second data block, and the third data block. In other words, by reading the entry of its historical data access information table, the memory controller may determine what data blocks were accessed (e.g., targeted and / or written) by the previous data access pattern.

[0038] Additionally or alternatively, based at least in part on the corresponding block identifiers indicated in the historical data access information table, the memory controller may determine a first step (e.g., distance) between a first (e.g., physical or virtual) memory address of a first data block and a second memory address of a second data block, a second step between the second memory address of the second data block and a third memory address of a third data block, and / or a third step between the first memory address of the first data block and a third memory address of the third data block. Furthermore, based on the order of corresponding entries in the historical data access information table, the memory controller may determine that a previous data access pattern accessed the second data block after the first data block, that a previous data access pattern accessed the third data block after the second data block, and / or that a previous data access pattern accessed the third data block after the first data block. In other words, by reading the entries of its historical data access information table, the memory controller may determine relative access times of data blocks during previous data access patterns.

[0039] In some embodiments, the memory controller may additionally track the absolute access time of the data block during the previous data access pattern. To facilitate historically tracking the absolute access time, in some embodiments, the historical data access information may include one or more write time parameters, each of which indicates when the corresponding data block and / or the corresponding memory address was initially written (e.g., stored), and / or one or more last access time parameters, each of which indicates when the corresponding data block and / or the corresponding memory address was most recently accessed (e.g., targeted and / or requested). For example, when accessing a first data block, the memory controller may store a first last access time parameter indicating a current time in a last access time field of a first entry in the historical data access information table. Similarly, the memory controller may store a second last access time parameter indicating a current time in a last access time field of a second entry in the historical data access information table when accessing a second data block, and / or store a third last access time parameter indicating a current time in a last access time field of a third entry in the historical data access information table when accessing a third data block.

[0040] Additionally or alternatively, the memory controller may track the number of times a data block was accessed (e.g., targeted or requested) during a previous data access pattern. To facilitate historically tracking access counts, in some embodiments, the historical data access information may include one or more access count parameters, each of which indicates the number of times a corresponding data block and / or a corresponding memory address has been accessed. For example, when accessing a first data block, the memory controller may increment the value of a first access count parameter indicated in an access count field of a first entry in the historical data access information table. Similarly, when accessing a second data block, the memory controller may increment the value of a second access count parameter indicated in an access count field of a second entry in the historical data access information table, and / or when accessing a third data block, increment the value of a third access count parameter indicated in an access count field of a third entry in the historical data access information table.

[0041] Since data access patterns are often repetitive (e.g., cyclical) to some extent, in some embodiments, the memory controller may predict a subsequent data access pattern based at least in part on historical data access information associated with one or more previous data access patterns. In other words, based at least in part on the historical data access information, the memory controller may predict what data will be accessed subsequently, when the data will be accessed subsequently, and / or the order in which the data will be accessed subsequently. To help illustrate, continuing with the above example, the memory controller may predict that since the historical data access information indicates that the first data block and the second data block have been accessed in accordance with the previous data access pattern, the first data block and the second data block will be accessed again in the subsequent data access pattern. Additionally or alternatively, the memory controller may predict that since the historical data access information indicates that the previous data access pattern accessed the second data block after accessing the first data block, the subsequent data access pattern will access the second data block again after accessing the first data block.

[0042] In other words, in some embodiments, the memory controller may predict the subsequent data access pattern by predicting the next target data block. For example, when accessing the first data block, the memory controller may predict that the second data block will be accessed next. Additionally or alternatively, because the historical data access information indicates that the second memory address of the second data block is the first step length (e.g., distance) away from the first memory address of the first data block, the memory controller may predict that the next target data block is a data block associated with a memory address (e.g., physical and / or virtual) that is the first step length away from the current or previously accessed data block.

[0043] However, at least in some cases, predicting subsequent data access patterns based solely on chronological data access information may result in inaccurate predictions of subsequent data access patterns, e.g., because historical data access information associated with unrelated data blocks and / or unrelated (e.g., virtual and / or physical) memory addresses is also overweighted in the prediction. To help illustrate, continuing with the above example, the previous targeting of the first data block and the previous targeting of the third data block may be caused by running a specific application (e.g., a program or thread) in the computing system. On the other hand, the previous targeting of the second data block may be caused by a system interruption independent of the specific application.

[0044] Since it is independent of the specific application, a system interruption may not always occur between targeting the first data block and targeting the third data block. In other words, at least in some cases, a system interruption and the resulting targeting of the second data block may not occur between targeting of the first data block and targeting of the third data block according to a subsequent data access pattern. Therefore, at least in this case, equally weighting the historical data access information associated with the first data block, the second data block, and the third data block may result in inappropriate prediction of the subsequent data access pattern, such as causing the predicted next target time of the third data block to occur at a time that is too late relative to its actual next target time, so that the third data block cannot be prefetched to a lower memory hierarchy before its next targeting.

[0045] To facilitate improved prediction accuracy, in some embodiments, a memory controller may predict subsequent data access patterns at least in part by analyzing historical data access information in light of a transaction context associated with one or more data (e.g., memory) accesses. Specifically, in some embodiments, a transaction context associated with a data access may be indicated via context information (e.g., one or more parameters) that identifies one or more aspects of a computing system associated with a (e.g., generated and / or targeted) data block and / or a (e.g., physical and / or virtual) memory address targeted by the data access. For example, the context information may include a processor context parameter that identifies a processor in the computing system that generated the data block, a processor in the computing system that currently targets the data block, and / or a processor in the computing system that previously targeted the data block.

[0046] Furthermore, in some embodiments, context information may be indicated with varying levels of specificity. For example, the context information may additionally or alternatively include processor core context parameters that identify a processor core in a processor that generated the data block, a processor core in a processor that is currently targeting the data block, and / or a processor core in a processor that was previously targeting the data block. In some embodiments, the context information may additionally or alternatively include application (e.g., program or thread) context parameters that identify an application that caused the data block to be generated, an application that is currently targeting the data block, and / or an application that was previously targeting the data block. Additionally or alternatively, the context information may include application instruction (e.g., program counter) context parameters that identify an application instruction that caused the data block to be generated, an application instruction that is currently targeting the data block, and / or an application instruction that was previously targeting the data block.

[0047] Thus, in some embodiments, context information associated with one or more previous data accesses may be directly available to the processing subsystem of the computing system, e.g., because the processing circuitry in the processing subsystem is the entity that generates and / or targets the data blocks stored in the computing system. Additionally, in some embodiments, the memory controller may identify different context information as being associated with different transaction contexts. In other words, in some embodiments, different transaction contexts may be associated with different sets of context parameters, e.g., differing in the types of context parameters included, the number of context parameters included, and / or the values ​​of one or more context parameters.

[0048] As described above, in some embodiments, the value of the context parameter associated with the data access may identify one or more aspects of the computing system associated with the (e.g., generated and / or targeted) data block and / or the (e.g., physical and / or virtual) memory address targeted by the data access. Indeed, in some embodiments, the memory controller may predict that the aspect of the computing system that generated the data block will subsequently target the data block. Additionally or alternatively, the memory controller may predict that the aspect of the computing system that previously targeted the data block will subsequently target the data block again. In other words, in some embodiments, the context information associated with the data access may indicate one or more aspects of the computing that are expected to subsequently target the corresponding data block, such as during an upcoming control scope.

[0049] Thus, in some embodiments, analyzing historical data access information in light of corresponding context information may enable a memory controller to identify data access patterns associated with different aspects (e.g., transaction contexts) of a computing system. To facilitate analysis in light of the context information, in some embodiments, a memory controller may organize its historical data access information by transaction context. For example, a table of historical data access information may be organized into multiple sections (e.g., portions), each section dedicated to a different transaction context. In other words, the historical data access information may include a first section to indicate historical data access information associated with a first transaction context, a second section implemented to indicate historical data access information associated with a second (e.g., different) transaction context, and so on.

[0050] As an illustrative example, when the first context is a specific application (e.g., a program or thread) that targets the first data block and the third data block, the memory controller may store a first entry data block corresponding to the first data block and a third entry corresponding to the third data block in a first section of the historical data access information table, for example, in chronological order relative to each other and / or other entries corresponding to the data block associated with the specific application. Additionally or alternatively, when the second context is a system interrupt that targets the second data block, the memory controller may store a second entry corresponding to the second data block in a second section of the historical data access information table, for example, in chronological order relative to one or more other entries corresponding to the data block associated with the system interrupt. In this way, the memory controller can distinguish between data accesses associated with (e.g., generated by) different aspects of the computing system, thereby enabling the memory controller to determine previous data access patterns that are each associated with a specific aspect of the computing system (e.g., a transaction context). At least in some cases, this can facilitate improving the prediction accuracy of subsequent data access patterns, for example, by enabling the memory controller to adaptively adjust the weighting of historical data access information in its prediction.

[0051] To help illustrate, continuing with the above example, the memory controller may determine that because both the first entry corresponding to the first data block and the third entry corresponding to the third data block are included in the first section of the historical data access information table, the previous targeting of the first data block and the previous targeting of the third data block are associated with a specific application (e.g., a program or thread). In addition, the memory controller may determine that because the second entry corresponding to the second data block is included in the second section of the historical data access information table, the previous targeting of the second data block is associated with a system interrupt. Since the system interrupt occurs independently of the specific application, when predicting a subsequent data access pattern associated with the specific application (e.g., a first transaction context), the memory controller may weight the historical data access information associated with the first data block and the second data block more heavily and weight the historical data access information associated with the third data block less, for example, so that the historical data access information associated with the third data block is excluded from the prediction.

[0052] Additionally, as available in the processing subsystem, in some embodiments, a processor-side memory (e.g., cache and / or prefetch) controller may predictively control data storage in the processing subsystem based at least in part on the context information. For example, based at least in part on the context information and historical data access information available in the processing subsystem, the processor-side memory controller may predict subsequent data access patterns. To facilitate improved operational efficiency of the computing system, the processor-side memory controller may then adaptively adjust data storage in one or more memory (e.g., cache and / or buffer) tiers of the processing subsystem based at least in part on the predicted subsequent data access patterns.

[0053] For example, the processor-side memory controller may control data storage in the processor-side cache so that data blocks expected to be targeted within an upcoming control scope are stored (e.g., pre-fetched and / or maintained) in the processor-side cache before they are actually targeted by the processing circuitry. Additionally or alternatively, the processor-side memory controller may control data storage in the processor-side cache so that data blocks that are not expected to be targeted during the upcoming control scope are evicted from the processor-side cache, e.g., to make room for another data block expected to be targeted within the upcoming control scope. In this manner, the processor-side memory controller may be implemented and / or operated to predictively control data storage in one or more memory hierarchies of a corresponding processing subsystem, which may facilitate improved operation of a computing system in at least some circumstances. For example, by reducing the likelihood that a targeted data block will result in a miss at a lower memory hierarchy.

[0054] To facilitate further improvements in the operational efficiency of the computing system, in some embodiments, a memory-side memory controller may be implemented and / or operated to predictively control data storage in one or more memory tiers of the memory subsystem. As described above, in some embodiments, context information associated with data accesses is directly available to the processing subsystem, and therefore available to its processing-side memory controller. However, in some embodiments, the context information may not be directly available to the memory subsystem, and therefore not available to its memory-side memory controller. As described above, at least in some cases, predicting subsequent data access patterns without considering the transaction context may affect (e.g., reduce or limit) the accuracy of the prediction, thereby affecting the operational efficiency of the resulting computing system.

[0055] Therefore, to facilitate improved prediction accuracy in the memory subsystem, in some embodiments, the processing subsystem may communicate context information to the memory subsystem via a memory interface, for example, the memory interface includes a memory bus coupled between the processing subsystem and the memory subsystem, a processor-side bus interface coupled to the memory bus, a memory-side bus interface coupled to the memory bus, and / or a communication protocol that controls communication between the processing subsystem and the memory subsystem. In fact, in some embodiments, the processing subsystem may indicate one or more context parameters in a memory access request, for example, along with one or more access parameters. In other words, in such embodiments, the processing subsystem may output a memory access request indicating one or more context parameters associated with a data block and access parameters, such as a virtual memory address used by the processing circuit to identify the data block, a physical memory address used or to be used to store the data block in the memory subsystem, a size of the data block, and / or an access type (e.g., write or read) indicator (e.g., bit).

[0056] However, at least in some cases, the ability of a computing system to communicate background parameters between its processing subsystem and its memory subsystem may be limited by the memory interface (e.g., hardware and / or software) implemented therein. Specifically, in some embodiments, the memory interface may include a memory bus coupled between bus interfaces implemented in the processing subsystem and the memory subsystem. Typically, the memory bus may be implemented with a fixed number of conductors (e.g., conductive paths or traces), and the bus interface coupled to the memory bus may be implemented with a fixed number of pins. Thus, the communication bandwidth provided by the memory interface may typically be fixed, for example, such that the memory interface may be operated to communicate up to a fixed (e.g., maximum) number of bits in parallel within each clock cycle.

[0057] Additionally or alternatively, the memory interface may include a communication protocol that governs formatting and / or communication (e.g., timing and / or routing) of memory access requests. For example, to facilitate proper interpretation by the memory subsystem, the communication protocol may govern formatting of the memory access request into one or more parameter fields, each parameter field being operable to indicate a value of a corresponding parameter. Furthermore, in some embodiments, the communication protocol may govern timing and / or routing of one or more parameter fields communicated between the processing subsystem and the memory subsystem. For example, the communication protocol may govern clock cycles during which parameter fields are communicated (e.g., transmitted or received) and / or bus interface pins via which parameter fields are communicated.

[0058] However, at least in some cases, including one or more context parameters in a memory access request may result in an increase in the number of bits used to indicate the memory access request, such as compared to another (e.g., conventional) memory access request that does not include the context parameters. Indeed, in some embodiments, a memory access request may additionally or alternatively include one or more implementation parameters, which may result in a further increase in the number of bits used to indicate the memory access request, at least in some cases. For example, a memory access request may include a priority parameter and / or a cache bypass parameter, the priority parameter indicating an implementation priority of the memory access request. In some embodiments, a cache bypass parameter included in a read memory access request may indicate whether an instance of a target data block retrieved from a lower memory level should be stored in a lower (e.g., cache) memory level. Additionally or alternatively, a cache bypass parameter included in a write memory access request may indicate whether an instance of a target data block to be stored in a higher memory level should also be stored in a lower (e.g., cache) memory level.

[0059] In some embodiments, the processing subsystem may include a request (e.g., command) queue that stores memory access requests before output to the memory subsystem via a memory bus. In other words, at least in such embodiments, the processor-side memory controller may generate memory access requests and store the memory access requests in a request queue. The memory access requests may then be retrieved from the request queue and output to the memory bus via a processor-side bus interface. To facilitate the inclusion of context parameters and / or implementation parameters in the memory access requests, in some embodiments, the bit width of entries in the request queue may be expanded to accommodate the increased number of bits per memory access request.

[0060] Furthermore, to facilitate the inclusion of context parameters and / or implementation parameters in memory access requests, memory interfaces in computing systems may be adjusted to accommodate the increase in the number of bits per memory access request. Specifically, in some embodiments, a communication protocol used by a memory interface may be adjusted to allocate one or more context parameter fields that may each be used to indicate a value for a corresponding context parameter, e.g., in addition to one or more access parameter fields, each access parameter field may be used to indicate a value for a corresponding access parameter. Additionally or alternatively, a communication protocol may be adjusted to allocate one or more implementation parameter fields that may each be used to indicate a value for a corresponding implementation parameter.

[0061] Furthermore, as described above, the communication bandwidth provided by the memory interface typically has a fixed upper limit, e.g., governed by the number of conductors implemented in the memory bus and / or the number of pins implemented in the bus interface coupled to the memory bus. To facilitate the inclusion of context parameters and / or implementation parameters in the memory access request, in some embodiments, the communication protocol may be adjusted to increase the number of clock cycles during which the memory access request is communicated (e.g., transmitted and / or received). For example, the processing subsystem may output an access parameter field of the memory access request during a first clock cycle and output a context parameter field of the memory access request during a second (e.g., a different, previous, or subsequent) clock cycle. However, in at least some cases, increasing the number of clock cycles during which the memory access request is communicated may delay the response of the memory subsystem and, therefore, affect the operating efficiency of the computing system.

[0062] Therefore, to facilitate the inclusion of context parameters and / or implementation parameters in memory access requests, in some embodiments, the memory interface may be additionally or alternatively adjusted to increase the communication bandwidth provided between the processing subsystem and the memory subsystem. In some embodiments, the communication bandwidth may be increased by increasing the number of parallel data paths, each of which includes a pair of bus interface pins and a memory bus conductor implemented in the memory interface coupled between the pair of bus interface pins. In other words, at least in such embodiments, the memory interface may be adjusted to increase the number of conductors included in the memory bus and to increase the number of pins in each bus interface coupled to the memory bus.

[0063] In some embodiments, by increasing the number of data paths, the number of bits communicated per clock cycle can be increased, thereby increasing the communication bandwidth provided by the memory interface. In fact, to take advantage of the increased communication bandwidth, in some embodiments, a computing system can be implemented and / or operated to communicate different parameter fields in parallel via different data paths (e.g., sets of bus interface pins and memory bus conductors) in the memory interface. For example, the memory interface can include a first data path including a first processor-side bus interface pin, a first memory-side bus interface pin, and a first memory bus conductor coupled therebetween, and a second data path including a second processor-side bus interface pin, a second memory-side bus interface pin, and a second memory bus conductor coupled therebetween. In some embodiments, a computing system can be implemented and / or operated to communicate access parameter fields via the first data path while communicating background parameter fields via the second data path.

[0064] In other words, at least in such embodiments, the computing system may be implemented and / or operated to communicate the context parameters indicated in the context parameter field during the same clock cycle as the access parameters indicated in the access parameter field (e.g., rather than during different (e.g., consecutive) clock cycles). Indeed, in some embodiments, increasing the communication bandwidth provided by the memory interface may facilitate reducing the number of clock cycles during which memory access requests are communicated, and thus, at least in some cases, may facilitate improving the operating efficiency of the computing system. However, at least in some cases, increasing the communication bandwidth may impact (e.g., increase) the implementation-associated cost of the computing system, for example, by causing an increase in its physical footprint, its component count, and / or the number of manufacturing steps used to implement the computing system.

[0065] To facilitate reducing the impact of the inclusion of context information on operational efficiency and / or implementation-associated costs, in some embodiments, the processing subsystem may hash the values ​​of one or more context parameters before transmitting (e.g., outputting or supplying) them to the memory subsystem. For example, the processor-side memory controller may perform a hash operation (e.g., a function) on the values ​​of the one or more context parameters to determine a hashed context parameter having a fixed bit length. In such embodiments, the communication protocol of the memory interface may be adjusted to allocate one or more hashed context parameter fields, each of which may be used to indicate the value of a corresponding hashed context parameter.

[0066] In addition, in some embodiments, the fixed bit depth of the hashed background parameter may be less than the combined bit depth of one or more background parameters that are hashed to generate the hashed background parameter. In other words, in some embodiments, hashing one or more background parameters before transmitting them to the memory subsystem may facilitate reducing the total number of bits communicated via the memory interface, and therefore, the inclusion of the background parameter has an impact on the operating efficiency and implementation-associated costs of the computing system. Specifically, reducing the total number of bits used to indicate a memory access request may enable fewer data paths to be implemented in the memory interface, which may, at least in some cases, facilitate reducing the implementation-associated costs of the computing system, for example, by reducing the physical footprint and / or component count of its memory interface. Additionally or alternatively, reducing the total number of bits used to indicate a memory access request may enable the memory access request to be communicated using fewer clock cycles, which may, at least in some cases, facilitate improving the operating efficiency of the computing system, for example, by reducing the delay before the memory subsystem responds to the memory access request.

[0067] In some embodiments, when receiving context information using hash context parameters, the memory subsystem may use hash context parameter values ​​to track the context of data accesses, e.g., instead of explicitly redetermining the original value of the context parameter used to generate the hash context parameter value. In other words, at least in such embodiments, the memory-side memory controller may determine that data blocks and / or memory addresses associated with different hash context parameter values ​​correspond to different transaction contexts. For example, the memory-side memory controller may organize its historical data access information table so that different sections are each associated with different hash context parameter values.

[0068] However, in some embodiments, hashing the values ​​of one or more context parameters to produce hashed context parameters with a lower bit depth may result in a certain amount of precision loss. For example, in some cases, performing a hash operation on a first application instruction context parameter that identifies a first application instruction and a second application instruction context parameter that identifies a second application instruction different from the first application instruction may still result in the same hashed context parameter value. Therefore, at least in such cases, the hash operation performed by the memory controller may result in the memory-side memory controller improperly identifying the context of a memory access request.

[0069] In other words, in some embodiments, the hash function used by the processor-side memory controller may trade off between the resulting prediction accuracy and the total number of bits used to indicate the memory access request. In fact, in some embodiments, the processor-side memory controller may, for example, selectively utilize different hash functions, which result in different output bit depths and therefore make different trade-offs between prediction accuracy and the number of bits per memory access request. In order to facilitate proper interpretation of the hash context parameters included in the memory access request, at least in such embodiments, the processor-side memory controller may, for example, indicate the hash function used to generate the hash context parameters via the hash function context parameters indicated in the additional context parameter field of the memory access request.

[0070] Furthermore, to facilitate improved operational flexibility, in some embodiments, the communication protocol of the memory interface may be adjusted to enable different types of context parameters to be indicated in different memory access requests. For example, both the first memory access request and the second memory access request may include a context parameter field. However, the context parameter field in the first memory access request may be used to indicate the value of the application instruction context parameter, while the context parameter field in the second memory access request is used to indicate the value of the processor context parameter. To facilitate proper interpretation of the context parameters included in the different memory access requests, at least in such embodiments, the processor-side memory controller may indicate the type of context parameter indicated in the context field of the memory access request, for example, via a context type context parameter indicated in an additional context parameter field of the memory access request.

[0071] In this manner, as will be described in more detail below, a computing system may be implemented and / or operated in accordance with the present disclosure to facilitate communicating context information between its processing subsystem and its memory subsystem. As will be described in more detail below, in some embodiments, communicating context information to the memory subsystem may enable the memory subsystem to predict subsequent (e.g., upcoming) data access patterns based at least in part on the context information, and to control data storage in the memory subsystem accordingly, such as causing data blocks expected to be targeted by the subsequent data access pattern to be stored in a lower memory tier and / or data blocks not expected to be targeted by the subsequent data access pattern to be evicted to a higher memory tier. In other words, at least in some cases, implementing and / or operating a computing system in this manner may facilitate improving data retrieval latency provided by its memory subsystem, and thus improve the operating efficiency of the computing system.

[0072] To help illustrate, Figure 11 shows an example of a computing system 10 (e.g., an apparatus) that includes a processing subsystem 12 (e.g., a system) and a memory subsystem 14 (e.g., a system). It should be appreciated that the depicted example is intended to be illustrative only and not limiting. Specifically, computing system 10 may additionally or alternatively include other computing subsystems. For example, computing system 10 may additionally include a networking subsystem, a radio frequency subsystem, a user input subsystem, and / or a display subsystem.

[0073] In addition, in some embodiments, computing system 10 may be implemented in a single electronic device, such as a desktop computer, a workstation computer, a laptop computer, a server, a mobile phone, a virtual reality head-mounted device, and / or the like. In other embodiments, computing system 10 may be distributed among multiple electronic devices. For example, processing subsystem 12 and memory subsystem 14 may be implemented in a host device, while other computing subsystems, such as a user input subsystem and / or a display subsystem, may be implemented in a client (e.g., remote) device. In fact, in some embodiments, computing subsystems may be distributed among multiple electronic devices. For example, a first portion of processing subsystem 12 and / or a first portion of memory subsystem 14 may be implemented in a host device, while a second portion of processing subsystem 12 and / or a second portion of memory subsystem 14 may be implemented in a client device.

[0074] In any case, during operation of computing system 10, processing subsystem 12 typically performs various operations, such as to determine output data by executing instructions in a processor to perform corresponding data processing operations on input data. Thus, as in the depicted example, processing subsystem 12 may include processing circuitry 16. In some embodiments, processing circuitry 16 may be included in one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more processor cores, or any combination thereof.

[0075] Additionally, as in the depicted example, processing circuitry 16 may include one or more registers 22. In some embodiments, registers 22 may provide one or more storage locations that may be directly accessed by processing circuitry 16. The storage capacity of registers 22 is typically limited. Thus, processing subsystem 12 may be communicatively coupled to memory subsystem 14 that provides additional data storage capacity via one or more communication buses 20. In some embodiments, communication bus 20 may include one or more cables, one or more wires, one or more conductive traces, one or more communication networks, or any combination thereof.

[0076] In other words, the processing subsystem 12 and the memory subsystem 14 may communicate via one or more communication buses 20. For example, the processing subsystem 12 may communicate (e.g., output or transmit) write memory access requests and read memory access requests for data stored in the memory subsystem 14 and / or targeting data previously stored in the memory subsystem 14. Additionally or alternatively, the memory subsystem 14 may communicate (e.g., output or transfer back) target data previously stored therein, such as in response to a read memory access request, to enable processing and / or execution by the processing circuit 16 implemented in the processing subsystem 12.

[0077] To enable communication via the communication bus 20 as in the depicted example, the processing subsystem 12 and the memory subsystem 14 may each include one or more bus interfaces 32. Additionally, as in the depicted example, to provide data storage, the memory subsystem 14 may include one or more memory devices 18 (e.g., chips or integrated circuits). As will be described in more detail below, in some embodiments, the memory devices 18 may include memory cells (e.g., circuits) organized into one or more memory arrays 28, and thus may include one or more tangible, non-transitory computer-readable media. For example, the memory subsystem 14 may include one or more memory devices 18 that are communicatively coupled to the processing subsystem 12 via a memory (e.g., external) bus 20.

[0078] However, as described above, communication between different computing subsystems is generally slower than communication within a computing subsystem. In other words, data communication within (e.g., internal to) the processing subsystem 12 may be faster and thus help reduce data retrieval latency compared to data communication between the processing subsystem 12 and the memory subsystem 14, e.g., due to sharing the communication bus 20 with other computing subsystems, timing differences between the processing subsystem 12 and the memory subsystem 14, and / or the communication distance between the processing subsystem 12 and the memory subsystem 14. Therefore, to facilitate improved operational efficiency, one or more caches and / or one or more buffers may be implemented between the processing circuitry 16 of the processing subsystem 12 and the memory devices 18 of the memory subsystem 14. As will be described in more detail below, in some embodiments, a cache may provide storage locations organized into one or more cache lines 30 to, for example, store instances (e.g., copies) of data that are also stored in a memory array 28 implemented in one or more memory devices 18.

[0079] As in the depicted example, computing system 10 may include one or more processor-side caches 24 implemented in processing subsystem 12. In some embodiments, one or more of processor-side caches 24 may be integrated with processing circuitry 16. For example, processor-side cache 24 may include a level one (L1) cache, a level two (L2) cache, and / or a level three (L3) cache. To facilitate reducing data retrieval latency, in some embodiments, processor-side cache 24 may be implemented using a different memory type than memory device 18 implemented in memory subsystem 14. For example, processor-side cache 24 may be implemented by static random access memory (SRAM) while memory device 18 is implemented by dynamic random access memory (DRAM) and / or non-volatile memory.

[0080] Additionally, as in the depicted example, the computing system 10 may include one or more memory-side caches 26 implemented in the memory subsystem 14. Despite being implemented in the memory subsystem 14, the memory-side caches 26 may provide faster data communications than a memory array 28 implemented in a memory device 18, for example, because the memory-side caches 26 are implemented using static random access memory (SRAM) while the memory devices 18 are implemented using dynamic random access memory (DRAM). Additionally or alternatively, the memory-side caches 26 and the memory arrays 28 implemented in one or more memory devices 18 may utilize the same memory type (e.g., DRAM). In fact, in some embodiments, one or more of the memory-side caches 26 may be implemented in the memory device 18.

[0081] Furthermore, as in the depicted example, computing system 10 may include one or more prefetch buffers 31. For example, processing subsystem 12 may include a processor-side prefetch buffer 31A that is distinct (e.g., separate) from its processor-side cache 24. Additionally or alternatively, memory subsystem 14 may include a memory-side prefetch buffer 31B that is distinct (e.g., separate) from its memory-side cache 26. Prefetch buffers 31 may be implemented and / or operated to store data that is prefetched (e.g., extracted before being actually targeted by processing circuitry 16) from a higher memory hierarchy (e.g., before the prefetched data is transferred to the cache). In other embodiments, prefetched data may be stored directly into the cache, and thus, prefetch buffers 31 may be optional.

[0082] In any case, to facilitate control of data storage therein, computing system 10 may include one or more memory controllers 34 communicatively coupled to caches, prefetch buffers 31, and / or memory devices 18, e.g., via instruction bus 20A. In some embodiments, memory controller 34 may include cache controller 35 implemented and / or operated to control data storage in one or more cache memory levels. Additionally or alternatively, memory controller 34 may include prefetch controller 37 implemented and / or operated to control data storage in one or more prefetch buffer memory levels.

[0083] Furthermore, in some embodiments, the memory controller 34 may additionally or alternatively include a main memory controller 41, such as a DRAM memory controller 34, which is implemented and / or operated to control data storage in one or more memory array memory hierarchies. Thus, in some embodiments, one or more memory controllers 34 may be implemented in the memory subsystem 14, for example, as a memory-side memory controller 34. Additionally or alternatively, one or more memory controllers 34 may be implemented in the processing subsystem 12, for example, as a processor-side memory controller 34.

[0084] To help illustrate, Figure 2 1 shows an example of a processing subsystem 12A including a processor-side memory controller 34A. As described above, in some embodiments, the processing circuitry 16 of the processing subsystem 12 may be implemented using one or more processor cores 36. For example, the processing circuitry 16A in the processing subsystem 12A may include at least a first processor core 36A and an Nth processor core 36N. However, it should be understood that the depicted examples are intended to be illustrative and not limiting. For example, in other embodiments, the processing subsystem 12 may include a single processor core 36 or more than two (e.g., four, eight, or sixteen) processor cores 36.

[0085] Additionally, as described above, in some embodiments, the processing subsystem 12 may include one or more registers 22 that provide storage locations that are directly accessible by its processing circuitry 16. For example, the processing subsystem 12A may include at least a first register 22A that provides a storage location that is directly accessible by the first processor core 36A and an Nth register 22N, the first register providing a storage location that is directly accessible by the first processor core 36A and the Nth register providing a storage location that is directly accessible by the Nth processor core 36N. To facilitate increasing the storage provided on the processor side of the memory bus 20B, as described above, the processing subsystem 12 may include one or more processor-side caches 24 and / or processor-side prefetch buffers 31A. In some embodiments, the processor-side caches 24 and / or processor-side prefetch buffers 31A may be implemented using volatile memory, such as static random access memory (SRAM) and / or dynamic random access memory (DRAM).

[0086] In addition, in some embodiments, the processor-side cache 24 may be organized to implement one or more hierarchical memory (e.g., cache) levels. For example, the processor-side cache 24A may include a dedicated processor-side cache 38, which may be used to implement one or more lower (e.g., lowest) memory levels, and a shared processor-side cache 40, which may be used to implement higher (e.g., middle) memory levels. In some embodiments, the data storage provided by the shared processor-side cache 40 may be shared by at least the first processor core 36A and the Nth processor core 36N. For example, the shared processor-side cache 40 may include one or more level three (L3) processor-side caches 24A.

[0087] On the other hand, in some embodiments, the data storage provided by the dedicated processor-side cache 38 may be dedicated to the corresponding processor core 36. For example, the first one or more dedicated processor-side caches 38A may include a level 1 (L1) processor-side cache 24A dedicated to the first processor core 36A and a level 2 (L2) processor-side cache 24A dedicated to the first processor core 36A. Additionally or alternatively, the Nth one or more dedicated processor-side caches 38N may include a level 1 (L1) processor-side cache 24A dedicated to the Nth processor core 36N and a level 2 (L2) processor-side cache 24A dedicated to the Nth processor core 36N.

[0088] In any case, the processor-side memory controller 34A may generally control data storage in the processing subsystem 12A. For example, the processor-side memory controller 34A may control data storage such that data targeted by the processing circuit 16A is returned to one or more of its registers 22. In other words, in some embodiments, the processor-side memory controller 34A controls data storage in the processor-side cache 24A, the processor-side prefetch buffer 31A, and / or the registers 22 implemented in the processing subsystem 12A. Thus, as in the depicted example, the processor-side memory controller 34A may be communicatively coupled to the processing circuit 16A, the processor-side cache 24A, and / or the processor-side prefetch buffer 31A via one or more processor-side internal buses 20C, e.g., to enable the processor-side memory controller 34A to determine data targeted by the processing circuit 16A and / or to output control (e.g., command) signals that instruct (e.g., cause) the processing subsystem 12A to adjust data storage therein.

[0089] Indeed, to facilitate increased data access speeds and, therefore, increased operational efficiency of computing system 10, in some embodiments, processor-side memory controller 34A may predictively control data storage in processing subsystem 12A, e.g., based at least in part on processor-side historical data access information 39A. In other words, in such embodiments, processor-side memory controller 34A may control data storage in processing subsystem 12A based at least in part on data that is expected to be targeted (e.g., requested) by processing circuit 16A and / or the time at which data is expected to be targeted (e.g., requested) by processing circuit 16A. For example, processor-side memory controller 34A may control data storage such that instances (e.g., copies) of a data block that is expected to be targeted (e.g., requested) by processing circuit 16A during an upcoming control scope (e.g., one or more clock cycles) are stored in one or more of processor-side caches 24 before processing circuit 16A actually targets (e.g., requests) data block 29.

[0090] However, as described above, the storage capacity implemented in the processing subsystem 12 is typically less than the storage capacity implemented in the corresponding memory subsystem 14. In fact, in some embodiments, the total storage capacity of the processor-side cache 24 may be less than the storage capacity of the memory array 28 implemented in the memory subsystem 14. Thus, to facilitate saving (e.g., optimizing) the storage capacity of the processor-side cache 24, in some embodiments, the processor-side memory controller 34A may control data storage in the processing subsystem 12A such that instances of the data blocks 29 that are not expected to be targeted by the processing circuit 16A during the upcoming control scope are not stored in the processor-side cache 24.

[0091] However, the data access pattern predicted by the memory controller 34 is often not entirely satisfactory. In other words, at least in some cases, the predicted data access pattern determined by the processor-side memory controller 34A may differ at least in part from the actual data access pattern of the processing circuit 16A. Therefore, at least in such cases, the data targeted by the processing circuit 16A may not be currently stored in the processing subsystem 12A and thus result in a processor-side miss.

[0092] As described above, when a processor-side miss is caused, the processing subsystem 12A may request the return of target data from the memory subsystem 14 coupled to the memory bus 20B. For example, the processor-side memory controller 34A may output a read memory access request that returns data targeted by the processing circuit 16A. Additionally or alternatively, the processor-side memory controller 34A may output a write memory access request along with data requesting that data be stored in the memory subsystem 14. In some embodiments, the processor-side memory controller 34A may store the memory access request in a request (e.g., command) queue 42, which is then supplied to the memory subsystem 14 via the memory bus 20B.

[0093] Furthermore, in some embodiments, the processor-side memory controller 34A may control data storage in the processing subsystem 12A so that data received (e.g., returned) via the memory bus 20B is stored in the registers 22 of the processing circuit 16A and / or the processor-side cache 24A. For example, the processing subsystem 12A may store a copy of a block of data returned via the memory bus 20B in one or more processor-side caches 24A to facilitate reducing data retrieval latency in the event that the processing circuit 16A targets the block of data again. Additionally or alternatively, for example, when a cache bypass parameter (e.g., high or "1 bit") is set by a memory access instruction (e.g., a non-temporal load instruction) of an application (e.g., a program or thread), the processing subsystem 12A may store a copy of a block of data returned via the memory bus 20B directly into one or more registers 22 of the processing circuit 16A.

[0094] Thus, as in the depicted example, the processor-side bus interface 32A may be coupled between the memory bus 20B and one or more processor-side internal buses 20C. Additionally, as in the depicted example, the processor-side bus interface 32A may include one or more pins 44. As will be described in more detail below, in some embodiments, each pin 44 of the bus interface 32 may be coupled to a corresponding conductor in the memory bus 20B. By implementing the processing subsystem 12 in this manner, the processor-side memory controller 34A may be operated to, for example, predictively control data storage in the processing subsystem 12 during operation of the corresponding computing system 10.

[0095] To help further illustrate, in Figure 3An example of a process 46 for operating the processing subsystem 12 is described in . In general, the process 46 includes determining a data block targeted by the processing circuit (processing block 48), determining whether the target data block causes a processor-side miss (decision block 50), and when the target data block does not cause a processor-side miss, outputting the target data block from the processor-side cache to the processing circuit (processing block 52). In addition, when the target data block causes a processor-side miss, the process 46 includes requesting the target data block from the memory subsystem (processing block 56), determining whether the target data block has been returned from the memory subsystem (decision block 58), and after the target data block is returned from the memory subsystem, supplying the target data block to the processing circuit (processing block 60). In addition, the process 46 includes updating the historical data access information (processing block 61).

[0096] Although described in a particular order representing a particular embodiment, it should be noted that process 46 may be performed in any suitable order. Additionally, embodiments of process 46 may omit processing blocks and / or include additional processing blocks. Furthermore, in some embodiments, process 46 may be implemented at least in part by executing instructions stored in a tangible, non-transitory computer-readable medium (e.g., a memory implemented in memory controller 34) using processing circuitry (e.g., a processor implemented in memory controller 34).

[0097] Thus, in some embodiments, a processor-side (e.g., cache and / or prefetch) memory controller 34A in a processing subsystem 12 of a computing system 10 may determine a data block targeted by a processing circuit 16 of the processing subsystem 12 (processing block 48). In some embodiments, the processing circuit 16 may identify the target data block using a corresponding (e.g., target) virtual memory address. In some embodiments, based at least in part on the target virtual memory address, the processor-side memory controller 34A may determine a corresponding (e.g., target) physical memory address indicating a storage location of the target data block in the computing system 10.

[0098] Additionally, the processor-side memory controller 34A may determine whether the target data block resulted in a processor-side miss (decision block 50). In some embodiments, the memory controller 34 may determine whether the data block is stored in the cache based at least in part on a virtual memory address and / or a physical memory address associated with the data block. For example, the memory controller 34 may determine a target value for a tag parameter (e.g., metadata) that is expected to be associated with the target data block based at least in part on its virtual memory address and physical memory address.

[0099] By searching valid cache lines 30 contained in the processor-side cache 24 based on the target tag parameter value, the processor-side (e.g., cache) memory controller 34A may determine whether the target data block causes a processor-side miss. For example, when the target tag parameter value does not match the tag parameter value contained in any cache line 30 in the processor-side cache 24, the processor-side memory controller 34A may determine that the target data block causes a processor-side miss. On the other hand, when the target tag parameter value is included in one or more cache lines 30 of the processor-side cache 24, the processor-side memory controller 34A may determine that the target data block causes a processor-side cache hit, and therefore does not cause a processor-side cache miss.

[0100] When the target data block does not result in a processor-side miss, the processor-side memory controller 34A may instruct the processor-side cache 24 to supply the target data block to the processing circuit 16, e.g., to facilitate increased data retrieval speed and thus increased operating efficiency of the computing system 10 (processing block 52). In some embodiments, the processor-side cache 24 may output a cache line 30 having a tag parameter value that matches a target tag parameter value that is expected to be associated with the target data block. In some embodiments, when stored in a higher memory (e.g., cache) hierarchy (e.g., shared processor-side cache 40), the target data block may pass through one or more lower memory hierarchies (e.g., dedicated processor-side cache 38) in the processing subsystem 12 before reaching the processing circuit 16.

[0101] On the other hand, when it results in a processor-side cache miss, the processor-side memory controller 34A may request the target data block from the memory subsystem 14 of the computing system 10 (processing block 56). For example, the processor-side memory controller 34A may request the target data block to be returned by outputting a memory access request that includes one or more access parameters to be used by the memory subsystem 14 to retrieve the target data block. As described above, in some embodiments, the memory access request generated by the processor-side memory controller 34A may be stored in the request (e.g., command) queue 42 before being output to the memory subsystem 14 via the memory bus 20B.

[0102] In addition, as will be described in more detail below, in some embodiments, the values ​​of the access parameters may be indicated in the corresponding access parameter fields included in the memory access request. For example, a virtual memory address used by the processing circuit 16 to identify the target data block may be indicated in the first access parameter field, a physical memory address identifying the storage location of the target data block in the memory subsystem 14 may be indicated in the second access parameter field, the size of the target data block (e.g., bit depth) may be indicated in the third access parameter field, a write access indicator (e.g., bit) may be indicated in the fourth access parameter field, or any combination thereof. Thus, as will be described in more detail below, the memory subsystem 14 may identify and return the target data block based at least in part on the values ​​of one or more access parameters indicated in the memory access request.

[0103] Once the target data block is returned from the memory subsystem 14, the processor-side memory controller 34A may instruct the processing subsystem 12 to supply the target data block to the processing circuitry 16 (processing block 60). In some embodiments, the processor-side memory controller 34A may instruct the processing subsystem 12 to store a copy of the target data block returned from the memory subsystem 14 in one or more registers 22 of the processing circuitry 16. Additionally, in some embodiments, the processor-side memory controller 34A may instruct the processing subsystem 12 to store a copy of the target data block in one or more processor-side caches 24, for example, to facilitate reducing data retrieval latency in the event that the processing circuitry 16 subsequently targets the data block again.

[0104] In this manner, the processing subsystem 12 in the computing system 10 may be operated to provide target data to its processing circuit 16, for example, to enable the processing circuit 16 to execute and / or process the target data. As described above, to facilitate improved operational efficiency of the computing system, in some embodiments, the processor-side memory controller 34A may predictably control the storage of data in the processing subsystem 12. For example, the processor-side memory controller 34A may predictably control what data is stored in the processing subsystem 12 and / or the level of memory (e.g., cache and / or pre-fetch buffer) at which data is stored in the processing subsystem 12.

[0105] As will be described in greater detail below, in some embodiments, the memory controller 34 may predictively control data storage based at least in part on historical data access information indicating one or more previous data access patterns. Thus, to facilitate predictive control of data storage during a subsequent control scope (e.g., one or more clock cycles), the processor-side memory controller 34A may update its processor-side historical data access information 39A to indicate information associated with accessing (e.g., targeting and / or requesting) target data (processing block 61). In some embodiments, a table structure may be used to indicate (e.g., store and / or read) the historical data access information 39.

[0106] To help illustrate, Figure 4 , which may be monitored and / or utilized by a (e.g., processor-side or memory-side) memory controller 34. As in the depicted example, the historical data access information table 69 may include one or more entries (e.g., rows) 71. Additionally, as in the depicted example, each entry 71 may include a block identifier field (e.g., column) 73, a write time field 75, a last access time field 77, and an access count field 79. However, it should be appreciated that the depicted example is intended to be illustrative only and not limiting. For example, in other embodiments, the historical data access information table 69 may additionally or alternatively include other types of data, fields, and / or information.

[0107] In any case, with respect to the described example, each entry 71 in the historical data access information table 69 may identify an associated data block in its block identifier field 73. For example, a first block identifier parameter in the first entry 71A may indicate that the first entry is associated with a first data block. Similarly, a second block identifier parameter in the second entry 71B may indicate that the second entry 71B is associated with a second data block, and a J-th block identifier parameter in the J-th entry 71J may indicate that the J-th entry 71J is associated with a J-th data block. In some embodiments, an entry 71 may identify a corresponding data block via its virtual memory address, its physical memory address, and / or a tag parameter value (e.g., determined based on the virtual memory address and / or physical memory address of the corresponding data block).

[0108] Additionally, as in the depicted example, each entry 71 in the historical data access information table 69 may associate a corresponding data block with a write time parameter indicated in a write time field 75, a last access time parameter indicated in a last access time field 77, and an access count parameter indicated in an access count field 79. For example, a first entry 71A may associate a first data block with a write time parameter indicating when the first data block was initially stored in the memory subsystem 14, a last access time parameter indicating when the first data block was most recently accessed (e.g., targeted or requested), and an access count parameter indicating the number of times the first data block has been accessed. Additionally, a second entry 71A may associate a second data block with a write time parameter indicating when the second data block was initially stored in the memory subsystem 14, a last access time parameter indicating when the second data block was most recently accessed, and an access count parameter indicating the number of times the second data block has been accessed. In addition, the Jth entry 71J may associate the Jth data block with a write time parameter indicating when the Jth data block was initially stored in the memory subsystem 14, a last access time parameter indicating when the Jth data block was most recently accessed, and an access count parameter indicating the number of times the Jth data block has been accessed.

[0109] Furthermore, as in the depicted example, the entries 71 in the historical data access information table 69 may be organized into a plurality of table sections 81. In some embodiments, different table sections 81 in the historical data access information table 69 may be dedicated to different transaction contexts. For example, the first table section 81A may be dedicated to indicating entries 71 corresponding to data blocks associated with a first transaction context, while the first table section 81I may be dedicated to indicating entries 71 corresponding to data blocks associated with a first (e.g., second or different) transaction context. However, again, it should be understood that the depicted example is intended to be illustrative only and not limiting. For example, in other embodiments, the entries 71 in the historical data access information table 69 may be organized into more than two table sections 81.

[0110] As will be described in greater detail below, in some embodiments, a transaction context associated with a data block may be indicated via context information (e.g., one or more parameters) that identifies one or more aspects of a computing system associated with the (e.g., generated and / or targeted) data block and / or a corresponding memory address (e.g., physical and / or virtual). For example, the context information associated with the data block may include processor context parameters that identify one or more processors in the computing system 10 that generated the data block, currently targets the data block, and / or previously targeted the data block. Additionally, in some embodiments, the transaction context information associated with the data block may include processor core context parameters that identify one or more processor cores 36 in the computing system 10 that generated the data block, currently targets the data block, and / or previously targeted the data block. Furthermore, in some embodiments, the transactional context information associated with a data block may include application (e.g., program or thread) context parameters identifying one or more application programs that caused the data block to be generated, currently targets the data block, and / or previously targeted the data block when executed in computing system 10. Furthermore, in some embodiments, the transactional context information associated with a data block may include application instruction (e.g., program counter) context parameters identifying one or more application instructions that, when executed by computing system 10, caused the data block to be generated, currently targets the data block, and / or previously targeted the data block.

[0111] In some embodiments, different sets of context parameters may correspond to different transaction contexts. For example, a first transaction context associated with the first table section 81A may correspond to a first set of context parameters, the first set of context parameters including a processor context parameter identifying a processor associated with the first data block and the second data block, and an application context parameter identifying an application associated with the first data block and the second data block. On the other hand, a first transaction context associated with the first table section 81I may correspond to a first set of context parameters including a processor context parameter identifying a processor associated with the Jth data block.

[0112] In other words, in some embodiments, the (e.g., processor-side and / or memory-side) memory controller 34 may determine a transaction context associated with a data access by comparing the values ​​of one or more context parameters associated with the data access with corresponding context parameter values ​​associated with one or more candidate transaction contexts. In some embodiments, the value of each context parameter associated with the data access and the candidate transaction context may unambiguously (e.g., specifically or directly) identify a corresponding aspect of the computing system 10. Thus, in such embodiments, the memory controller 34 may identify the candidate transaction context associated with the context parameter values ​​as the transaction context of the data access, each context parameter value matching a corresponding context parameter value associated with the data access.

[0113] In other embodiments, the values ​​of one or more context parameters associated with the data access may be hashed to generate a hashed context parameter. In other words, in such embodiments, the values ​​of the hashed context parameters associated with the data access and the candidate transaction context may indirectly identify one or more aspects of the computing system 10. Thus, in some embodiments, the memory controller 34 may identify different hashed context parameter values ​​corresponding to different transaction contexts. In other words, in such embodiments, the memory controller 34 may identify the candidate transaction context associated with the hashed context parameter value as the transaction context of the data access, and the hashed context parameter value matches the hashed context parameter value associated with the data access.

[0114] Based at least in part on the transactional context of the data access, e.g., in response to receiving a memory access request and / or satisfying a memory access request, the memory controller 34 may update its historical data access information 39 accordingly. Specifically, in some embodiments, the memory controller 34 may add entries 71 corresponding to data blocks targeted by the data access to the table section 81 associated with the transactional context of the data access, e.g., in chronological order relative to other entries 71 in the table section 81, to facilitate identification of previous data access patterns associated with the transactional context. Additionally or alternatively, the memory controller 34 may update a last access time parameter and / or increment an access count parameter indicated in an entry 71 associated with a data block targeted by the data access. In this manner, the historical data access information 39 may be organized at least in part based on the transactional context, which may, at least in some cases, facilitate improved prediction accuracy, and thus facilitate effectiveness of predictive data storage control techniques.

[0115] To help illustrate, Figure 5An example of a process 62 for predictively controlling data storage is described in . Generally, process 62 includes determining historical data access information (processing block 64), and predicting subsequent data access patterns based on the historical data access information (processing block 66). Additionally, process 62 includes controlling data storage in a memory hierarchy based on the predicted data access patterns (processing block 68).

[0116] Although described in a particular order representing a particular embodiment, it should be noted that process 62 may be performed in any suitable order. Additionally, embodiments of process 62 may omit processing blocks and / or include additional processing blocks. Furthermore, in some embodiments, process 62 may be implemented at least in part by executing instructions stored in a tangible, non-transitory computer-readable medium (e.g., a memory implemented in memory controller 34) using processing circuitry (e.g., a processor implemented in memory controller 34).

[0117] Thus, in some embodiments, the (e.g., processor-side and / or memory-side) memory controller 34 may determine historical data access information (processing block 64). For example, the processor-side (e.g., cache and / or prefetch) memory controller 34A may determine processor-side historical data access information 39A associated with one or more previous data (e.g., memory) accesses organized in a transaction context. Additionally or alternatively, as will be described in greater detail below, the memory-side (e.g., main) memory controller 34 may determine memory-side historical data access information 39 associated with one or more previous data (e.g., memory) accesses organized in a transaction context.

[0118] Furthermore, in some embodiments, the historical data access information 39 may be stored in a tangible, non-transitory computer-readable medium, such as a static random access memory (SRAM) implemented in or coupled to (e.g., processor-side and / or memory-side) the memory controller 34. Thus, in such embodiments, the memory controller 34 may retrieve the historical data access information 39 from the tangible, non-transitory computer-readable medium. Furthermore, as described above, in some embodiments, the historical data access information 39 may be organized by transaction context via the historical data access information table 69, which indicates entries 71 corresponding to different transaction contexts in different table sections 81.

[0119] Based at least in part on the historical data access information 39, the memory controller 34 may predict data access patterns that are expected to occur during an upcoming control horizon (e.g., a time period or one or more clock cycles) (processing block 66). As described above, in some embodiments, the historical data access information 39 may indicate what data was previously accessed (e.g., targeted or requested), when the data was previously accessed, and / or the order in which the data was previously accessed. In other words, at least in such embodiments, the memory controller 34 may determine one or more previous data access patterns based at least in part on the historical data access information 39. Because data access patterns are often repetitive (e.g., cyclical) to some extent, in some embodiments, the memory controller 34 may predict subsequent data access patterns based at least in part on the historical data access information 39 indicating previous data access patterns.

[0120] Specifically, in some embodiments, the memory controller 34 may predict what data will be targeted in an upcoming control scope, when the data will be targeted in an upcoming control scope, and / or in what order the data will be targeted in an upcoming control scope. For example, when the historical data access information 39 indicates that the first data block and the second data block were targeted by a previous data access pattern, the memory controller 34 may predict that the first data block and the second data block will be targeted again by a subsequent data access pattern. Additionally or alternatively, when the historical data access information 39 indicates that the second data block was targeted after the first data block during a previous data access pattern, the memory controller 34 may predict that the second data block will be targeted again after the first data block during a subsequent data access pattern.

[0121] In other words, in some embodiments, the memory controller 34 may predict the next target data block relative to the currently or previously targeted data block. To help illustrate, continuing with the above example, when the first data block is currently targeted, the memory controller 34 may predict that the second data block will be the next target data block. In fact, in some embodiments, the historical data access information 39 may enable the memory controller 34 to predict that a data block that was not accessed in the previous data access pattern will be the next target data block. For example, when the historical data access information 39 indicates that the first (e.g., physical or virtual) storage address of the first data block is separated from the second storage address of the second data block by a certain step length, the memory controller 34 may predict that the data block associated with the memory address that is the step length away from the memory address of the currently targeted data block will be the next target data block.

[0122] Additionally or alternatively, in some embodiments, the memory controller 34 may more explicitly predict the next target time of one or more data blocks. For example, based at least in part on a difference between a last access time parameter associated with a first data block and a last access time parameter associated with a second data block, the memory controller 34 may determine a time difference between previous targetings of the first data block and the second data block, and thus predict that the next target time of the second data block will occur the time difference after another targeting of the first data block. Additionally or alternatively, the memory controller 34 may determine the average period between consecutive accesses of the data block at least in part by dividing the difference between the last access time parameter and the write time parameter associated with the data block by the access count parameter associated with the data block. Thus, the memory controller 34 may predict that the next target time of the data block will occur the average period of time after the previous targeting of the data block.

[0123] However, at least in some cases, predicting subsequent data access patterns based solely on chronological data access information may result in inaccurate predictions of subsequent data access patterns. To help illustrate, continuing with the above example, an application running in computing system 10 may cause a first data block to be targeted and a second data block to be subsequently targeted. However, between the targeting of the first data block and the second data block, a system interruption independent of the particular application may cause a Jth (e.g., different) data block to be targeted.

[0124] Thus, at least in some cases, predicting subsequent data access patterns without considering the transaction context may cause the memory controller 34 to predict that the Jth data block will be the next target data block after another targeting of the first data block. However, since it is independent of the specific application, the system interruption may not always occur between targeting the first data block and targeting the second data block. In other words, when no system interruption occurs in the upcoming control scope, equally weighting the historical data access information 39 associated with the first data block, the second data block, and the Jth data block may cause the subsequent data access pattern to be improperly predicted, such as causing the second data block to be predicted to be targeted at a time after its actual target time. At least in some cases, for example, because the computing system 10 did not pay enough attention to the individual instances of storing data blocks in a lower memory (e.g., cache) hierarchy before actually setting the target and therefore retrieved the data blocks from a higher memory hierarchy instead, determining a predicted next target time that is much later than the actual next target time of the data may reduce the operating efficiency of the computing system.

[0125] Additionally, as described above, lower memory tiers may generally be implemented with smaller storage capacities than higher memory tiers. Thus, as will be described in greater detail below, in some embodiments, a lower memory tier may evict a data block that is not expected to be targeted during an upcoming control scope to make room for storing another data block that is expected to be targeted during an upcoming control scope. However, evicting another data block based on a predicted next target time that occurs much earlier than the actual target time of the data block may result in the other data block being evicted prematurely, which may reduce the operating efficiency of the computing system in at least some circumstances, for example because another data block is actually targeted before the data block and, therefore, is retrieved from a higher memory tier rather than a lower memory tier.

[0126] To facilitate improved prediction accuracy, in some embodiments, the memory controller 34 may predict subsequent data access patterns by analyzing historical data access information 39 in view of corresponding transaction contexts. Specifically, in some embodiments, the memory controller 34 may determine multiple data access patterns, for example, each data access pattern is associated with a different transaction context (e.g., one or more aspects of the computing system 10). As an illustrative example, the memory controller 34 may determine a first (e.g., application) data access pattern associated with a first transaction context based at least in part on the historical data access information 39 indicated in one or more entries 71 of the first table section 81A. Additionally, the memory controller 34 may determine a first (e.g., system interrupt) data access pattern associated with a first transaction context based at least in part on the historical data access information 39 indicated in one or more entries 71 of the first table section 81I.

[0127] In this way, the memory controller 34 can predict subsequent data access patterns of a transaction context based at least in part on previous data access patterns associated with the transaction context. In other words, in some embodiments, considering context information in the prediction of subsequent data patterns corresponding to a particular transaction context can enable the memory controller 34 to adaptively (e.g., dynamically) adjust the impact of historical data access information 39 associated with different data blocks on its prediction. At least in some embodiments, this can facilitate improved prediction accuracy, for example, by enabling the memory controller 34 to filter out noise that might otherwise affect its prediction (e.g., historical data access information 39 associated with data blocks that are not related to a particular aspect of the transaction context). As an illustrative example, when predicting a subsequent data access pattern associated with a first transaction context, the memory controller 34 can weight the historical data access information 39 associated with the first data block and the second data block more heavily than the historical data access information 39 associated with the jth data block, for example, so that the historical data access information 39 associated with the jth data block is excluded from the prediction.

[0128] To facilitate improved operational efficiency of the computing system, as described above, the memory controller 34 may predictively control the storage of data in one or more memory tiers based at least in part on predicted data access patterns (processing block 68). Specifically, in some embodiments, the memory controller 34 may control what data blocks are stored in the memory tiers based at least in part on the predicted access order of the data blocks and / or the next predicted target time of the data blocks. For example, the memory controller 34 may pre-fetch copies (e.g., instances) of data blocks that are expected to be targeted during an upcoming control scope from a higher memory tier to a lower (e.g., lowest or L1) memory tier (before actually targeting the data blocks) (processing block 78). Additionally or alternatively, the memory controller 34 may preemptively (e.g., predictively) instruct a lower memory tier to evict a data block to make room for another data block that is expected to be targeted during an upcoming control scope, such as when the data block is not expected to be targeted during an upcoming control scope (processing block 80). In this way, the (e.g., processor-side and / or memory-side) memory controller 34 may be operable to predictively control the storage of data in one or more memory tiers in the computing system 10 (e.g., the processing subsystem 12 and / or the memory subsystem 14) based at least in part on context information associated with one or more previous data accesses.

[0129] As described above, in some embodiments, context information may be available in the processing subsystem 12 of the computing system 10, for example, due to the generation and / or targeting of data blocks by the processing circuitry 16 in the processing subsystem 12. In other words, in such embodiments, the context information may be directly available to the processor-side memory controller 34A, thereby enabling the processor-side memory controller 34A to predictively control the storage of data in one or more memory (e.g., cache) tiers of the processing subsystem 12 based at least in part on the context information. However, in some embodiments, the context information may not be directly available to the memory subsystem 14 in the computing system 10. Therefore, at least in such embodiments, to facilitate improved prediction accuracy in the memory subsystem 14, the processing subsystem 12 may indicate the context information in a memory access request output to the memory subsystem 14 via the memory bus 20B.

[0130] To help illustrate, Figure 6 An example of a process 82 for operating the processing subsystem 12 to request access to the memory subsystem 14 is described in . In general, the process 82 includes determining access parameters to be used to access data (processing block 84) and determining a transaction context for the data (processing block 86). In addition, the process 82 includes outputting a memory access request indicating the access parameters and the context (processing block 88).

[0131] Although described in a particular order representing a particular embodiment, it should be noted that process 82 may be performed in any suitable order. Additionally, embodiments of process 82 may omit processing blocks and / or include additional processing blocks. Furthermore, in some embodiments, process 82 may be implemented at least in part by executing instructions stored in a tangible, non-transitory computer-readable medium (e.g., a memory implemented in memory controller 34) using processing circuitry (e.g., a processor implemented in memory controller 34).

[0132] Thus, in some embodiments, the processor-side memory controller 34A may determine access parameters to be used to access the data (processing block 84). In some embodiments, determining the access parameters may include determining a memory address associated with the data (processing block 90). For example, when a block of data is to be stored in the memory subsystem 14, the write access parameters may include a virtual memory address used by the processing circuit 16 to identify the block of data and / or a physical memory address in the memory subsystem 14 where the block of data is stored. Additionally or alternatively, when a block of data is to be retrieved from the memory subsystem 14, the read access parameters may include a virtual memory address used by the processing circuit 16 to identify the block of data and / or a physical memory address in the memory subsystem 14 where the block of data is expected to be stored. In some embodiments, the processor-side memory controller 34A may also determine a tag parameter value associated with the data based at least in part on the virtual memory address of the data and / or the physical memory address of the data.

[0133] Additionally, in some embodiments, determining the access parameters may include determining the size (e.g., bit depth) of the data (processing block 92). For example, when a block of data is to be stored in the memory subsystem 14, the write access parameters may indicate the size of the block of data. Additionally or alternatively, when a block of data is to be retrieved from the memory subsystem 14, the read access parameters may indicate the expected size of the block of data.

[0134] Furthermore, in some embodiments, determining the access parameters may include determining the access type (processing block 94). For example, when the data block is to be stored in the memory subsystem 14, the write access parameters may include a write enable indicator (e.g., a bit). Additionally or alternatively, when the data block is to be retrieved from the memory subsystem 14, the read access parameters may include a read enable indicator (e.g., a bit).

[0135] To facilitate improved prediction accuracy in the memory subsystem 14, the processor-side memory controller 34A may determine a transaction context associated with data to be stored in and / or retrieved from the memory subsystem 14 (processing block 86). As described above, in some embodiments, the transaction context associated with the data access may be indicated via context information (e.g., one or more parameters) that identifies one or more aspects of the computing system associated with the (e.g., generated and / or targeted) data block and / or the (e.g., physical and / or virtual) memory address targeted by the data access. For example, the context information may include processor context parameters, processor core context parameters, application (e.g., program or thread) context parameters, and / or application instruction (e.g., program counter) context parameters.

[0136] Thus, in some embodiments, determining the transaction context of the data access may include determining a processor context parameter that identifies one or more processors in computing system 10 (processing block 70). For example, processor-side memory controller 34A may determine the value of the processor context parameter to identify the processor that generated the data block in computing system 10. Additionally or alternatively, processor-side memory controller 34A may determine the value of the processor context parameter to identify the processor that currently targets the data block and / or previously targeted the data block.

[0137] In some embodiments, determining the transaction context of the data access may additionally or alternatively include determining a processor core context parameter that identifies one or more processor cores 36 in the computing system 10 (processing block 72). For example, the processor-side memory controller 34A may determine a value for the processor core context parameter to identify the processor core 36 in the computing system 10 that generated the data block. Additionally or alternatively, the processor-side memory controller 34A may determine a value for the processor core context parameter to identify the processor core 36 that is currently targeting the data block and / or that previously targeted the data block.

[0138] Furthermore, in some embodiments, determining the transaction context of the data access may additionally or alternatively include determining an application (e.g., program or thread) context parameter identifying one or more applications in computing system 10 (processing block 74). For example, processor-side memory controller 34A may determine a value for the application context parameter to identify an application that, when executed in computing system 10, caused the generation of the data block. Additionally or alternatively, processor-side memory controller 34A may determine a value for the application context parameter to identify an application that, when executed in computing system 10, caused the current targeting and / or previous targeting of the data block.

[0139] Furthermore, in some embodiments, determining the transaction context of the data access may additionally or alternatively include determining an application instruction (e.g., program counter) context parameter that identifies one or more application instructions in the computing system 10 (processing block 76). For example, the processor-side memory controller 34A may determine a value for the application instruction context parameter to identify an application instruction that, when executed by the computing system 10, results in the generation of a block of data. Additionally or alternatively, the processor-side memory controller 34A may determine a value for the application instruction context parameter to identify an application instruction that, when executed by the computing system 10, results in the current targeting and / or previous targeting of a block of data. However, as described above, at least in some embodiments, including one or more context parameters in a memory access request may increase the total number of bits used to indicate a memory access request.

[0140] To facilitate accommodating the increased number of bits, as will be described in greater detail below, in some embodiments, a memory interface implemented in computing system 10 may be adjusted, for example, to increase the communication bandwidth provided by the memory interface and / or to increase the number of clock cycles in which a memory access request is transmitted. However, in at least some cases, adjusting the memory interface may affect implementation-associated costs and / or operating efficiency of computing system 10, for example, by delaying the response of memory subsystem 14 thereof due to the increased number of clock cycles and / or by increasing the component count and / or physical footprint of the memory interface due to the increased communication bandwidth.

[0141] To facilitate reducing the impact of including one or more context parameters on implementation-associated costs and / or computing system operating efficiency, in some embodiments, the processor-side memory controller 34A may hash the value pairs of one or more of the context parameters before outputting them to the memory bus 20B. In other words, in some embodiments, the processor-side memory controller 34A may pass the values ​​of one or more context parameters through a hash function to determine hashed context parameters having a fixed bit length (e.g., bit depth). In fact, in some embodiments, performing a hash operation (e.g., function) on the values ​​of the context parameters may enable different types and / or different numbers of context parameters to be included in different memory access requests, such as because the hash operation outputs hashed context parameters having the same bit length regardless of its input. .

[0142] However, at least in some cases, hashing the context parameters may result in a certain degree of precision loss compared to directly (e.g., explicitly) indicating the context parameters, for example, due to inadvertently hashing different sets of context parameter values ​​to obtain the same hashed context parameter value. As an illustrative example, the processor-side memory controller 34A may pass the value of the first application instruction (e.g., program counter) context parameter to be included in the first memory access request through a hash function to determine the first hashed context parameter. In addition, the processor-side memory controller 34A may pass the value of the second application instruction context parameter to be included in the second memory access request through the same hash function to determine the second hashed context parameter. However, at least in some cases, the hash function may result in the first hashed context parameter value being the same as the second hashed context parameter value even when the values ​​of the first application instruction context parameter and the second application instruction context parameter identify different application instructions. In other words, at least in such cases, hashing the context parameters may affect the ability of the memory subsystem 14 to properly interpret the context information indicated in the memory access request, and therefore affect the precision of indicating the context information in the memory access request.

[0143] In some embodiments, the loss of precision may depend at least in part on the hash function applied. In other words, in some embodiments, the resulting loss of precision may vary between different hash functions. In fact, to facilitate reducing the impact of hashing on the ability of the memory subsystem 14 to properly interpret context information, in some embodiments, the processor-side memory controller 34A may selectively implement different hash functions. For example, the processor-side memory controller 34A may use a first hash function to hash the first one or more context parameters to be included in the first memory access request, and use a second (e.g., different) hash function to hash the second one or more context parameters to be included in the second memory access.

[0144] Therefore, in order to facilitate proper interpretation of the hash context parameter included in the memory access request, in some embodiments, the processor-side memory controller 34A may also identify the hash function used to generate the hash context parameter value in the memory access request. In other words, in some embodiments, the memory access request may include one or more context parameters that indicate the context of another context parameter included in the memory access request. For example, the memory access request may include a hash function context parameter that identifies one or more hash functions used to generate the hash context parameter included in the memory access request.

[0145] Additionally or alternatively, to facilitate changing the type of context parameters included in different memory access requests, the memory access request may include a context type context parameter that identifies the context parameter type of one or more other context parameters included in the memory access request. For example, a first memory access request may include a first context type context parameter that indicates that the first memory access request includes processor context parameters. On the other hand, a second memory access request may include a second context type context parameter that indicates that the second memory access request includes application instruction context parameters.

[0146] Based at least in part on the background parameters and the access parameters, the processor-side memory controller 34A may instruct the processing subsystem 12 to output a memory access request to the memory subsystem 14 via the memory bus 20B (processing block 88). To facilitate proper interpretation of the various parameters, in some embodiments, the memory access request may be organized into one or more parameter fields, for example, according to a communication protocol used by a memory interface communicatively coupled between the processing subsystem 12 and the memory subsystem 14. In other words, at least in such embodiments, the memory access request may include one or more parameter fields, each of which may be used to indicate a value for a corresponding parameter.

[0147] To help illustrate, Figure 7 . As depicted, the memory access request 98 includes a plurality of parameter fields 100. In some embodiments, such as when the memory access request 98 is a write (e.g., store) memory access request 98, the memory access request 98 may additionally include a data block 102. However, it should be appreciated that the depicted example is intended to be illustrative and not limiting. For example, when the memory access request 98 is a read (e.g., load) memory access request 98, the memory access request 98 may not include the data block 102.

[0148] In any case, as in the depicted example, the memory access request 98 may include one or more access parameter fields 104, which may each be used to indicate a value for a corresponding access parameter. Specifically, in some embodiments, the memory access request 98 may include a first (e.g., access type) access parameter field 104, which may be used to indicate the type of memory access requested (e.g., read or write). For example, by indicating that a write (e.g., store) access is being requested, the access type access parameter may identify the memory access request 98 as a write memory access request 98. On the other hand, by indicating that a read (e.g., load) access is being requested, the access type access parameter identifies the memory access request 98 as a read memory access request 98.

[0149] Additionally, in some embodiments, the memory access request 98 may include a second (e.g., memory address) access parameter field 104 that may be used to indicate the (e.g., physical and / or virtual) memory address being requested for access. For example, in a write memory access request, the address access parameter may be used to indicate the virtual memory address used by the processing circuitry 16 to identify the data block 102 and / or the physical memory address in the memory subsystem 14 where the data block 102 is to be stored. On the other hand, in a read memory access request, the address access parameter may be used to indicate the virtual memory address used by the processing circuitry 16 to identify the data block 102 being retrieved and / or the physical memory address in the memory subsystem 14 where the data block 102 being retrieved is currently stored.

[0150] Furthermore, in some embodiments, the memory access request 98 may include a third (e.g., size) access parameter field 104 to indicate, for example, the size (e.g., bit depth) of the associated data requested to be stored in the memory subsystem 14 and / or requested to be transferred back to the processing subsystem 12. In other words, in some embodiments, the size access parameter in a write memory access request may be used to indicate the size of the data block 102 to be stored in the memory subsystem 14. On the other hand, the size access parameter in a read memory access request may be used to indicate the size of the data block 102 requested to be retrieved from the memory subsystem 14.

[0151] As in the depicted example, the memory access request 98 may additionally include one or more context parameter fields 106, which may each be used to indicate a value of a corresponding context parameter. Specifically, in some embodiments, the memory access request 98 may include a first (e.g., processor) context parameter field 106, which may be used to specifically identify one or more processors in the computing system 10. For example, in a write memory access request, the processor context parameter may be used to identify the processor in the computing system 10 that generated the data block 102. On the other hand, in a read memory access request, the processor context parameter in the read memory access request may be used to identify the processor in the computing system 10 that is currently targeting the data block 102.

[0152] Additionally, in some embodiments, the memory access request 98 may include a second (e.g., processor core) context parameter field 106 that may be used to specifically identify one or more processor cores 36 in the computing system 10. For example, in a write memory access request, the processor core context parameter may be used to identify the processor core 36 in the computing system 10 that generated the data block 102. On the other hand, in a read memory access request, the processor core context parameter in the read memory access request may be used to identify the processor core 36 in the computing system 10 that is currently targeting the data block 102.

[0153] Furthermore, in some embodiments, the memory access request 98 may include a third (e.g., application) context parameter field 106 that may be used to specifically identify one or more applications (e.g., programs) in the computing system 10. For example, in a write memory access request, the application context parameter may be used to identify the application in the computing system 10 that caused the generation of the data block 102. On the other hand, in a read memory access request, the application context parameter may be used to identify the application in the computing system 10 that caused the data block 102 to be currently targeted.

[0154] Additionally, in some embodiments, the memory access request 98 may include a fourth (e.g., application instruction) context parameter field 106 that may be used to identify a particular application instruction (e.g., a program counter) in an application running in the computing system 10. For example, in a write memory access request, the application instruction context parameter may be used to identify the application instruction that, when executed by the computing system 10, resulted in the generation of the data block 102. On the other hand, in a read memory access request, the application instruction context parameter may be used to identify the application instruction executed by the computing system 10 that resulted in the data block 102 being currently targeted.

[0155] In some embodiments, the memory access request 98 may include one or more parameter fields 100 that are different from the access parameter field 104 and the background parameter field 106. For example, the parameter field 100 may include one or more implementation parameter fields 108, each of which may be used to indicate the value of a corresponding implementation parameter. In some embodiments, the implementation parameters may include a priority parameter and / or a cache bypass parameter indicating an implementation priority of the memory access request 98. In some embodiments, the cache bypass parameter included in the read memory access request 98 may indicate whether an instance of a target data block 102 retrieved from a lower memory level should be stored in a lower (e.g., cache) memory level. Additionally or alternatively, the cache bypass parameter included in the write memory access request 98 may indicate whether an instance of a target data block 102 stored in a higher memory level should also be stored in a lower (e.g., cache) memory level. Thus, at least in such embodiments, the memory access request 98 may include a first (e.g., cache bypass) implementation parameter field 108 that may be used to indicate a value for a cache bypass parameter and / or a second (e.g., priority) implementation parameter field 108 that may be used to indicate a value for a priority parameter. In this manner, a memory access request 98 (e.g., generated by the processor-side memory controller 34A) may be formatted to indicate associated context information, e.g., via one or more context parameters indicated in a corresponding context parameter field 106 of the memory access request 98.

[0156] Back to Figure 6 In the process 82 of FIG. 8 , in some embodiments, after generating the memory access request 98, the processor-side memory controller 34 may store the memory access request 98 in the request (e.g., command) queue 42. In other words, at least in such embodiments, one or more memory access requests 98 may be stored in an entry of the request queue 42 before being transmitted from the processing subsystem 12 to the memory subsystem 14 via the memory interface implemented in the computing system 10. In addition, as described above, in some embodiments, the memory interface may include a processor-side bus interface 32A implemented in the processing subsystem 12, a memory-side bus interface 32 implemented in the memory subsystem 14, and a memory bus 20B coupled between a pin 44 of the processor-side bus interface 32A and a pin 44 of the memory-side bus interface 32. In other words, at least in such embodiments, the memory access request may be retrieved from the request queue 42 and output from the processing subsystem 12 to the memory bus 20B via the processor-side bus interface 32A.

[0157] Furthermore, as described above, at least in some embodiments, including one or more context parameters in the memory access request 98 may result in an increase in the total number of bits used to indicate the memory access request 98. To facilitate accommodating the increase in the total number of bits, as will be described in more detail below, in some embodiments, the memory interface used to communicate the memory access request 98 from the processing subsystem 12 to the memory subsystem 14 may be adjusted. For example, to facilitate reducing the impact of the increase in the total number of bits on the efficiency of the operation of the computing system, the communication bandwidth provided by the memory interface may be increased (e.g., expanded). To facilitate increasing the communication bandwidth, in some embodiments, the number of data paths provided by the memory interface may be increased. For example, the communication bandwidth may be increased by implementing additional data paths, the additional data paths including additional wires in the memory bus 20B, additional processor-side bus interface pins 44 coupled to the additional wires, and additional memory-side bus interface pins 44 coupled to the additional wires.

[0158] Indeed, in some embodiments, one or more data paths implemented in the memory interface may be dedicated to communicating a particular context parameter field 106. Thus, in some embodiments, outputting the memory access request 98 to the memory subsystem 14 may include outputting the value of the context parameter via an additional data path implemented in the memory interface (processing block 110). In at least some cases, communicating the context parameter via an additional data path may facilitate reducing the impact of the inclusion of the context parameter on the efficiency of computing system operation, such as by enabling the context parameter to be communicated in parallel (e.g., in parallel) with an access parameter and / or another context parameter.

[0159] Additionally or alternatively, to facilitate reducing the impact of increasing the total number of bits on implementation associated costs, the communication protocol of the memory interface may be adjusted. For example, to facilitate accommodating an increase in the number of bits used to indicate a memory access request 98, the communication protocol may be adjusted to increase the number of clock cycles over which (e.g., during which) the memory access request 98 is communicated (e.g., transmitted and / or received). In other words, in some embodiments, the communication protocol of the memory interface may be adjusted to add one or more clock cycles to facilitate accommodating an increase in the number of bits per memory access request 98.

[0160] Indeed, in some embodiments, one or more clock cycles provided by the communication protocol of the memory interface may be dedicated to communicating a particular context parameter field 106. Thus, in some embodiments, outputting the memory access request 98 to the memory subsystem 14 may include outputting the value of the context parameter via an additional clock cycle provided by the memory interface (processing block 112). Communicating the context parameter via an additional clock cycle may facilitate reducing the impact of the inclusion of the context parameter on the cost associated with implementation, at least in some cases, such as by reducing and / or avoiding expanding the communication bandwidth provided by the memory interface. In addition to the memory interface, in some embodiments, the implementation of the request queue 42 may be adjusted to facilitate accommodating memory access requests 98 that include one or more context parameter fields 106 and / or an increase in the number of bits per memory access request 98.

[0161] To help illustrate, Figure 8 , which may be used to store one or more memory access requests 98 in the processing subsystem 12. As in the depicted example, the request queue 42A may include a plurality of entries 113, each of which may be used to queue (e.g., store) a memory access request 98. For example, a first entry 113A may be used to queue a first memory access request 98A, and a Qth entry 113Q may be used to queue a Qth memory access request 98Q.

[0162] However, it should be appreciated that the depicted examples are intended to be illustrative only and not limiting. For example, in some embodiments, the request queue 42 may include a single entry 113 or more than two entries 113. Additionally or alternatively, one or more entries 113 in the request queue 42 may remain unpopulated (e.g., null or invalid), such as when the request queue 42 includes more entries 113 than the number of memory access requests 98 that have not yet been output from the processing subsystem 12 to the memory subsystem 14.

[0163] In any case, as in the depicted example, each memory access request 98 queued in the request queue 42 may include one or more access parameter fields 104 and one or more context parameter fields. For example, the first memory access request 98A may include the first one or more access parameter fields 104A and the first one or more context parameter fields 106A. On the other hand, the Qth memory access request 98Q may include the Qth one or more access parameter fields 104Q and the Qth one or more context parameter fields 106Q.

[0164] To facilitate improved operational flexibility, in some embodiments, the number of context parameter fields 106 and / or the types of context parameters included in different memory access requests 98 may vary. For example, the first memory access request 98A may include a single context parameter field 106, while the Qth memory access request 98Q may include four context parameter fields 106. Additionally or alternatively, processor core context parameters may be indicated in the context parameter field 106 of the first memory access request 98A, while the same context parameter field 106 in the Qth memory access request 98Q is used to indicate application instruction context parameters.

[0165] However, as described above, including one or more context parameter fields 106 in a memory access request 98 may result in an increase in the number of bits used to indicate the memory access request 98. In other words, to enable the request queue 42A to queue the memory access request 98 including the one or more context parameter fields 106, in some embodiments, the bit width of the entry 113 in the request queue 42A may be increased (e.g., expanded), for example, compared to another request queue 42 implemented to queue the memory access request 98 including only the access parameter field 104. After the memory access request 98 is queued, in some embodiments, the processing subsystem 12 may retrieve (e.g., read) the corresponding entry 113 from its request queue 42 and output the memory access request 98 via the memory interface. As described above, the memory subsystem 14 coupled to the memory interface may then provide memory (e.g., data) access to the processing subsystem 12 based at least in part on the value of the one or more access parameter fields 104 included in the memory access request 98.

[0166] To help illustrate, Fig. 91 shows an example of a memory subsystem 14A including a memory-side memory controller 34B. As in the depicted example, the memory subsystem 14A may include a memory-side cache 26A, a memory-side pre-fetch buffer 31, and a memory device 18A. However, it should be understood that the depicted example is intended to be illustrative and not limiting. For example, in other embodiments, the memory-side cache 26 and / or the memory-side pre-fetch buffer 31 may be avoided (e.g., optional), and therefore not included in the memory subsystem 14.

[0167] In any case, as described above, in some embodiments, the memory subsystem 14 may include one or more non-volatile memory devices 18 and / or one or more volatile memory devices 18. Typically, the non-volatile memory devices 18 may provide data storage using non-volatile memory. For example, the non-volatile memory devices 18 may include flash memory (e.g., NAND) memory devices, phase change memory (e.g., 3D XPoint™) devices, ferroelectric random access memory (FeRAM) devices, solid-state drives (SSDs), hard disk drives (HDDs), or any combination thereof. On the other hand, the volatile memory devices 18 may typically provide data storage using volatile memory. For example, the volatile memory devices 18 may include dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, or both.

[0168] Furthermore, in some embodiments, multiple memory devices 18 may be implemented on a memory module such as a dual in-line memory module (DIMM) or a single in-line memory module (SIMM). For example, the memory module may include a printed circuit board (PCB) and multiple memory devices 18 disposed on a flat or planar (e.g., front or back) surface of the printed circuit board. Additionally, the memory devices 18 may be coupled to external pins formed along an edge (e.g., bottom) of the printed circuit board via conductive traces formed on the printed circuit board.

[0169] It should be appreciated that one or more of memory devices 18 may be implemented using other packaging technologies. For example, memory device 18 may be coupled to an (e.g., silicon) interposer to implement a 2.5D configuration. Additionally or alternatively, memory devices 18 may be stacked to implement a 3D configuration. Furthermore, in some embodiments, memory device 18 may be implemented using organic packaging technology. In other words, the techniques described in this disclosure may be implemented as an on-package solution.

[0170] In any case, as described above, different memory types generally provide varying trade-offs that affect the operating efficiency and / or implementation-associated costs of the memory subsystem 14 and, therefore, the computing system 10 in which the memory subsystem 14 is implemented, such as component count, manufacturing steps, and / or physical footprint. For example, non-volatile memory generally provides a higher (e.g., greater) data storage density than volatile memory. Additionally, non-volatile memory cells can maintain storage of data even in an unpowered state, compared to volatile memory cells. On the other hand, volatile memory generally provides faster data communication (e.g., read and / or write) speeds than non-volatile memory. In fact, static random access memory (SRAM) generally provides faster data communication speeds than dynamic random access memory (DRAM).

[0171] Thus, to facilitate increased data access speeds, in some embodiments, volatile memory devices 18 may be used to implement a lower (e.g., smaller and faster) memory tier, e.g., compared to non-volatile memory devices 18 that implement the highest (e.g., largest and slowest) memory tier. As described above, in some embodiments, memory cells in one or more memory devices 18 may be organized into memory arrays 28 to implement corresponding memory tiers. For example, non-volatile memory cells in memory subsystem 14A may be organized into a storage device memory array 114 corresponding to a (e.g., highest and / or non-volatile) memory tier of storage devices in memory subsystem 14A.

[0172] Additionally, in some embodiments, the volatile memory cells may be organized into one or more memory channel memory arrays 116, e.g., each corresponding to a different memory (e.g., DRAM) channel. As an illustrative example, the volatile memory cells in the memory subsystem 14A may be organized into a first memory channel memory array 116A corresponding to a first memory channel. Additionally or alternatively, the volatile memory cells in the memory subsystem 14A may be organized into an Mth memory channel memory array 116M corresponding to an Mth memory channel. To facilitate predictive control of data storage in the memory subsystem 14, in some embodiments, the memory subsystem 14 may store context information, e.g., along with corresponding data blocks 102 as data objects in the memory array 28A.

[0173] To help illustrate, Fig.101 shows an example of a memory array 28A that may be implemented in one or more memory devices 18. As in the depicted example, the memory array 28A may be coupled to row select (e.g., decoder) circuitry 118 and column select (e.g., decoder) circuitry 120. Additionally, as in the depicted example, the memory array 28A may include memory cells 122 that are coupled to the row select circuitry 118 via word lines 124 formed in a first (e.g., horizontal) direction and to amplifier circuitry 126 via bit lines 128 formed in a second (e.g., vertical) direction.

[0174] In some embodiments, each memory cell 122 may include a switching element, such as a metal oxide semiconductor field effect transistor (MOSFET), and a storage element, such as a capacitor. For example, a memory cell 122 may be implemented such that its MOSFET is coupled between a bit line 128 and its storage capacitor, and the gate of its MOSFET is coupled to a word line 124. Thus, in some embodiments, each memory cell 122 may be used to store one bit of data.

[0175] For example, memory cell 122 may indicate a 1 bit when the charge stored in memory cell 122 produces a voltage greater than a threshold voltage. On the other hand, memory cell 122 may indicate a 0 bit when the charge stored in memory cell 122 produces a voltage less than a threshold voltage. In other embodiments, memory cell 122 may be implemented to store multiple bits of data. For example, memory cell 122 in a quad-level cell (QLC) NAND memory may be implemented to store two bits of data.

[0176] In any case, as in the depicted example, the memory cells 122 may be organized into one or more memory cell rows 130 that may each be identified by a corresponding row address (e.g., a physical memory address) and one or more memory cell columns 132 that may each be identified by a corresponding column address (e.g., a physical memory address). In some embodiments, the memory cell rows 130 may include each of the memory cells 122 coupled to (e.g., one) word line 124. For example, a first memory cell row 130A may include each of the memory cells 122 coupled to a first word line 124A, and an Lth memory cell row 130L may include each of the memory cells 122 coupled to an Lth word line 124L.

[0177] As in the depicted example, organizing the memory array 28A in this manner may enable the memory cells 122 to be grouped into storage locations that are each suitable for storing a data object 134. For example, a first data object 134A may be stored in a first storage location including memory cells 122 in a first memory cell row 130A and a first memory cell column 132A, a second data object 134B may be stored in a second storage location including memory cells 122 in an Lth memory cell row 130L and a second memory cell column 132B, and a Oth data object 134O may be stored in a Oth storage location including memory cells 122 in a first memory cell row 130A and a Kth memory cell column 132K. In some embodiments, the data objects 134 may include a data block 102 and associated metadata, e.g., identifying context information associated with the data block 102.

[0178] To help illustrate, Fig.11 . As in the depicted example, the data object 134 may include metadata 136 concatenated in front of (e.g., before) the data block 102. However, it should be appreciated that the depicted example is intended to be illustrative only and not limiting. For example, in other embodiments, the metadata 136 may be concatenated behind (e.g., attached to) the data block 102 or otherwise associated with (e.g., multiplexed and / or interleaved with) the data block 102.

[0179] In any case, data blocks 102 typically include, for example, related data, such as that which is expected to be processed (e.g., analyzed and / or interpreted) together. To facilitate identification of data blocks 102, as in the depicted example, metadata 136 may include tag parameters 138. In some embodiments, tag parameters 138 may indicate a storage location of data blocks 102 and / or data objects 134 in an address space, and thus may be used to identify data blocks 102 and / or data objects 134. In other words, in some embodiments, tag parameters 138 may indicate a virtual storage address of data block 102, a physical memory address of data block 102, or a value determined based on a virtual memory address and a physical memory address of data block 102.

[0180] Additionally, as in the depicted example, metadata 136 may include validity parameters 140 that indicate the validity of data block 102. In some embodiments, validity parameters 140 may include validity bits that indicate that the data block is valid when set (e.g., a "1" bit or high) and invalid when not set (e.g., a "0" bit or low). Additionally or alternatively, validity parameters 140 may facilitate detecting whether data block 102 is valid and / or correcting data block 102 if invalid. For example, validity parameters 140 may include one or more error checking codes, such as toggle bits, poison bits, parity bits, error detection codes (EDC), error correction codes (ECC), Bose-Chaudhuri-Hocquenghem (BCH) codes, message authentication codes (MACs), cyclic redundancy check (CRC) codes, or any combination thereof.

[0181] Additionally, as in the depicted example, metadata 136 may include a dirty parameter 141 that indicates whether data block 102 has been modified relative to a version stored in a higher memory hierarchy. In some embodiments, dirty parameter 141 may include a dirty bit that, when set (e.g., a "1" bit or high), indicates that the data block has been modified, and when not set (e.g., a "0" bit or low), indicates that the data block has not been modified. In other words, at least in such embodiments, dirty parameter 141 may be toggled when data block 102 is initially modified relative to a version of data block 102 stored in a higher memory hierarchy.

[0182] Furthermore, as in the depicted example, the metadata 136 may include one or more context parameters 142 that identify context information indicative of the context of the transaction with the data block 102. For example, the metadata 136 may include a processor context parameter 142 that identifies the processor that generated the data block 102, the processor that is currently targeting the data block 102, the processor that previously targeted the data block 102, and / or the processor that is expected to subsequently target the data block 102. Additionally, in some embodiments, the metadata 136 may include a processor core context parameter 142 that identifies the processor core 36 that generated the data block 102, the processor core 36 that is currently targeting the data block 102, the processor core 36 that previously targeted the data block 102, and / or the processor core 36 that is expected to subsequently target the data block 102.

[0183] Furthermore, in some embodiments, the metadata 136 may include an application context parameter 142 that identifies an application (e.g., a program or thread) that caused the data block 102 to be generated, an application that caused the data block to be currently targeted, an application that caused the data block to be previously targeted, and / or an application that is expected to cause the data block to be subsequently targeted. Furthermore, in some embodiments, the metadata 136 may include an application instruction context parameter 142 that identifies an application instruction (e.g., a program counter) that caused the data block 102 to be generated, an application instruction that caused the data block 102 to be currently targeted, an application instruction that caused the data block 102 to be previously targeted, and / or an application instruction that is expected to cause the data block 102 to be subsequently targeted. In this manner, the data block 102 may be associated with the metadata 136 that indicates the transaction context of the data block 102 as a data object 134.

[0184] Back to Fig.10 1. As described above, data (e.g., data object 134) may be stored at and / or retrieved from storage locations in memory array 28A. Additionally, as described above, row select circuitry 118 may be connected to rows of memory array 28A via corresponding word lines 124. Thus, to enable reading and / or writing of memory cells 122, row select circuitry 118 may activate memory cells 122, such as by outputting an activation (e.g., logic high) signal via corresponding word lines 124 that causes a switching component of memory cell 122 to electrically couple a storage component of memory cell 122 to a corresponding bit line 128.

[0185] Furthermore, as described above, column select circuitry 120 may be coupled to columns of memory array 28A. In other words, column select circuitry 120 may be coupled to a first column of memory cells 132A via a first bit line 128A and a first amplifier circuit 126A, to a second column of memory cells 132B via a second bit line 128B and a second amplifier circuit 126B, and to a Kth column of memory cells 132K via a Kth bit line 128K and a Kth amplifier circuit 126K. In some embodiments, amplifier circuitry 126 may include a driver that facilitates storing (e.g., writing) data into memory cells 122 and / or a sense amplifier that facilitates outputting (e.g., reading) data from memory cells 122.

[0186] Additionally, in some embodiments, the column selection circuit 120 may selectively enable reading from and / or writing to the memory cell columns 132, for example, by outputting a column selection signal (e.g., logic high) to the corresponding amplifier circuit 126. In other words, in order to read data (e.g., the first data object 134A) from and / or write data to the first memory cell column 132A, the column selection circuit 120 may output a column selection signal to the first amplifier circuit 126A. Similarly, in order to read data (e.g., the second data object 134B) from and / or write data to the second memory cell column 132B, the column selection circuit 120 may output a column selection signal to the second amplifier circuit 126B. Furthermore, in order to read data (e.g., the Oth data object 134O) from and / or write data to the Kth memory cell column 132K, the column selection circuit 120 may output a column selection signal to the Kth amplifier circuit 126K. In this manner, memory cells 122 in one or more memory devices 18 may be organized to implement a memory array 28 in the memory subsystem 14 .

[0187] Return to Fig. 9 As described above, in some embodiments, the memory subsystem 14A may include one or more memory-side caches 26A in addition to the memory device 18. As described above, the memory-side cache 26 may be implemented in the memory subsystem 14 to provide a lower memory hierarchy than the memory array 28 implemented in the memory subsystem 14. In other words, in some embodiments, the memory-side cache 26 may be implemented to provide faster data communication speeds on average than the memory array 28.

[0188] Thus, in some embodiments, the memory-side cache 26 may also be implemented using volatile memory. For example, the memory-side cache 26A may be implemented with static random access memory (SRAM), while the volatile memory device 18 may be implemented with dynamic random access memory (DRAM). Additionally or alternatively, the memory-side cache 26A and the volatile memory device 18 may be implemented using the same memory type (e.g., DRAM). In fact, in some embodiments, one or more memory-side caches 26 may be implemented in the volatile memory device 18. In any case, as described above, the cache may be implemented to provide storage locations organized into one or more cache lines 30, for example, to store instances (e.g., copies) of data that are also stored in the memory array 28.

[0189] To help illustrate, Fig.121 shows an example of a cache 144 (e.g., a memory-side cache 26 and / or a processor-side cache 24). As in the depicted example, the cache 144 may provide storage locations organized into a plurality of cache lines 30 (i.e., a first cache line 30A, an Fth cache line 30F, and so on). Additionally, as in the depicted example, the storage locations included in the cache lines 30 may be allocated to enable storage of one or more data objects 134 (e.g., 134A-134N). For example, the first cache line 30A may be implemented with a line width that enables storage of N valid data objects 134. However, it should be understood that the depicted example is intended to be illustrative only and not limiting. For example, in other embodiments, a cache line 30 may be allocated a line width that enables storage of a single valid data object 134 or more than two valid data objects 134.

[0190] In any case, as referred to above Fig.11 As described, the data object 134 may include the data block 102 and metadata 136. For example, as described above, the metadata 136 may include a validity parameter 140 that indicates whether the data block 102, and therefore the data object 134, is valid. Additionally, as described above, in some embodiments, the metadata 136 may include one or more context parameters 142 that indicate context information associated with the data block 102. For example, the context parameters 142 may include processor context parameters 142, processor core context parameters 142, application (e.g., program or thread) context parameters 142, application instruction (e.g., program counter) context parameters 142, or any combination thereof.

[0191] Additionally, as described above, in some embodiments, metadata 136 may include tag parameters 138 that indicate a storage location in an address space of data block 102 and / or data object 134. For example, tag parameters 138 associated with data block 102 may be determined based at least in part on a virtual memory address used by processing circuitry 16 to identify data block 102 and / or a physical memory address where the data block is stored or to be stored in memory array 28. Thus, in some embodiments, tag parameters 138 may be used to identify data block 102 and / or data object 134.

[0192] Indeed, in some embodiments, the memory subsystem 14 may search for a data block 102 targeted by the read memory access request 98 based at least in part on a target value of a tag parameter 138 expected to be associated with the data block 102. For example, the memory subsystem 14 may determine a target value of a tag parameter 138 expected to be associated with the target data block 102 based at least in part on a virtual memory address and / or a physical memory address indicated in the read memory access request 98. Based at least in part on the target value, the memory subsystem 14 may determine whether the target data block 102 results in a cache miss by searching for a tag parameter 138 associated with a valid data block 102 currently stored in the cache 144.

[0193] For example, when the target tag parameter 138 and the tag parameter 138 associated with the valid data block 102 stored therein match, the memory subsystem 14 may determine that the target data block 102 is currently stored in the cache 144, and thus results in a cache hit. On the other hand, when the target tag parameter 138 and the tag parameter 138 associated with any valid data block 102 stored therein do not match, the memory subsystem 14 may determine that the target data block 102 is not currently stored in the cache 144, and thus results in a cache miss. Thus, on average, the data retrieval latency provided by the cache 144 may vary with its storage capacity, for example, because the increased storage capacity enables more valid data objects 134 to be stored therein.

[0194] Indeed, to facilitate improved data retrieval latency, in some embodiments, different caches 144 may be used to implement different hierarchical memory (e.g., cache) levels with varying storage capacities. For example, different memory levels may be implemented with different numbers of cache lines 30. As an illustrative example, a cache 144 used to provide a lower memory level may be implemented with fewer cache lines 30 than a cache 144 used to provide a higher memory level. Additionally or alternatively, the line width of a cache line 30 implemented in a lower memory level may be allocated so that fewer valid data objects 134 can be stored than a cache line 30 implemented in a higher memory level. In any case, in this manner, a cache 144 (e.g., a memory-side cache 26 and / or a processor-side cache 24) may be implemented to provide storage locations organized into one or more cache lines 30.

[0195] In fact, returning to Fig. 9In the memory subsystem 14A of FIG. 1 , in some embodiments, the memory side cache 26A may be organized hierarchically. For example, the memory side cache 26A may include one or more memory channel caches 146 and a shared memory side cache 148. In some embodiments, the memory channel caches 146 may be dedicated to the corresponding memory channels, while the shared memory side caches 148 may be shared among multiple memory channels. For example, the first one or more memory channel caches 146A may be dedicated to the first memory channel implemented by the first memory channel memory array 116A, and the Mth one or more memory channel caches 146M may be dedicated to the Mth memory channel implemented by the Mth memory channel memory array 116M. On the other hand, the shared memory side cache 148 may be shared by at least the first memory channel and the Mth memory channel. Therefore, in some embodiments, the shared memory side cache 148 may be implemented to provide a lower (e.g., lowest) memory (e.g., cache) level in the memory subsystem 14A compared to the memory channel caches 146.

[0196] In any case, as described above, the memory-side memory controller 34B may generally control the storage of data in the memory subsystem 14A. For example, the memory-side memory controller 34B may control whether data is stored in the memory-side cache 26, the volatile memory device 18, the non-volatile memory device 18, or any combination thereof. In other words, in some embodiments, the memory-side memory controller 34B may control whether data is stored in a (e.g., lower intermediate) memory level implemented in the memory-side cache 26, a (e.g., upper intermediate) memory level implemented in the non-volatile memory device 18, a (e.g., highest) memory level implemented in the non-volatile memory device 18, or any combination thereof. Thus, as in the depicted example, the memory-side memory controller 34B may be communicatively coupled to the memory-side cache 26A, the memory-side prefetch buffer 31B and / or the memory device 18A via one or more memory-side internal buses 20D, for example, to enable the memory-side memory controller 34B to search for target data and / or output control (e.g., command) signals that instruct (e.g., cause) the memory subsystem 14A to adjust the storage of data therein.

[0197] In addition, as described above, in response to receiving a memory access request 98 via the memory interface, the memory subsystem 14 may provide memory access to the processing subsystem 12. For example, in response to receiving a write memory access request 98, the memory-side memory controller 34B may instruct the memory subsystem 14A to store an instance of the data block 102 indicated in the write memory access request 98 in one or more memory hierarchies of the memory subsystem 14A. Additionally or alternatively, in response to receiving a read memory access request 98, the memory-side memory controller 34B may identify the data block 102 targeted by the read memory access request 98 and instruct the memory subsystem 14A to return the target data block 102 via the memory interface.

[0198] Thus, as in the depicted example, the memory-side bus interface 32B can be coupled between the memory bus 20B and the one or more memory-side internal buses 20D. Additionally, as in the depicted example, the memory-side bus interface 32B can include one or more pins 44. As will be described in more detail below, in some embodiments, each pin 44 of the bus interface 32 can be coupled to a corresponding conductor in the memory bus 20B. By implementing the memory subsystem 14 in this manner, the memory-side memory controller 34B can be operated to control data storage in the memory subsystem 14 based at least in part on the memory-side historical data access information 39B, such as predictively during operation of the corresponding computing system 10.

[0199] To help further illustrate, in Fig.13 1. An example of a process 150 for operating the memory subsystem 14 is described in . In general, the process 150 includes: receiving a memory access request from a processing subsystem (processing block 152); determining access parameters and context parameters indicated by the memory access request (processing block 154); and determining whether the memory access request is a read access request (decision block 156). In addition, the process 150 includes: when the memory access request is not a read access request, storing a data block in the memory subsystem based on the access parameters (processing block 158), when the memory access request is a read access request, outputting a target data block to the processing subsystem based on the access parameters (processing block 160), updating historical data access information based on the context parameters (processing block 161), and determining whether another memory access request has been received (decision block 162). When another memory access request has not been received, the process 150 includes predicting a subsequent data access pattern based on the context parameters (processing block 164), and controlling data storage in the memory subsystem based on the predicted data access pattern (processing block 166).

[0200] Although described in a particular order representing a particular embodiment, it should be noted that process 150 may be performed in any suitable order. Additionally, embodiments of process 150 may omit processing blocks and / or include additional processing blocks. Furthermore, in some embodiments, process 150 may be implemented at least in part by executing instructions stored in a tangible, non-transitory computer-readable medium (e.g., a memory implemented in memory controller 34) using processing circuitry (e.g., a processor implemented in memory controller 34).

[0201] Thus, in some embodiments, the memory-side memory controller 34B implemented in the memory subsystem 14 of the computing system 10 may determine the memory access request 98 output from the processing subsystem 12 in the computing system 10 to the memory subsystem 14 (processing block 152). As described above, in some embodiments, the processing subsystem 12 may output the memory access request 98 via the memory bus 20B. Additionally, as described above, in some embodiments, the memory subsystem 14 may include a memory-side bus interface 32B coupled between the memory bus 20B and one or more memory-side internal buses 20D. Thus, in some embodiments, the memory-side bus interface 32 may receive the memory access request 98 output from the processing subsystem 12 via the memory bus 20B, and route the memory access request 98 to the memory-side memory controller 34B via the one or more memory-side internal buses 20D.

[0202] Additionally, the memory-side memory controller 34B may determine one or more access parameters and one or more context parameters 142 indicated by the memory access request 98 (processing block 154). As described above, in some embodiments, the memory access request 98 may include one or more parameter fields 100, each of which may be used to indicate a value of a corresponding (e.g., access or context) parameter. Additionally, as described above, in some embodiments, a communication protocol associated with a memory interface implemented in the computing system 10 may control the formatting of the memory access request 98. For example, the communication protocol may control the number and / or type of parameters to be included in the memory access request 98. The communication protocol may control bit allocation to indicate the parameter fields 100 in the memory access request 98.

[0203] Thus, in some embodiments, the memory-side memory controller 34B may determine the value of one or more context parameters 142 by parsing the memory access request 98 according to the communication protocol of the memory interface. For example, the memory-side memory controller 34B may determine the value of the processor context parameter 142 by reading one or more bits assigned by the communication protocol to indicate the processor context parameter field 106 in the memory access request 98. Additionally or alternatively, the memory-side memory controller 34B may determine the value of the processor core context parameter 142 by reading one or more bits assigned by the communication protocol to indicate the processor core context parameter field 106 in the memory access request 98, determine the value of the application (e.g., program or thread) context parameter 142 by reading one or more bits assigned by the communication protocol to indicate the application context parameter field 106 in the memory access request 98, determine the value of the application instruction (e.g., program counter) context parameter 142 by reading one or more bits assigned by the communication protocol to indicate the application instruction context parameter field 106 in the memory access request 98, or any combination thereof.

[0204] As described above, in some embodiments, the one or more context parameters 142 may be hashed before being included in the memory access request 98 as the hashed context parameters 142. Thus, at least in such embodiments, the memory-side memory controller 34B may determine the indication of the one or more context parameters 142 by reading one or more bits assigned by the communication protocol to indicate the hashed context parameter field 106 in the memory access request 98. Additionally, to facilitate proper interpretation by the memory subsystem 14, in some embodiments, the memory access request 98 may include a hash function context parameter 142 that identifies the hash function used to generate the hashed context parameter 142.

[0205] Similarly, in some embodiments, the memory-side memory controller 34B may determine one or more access parameters according to the communication protocol of the memory interface by parsing the memory access request 98. For example, the memory-side memory controller 34B may determine the value of the memory address access parameter by reading one or more bits of the memory address access parameter field 104 assigned by the communication protocol to indicate the memory access request 98. In addition, the memory-side memory controller 34B may determine the value of the access type access parameter by reading one or more bits of the access type access parameter field 104 assigned by the communication protocol to indicate the memory access request 98.

[0206] Based at least in part on the access type access parameter, the memory-side memory controller 34B may determine whether the memory access request 98 is requesting read access (decision block 156). For example, when the access type access parameter is not set (e.g., low or "0 bit"), the memory-side memory controller 34B may determine that a read access is being requested, and therefore, the memory access request 98 received from the processing subsystem 12 is a read memory access request 98. On the other hand, when the access type access parameter is set (e.g., high or "1 bit"), the memory-side memory controller 34B may determine that the memory access request 98 received from the processing subsystem 12 is requesting write access. In other words, when the access type access parameter is set, the memory-side memory controller 34B may determine that the memory access request 98 is a write memory access request 98, and therefore, does not request read access.

[0207] In response to receiving the write memory access request 98, the memory-side memory controller 34B may instruct the memory subsystem 14 to store the data block 102 indicated by the write memory access request 98 in one or more memory hierarchies (processing block 158). As described above, in some embodiments, the data block 102 and one or more context parameters 142 associated with the data block 102 may be stored together as a data object 134. In addition, as described above, in some embodiments, the memory address access parameter indicated in the write memory access request 98 may identify the (e.g., physical) memory address at which the corresponding data block 102 is stored. In other words, in response to receiving the write memory access request 98, the memory-side memory controller 34B may instruct the memory subsystem 14 to store an instance of the data block 102 at the memory address identified by its memory address access parameter. In some embodiments, the memory-side memory controller 34B may additionally instruct the memory subsystem 14 to store instances of the data block 102 in one or more other (e.g., lower) memory hierarchies, for example to facilitate reducing data retrieval latency when the memory address identified by the write memory access request 98 is at a higher (e.g., memory channel and / or storage device) memory hierarchy.

[0208] On the other hand, in response to receiving the read memory access request 98, the memory-side memory controller 34B may identify the data block 102 targeted by the read memory access request 98 and instruct the memory subsystem 14 to return the target data block 102 to the processing subsystem 12 (processing block 160). As described above, in some embodiments, the memory subsystem 14 may include one or more memory-side caches 26 to implement a lower memory hierarchy than the memory array 28 implemented in one or more memory devices 18 of the memory subsystem 14. Therefore, when the memory subsystem 14 includes the memory-side cache 26, the memory-side memory controller 34B may determine whether the target data block 102 is currently stored in the memory-side cache 26, and therefore determine whether the target data will cause a memory-side cache miss. For example, the memory-side memory controller 34B may search for a tag parameter 138 associated with a valid data block 102 currently stored in the memory-side cache 26 based at least in part on the target value of the tag parameter 138 expected to be associated with the target data block 102. Specifically, when the target value of the tag parameter 138 is contained in the memory-side cache 26, the memory-side memory controller 34B may determine that the target data block 102 will not cause a memory-side cache miss, and thus instruct the memory-side cache 26 to output the target data block 102.

[0209] When the target data block 102 causes a memory-side cache miss or the memory subsystem 14 does not include a memory-side cache 26, the memory-side memory controller 34B may locate the target data block 102 in a memory array 28 implemented in one or more memory devices 18, and instruct the memory array 28 to output the target data block 102. For example, the memory-side memory controller 34B may instruct the row selection circuit 118 to activate the memory cell row 130 of the memory array 28 storing the target data block 102. In some embodiments, the row selection circuit 118 may activate the memory cell row 130 identified by the row address associated with the target data block 102. Additionally, in some embodiments, the row selection circuit 118 may activate the memory cell row 130 by outputting an activation (e.g., logic high) signal to the word line 124 of the memory cell 122 coupled to the memory cell row 130. Furthermore, in some embodiments, the column select circuit 120 may read the target data block 102 from the enabled memory cell row 130 by selecting the amplifier circuit 126 coupled to the memory cell column 132 identified by the column address associated with the target data block 102. Additionally or alternatively, the column select circuit 120 may multiplex the output from each memory cell column 132 based on the column address associated with the target data block 102.

[0210] As described above, in some embodiments, the data block 102 retrieved from the memory hierarchy in the memory subsystem 14 may be returned (e.g., output) to the processing subsystem 12 via the memory-side bus interface 32B. In other words, at least in such embodiments, the memory-side memory controller 34B may instruct the memory-side bus interface 32B to output the data block 102 via the memory bus 20B coupled between the processing subsystem 12 and the memory subsystem 14. In addition, to facilitate improved subsequent data retrieval latency, in some embodiments, the memory subsystem 14 may store an instance (e.g., a copy) of the target data block 102 retrieved from the higher memory hierarchy in one or more lower memory (e.g., cache) hierarchies. For example, when retrieving the target data block from the memory array 28, the memory-side memory controller 34B may instruct the memory subsystem 14 to store the instance of the target data block 102 in one or more memory-side caches 26. Additionally or alternatively, when the target data block 102 is returned from the memory subsystem 14 , the processor-side memory controller 34A may instruct the processing subsystem 12 to store instances of the target data block 102 in one or more processor-side caches 24 .

[0211] In any case, to facilitate predictive control of data storage in the memory subsystem 14, the memory-side memory controller 34B may update its memory-side historical data access information 39B based at least in part on the context parameters 142 indicated in the memory access request 98. As described above, in some embodiments, the historical data access information 39 associated with the data block 102 may be indicated via one or more corresponding entries 71 in the historical data access information table 69. In addition, as described above, in some embodiments, the historical data access information table 69 may be organized such that entries 71 corresponding to different transaction contexts are indicated in different table sections 81.

[0212] Thus, in some embodiments, the memory-side memory controller 34B may at least partially update the memory-side historical data access information 39B by at least partially adding an entry 71 to the table section 81 corresponding to the transaction context indicated by the context parameter 142 (processing block 171). For example, when the memory access request 98 is a write memory access request 98, the memory-side memory controller 34B may add an entry 71 that identifies the data block 102 received for storage in the memory subsystem 14 via the block identifier parameter in its block identifier field 73. On the other hand, when the memory access request 98 is a read memory access request 98, the memory-side memory controller 34B may add an entry 71 that identifies the target data block 102 returned from the memory subsystem 14 via the block identifier parameter indicated in its block identifier field 73. In some embodiments, the entry 71 may be added to the table section 81 such that the entry 71 is indicated in chronological order relative to one or more other entries 71 associated with the same transaction context.

[0213] In addition to the block identifier field 73, as described above, in some embodiments, the entry 71 in the historical data access information table 69 may also include a write time field 75, a last access time field 77, and / or an access count field 79. Thus, in some embodiments, the memory-side memory controller 34B may update the memory-side historical data access information 39B at least in part by updating the values ​​of one or more fields included in the entry 71 of its historical data access information table 69 (processing block 173). For example, when the memory access request 98 is a read memory access request 98, the memory-side memory controller 34B may update the value of the last access time parameter in its last access time field 77 to indicate the current time, and / or increment the value of the access count parameter in its access count field 79. On the other hand, when the memory access request 98 is a write memory access request 98, the memory-side memory controller 34B may indicate the current time via the write time parameter in its write time field 75.

[0214] After implementing the memory access request 98, the memory-side memory controller 34B may determine whether another memory access request 98 has been received from the processing subsystem 12 (decision block 162). When another memory access request 98 has been received, the memory controller again determines one or more access parameters indicated in the another memory access request 98, determines one or more context parameters 142 indicated in the another memory access request 98, and so on (arrow 169). On the other hand, when another memory access request 98 has not been received, the memory-side memory controller 34B may take the opportunity to predictively adjust data storage in the memory subsystem 14, for example, to facilitate improving (e.g., reducing) subsequent data retrieval latency provided by the memory subsystem 14, and thus improve the operating efficiency of the computing system.

[0215] Specifically, when another memory access request 98 has not yet been received, the memory-side memory controller 34B may predict the data access pattern expected to occur within an upcoming control scope (e.g., a time period or one or more clock cycles) based at least in part on the memory-side historical data access information 39B. In other words, the memory-side memory controller 34B may predict what data will be targeted within the upcoming control scope, when the data will be targeted during the upcoming control scope, and / or the order in which the data will be targeted during the upcoming control scope. In fact, since the context information is used for prediction in the processing subsystem 12, in some embodiments, the memory-side memory controller 34B in the memory subsystem 14 may predict one or more subsequent data access patterns in a similar manner.

[0216] In other words, in some embodiments, the memory-side memory controller 34B may predict the subsequent data access pattern by analyzing the memory-side historical data access information 39B in view of the transaction context indicated, for example, via one or more context parameters 142 included in the memory access request 98 received from the processing subsystem 12 and / or included in the data object 134 with the corresponding data block 102. However, in at least some embodiments, the historical data access information 39 available to the memory subsystem 14 and the corresponding processing subsystem 12 may be different, for example, due to one or more target data blocks 102 being accessed from the processor-side cache 24 and therefore not being accessed in the memory subsystem 14. In other words, at least in such embodiments, the memory-side historical data access information 39B and the processor-side historical data access information 39A may be different, thereby causing the subsequent data access pattern predicted by the memory subsystem 14 to be different from the subsequent data access pattern predicted by the processing subsystem 12, for example, even if they implement similar prediction techniques.

[0217] To facilitate improved operational efficiency of the computing system, the memory-side memory controller 34B may predictively control data storage in the memory subsystem 14 based at least in part on predicted data access patterns (processing block 166). Specifically, in some embodiments, the memory-side memory controller 34B may control what data blocks are stored in the memory hierarchy based at least in part on the predicted access order of the data blocks and / or the next predicted target time of the data. For example, the memory-side memory controller 34B may pre-fetch a copy of a data block 102 that is expected to be targeted during an upcoming control scope from the storage device memory array 114 to the memory channel memory array 116 and / or from the memory channel memory array 116 to the memory-side cache 26 or the memory-side pre-fetch buffer 31B (before the data block 102 is actually targeted). Additionally or alternatively, the memory-side memory controller 34B may instruct the memory-side cache 26 and / or the memory channel memory array 116 to evict a data block 102, e.g., when a data block is not expected to be targeted during an upcoming control scope, to make room for another data block 102 that is expected to be targeted during an upcoming control scope. In this manner, the memory-side memory controller 34B may be operable to predictively control data storage in one or more memory hierarchies implemented in the memory subsystem 14 based at least in part on context information.

[0218] As described above, in some embodiments, to facilitate consideration by the memory subsystem 14, context information may be indicated in a memory access request 98 output from the corresponding processing subsystem 12, for example, via a memory interface, which includes software that facilitates formatting the memory access request 98 according to a communication protocol of the memory interface and / or hardware (e.g., bus interface pins 44 and memory bus 20B) that enables communication between the processing subsystem 12 and the memory subsystem 14. However, as described above, at least in some embodiments, including context information in the memory access request 98 may result in an increase in the number of bits per memory access request 98, for example, due to the addition of one or more context parameter fields 106 in the memory access request 98. As described above, to facilitate accommodating memory access requests 98 that include one or more context parameter fields 106 and / or the resulting increase in the number of bits per memory access request 98, in some embodiments, the implementation of the memory interface deployed in the computing system 10 may be adjusted.

[0219] To help explain further, Fig.141 shows an example of a memory interface 170 that may be deployed in the computing system 10. As in the depicted example, the memory interface 170 may include a bus interface 32 and a memory bus 20B coupled to the bus interface 32. Thus, in some embodiments, the memory interface 170 may be a bus-based interface, such as a double data rate (DDR) interface, a graphics double data rate (GDDR) interface, a high bandwidth memory (HBM) interface, etc.

[0220] However, it should be appreciated that the depicted examples are intended to be illustrative only and not limiting. For example, in other embodiments, the memory interface 170 may be a packetized interface, such as a hybrid memory cube (HMC) interface, a Generation Z interface, etc. Furthermore, the memory interface 170 may additionally include another bus interface 32 coupled to the opposite end (e.g., side) of the memory bus 20B.

[0221] In some embodiments, the bus interface 32 may be implemented as a processor-side bus interface 32A in the processing subsystem 12. In other embodiments, the bus interface 32 may be implemented as a memory-side bus interface 32B in the memory subsystem 14. In any case, as described above, the bus interface 32 may include one or more pins 44 that may be coupled to the memory bus 20B. For example, the bus interface 32 may include a first pin 44A and a P-th pin 44P.

[0222] In addition, as described above, the memory bus 20B may include one or more conductors 176 (e.g., conductive paths or traces). In fact, in some embodiments, each conductor 176 of the memory bus 20B may be coupled to a corresponding pin 44 in the bus interface 32. To help illustrate, in the depicted example, the memory bus 20B includes a first conductor 176 that may be coupled to a first pin 44A of the bus interface 32. The memory bus 20B also includes a P-th conductor 176P that may be coupled to a P-th pin 44P of the bus interface 32.

[0223] In other words, in some embodiments, the memory interface 170 may include, for example, a plurality of (e.g., parallel) data paths 178, each of which includes a set (e.g., a pair) of bus interface pins 44 and a memory bus conductor 176 coupled therebetween. As an illustrative example, a first data path 178A in the memory interface 170 may include a first pin 44A of the bus interface 32 and a first conductor 176A of the memory bus 20B. Similarly, a P-th data path 178P in the memory interface 170 may include a P-th pin 44P of the bus interface 32 and a P-th conductor 176P of the memory bus 20B. Although not depicted, the first data path 178A may additionally include a pin 44 of another bus interface 32 (e.g., deployed in a different computing subsystem), and the P-th data path 178P may additionally include another pin 44 of the other bus interface 32.

[0224] Furthermore, in some embodiments, during communication of a memory access request 98, different data paths 178 in the memory interface 170 may be dedicated to communicating different parameter fields 100 in the memory access request 98. For example, a first data path 178A may be implemented to communicate the value of the access parameter 174 indicated in the access parameter field 104 of the memory access request 98. On the other hand, a third data path 178P may be implemented to communicate the value of the context parameter 142 indicated in the context parameter field 106 of the memory access request 98.

[0225] In other words, in other embodiments where the context parameter field 106 is not included in the memory access request 98, the P data path 178P may be avoided and therefore not included in the memory interface 170, for example to facilitate reducing costs associated with implementation, such as the physical footprint and / or component count of the memory interface 170. That is, in embodiments where the context parameter field 106 is included in the memory access request 98, the P data path 178P may be added to the memory interface 170.

[0226] As described above, in some embodiments, adjusting the memory interface 170 to include one or more additional data paths 178 may facilitate increasing its (e.g., maximum) communication bandwidth. In other words, to facilitate accommodating memory access requests 98 that include one or more context parameter fields 106, in some embodiments, the memory interface 170 may be implemented to provide a higher communication bandwidth, e.g., as compared to embodiments in which the context parameter fields 106 are not included in the memory access requests 98. As described above, in at least some cases, increasing the communication bandwidth provided by the memory interface 170 may facilitate improving the operating efficiency of the computing system, e.g., by enabling access parameters 174 and context parameters 142 to be communicated in parallel, at least in part, within the same one or more clock cycles.

[0227] However, as described above, the number of data paths 178 implemented in the memory interface 170 may affect the costs associated with its implementation. For example, adding pins 44 to the bus interface 32 may increase the physical footprint and / or component count of the bus interface 32 and, therefore, the memory interface 170 in which the bus interface 32 is deployed. Similarly, adding wires 176 to the memory bus 20B may increase the physical footprint and / or component count of the memory bus 20B and, therefore, the memory interface 170 in which the memory bus 20B is deployed. As described above, in order to facilitate accommodating memory access requests 98 that include one or more context parameter fields 106 while reducing the impact on the costs associated with implementation, in some embodiments, the communication protocol used to communicate via the memory interface 170 may be adjusted.

[0228] To help illustrate, Fig.15 , which describes communications via the memory bus 20 that may be implemented in the memory interface 170. Specifically, the timing diagram 180 describes the communication timing (e.g., formatting) of the memory access request 98 via a plurality of clock cycles 182, the plurality of clock cycles including at least a first clock cycle 182A and an Rth clock cycle 182R. However, it should be appreciated that the depicted example is intended to be illustrative and not limiting. Specifically, in other embodiments, such as when the communication bandwidth of the memory interface 170 is expanded to enable each parameter field 100 in the memory access request 98 to be communicated in parallel (e.g., in parallel), the memory access request 98 may be communicated within a single clock cycle 182.

[0229] As described above, in some embodiments, different parameter fields 100 in a memory access request 98 may be communicated (e.g., transmitted and / or received) during different clock cycles 182. To help illustrate, as in the depicted example, the value of the access parameter 174 indicated in the access parameter field 104 of the memory access request 98 may be communicated during a first clock cycle 182A. On the other hand, the value of the context parameter 142 indicated in the context parameter field 106 of the memory access request 98 may be communicated during an R-th clock cycle 182R.

[0230] In other words, in other embodiments where the background parameter field 106 is not included in the memory access request 98, the communication of the memory access request 98 may be completed before reaching the Rth clock cycle 182R. That is, at least in such cases, the communication of the memory access request 98 during the Rth clock cycle 182R may be avoided and therefore not performed, for example, to facilitate improved operating efficiency of the computing system.

[0231] As described above, in some embodiments, the timing and / or formatting of communications via the memory interface 170 may be governed by a communication protocol. For example, the communication protocol may govern what parameter fields 100 are communicated during each clock cycle 182. Additionally or alternatively, the communication protocol may govern the number of clock cycles 182 allotted for communication of each memory access request 98.

[0232] In other words, in embodiments where the context parameter field 106 is included in the memory access request 98, the communication protocol may be adjusted to additionally allocate an Rth clock cycle 182R for communication of the memory access request 98. To accommodate memory access requests 98 that include one or more context parameter fields 106, the communication protocol to be used for communication via the memory interface 170 may be adjusted to increase the number of clock cycles 182 during which each memory access request 98 is communicated (e.g., compared to embodiments where the context parameter field 106 is not included in the memory access request 98). As described above, in at least some cases, increasing the number of clock cycles 182 allocated for communication of the memory access request 98 may facilitate reducing implementation-associated costs, such as by avoiding the inclusion of one or more data paths 178 in the memory interface 170.

[0233] However, as described above, the number of clock cycles 182 used to communicate the memory access request 98 from the processing subsystem 12 to the memory subsystem 14 may affect the operating efficiency of the computing system. In particular, in some embodiments, the memory subsystem 14 may wait for the memory access request 98 to be fully received before taking action on the memory access request 98. Thus, in some embodiments, setting the communication protocol to increase the number of clock cycles 182 to communicate the memory access request 98 may delay the response of the memory subsystem 14 and thus affect (e.g., reduce) the operating efficiency of the computing system.

[0234] In other words, in some embodiments, different adjustments to the memory interface 170 may present different trade-offs between operational efficiency and implementation-associated costs. To facilitate balancing (e.g., optimizing) the trade-offs, in some embodiments, both the communication bandwidth and the communication protocol of the memory interface 170 may be adjusted. For example, to facilitate accommodating memory access requests 98 that include one or more context parameter fields 106, both the number of data paths 178 implemented in the memory interface 170 and the number of clock cycles 182 allocated for each memory access request 98 may be increased. In this way, the techniques described in the present disclosure may facilitate communicating context information associated with data access from the processing subsystem 12 to the memory subsystem 14, which may, at least in some cases, facilitate improving the operational efficiency of the computing system, such as by enabling the memory subsystem 14 to predictively control data storage based at least in part on the context information available to the processing subsystem 12.

[0235] One or more specific embodiments of the present disclosure are described herein and described in the corresponding figures. These described embodiments are merely examples of the currently disclosed technology. In addition, in an effort to provide a concise description of these embodiments, all features of the actual implementation scheme may not be described in the specification. It should be understood that in the development of any such actual implementation scheme, as in any engineering or design project, many implementation-specific decisions must be made to achieve the specific goals of the developer, such as subjecting system-related and business-related constraints, which can change from one implementation scheme to another. In addition, it should be understood that such development efforts may be complex and time-consuming, but can be a routine of design, construction and manufacture that a general technician who benefits from the present invention is engaged in.

[0236] When introducing elements of various embodiments of the present invention, the words "a," "an," and "the" are intended to mean that there are one or more of the elements described. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements besides the listed elements. Additionally, it should be understood that reference to "one embodiment" of the present invention is not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features.

[0237] The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments are susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the specific forms disclosed, but are intended to cover all modifications, equivalents and alternatives within the spirit and scope of the present disclosure.

Claims

1. An apparatus comprising a memory system configured to be communicatively coupled to a processing system via a memory bus, wherein the memory system comprises: a plurality of hierarchical memory levels implemented at least in part using one or more memory devices in the memory system; as well as A memory-side memory controller configured to: Receiving a first memory access request, the first memory access request requesting a first data block targeted by processing circuitry in the processing system, at least in part by: receiving, from the memory bus during a first clock cycle, a first address parameter indicating a first memory address associated with the first block of data; as well as receiving, from the memory bus during a second clock cycle different from the first clock cycle, a first context parameter indicating first context information associated with a current targeting of the first block of data; instructing the memory system to output the first block of data to the memory bus based at least in part on the first memory address indicated in the first address parameter of the first memory access request; as well as Data storage in the plurality of hierarchical memory levels of the memory system is controlled based at least in part on the first context information indicated in the first context parameter of the first memory access request.

2. The apparatus according to claim 1, wherein: The first address parameter identifies a virtual memory address used by the processing circuit to identify the first block of data, a physical memory address at which the first block of data is stored in the memory system, or both; and The first context parameter identifies a processor in the processing circuit that currently targets the first block of data, a processor core in the processing circuit that currently targets the first block of data, an application running in the processing circuit that causes the first block of data to be currently targeted, application instructions that when executed by the processing circuit cause the first block of data to be currently targeted, or any combination thereof.

3. The apparatus according to claim 1, wherein: The plurality of hierarchical memory levels implemented in the memory system include a lower memory level and an upper memory level; and The memory-side memory controller is configured to control data storage in the plurality of hierarchical memory levels at least in part by: predicting, based at least in part on the first context information indicated via the first context parameter in the first memory access request, that a second data block stored in the higher memory hierarchy will be a next target data block; as well as In anticipation of targeting the next target data block, the memory system is instructed to pre-fetch the second data block from the higher memory tier so that a copy of the second data block is stored in the lower memory tier.

4. The apparatus according to claim 1, wherein: The plurality of hierarchical memory levels implemented in the memory system include a lower memory level and an upper memory level; and The memory-side memory controller is configured to control data storage in the plurality of hierarchical memory levels at least in part by: predicting a next target time for the first data block based at least in part on the first context information indicated via the first context parameter in the first memory access request; issuing instructions to the memory system to store a copy of the first data block in the lower memory level of the plurality of hierarchical memory levels when a duration between a current time and the next target time of the first data block is less than a duration threshold; as well as When the duration between the current time and the next target time of the first data block is not less than the duration threshold, instructing the memory system to evict the copy of the first data block from the lower memory level of the plurality of hierarchical memory levels.

5. The apparatus of claim 1, wherein the processing system comprises: one or more caches organized to implement one or more cache memory levels hierarchically lower than the plurality of hierarchical memory levels implemented in the memory system; as well as A processor-side memory controller is configured to control storage of data in the one or more cache memory hierarchies implemented in the processing system based at least in part on the first context information associated with the current targeting of the first block of data.

6. The apparatus according to claim 5, wherein: The processor-side memory controller is configured to control data storage in the one or more cache memory hierarchies implemented in the processing system based at least in part on the first context information associated with the current targeting of the first block of data and first historical data access information available in the processing system; and The memory-side memory controller is configured to control data storage in the plurality of hierarchical memory levels implemented in the memory system based at least in part on the first context information indicated in the first memory access request and second historical data access information available in the memory system, wherein the second historical data access information available in the memory system is different from the first historical data access information available in the processing system when one or more data blocks previously targeted by the processing circuit in the processing system resulted in a processor-side hit.

7. The device according to claim 1, wherein: In response to receiving the first memory access request, the memory-side memory controller is configured to update historical data access information to be used to control data storage in the memory system based at least in part on the first context information indicated in the first memory access request.

8. The apparatus of claim 7, wherein: The memory system is configured to indicate the historical data access information via a historical data access information table comprising one or more table sections, each table section being dedicated to indicating table entries associated with different context information; and The memory-side memory controller is configured to: updating the historical data access information at least in part by adding a table entry identifying the first data block in a table section of the historical data access information table associated with the first context information indicated in the first memory access request; as well as Data storage in the plurality of hierarchical memory levels is controlled at least in part by predicting a next target data block, a next target time of the first data block, or both based at least in part on a memory address stride between data blocks identified by corresponding table entries in the table section associated with the first context information.

9. The apparatus of claim 7, wherein: The memory system is configured to indicate the historical data access information via a historical data access information table including one or more table sections each associated with different context information, wherein each table entry indicated in the historical data access information table includes: A chunk identifier parameter to identify the associated data chunk; and using a last access time parameter indicating when the associated data block was last accessed, an access count parameter indicating a number of times the associated data block has been accessed, or both; and The memory-side memory controller is configured to: updating the historical data access information at least in part by updating the last access time parameter in the table entry associated with the first data block to indicate a current time, incrementing a value of the access count parameter in the table entry associated with the first data block, or both; and Controlling data storage in the plurality of hierarchical memory levels at least in part by predicting a next target data block, a next target time of the first data block, or both based at least in part on the last access time parameter of one or more table entries in a table section of the historical data access information table associated with the first context information, the access count parameter of the one or more table entries indicated in the table section associated with the first context information, or both.

10. The apparatus of claim 1, wherein the second clock cycle in which the first background parameter of the first memory access request is received from the memory bus occurs after the first clock cycle in which the first address parameter of the first memory access request is received from the memory bus.

11. The apparatus of claim 1 , wherein the memory-side memory controller is configured to: Receiving a second memory access request to store a first block of data in the memory system is performed at least in part by: receiving from the memory bus the first address parameter indicating the first memory address associated with the first block of data; as well as receiving from the memory bus a second context parameter indicating second context information associated with generating the first data block; instructing the memory system to store the first block of data at a physical memory address in the plurality of hierarchical memory levels based at least in part on the first address parameter indicated in the second memory access request; as well as Data storage in the plurality of hierarchical memory tiers of the memory system is controlled based at least in part on the first context information indicated in the first memory access request and the second context information indicated in the second memory access request.

12. The apparatus of claim 1, wherein the memory-side memory controller is configured to: Receiving a second memory access request to return a second data block targeted by the processing circuit in the processing system at least in part by: receiving, from the memory bus during a third clock cycle, a second address parameter indicating a second memory address associated with the second block of data; as well as receiving, from the memory bus during a fourth clock cycle different from the third clock cycle, a second context parameter indicating second context information associated with current targeting of the second block of data, wherein the second context parameter indicates a different type of context information than the first context parameter indicated in the first memory access request; instructing the memory system to output the second block of data to the memory bus based at least in part on the second memory address indicated in the second address parameter of the second memory access request; as well as Data storage in the plurality of hierarchical memory levels of the memory system is controlled based at least in part on the second context information indicated in the second context parameter of the second memory access request.

13. The apparatus of claim 1, wherein the memory bus comprises: A plurality of conductors configured to: communicating the first address parameter during the first clock cycle; as well as communicating the first context parameter indicative of the first context information associated with the current targeting of the first block of data during the second clock cycle; as well as Additional conductors configured to: communicating, at least in part during the first clock cycle, a second context parameter indicative of second context information associated with the current targeting of the first block of data; communicating, at least in part during the second clock cycle, the second context parameter indicative of the second context information associated with the current targeting of the first block of data; or Both.

14. A method of operating a computing system, comprising: Receiving, using a memory control circuit in a memory subsystem of the computing system, a memory access request output to a memory bus coupled between the memory subsystem and a processing subsystem of the computing system, wherein the memory access request comprises: an address parameter field to indicate a memory address associated with a first data block targeted by the memory access request; and A background parameter field for indicating background information associated with generation of the first data block, targeting of the first data block, or both; locating, using the memory control circuitry, the first block of data in a plurality of hierarchical memory levels implemented in the memory subsystem based at least in part on the memory address indicated in the address parameter field of the memory access request; instructing, using the memory control circuitry, based at least in part on the first block of data, the memory subsystem to output the first block of data to the memory bus to enable processing circuitry implemented in the processing subsystem to perform a data processing operation; updating, using the memory control circuitry, historical data access information stored in the memory subsystem based at least in part on the context information indicated in the context parameter field of the memory access request; and Data storage in the plurality of hierarchical memory levels implemented in the memory subsystem is controlled using the memory control circuitry based at least in part on the historical data access information.

15. The method of claim 14, wherein receiving the memory access request comprises: receiving the address parameter field of the memory access request from the memory bus during a first clock cycle; as well as The context parameter field of the memory access request is received from the memory bus during a second clock cycle following the first clock cycle.

16. The method of claim 14, wherein: Updating the historical data access information stored in the memory subsystem includes adding a table entry identifying the first data block to a table section, wherein each data block identified in the table section is associated with a transaction context matching the context information associated with the first data block; and Controlling data storage in the plurality of hierarchical memory levels includes: predicting that a second block of data stored in a higher memory level of the plurality of hierarchical memory levels implemented in the memory subsystem will be next targeted by the transaction context based at least in part on a memory address stride between the blocks of data identified by corresponding table entries in the table segment associated with the transaction context; as well as The memory subsystem is instructed to pre-fetch the second block of data from the higher memory level so that a copy of the second block of data is stored in a lower memory level of the plurality of hierarchical memory levels.

17. The method of claim 14, wherein receiving the memory access request comprises: receiving the address parameter field of the memory access request from a first subset of conductors implemented in the memory bus; as well as The context parameter field of the memory access request is received in parallel from a second subset of conductors implemented in the memory bus.

18. A computing system comprising a memory subsystem, wherein the memory subsystem comprises: one or more memory-side caches organized to implement a first memory hierarchy in the memory subsystem; one or more memory devices organized to implement a second memory level in the memory subsystem that is higher than the first memory level; one or more internal communication buses coupled to the one or more memory-side caches and the one or more memory devices; as well as a bus interface coupled to the one or more internal communication buses, wherein the bus interface includes a plurality of pins each configured to couple to a corresponding conductor of an external communication bus to enable the memory subsystem to: receiving a memory access request including an access parameter field and a context parameter field output by a processing subsystem of the computing system to the external communication bus, wherein context information used by the processing subsystem to control storage of data in one or more processor-side caches is indicated in the context parameter field of the memory access request; and Memory access is provided to the processing subsystem based at least in part on a memory address indicated in the access parameter field of the memory access request.

19. The computing system of claim 18, wherein the bus interface is configured to: receiving the memory address indicated in the access parameter field of the memory access request from the external communication bus during a first clock cycle; and The context information indicated in the context parameter field of the memory access is received from the external communication bus during a second clock cycle following the first clock cycle.

20. The computing system of claim 18, wherein the bus interface is configured to: receiving the memory address indicated in the access parameter field of the memory access request from the external communication bus via a first subset of the plurality of pins implemented in the bus interface; and The context information indicated in the context parameter field of the memory access request is received in parallel from the external communication bus via a second subset of the plurality of pins implemented in the bus interface.

Images