Host-assisted refresh command control for row hammer mitigation

Abstract

A memory device with internal row hammer mitigation is coupled to a memory controller. A memory controller or host may assist row hammer mitigation by sending additional refresh cycles or refresh commands. In response to an additional refresh command, the memory device may perform a refresh for row hammer mitigation, rather than a refresh for standard data integrity. The memory controller may maintain a tracking of the number of activation commands sent to the memory device, and in response to a threshold number of activation commands, the memory controller sends additional refresh commands. With additional refresh commands, the memory device may refresh a potential victim row of the potential aggressor row rather than only rows that have not been accessed for a period of time.

Description

This case is a divisional application. The invention name of the parent case is “Host-assisted refresh command control for row hammer mitigation”, the application date is February 28, 2020, and the application number is 202010127858.X. Technical Field

[0001] The present description relates generally to computer memory systems, and more particularly, the present description relates to mitigation of rowhammer events. Background Art

[0002] As computer devices continue to decrease in size and increase in capacity and capability, the minimum device geometry used to manufacture components also continues to decrease. The reduction in memory device geometry enables continued system expansion, but this leads to the possibility of data loss due to row hammering or row disturb events. "Row hammering" refers to failures caused by repeated accesses to a target or aggressor row over a period of time. Repeated activation of accesses to an aggressor row may cause failures in a victim row adjacent or neighboring the target / aggressor row, where repeated activation of the target row causes migration of charge across the passgate of the victim row, resulting in an indeterminate state of the victim row. Row hammering is a known problem in DRAM (dynamic random access memory) devices.

[0003] With reduced device geometries, the number of activations to a particular row that could cause a row hammer event has gone from 500K to 300K, and is now expected to be 100K, and even reduced to a range of about 30K-50K activations. With fewer activations causing row hammer events, more rows are likely to be aggressors within the refresh window, and more row hammer mitigation is required to reduce the risk of data loss.

[0004] Traditional row hammer mitigation managed by the memory controller places a significant burden on the memory controller, and the coordination of management between the memory controller and the DRAM places a burden on the memory bus bandwidth. Today, most DRAM devices handle row hammer mitigation internally, typically by "stealing" refresh cycles used to perform row hammer refreshes. Thus, the DRAM device itself determines how many refresh cycles issued by the memory controller will be used for row hammer mitigation.

[0005] However, as the row hammer threshold is lowered, the memory device will need to steal more refreshes than is reasonably possible without compromising the integrity of the data in the device. One option is to increase the refresh rate. However, increasing the refresh rate will place constant demands on the memory subsystem in terms of power and bandwidth even when row hammer refresh is not needed. Therefore, changing the refresh rate will be ineffective due to the risk of over-refreshing when there is no row hammer condition. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The following description includes a discussion of the accompanying drawings, which have diagrams given by examples of implementations. The accompanying drawings should be understood as examples rather than as limitations. As used herein, reference to one or more examples is to be understood as describing a specific feature, structure or characteristic included in at least one implementation of the present invention. Phrases such as "in one example" or "in an alternative example" that appear herein provide examples of implementations of the present invention, and do not necessarily all refer to the same implementation. However, they are not necessarily mutually exclusive.

[0007] Figure 1 is a block diagram of an embodiment of a system for performing row hammer mitigation with host assistance.

[0008] Figure 2 is a timing diagram of an example of command sequencing for excess external refresh for row hammer mitigation refresh.

[0009] Figure 3 is a block diagram of an example of a memory subsystem in which additional external refresh from the host may be implemented to assist in row hammer mitigation.

[0010] Figure 4 is a block diagram of an example of multiple counters for tracking row hammer mitigation information for different memory sections.

[0011] Figure 5 is a representation of examples of selected commands in a command truth table for a system supporting host-assisted row hammer mitigation.

[0012] Figure 6 is a flow chart of an example of a process for host-assisted row hammer mitigation.

[0013] Figure 7 is a block diagram of an example of a memory subsystem in which host-assisted row hammer mitigation may be implemented.

[0014] Figure 8 is a block diagram of an example of a computing system in which host-assisted row hammer mitigation may be implemented.

[0015] Fig. 9is a block diagram of an example of a mobile device in which host-assisted row hammer mitigation may be implemented.

[0016] What follows is a description of certain details and implementations, including a non-limiting description of the accompanying drawings, which may depict some or all of the examples, as well as other possible implementations. DETAILED DESCRIPTION

[0017] As described herein, row hammer mitigation is host-assisted and memory device-managed. The memory device performs internal row hammer mitigation, and a memory controller or host can assist in row hammer mitigation by sending additional refresh cycles or refresh commands. The system can track the need to send additional refresh cycles to prevent the use of power and bandwidth for unnecessary refreshes.

[0018] For example, a memory controller may keep track of the number of activation commands sent to a memory device, and in response to a threshold number of activation commands, the memory controller sends additional refresh commands. In response to the additional refresh commands, the memory device may perform a refresh for row hammer mitigation rather than a refresh for standard data integrity. Using the additional refresh commands, the memory device may refresh potential victim rows of potential aggressor rows rather than simply refreshing rows that have not been accessed within a period of time. In this implementation, the memory device will have sufficient refresh cycles available to perform row hammer mitigation, but excess cycles may still be effective as needed rather than simply increasing the refresh rate. The additional refresh commands may be referred to as excess refresh commands. In one example, the additional refresh commands may be issued as refresh management (RFM) commands from a host designed to address row hammer issues.

[0019] A host controller or memory controller sends additional refresh commands to a memory device (e.g., a dynamic random access memory (DRAM) device) to compensate for the additional refreshes required for row hammer mitigation. Providing additional refresh cycles can enable the memory device to steal cycles without compromising data integrity by still providing enough refresh cycles for standard refresh operations. In one example, the memory controller determines the number of additional refresh commands to send by how many activate commands have been sent to the memory device. There is a high correlation between the number of activates sent to the memory device and the number of refreshes that the memory device needs to steal to perform row hammer mitigation.

[0020] Host-assisted row hammer mitigation as provided can eliminate the need for a targeted row refresh (TRR) protocol in a host controller. A TRR occurs when the controller becomes aware of a potential row hammer event, either through its own monitoring or through signaling from a memory device. In the case of a TRR, the controller can send a specific refresh command indicating a target row, and the memory device will refresh one or more victim rows. Host-assisted row hammer mitigation does not require the controller to know the target row for a TRR command. Additionally, host-assisted row hammer mitigation can simply estimate the need for row hammer mitigation by generally observing the number of activations, without having to worry about whether a particular target row is the subject of a threshold number of activations.

[0021] Host-assisted row hammer mitigation puts the decision of what rows to refresh under the control of the memory device. There tends to be a lot of leeway in the internal operation of refresh, and memory device manufacturers know the specific capabilities and needs for their own devices, rather than just operating under the worst-case scenario. This capability allows memory devices to perform row hammer mitigation and refresh control in a device-specific or manufacturer-specific manner. So, for example, DRAM manufacturers know how much refresh they can safely steal without affecting data integrity, and can perform whatever mitigation makes sense for their specific device.

[0022] Figure 1 (WAS1) is a block diagram of an embodiment of a system for performing row hammer mitigation with host assistance. System 100 includes a memory device 120 coupled to a memory controller 110, which may also be referred to as a host controller, or just a controller. Memory device 120 may include any type of memory technology having adjacent rows of memory cells, where data may be accessed via word lines or equivalent. In one example, memory device 120 includes DRAM technology. Rows of memory device 120 need to be refreshed to maintain a deterministic state.

[0023] Memory device 120 includes memory array 130, which represents an array of memory cells or storage cells. A memory cell stores a data bit, or multiple bits of a multi-level cell. Memory array 130 includes a representation of a potential row hammering condition. For purposes of example, memory array 130 shows a bank 140 and a bank 150. It should be understood that memory array 130 may include multiple banks. Typically, a bank or sub-bank of memory includes memory cells that are separately addressable from memory cells of another bank or sub-bank and are therefore accessible in parallel to another portion of memory array 130. Memory array 130 may include portions of system 100 that are not shown.

[0024] The memory device 120 includes a column decoder (dec) 132, which represents a circuit that applies a charge to a column based on an access command. In one example, the circuit selects a column in response to a column address strobe (CAS) command. The memory device 120 includes a row decoder (dec) 134, which represents a circuit that applies a select voltage to a row based on a memory access command. In one example, the circuit selects a column in response to a row address strobe (RAS) command.

[0025] The memory controller 110 includes command logic 112 to generate commands for the memory device 120. The command may include a command such as a write command or a read command. The command may also include an activate command, a precharge command, a refresh command, or other commands. In one example, the memory controller 110 includes refresh logic 172, which represents logic for controlling the refresh of the memory device 120. The refresh logic 172 may include one or more counters to determine the refresh for the memory device 120 and the need for register space for tracking the transmission of the refresh command. The refresh command may include an external refresh command (e.g., REF, REFpb), in which the memory device continues to operate according to a clock signal from the memory controller 110. The refresh command may include a self-refresh command (e.g., SRE), in which the memory device operates on an internal clock rather than based on a clock signal from the memory controller. The external refresh has a specific window for completing the command, and the self-refresh is a state that the memory device may be in for a non-specific amount of time.

[0026] The memory controller 110 includes a scheduler 116 for managing the scheduling and sending of command sequences to the memory devices 120. The scheduler 116 includes logic for determining the order of commands, as well as the timing requirements of the commands. The memory controller 110 must determine what commands to send. It will also determine the order of the commands to ensure that the timing requirements are met. The scheduler 116 can enable the memory controller 110 to make certain determinations about commands and timing. In one example, the scheduler 116 determines how many external refresh commands to send during the refresh window. The scheduler 116 can generate additional refresh commands to enable row hammer mitigation.

