DRAM refresh management list

Abstract

The memory controller includes a command queue having a first input for receiving a memory access request and a memory interface queue having an output for coupling to a memory channel adapted to connect to at least one dynamic random access memory (DRAM) module. The refresh control circuit monitors activation commands transmitted over the memory channel. In response to the activation command satisfying specified conditions, the refresh control circuit identifies a candidate attack row associated with the activation command. A command is transmitted to the DRAM requesting that the candidate attack row be queued for mitigation in a future refresh or refresh management event.

Description

[Background technology]

[0001] Computer systems typically use inexpensive, high-density dynamic random access memory (DRAM) chips for main memory. When a particular row in a DRAM chip is activated for reading or writing, the word line associated with that row is activated and the contents of the memory cells along that row are read into a page buffer. Subsequent read and write accesses to memory cells in the row can occur entirely within the page buffer without accessing the row again. If the data processor later accesses another row in the same memory bank, the memory cells along the row are restored with a precharge operation before the other row can be activated.

[0002] Modern DRAM chips typically use deep submicron technology to store multiple gigabits (Gb) of data. Due to high density and small feature sizes, rows of memory are physically very close to other rows, so activating a particular row can disrupt data stored in adjacent rows by changing the charge on the memory cell capacitors. Until now, such disruptions have typically been harmless because memory cells are periodically refreshed. However, occasionally, some memory access patterns can cause a particular row to be activated and precharged multiple times before the next refresh cycle, corrupting memory cells in adjacent rows and reversing their logic states. After the corruption occurs, the original data is lost and cannot be restored by subsequent refresh cycles. As feature sizes shrink, this problem, known as "row hammer," becomes more difficult to mitigate because fewer row activations are required to cause the problem.

[0003] One known technique for addressing the data disruption problem is known as targeted row refresh (TRR). To ensure that a row of a DRAM is not activated multiple times within a refresh period without refreshing adjacent rows, a memory controller places the DRAM in TRR mode by setting a specific mode register bit. The controller then issues successive activate and precharge commands to rows physically adjacent to the potential aggressor row. Typically, TRR mode is self-clearing and automatically disabled after the defined TRR flow is complete. TRR mode can also be exited via a mode register set command upon completion of the defined TRR flow. While TRR allows the memory controller to mitigate the row hammer problem, TRR is initiated by setting the mode register, which requires a significant amount of time because all banks must be idle before the controller can issue the mode register set command. [Brief explanation of the drawings]

[0004] [Figure 1] 1 is a block diagram of an accelerated processing unit (APU) and memory system known in the prior art; [Figure 2] 2 is a block diagram of a memory controller suitable for use in an APU similar to FIG. 1 in accordance with some embodiments. [Figure 3] FIG. 1 is a block diagram of a memory device according to some embodiments. [Figure 4] FIG. 1 is a flow diagram of a process for handling refresh management according to some embodiments. [Figure 5] FIG. 10 is a flow diagram of a process for handling refresh management according to some further embodiments. [Figure 6]FIG. 1 is a flow diagram illustrating a process for selecting candidate aggressor rows according to some embodiments. [Figure 7] FIG. 10 is a flow diagram illustrating a process for selecting candidate attack lines, according to some further embodiments. DETAILED DESCRIPTION OF THE INVENTION

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

[0006] The memory controller includes a command queue having a first input for receiving a memory access request and a memory interface queue having an output for coupling to a memory channel adapted to connect to at least one dynamic random access memory (DRAM) module. An arbiter is connected to the command queue to select an entry from the command queue and place the entry in the memory interface queue for transmission on the memory channel. A refresh control circuit is connected to the arbiter and operable to monitor activation commands transmitted on the memory channel. In response to the activation command meeting specified conditions, a candidate attack row associated with the activation command is identified. A command is transmitted to the DRAM requesting that the candidate attack row be queued for mitigation in a future refresh or refresh management event.

[0007] A data processing system includes a data processor, a data fabric connected to the data processor, and a memory controller connected to the data fabric for fulfilling memory requests from the data processor. The memory controller includes a command queue having a first input for receiving memory access requests and a memory interface queue having an output for coupling to a memory channel adapted to connect to at least one dynamic random access memory (DRAM) module. An arbiter is connected to the command queue to select entries from the command queue and place the entries in the memory interface queue for transmission on the memory channel. A refresh control circuit is connected to the arbiter and operable to monitor activation commands transmitted on the memory channel. In response to the activation commands meeting specified conditions, candidate attack rows associated with the activation commands are identified. A command is transmitted to the DRAM requesting that the candidate attack rows be queued for mitigation in a future refresh or refresh management event.

