CN116504295A - Feasible and efficient hammer error detection - Google Patents

Abstract

Practical, energy-efficient, and area-saving mitigation of errors in memory media devices caused by row hammer attacks and the like is described. Detection of errors is performed deterministically while maintaining a number of row access counters in SRAM that is less than a total number of protected rows in the memory media device. The mitigation may be implemented on a per-row group basis. The memory media device may be a DRAM.

Description

Feasible and efficient hammer error detection

Cross reference to related applications

The present application claims priority from U.S. provisional application No. 63/303,910 filed on day 2022, month 1, and 27, the contents of which are incorporated herein by reference. Furthermore, the present application relates to the following commonly assigned: U.S. patent application Ser. No. 17/941,551, filed on 9/2022, attorney docket No. 2021139975-US-2, entitled "cache policy bias caused by high DRAM Rate (Cache Policy Biased by High DRAM Row Activation Rate)"; U.S. patent application Ser. No. 17/941,558, filed on 9/2022, attorney docket No. 2021139975-US-3, entitled "memory media line activation Biased cache" (Memory Media Row Activation-Biased cache); U.S. patent application Ser. No. 17/940,785, filed on 8/9/2022, attorney docket No. 2021140001-US-2, entitled "RHR interrupt (RHR Interrupts to the Operating System) for operating System"; U.S. patent application Ser. No. 17/897,813, filed on 8/29 of 2022, attorney docket No. 2021140206-US-2, area optimization RHR solution (Area Optimized RHR Solution for the CXL Controller) entitled "CXL controller"; and U.S. patent application Ser. No. 17/941,655, filed on 9/2022, attorney docket No. 2021140260-US-2, entitled "aliased row hammer detector (Aliased Row Hammer Detector"), the contents of each of which are incorporated herein by reference.

Technical Field

The present disclosure relates to deterministic detection of row hammer errors in memory media.

Background

Memory devices (also referred to as "memory media devices") are widely used to store information in a variety of electronic devices, such as computers, user devices, wireless communication devices, cameras, digital displays, and the like. Information is stored by programming memory cells within a memory device to various states. For example, a binary memory cell may be programmed to one of two support states, typically corresponding to a logic 1 or a logic 0. In some examples, a single memory cell may support more than two possible states, any of which may be stored by the memory cell. To access information stored by the memory device, the component may read or sense the state of one or more memory cells within the memory device. To store information, a component may write or program one or more memory cells within a memory device to a corresponding state.

There are various types of memory devices including magnetic hard disks, random Access Memories (RAMs), read Only Memories (ROMs), dynamic RAMs (DRAMs), synchronous Dynamic RAMs (SDRAM), static RAMs (SRAMs), flash memories, and the like. The memory device may be volatile or nonvolatile. Unless regularly refreshed by an external power source, volatile memory cells (e.g., DRAM cells) may lose their programmed state over time. The SRAM memory may maintain its programmed state for the duration that the system is being powered on. Non-volatile memory cells (e.g., NAND memory cells) can maintain their programmed state for a long period of time even in the absence of an external power source.

The memory device may be coupled to a host (e.g., a host computing device) to store data, commands, and/or instructions for use by the host when the computer or other electronic system is operating. For example, data, commands, and/or instructions may be transferred between a host and a memory device during operation of a computing or other electronic system. A controller, referred to as a "memory controller," may be used to manage the transfer of data, commands, and/or instructions between a host and a memory device.

DRAM is organized as an array of memory cells, with each cell storing a programmed value. As noted above, if not periodically refreshed, the cell may lose its programmed value. Thus, the rows are refreshed at fixed intervals, commonly referred to as "refresh intervals". Refresh is also referred to as "row activation". In row activation, a row in a DRAM device is read, errors are corrected, and written back to the same physical row. In current DRAM devices, data corruption caused by a "row hammer event" (also referred to as a "row hammer attack") is a considerable risk.

A row hammer event occurs when a particular row in the media device is accessed multiple times in an "activation interval" (i.e., an interval between two refresh/activation events), i.e., a number of times exceeding a "row hammer threshold" (RHT). In particular, when a particular row ("aggressor row") is accessed more than RHT times during an activation interval, one or more rows that are physically close to the particular row in the DRAM media ("victim rows") may be affected by frequent activation of the particular row, and data corruption of the one or more rows may occur. Due to various physical effects of shrink manufacturing process geometry, the RHT of memory devices has been reduced to a level where even a common computer system program may inadvertently damage its own data or the data of another program sharing the same system memory. Conventional row hammer detection techniques are either feasible but not perfect-allowing data corruption or severe performance degradation, or perfect but not feasible-requiring expensive resources.

Conventional row hammer detector algorithms, such as "address sampling" and "priority CAM" (priority content addressable memory), are probabilistic and therefore cannot guarantee perfect (i.e., complete, accurate, and precise) protection against data corruption in all row hammer scenarios. If an intruder (e.g., a malicious attacker) knows enough details of these conventional row hammer detection methods and their implementations, the intruder can attack their shortcomings to bypass or destroy them and corrupt the data.

The "direct" or "perfect" row tracking method is a known perfect row hammer detection algorithm in which one counter is maintained for each row in the DRAM medium, but its implementation requires a large amount of memory and operating power, which are too high to be practical.

Guaranteed row hammer event cancellation is attractive for any memory device, but particularly attractive for systems such as very large scale data centers (HSDC). In HSDC, a processor and memory are typically shared by multiple clients. A malicious attacker may use a row hammer attack to silently (e.g., without detection) damage the data of other customers, possibly upgrading their privileges to control more system resources or compromising data center security.

Currently, row hammer damage is indistinguishable from other soft errors. Modern workloads impact processor caches and cause unintended row hammer scenarios. When the detected error exceeds a threshold rate, physical repair of the dual in-line memory module (DIMM) is required, which is typically returned to the vendor for accounting credits.

Accordingly, improved techniques are needed to mitigate soft errors such as row hammer errors.

Disclosure of Invention

Drawings

Fig. 1 illustrates an example functional block diagram in the form of a computing system including a memory controller configured for detecting row hammer attacks according to some example embodiments of this disclosure.

FIG. 2A shows a schematic diagram of a bank of memory in a DRAM media device.

Fig. 2B shows a flowchart depicting a basic implementation flow of row hammer mitigation.

Figure 3 graphically illustrates example distributions of row hammer events at the global level, at the channel level, and at the rank group level in the memory controller.

Fig. 4 illustrates a logical block diagram of a per-row group row hammer mitigation component in accordance with some embodiments.

Fig. 5 shows a flow chart of a process for row hammer mitigation.

Fig. 6 is a diagram of the maintenance of a limited number of counters according to a space saving algorithm.

Fig. 7 shows a flowchart of a row hammer mitigation process and related tables for maintaining some states, according to some example embodiments.

Fig. 8 shows a flowchart of a process that provides an alternative technique of initializing the table and metadata of the row hammer mitigation technique described in fig. 7, in accordance with some embodiments.

Fig. 9 graphically illustrates some timelines for arranging the operations illustrated in fig. 7, in accordance with some embodiments.

FIG. 10 illustrates an example of a state associated with a process according to some embodiments.

FIG. 11 illustrates a schematic diagram of a shuttle reset circuit in accordance with some embodiments.

Detailed Description

The present disclosure describes systems, apparatus, and methods related to a detector for memory medium soft errors, such as row hammer errors. The detector, sometimes referred to herein as a row hammer detector, is configured to perform deterministic detection of row hammer attacks in DRAM media in a viable (e.g., space-saving and energy-saving) manner. The detector is based on a modified "space saving" algorithm.

In the following detailed description of the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration, one or more embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those of ordinary skill in the art to practice the embodiments of this disclosure, and it is to be understood that other embodiments may be utilized and that process, electrical, and structural changes may be made without departing from the scope of the present disclosure.

In some embodiments, the row hammer detector is located in a "memory controller". The memory controller may schedule execution of operations to write data to at least one of the plurality of types of memory devices.