[0027] In one example, the memory controller 110 includes row hammer (RH) logic 174 to enable the controller to determine when a threshold number of activation commands or activations have been sent to the memory device 120. For example, the row hammer logic 174 may include one or more counters or other logic to monitor potential row hammer conditions. In one example, the row hammer logic 174 includes a comparator that is used to determine when the activation counter has reached a threshold number. In one example, the threshold number is programmable, such as through a mode register or other register or configuration, such as programmable in register 122. The memory controller 110 can read the configuration and store it in a register or other device (not specifically shown) internal to the memory controller 110.

[0028] The memory controller 110 includes I / O (input / output) hardware 114. The I / O 114 represents transceiver and signal line interface hardware to enable the memory controller 110 to connect to the memory devices 120 through one or more buses. The I / O 114 enables the memory controller 110 to send commands to the memory devices 120. The memory controller 110 includes a buffer 176 that buffers a sequence of commands to be sent to the memory devices 120. In one example, the buffer 176 is part of the scheduler 116. The scheduler 116 determines the commands to be sent and the order of the commands, which can then be queued in the buffer 176 for transmission via the I / O 114.

[0029] To illustrate a row hammer condition, the memory array 130 includes a target row 142 in a memory bank 140. A physically adjacent row or physically neighboring row may suffer from unintentional programming or disturbance of one or more values ​​stored in the target row 142 based on repeated accesses to the target row 142 during a period of time prior to a refresh operation on the row. A victim row 144 represents a row that is subject to row hammering when the target row 142 is repeatedly accessed. When the victim row 144 is at risk of a row hammering event, the target row 142 may be referred to as an aggressor row. There may be another row in the memory bank 140 that is a victim row for the target row 142.

[0030] In one example, the memory bank 140 also includes a target row 146. Consider that the target row 146 is at or near a memory bank boundary. It should be understood that the rows in the memory array 130 can have the same spacing even if the rows are in different memory banks. Instead, the separation of one memory bank from another can be defined by selecting or decoding hardware elements. Therefore, depending on the architecture of the physical layout of the rows, the rows on the boundary of the memory bank 150 may also be at risk of a row hammering event based on access to the target row 146. In one example, repeated access to the target row may cause interference to multiple adjacent rows. As illustrated, the target row 146 may cause a row hammering event to both the victim row 148 of the memory bank 140 and the victim row 152 of the memory bank 150.

[0031] The memory device 120 includes an I / O 126 that interfaces with the I / O 114 of the memory controller 110. The I / O 126 has corresponding signal lines to the I / O 114 to receive command and address information, so as to receive activate and refresh commands in addition to other commands. In one example, the I / O 126 includes an interface to a data bus to exchange data with the memory controller 110.

[0032] The memory device 120 includes registers 122, which represent one or more registers or storage locations to store configuration information or values ​​related to the operation of the memory device 120. In one example, the registers 122 include one or more mode registers. In one example, the registers 122 include configuration information to control the application of refreshes within the memory device 120. In one example, the registers 122 include information related to row hammering operations, such as a threshold number of activations prior to a row hammering condition.

[0033] The memory device 120 includes a controller 180, which represents a controller local to the memory device. The controller 180 includes hardware logic that performs operations in response to commands. The controller 180 includes software or firmware logic for controlling the hardware logic and controlling operations and sequences of operations in the memory device. In one example, the controller 180 includes refresh logic 160. In one example, the controller 180 includes a RH counter 124. The controller 180 manages I / O 126.

[0034] In one example, the memory device 120 includes refresh logic 160, which represents logic within the memory device 120 for managing refresh of the memory array 130. In one example, the refresh logic 160 includes a refresh (ref) counter 162 and a row hammer (RH) logic 164. The refresh counter 162 can indicate the address of the row to be refreshed. The refresh counter 162 can represent multiple counters because different memory banks or sub-memory banks may have different addresses identified for refresh. The row hammer logic 164 enables the memory device 120 to manage row hammer mitigation. The row hammer logic 164 can include one or more counters, lists or potential aggressor rows, or other logic for performing row hammer mitigation. In one example, row hammer mitigation occurs by performing a refresh of the potential victim row of the last row address to receive an activate command. The heuristic involved in this method recognizes that when a row is being hammered, it is most likely a row whose address just received an activate command before receiving a refresh command for row hammer mitigation. On average, if enough row hammer mitigation actions are performed, this approach should refresh potential victim rows.

[0035] In one example, the memory device 120 includes one or more row hammer (RH) counters 124. The counter 124 may be or include row hammer detection logic. In one example, the memory device 120 detects a potential row hammer condition and performs operations to mitigate the risk associated with a row hammer event. In one example, the counter 124 maintains a count associated with one or more rows that are repeatedly accessed. For example, the counter 124 may maintain an optional address (addr) list of rows with the highest activation count within a refresh window. The count may be reset after a refresh.

[0036] It should be understood that keeping track of the number of activations for each row would be impractical because, in some memory devices, one million counters or more would be required per bank. Memory devices typically employ heuristics or probabilistic execution to apply row hammer mitigation. Instead of tracking activations for all rows, only selected rows are tracked. When the counters reach a threshold number, the refresh logic 160 can perform a row hammer refresh. In this implementation, each time a new row is activated, the lowest count can be replaced. In one example, the counter 124 maintains a list of rows with the highest number of activations, and when an external refresh command is received, row hammer mitigation is performed for the row or rows with the highest number of activations. Thus, the refresh logic 160 does not have to wait until the threshold number is reached before performing row hammer refresh mitigation.

[0037] Another heuristic technique is to randomly assign row hammer refreshes to randomly selected rows that have received activations. This implementation may only require counter 124 to optionally store the address of the most recently activated row. In theory, rows that are repeatedly activated will have a higher probability of being randomly selected for row hammer mitigation refreshes. Therefore, in probability, rows that are repeatedly accessed or hammered are also rows that are more likely to be selected for row hammer mitigation. The logic and circuit requirements of this approach are simpler than those required to maintain a list of rows, but are less precise in terms of row hammer mitigation.

[0038] The refresh logic 160 represents logic within the memory device 120 for controlling the refresh of rows within the memory array 130. The refresh logic 160 responds to external refresh commands sent by the refresh logic 172 of the memory controller 110. The refresh logic 160 controls the operation of the refresh during the self-refresh operation of the memory device 120. The refresh logic 160 includes a refresh (ref) counter 162 to track the row address for the scheduled refresh operation. The scheduled refresh operation includes refreshing of consecutive rows to ensure that all rows are refreshed within the refresh period. The refresh logic 160 of the memory controller 110 is responsible for ensuring that enough refresh operations are scheduled for the memory device 120 to meet the refresh requirements.

[0039] In one example, the refresh logic 172 will schedule more refresh operations than are necessary within the refresh period. As described, based on the number of activations sent to the memory devices 120, the row hammer logic 174 can provide additional or excess refreshes to the refresh logic 160 for row hammer mitigation. It should be appreciated that with the additional row hammer mitigation refreshes provided by the memory controller 110, even the heuristic approach will significantly reduce the likelihood of data loss due to row hammering.

[0040] In one example, the refresh logic 160 includes row hammer logic 164 to provide refresh operations for row hammer mitigation. Row hammer mitigation refers to the refresh of potential victim rows to avoid row disturbances. In operation, the counter 124 may indicate a target row to the row hammer logic 164, which may trigger a "refresh steal" by the refresh logic 160. Refresh steal refers to the refresh logic 160 performing a refresh of the victim row associated with the indicated target row, rather than performing a refresh of the row indicated in the refresh counter 162. Thus, the row hammer mitigation refresh operations are out of order with respect to the refresh row pointer or counter. Row hammer mitigation may include stealing all refreshes of an entire refresh operation or refresh cycle, or just stealing one or more refreshes of a refresh operation. For commands that are tagged or indicated as row hammer refreshes (described in more detail below), or when the refresh logic 160 determines that the refresh command corresponds in time to reaching the activation threshold, the logic may determine that it is safe to use all cycles for row hammer mitigation.

[0041] In response to an external refresh command, the memory device 120 typically performs a refresh of multiple rows. A refresh operation refers to a refresh of all rows that are to be refreshed in response to a single refresh command. A refresh operation has a time tRFC (row refresh cycle time), and there will be an average refresh interval of tREFI (refresh interval time) between refresh operations in a refresh period or refresh window. A refresh period refers to the time between refreshes of any given row to avoid data loss in the row. A refresh may refer to the refresh of a single row of all rows that are to be refreshed in response to a refresh command, and since a single refresh operation includes multiple refreshes, the refresh has a time less than tRFC.

[0042] It should be understood that there may be multiple target rows in the same bank, such as those illustrated in bank 140. As the critical number of row hammers decreases due to the number of activations required to cause a row disturb continues to decrease, the number of potential aggressor rows will increase. Therefore, the number of row hammer mitigation operations required per refresh period continues to increase. In order to allow for more row hammer mitigation operations, the memory controller 110 sends more external refresh commands, specifically based on determining how many activation commands have been sent. A refresh (whether external or internal) is the only time that the memory controller and memory device can ensure that there will be no access to a row. It should be understood that different banks may be refreshed at different times, and therefore unavailable for access at different times. Banks that are not being refreshed may be accessed, and therefore the scheduler 116 will manage the scheduling of refreshes for the different banks.

[0043] The row hammer logic 174 of the memory controller 110 may keep track of the number of activate commands sent to the memory device 120 to trigger the sending of additional refresh commands. This mechanism is much simpler than having the memory device 120 keep track of the need for additional refreshes and attempt to signal the memory controller. When the row hammer logic 174 keeps track of the threshold for sending excessive refreshes, the operation may be performed based on a configurable parameter, such as an activate threshold. This approach enables configurability for different operating conditions, for different devices or manufacturers, or other variables that may affect the need for additional row hammer mitigation.

[0044] The operation of the row hammer logic 174 may vary for different implementations. In one example, the row hammer logic 174 sends additional refresh commands whenever a programmable threshold has been reached, regardless of the time window. In one example, the row hammer logic 174 sends additional refreshes only if the count has been reached within a certain time period. For example, the count may be reset for each normal refresh period, and the count will only trigger an additional external refresh if the threshold is reached within the refresh window.

