Patent Description:
DRAM devices employ row buffers (at least one per bank) in which memory reads and writes take place. Accesses to a DRAM row that is different from the one in the row buffer requires closing the currently buffered or open row and activating the requested row, which is referred to as a row-buffer conflict and incurs performance and energy penalties. DRAM row-buffer conflicts limit the optimal exploitation of the available memory bandwidth and increase the memory-access latencies due to closing and activating DRAM rows. Memory-access conflicts are further increased by sub-optimal physical-address allocations by the operating system (OS). Further, software memory access patterns frequently cause accesses to contend for the same row buffer causing thrashing and forcing rows to be closed after only a few accesses, thereby reducing the performance and energy efficiency of memory systems.

<CIT> discloses a memory access optimizer that monitors physical memory addresses and detects a memory access conflict based on the monitored physical memory addresses. The data stored at a physical address for which a conflict was detected is transferred to a new physical address. The optimizer uses a scheduler and a conflict detector that examines access patterns of the physical memory addresses to detect a conflict.

<NPL>, discloses a memory access scheduling technique that improves the performance of a "<NUM>-D" memory system such as a DRAM memory system having banks, rows, and columns. The technique increases the bandwidth utilization of these DRAMs by buffering memory references and choosing to complete them in an order that both accesses the internal banks in parallel and maximizes the number of column accesses per row access. Rixner et al. , however, do not address what to do when memory access patterns create thrashing in systems employing memory controllers that already attempt to optimize scheduling to reduce row conflicts. <CIT> discloses improvements for "leveling" or averaging out more evenly the number of activate/precharge cycles seen by the rows of a memory so that one or more particular rows are not excessively stressed. A memory controller has a remapping block arranged to move data from a source physical location in the memory component to a selected destination physical location in the memory component, and to remap a logical address corresponding to the source row to a physical address corresponding to the destination row for accessing the moved data.

A memory controller of the invention is defined by claim <NUM> and a method for conflict detection of the invention is defined by claim <NUM>.

In the following description, the use of the same reference numerals in different drawings indicates similar or identical items. Unless otherwise noted, the word "coupled" and its associated verb forms include both direct connection and indirect electrical connection by means known in the art, and unless otherwise noted any description of direct connection implies alternate embodiments using suitable forms of indirect electrical connection as well. Additionally, the terms remap and migrate, and variations thereof, are utilized interchangeably as a descriptive term for relocating.

A memory controller as defined in claim <NUM> includes a decoder, a queue, and an arbiter. The decoder is configured to receive memory access requests, and to decode the memory access requests into decoded memory addresses, each of the decoded memory addresses including a bank address and a row address. The queue is configured to receive and store, along with other address information, the corresponding decoded memory address or a corresponding remapped physical address for each memory access request. The arbiter is coupled to the queue and is configured to select entries from the queue efficiently based on the other address information. The memory controller further comprises a conflict detector and an indirection table. The conflict detector is coupled to the arbiter and is configured to detect accesses to memory rows in a subset of memory and to monitor, for each memory row of the subset, a corresponding memory row activation count and a corresponding memory row accesses per activation count, identify a frequent conflict, wherein a frequent conflict is determined if the corresponding memory row activation count is greater than a predetermined memory row activation count threshold, and the corresponding memory row access per activation count is less than a predetermined memory row access per activation count threshold, and selectively trigger remapping of a memory row associated with the identified frequent conflict from an original memory bank to a memory row in a second memory bank. The indirection table is coupled to the conflict detector and is configured to selectively perform said remapping and to provide said corresponding remapped physical address.

In yet another form, a data processing system includes a memory, and the memory controller.

In still another form, a method for conflict detection based on access statistics to a subset of a memory includes detecting closure of an open row in the subset of the memory. In response to the detecting of the closure, whether a tracking system has an entry for the row whose closure has been detected is checked. In response to the tracking system having an entry for the row whose closure has been detected, row access statistics corresponding to the row are updated. In response to the tracking system not having an entry for the row whose closure has been detected, row access statistics of a not-recently accessed row, in the tracking system, are replaced with row access statistics associated with the row whose closure has been detected. Activations for the row whose closure has been detected to a conflict activation threshold are compared. In response to the activations being greater than the conflict activation threshold, an average count of accesses per activation is compared to a predetermined row accesses per activation threshold for the row whose closure has been detected in the subset of the memory to determine if the row is a candidate for remapping.