Fig. 1 shows an example functional block diagram in the form of a computing system 101 including a memory controller 100 configured for detecting row hammer attacks, according to some embodiments of the present disclosure. Computing system 101 may detect and mitigate row hammer attacks on one or more memory devices 126. The memory controller 100 includes a front end section 104, a central controller section 110, a back end section 119, and a management unit 135. The memory controller 100 may be coupled to a host 103 (i.e., host system 103) and a memory device 126. In some embodiments, memory device 126 may be a DRAM device.

Front end portion 104 includes an interface 106 to couple memory controller 100 to host 103 through one or more input/output (I/O) lanes 102. Communication via I/O lane 102 may be in accordance with protocols such as peripheral component interconnect express (PCIe). In some embodiments, multiple I/O lanes 102 may be configured as a single port. The exemplary embodiments are not limited by the number of I/O lanes, whether the I/O lanes belong to a single port, or the communication protocol used to communicate with the host. Interface 106 receives data and/or commands from host 103 through I/O lane 102. In an embodiment, interface 106 is a Physical (PHY) interface configured for PCIe communications. The front-end portion 104 may include interface management circuitry 108 (including data links and transaction control) that may provide higher layer protocol support for communicating with the host 103 over the PHY interface 106.

The central controller portion 110 is configured to control execution of memory operations in response to receiving requests or commands from the host 103. The memory operation may be a memory operation that reads data from or writes data to the memory device 126. The central controller portion 110 may include: a cache memory 112 to store data associated with the execution of memory operations; a security component 114 configured to encrypt data prior to storage and decrypt data after reading, the data being in the memory device 126.

In some embodiments, in response to receiving a request from the host 103, data from the host 103 may be stored in a cache line of the cache memory 112. Data in the cache memory may be written to the memory device 126. The error correction component 116 is configured to provide error correction to data read from and/or written to the memory device 126. In some embodiments, the data may be encrypted using an encryption protocol such as Advanced Encryption Standard (AES) encryption before the data is stored in the cache memory. In some embodiments, the central controller portion 110 may control the writing of multiple pages of data to the memory device 126 substantially simultaneously in response to receiving a request from the host 103.

The management unit 135 is configured to control the operation of the memory controller 100. The management unit may recognize commands from the host 103 and thus manage one or more memory devices 126. In some embodiments, the management unit 135 comprises: an I/O bus 138 to manage out-of-band data; a management unit controller 140 to perform its functions including, but not limited to, firmware that monitors and configures the characteristics of the memory controller 100; and a management unit memory 142 to store data associated with the memory controller 100 functions. The management unit controller 140 may also execute instructions associated with initializing and configuring the characteristics of the memory controller 100. The endpoints of the management unit 135 may be exposed to the host system 103 to manage data via the communication channel using the I/O bus 138.

A second endpoint of the management unit 135 may be exposed to the host system 103 to manage data over the communication channel using the interface 106. In some embodiments, the characteristics monitored by the management unit 135 may include the voltage supplied to the memory controller 100 or the temperature measured by an external sensor, or both. Further, the management unit 135 may include a local bus interconnect 136 to couple the different components of the memory controller 100. In some embodiments, the local bus interconnect 136 may include, but is not limited to, an advanced high performance bus (AHB).

The management unit 135 may include a management unit controller 140. In some embodiments, the management unit controller 140 may be a controller that meets the Joint Test Action Group (JTAG) standard and operates in accordance with the inter-integrated circuit (I2C) protocol and auxiliary I/O circuitry. As used herein, the term "JTAG" generally refers to an industry standard for verifying design and testing printed circuit boards after manufacture. As used herein, the term "I2C" generally refers to a serial protocol for a two-wire interface to connect low speed devices like microcontrollers, I/O interfaces, and other similar peripherals embedded in a system.

The back-end portion 119 is configured to be coupled to one or more types of memory devices (e.g., DRAM media 126) via (e.g., through) a plurality of channels 125 that may be used to read/write data from/to the memory devices 126, transmit commands to the memory devices 126, receive status and statistics from the memory devices 126, and so forth. The management unit 135 may couple the memory controller 100 to external circuitry or external devices, such as the host 103 that may generate requests to read data from and/or write data to the memory devices, by initializing and/or configuring the memory controller 100 and/or the memory devices 126 accordingly. The management unit 135 is configured to recognize commands received from the host 103 and execute instructions to apply specific operation codes associated with the received host commands for each of the plurality of channels coupled to the memory device 126.

The back-end portion 119 contains a media controller portion that includes a plurality of media controllers 120 and a Physical (PHY) layer portion that includes a plurality of PHY interfaces 122. In some embodiments, back-end portion 119 is configured to couple PHY interface 122 to a plurality of memory banks of memory device 126. The memory banks may be connected to the memory controller 100 via a plurality of channels 125. The respective media controller 120 and the respective PHY interface 122 may drive the channel 125 for a memory bank. In some embodiments, each media controller 120 may execute commands independent of other media controllers 120. Thus, data may be transferred from one PHY interface 122 to memory device 126 over channel 125 independent of the other PHY interfaces 122 and channel 125.

Each PHY interface 122 may operate according to a Physical (PHY) layer that couples the memory controller 100 to one or more memory banks in the memory device 126. As used herein, the term "PHY layer" generally refers to the physical layer in the Open Systems Interconnection (OSI) model of computing systems. The PHY layer may be the first (e.g., lowest) layer of the OSI model and may be used to transfer data via a physical data transmission medium. In some embodiments, the physical data transmission medium may be a plurality of channels 125. As used herein, the term "memory rank" generally refers to a plurality of memory chips (e.g., DRAM memory chips) that are simultaneously accessible. In some embodiments, the memory banks may be sixty-four (64) bits wide, and each memory bank may have eight (8) pages. In some embodiments, the page size of the first type of memory device may be greater than the page size of the second type of memory device. However, the exemplary embodiments are not limited to a particular width or page size of a memory bank.

Each media controller 120 may include channel control circuitry 124 and a plurality of bank control circuitry 128, wherein a respective one of the plurality of bank control circuitry 128 is configured to access a respective bank 130 of a plurality of banks on a media device 126 accessed by the respective media controller 120. In embodiments of the present disclosure, as described in more detail below, a memory error detector, or more specifically a respective per-row bank row hammer mitigation circuitry 132 is configured for each row bank 120 in each channel.

The ranks, channels, and ranks groups may be considered hardware dependent logical groupings of storage locations in the media device. The mapping of ranks, channels, and rank groups of logical groupings to physical storage locations or rows in the memory device 126 may be preconfigured or, in some embodiments, may be configured by a memory controller in communication with the memory device 126.

In some embodiments, the memory controller 100 may be Compute Express Link ^TM (CXL) compliant memory systems (e.g., a memory system may include a PCIe/CXL interface). CXLs are high-speed Central Processing Unit (CPU) -to-device and CPU-to-memory interconnects designed to facilitate next-generation data center performance. CXL technology maintains memory coherence between CPU memory space and memory on attached devices, which allows for resource sharing to achieve higher performance, reduce software stack complexity, and reduce overall system cost. As accelerators are increasingly used to supplement CPUs to support emerging applications, such as artificial intelligence and machine learning, CXLs are designed as industry open standard interfaces for high speed communications. CXL technology builds on peripheral component interconnect express (PCIe) infrastructure, which utilizes PCIe physical and electrical interfaces to provide advanced protocols in fields such as input/output (I/O) protocols, memory protocols (e.g., initially allowing a host to share memory with an accelerator), and coherence interfaces. When the memory controller 100 conforms to CXL, the interface management circuitry 108 (including the data link and transaction control 108) may use the CXL protocol to manage the interface 106, which may include a PCIe PHY interface.