[0008] The method includes receiving a plurality of memory access requests, including memory reads and memory writes. Memory access commands for satisfying the memory access requests are selectively placed in a memory interface queue, and transmitting the memory access commands from the memory interface queue to a memory channel coupled to at least one dynamic random access memory (DRAM). Activation commands transmitted on the memory channel are monitored. In response to the activation commands meeting specified conditions, candidate attack rows associated with the activation commands are identified. A command is transmitted to the DRAM requesting that the candidate attack rows be queued for mitigation in a future refresh or refresh management event.

[0009] 1 is a block diagram of an accelerated processing unit (APU) 100 and memory system 130 known in the prior art. APU 100 is an integrated circuit suitable for use as a processor in a host data processing system and generally includes a central processing unit (CPU) core complex 110, a graphics core 120, a set of display engines 122, a memory management hub 140, a data fabric 125, a set of peripheral controllers 160, a set of peripheral bus controllers 170, and a system management unit (SMU) 180.

[0010] CPU core complex 110 includes CPU core 112 and CPU core 114. In this example, CPU core complex 110 includes two CPU cores, but in other embodiments, CPU core complex 110 may include any number of CPU cores. Each of CPU cores 112 and 114 is bidirectionally connected to a system management network (SMN) that forms a control fabric and to data fabric 125, and can provide memory access requests to data fabric 125. Each of CPU cores 112 and 114 may be a single core, or may be a core complex with two or more single cores that share certain resources, such as a cache.

[0011] Graphics core 120 is a high-performance graphics processing unit (GPU) capable of performing graphics operations such as vertex processing, fragment processing, shading, and texture blending in a highly integrated and parallel manner. Graphics core 120 is bidirectionally connected to the SMN and data fabric 125 and can provide memory access requests to data fabric 125. In this regard, APU 100 can support either a unified memory architecture in which CPU core complex 110 and graphics core 120 share the same memory space, or a memory architecture in which CPU core complex 110 and graphics core 120 share a portion of the memory space, but graphics core 120 also uses private graphics memory that is inaccessible by CPU core complex 110.

[0012] Display engine 122 renders and rasterizes objects generated by graphics core 120 for display on a monitor. Graphics core 120 and display engine 122 are bidirectionally connected to a common memory management hub 140 for uniform translation to appropriate addresses in memory system 130, which in turn is bidirectionally connected to data fabric 125 for generating such memory accesses and receiving read data returned from the memory system.

[0013] Data fabric 125 includes a crossbar switch for routing memory access requests and responses between any memory accessing agent and memory management hub 140. The data fabric also includes a system memory map defined by the basic input / output system (BIOS) and buffers for each virtual connection to determine the destination of memory accesses based on the system configuration.

[0014] Peripheral controllers 160 include a universal serial bus (USB) controller 162 and a Serial Advanced Technology Attachment (SATA) interface controller 164, each of which is bidirectionally connected to a system hub 166 and an SMN bus. These two controllers are merely exemplary of peripheral controllers that may be used in APU 100.

[0015] Peripheral bus controller 170 includes a system controller or "Southbridge" (SB) 172 and a Peripheral Component Interconnect Express (PCIe) controller 174, each of which is bidirectionally connected to an input / output (I / O) hub 176 and the SMN bus. I / O hub 176 is also bidirectionally connected to system hub 166 and data fabric 125. Thus, for example, a CPU core can program registers in USB controller 162, SATA interface controller 164, SB 172, or PCIe controller 174 via accesses routed by data fabric 125 through I / O hub 176. Software and firmware for APU 100 is stored in a system data drive or system BIOS memory (not shown), which can be any of a variety of non-volatile memory types, such as read-only memory (ROM), flash, electrically erasable programmable ROM (EEPROM), etc. Typically, the BIOS memory is accessed via the PCIe bus, and the system data drive is accessed via the SATA interface.

[0016] SMU 180 is a local controller that controls the operation of resources on APU 100 and synchronizes communication between them. SMU 180 manages the power-up sequencing of the various processors on APU 100 and controls multiple off-chip devices via reset, enable, and other signals. SMU 180 includes one or more clock sources (not shown), such as a phase-locked loop (PLL), to provide clock signals to each of the components of APU 100. SMU 180 also manages power for the various processors and other functional blocks and can receive measured power consumption values ​​from CPU cores 112, 114 and graphics core 120 to determine appropriate power states.