[0045] In one example, the period of interest for sending additional refresh commands is a sliding window. The sliding window can be set, for example, by using a leaky bucket approach. In the leaky bucket approach, the row hammer logic 174 can decrement (or increment, depending on the approach) a count in response to each activation command. In the decrement approach, reaching zero on the count can trigger the sending of additional refreshes. In one example, the row hammer logic 174 will decrement on a time basis to produce a nominal rate of activations per μs (microseconds), which will not cause any additional refresh cycles. In this approach, only cycles detected above this nominal rate will cause the row hammer logic 174 to send additional refreshes. This approach can be based on the assumption that only the rate of activations within a certain time will trigger a row hammer event, not just the total activations.

[0046] In a counter up approach, refresh can occur over a sub-refresh period, which can be, for example, 1 / 4 or 1 / 2 of the normal refresh time. Thus, every fixed period, row hammering logic 174 can trigger the sending of additional refresh commands. Considering the example of 100,000 causing row disturbances, row hammering logic 174 can trigger the sending of additional refresh commands after 80k activations or 60k activations or some other programmable count below the row disturbance value.

[0047] The timing of sending additional refreshes can be adjusted in any of a number of different ways. In one example, the frequency of the additional refreshes is adjusted by programmability or configuration. In one example, the frequency of the additional refreshes depends on the manner in which the additional refresh monitoring is performed. The frequency can be adjusted by a combination of the monitoring method and programmability. As described above, the monitoring method depends on whether the additional refreshes are sent in response to detecting a threshold number of activations regardless of the time window, in response to detecting multiple activations within a fixed time window, or in response to detecting multiple activations within a sliding window. In one example, the time period is programmable rather than fixed at the refresh period. In one example, the sliding window is programmable. In one example of the leaky bucket method, the rate at which the leaky bucket fills is programmable.

[0048] The granularity of row hammer mitigation tracking can depend on the implementation. The granularity of tracking will be described in more detail below. Generally, the granularity depends on the level at which monitoring is performed. In one example, monitoring is performed at the device level. In one example, monitoring is performed at the channel level. In one example, monitoring is performed at the rank. In one example, monitoring is performed at the memory bank group. In one example, monitoring is performed at the memory bank.

[0049] Figure 2 2 is a timing diagram of an example of command sequencing for an excessive external refresh for a row hammer mitigation refresh. Diagram 200 represents a timing diagram for a refresh in the case of row hammer mitigation. Diagram 200 represents a number of interconnections between a host or memory controller and an associated memory device, as well as certain internal functions within the memory device. The interconnections are provided via one or more signal lines.

[0050] CLK 210 represents the clock of the system, and illustrates both the clock (CK_t) and the complement (CK_c). For the example of diagram 200, the clock is a solid line signal with an arrow to indicate a rising edge. The complement is illustrated as a dashed line. CA 212 represents the command / address (C / A) signal sent on the C / A signal line, and indicates the command encoding provided by the host. CMD 216 represents the decoding of the command encoding, and therefore can represent the signal internal to the memory device for the operation generated to perform the command. RH CTR 214 represents the row hammer counter of the memory controller. Refresh 218 represents the operation of refreshing within the memory device.

[0051] CA 212 illustrates a REF command at 220. The refresh command represents a standard external refresh command from the memory controller. At 222, the memory device interprets the command as an external (EXT) refresh command on CMD 216 and generates internal operations at 224 to implement the refresh. Refresh 218 illustrates a sequence of refresh commands, which may include CTR0, followed by REF at CTR1, and so on until the row corresponding to the external refresh command is refreshed. CTR0 and CTR1 represent values ​​used to indicate which row to refresh, which may be counters or pointers used to track internal refresh operations. In one example not specifically illustrated, the memory device will steal one or more refresh cycles to perform a row hammer mitigation refresh.

[0052] Dashed line 226 represents a time break. CA 212 illustrates an ACT command at 228. In one example, the ACT command is followed by a row hammer counter 214 performing a row hammer increment (RH INCR) at 230. The increment represents tracking of the activate command by the memory controller, although it should be understood that the increment may alternatively be a decrement depending on how row hammer mitigation tracking is implemented. Following the activate command, one or more internal operations are also performed on CMD 216 to execute the activate command at 232. In one example, at 234, the memory device also tracks the row hammer effect of the activate command on refresh 218. It should be understood that row hammer tracking is performed in addition to executing the activate command on the row indicated by the address accompanying the activate command. In a system that keeps track of multiple counters for row hammer mitigation, row hammer tracking may include updating counter information.

[0053] Dashed line 236 represents a time interrupt. CA 212 illustrates a subsequent ACT command at 238. It will be observed that this subsequent activate command may trigger the same operations as illustrated by RH INCR on row hammer counter 214 at 240, ACT on CMD 216 at 242, and RH tracking on refresh 218 at 244. It should be understood from this section that when activate commands are received, the memory controller may track them, but the memory controller may not trigger row hammer mitigation unless the threshold has been reached.

[0054] Dashed line 246 represents a time interrupt. After the time interrupt, regardless of what may have occurred on CA 212, in one example, a time threshold is reached in a system that implements a leaky bucket approach for row hammer detection. In response to reaching the time, in one example, at 248, the memory controller performs a row hammer decrement (RHDECR) on the row hammer counter 214.

[0055] Dashed line 250 represents a time interrupt. CA 212 illustrates a subsequent ACT command at 252. It will be observed that this subsequent ACT command triggers a threshold for row hammer mitigation. Therefore, when RH INCR occurs on row hammer counter 254 at 254, the memory controller determines to trigger an additional refresh command. In response to the ACT on CA 212, the memory device decodes the ACT operation, as illustrated on CMD 216 at 256, and performs internal row hammer tracking on RH tracking on refresh 218 at 258. In response to the threshold ACT command, at some point after the ACT command, on CA 212, the memory controller sends a row hammer refresh command (RH REF) at 260. Although illustrated as being adjacent to the ACT command that triggered the row hammer condition, the refresh command may or may not be sent directly adjacent to the ACT command. In one example, the REF command is sent adjacent to the ACT command, such as by logic in the memory controller that detects the condition, schedules the REF command, and buffers it for sending to the memory device.

[0056] In the case where the activation command triggers row hammer mitigation, CMD 216 illustrates a row hammer mitigation (RH MIT) selection by the memory device at 262. The row hammer mitigation selection may include the memory device selecting a victim row for refresh. In response to the selection of one or more victim rows, at 264, the memory device may perform a row hammer mitigation refresh represented by RH REF on refresh 218. A refresh is the only time the memory device will be assured that the host will not attempt to access the memory device, which allows the memory device to perform a refresh on a row hammer victim rather than performing a refresh based on a refresh counter. Thus, a row hammer mitigation refresh performed during a refresh cycle provides an operation that is guaranteed to be immune to other operations performed by the memory device or attempted access by the memory controller.

[0057] Figure 3 3 is a block diagram of an example of a memory subsystem in which additional external refresh from a host may be implemented to assist in row hammer mitigation. System 300 represents an element of a computing system. System 300 provides an example of a system that may include system 100. System 300 may be considered to have a memory subsystem with a memory controller 320 and a memory 330. Host 310 represents a hardware platform that controls the memory subsystem. Host 310 includes one or more processors 312 (e.g., a central processing unit (CPU) or a graphics processing unit (GPU)) that generates requests for data stored in memory 330.

[0058] The host 310 includes a memory controller 320, which can be integrated into a processor device. The memory controller 320 includes an I / O (input / output) 326 to connect to the memory 330. The I / O includes connectors, signal lines, drivers and other hardware to interconnect the memory device with the host 310. The I / O 326 may include a command I / O represented by a command (CMD) bus 314, and a data I / O represented by a DQ (data) bus (not specifically shown). The CMD bus 314 includes a command signal line that enables the memory controller 320 to send a command to the memory 330, the command including an activation command (ACT) and a refresh command (REF).

[0059] The memory controller 320 includes command (CMD) logic 322 for generating commands for the memory in response to the operation of the processor 312. The command can be a command for data access (such as a read, write, refresh or other command), or a command for configuration (such as a mode register command). The memory controller 320 includes a scheduler 324 for scheduling when to send commands in an operation sequence. The scheduler 324 can control the timing of the I / O according to a known timing to improve the probability that the I / O will be error-free. The timing is set by training.

[0060] Memory 330 may include individual memory devices, or may represent memory modules. System 300 illustrates two banks of memory devices in memory 330, bank [0] and bank [1]. A bank refers to a collection or group of memory devices that share a select line (e.g., a CS signal line). Thus, memory devices in a bank will perform operations in parallel. Bank [0] and bank [1] are illustrated as including N DRAM devices or DRAMs. Typically, a system with multiple banks will have the same number of DRAMs in each bank.

[0061] DRAM[0] of bank[0] and DRAM[0] of bank[1] are shown to include I / O 332, control (CTRL) 336, and register (REG) 334. Such components will be understood to be included in other DRAMs as well. I / O 332 represents connection hardware equivalent to I / O 326 of memory controller 320. I / O 332 implements the connection of the DRAM to memory controller 320. Register 334 represents one or more registers within the DRAM, which include one or more configuration registers, such as a mode register. Register 334 can store configuration information, as well as information that determines the mode of operation performed by the DRAM in response to signals on command and data signal lines. In one example, the DRAM includes register 334 for storing a programmable value to indicate a row hammer mitigation threshold.

[0062] The control logic 336 represents control components within the DRAM for decoding and executing commands and access operations. The control 336 causes the DRAM to perform internal operations required to perform accesses initiated by the memory controller 320. In one example, the DRAM includes row hammer (RH) logic 338, which represents row hammer logic consistent with those described herein. In one example, the row hammer logic 338 is part of the control logic 336. The row hammer logic 338 enables the DRAM to determine how to perform refresh to manage row hammer mitigation. For example, the row hammer logic 338 can control refresh cycle stealing to perform row hammer mitigation.

[0063] In one example, the memory controller 320 includes one or more row hammer counters (RH CTR) 328 to monitor the status of row hammer mitigation. In one example, the counter 328 detects the number of activate commands sent to the memory 330. Tracking the commands scheduled to be sent to the memory 330 can be a good indicator of when additional refreshes may be needed for row hammer mitigation.