According to some embodiments, memory device 126 includes one or more DRAM devices. In some embodiments, the main memory is stored in DRAM cells having a high storage density. DRAM cells lose their state over time. That is, the DRAM cells must be refreshed periodically, and therefore, are termed "dynamic". DRAMs may be described as being organized according to a hierarchy of memory organizations including DIMMs, ranks, banks, and arrays. The DIMMs include a plurality of DRAM chips, and the plurality of chips in the DIMM are organized into one or more "ranks". Each chip is formed of a plurality of "banks". The banks are formed from one or more "rows" of the memory cell array. All bank groups within a bank share all address and control pins. All of the banks are independent, but in some embodiments only one bank of the banks may be accessed at a time. Due to electrical constraints, only a few DIMMs may be attached to the bus. The ranks help to increase the capacity of the DIMM.

Multiple DRAM chips are used for each access to improve data transfer bandwidth. Multiple banks are provided so that the computing system can work for different requests simultaneously. To maximize density, the array within the bank is larger, the rows are wider, and the row buffers are wider (8 KB read for 64B requests). Each array provides a single bit to the output pins in a cycle (for high density and because there are fewer pins). DRAM chips are generally described as xN, where N refers to the number of output pins; one bank may consist of eight x8 DRAM chips (e.g., 64 bits for the data bus). Banks and banks provide memory parallelism, and memory controller 100 may schedule memory accesses to maximize row buffer hit rates and bank/bank parallelism.

In the embodiment shown in FIG. 1, memory device 126 is a Low Power Double Data Rate (LPDDR) LP5 or other similar memory interface. However, embodiments are not so limited, and memory device 126 may include one or more memory media of any memory media type subject to a row hammer attack or similar memory attack, such as, but not limited to, the type of DRAM.

Each of the plurality of media controllers 120 may receive the same command and address and drive the plurality of channels 125 substantially simultaneously. By using the same commands and addresses for the multiple media controllers, each of the multiple media controllers 120 can perform the same memory operation on the same plurality of memory units utilizing the multiple channels 125. Each media controller 120 may correspond to a RAID component. As used herein, the term "substantially" means that the characteristic need not be absolute, but rather close enough to achieve the advantage of the characteristic.

For example, "substantially simultaneous" is not limited to operations performed simultaneously and may include opportunities that are intended to be simultaneous but may not be exactly simultaneous due to manufacturing limitations. For example, media controllers that are utilized "substantially simultaneously" may not begin or end at the same time due to read/write delays that may be manifested by various interfaces (e.g., LPDDR5 and PCIe). For example, multiple memory controllers may be utilized such that they write data to a memory device at the same time regardless of whether one of the media controllers begins or ends before the other media controllers.

FIG. 2A shows a schematic diagram of a memory bank 130 viewed in a DRAM device, such as memory device 126. Row group 130 is shown representing a 10x10 array of cells organized in 10 rows (e.g., row 202) and 10 columns (e.g., column 204). For a bank, one row is read or stored at a time via a row buffer 206. Each cell in the array is accessed by providing a row address and a column address. Address bus, row access strobe, column access strobe (shown as A, RAS, CAS, respectively, in fig. 2A) are used to access a particular memory location in the array. The row buffer 206 and data or read/write signals are used for data to be read from or stored to a memory location.

In some memory devices, a counter not shown in FIG. 2A may be associated with a row to track the number of times the row has been activated during a particular time interval. For example, a counter may be initialized at the beginning of each refresh interval and incremented for each access to the row during the refresh interval. In a conventional perfect tracking implementation, a respective counter is associated with each row. In an exemplary embodiment, the number of counters maintained is much smaller than the total number of rows in a memory device attached to the memory controller.

Fig. 2B shows a flowchart 210 depicting a basic implementation flow of row hammer mitigation. Row hammer mitigation includes two aspects: the first aspect is row hammer detection and the second aspect is response to the detection. A variety of responses are possible, with the response commanding the memory device 126 to refresh the victim row (e.g., DRFM response) as one of the possible responses to mitigate or eliminate the effects of the row hammer effect. In some cases, the memory controller transmits a refresh command, such as a DRFM response, to the memory device 126 and designates an aggressor row, and the internal circuitry of the memory device determines the victim row to refresh and refreshes the victim row based on the aggressor row identified by the memory controller.

When a request to access a row in the memory device 126 is received, the row may be referred to in this disclosure as an "aggressor row" (row 207 in FIG. 2A), at operation 212, the row is identified as the next row to be activated. At operation 214, the value of a counter configured to track the number of accesses to the aggressor row over a predetermined time period is checked. At operation 216, it is determined whether the value of the counter is above RHT. When RHT is exceeded for aggressor row 207, the integrity of data in one or more rows (referred to as "victim rows"; see rows 208 and 209 in FIG. 2A) that are physically adjacent to aggressor row 207 cannot be guaranteed. The RHT may be factory set or may be configured at start-up time. If the value is higher than RHT, then a response is issued at operation 218.

One type of response may be a digital refresh management (DRFM) command that refreshes physically adjacent rows (e.g., rows 208 and 209) on both sides of the aggressor row 207. When a response is issued at operation 218, the counter (e.g., set to 0) of the refreshed victim rows (e.g., rows 208 and 209) may be reset. The number of physically adjacent rows to be refreshed may be preconfigured or may be dynamically determined. After issuing the response at 218, or if it is determined at operation 216 that the aggressor row 207 does not exceed RHT, then at operation 220, row activation for the aggressor row is scheduled and a counter for the row is incremented (e.g., by 1).

As described above, memory devices 126, such as one or more DRAM DIMMs, may be subject to row hammer attacks, and several methods are used to eliminate or reduce the impact of such attacks. While the inventors appreciate that conventional techniques of row hammer mitigation currently implemented in memory systems are deficient in the practicality of energy efficiency and/or space efficiency, the row hammer mitigation techniques implemented by the exemplary embodiments of this disclosure provide for perfect tracking of row hammer attacks in a viable, energy and/or space efficient manner (i.e., do not allow for any false negative row hammer detection).

As shown in fig. 3, in some example scenarios in which a DRAM memory device is attached to a CXL compliant memory controller, the global rate of row hammer attacks on the memory device may be about 6.25 hundred million attacks per second. Thus, if perfect row hammer detection is implemented at the global level for an attached memory device, the row hammer detector must be configured with enough counters to detect many attacks that occur in at least one second of duration. For example, in the exemplary embodiment shown in fig. 1, if perfect row tracking is to be implemented globally, central controller 110 may be configured with row hammer mitigation circuitry that potentially receives row access information for rows in an attached memory device from media controller 120 at a rate of 6.25 billion per second and communicates mitigation responses (e.g., DRFM) to the respective media controllers 120 as needed.

If per-channel row hammer mitigation is implemented for each media controller 120, then the sum of attack rates that the respective media controller 120 can handle must be at least 6.25 billion/second, such an implementation would be able to track significantly higher row update rates and accordingly using the required space and energy resources, as the resources are configured on a per-channel basis.

Similarly, if per-bank row hammer mitigation is implemented in per-bank controller 128 for each bank in the channel, the sum of attack rates that all bank controllers can handle must be at least equivalent to 6.25 billion/second, but this implementation will be able to and accordingly use the space and energy resources required to detect substantially higher detection rates, as the resources are configured on a per-bank basis. Thus, the total amount of space and energy resources that may be required to implement row hammer detection at the rank-group level exceeds the amount of space and energy resources that may be required at the channel level, which in turn exceeds the amount of space and energy resources required for the global-level implementation.

Thus, various approaches can be considered to achieve perfect (deterministic) row hammer tracking in a memory controller by accessing multiple rows as one unit (same row on different chips) and thus having only one counter for the group instead of having a counter for each row of the media device.

The motivation for the solution described in this disclosure is to instead of having a counter for each row of the memory device, instead the number of counters is limited to the number of potential attacks in a time frame, since only so many attacks can occur in a 60 millisecond time frame, for example. In an exemplary embodiment, the total number of counters and thus the size of the detector and the amount of resources used for the detector is limited to the total number of potential attacks rather than the total amount of memory to be protected. Thus, in practice, the exemplary embodiments provide a detector algorithm that scales with the maximum potential attacks per unit time rather than the protected maximum memory capacity.