[0017] Memory management hub 140 and its associated physical interfaces (PHYs) 151 and 152 are integrated with APU 100 in this embodiment. Memory management hub 140 includes memory channels 141 and 142 and a power engine 149. Memory channel 141 includes a host interface 145, a memory channel controller 143, and a physical interface 147. Host interface 145 bidirectionally connects memory channel controller 143 to data fabric 125 via a serial presence detect (SDP) link. Physical interface 147 bidirectionally connects memory channel controller 143 to PHY 151 and conforms to the DDR PHY Interface (DFI) specification. Memory channel 142 includes a host interface 146, a memory channel controller 144, and a physical interface 148. Host interface 146 bidirectionally connects memory channel controller 144 to data fabric 125 via another SDP. Physical interface 148 bidirectionally connects memory channel controller 144 to PHY 152 and conforms to the DFI specification. Power engine 149 is bidirectionally connected to SMU 180 via the SMN bus, to PHYs 151 and 152 via the APB, and to memory channel controllers 143 and 144. PHY 151 has a bidirectional connection to memory channel 131. PHY 152 has a bidirectional connection to memory channel 133.

[0018] Memory management hub 140 is an instantiation of a memory controller with two memory channel controllers and uses a shared power engine 149 to control the operation of both memory channel controller 143 and memory channel controller 144 in a manner described further below. Each of memory channels 141 and 142 can connect to state-of-the-art DDR memory, such as DDR version four (DDR4), low power DDR4 (LPDDR4), graphics DDR version five (gDDR5), and high bandwidth memory (HBM), and can accommodate future memory technologies. These memories provide high bus bandwidth and high-speed operation. At the same time, they also provide low-power modes to conserve power for battery-powered applications such as laptop computers, as well as built-in thermal monitoring.

[0019] Memory system 130 includes memory channel 131 and memory channel 133. Memory channel 131 includes a set of dual inline memory modules (DIMMs) connected to DDRx bus 132, including representative DIMMs 134, 136, and 138, which in this example correspond to individual ranks. Similarly, memory channel 133 includes a set of DIMMs connected to DDRx bus 139, including representative DIMMs 135, 137, and 139.

[0020] The APU 100 acts as the central processing unit (CPU) of the host data processing system and provides various buses and interfaces useful in modern computer systems, including 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 SATA mass storage device.

[0021] The APU 100 also implements various system monitoring and power saving functions. One system monitoring function in particular is thermal monitoring. For example, if the APU 100 gets too hot, the SMU 180 can reduce the frequency and voltage of the CPU cores 112, 114 and / or the graphics core 120. If the APU 100 gets too hot, the SMU can shut down completely. Thermal events can also be received from external sensors by the SMU 180 via the SMN bus, and the SMU 180 can reduce the clock frequency and / or power supply voltage accordingly.

[0022] Figure 2 is a block diagram of a memory controller 200 suitable for use in an APU such as Figure 1. Memory controller 200 generally includes a memory channel controller 210 and a power controller 250. Memory channel controller 210 generally includes an interface 212, a memory interface queue 214, a command queue 220, an address generator 222, a content addressable memory (CAM) 224, replay control logic 231 including a replay queue 230, a refresh control circuit block 232, a timing block 234, a page table 236, an arbiter 238, an error correction code (ECC) check circuit 242, an ECC generation block 244, and a data buffer 246.

[0023] Interface 212 has a first bidirectional connection to data fabric 125 via an external bus and has an output. In memory controller 200, this external bus conforms to the Advanced Extensible Interface version 4 specified by ARM Holdings, PLC of Cambridge, UK, known as "AXI4," although other embodiments could be other types of interfaces. Interface 212 translates memory access requests from a first clock domain known as the FCLK (or MEMCLK) domain to a second clock domain internal to memory controller 200, known as the UCLK domain. Similarly, memory interface queue 214 provides memory access requests from the UCLK domain to the DFICLK domain associated with the DFI interface.