<FIG> illustrates in block diagram form a data processing system <NUM> according to some embodiments. Data processing system <NUM> includes generally a data processor <NUM>, a memory system <NUM>, a peripheral component interconnect express (PCIe) system <NUM>, a universal serial bus (USB) system <NUM>, and a disk drive <NUM>. Data processor <NUM> operates as the central processing unit (CPU) of data processing system <NUM> and provides various buses and interfaces useful in modern computer systems. These interfaces include two double data rate (DDRx) memory channels, a PCIe root complex for connection to a PCIe link, a USB controller for connection to a USB network, and an interface to a Serial Advanced Technology Attachment (SATA) mass storage device.

Memory system <NUM> includes a memory channel <NUM> and a memory channel <NUM>. Memory channel <NUM> includes a set of dual inline memory modules (DIMMs) connected to a memory bus <NUM>, including representative DIMMs <NUM>, <NUM>, and <NUM> that in this example correspond to separate ranks. Likewise, memory channel <NUM> includes a set of DIMMs connected to a memory bus <NUM>, including representative DIMMs <NUM>, <NUM>, and <NUM>.

PCIe system <NUM> includes a PCIe switch <NUM> connected to the PCIe root complex in data processor <NUM>, a PCIe device <NUM>, a PCIe device <NUM>, and a PCIe device <NUM>. PCIe device <NUM> in turn is connected to a system basic input/output system (BIOS) memory <NUM>. System BIOS memory <NUM> can be any of a variety of non-volatile memory types, such as read-only memory (ROM), flash electrically erasable programmable ROM (EEPROM), and the like.

USB system <NUM> includes a USB hub <NUM> connected to a USB master in data processor <NUM>, and representative USB devices <NUM>, <NUM>, and <NUM> each connected to USB hub <NUM>. USB devices <NUM>, <NUM>, and <NUM> could be devices such as a keyboard, a mouse, a flash EEPROM port, and the like.

Disk drive <NUM> is connected to data processor <NUM> over a SATA bus and provides mass storage for the operating system, application programs, application files, and the like.

Data processing system <NUM> is suitable for use in modern computing applications by providing memory channel <NUM> and memory channel <NUM>. Each of memory channels <NUM> and <NUM> can connect to DDR memories such as DDR version <NUM> (DDR4), low power DDR4 (LPDDR4), graphics DDR version five (gDDR5), and high bandwidth memory (HBM), and can be adapted for future memory technologies. These memories provide high bus bandwidth and high speed operation.

<FIG> illustrates in block diagram form a data processor <NUM> suitable for use in data processing system <NUM> of <FIG>. Data processor <NUM> includes generally a central processing unit (CPU) core complex <NUM>, a graphics core <NUM>, a set of display engines <NUM>, a memory management hub <NUM>, a data fabric <NUM>, a set of peripheral controllers <NUM>, a set of peripheral bus controllers <NUM>, a system management unit (SMU) <NUM>, and a set of memory controllers <NUM> (memory controller <NUM> and <NUM>).

CPU core complex <NUM> includes a CPU core <NUM> and a CPU core <NUM>. In this example, CPU core complex <NUM> includes two CPU cores, but in other embodiments CPU core complex can include an arbitrary number of CPU cores. Each of CPU cores <NUM> and <NUM> is bi-directionally connected to a system management network (SMN), which forms a control fabric, and to data fabric <NUM>, and is capable of providing memory access requests to data fabric <NUM>. Each of CPU cores <NUM> and <NUM> may be unitary cores, or may further be a core complex with two or more unitary cores sharing certain resources such as caches.