A problem with having a separate counter for each row is that with the creation of large systems, memory can grow to millions (or even billions) of rows. With billions of counters then, one per row may produce billions of counters. Billions of attacks far exceeding 6.25 billions per second are divided into 60 milliseconds per second, which reduces the number of counters required to thousands rather than the number of counters that would be needed for each row of the protected memory in billions or millions. Thus, embodiments of the present disclosure provide a row hammer detector that scales with the maximum potential attacks per unit time rather than the protected maximum memory capacity.

As described above, memory devices 126, such as DRAMs, may be subject to row hammer attacks, and several methods are used to eliminate or reduce the impact of such attacks. While the inventors appreciate that conventional techniques of row hammer mitigation currently implemented in memory systems are deficient in energy efficiency and/or space efficiency, the row hammer mitigation techniques implemented by embodiments of the present disclosure provide perfect tracking of row hammer attacks in a practical, energy and/or space efficient manner (i.e., do not allow any false negative row hammer detection).

Fig. 4 illustrates a logical block diagram of each row of group row hammer mitigation component 132 in accordance with some embodiments. The row-per-row group row hammer mitigation component 132 is repeated for each row group of attached memory devices 126 accessed by the memory controller 100. As shown in fig. 1, each media controller 120 accessing media device 126 may have a plurality of row hammer mitigation components 132 such that each row group controlled by a channel corresponding to the media controller has a corresponding respective row hammer mitigation component 132.

Each row of group row hammer mitigation elements 132 includes row hammer detectors 133 and SRAM 134. The row hammer detector 133 includes circuitry that monitors the corresponding bank of memory devices 126 for row hammer attacks and responds appropriately when an attack or potential attack is detected. SRAM 134 is used by row hammer detector 133 to maintain counters and other states associated with row hammer detection of the corresponding bank. Additional desired states associated with row hammer detection may be maintained in the d-flip-flop associated with row hammer detector 133.

The "space saving" algorithm, originally described in Mei Tewa (Metwall) et al, "efficient computation of the first k high frequency elements in the data stream (Efficient Computation of Frequent and Top-k Elements in Data Streams)", report techniques 2005-23, university of California, santa Bara, month 9 2005 ("Mei Tewa li"), describes a technique for finding the most active users of a particular resource or service. Mei Tewa utilizes one of the described techniques for finding a specified maximum number of users for web services. The space saving algorithm may be used to perform deterministic row hammer detection with a lower number of counters than would be required if one counter were used for each row in the memory device. Looking at high levels, the space saving algorithm maintains only the first k (where k may be a predetermined positive number) counters, and thus the space required for the counters is greatly reduced. Thus, the space saving algorithm is referred to as space saving because it counts only the rows that need to be counted, rather than setting one counter for each row. By definition, this saves orders of magnitude space.

In the embodiments primarily described in this disclosure, a plurality of per-row group row hammer mitigation components 132 are included in memory controller 100. The inclusion of row hammer mitigation circuitry, e.g., a plurality of per-bank row hammer mitigation components 132, in memory controller 100 is advantageous because all accesses to memory devices 126 protected by row hammer mitigation circuitry flow through memory controller 100. However, embodiments of the present disclosure are not limited to implementing a plurality of per-row group row hammer assemblies 132 in memory controller 100. In some embodiments, the plurality of per-row group row hammer assemblies 132 may be implemented external to the memory controller. Further, embodiments may not be limited to storing counters in SRAM, and in some embodiments, memory 134 may be a different memory type than SRAM but providing serial searching of counters.

Fig. 5 shows a flow chart of a process for row hammer mitigation using aspects of the space saving algorithm described in Mei Tewa. As described in U.S. application No. 17/897,813 (docket No. 2021140206-US-2), filed on 8/29, 2022, which is incorporated herein by reference in its entirety, the "space saving" algorithm also provides thorough, accurate, and precise detection of any and all row hammer situations when modified and enhanced to address row hammer situations. However, as described in U.S. application Ser. No. 17/897,813 (Ser. No. 2021140206-US-2) to App. No. 29, 8, 2022, implementations can be cost prohibitive and power intensive, requiring both large Content Addressable Memories (CAMs) and magnitude searches of the entire detector state.

In the example implementation shown in fig. 5, a Content Addressable Memory (CAM) is used to maintain the counter. The RHT may be preconfigured. If n is the maximum row active during the cycle, then the CAM total entry is k=n/F, where F is RHT. The row counter should be at least log2 (RHT) in size. Each row counter may also have a "reserved" bit. The row address size should be at least log2 (the number of rows in a media (e.g., DRAM) bank). Thus, the total CAM size may be k (row counter size + reserved bits + row address size).

At operation 502, the CAM is initialized. CAM initialization may be performed at each refresh interval (e.g., tREF, interval of refreshing rows of memory devices) using a toggle reset or similar mechanism. As used herein, "reciprocation" may refer to the tendency of a device, apparatus, or the like to repeatedly alternate between two or more states. "reset to and fro" may provide a mechanism or procedure that interrupts or circumvents such operations, which may allow devices, apparatuses, etc. to operate in different ways. At operation 504, an incoming row address is received. The incoming row address is the address of a row in the memory device 126 that will be subsequently accessed by the memory controller 100. That is, the row address of the invader row 207 is received. At operation 506, the CAM is searched for an aggressor row address. CAM searches are parallel lookups of all CAM entries.

If an aggressor row address is found at operation 506, then at operation 508, a count associated with the aggressor row address is incremented in the CAM. At operation 510, a determination is made as to whether the incremented count exceeds RHT. As previously mentioned in this disclosure, RHT specifies the number of accesses for a particular row, which when exceeded causes the system to assume that the data integrity of a physically adjacent row, i.e., the victim row, is compromised. If it is determined at operation 510 that RHT is exceeded for the aggressor row address, then at operation 512 a trigger response is sent to the memory device. The response may be a signal (e.g., a DRFM command) that instructs the memory media device to refresh the identified victim row, and the aggressor row's counter is reset (e.g., set to 0).

In some embodiments, a flag associated with the counter being refreshed is additionally set to indicate that the aggressor row ID is "reserved" associated with the aggressor row counter in the CAM. In some embodiments, the flag may be a bit, referred to as a "sticky bit," that when set (e.g., set to 1) indicates that the aggressor row ID is reserved, and thus should not be considered in the selection of the minimum count value in operation 518 described below. Thus, the sticky bits enable initializing a subsequent newly inserted row based on the minimum count value in the CAM while ignoring the most recently refreshed row that may have a disproportionately low count value compared to most other rows in the table.

If it is determined at operation 506 that the row address is not in the CAM, then at operation 514 it is determined whether the CAM is full. If the CAM is not full, at operation 516, the incoming row is inserted and the count associated with the inserted row is incremented.

If the CAM is determined to be full at operation 514, then at operation 518 the row with the lowest count in the CAM is identified and replaced with a new row in the CAM. The value of the counter is incremented effectively introducing a new row into the CAM with a start value of 1 that is greater than the current minimum count in the CAM. It should be noted that in some implementations in which a row in the CAM has a sticky bit set, the row may not be considered in identifying the row with the lowest count, as described with respect to operation 512.

Fig. 6 is a diagram of the maintenance of a limited number of counters according to a space saving algorithm. In this example, four counters, counter 1, counter 2, counter 3, and counter 4 are maintained. Each counter (e.g., 606) represents a row of items at a given time instance and includes an address of the row (e.g., a row number) and a count associated with the row (e.g., a number of accesses to the row). The counter may be initialized at predetermined intervals. When a request is received in the illustrated time period (between two refreshes), 602 represents a sequence of consecutive row access requests. 604 illustrates the row (aggressor row) for which access is sought in the corresponding request. Requests 1-3 are accesses to rows 9, 7 and 6, respectively.