[0024] Address generator 222 decodes addresses of memory access requests received from data fabric 125 via the AXI4 bus. Memory access requests include access addresses within the physical address space expressed in a normalized format. Address generator 222 converts the normalized addresses into a format that can be used to address actual memory devices in memory system 130 and efficiently schedule associated accesses. This format includes a region identifier that associates the memory access request with a particular rank, row address, column address, bank address, and bank group. At startup, the system BIOS interrogates the memory devices in memory system 130 to determine their size and configuration and programs a set of configuration registers associated with address generator 222. Address generator 222 converts the normalized addresses into the appropriate format using the configuration stored in the configuration registers. Command queue 220 is a queue of memory access requests received from memory access agents within APU 100, such as CPU cores 112 and 114 and graphics core 120. Command queue 220 stores address fields decoded by address generator 222 and other address information that allows arbiter 238 to efficiently select memory accesses, including access type and quality of service (QoS) identifiers. CAM 224 contains information for enforcing ordering rules, such as write after write (WAW) and read after write (RAW) ordering rules.

[0025] An error correction code (ECC) generation block 244 determines the ECC for the write data sent to the memory. An ECC check circuit 242 checks the received ECC against the incoming ECC.

[0026] Replay queue 230 is a temporary queue for storing memory accesses selected by arbiter 238 awaiting responses, such as address and command parity responses. Replay control logic 231 accesses ECC check circuitry 242 to determine whether the returned ECC is correct or indicates an error. Replay control logic 231 initiates and controls a replay sequence in which an access is replayed in the event of a parity or ECC error in one of these cycles. Replayed commands are placed in memory interface queue 214.

[0027] The refresh control logic 232 includes state machines for various power-down, refresh, and termination resistor (ZQ) calibration cycles that are generated separately from the normal read and write memory access requests received from the memory access agents. For example, when a memory rank is in precharge power-down, the refresh control logic must be periodically invoked to perform refresh cycles. The refresh control circuit 232 periodically generates refresh commands in response to defined conditions to prevent data errors caused by charge leakage from the storage capacitors of memory cells in the DRAM chip. The refresh control circuit 232 includes an activation counter 248, which in this embodiment has a counter for each memory region that counts the rolling number of activation commands sent to the memory region over the memory channel. The memory region is a memory bank in some embodiments and a memory sub-bank in other embodiments, as described further below. Refresh control circuitry 232 also generates refresh commands, including both refresh (REF) commands and refresh management (RFM) commands, which instruct the memory to perform refresh functions to mitigate row hammering issues, as described further below. Additionally, refresh control circuitry 232 periodically calibrates ZQ to prevent on-die termination resistor mismatches due to thermal changes in the system.

[0028] Arbiter 238 is bidirectionally connected to command queue 220 and is the heart of memory channel controller 210. Arbiter 238 improves efficiency by intelligently scheduling accesses to improve memory bus utilization. Using timing block 234, arbiter 238 enforces the proper timing relationships by determining whether a particular access in command queue 220 is eligible for issue based on DRAM timing parameters. For example, each DRAM has a "t RC A timing block 234 maintains a set of counters that determine eligibility based on this and other timing parameters defined in the JEDEC specification, and is bidirectionally connected to replay queue 230. A page table 236 maintains state information about active pages in each bank and rank of the memory channel for arbiter 238, and is bidirectionally connected to replay queue 230.

[0029] ECC generation block 244 calculates an ECC according to the write data in response to a write memory access request received from interface 212. Data buffer 246 stores the write data and ECC for a received memory access request. The data buffer outputs the combined write data / ECC to memory interface queue 214 when arbiter 238 selects the corresponding write access for dispatch to the memory channel.

[0030] Power controller 250 generally includes an interface 252 to an Advanced Extensible Interface, version 1 (AXI), an advanced peripheral bus (APB) interface 254, and a power engine 260. Interface 252 has a first bidirectional connection to the SMN, including an input for receiving an event signal labeled "EVENT_n," shown separately in FIG. 2, and an output. APB interface 254 has an input connected to the output of interface 252 and an output for connecting to the PHY via the APB. Power engine 260 has an input connected to the output of interface 252 and an output connected to the input of memory interface queue 214. Power engine 260 includes a set of configuration registers 262, a microcontroller (μC) 264, a self refresh controller (SLFREF / PE) 266, and a reliable read / write timing engine (RRW / TE) 268. Configuration registers 262 are programmed via the AXI bus and store configuration information for controlling the operation of various blocks within memory controller 200. Accordingly, configuration registers 262 have outputs connected to these blocks that are not shown in detail in FIG. 2. Self-refresh controller 266 is an engine that allows manual generation of refreshes in addition to the automatic generation of refreshes by refresh control circuitry 232. Reliable read / write timing engine 268 provides a continuous stream of memory accesses to memory or I / O devices for purposes such as DDR interface maximum read latency (MRL) training and loopback testing.