Graphics core <NUM> is a high performance graphics processing unit (GPU) capable of performing graphics operations such as vertex processing, fragment processing, shading, texture blending, and the like in a highly integrated and parallel fashion. Graphics core <NUM> is bidirectionally connected to the SMN and to data fabric <NUM>, and is capable of providing memory access requests to data fabric <NUM>. In this regard, data processor <NUM> may either support a unified memory architecture in which CPU core complex <NUM> and graphics core <NUM> share the same memory space, or a memory architecture in which CPU core complex <NUM> and graphics core <NUM> share a portion of the memory space, while graphics core <NUM> also uses a private graphics memory not accessible by CPU core complex <NUM>.

Display engines <NUM> render and rasterize objects generated by graphics core <NUM> for display on a monitor. Graphics core <NUM> and display engines <NUM> are bi-directionally connected to a common memory management hub <NUM> for uniform translation into appropriate addresses in memory system <NUM>, and memory management hub <NUM> is bi-directionally connected to data fabric <NUM> for generating such memory accesses and receiving read data returned from the memory system.

Data fabric <NUM> includes a crossbar switch for routing memory access requests and memory responses between any memory accessing agent and memory controllers <NUM>. It also includes a system memory map, defined by BIOS, for determining destinations of memory accesses based on the system configuration, as well as buffers for each virtual connection.

Peripheral controllers <NUM> include a USB controller <NUM> and a SATA interface controller <NUM>, each of which is bi-directionally connected to a system hub <NUM> and to the SMN bus. These two controllers are merely exemplary of peripheral controllers that may be used in APU <NUM>.

Peripheral bus controllers <NUM> include a system controller or "Southbridge" (SB) <NUM> and a PCIe controller <NUM>, each of which is bi-directionally connected to an input/output (I/O) hub <NUM> and to the SMN bus. I/O hub <NUM> is also bi-directionally connected to data fabric <NUM>.

SMU <NUM> is a local controller that controls the operation of the resources on data processor <NUM> and synchronizes communication among them. SMU <NUM> manages power-up sequencing of the various processors on data processor <NUM> and controls multiple off-chip devices via reset, enable and other signals. SMU <NUM> includes one or more clock sources not shown in <FIG>, such as a phase locked loop (PLL), to provide clock signals for each of the components of data processor <NUM>. SMU <NUM> also manages power for the various processors and other functional blocks, and may receive measured power consumption values from CPU cores <NUM> and <NUM> and graphics core <NUM> to determine appropriate power states.

<FIG> illustrates in block diagram form a memory controller <NUM> for use in data processor <NUM> of <FIG> according to some embodiments. Memory controller <NUM> generally includes a system of arbitration <NUM> and an indirection table <NUM>, a conflict detector <NUM>, and clear logic <NUM>. System of arbitration <NUM> includes bank/channel/row decoder <NUM>, multiplexer <NUM>, arbiter <NUM>, and queue <NUM>. Conflict detector <NUM> includes conflict logic <NUM> and tracking system <NUM>. Memory controller <NUM> is an instantiation of a memory controller for a single memory channel.

Bank/row/channel decoder <NUM> includes an input for receiving memory access requests from data fabric <NUM>, and an output for providing the physical memory address to multiplexer <NUM> and indirection table <NUM>. The memory access requests include access addresses in the physical address space represented in a normalized format. Bank/row/channel decoder <NUM> converts the normalized addresses into a format that can be used to address the actual memory devices in memory system <NUM>, as well as to efficiently schedule related accesses. This format includes a region identifier that associates the memory access request with a particular rank, a row address, a column address, a bank address, and a bank group. On startup, the system BIOS queries the memory devices in memory system <NUM> to determine their size and configuration, and provides the size and configuration to conflict detector <NUM>. Additionally, bank/row/channel decoder <NUM> decodes the physical memory address information into rank, row address, column address, bank address, and bank group in the memory system. Bank/row/channel decoder <NUM> provides the decoded memory address to multiplexer <NUM>.