Since four counters are not allocated at the beginning of the illustrated cycle, counters 1, 2 and 3 are allocated to rows 9, 7 and 6 in response to requests 1-3. The corresponding counter is incremented to 1. Request 4 is an access to row 7, which already has an allocated counter, and thus the counter (counter 2) is incremented from 1 to 2. When request 6 is received for row 11, all four counters have been allocated. That is, there is no unassigned counter. Thus, the counter having the smallest count value is identified among the allocated counters. In this case, the counters 1, 3, and 4 have the lowest count value of 1, and the counter 3 is randomly selected from among the counters having the lowest count values to be reassigned to the row 11. Thus, counter 3 is assigned to row 11, but the count value of counter 3 is incremented only from the current value (i.e., the last value of the counter before replacing the corresponding row with the selected row), and thus from 1 to 2. By incrementing the count value of the counter, this technique ensures that row hammer attacks are taken into account even if the counter is reassigned from one row to another.

Looking at requests 10 and 11, it can be seen that counter 4 is reassigned to row 9 at request 10 with incremented counter value 2, but then is again selected in the next request to be reassigned to row 6 with incremented counter value 3 based on its counter value 2 being among the lowest counter values at the time. Thus, at the end of request 11, row 9 is no longer represented in the counter.

Again, however, row 9 is accessed at request 13. Thus, row 9 is reinserted into the counter by reassigning to counter 3, the row below counter value 2 being now among the lowest counter values. When row 9 is reintroduced into the counter at counter 3, it is incremented by a counter value of 3. Thus, the row access tracking process never decrements the counter value during tracking, and thus never misses a potential row hammer attack, even while maintaining a small number of counters compared to the total number of protected rows.

Because of its ability to provide deterministic row hammer detection with a relatively small number of counters (i.e., less than the total number of rows of the protected memory medium), a space-saving algorithm may be considered to be implemented as a row hammer mitigation technique. However, difficulties are encountered in implementing a space saving algorithm with respect to row hammer detection. The use of large CAMs requires excessive area and power when implemented as described above with respect to fig. 5. When the CAM is full, the entire CAM must be scanned in parallel to find the smallest count entry to be overwritten. Thus, an implementation of a space saving algorithm such as that described with respect to fig. 5 may require more time than an actual or simultaneous comparison of many counter values.

The update cycle of the space saving algorithm (e.g., operation 504-506-508-510-512) is similar to the basic row hammer update process shown in fig. 2. However, the space saving algorithm achieves deterministic row hammer mitigation with a much smaller number of counters than the technique that requires one counter for each row of the memory device. The space saving algorithm counts only the rows that need to be counted in the time interval, instead of setting one counter for each row. In some implementations, for example, while perfect detection from conventional row hammer detection may require millions of counters such that each row of memory is represented by a respective counter, the modified space saving algorithm used in process 500 may require only hundreds of counters, thus resulting in a substantial efficiency gain and reducing the state size to be maintained.

The key reason for the energy efficiency of the implementation shown in FIG. 5 is the test required at operation 506 to determine "as a row in the CAM". CAMs are highly associative, i.e., parallel compare memories. Thus, even though the space saving algorithm may reduce the problem of tracking row hammer attacks from billions of counters to thousands, the implementation shown in fig. 5 still requires access and thousands of comparisons in a short amount of time. For example, to process 6.25 hundred million events per second at the global (i.e., all channels) level as described above, it may be desirable to process about 62000 events every 60 milliseconds. Such use of large CAMs is highly resource intensive in both silicon area and energy, and thus may not be feasible in a system environment requiring row hammer mitigation.

Row hammer mitigation according to fig. 5 may be implemented in each row group. This will result in each row group implementing row hammer mitigation having to handle the incoming rate of events that are orders of magnitude less than the incoming rate of events that need to be handled at the global level. However, if a CAM is used to perform a lookup at operation 506 according to the implementation of FIG. 5, then in each 60 millisecond time period, it is necessary to span all banks equal to or greater in number than is required at the above-described global level of highly resource-intensive CAM lookups. Therefore, a per-row group embodiment of row hammer mitigation according to fig. 5 is not much feasible.

Mainly highly resource intensive parallel comparisons, which require replication across each single bank, make the implementation extremely inefficient in terms of resource requirements and thus infeasible. Each comparison requires reading and comparing the data required for the comparison. When done in parallel in a highly associative CAM, even if each data field read is small (e.g., 16, 20 bits), a large number of bits are needed for reading and very frequent comparisons are made to determine a match. The present inventors provide a microarchitecture that can take advantage of lower event rates that need to be handled at each bank level in a more resource efficient manner to make deterministic row hammer mitigation feasible in a memory controller.

Although described above with the potential for higher costs, especially for deterministic row hammer detection that requires highly correlated comparisons, the exemplary embodiments implement row hammer detection at the rank-group level, which necessarily means more if replicated somewhere else. The present disclosure describes practical implementations of modified "space saving" algorithms that require neither CAM nor full magnitude searches of detector states. Indeed, in some embodiments, the disclosed row hammer detector implementations use single port SRAM and a relatively small number of temporary states. As a derivative of the "space saving" algorithm, the disclosed row hammer detection methods and apparatus provide for a proven thorough, accurate, and precise row hammer event detection. The cost and equivalence of its perfect tracking enables all row hammer detection to be performed within or in parallel with the memory controller, rather than all row hammer detection being performed within or partially within the memory media device. The high accuracy of the disclosed row hammer detector minimizes row hammer response rates and thus minimizes systematic performance impact of row hammer situations and attacks.

In fact, when compared to the implementation described in fig. 5 using CAMs that allow extremely fast parallel searches but are costly and consume a large amount of power, the exemplary embodiment employs the basic idea of the space saving algorithm described by Mei Tewa, modified and used in process 500, breaks the highly associative comparison and search operations across time, makes the amount of searches performed for each row of access requests smaller in total (e.g., performs fewer read and compare operations), and on a per bank basis, the smaller the amount of searches, the slower the execution speed. The exemplary embodiment exploits the fact that: the event rate at the rank level at a particular rank is much lower than the global event rate. Rather than performing an associative lookup, the exemplary embodiment performs a serialized search (sequential search) on the aggressor rows using the time obtained from processing a smaller number of events per time interval (as compared to performing operations at the global level).

Thus, rather than looking at all thousands of row counters at the same time, in practice the exemplary embodiment looks at the first row, then the second row, then the third row, the fourth row, etc., until the last row in the row group is counted. The lower event rate at the rank group level permits serial searches to be performed at each rank group instead of the parallel searches shown in fig. 5. Furthermore, since the search may terminate when a match is found, only half of the comparisons typically required in parallel operations need to be performed on average, and thus only half of the power requirements are required. In addition, since the row counters are searched one at a time, the complexity of the circuitry may be substantially less, saving even more power and area. Thus, the exemplary embodiments provide a more practical way of performing row hammer mitigation.

Fig. 7 shows a flowchart of a row hammer mitigation process 700 and associated tables 724 and 726, according to some example embodiments. Process 700 may be implemented in each row of group row hammer mitigation elements 132. Accordingly, in memory controller 100, a respective each of the bank row hammer mitigation components 132 corresponding to each of the bank connected to the attached media device 126 will have its own circuitry to perform process 700 independently. For example, fig. 4 shows a respective per-row group row hammer mitigation component 132 for each of a plurality of row groups in a channel.

Process 700 may begin at operation 702, during which tables and metadata associated with row hammer mitigation are initialized. The counter table has an initial state and, furthermore, the counter table must be periodically cleared. In some embodiments, this operation may be triggered/initiated in response to a ping-pong reset operation of the memory device 126 at respective refresh (tREF) intervals. Resetting clears all counters in the modified space saving algorithm mechanism.

At operation 704, an incoming memory medium access request (row access request) is received for a particular row of memory devices 126 attached to the memory controller 100. The requested line may be referred to as an invader line.