[0031] The memory channel controller 210 includes circuitry that enables it to select memory accesses for dispatch to the associated memory channel. To make the desired arbitration decisions, the address generator 222 decodes address information into pre-decoded information, including rank, row address, column address, bank address, and bank group within the memory system, and the command queue 220 stores the pre-decoded information. The configuration registers 262 store configuration information that determines how the address generator 222 decodes the address information it receives. The arbiter 238 uses the decoded address information, timing eligibility information indicated by the timing block 234, and active page information indicated by the page table 236 to efficiently schedule memory accesses while adhering to other criteria, such as quality of service (QoS) requirements. For example, the arbiter 238 implements prioritization of accesses to open pages to avoid the overhead of precharge and activation commands required to change memory pages, and hides overhead accesses to one bank by interleaving them with read and write accesses to another bank. In particular, during normal operation, the arbiter 238 typically keeps pages open in different banks until they need to be precharged before selecting a different page. In some embodiments, the arbiter 238 determines eligibility for command selection based on at least the respective values ​​of the activation counters 248 for the target memory regions of each command.

[0032] FIG. 3 is a block diagram of a memory 300, according to some embodiments. The memory 300 is configured to communicate with a memory controller, such as the memory controller 200 of FIG. 2. The memory 300 generally includes control logic 310, a DRAM core including multiple DRAM banks 320, and circuitry used to read and write data to and from the DRAM banks 320. A set of row decoders and word line drivers 324 are used to access rows and control the gates of transfer lines. A set of column decoders 326 are used to select locations within the memory array, and a set of sense amplifiers and write drivers 328 perform precharge operations on memory locations and read and write data to memory locations. A data buffer 322 holds incoming and outgoing data for write and read operations.

[0033] Control logic 310 includes refresh control logic 312 and candidate attacker / victim row queue 314, as well as various other control logic not separately shown, such as command decode logic and mode registers. Refresh control logic 312 controls the charge refresh of rows in memory 300, including processing refresh (REF) and refresh management (RFM) commands. Additionally, refresh control logic 312 maintains candidate attacker / victim row queue 314 in response to commands received from the memory controller that identify candidate attacker rows.

[0034] In various embodiments, the commands that cause additions to the candidate attack row / victim row queue 314 are the precharge list (PREL) command, the activate list (ACTL) command, and the refresh management list (RFML) command. Of course, the command names may vary in different embodiments. The PREL and ACTL commands identify candidate attack rows for the memory 300 by tagging an activate (ACT) or precharge (PRE) command as associated with a row that is a candidate attack row. The RFML command identifies a candidate attack against a row of the memory 300 by including the row address of the candidate attack row in the RFML command. For example, as described further below, these commands cause either the candidate attack row or one or more candidate victim rows associated with the candidate attack row to be added to the candidate attack row / victim row queue 314. Then, when a subsequent RFM command is received at memory 300, refresh control logic 312 causes a refresh to occur on one or more rows selected from candidate attack row / victim row queue 314. In some embodiments, a subsequent REF command may cause refresh control logic 312 to select candidate rows for refresh based on the rows listed in candidate attack row / victim row queue 314.

[0035] In some embodiments, the candidate attack row / victim row queue 314 stores one or more victim rows associated with a candidate attack row. An example of such a process is shown in FIG. 4. In other embodiments, the candidate attack row / victim row queue 314 directly stores candidate attack row addresses. An example of such a process is described in FIG. 5. In either case, the refresh control logic 312 includes decoding logic to identify which potential victim rows are adjacent to the candidate attack row. While a "queue" is described here, other embodiments may include a list of candidate attack rows from which the refresh control logic 312 can select, in any order, when performing a refresh operation. In some embodiments, it is appropriate for the memory controller to identify the candidate victim row; however, because the mapping between addresses and physical rows varies in particular DRAM designs, the memory controller typically does not have the information necessary to identify a specific victim row. Therefore, it is typically more useful to identify the candidate attack row. Additionally, although some embodiments record candidate victim rows in the candidate attack row / victim row queue 314, it is typically more efficient to record candidate attack rows because for each candidate attack, memory 300 may have one victim row or more than one victim row in each physical direction, depending on the processing node.

[0036] 4 is a flow diagram of a process 400 for handling refresh management, according to some embodiments. Process 400 includes blocks 402, 404, and 406 that are performed in a memory controller, for example, by refresh control circuitry 232 (FIG. 2). Blocks 408, 410, 412, 414, and 416 are performed in a DRAM memory, for example, by refresh control logic 312 (FIG. 3).