Multiplexer <NUM> includes a first input connected to bank/row/channel decoder <NUM>, a second input, a control input for receiving the hit signal, and an output. The second input, connected to indirection table <NUM>, is for receiving the remapped address. The output signal is connected to queue <NUM>.

Queue <NUM> includes an input connected to the output of the multiplexer <NUM>, a control input, and an output. Queue <NUM> processes memory access requests received from the memory accessing agents in data processing system <NUM>, such as CPU cores <NUM> and <NUM> and graphics core <NUM>. Queue <NUM> stores the address fields provided by multiplexer <NUM>, as well other address information that allows arbiter <NUM> to select memory accesses efficiently.

Arbiter <NUM> schedules the decoded physical memory addresses awaiting memory access in the queue <NUM> and provides an update to the tracking system <NUM>, is bi-directionally connected to queue <NUM>, and is connected to tracking system <NUM>. The update to the tracking system corresponds to the memory access statistics of the dynamically selected physical memory addresses. Arbiter <NUM> includes information to enforce ordering rules when selecting memory accesses, and enables efficiency by scheduling of accesses to the memory bus. Arbiter <NUM> uses timing to enforce proper timing relationships by determining whether certain accesses in queue <NUM> are eligible for issuance based on DRAM timing parameters.

Conflict detector <NUM> includes conflict logic <NUM> and tracking system <NUM>. Conflict logic <NUM> determines, from the memory access statistics, when a memory row causes frequent row conflicts and is bi-directionally connected to indirection table <NUM> and tracking system <NUM>. A frequent row conflict is a number of row-buffer conflicts in a subset of a memory exceeding a threshold. The frequent row conflict occurs when the memory row activation count is higher than a defined activation count threshold, and the memory access per activation count is lower than a defined access per activation count threshold. Conflict logic <NUM> provides the logic that controls select operations of conflict detector <NUM>. Although described as a component of memory controller <NUM>, in one embodiment, conflict detector <NUM> is a separate component from memory controller <NUM>. Tracking system <NUM> stores memory access statistics, and is bi-directionally connected to conflict logic <NUM> and receives arbitrated inputs from arbiter <NUM>. Tracking system <NUM> is implemented as a cache memory, a table of access statistics, or an algorithm for tracking memory row access counts.

Conflict detector <NUM> tracks the memory access statistics for the first memory bank, and determines if the first memory bank contains a frequent conflict row. In response to detecting the existence of the frequent conflict row, the conflict detector <NUM> triggers the migration of the frequent conflict row to an available row in the second memory bank. The data processing system also includes an indirection table <NUM> connected to the conflict detector <NUM> that maintains a record of migrated rows. After the migration of the frequent conflict row, the indirection table <NUM> receives a memory request and remaps requests to the frequent conflict row in the first memory bank to the row in the second memory bank it was migrated to.

Indirection table <NUM> maintains state information about select (remapped) memory pages in each bank and rank of the memory channel for arbiter <NUM>, and is connected to conflict logic <NUM>. Additionally, indirection table <NUM> has an input connected to bank/row/channel decoder <NUM> and clear content logic <NUM>, and an output connected to multiplexer <NUM>.

Clear content logic <NUM> includes an output to indirection table <NUM> and an output to conflict logic <NUM>. Clear content logic <NUM> generates refresh commands periodically to indirection table <NUM> and conflict logic <NUM>. Additionally, clear content logic <NUM> allows the manual and automatic generation of commands to clear and/or reset the content of indirection table <NUM> and conflict logic <NUM>.

In operation, a memory controller such as memory controller <NUM> of <FIG> is connected to and receives memory access requests from a memory accessing agent, such as a CPU core in CPU core complex <NUM> or graphics core <NUM> of <FIG>. Memory controller <NUM> is also adapted to connect to memory system <NUM> of <FIG>. As described above, memory system <NUM> can include multiple ranks of memory implemented as DIMMs <NUM>, <NUM>, and <NUM> in <FIG>. Arbiter <NUM> picks memory access requests from queue <NUM> based on predetermined criteria based on performance and efficiency consideration. In response to a memory bus access request, conflict detector <NUM> monitors activity in a memory bank to selectively track performance-critical patterns.