At operation 706, the media line ID table 724 is searched for the line ID of the aggressor line. The media line ID table 724 and the ACT count table 726 collectively contain a counter state to track the number of accesses to a line of the media device 126.

Tables 724 and 726 are separate tables that may be formed in separate SRAM devices, such as SRAM 134. In some embodiments, table 724 is formed in a first single-port SRAM device and table 726 is formed in a second single-port SRAM device. Tables 724 and 726 contain row address and counter information for the most recently accessed row. For each counter 1 … n maintained by the row hammer mitigation process 700, the row address (row ID) is in table 724 and the corresponding count is in table 726. Tables 724 and 726 maintain counters, such as shown in FIG. 6. The search for the aggressor row ID may be performed consecutively in table 724. For example, a loop operation may be used for searching in the table 724 SRAM. In some embodiments, the comparison of the row ID to the minimum may be performed using D flip-flop circuitry. The use of lower cost SRAM for most state stores in process 700 enables a more power efficient serial search than the higher cost CAM and less power efficient associated search for the CAM required by process 500.

At operation 708, a determination is made as to whether an aggressor row ID is found in table 724.

If an aggressor row ID is found in table 724, at operation 710, a corresponding count value is determined from table 726. For example, in a search performed in table 724 at operation 706, an index is determined that finds the location in table 724 for the aggressor row ID, and table 726 with the same index may be accessed to determine the count value corresponding to the counter in table 724 containing the aggressor row ID.

The state maintained for the last modified column is updated. At operation 712, the count value obtained in operation 710 is compared to a pre-configured row hammer threshold to determine whether the count value corresponding to the aggressor row ID exceeds RHT. Thus, this operation determines that an aggressor row has been accessed multiple times, which now or soon (e.g., in 1 or more accesses) will potentially damage an adjacent row.

If it is determined at operation 712 that the aggressor row access number has been greater than RHT, then at operation 714 a response, such as a signal (e.g., DRFM command) to instruct the memory device to refresh the victim row of the identified aggressor row, is transmitted to the memory device. In some embodiments, the memory device includes circuitry to receive an aggressor row ID and refresh the victim row in response. In some embodiments, the response may identify a victim row to refresh.

During operation 714, the count value corresponding to the aggressor row ID is set to 0 because the victim row of the aggressor row has been refreshed in response to the transmitted response.

In some embodiments, a flag associated with the aggressor row counter in table 726 is additionally set to indicate that the aggressor row ID is "reserved" in association with the counter value being refreshed. In some embodiments, the flag may be a bit referred to as a "sticky bit" that indicates that the aggressor row ID is reserved when set (e.g., set to 1), and thus should not be considered in the selection of the minimum count value in operations 720 (and/or 706) described below. Thus, the sticky bits enable the initialization of a subsequent newly inserted row based on the minimum count value in table 726 while ignoring recently refreshed rows that may have disproportionately low count values compared to most other rows in the table.

If it is determined at operation 712 that the number of accesses to the aggressor row has not exceeded RHT, then at operation 716 the count value corresponding to the aggressor row ID is incremented.

After either operation 714 or 716, the process 700 proceeds to operation 704 to await the next row access request.

If at operation 708, the aggressor row ID is not found in table 724, then the aggressor row ID must be assigned a counter, or in other words, the aggressor row ID must be inserted into tables 724-726. Thus, at operation 718, a determination is made as to whether table 724 is currently full. Which is determined by checking whether the global minimum count in table 726 is greater than 0. It should be noted that in embodiments where sticky bits are associated with rows in state tables 724-726, it is contemplated that rows having their sticky bit sets are reserved and therefore excluded from consideration of the minimum count value in determination table 726.

During a previously completed operation 706, table 724 is concurrently searched for the incoming row ID, and table 726 is optionally searched for the first unreserved minimum in the last modified column. These two searches may be performed simultaneously because, in some embodiments, tables 724 and 726 are separate tables each formed in separate single port SRAMs.

If it is determined at operation 718 that the global unreserved minimum is greater than 0 (i.e., table 724 is full (i.e., no unreserved/unallocated counters are available)), then at operation 720, an aggressor row ID is entered into table 724 and an associated count update is made in table 726. In an embodiment, the counter with the smallest count value is identified in table 726 and the corresponding counter in table 724 is updated (i.e., the existing row ID/address is overwritten with the aggressor row ID/address). The corresponding count value in table 726 is incremented. For example, the count value may be incremented by setting the count value to a global minimum +1.

In this operation, the states maintained for the unreserved global minimum and the last modified column may be set according to the updated counter.

If it is determined at operation 718 that the global unreserved minimum is not greater than 0 (i.e., table 724 is not full (i.e., unreserved/unallocated counters are available)), then at operation 722 an aggressor row ID is inserted into table 724 and an associated count update is made in table 726. In an embodiment, the aggressor row ID is inserted into table 724 at the location of the first global 0, and the corresponding count value in table 726 is set to 1.

The state maintained for the last modified column is updated.

After any of operations 714, 716, 722, and 720, process 700 returns to operation 704 to await the next incoming row access.

In some embodiments, some or all of operations 702-722 may be performed by detector circuitry 133 of each row of group row hammer mitigation component 132, with a majority of the required states maintained in SRAM tables 724-726 and in d-flip-flops, as shown in fig. 10.

Fig. 8 shows a flow chart of a process 800 that provides techniques to initialize tables and metadata, such as the row hammer mitigation technique described in operation 702 with respect to process 700.

At operation 802, in an exemplary embodiment performed in lieu of operation 702, a flag is set that indicates that the ACT count is to be cleared after the next incoming media line ID (e.g., a line access request for a line ID). This operation may be triggered/initiated based on a ping-pong reset at each tREF interval. In some embodiments, the flag may be set using D flip-flop circuitry.

At operation 804, an incoming intruder row ID is received, as in operation 704 in process 700. For example, a row access request for an aggressor row ID is received.

In response to receiving the aggressor row ID, a determination is made at operation 806 as to whether a flag is set that indicates that the ACT count is to be cleared after the next incoming media row ID.

If the flag is set, at operation 810, table 724 is updated by writing the aggressor row ID and setting the corresponding count value in table 726. In an embodiment, the aggressor row ID is written to row 0 in table 724, column 0, row 0 in table 726, the corresponding count at column 0 is set to 1, and all columns in table 726 except column 0 of counted row 0 are cleared (written) to 0.