[0037] Process 400 begins at block 402 by monitoring activation commands sent over a memory channel during operation in a memory controller to identify a specified condition. The specified condition is one in which too many ACT commands to an attacking row are likely to result in a row hammer problem, causing bit errors in adjacent victim rows. The specified condition can be identified in several suitable ways. For example, an activation counter for a particular memory region, such as a bank or sub-bank, may exceed a certain threshold. Alternatively, ACT commands can be tracked at a finer granularity than a bank or sub-bank. For example, a monitoring process similar to that used for existing targeted row refresh (TRR) commands may be employed, in which the condition for a potential victim row is determined by counting the number of row activations for each row and comparing it to predetermined chip-specific maximum activate count (MAC) and maximum activate window (tMAW) values. The MAC value is the maximum total number of row activations that can occur in a particular DRAM row within a time interval that is less than or equal to the tMAW time amount. In another example, a specified condition for a potential row hammering problem may be when the sum of the row activations for the two adjacent rows on either side of a particular row reaches the MAC limit within the tMAW time window.

[0038] Once the specified condition is identified in block 402, process 400 proceeds to block 404 to identify a candidate attack row associated with the activation command. While this embodiment involves identifying a particular row as a candidate attack row, other embodiments indirectly identify the attack row by identifying candidate victim rows adjacent to the candidate attack row. While a separate block is shown for identifying the candidate attack row, the actual identification of the candidate attack row may occur simultaneously with recognizing the occurrence of the specified condition in block 402.

[0039] Next, in block 406, a command is sent from the memory controller to the DRAM memory requesting the DRAM to mitigate the row hammer problem for the identified candidate attack row when performing a future refresh or refresh management command. The specific command sent in block 406 will vary in different embodiments, but in each case the row will be indicated to the DRAM in some way to be a candidate attack row. In some embodiments, the memory controller has the capability to send one or more of a precharge list (PREL) command, an activate list (ACTL) command, and / or a refresh management list (RFML) command. Other similar commands may accomplish the same functionality.

[0040] The ACTL command is a modified version of the ACT command that includes a tag on the ACT command for the row address of a candidate attack row, indicating that the row is a candidate attack row. A suitable tagging scheme may be selected one or more bits in the command that are set HIGH or LOW. Such a command is operable to cause the DRAM to activate the row and queue the row as a candidate attack row. The PREL command is a modified version of the PRE command that is operable to cause the DRAM to precharge the row, and includes a tag indicating that the row is a candidate attack row and should therefore be queued. The RFML command is a new command that includes the address of a candidate attack row and indicates to the DRAM that the candidate attack row should be added to the candidate attack row / victim row queue 314.

[0041] In block 408, a transmitted command is received at the DRAM indicating to the DRAM that the identified row is a candidate attack row for mitigation. For commands that also include actions such as precharge or activation, the action is performed by the DRAM control logic. In this embodiment, the candidate victim row is identified and recorded, whereas in the embodiment of FIG. 5, when a REF or RFM command is executed, the candidate attack row address is recorded and the candidate victim row is identified. In block 410, process 400 identifies one or more candidate victim rows associated with the identified candidate attack row. This identification typically involves using decoding logic to identify row addresses adjacent to or near the candidate attack row within the particular row layout employed by the DRAM.

[0042] At block 412, the addresses of the identified candidate victim rows are recorded in DRAM for future mitigation. For example, in the embodiment of FIG. 3, the addresses are recorded in the candidate attacker / victim row queue 314. In contrast to conventional refresh management schemes such as TRR, mitigation of the row hammer problem is not performed immediately at block 412. Instead, process 400 proceeds to block 414 and waits until a REF or RFM command is received. Process 400 continues to receive commands and record victim rows at block 408 until a REF or FRM command is received. Once such a command is received, process 400 proceeds to block 416 and selects one or more of the recorded candidate victim rows and performs some mitigation action, such as a row refresh operation.

[0043] 5-7 illustrate various exemplary refresh management processes for identifying candidate attack rows according to preferred alternative methods. Some embodiments may count row activation commands for all rows.