In one embodiment, conflict detector <NUM> monitors DRAM-row granularity access statistics and detects performance-critical conflicts. In general, bank/row/channel decoder <NUM> receives memory access requests and provides the decoded physical address to multiplexer <NUM> and indirection table <NUM>. Queue <NUM> stores memory access requests that are selectively provided by the bank/channel/row decoder <NUM> or the indirection table <NUM> via multiplexer <NUM>. Arbiter <NUM> selects memory requests from among those pending in queue <NUM> to issue to the memory channel. Tracking system <NUM> detects the access to each memory row and monitors the memory row activation count and a memory row accesses per activation count. A row with an activation count higher than a predetermined activation count and an access per activation count lower than a predetermined access per activation is considered performance-critical and is marked by conflict logic <NUM> as a remapping candidate.

Tracking system <NUM> maintains row-access information for the C most-recently-accessed rows for each DRAM bank in a memory cache, where C is the number of entries in the memory cache per DRAM bank. Each entry tracks the number of activations and an approximate running average of the number of accesses per activation for the corresponding DRAM row. An update to tracking system <NUM> is made when a currently open row, R, is being closed. If there is no existing entry for row R in tracking system <NUM>, an entry is inserted using a memory row granularity replacement policy. In one embodiment, the memory row granularity replacement policy replaces the entry for the least-recently-accessed row with an entry for row R. In another embodiment, the replacement policy replaces the entry in tracking system <NUM> with the highest average accesses per activation (i.e., the one that is typically least likely to be performance-critical) with an entry for row R if the number of accesses to row R since row R was activated is fewer than the average accesses per activation in the entry being replaced. If an entry for row R already exists in tracking system <NUM>, then it is updated. Subsequently, the updated row-access statistics of an entry is checked to see if the row has more than N activations and fewer than M average accesses per activation, where N and M are predefined or dynamically adjusted thresholds. If so, the row R is experiencing frequent performance-critical page conflicts and becomes a candidate for migration.

A bank with few or no heavily conflicted rows is the destination for the migration. Such bank may have <NUM>) no rows with more than N activations, <NUM>) no rows with fewer than M average accesses per activation, or <NUM>) a combination of <NUM> and <NUM>, where N and M are the same as the previously defined variables.

In one embodiment, tracking system <NUM> maintains a rate of the frequent performance-critical page conflicts by implementing a cache with memory row granularity replacement policy, a tracking algorithm, or a table of access statistics. The memory row granularity replacement policy can be implemented within a memory cache. A tracking algorithm can be implemented by determining rows with performance-critical row conflicts.

For example, the Majority Element Algorithm (MEA) may be used to identify rows that are most-frequently opened and closed with fewer than a threshold number of intervening accesses. MEA is a data analytics algorithm that enables identification of the most frequently-occurring elements in a stream of data elements. The sequence of rows that are opened and closed with fewer than a threshold number of intervening accesses are the target data elements. The tracking algorithm of the MEA stores the most frequently occurring elements with high probability, thereby providing the rows with frequent performance-critical page conflicts to conflict logic <NUM>.

Additionally, a table of access statistics may be implemented as tracking system <NUM>. The table of access statistics is a full table with an entry for every DRAM row. The table of access statistics can be used to determine frequent performance-critical page conflicts by searching for rows that have more than N activations and fewer than M average accesses per activation, where N and M are predefined or dynamically adjusted thresholds. The row-granularity tracking statistics and data structures may be cleared and/or re-initialized, via clear content logic <NUM>, periodically or at specific points (e.g., starting up a new application) to avoid the influence of long-past events that are no longer relevant.

In another example not covered by the claims, per-bank statistics on activations and accesses per activation are maintained. In general, thresholds N and M are used to determine if a bank has frequent performance-critical row conflict (i.e., more than N activations and less than M average accesses per activation). If so, specific rows from that bank to migrate can be determined. A first example of determining rows to migrate includes identifying the bank has frequent performance-critical row conflicts, the very next one or more rows that are opened in that bank and are closed with less than a threshold number of accesses are remapped.