[0064] In one example, memory controller 320 includes a plurality of counters 328 sufficient to provide the desired level of tracking granularity in system 300. The highest granularity is channel. System 300 does not specifically illustrate a second channel. A channel refers to all memory devices connected to the same command bus. Command bus 314 is connected to all illustrated DRAM devices and is therefore assumed to be a single channel.

[0065] The DRAM device is illustrated as having multiple banks (banks [0:7]). It should be understood that eight banks are an example and not limiting. Other systems may include 4 banks, 16 banks, 32 banks, or some other number of banks. From an addressing perspective, binary banks are simple, but are not necessary for operational purposes, and any number of banks may be used. Banks 340 may be used as separate banks that may be separately addressed by bank numbers. In one example, banks 340 are organized in bank groups, such as banks [0:3] as BG0 (bank group 0) and banks [4:7] as BG1. Bank groups may alternatively be, for example, BG0 with banks [0, 2, 4, 6], or some other grouping. For example, bank groups may typically be accessed separately, and shorter access times may be achieved than back-to-back accesses to banks in the same bank group.

[0066] A lower level of granularity may be at the rank level, where each rank may be tracked separately. Additional refresh commands will only be sent to the rank that is detected to have a threshold number of activation commands. Another level of granularity may be on a die basis or package basis for memory device dies or packages. Such a level may provide balance for the system 300, since the tracking performed by the memory controller 320 will match the tracking performed by the DRAM devices. As previously described, additional refreshes may be limited to be sent when needed, and only to the device(s) that are detected to need additional refreshes.

[0067] A lower level of granularity (finer granularity) can be based on the granularity of refresh commands for a particular DRAM technology of memory 330. For example, different DRAM technologies can perform refresh based on bank groups, bank groups, or on a per-bank basis. A bank refers to a group of rows that are addressed together in the case of row and column decoders. A bank group refers to a group of banks that can be accessed together based on a bank group address, based on a bank group decoder. A bank group can refer to the identification of banks within a bank group that have a common bank address in a bank group.

[0068] The advantage of finer granularity is that additional refresh commands will only be sent to the affected regions, rather than the entire chip or channel. The disadvantage of finer granularity is additional tracking logic in the memory controller 320, such as counter 328. Regardless of the granularity level used, additional refresh commands are only sent to the specific segment for which an activation threshold was detected.

[0069] In current implementations of DRAM devices that allow per-bank or per-bank refreshes, additional refreshes to a particular bank or bank group are typically not allowed due to the presence of a common row counter. The described implementation of row hammer mitigation may require an exception to the typical rule, where the DRAM may detect additional refreshes to a particular bank group or bank and use them for row hammer mitigation.

[0070] Figure 4 is a block diagram of an example of multiple counters for tracking row hammer mitigation information for different memory portions. System 400 represents elements of a memory controller according to any example herein. System 400 includes a scheduler 430 to schedule and send commands to memory devices.

[0071] In one example, the system 400 includes a plurality of row hammer counters 410. The system 400 illustrates N counters, where N is a value representing the number of elements to be tracked for row hammer conditions. For example, if the level of monitoring for row hammer mitigation occurs at the level of memory device dies, then N may be equal to the number of device dies connected to the memory controller.

[0072] In one example, the system 400 includes a row hammer decoder 420 that can determine which portion of the memory to send additional refresh commands from the counters 410. The row hammer decoder 420 can ensure that the scheduler 430 schedules additional refreshes for counters that indicate potential row hammer conditions. It should be understood that the finer the granularity of the tracking, the more counters 410 the memory controller will need to identify a row hammer mitigation condition.

[0073] Figure 5 is a representation of examples of selected commands in a command truth table for a system supporting host-assisted row hammer mitigation. Command table 700 illustrates an example of command encoding for a memory device performing a row hammer mitigation refresh according to any description herein.

[0074] For command table 500, the command bus signals may include CS for chip select, and multiple CA (command / address) signals identified as CA[0:13]. The number of CA signal lines may be more or less than the number depicted. The interpretation of the signal line values ​​may be as follows: BG = memory group address; BA = memory address; R = row address; C = column address; BC8 = burst chop 8; MRA = mode register address; OP = operation code; CID = chip identifier; CW = control word; H = logic high; L = logic low; X = don't care, or it doesn't matter what state the signal has, and the signal may be floating; and, V = valid, meaning any valid signal state, or more specifically high or low.

[0075] ACT represents an activate command that can be used in memory array access. As indicated above, a number of activations equal to or above a threshold may result in a row hammer event. In one example, the memory controller counts the number of activations and sends additional refresh commands to provide additional refresh cycles to the memory device so that row hammer mitigation can be performed.

[0076] The command table 500 includes a Refresh All command REF to refresh all rows. The REF command causes the memory device to refresh rows according to the row addresses indicated in the refresh counter. In one example, according to the above description, the memory device can refresh rows out of order according to the refresh counter so as to perform refresh on the victim rows at risk of data loss due to the row hammering event. The memory device performs randomization on the selected rows.

[0077] In one example, the command table 500 includes a refresh same bank REFsb command to refresh the same bank in different groups. In one example, the memory device can perform a row hammer mitigation refresh as a stolen refresh cycle according to a REF or REFsb command. In one example, the command table 500 includes a self refresh entry SRE command to cause the memory device to enter a low power state and perform a self refresh. It should be understood that SRE is a different command type from REF or REFsb. REF and REFsb commands can be referred to as external refresh commands.

[0078] In one example, the memory controller tags one or more refresh commands to mark them as additional refresh or row hammer refresh commands. The memory device can detect this bit and determine from it that the refresh command is intended for row hammer mitigation. In one example, the refresh command can be extended with a header or other bit to indicate row hammer mitigation. It will be observed that for the command table 500, there are bits CA8 and CA9 as indicated by area 510 that only require valid signals to comply with the command encoding. Thus, these bits can be used as tags, for example, where the memory controller sets the value of one of these bits to indicate a row hammer mitigation refresh, and the memory device detects the logic value of the bit to determine whether it is a standard refresh command or a row hammer refresh command. In one example, a command that is modified to have allowable information in the bit but is not directed under the memory device specification (such as CA8 and CA9 under the double data rate (DDR) standard) can be considered a refresh management command.

[0079] It should be understood that the illustrated tagging is only one possible example. There are other ways to tag commands for row hammer mitigation.

[0080] Figure 6 is a flow chart of an example of a process for host-assisted row hammer mitigation. According to any example herein, process 600 can be implemented by a system with host-assisted row hammer mitigation.

[0081] In one example, the memory controller determines whether there is an activate command to be sent to the memory device at 602. If there is an activate command—602 "yes" branch, the memory controller can increment a counter at 604. In one example, if no activate command is detected—602 "no" branch, the memory controller does not increment the counter.

[0082] After checking for the activate command, in one example, the memory controller determines if there is a timer timeout at 606. In one example, if there is a timer timeout - 606 "yes" branch, the memory controller decrements the counter. This implementation may be referred to as a leaky bucket implementation to create a sliding window for checking for row hammering conditions. In the leaky bucket approach, detection of an activate command increments the counter, while a timer timeout decrements the counter. The decrement may be a single decrement, depending on the frequency of timer timeouts, or in multiple units for slower counters. If no timeout is detected - 606 "no" branch, the counter is not changed.

[0083] In one example, after checking for an activate command and the timer expires, the memory controller can determine whether the counter exceeds its limit, indicating that a threshold has been reached, at 608. In one example, if the threshold has been reached, the memory controller sends additional refresh commands and resets the counter at 610. In one example, if the counter has not reached the threshold, the memory system continues to monitor for an activate command at 602.

[0084] Figure 7 is a block diagram of an example of a memory subsystem in which host-assisted row hammer mitigation can be implemented. System 700 includes a processor and elements of a memory subsystem in a computing device. System 700 can be based on Figure 1 An example of system 100 is shown.

[0085] In one example, the memory device 740 includes row hammer logic 780, which represents row hammer logic that enables the memory device to manage row hammer mitigation within the memory device. In one example, according to any of the examples provided herein, the memory controller 720 includes row hammer logic 790 for providing host-assisted row hammer mitigation. The row hammer logic 790 enables the controller to send additional refresh commands to enable the memory device 740 to perform refreshes on potential victim rows via the row hammer logic 780.

[0086] In one example, memory module 770 represents DIMM and includes registers (e.g., RDIMM or DIMM with registers). In one example, memory module 770 includes multiple buffers that can be separately addressed. In RDIMM, the register buffers the C / A bus, but the data line can be buffered. The specific PDA operation of the command bus as described herein can be utilized in the system 700 with or without registers or buffers or clock devices with registers.

[0087] Processor 710 represents a processing unit of a computing platform that can execute an operating system (OS) and applications, which can be collectively referred to as a host or user of memory. The OS and applications perform operations that result in memory access. Processor 710 may include one or more separate processors. Each separate processor may include a single processing unit, a multi-core processing unit, or a combination thereof. The processing unit may be a main processor such as a CPU (central processing unit), a peripheral processor such as a GPU (graphics processing unit), or a combination thereof. Memory access may also be initiated by devices such as a network controller or a hard disk controller. Such a device may be integrated with a processor in some systems, or connected to a processor via a bus such as PCI Express, or a combination thereof. System 700 may be implemented as a SOC (system on chip), or may be implemented in the case of separate components.