[0044] 5 is a flow diagram of a process 500 for handling refresh management according to some embodiments. Process 500 includes blocks 502, 504, and 506 that are performed in a memory controller, for example, by refresh control circuitry 232 (FIG. 2). Blocks 508, 510, 512, 514, and 516 are performed in a DRAM memory, for example, by refresh control logic 312 (FIG. 3). Process 500 is similar to process 400 of FIG. 4, except that instead of recording addresses of candidate victim rows, process 500 records addresses of candidate attack rows and identifies candidate victim rows when refresh operations are performed on the candidate victim rows.

[0045] Process 500 begins at block 502 by monitoring activate commands sent on a memory channel during operation in a memory controller to identify specified conditions that are likely to result in a row hammer problem. The specified conditions employed in various embodiments are described with respect to FIG. 4.

[0046] Once the specified condition is identified in block 502, process 500 proceeds to block 504 to identify candidate attack lines associated with the activation command. Although a separate block is shown for identifying candidate attack lines, the actual identification of the candidate attack lines may occur simultaneously with recognizing the occurrence of the specified condition in block 502.

[0047] Next, in block 506, commands are sent from the memory controller to the DRAM memory requesting the DRAM to mitigate the row hammer problem for the identified candidate attack rows when performing future refresh or refresh management commands. Various commands suitable for use in this block are described with respect to block 406.

[0048] At block 508, a transmitted command is received at the DRAM indicating to the DRAM that the identified row is a candidate attack row for mitigation. For commands that also include actions such as precharge or activation, the actions are performed by the DRAM control logic. At block 510, the address of the identified candidate attack row is recorded in the DRAM for future mitigation.

[0049] As shown in block 512, process 500 returns to block 508 and continues receiving commands that may result in further candidate attack rows being identified and their addresses recorded, until a REF or RFM command is received. If a REF or RFM command is received in block 512, process 500 proceeds to block 514, where it selects one or more of the recorded candidate attack rows to be mitigated. Process 500 then identifies one or more candidate victim rows associated with the selected candidate attack row. This identification typically involves using decoding logic to identify row addresses adjacent to or near the candidate attack row within the particular row layout employed in the DRAM. Process 500 then performs mitigation on the identified candidate victim row(s) in block 516.

[0050] 6 is a flow diagram illustrating a process 600 for selecting a candidate attack row, according to some embodiments. Process 600 is performed by a refresh control circuit in a memory controller, such as refresh control circuit 232 of FIG. 2. At block 602, process 600 begins monitoring activation commands to identify specified conditions that may result in the row hammer problem. As shown in block 604, in this embodiment, the specified conditions include activation counters for memory regions that exceed a specified threshold. Once such a condition is identified at block 604, process 600 proceeds to block 606, where a candidate attack row is selected by randomly selecting from among the rows receiving ACT commands.

[0051] 7 is a flow diagram illustrating a process 700 for selecting candidate attack rows, according to some further embodiments. At block 702, the process 700 begins monitoring activate commands to identify specified conditions that may result in a row hammer problem. At block 704, a refresh window begins during which activate commands are tracked. In this embodiment, the activate commands are monitored over a refresh period defined by a row cycle time tREFC, which specifies the maximum period between row refreshes specified for each memory device. Other periods related to refresh timing are also suitable for defining the refresh period. Separate refresh windows may be measured for different memory banks.

[0052] At block 706, an activation count is maintained for one or more most activated rows in the memory bank. Several counters may be used to track frequently activated rows. During the refresh window, one or more of the most activated rows may be selected as candidate attack rows, as shown at block 708. In this embodiment, the selection is based on the activation count exceeding a specified threshold. When the refresh window ends at block 710, a new refresh window begins at block 704. The counters used to track the activation count are reset at the start of the new refresh window.

[0053] While specific embodiments have been described, various modifications to these embodiments will be apparent to those skilled in the art. For example, the internal architecture of memory controller 200 and memory 300 may vary in different embodiments. Memory controller 200 may interface with other types of memory besides DDRx, such as high-bandwidth memory (HBM). While the illustrated embodiment shows each rank of memory corresponding to a separate DIMM or SIMM, in other embodiments, each module may support multiple ranks. Still other embodiments may include other types of DRAM modules or DRAM not contained in a particular module, such as DRAM installed on a host motherboard. Accordingly, the appended claims are intended to cover all modifications of the disclosed embodiments that fall within the scope of the disclosed embodiments.

Claims