In still another embodiment, in addition to per-bank statistics of row openings and accesses, statistics are maintained for a predetermined number of rows in each bank. When a row R is closed, if the number of accesses to row R since it was last opened is fewer than a predetermined threshold, T, the row identification and number of accesses is inserted into tracking system <NUM>. If the set of tracked entries is full, the new entry may displace an existing entry. The displaced entry may be the oldest entry in the set or the entry with the highest access count. In one or more embodiments, the new entry (for row R) may not be inserted into the set if it has an access count that is greater than the access counts of all entries in the set of rows for which statistics are maintained. When a bank is determined to have frequent performance-critical row conflict, one or more of the tracked rows within tracking system <NUM> with fewer than a threshold number of accesses in their last activation are remapped.

<FIG> illustrates a memory controller and associated memory bus for dynamic memory remapping. Memory system <NUM> includes memory controller <NUM>, system of arbitration <NUM>, conflict detector engine <NUM>, and indirection table <NUM>. Memory system <NUM> includes a memory channel <NUM>. Memory channel <NUM> includes a set of memory modules connected to a memory bus, including representative memory modules <NUM>, <NUM>, and <NUM> connect to memory bus <NUM>. In this example, the memory modules correspond to separate ranks.

Indirection table <NUM>, similar to indirection table <NUM>, maintains state information about active pages in each bank and rank of the memory channel that have been remapped. Conflict detector engine <NUM> and indirection table <NUM> are connected to memory channel <NUM> and are shared across the memory modules (<NUM>, <NUM>, <NUM>). Conflict detector engine <NUM> tracks row-access information and remap table <NUM> holds remap information across at least a subset of the memory banks in the memory modules (<NUM>, <NUM>, <NUM>).

In operation, to reduce row-buffer conflicts, conflict detector engine <NUM> triggers the migration of heavily conflicted rows within the banks of a rank to the less contended DRAM bank(s). A bank with few or no heavily conflicted rows is the destination for the migration (i.e., remapping). Such bank may have <NUM>) no rows with more than N activations, <NUM>) no rows with fewer than M average accesses per activation, or <NUM>) a combination of <NUM> and <NUM>, where N and M are the same as the previously defined variables. In one example, conflict logic copies data from the source rows to free (unused) row(s) in the destination bank(s). In another example, conflict detector engine <NUM> triggers (e.g., via an interrupt) a computing device within the system (e.g., processor <NUM> of system <NUM>) to copy data from the source rows to free (unused) row(s) in the destination bank(s). Once the data copy is complete, the indirection table <NUM> is updated to reflect the corresponding remapping of the source row.

In a first example, a free list that an operating system (OS) maintains for tracking unused OS pages is used to identify a free DRAM row in a different bank as a destination for migration. Even if the granularity of DRAM rows is different from the OS pages (e.g., <NUM> row size vs. <NUM> page size), the free list is utilized to find a free row. When a free row is identified, the corresponding OS page is marked as used and is removed from the free list to prevent the OS from allocating the same page for other uses.

In another example, the conflict detector engine <NUM> contains hardware logic to determine the availability of free rows for remapping. A few rows of each bank (e.g., top-most X rows of every bank) are reserved initially for remapping. In one example, a separate tracking table tracks the identification of rows that are reserved. When a reserved row is claimed for remapping, the row is marked in the tracking table. When a bank has no more free rows, it is no longer eligible for a destination of remapping until rows are freed again. In one example, conflict logic dynamically evaluates when to increase, decrease, and/or defragment, or otherwise manage the reserved rows within one or more banks. Additionally, conflict logic determines when and which rows to revert to the original mappings.

In one example, conflict detector engine <NUM> determines the need to restore the original mapping when it determines the bank is no longer heavily conflicted, a different row is identified to have more frequent performance-critical conflicts than the currently remapped rows, and/or the number of free OS pages reduces below a determined threshold. Accordingly, conflict detector engine <NUM> restores original mappings, thereby freeing up physical-address space in a bank.