[0088] References to memory devices may apply to different memory types. Memory devices typically refer to volatile memory technology. Volatile memory is memory whose state (and therefore the data stored on it) is uncertain if power to the device is interrupted. Non-volatile memory refers to memory whose state is determined even if power to the device is interrupted. Dynamic volatile memory requires refreshing of the data stored in the device to maintain the state. An example of dynamic volatile memory includes DRAM (Dynamic Random Access Memory), or some variants such as Synchronous DRAM (SDRAM). The memory subsystem as described herein may be compatible with multiple memory technologies, such as DDR4 (DDR version 4, JESD79, an initial specification disclosed by JEDEC in September 2012), LPDDR4 (Low Power DDR version 4, JESD209-4, originally disclosed by JEDEC in August 2014), WIO2 (Wide I / O 2 (WideIO2), JESD229-2, originally disclosed by JEDEC in August 2014), HBM (High Bandwidth Memory DRAM, JESD235A, originally disclosed by JEDEC in November 2015), DDR5 (DDR version 5, currently under discussion by JEDEC), LPDDR5 (currently under discussion by JEDEC), HBM2 ((HBM version 2), currently under discussion by JEDEC) and / or other or combinations of memory technologies, as well as technologies based on derivatives or extensions of such specifications.

[0089] In addition to volatile memory or as an alternative to volatile memory, in one example, a reference to a memory device may refer to a non-volatile memory device whose state is determined even if power to the device is interrupted. In one example, the non-volatile memory device is a block addressable memory device, such as NAND or NOR technology. Therefore, the memory device may also include a next generation non-volatile device, such as a three-dimensional crosspoint memory device, other byte addressable non-volatile memory devices, or a memory device using a chalcogenide phase change material (e.g., chalcogenide glass). In one example, the memory device may be or include a multi-threshold level NAND flash memory, a NOR flash memory, a single-level or multi-level phase change memory (PCM), a phase change memory with a switch (PCMS), a resistive memory, a nanowire memory, a ferroelectric transistor random access memory (FeTRAM), a magnetoresistive random access memory (MRAM) memory incorporating memristor technology, or a spin transfer torque (STT)-MRAM, or a combination of any of the above, or other memory.

[0090] Descriptions herein referring to "RAM" or "RAM device" may apply to any memory device that allows random access, whether volatile or non-volatile. Descriptions referring to "DRAM" or "DRAM device" may refer to a volatile random access memory device. A memory device or DRAM may refer to the die itself, to a packaged memory product that includes one or more dies, or both. In one example, a system having volatile memory that needs to be refreshed may also include non-volatile memory.

[0091] The memory controller 720 represents one or more memory controller circuits or devices for the system 700. The memory controller 720 represents control logic that generates memory access commands in response to the execution of the operation by the processor 710. The memory controller 720 accesses one or more memory devices 740. The memory device 740 can be a DRAM device according to any of the above-mentioned. In one example, the memory device 740 is organized and managed as different channels, each of which is coupled to a bus and a signal line, which is coupled to multiple memory devices in parallel. Each channel can operate independently. Therefore, each channel is accessed and controlled independently, and for each channel, the timing, data transfer, command and address exchange and other operations are separated. Coupling can refer to electrical coupling, communication coupling, physical coupling or a combination thereof. Physical coupling can include direct contact. Electrical coupling includes an interface or interconnection that allows electrical flow between components, or allows signal notification between components, or both. Communication coupling includes connections (including wired or wireless connections) that enable components to exchange data.

[0092] In one example, the settings for each channel are controlled by separate mode registers or other register settings. In one example, each memory controller 720 manages a separate memory channel, although the system 700 can be configured to have multiple channels managed by a single controller, or to have multiple controllers on a single channel. In one example, the memory controller 720 is part of the host processor 710, such as logic implemented on the same die as the processor, or logic implemented in the same package space as the processor.

[0093] The memory controller 720 includes an I / O interface logic 722 for coupling to a memory bus such as the memory channel mentioned above. The I / O interface logic 722 (and the I / O interface logic 742 of the memory device 740) may include pins, pads, connectors, signal lines, traces or lines, or other hardware for connecting devices, or a combination of these. The I / O interface logic 722 may include a hardware interface. As shown, the I / O interface logic 722 includes at least a driver / transceiver for a signal line. Typically, the lines within the integrated circuit interface are coupled to pads, pins or connectors to connect signal lines or traces or other lines between devices. The I / O interface logic 722 may include a driver, a receiver, a transceiver, or a termination device (termination), or other circuits or circuit combinations to exchange signals on signal lines between devices. Signal exchange includes at least one of sending or receiving. Although shown as coupling I / O 722 from memory controller 720 to I / O 742 of memory devices 740, it should be understood that in implementations of system 700 where groups of memory devices 740 are accessed in parallel, multiple memory devices may include an I / O interface to the same interface of memory controller 720. In implementations of system 700 that include one or more memory modules 770, I / O 742 may include interface hardware for the memory modules in addition to interface hardware on the memory devices themselves. Other memory controllers 720 will include separate interfaces to other memory devices 740.

[0094] The bus between the memory controller 720 and the memory device 740 can be implemented as a plurality of signal lines coupling the memory controller 720 to the memory device 740. The bus can generally include at least a clock (CLK) 732, a command / address (CMD) 734, and write data (DQ) and read data (DQ) 736, and zero or more other signal lines 738. In one example, the bus or connection between the memory controller 720 and the memory can be referred to as a memory bus. The signal line for CMD can be referred to as a "C / A bus" (or ADD / CMD bus, or some other name indicating the transmission of command (C or CMD) and address (A or ADD) information), and the signal line for write and read DQ can be referred to as a "data bus". In one example, independent channels have different clock signals, C / A buses, data buses, and other signal lines. Therefore, in the sense that independent interface paths can be considered as separate buses, the system 700 can be considered to have multiple "buses". It should be understood that, in addition to the lines clearly shown, the bus may also include at least one of a gate command line, an alarm line, an auxiliary line or other signal line, or a combination thereof. It should also be understood that serial bus technology can be used for the connection between the memory controller 720 and the memory device 740. An example of serial bus technology is the transmission of high-speed data and 8B10B encoding in the case of an embedded clock by a single differential signal pair in each direction. In one example, CMD 734 represents a signal line shared in parallel with multiple memory devices. In one example, multiple memory devices share the encoding command signal line of CMD 734, and each has a separate chip select (CS_n) signal line to select each memory device.

[0095] It should be understood that in the example of system 700, the bus between the memory controller 720 and the memory device 740 includes an auxiliary command bus CMD 734 and an auxiliary bus DQ 736 for carrying write and read data. In one example, the data bus may include bidirectional lines for read data and for write / command data. In another example, the auxiliary bus DQ736 may include a unidirectional write signal line for write and data from the host to the memory, and may include a unidirectional line for read data from the memory to the host. Depending on the selected memory technology and system design, other signals 738 may accompany the bus or sub-bus such as the strobe line DQS. Based on the design or implementation of the system 700 (if the design supports multiple implementations), the data bus may have more or less bandwidth per memory device 740. For example, the data bus may support memory devices with x32 interfaces, x16 interfaces, x8 interfaces, or other interfaces. The notation "xW", where W refers to an integer of the interface size or interface width of the memory device 740, represents the number of signal lines that exchange data with the memory controller 720. The interface size of the memory device is a controlling factor regarding how many memory devices can be used simultaneously per channel or how many memory devices can be coupled in parallel to the same signal line in the system 700. In one example, a high bandwidth memory device, a wide interface device, or a stacked memory configuration, or a combination thereof, can implement a wider interface, such as a x128 interface, a x256 interface, a x512 interface, a x1024 interface, or other data bus interface widths.

[0096] In one example, the memory device 740 and the memory controller 720 exchange data through the data bus in a burst or continuous data transfer sequence. The burst corresponds to a plurality of transfer cycles related to the bus frequency. In one example, the transfer cycle can be the entire clock cycle for the transfer occurring on the same clock or strobe signal edge (e.g., on the rising edge). In one example, each clock cycle (which refers to the cycle of the system clock) is divided into a plurality of unit intervals (UI), wherein each UI is a transfer cycle. For example, double data rate transfer is triggered on two edges (e.g., rising edge and falling edge) of the clock signal. The burst can last up to a configured number of UIs, which can be a configuration stored in a register, or triggered in operation. For example, a sequence of eight continuous transfer periods can be considered as a burst length 8 (BL8), and each memory device 740 can transfer data on each UI. Therefore, an x8 memory device operating on BL8 can transfer 64 bits of data (8 data signal lines multiplied by 8 data bits transferred per row on the burst). It should be understood that this simple example is merely illustrative and not restrictive.

[0097] The memory devices 740 represent memory resources for the system 700. In one example, each memory device 740 is a separate memory die. In one example, each memory device 740 can be docked with multiple (e.g., 2) channels per device or per die. Each memory device 740 includes an I / O interface logic 742 having a bandwidth determined by the implementation of the device (e.g., x16 or x8 or some other interface bandwidth). The I / O interface logic 742 enables the memory device to dock with the memory controller 720. The I / O interface logic 742 may include a hardware interface and may be based on the I / O 722 of the memory controller, but at the end of the memory device. In one example, multiple memory devices 740 are connected in parallel to the same command and data bus. In another example, multiple memory devices 740 are connected in parallel to the same command bus and are connected to different data buses. For example, the system 700 may be configured with multiple memory devices 740 coupled in parallel, each of which responds to commands and accesses memory resources 760 inside each memory device. For write operations, individual memory devices 740 may write a portion of an entire data word, and for read operations, individual memory devices 740 may fetch a portion of an entire data word. As non-limiting examples, a particular memory device may provide or receive 8 bits of a 128-bit data word for a read or write transaction, or 8 or 16 bits of a 256-bit data word (depending on the x8 or x16 device), respectively. The remaining bits of the word will be provided or received in parallel by other memory devices.

[0098] In one example, the memory device 740 is directly disposed on a motherboard or host system platform (e.g., a PCB (printed circuit board) on which the processor 710 is arranged) of the computing device. In one example, the memory device 740 can be organized into a memory module 770. In one example, the memory module 770 represents a dual in-line memory module (DIMM). In one example, the memory module 770 represents other organizations of multiple memory devices for sharing at least a portion of the access or control circuit, which can be a circuit, a separate device, or a separate board separated from the host system platform. The memory module 770 may include multiple memory devices 740, and the memory module may include support for multiple separate channels to the included memory devices disposed on them. In another example, the memory device 740 may be incorporated into the same package as the memory controller 720, such as by a technology such as a multi-chip module (MCM), a stacked package (package-on-package), a through silicon via (TSV), or other technologies or combinations thereof. Similarly, in one example, multiple memory devices 740 may be incorporated into a memory module 770, which itself may be incorporated into the same package as the memory controller 720. It should be appreciated that for these and other implementations, the memory controller 720 may be part of the host processor 710.