1. A memory controller, a command queue having a first input for receiving a memory access request; a memory interface queue having an output for coupling to a memory channel configured to couple to a dynamic random access memory (DRAM); an arbiter coupled to the command queue to select an entry from the command queue and place the entry in the memory interface queue for transmission over the memory channel; a refresh control circuit coupled to the arbiter; The refresh control circuit monitoring activation commands transmitted over the memory channel; identifying a candidate attack line associated with the activation command in response to the activation command satisfying a specified condition; sending a command to the DRAM requesting that the candidate attack row be queued for mitigation in a future refresh or refresh management event, wherein the refresh control circuitry sends the command to the DRAM by tagging an activate command with a row address of the candidate attack row or by tagging a precharge command with the row address of the candidate attack row; and the refresh control circuitry sends an activation command to the DRAM by tagging the command with a row address of the candidate attack row; Memory controller.

2. the activation command is an activation list command operable to cause the DRAM to activate a row and record the row as a candidate attack row. The memory controller of claim 1 .

3. A memory controller, a command queue having a first input for receiving a memory access request; a memory interface queue having an output for coupling to a memory channel configured to couple to a dynamic random access memory (DRAM); an arbiter coupled to the command queue to select an entry from the command queue and place the entry in the memory interface queue for transmission over the memory channel; a refresh control circuit coupled to the arbiter; The refresh control circuit monitoring activation commands transmitted over the memory channel; identifying a candidate attack line associated with the activation command in response to the activation command satisfying a specified condition; sending a command to the DRAM requesting that the candidate attack row be queued for mitigation in a future refresh or refresh management event, wherein the refresh control circuitry sends the command to the DRAM by tagging an activate command with a row address of the candidate attack row or by tagging a precharge command with the row address of the candidate attack row; and the refresh control circuit sends a precharge command to the DRAM by tagging the command with the row address of the candidate attack row; Memory controller.

4. the precharge command is a precharge list command operable to cause the DRAM to precharge a row and record the row as a candidate attack row. The memory controller of claim 3.

5. the refresh control circuitry is further operable, in response to identifying the candidate attack row, to store a record of the candidate attack row in a list of candidate attack rows. The memory controller of claim 1 .

6. 1. A data processing system comprising: A data processor; a data fabric coupled to the data processor; and a memory controller according to any one of claims 1 to 5. Data processing system.

7. 1. A method comprising: receiving a plurality of memory access requests including memory reads and memory writes; selectively placing memory access commands in a memory interface queue to satisfy the memory access requests, and transmitting the memory access commands from the memory interface queue to a memory channel coupled to at least one dynamic random access memory (DRAM); monitoring activation commands transmitted over the memory channel; identifying a candidate attack line associated with the activation command in response to the activation command satisfying a specified condition; sending a command to the DRAM requesting that the candidate attack row be queued for mitigation in a future refresh or refresh management event, wherein sending the command to the DRAM is performed by tagging an activate command with a row address of the candidate attack row or tagging a precharge command with the row address of the candidate attack row; sending the command to the DRAM includes tagging an activation command with a row address of the candidate attack row. method.

8. the activation command is an activation list command operable to cause the DRAM to activate a row and record the row as a candidate attack row. The method of claim 7.

9. A method comprising: receiving a plurality of memory access requests including memory reads and memory writes; selectively placing memory access commands in a memory interface queue to satisfy the memory access requests, and transmitting the memory access commands from the memory interface queue to a memory channel coupled to at least one dynamic random access memory (DRAM); monitoring activation commands transmitted over the memory channel; identifying a candidate attack line associated with the activation command in response to the activation command satisfying a specified condition; sending a command to the DRAM requesting that the candidate attack row be queued for mitigation in a future refresh or refresh management event, wherein sending the command to the DRAM is performed by tagging an activate command with a row address of the candidate attack row or tagging a precharge command with the row address of the candidate attack row; sending the command to the DRAM includes tagging a precharge command with a row address of the candidate attack row. method.

10. the precharge command is a precharge list command operable to cause the DRAM to precharge a row and record the row as a candidate attack row.

10. The method of claim 9.

11. and storing, in the DRAM, a record of the candidate attack line in a list of candidate attack lines in response to the candidate attack line being indicated in the DRAM. The method of claim 7.

12. responsive to the candidate attack row being identified in the DRAM, storing in the DRAM, for refresh management purposes during one of a subsequent refresh management command and a subsequent refresh command, a record of one or more victim rows associated with the candidate attack row. The method of claim 7.

13. the DRAM responds to the refresh management command by refreshing a plurality of victim rows associated with each of one or more corresponding candidate attack rows; The method of claim 7.

Images