Conflict detector engine <NUM> restores the original mapping by <NUM>) copying the data in the remapped row back to the original row (if any writes are made after remapping), <NUM>) updating the table for the set-aside rows, and <NUM>) deallocating the corresponding entry in the indirection table <NUM>. Conflict detector engine <NUM> and indirection table <NUM> can be shared by the memory modules that share the same address space or can be a per-memory-channel structure that constrains remapping only within memory channel <NUM>. Alternatively, each processor core <NUM> or a group of cores <NUM> can have a copy of indirection table <NUM> that is synchronously updated. Indirection table <NUM> is accessed before memory requests are sent to the individual memory banks but after cache accesses. In one example, indirection table <NUM> is indexed by the original bank and row identifications. Addresses that hit in indirection table <NUM> access the new bank and row specified in the corresponding table entry. Other addresses continue using previously defined, or default bank-row mapping. The indirection table <NUM> can be managed as a fixed-size content-addressable memory or SRAM. The number of table entries within indirection table <NUM> can be determined by simulation or area and/or power constraints. The remapping capacity provided by conflict detector engine <NUM> is proportional to the number of entries indirection table <NUM> includes.

<FIG> illustrates a flow diagram method for row-level conflict detection that may be used by the memory controller of <FIG>. Method <NUM> begins at the start block. A determination is made at block <NUM>, whether conflict detector <NUM> detects closure of an open row, R, in a memory bank. If closure of row R is not detected, the process ends. If closure of row R is detected, the process continues to block <NUM>. At block <NUM>, conflict detector determines if there is an existing entry for row R in tracking system <NUM>. If there is an existing entry for row R in tracking system <NUM>, the process continues to block <NUM> where conflict detector <NUM> updates row access statistics for row R in tracking system <NUM>. If there is not an existing entry for row R in tracking system <NUM>, at block <NUM>, conflict logic <NUM> replaces the least recently accessed row in tracking system <NUM> with row R, then continues to block <NUM>. Conflict detector <NUM> assesses current row access statistics in tracking system <NUM> for row R, at block <NUM>. A determination is made, at block <NUM>, whether row R activations are greater than a dynamically or statically determined conflict activation threshold. If the number of row R activations are not greater than the conflict activation threshold, the process ends. If the number of activations are greater than the conflict activation threshold, the process continues to block <NUM>. At block <NUM>, conflict detector <NUM> determines whether the average accesses per activation is less than a determined conflict access threshold, where the threshold is dynamically or statically determined. If the average accesses per activation is not less than a determined conflict access threshold, the process ends. If the average access per activation is less than a determined conflict access threshold, the process continues to block <NUM>. At block <NUM>, conflict detector <NUM> indicates row R as a candidate for remapping (also described as migration). The process concludes at the end block.

<FIG> illustrates a flow diagram method for bank level conflict detection that may be used by the memory controller of <FIG>. Method <NUM> begins at the start block and continues to block <NUM> where when a row of an identified memory bank is closed, conflict detector retrieves the number of row activations in an identified memory bank. The conflict detector determines if the row activation count is greater than the row activation threshold, at block <NUM>. If the row activation count is not greater than the row activation threshold, the process ends. If the row activation count is greater than the row activation threshold, the process continues to block <NUM>. A determination is made at block <NUM> whether the row accesses per activation (APA) is less than the row accesses per activation threshold. If the row accesses per activation is not less than the row accesses per activation threshold, the process ends. If the row accesses per activation is less than the row accesses per activation threshold, the process continues to block <NUM>. At block <NUM> another determination is made, whether the number of accesses per activation to recently closed rows are less than a determined row accesses per activation threshold. If the number of row accesses per activation to recently closed rows are less than a determined row accesses per activation threshold, the process continues to block <NUM>. At block <NUM>, conflict detector <NUM> indicates the specified bank as a candidate to provide rows for remapping (or migrating) rows. If the number of access per activation to recently closed rows is not less than a determined access per activation threshold, the row access statistics within tracking system <NUM> are updated in block <NUM>. The process concludes at the end block.