[0099] The memory devices 740 each include a memory resource 760. The memory resource 760 represents each array of memory locations or storage locations for data. Typically, the memory resource 760 is managed as a data row accessed via word lines (rows) and bit lines (individual bits in a row) control. The memory resource 760 can be organized into separate channels, rows, and storage bodies of the memory. A channel can refer to an independent control path to a storage location in the memory device 740. A row can refer to a common location across multiple memory devices (e.g., the same row address in different devices). A storage body can refer to an array of memory locations in the memory device 740. In one example, a storage body of a memory is divided into sub-storage bodies, which have at least a portion of a shared circuit (e.g., driver, signal line, control logic) for the sub-storage body, thereby allowing separate addressing and access. It should be understood that the channel, row, storage body, sub-storage body, storage body group or other organization of the memory location and the combination of these organizations can overlap in its application to physical resources. For example, the same physical memory location may be accessed through a specific channel as a specific bank, which may also belong to a certain rank. Thus, the organization of memory resources is to be understood in an inclusive rather than exclusive manner.

[0100] In one example, the memory device 740 includes one or more registers 744. Register 744 represents one or more storage devices or storage locations that provide configuration or settings for the operation of the memory device. In one example, register 744 can provide a storage location for the memory device 740 to store data for access by the memory controller 720 as part of a control or management operation. In one example, register 744 includes one or more mode registers. In one example, register 744 includes one or more multi-function registers. The configuration of the location within register 744 can configure the memory device 740 to operate in different "modes", where command information can trigger different operations within the memory device 740 based on the mode. Additionally or alternatively, different modes can also trigger different operations based on address information or other signal lines depending on the mode. The settings of register 744 can indicate the configuration for I / O settings (e.g., timing, termination device or ODT (on-die termination device) 746, driver configuration, or other I / O settings).

[0101] In one example, the memory device 740 includes an ODT 746 as part of the interface hardware associated with the I / O 742. The ODT 746 can be configured as mentioned above, and provides a setting for the impedance to be applied to the interface to a specified signal line. In one example, the ODT 746 is applied to the DQ signal line. In one example, the ODT 746 is applied to the command signal line. In one example, the ODT 746 is applied to the address signal line. In one example, the ODT 746 can be applied to any combination of the foregoing. The ODT setting can be changed based on whether the memory device is the selected target or non-target device of the access operation. The ODT 746 setting can affect the timing and reflection of the signaling on the terminated line. Careful control of the ODT 746 can achieve higher speed operation in the case of improved matching of the applied impedance and loading. The ODT 746 can be applied to specific signal lines of the I / O interface 742, 722, without having to be applied to all signal lines.

[0102] The memory device 740 includes a controller 750, which represents the control logic within the memory device for controlling the internal operations within the memory device. For example, the controller 750 decodes the command sent by the memory controller 720 and generates an internal operation to execute or satisfy the command. The controller 750 can be referred to as an internal controller and is separated from the memory controller 720 of the host. The controller 750 can determine what mode to select based on the register 744, and configure the internal execution of the operation or other operation for accessing the memory resource 760 based on the selected mode. The controller 750 generates a control signal to control the routing of the bits within the memory device 740 so as to provide an appropriate interface for the selected mode, and guide the command to the appropriate memory location or address. The controller 750 includes a command logic 752, which can decode the command encoding received on the command and address signal lines. Therefore, the command logic 752 can be or include a command decoder. Using the command logic 752, the memory device can identify the command and generate an internal operation to execute the requested command.

[0103] Referring again to the memory controller 720, the memory controller 720 includes command (CMD) logic 724, which represents logic or circuitry for generating commands to be sent to the memory device 740. The generation of a command may refer to a command before scheduling, or to the preparation of a queued command ready to be sent. Typically, signaling in a memory subsystem includes address information within or accompanying a command to indicate or select one or more memory locations where the memory device should execute the command. In response to scheduling a transaction for the memory device 740, the memory controller 720 may issue a command via I / O 722 to cause the memory device 740 to execute the command. In one example, the controller 750 of the memory device 740 receives and decodes the command and address information received from the memory controller 720 via I / O 742. Based on the received command and address information, the controller 750 may control the timing of the operation of the logic and circuitry within the memory device 740 to execute the command. The controller 750 is responsible for complying with standards or specifications (such as timing and signaling requirements) within the memory device 740. The memory controller 720 may implement compliance with standards or specifications through access scheduling and control.

[0104] The memory controller 720 includes a scheduler 730, which represents logic or circuitry for generating transactions and ordering transactions to be sent to the memory device 740. From one perspective, it can be said that the main function of the memory controller 720 is to schedule memory access and other transactions to the memory device 740. Such scheduling can include generating the transaction itself to implement the processor 710 request for data and maintain the integrity of the data (e.g., such as using commands related to refresh). A transaction can include one or more commands and result in the transfer of commands or data, or both, over one or more timing cycles (such as clock cycles or unit intervals). Transactions can be used for access (such as read or write or related commands or combinations thereof), while other transactions can include memory management commands for configuration, setup, data integrity, or other commands or combinations thereof.

[0105] The memory controller 720 typically includes logic such as a scheduler 730 to allow transactions to be selected and ordered to improve the performance of the system 700. Thus, the memory controller 720 can select which pending transactions should be sent to the memory device 740 in which order, which is typically implemented using logic that is much more complex than a simple first-in, first-out algorithm. The memory controller 720 manages the transmission of transactions to the memory device 740 and manages the timing associated with the transactions. In one example, the transactions have deterministic timing that can be managed by the memory controller 720 and can be used to determine how to schedule transactions using the scheduler 730.

[0106] In one example, the memory controller 720 includes a refresh (REF) logic 726. The refresh logic 726 can be used for memory resources that are volatile and need to be refreshed to maintain a deterministic state. In one example, the refresh logic 726 indicates the location for refresh and the type of refresh to be performed. The refresh logic 726 can trigger a self-refresh within the memory device 740 by sending a refresh command, or perform an external refresh (which can be referred to as an automatic refresh command) or a combination thereof. In one example, the system 700 supports all memory bank refreshes and per-memory bank refreshes. All memory bank refreshes result in refreshes of memory banks within all memory devices 740 coupled in parallel. Per-memory bank refreshes result in refreshes of specified memory banks within a specified memory device 740. In one example, the controller 750 within the memory device 740 includes a refresh logic 754 for applying refreshes within the memory device 740. In one example, the refresh logic 754 generates internal operations to perform refreshes based on external refreshes received from the memory controller 720. The refresh logic 754 can determine whether to direct the refresh to the memory device 740, and what memory resource 760 to refresh in response to the command.

[0107] Figure 8 800 is a block diagram of an example of a computing system in which host-assisted row hammer mitigation may be implemented. System 800 represents a computing device according to any example herein and may be a laptop computer, a desktop computer, a tablet computer, a server, a gaming or entertainment control system, an embedded computing device, or other electronic device. System 800 provides an example of a system according to system 100.

[0108] In one example, the memory subsystem 820 includes row hammer logic 890, which represents row hammer logic for implementing host-assisted row hammer mitigation according to any of the examples herein. The row hammer logic may include logic in a memory device for managing row hammer mitigation internal to the memory device. In one example, the row hammer logic 890 includes row hammer logic in a memory controller 822 for providing host-assisted row hammer mitigation according to any of the examples provided herein. The row hammer logic 890 enables the controller to send additional refresh commands to enable the memory 830 to perform refreshes of potential victim rows based on the number of activation commands.

[0109] The system 800 includes a processor 810, which may include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware or combination thereof to provide processing or execution of instructions for the system 800. The processor 810 controls the overall operation of the system 800 and may be or include one or more programmable general or special purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations of such devices.

[0110] In one example, the system 800 includes an interface 812 coupled to the processor 810, which can represent a higher speed interface or a high throughput interface for system components (such as a memory subsystem 820 or a graphics interface component 840) that require a higher bandwidth connection. The interface 812 represents an interface circuit, which can be an independent component or integrated into a processor die. The interface 812 can be integrated into the processor die as a circuit, or integrated into a system on a chip as a component. The graphics interface 840 interfaces with the graphics component when present to provide a visual display to a user of the system 800. The graphics interface 840 can be an independent component or integrated into a processor die or a system on a chip. In one example, the graphics interface 840 can drive a high-definition (HD) display that provides output to the user. In one example, the display can include a touch screen display. In one example, the graphics interface 840 generates a display based on data stored in the memory 830 or based on operations performed by the processor 810 or both.

[0111] The memory subsystem 820 represents the main memory of the system 800 and provides storage for the code to be executed by the processor 810 or the data values ​​to be used in the execution routine. The memory subsystem 820 may include one or more memory devices 830, such as read-only memory (ROM), flash memory, one or more types of random access memory (RAM) (such as DRAM), or other memory devices, or a combination of such devices. Among other things, the memory 830 also stores and hosts an operating system (OS) 832 to provide a software platform for the execution of instructions in the system 800. Additionally, applications 834 can be executed on the software platform of the OS 832 based on the memory 830. Applications 834 represent programs that have their own operating logic to implement the execution of one or more functions. Processes 836 represent agents or routines that provide auxiliary functions to the OS 832 or one or more programs 834 or a combination thereof. The OS 832, applications 834, and processes 836 provide software logic to provide functions for the system 800. In one example, the memory subsystem 820 includes a memory controller 822, which is a memory controller for generating commands and issuing commands to the memory 830. It should be understood that the memory controller 822 can be a physical part of the processor 810 or a physical part of the interface 812. For example, the memory controller 822 can be an integrated memory controller that is integrated into a circuit with the processor 810, such as integrated into a processor die or a system on a chip.