In addition, in this operation, other actions are performed, such as clearing the last modified column (//0 represents column 1), clearing all columns of the minimum unreserved count value, clearing all columns of the minimum unreserved count row, and setting column 0 of the minimum unreserved count row to '1'.

In some embodiments, while some of the table updates may be performed in SRAM (e.g., set row 0, column 0, and clear all columns except column 0, as described above), some of the other operations may be performed in D flip-flops (e.g., clear the last modified column, clear the column of the minimum unreserved count value, clear all columns of the minimum unreserved count row, and set column 0 of the minimum unreserved count row).

Following operation 810, in operation 812, the "count" and "reserved" in all columns of all rows in the ACT count table except row 0 (row 1) may be cleared (written to '0'). In some embodiments, this may be performed by cycling through the SRAM.

In operation 806, when it is determined that the flag is not set at operation 808, the update loop (e.g., operations 706, 708, 710, 712, and 724) and/or the insertion of the incoming lines (e.g., 706, 708, 718, 720, and 722) described with respect to process 700 is performed.

After either operation 808 or 812, the process 800 proceeds to operation 804 to wait for the next incoming row ID.

According to some embodiments, some operations of processes 700 and 800 may be performed in SRAM (e.g., search counter state tables 724 and 726), and some operations may be performed in D flip-flops. This ability to selectively utilize SRAM and D flip-flops to maintain portions of the desired state information allows for an efficient implementation.

An SRAM implementation of the "space saving" algorithm as implemented in process 700 and optionally in process 800 is possible because neither the "update loops" (operations 706-716) nor the "insert incoming rows" (operations 718-722) need to read and write the media row ID or ACT count table at the same time.

FIG. 9 graphically illustrates an example timeline for a group of media lines of a process 700, in accordance with some embodiments. Fig. 9 illustrates that the process 700 may present a chronological manner upon receipt of an incoming row access request: an equal search of the portion of the memory array may be performed in table 724 and a minimum search of the portion of the array performed in table 726. As illustrated in timeline 902, a portion of the insert new row operation may be performed in parallel with the update cycle operation. In particular, the peer search of the matching row in table 724 performed for the update cycle operation and the search of the minimum count in table 726 as part of the insert new row operation may be performed in parallel with each other.

This parallel search operation reduces the time required for process 700 and is made possible by having the row ID in a separate table from the count value of the counter. This parallel search capability is critical in terms of making process 700 feasible for efficient operation within the time constraints required for row hammer mitigation. These parallel operations may be followed by the minimum search required to insert an incoming row in tables 724 and 726 when the incoming row is not found in the table and when the table is full. As illustrated, these operations are completed within the interval between two consecutive refresh operations (e.g., row cycle time (tRC) =60 ns-90 ns).

Thus, while an embodiment requires the insertion of an incoming row at the current minimum, an embodiment is arranged such that after an equal search, only the portions of operations required to determine the minimum and insert the row need be performed sequentially. The second portion of the minimum search may begin in parallel with or shortly after the tail end of the first minimum search, such that all but not the last modified column is checked in parallel with the peer search.

tRC is a DRAM timing constraint or metric. And tRC is the time interval between the activation times of the switches between one row and another in the same bank.

The schedule 904 shows that, for example, in process 700, all counts are cleared prior to insertion of the initial media line.

Fig. 10 illustrates an example of a state associated with process 700, according to some embodiments. In addition to tables 724 and 726, the states maintained in some embodiments may also include a minimum unreserved count value 1002, a minimum unreserved count row 1004, an incoming media row ID 1006, an incoming media row location 1008 in the table, a most recently modified column 1010, a global minimum unreserved count value 1012, a global RHT 1016, an ACT count 1018 of an incoming row ID, a clear ACT count 1020 after a next incoming row ID, a number of response signals (e.g., DRFM) 1022 sent in tREF, a number of accumulated response signals sent (e.g., DRFM) 1024, a counter reservation 1026, and a counter reservation host notification threshold 1028. In some embodiments, tables 724 and 726, which include a substantial portion of the states required for processes 700 and 800, are maintained in SRAM that is significantly more efficient in area and power than other state memories, such as d-flip-flops, which may store states 1002-1026. The states shown in fig. 10 are examples, and some example embodiments may maintain more or fewer states than shown. For example, in some embodiments, states 1010-1014, 1022-1028, and/or 1020 may not be maintained.

Any counter-based logic needs to be reset. Because different memory media lines are refreshed at different internal media determination times, the ideal time to reset the external counter for a particular media line may be configurable or determined at the start-up time. Periodic ping-pong resets are possible secure counter resets when paired counters are used in a ping-pong scheme. The time between resets of any particular counter may be configurable, and in some embodiments is, for example, 128ms (2 xtREF). According to an embodiment, during the first tREF period, the ACT counter is in a preconditioned state, wherein the ACT counter is counting but not transmitting DRFM. During the next tREF period, the ACT counter triggers a DRFM command or other row hammer response while counting.

The second set of ACT counters operates similarly, but is offset tREF from the first set of ACT counters. A set of ACT counters is always active to trigger the DRFM command.

This approach eliminates false negative DRFM triggers. However, this approach requires two sets of counters, which means twice the silicon area and power. Furthermore, there are potential DRFMs to send based on counts from 2x tREF.

Fig. 11 illustrates a schematic diagram of a shuttle reset circuit 1100 in accordance with some embodiments. The external clock serves as an input to the circuit 1100. Based on the input clock, the 0-tREF counter 1102 generates a pulse per tREF (e.g., 64 ms). Based on the pulse from the counter 1102, the flip-flop 1104 toggles the output between 0 and 1 every tREF. When ACT counter B1108 becomes active (i.e., DRFM can be triggered), ACT counter a 1106 is reset and vice versa.

Both ACT counter a 1106 and ACT counter B1108 always receive and count all memory media line Activations (ACTs). When ACT counter a and ACT counter B reach the memory medium RHT count, they trigger DRFM (or other row hammer mitigation response), but based on the state of trigger 1104, only one of the "active" ACT counters may trigger DRFM, the other ACT counters being ignored. Component 1110 generates a DRFM to a memory media controller for transmission to a memory device.

Thus, as described above, in some embodiments, process 700 is implemented separately for each media rank group, allowing enough time for global equivalence and magnitude comparison of processes to be performed sequentially on small subsets of their states. The implementation of process 700 at media rank granularity enables replacement of the CAM for global row ID equal comparison in the "update cycle" of process 500 with a universal single port SRAM.

By performing partial minimum searches in parallel with or as part of sequential implementations of the update cycle and completing the aggregate magnitude search only within the "insert incoming row" program, magnitude comparisons to find global minimum count values in the "insert incoming row" program can be implemented in a similar manner as a general purpose single port SRAM.

The SRAM implementation of the state body required for the space saving algorithm makes the space saving algorithm feasible for use in row hammer detection. The SRAM implementation of the body of the state required by the space saving algorithm makes it feasible to perform row hammer detection within the controller for a large number of memory media, and in turn enables row hammer detection functions to be removed from the controlled memory media, simplifying and reducing the cost and power consumption of the memory media.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

It should be noted that the above-described methods describe possible implementations, and that the operations and steps may be rearranged or otherwise modified, and that other implementations are possible. Furthermore, two or more parts from the methods may be combined.

Any of a variety of different technologies and techniques may be used to represent the information and signals described herein. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Some figures may illustrate signals as a single signal; however, the signals may represent buses of signals, where the buses may have various bit widths.

The terms "transmit," "connect," and "couple" may refer to the relationship between components that support signal flow between the components. Components are considered to be in electronic communication with each other (or in conductive contact with each other, or connected to each other, or coupled to each other) if there are any conductive paths between the components that can support the flow of signals between the components at any time. At any given time, the conductive paths between components in electronic communication with each other (or in conductive contact with each other, or connected to each other, or coupled to each other) may be open or closed based on the operation of the device containing the connected components. The conductive paths between connected components may be direct conductive paths between components or the conductive paths between connected components may be indirect conductive paths that may include intermediate components such as switches, transistors, or other components.

In some examples, signal flow between connected components may be interrupted for a period of time, for example, using one or more intermediate components, such as switches or transistors. The term "coupled" refers to the condition of moving from an open circuit relationship between components, in which signals are not currently able to pass between components via conductive paths, to a closed circuit relationship between components, in which signals are able to pass between components via conductive paths. If a component, such as a controller, couples other components together, the component initiates the following changes: allowing signals to flow between other components via conductive paths that previously did not permit signal flow.

The terms "if," "when …," "based on," or "based at least in part on" are used interchangeably. In some examples, the terms are interchangeable if the terms "if," "when …," "based on," or "based at least in part on" are used to describe a conditional action, a conditional process, or a connection between portions of a process.

The term "responsive to" may refer to a condition or action that occurs at least partially, if not completely, as a result of a prior condition or action. For example, a first condition or action may be performed and a second condition or action may occur at least in part as a result of a previous condition or action occurring (whether directly after the first condition or action or after one or more other intermediate conditions or actions occurring after the first condition or action).

In addition, the term "directly responsive" or "directly responsive" may refer to a condition or action that occurs as a direct result of a prior condition or action. In some examples, a first condition or action may be performed and a second condition or action may occur directly as a result of a previous condition or action occurring independent of whether other conditions or actions occur. In some examples, a first condition or action may be performed and a second condition or action may occur directly as a result of a previous condition or action occurring such that no other intermediate condition or action occurs between the earlier condition or action and the second condition or action, or a limited number of one or more intermediate steps or actions occur between the earlier condition or action and the second condition or action. Any condition or action described herein as being performed "based on," "at least in part on," or "in response to" some other step, action, event, or condition may additionally or alternatively (e.g., in alternative examples) "be performed in direct response" or "directly in response to" such other condition or action, unless otherwise specified.

The devices discussed herein, including memory arrays, may be formed on semiconductor substrates such as silicon, germanium, silicon-germanium alloys, gallium arsenide, gallium nitride, and the like. In some examples, the substrate is a semiconductor wafer. In some other examples, the substrate may be a silicon-on-insulator (SOI) substrate, such as silicon-on-glass (SOG) or silicon-on-Sapphire (SOP), or an epitaxial layer of semiconductor material on another substrate. The conductivity of the substrate or sub-regions of the substrate may be controlled by doping with various chemicals including, but not limited to, phosphorus, boron, or arsenic. Doping may be performed by ion implantation or by any other doping method during the initial formation or growth of the substrate.

The description set forth herein in connection with the appended drawings describes example configurations and is not intended to represent all examples that may be practiced or that are within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration," and not "preferred" or "advantageous over" other examples. The detailed description contains specific details to provide an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described examples.

The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software that is executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired or a combination of any of these. Components that perform the functions may also be physically located at various locations including distributed such that the portions of the functions are performed at different physical locations.

For example, the various illustrative blocks and components described in connection with the disclosure herein may be implemented or performed with the following components designed to perform the functions described herein: a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general purpose processor may be a microprocessor; but, in the alternative, the processor may be any processor, controller, microcontroller, or state machine. A processor may be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

As used herein, an "or" as used in an item list (e.g., an item list beginning with a phrase such as "at least one of …" or "one or more of …") indicates an inclusive list such that a list of at least one of A, B or C refers to a or B or C or AB or AC or BC or ABC (i.e., a and B and C). In addition, as used herein, the phrase "based on" should not be understood to refer to a set of closed conditions. For example, exemplary steps described as "based on condition a" may be based on both condition a and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" should be interpreted in the same manner as the phrase "based at least in part on".

Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Non-transitory storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, non-transitory computer-readable media can comprise RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compact Disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium.

For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes CD, laser disc, optical disc, digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" may include both a single indicator and a plurality of indicators unless the context clearly dictates otherwise. In addition, "plurality," "at least one," and "one or more" (e.g., a number of memory banks) may refer to one or more memory banks, while "plurality" means more than one such thing.

Furthermore, the word "can/make" is used throughout this application in a permissive sense (i.e., having the potential to, being able to), rather than the mandatory sense (i.e., must). The term "include" and its derivatives mean "include, but are not limited to. Depending on the context, the term "coupled/coupled" means physically directly or indirectly connecting or accessing and moving (transmitting) commands and/or data. The terms "data" and "data value" are used interchangeably herein and may have the same meaning, depending on the context.

The description herein is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (20)

1. An apparatus, comprising:

at least one static random access memory, SRAM, comprising a plurality of counters, each counter comprising a row identifier and a count, and a total number of counters in the plurality of counters being less than a total number of rows monitored by a memory error detector in a memory media device; and

Circuitry configured to perform operations comprising:

identifying whether a line identifier of a memory media access request is in the plurality of counters;

updating the count of the counter corresponding to the row identifier of the plurality of counters when the row identifier of the memory media access request is identified in the plurality of counters, and triggering a response to an error in the memory media device if the count exceeds a predetermined threshold; and

when the line identifier of the memory medium access request is not identified in the plurality of counters, the counter of the plurality of counters is updated to include the line identifier of the memory medium access request.

2. The apparatus of claim 1, configured to monitor all rows of one of a plurality of banks of the memory media device.

3. The apparatus of claim 1, wherein the SRAM comprises a plurality of single port SRAMs.

4. The apparatus of claim 1, wherein the plurality of counters comprises a first table comprising the row identifiers and a second table comprising respective counts associated with each row identifier in the first table.

5. The apparatus of claim 4, wherein the identifying whether the row identifier of the memory medium access request is in the plurality of counters comprises searching the first table to determine whether a matching entry for the row identifier of the memory access request is present in the first table.

6. The apparatus of claim 5, wherein the search is a serial search of the first table.

7. The apparatus of claim 5, wherein the updating the counter of the plurality of counters to include the row identifier comprises:

identifying a minimum count in the second table and inserting the row identifier into the first table in a location corresponding to the identified minimum count in the second table; and

incrementing the identified minimum count in the second table.

8. The apparatus of claim 7, wherein the identifying a minimum in the second table is performed at least partially concurrently with the searching the first table.

9. The apparatus of claim 7, wherein the identifying a minimum value in the second table includes considering a sticky bit associated with each count value in the second table.

10. The apparatus of claim 1, wherein the operation provides deterministic detection of a row hammer attack on the memory media device.

11. The apparatus of claim 1, wherein the memory media device is a dynamic random access memory DRAM, and wherein respective banks correspond to a plurality of rows in the DRAM.

12. The apparatus of claim 1, wherein the circuitry is further configured to clear the plurality of counters in each refresh interval of the memory media device.

13. The apparatus of claim 1, wherein the response comprises a digital refresh management DRFM command to refresh one or more physically adjacent rows of rows corresponding to the row identifier.

14. A method, comprising:

identifying, by circuitry, whether a row identifier of a memory media access request is in a plurality of counters stored in at least one static random access memory, SRAM, wherein each counter of the plurality of counters comprises a row identifier and a count, and a total number of counters of the plurality of counters is less than a total number of rows monitored by the circuitry in a memory media device;

updating the count of the counter corresponding to the row identifier of the plurality of counters when the row identifier of the memory media access request is identified in the plurality of counters, and triggering a response to an error in the memory media device if the updated count exceeds a predetermined threshold; and

When the line identifier of the memory medium access request is not identified in the plurality of counters, the counter of the plurality of counters is updated to include the line identifier of the memory medium access request.

15. The method of claim 14, wherein the plurality of counters comprises a first table comprising the row identifiers and a second table comprising respective counts associated with each row identifier in the first table, and wherein determining whether the row identifier of the memory medium access request is in the plurality of counters comprises searching the first table to determine whether a matching entry for the row identifier of the memory access request is present in the first table.

16. The method of claim 15, wherein the updating the counter of the plurality of counters to include the row identifier comprises:

identifying a minimum count in the second table and inserting the row identifier into the first table in a location corresponding to the identified minimum count in the second table; and

incrementing the identified minimum count in the second table.

17. A memory controller, comprising:

a first interface to a host system;

a second interface coupled to a memory media device, wherein the second interface comprises a plurality of physical interfaces to the memory media device, and each of the physical interfaces corresponds to a respective channel having a plurality of banks;

a plurality of devices, each device comprising:

at least one static random access memory, SRAM, comprising a plurality of counters, each counter comprising a row identifier and a count, and a total number of counters in the plurality of counters being less than a total number of rows monitored by the devices in the memory media device; and

circuitry configured to perform operations comprising:

identifying whether a line identifier of a memory media access request is in the plurality of counters;

when the row identifier of the memory medium access request is identified in the plurality of counters,

updating the count of the counter corresponding to the row identifier in the plurality of counters and triggering a response to an error in the memory media device if the updated count exceeds a predetermined threshold; and

When the line identifier of the memory medium access request is not identified in the plurality of counters, the counter of the plurality of counters is updated to include the line identifier of the memory medium access request.

18. The memory controller of claim 17, wherein each of the devices is configured to monitor all rows of a respective bank of the plurality of banks.

19. The memory controller of claim 17, wherein the plurality of counters comprises a first table including the row identifiers and a second table including respective counts associated with each row identifier in the first table.

20. The memory error detector of claim 1, wherein the operation provides deterministic detection of a row hammer attack on the memory media device.