<FIG> illustrates a flow diagram method for remapping memory that may be used by the memory controller of <FIG>. Method <NUM> initiates at the start block. At block <NUM> conflict detector <NUM> initiates a migration (or remapping). At block <NUM>, using the free row table, conflict detector <NUM> identifies a free row reserved for migration in a bank different from the migration source. At block <NUM>, the selected rows are indicated as slated to receive the migration entry. At block <NUM>, the data from the conflict rows is copied to the identified rows in the different bank. At block <NUM>, conflict detector <NUM> updates indirection table <NUM> to reflect migration of the rows.

<FIG> illustrates a flow diagram method for deallocating an indirection table entry that may be used by the memory controller of <FIG>. Method <NUM> initiates at the start block and continues to block <NUM>. At block <NUM>, conflict logic <NUM> determines whether to restore an original mapping of the indirection table. If conflict logic <NUM> determines not to restore indirection table <NUM> entry to the original mapping, the process ends. If conflict logic <NUM> determines to restore indirection table <NUM> entry to the original mapping, the process continues to block <NUM>. At block <NUM>, conflict logic <NUM> copies data in the remapped row of a bank back to the original row of the original bank. Conflict logic <NUM> updates free row table to indicate the availability of the newly freed remap row at block <NUM>. At block <NUM>, conflict logic <NUM> deallocates the entry in indirection table <NUM> for the restored row. The process concludes at the end block.

Some or all of the methods illustrated in <FIG>, <FIG>, <FIG> and <FIG> may be governed by instructions that are stored in a computer readable storage medium and that are executed by at least one processor. Each of the operations shown in <FIG>, <FIG>, <FIG> and <FIG> may correspond to instructions stored in a non-transitory computer memory or computer readable storage medium. In various embodiments, the non-transitory computer readable storage medium includes a magnetic or optical disk storage device, solid-state storage devices such as Flash memory, or other non-volatile memory device or devices. The computer readable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted and/or executable by one or more processors.

Memory controller <NUM> may interface to other types of memory besides DDRx memory, such as high bandwidth memory (HBM), types of synchronous DRAM, and the like. Although described in the context of DRAM-based memory, other memory systems, for instance, diestacked DRAMs, and NVRAMs may also be utilized. For any memory technology, a "conflict" is described to be caused by interleaved memory-access streams to the same memory module that cause additional performance penalties. While the illustrated embodiment showed each rank of memory corresponding to separate DIMMs, in other embodiments each DIMM can support multiple ranks. Moreover, the memory channel may include a plurality of ranks of DDR memory or just a single rank.

Claim 1:
A memory controller (<NUM>/<NUM>), comprising:
a decoder (<NUM>) configured to receive memory access requests, and to decode the memory access requests into decoded memory addresses, each of the decoded memory addresses including a bank address and a row address;
a queue (<NUM>) configured to receive and store, along with other address information, the corresponding decoded memory address or a corresponding remapped physical address for each memory access request;
an arbiter (<NUM>) coupled to the queue (<NUM>) configured to select entries from the queue (<NUM>) efficiently based on the other address information, wherein the memory controller further comprises:
a conflict detector (<NUM>), coupled to the arbiter (<NUM>) configured to:
detect accesses to memory rows in a subset of memory and to monitor, for each memory row of the subset, a corresponding memory row activation count and a corresponding memory row accesses per activation count;
identify a frequent conflict, wherein a frequent conflict is determined if, for a memory row of the subset, the corresponding memory row activation count is greater than a predetermined memory row activation count threshold, and the corresponding memory row access per activation count is less than a predetermined memory row access per activation count threshold; and
selectively trigger remapping of a memory row associated with the identified frequent conflict from an original memory bank to a memory row in a second memory bank; and
an indirection table (<NUM>) coupled to the conflict detector (<NUM>), configured to selectively perform said remapping and to provide said corresponding remapped physical address.