[0112] Although not specifically illustrated, it should be understood that the system 800 may include one or more buses or bus systems between devices, such as a memory bus, a graphics bus, an interface bus, or others. A bus or other signal line may couple components together communicatively or electrically, or couple components communicatively and electrically. A bus may include a physical communication line, a point-to-point connection, a bridge, an adapter, a controller, or other circuits or a combination thereof. A bus may include, for example, a system bus, a peripheral component interconnect (PCI) bus, a hypertransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or one or more of other buses or a combination thereof.

[0113] In one example, system 800 includes an interface 814 that can be coupled to interface 812. Interface 814 can be a slower interface than interface 812. In one example, interface 814 represents an interface circuit that can include independent components and integrated circuits. In one example, multiple user interface components or peripheral components or both are coupled to interface 814. Network interface 850 provides system 800 with the ability to communicate with remote devices (e.g., servers or other computing devices) via one or more networks. Network interface 850 can include an Ethernet adapter, a wireless interconnect component, a cellular network interconnect component, a USB (universal serial bus) or other interface based on wired or wireless standards or a proprietary interface. Network interface 850 can exchange data with a remote device, which can include sending data stored in a memory or receiving data to be stored in a memory.

[0114] In one example, the system 800 includes one or more input / output (I / O) interfaces 860. The I / O interfaces 860 may include one or more interface components through which a user interacts with the system 800 (e.g., audio, alphanumeric, tactile / touch, or other interfacing). The peripheral interfaces 870 may include any hardware interfaces not specifically mentioned above. Peripheral devices generally refer to devices that are dependently connected to the system 800. A dependent connection is one in which the system 800 provides a software platform or a hardware platform, or both, on which operations are performed and on which a user interacts.

[0115] In one example, the system 800 includes a storage subsystem 880 for storing data in a non-volatile manner. In one example, in certain system implementations, at least some components of the storage device 880 may overlap with components of the memory subsystem 820. The storage subsystem 880 includes (one or more) storage devices 884, which may be or include any conventional media for storing large amounts of data in a non-volatile manner, such as one or more magnetic, solid-state or optical disks, or a combination thereof. The storage device 884 saves code or instructions and data 886 in a persistent state (i.e., the value is maintained despite power interruptions to the system 800). The storage device 884 may generally be considered as "memory", although the memory 830 is typically used to provide execution or operating memory for instructions to the processor 810. Given that the storage device 884 is non-volatile, the memory 830 may include volatile memory (i.e., if the power to the system 800 is interrupted, the value or state of the data is uncertain). In one example, the storage subsystem 880 includes a controller 882 to interface with the storage device 884. In one example, controller 882 is a physical part of interface 814 or processor 810 , or may include circuitry or logic in both processor 810 and interface 814 .

[0116] The power supply 802 provides power to the components of the system 800. More specifically, the power supply 802 is typically docked with one or more power supplies 804 in the system 800 to provide power to the components of the system 800. In one example, the power supply 804 includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such an AC power source can be a renewable energy (e.g., solar) power source 802. In one example, the power supply 802 includes a DC power source, such as an external AC to DC converter. In one example, the power supply 802 or the power supply 804 includes wireless charging hardware to charge via proximity to a charging field. In one example, the power supply 802 can include an internal battery or fuel cell source.

[0117] Fig. 9 900 is a block diagram of an example of a mobile device in which host-assisted row hammer mitigation may be implemented. System 900 represents a mobile computing device, such as a computing tablet, a mobile phone or smartphone, a wearable computing device, or other mobile device or embedded computing device. It should be understood that some of the components are generally shown and not all components of such a device are shown in system 900. System 900 provides an example of a system according to system 100.

[0118] In one example, the memory subsystem 960 includes row hammer logic 990, which represents row hammer logic for implementing host-assisted row hammer mitigation for any memory 962 that needs to be refreshed according to any example herein. The row hammer logic may include logic in the memory device for managing row hammer mitigation internal to the memory device. In one example, the row hammer logic 990 includes row hammer logic in the memory controller 964 for providing host-assisted row hammer mitigation according to any example provided herein. The row hammer logic 990 enables the controller to send additional refresh commands to enable the memory 962 to perform refreshes of potential victim rows based on the number of active commands.

[0119] The device 900 includes a processor 910 that performs the primary processing operations of the system 900. The processor 910 may include one or more physical devices, such as a microprocessor, an application processor, a microcontroller, a programmable logic device, or other processing components. The processing operations performed by the processor 910 include the execution of an operating platform or operating system on which applications and device functions are executed. The processing operations include operations related to I / O (input / output) in the case of a human user or other device, operations related to power management, operations related to connecting the system 900 to another device, or a combination thereof. The processing operations may also include operations related to audio I / O, display I / O, or other docking, or a combination thereof. The processor 910 may execute data stored in a memory. The processor 910 may write or edit data stored in a memory.

[0120] In one example, the system 900 includes one or more sensors 912. The sensor 912 represents an embedded sensor or an interface to an external sensor, or a combination thereof. The sensor 912 enables the system 900 to monitor or detect one or more conditions of the environment or device in which the system 900 is implemented. The sensor 912 may include an environmental sensor (such as a temperature sensor, a motion detector, a light detector, a camera, a chemical sensor (e.g., carbon monoxide, carbon dioxide or other chemical sensor)), a pressure sensor, an accelerometer, a gyroscope, a medical or physiological sensor (e.g., a biosensor, a heart rate monitor or other sensor for detecting physiological attributes), or other sensors or a combination thereof. The sensor 912 may also include a sensor for a biometric system, such as a fingerprint recognition system, a facial detection or recognition system, or other systems that detect or recognize user characteristics. The sensor 912 should be understood broadly, rather than limiting the many different types of sensors that can be implemented using the system 900. In one example, one or more sensors 912 are coupled to the processor 910 via a front-end circuit integrated with the processor 910. In one example, one or more sensors 912 are coupled to the processor 910 via another component of the system 900.

[0121] In one example, system 900 includes an audio subsystem 920, which represents hardware (e.g., audio hardware and audio circuits) and software (e.g., drivers, codecs) components associated with providing audio functions to a computing device. Audio functions can include speaker or headphone outputs, and microphone inputs. Devices for such functions can be integrated into system 900, or connected to system 900. In one example, a user interacts with system 900 by providing audio commands received and processed by processor 910.

[0122] The display subsystem 930 represents hardware (e.g., a display device) and software components (e.g., a driver) that provide a visual display to present to a user. In one example, the display includes a tactile component or a touch screen element for a user to interact with a computing device. The display subsystem 930 includes a display interface 932, which includes a specific screen or hardware device for providing a display to a user. In one example, the display interface 932 includes logic separated from the processor 910 (such as a graphics processor) for performing at least some processing related to the display. In one example, the display subsystem 930 includes a touch screen device that provides both output and input to the user. In one example, the display subsystem 930 includes a high-definition (HD) or ultra-high-definition (UHD) display that provides output to the user. In one example, the display subsystem includes or drives a touch screen display. In one example, the display subsystem 930 generates display information based on data stored in a memory or based on operations performed by the processor 910 or both.

[0123] I / O controller 940 represents hardware devices and software components related to interaction with the user. I / O controller 940 can operate to manage hardware as a part of audio subsystem 920, or display subsystem 930 or both. Additionally, I / O controller 940 illustrates a connection point for an additional device connected to system 900, through which a user may interact with the system. For example, the device that can be attached to system 900 may include a microphone device, a speaker or stereo system, a video system or other display device, a keyboard or keypad device, or other I / O devices for use with a specific application, such as a card reader or other devices.

[0124] As mentioned above, the I / O controller 940 can interact with the audio subsystem 920, or the display subsystem 930, or both. For example, input through a microphone or other audio device can provide input or commands for one or more applications or functions of the system 900. Additionally, audio output can be provided instead of or in addition to display output. In another example, if the display subsystem includes a touch screen, the display device also acts as an input device, which can be managed at least in part by the I / O controller 940. Additional buttons or switches may also be present on the system 900 to provide I / O functions managed by the I / O controller 940.

[0125] In one example, I / O controller 940 manages devices such as accelerometers, cameras, light sensors or other environmental sensors, gyroscopes, global positioning systems (GPS), or other hardware that may be included in system 900 or sensor 912. Input may be part of direct user interaction, as well as providing environmental input to the system to affect its operation (such as filtering for noise, adjusting the display for brightness detection, applying a camera flash, or other features).

[0126] In one example, the system 900 includes power management 950, which manages battery power usage, charging of the battery, and features related to power saving operation. Power management 950 manages power from a power supply 952, which provides power to components of the system 900. In one example, the power supply 952 includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such an AC power source can be a renewable energy source (e.g., a solar power source, a motion-based power source). In one example, the power supply 952 includes only DC power, which can be provided by a DC power source such as an external AC to DC converter. In one example, the power supply 952 includes wireless charging hardware to charge via proximity to a charging field. In one example, the power supply 952 can include an internal battery or fuel cell source.

[0127] The memory subsystem 960 includes (one or more) memory devices 962 for storing information in the system 900. The memory subsystem 960 may include non-volatile (if power to the memory device is interrupted, the state does not change) or volatile (if power to the memory device is interrupted, the state is indeterminate) memory devices or a combination thereof. The memory 960 may store application data, user data, music, photos, documents, or other data, as well as system data (whether long-term or temporary) related to the execution of applications and functions of the system 900. In one example, the memory subsystem 960 includes a memory controller 964 (which may also be considered part of the control of the system 900, and may potentially be considered part of the processor 910). The memory controller 964 includes a scheduler to generate and issue commands to control access to the storage device 962.

[0128] Connectivity 970 includes hardware devices (e.g., wireless or wired connectors and communication hardware, or a combination of wired and wireless hardware) and software components (e.g., drivers, protocol stacks) to enable the system 900 to communicate with external devices. External devices can be separate devices, such as other computing devices, wireless access points or base stations, and peripheral devices (such as headphones, printers, or other devices). In one example, the system 900 exchanges data with external devices for storage in memory or for display on a display device. The exchanged data can include data to be stored in memory, or data already stored in memory, so as to read, write, or edit the data.

[0129] Connectivity 970 may include multiple different types of connectivity. In summary, system 900 is illustrated with cellular connectivity 972 and wireless connectivity 974. Cellular connectivity 972 generally refers to cellular network connectivity provided by a wireless carrier, such as connectivity provided via GSM (Global System for Mobile Communications) or its variants or derivatives, CDMA (Code Multiple Division Access) or its variants or derivatives, TDM (Time Division Multiplexing) or its variants or derivatives, LTE (Long Term Evolution - also known as "4G") or other cellular service standards. Wireless connectivity 974 refers to non-cellular wireless connectivity, and may include a personal area network (such as Bluetooth), a local area network (such as WiFi) or a wide area network (such as WiMax), or other wireless communications or combinations thereof. Wireless communication refers to the transfer of data via a non-solid medium using modulated electromagnetic radiation. Wired communication occurs through a solid communication medium.

[0130] Peripheral connections 980 include hardware interfaces and connectors, as well as software components (e.g., drivers, protocol stacks) used to make peripheral connections. It should be understood that system 900 can be both a peripheral device to other computing devices ("to" 982) and have peripheral devices connected to it ("from" 984). Device 900 typically has a "docking" connector that connects to other computing devices for purposes such as managing (e.g., downloading, uploading, changing, syncing) content on system 900. Additionally, the docking connector can allow system 900 to connect to certain peripheral devices that allow system 900 to control content output, such as to an audio-visual system or other system.

[0131] In addition to proprietary docking connectors or other proprietary connection hardware, the system 900 may also make peripheral connections 980 via common or standards-based connectors. Common types may include a Universal Serial Bus (USB) connector (which may include any of a number of different hardware interfaces), a DisplayPort including a Mini DisplayPort (MDP), a High-Definition Multimedia Interface (HDMI), or other types.

[0132] Generally, with respect to the description herein, in one example, a dynamic random access memory (DRAM) device includes: a memory array having multiple rows of memory; and input / output (I / O) hardware for receiving commands from an associated memory controller, including multiple activate commands and multiple refresh commands, wherein in response to receiving a threshold number of activate commands, the memory controller will send an excess refresh command exceeding the number of refresh commands required to refresh the rows within a refresh window, wherein the DRAM device will perform a row hammer refresh in response to the excess refresh command to refresh a potential victim row of a potential aggressor row.

[0133] In one example, receiving a threshold number of activations includes receiving a threshold number of activations within a specific time window. In one example, receiving a threshold number of activations within a specific time window includes a sliding window where each activation command increments a count and a certain amount of time decrements the count. In one example, the threshold number of activation commands includes a threshold number of activation commands per channel or per row. In one example, the threshold number of activation commands includes a threshold number of activation commands per memory bank or per group of memory banks. In one example, the excessive refresh command includes a refresh command having a tag to indicate that the refresh command is for a row hammer refresh.

[0134] Generally speaking, with respect to the description herein, in one example, a memory controller includes: a buffer for queuing commands to be sent to a memory device having multiple rows of memory; a counter for tracking a number of activation commands to the memory device; and input / output (I / O) hardware for sending commands to the memory device, the commands including multiple activation commands and multiple refresh commands, wherein in response to detecting a threshold number of activation commands, the I / O hardware will send excess refresh commands exceeding the number of refresh commands required to refresh the rows within a refresh window, the excess refresh commands will trigger the memory device to perform a row hammer refresh to refresh a potential victim row of a potential aggressor row.

[0135] In one example, detecting a threshold number of activations includes detecting a threshold number of activations within a specific time window. In one example, detecting a threshold number of activations within a specific time window includes a sliding window where each activation command increments a counter and a certain amount of time decrements the counter. In one example, the threshold number of activation commands includes: a threshold number of activation commands for each channel or each row of a plurality of memory devices including a memory device. In one example, the threshold number of activation commands includes a threshold number of activation commands for each memory bank or each memory bank group of the memory device. In one example, the excessive refresh command includes a refresh command having a tag to indicate that the refresh command is for a row hammer refresh.

[0136] In general, with respect to the description herein, in one example, a system includes: a plurality of dynamic random access memory (DRAM) devices having a plurality of rows of memory; a memory controller coupled to the plurality of DRAM devices, the memory controller including a counter for tracking a number of activation commands to the memory devices; and input / output (I / O) hardware for sending a plurality of commands to the memory devices, the commands including a plurality of activation commands and a plurality of refresh commands, wherein in response to detecting a threshold number of activation commands, the I / O hardware will send an excess of refresh commands exceeding the number of refresh commands required to refresh the rows within a refresh window, the excess refresh commands will trigger the DRAM devices to perform a row hammer refresh to refresh a potential victim row of a potential aggressor row.

[0137] In one example, detecting a threshold number of activations includes detecting a threshold number of activations within a specific time window. In one example, detecting a threshold number of activations within a specific time window includes a sliding window where each activation command increments a counter and a certain amount of time decrements the counter. In one example, the threshold number of activation commands includes a threshold number of activation commands for each channel or each row of a DRAM device. In one example, the threshold number of activation commands includes a threshold number of activation commands for each DRAM device. In one example, the threshold number of activation commands includes a threshold number of activation commands for each memory bank or each memory bank group of a particular DRAM device. In one example, an over-refresh command includes a refresh command having a tag to indicate that the refresh command is for a row hammer refresh. In one example, the system includes one or more of: a host processor device coupled to a memory controller; a display communicatively coupled to a host processor; a network interface communicatively coupled to a host processor; or a battery to power the system.

[0138] The flowcharts as illustrated herein provide examples of sequences of various process actions. The flowcharts may indicate operations to be performed by software or firmware routines, as well as physical operations. The flowcharts may illustrate examples of implementations of states of finite state machines (FSMs) that may be implemented in hardware and / or software. Although shown in a particular sequence or order, the order of the actions may be modified unless otherwise specified. Therefore, the illustrated diagrams should be understood only as examples, and the processes may be performed in different orders, and certain actions may be performed in parallel. Additionally, one or more actions may be omitted; therefore, not all implementations will perform all actions.

[0139] To the extent that various operations or functions are described herein, they may be described or defined as software code, instructions, configurations, and / or data. Content may be directly executable ("object" or "executable" form), source code, or difference code ("delta" or "patch" code). Software content of the things described herein may be provided via an article having content stored thereon or via a method of operating a communication interface to send data through the communication interface. Machine-readable storage media may enable a machine to perform the functions or operations described, and include any mechanism for storing information in a form accessible to a machine (e.g., a computing device, an electronic system, etc.), such as recordable / non-recordable media (e.g., read-only memory (ROM), random access memory (RAM), disk storage media, optical storage media, flash memory devices, etc.). Communication interfaces include: any mechanism that interfaces with any of hardwired, wireless, optical, etc. media to communicate with another device, such as a memory bus interface, a processor bus interface, an Internet connection, a disk controller, etc. The communication interface may be configured by providing configuration parameters and / or sending signals to prepare the communication interface to provide data signals describing the software content.The communication interface may be accessed via one or more commands or signals sent to the communication interface.

[0140] The various components described herein may be components for performing the described operations or functions. Each component described herein includes software, hardware, or a combination of these. The components may be implemented as software modules, hardware modules, dedicated hardware (e.g., application-specific hardware, application-specific integrated circuits (ASICs), digital signal processors (DSPs), etc.), embedded controllers, hard-wired circuits, etc.

[0141] In addition to what is described herein, various modifications may be made to the disclosed content and implementation of the present invention without departing from its scope. Therefore, the description and examples herein should be interpreted in an illustrative and non-restrictive sense. The scope of the present invention should be measured only with reference to the claims that follow.

Claims

1. A dynamic random access memory (DRAM) device comprising: The memory rows to be refreshed during normal operation; as well as Input / output (I / O) hardware to receive additional refresh commands during a period of high access to the memory row indicated by a count of received activate commands, the additional refresh commands exceeding the number of refresh commands required to refresh the memory row within a refresh window, the additional refresh commands to provide additional refresh time for the DRAM device to internally manage refresh during the refresh window, including the DRAM device internally indicating an address for refresh.

2. The DRAM device of claim 1, wherein the I / O hardware is configured to receive the additional refresh commands in response to a threshold number of activate commands per memory bank.

3. The DRAM device of claim 1, wherein the I / O hardware is to receive the additional refresh command in response to a threshold number of activate commands within a sliding time window.

4. The DRAM device of claim 3, wherein receipt of each activate command causes a count to be incremented, and a certain amount of time causes the count to be decremented. 5 . The DRAM device of claim 1 , wherein the additional refresh command comprises a refresh command having a tag, the tag being used to indicate that the refresh command is for row hammering refresh. The DRAM device of claim 5 , wherein the tag comprises unused bits of a refresh command encoding.

7. The DRAM device according to claim 1, further comprising: A counter in the DRAM device is used to track the receipt of the activate command.

8. A memory controller comprising: a buffer to queue commands for sending to a dynamic random access memory (DRAM) device having a plurality of memory rows; as well as Input / output (I / O) hardware to send additional refresh commands in response to sending a threshold number of activate commands to the DRAM device, the additional refresh commands exceeding the number of refresh commands required to refresh the plurality of memory rows within a refresh window, the additional refresh commands to provide additional refresh time for the DRAM device during the refresh window to internally manage refresh, including the DRAM device internally indicating addresses for refresh. 9 . The memory controller of claim 8 , wherein the threshold number comprises a number of activate commands per memory bank.

10. The memory controller of claim 8, wherein the threshold number of activate commands comprises a threshold number of activate commands within a sliding time window.

11. The memory controller of claim 8, wherein the additional refresh command comprises a refresh command having a tag to indicate that the refresh command is for row hammering refresh.

12. The memory controller according to claim 8, further comprising: A counter in the memory controller is used to track the receipt of activate commands.

13. A system comprising: A dynamic random access memory (DRAM) device according to any one of claims 1 to 7; A memory controller is coupled to the DRAM device.

Images