Semiconductor memory device with per-channel alerting of row

Abstract

The invention relates to a semiconductor memory device with per-channel alert of a row of hammering attacks. Methods, systems, and apparatus are disclosed for providing a per-lane row hammer alert from a memory device to a host without the use of a dedicated per-lane alert interface. When a row hammer alert condition is detected, the memory device may determine whether an existing interface (e.g., a severity interface for communicating severity information) is available. The interface may be available outside certain specified burst locations during a read burst. Once the interface is available, the memory device may transmit a row hammer alert indication to the host. The host may determine whether information received through the interface is associated with a row hammer alert or severity, depending on when the information is received (e.g., which burst position is in during a read burst).

Description

Technical Field

[0001] The present disclosure relates generally to a memory device, and more particularly to a memory device that enables alerting a host to a large number of row hammer attacks on individual channels of the memory device. Background Art

[0002] Memory devices are widely used to store information associated with various electronic devices such as computers, wireless communication devices, cameras, digital displays, etc. Memory devices can be volatile or non-volatile and can be of various types, such as magnetic hard disks, random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), etc. Information is stored in various types of RAM by charging memory cells to have different states. Improving RAM devices can generally include increasing memory cell density, increasing read / write speeds or otherwise reducing operating delays, increasing reliability, increasing data retention, reducing power consumption, or reducing manufacturing costs, among other criteria. Summary of the invention

[0003] In one aspect, the present disclosure provides a high bandwidth memory (HBM) device comprising: a plurality of channels coupled to a host, each channel being associated with a command / address bus and a severity bus; and a plurality of vertically stacked memory dies, each of the memory dies comprising: one or more memory groups, each memory group being associated with one of the plurality of channels; one or more interfaces, each interface being associated with a channel from the plurality of channels, the channel being associated with a memory group of the one or more memory groups; and a row hammer alert circuit configured to: detect a row hammer attack on a memory group of the one or more memory groups; determine whether the severity bus of the channel associated with the memory group is transmitting severity information; and transmit a row hammer alert via the severity bus when the severity bus of the channel associated with the memory group is not being used to transmit severity information.

[0004] In another aspect, the present disclosure further provides a memory device comprising: a memory array including a plurality of rows of memory cells; a row hammer mitigation circuit configured to determine whether to perform a mitigation action on a row of the plurality of rows; and a row hammer warning circuit configured to: generate a row hammer warning; and transmit the row hammer warning through a severity interface of the memory device.

[0005] In yet another aspect, the present disclosure further provides a method, comprising: receiving, by a memory controller, data from a high bandwidth memory (HBM) device coupled to the severity interface through a severity interface; determining whether the data is associated with severity information or row hammer warning information; if the data is associated with row hammer warning information, evaluating the data to determine whether a row hammer warning is indicated; and suspending requests transmitted to the HBM device through a command / address interface associated with the severity interface based on the determination indicating a row hammer warning. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present disclosure will be more fully understood from the detailed description given below and the accompanying drawings of various embodiments of the present disclosure.

[0007] Figure 1 A simplified block diagram is described that schematically illustrates a memory device in accordance with an embodiment of the present technology.

[0008] Figure 2 A simplified block diagram is described that schematically illustrates a high bandwidth memory device in accordance with an embodiment of the present technology.

[0009] Figure 3 Severity interface encoding according to an embodiment of the present technology is described.

[0010] Figure 4 is a flow chart illustrating a process for alerting a hammer attack according to an embodiment of the present technology.

[0011] Figure 5 is a block diagram of an example computer system according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0012] High data reliability, high memory access speed, lower power consumption and reduced chip size are features required for semiconductor memory. In recent years, three-dimensional (3D) memory devices have been introduced. Some 3D memory devices are formed by vertically stacking memory dies and interconnecting the dies using through-silicon (or through-substrate) vias (TSVs). The benefits of 3D memory devices include shorter interconnects (which reduces circuit delays and power consumption), a large number of vertical vias between layers (which allows for wide bandwidth buses between functional blocks such as memory dies in different layers), and significantly smaller footprints. Therefore, 3D memory devices contribute to higher memory access speeds, lower power consumption and reduced chip size. Example 3D memory devices include hybrid memory cubes (HMCs) and high bandwidth memories (HBMs). For example, HBM is a vertically stacked memory including a DRAM die and an interface die (which, for example, provides an interface between the DRAM die of the HBM device and a host device).

[0013] Some semiconductor memory devices used in 3D memory devices (including HBM devices), such as DRAM, store information as charge accumulated in cell capacitors, which can be susceptible to leakage and therefore require periodic refresh operations to prevent information loss. In addition to charge leakage, information can be lost or degraded due to bit errors caused by disturbance mechanisms such as row hammering (e.g., repeated access to the same storage location or row within a threshold duration). Row hammering affects memory cells coupled to unselected word lines adjacent to a selected word line that is repeatedly driven to an active level within a short period of time. Unless a refresh operation is performed to refresh the charge in the memory cells, activity on the selected word line can cause the charge in the cells of the adjacent unselected word lines to change, thereby putting the information stored therein at risk.

[0014] In some memory devices, an automatic refresh (AREF) command instructing a refresh operation is periodically issued from a control device, such as a host or a controller operably coupled to the memory device. The AREF command is provided from the control device at a certain frequency so that all word lines will be refreshed once in a refresh cycle. However, since the refresh address according to the AREF command is determined by a refresh counter provided in the DRAM, the refresh operation in response to the AREF command may not prevent bit errors caused by the row hammering effect. Therefore, the memory device may include an additional capability to address the row hammering effect.

[0015] A method for addressing row hammering effects involves providing a memory device with circuitry to redirect or preempt a portion of available refresh opportunities (e.g., regularly scheduled refresh commands received from a host device) to specific victim rows (e.g., adjacent to a row where a large number of activate commands have been executed) where hammering activity has been detected. For example, the row hammering mitigation circuitry may count the number of times a row has been activated since a previous refresh of an adjacent victim row. If the row activation count exceeds a threshold number, the row hammering mitigation circuitry may initiate a refresh of the adjacent victim rows to address the row hammering effects on those rows. For example, the row hammering mitigation circuitry may add the row address of the victim row to a refresh operation queue (otherwise referred to as a mitigation queue) so that the victim row is refreshed.

[0016] Memory devices and row hammer mitigation circuits may employ different methods to count the number of row activations since the last refresh. For example, some devices may employ a probability-based method in which row addresses are randomly sampled during activation, and if any row address is sampled too frequently and / or sampled greater than a threshold number of times during a sampling window, the adjacent victim row is refreshed. As another example, some memory devices may employ per-row hammer tracking (PRHT) in which an activation counter bit is stored in each row of the memory array of the memory device. In the case of PRHT, each time a row is activated, the activation counter bit may be incremented and written back to the memory array, and once the counter exceeds a threshold, the adjacent victim row is refreshed.

[0017] In certain memory devices, such as those that employ PRHT and / or random sampling of activated row addresses, the thresholds used to determine whether to refresh a victim row may be fixed and / or statically configured (e.g., based on memory device characteristics and the sensitivity of neighboring victim rows to row hammering effects). As a result, the memory device and row hammering mitigation circuitry may have deterministic behavior in which refresh operations are predictably generated for the victim row after sufficient activations of neighboring rows. Furthermore, as memory array geometries continue to decrease and sensitivity to row hammering effects correspondingly increases, the threshold number of neighboring row activation commands that may be allowed to occur before a victim row is refreshed continues to decrease. These factors may enable an adverse actor to exploit the row hammering effect and the deterministic operation of the row hammering mitigation circuitry to intentionally overwhelm a memory device with targeted row hammering activity, thereby producing a deleterious effect (e.g., data degradation in the memory array).

[0018] In one such attack, which is generally referred to as a waterfall attack, multiple victim rows in an array are targeted by row hammering activity (e.g., by activation commands directed to one or more rows adjacent to the victim rows) to bring the count of adjacent row activations close to but still below a threshold number that will trigger a targeted refresh of the victim rows. Once a sufficiently large number of such victim rows are so stimulated, the attack involves targeted activation of adjacent rows, thereby pushing a large number of victim rows above the threshold number in a short period of time. Typically, a memory device so attacked will respond by adding all victim rows to a refresh operation queue (e.g., a mitigation queue). By doing so, any of several undesirable results may occur. For example, if the number of victim row addresses to be added to the mitigation queue exceeds the capacity of the mitigation queue, once the queue capacity is reached, the memory device may omit adding the victim row address to the mitigation queue. In such a scenario, the victim rows omitted from the mitigation queue may experience a change in value (e.g., a bit flip in the data may occur), resulting in a memory device error. As another example, even if the mitigation queue has the capacity to add all victim rows, in the time it takes to complete corresponding refresh operations for all victim row addresses in the mitigation queue, additional activation commands may continue to hammer the same set of victim rows, causing their contents to potentially be degraded before being refreshed (e.g., due to their position in the mitigation queue).

[0019] To address undesirable results caused by row hammer attacks and / or waterfall attacks (collectively referred to as "row hammer attacks" or "attacks"), it may be advantageous for a memory device to be able to signal a host when the memory device is under attack. For example, and as described herein, a memory device may generate an alert signal when a threshold number of rows are excited for attack (e.g., sufficient rows each have an activation count that is close to but still below the number that would trigger a refresh of an adjacent victim row), when a mitigation queue is at a threshold utilization (e.g., the queue is filled to a certain number of victim row addresses to be refreshed and / or the queue contains a certain number of victim row addresses associated with a portion of the memory array), and / or in response to other conditions that may generally result in loss and / or alteration of stored data. The host, upon receiving the alert signal, may pause or slow the rate of requests to the memory device, thereby giving the memory device additional time to respond to the attack. For example, if the host suspends sending new read and / or write requests to the memory device while the alert signal is active, the memory device can refresh the already identified victim rows before the victim rows are activated again and / or additional rows become victim rows. Once the memory device successfully responds to the attack (e.g., enough victim rows are refreshed), the memory device can de-assert the alert signal and normal operation can be resumed.

[0020] In some memory systems, a single alert signal may be used to indicate a row hammer attack on any of a plurality of memory devices. For example, some memory systems include one or more memory modules (e.g., dual in-line memory modules or DIMMs), each of which includes a plurality (e.g., 10 or more) of memory devices (DRAM dies, DRAM devices, etc.). Some memory modules (e.g., DIMMs conforming to certain versions of the double data rate (DDR) SDRAM standard (e.g., DDR5)) have a single alert signal between them and a host that is asserted when any memory device on the memory module is subjected to a row hammer attack. In the memory module, each memory device may have an alert pin through which an alert signal may be transmitted (e.g., when a memory array of a memory device is subjected to a row hammer attack), and all of the alert pins are combined (e.g., ORed together) to generate a module alert signal that is transmitted to the host.

[0021] However, due to the differences between 3D memory devices and other types of memory devices (e.g., DDR5 DIMMs), signaling a row hammer attack to the host may present certain challenges in a memory system that includes a 3D memory device such as an HBM device. An HBM device consists of multiple channels, each of which provides an independent interface to the host. That is, each channel includes an independent clock, command, data, etc. interface to the host. In addition, each channel provides access to an independent set of storage within the HBM device (e.g., an independent set of DRAM banks), so that a host request on one channel may not have access to storage associated with another channel. In addition, each HBM channel can be further divided into two separate sub-channels or pseudo-channels (PCs) that can operate semi-independently. The two PCs of the channel may share certain portions of the channel interface (e.g., clock, row and column command buses, etc.), but may be independent in other respects. For example, the two PCs may have independent data buses that provide access to different portions of the channel's storage, and commands may be decoded and executed individually. Devices compliant with the HBM3 specification (e.g., HBM3 devices) can support up to 16 independent channels (each of which can be further divided into two PCs), while HBM devices compliant with future specifications can support more channels (e.g., 32 channels, 64 channels, etc.). For example, HBM4 devices can support up to 32 independent channels (and correspondingly 64 PCs). In contrast, DDR5 DIMMs support two channels per DIMM.

[0022] Because HBM devices support a relatively large number of channels, a number that is expected to increase over time, conventional solutions for how HBM devices can alert a host of a row hammering attack may suffer from various shortcomings. Each channel and / or PC of an HBM device can independently detect an alert condition (e.g., a situation in which a sufficient number of rows associated with the channel and / or PC are excited and / or there are a sufficient number of victim rows associated with the channel and / or PC). Therefore, one solution is for the HBM device to have an alert pin for each channel and / or PC, through which the HBM device can signal the alert condition to the host. Such a solution may enable the host to identify the specific channel and / or PC that is under attack and suspend host requests only to that channel / PC while maintaining normal operation with other channels / PCs, but this solution may not be feasible due to the amount of area involved (e.g., an additional 32 alert pins on a 32-channel HBM device) and / or the routing resources required (e.g., between the HBM device and the host, such as through a silicon interposer). An alternative solution is for the HBM device to combine channel / PC specific alert signals into a single alert signal that is transmitted to the host, similar to the approach described above for DDR5. Such a solution may be beneficial from an area and / or routing perspective, but may not be feasible from a performance perspective. For example, if in a memory system with 32-channel HBM devices, the host were to suspend sending any requests to the HBM device (e.g., all 32 channels) if only a single channel is attacked, this would be inefficient.

[0023] Thus, described herein are memory systems, components therein (e.g., memory devices, HBM devices, hosts, and memory controllers), and associated methods that provide per-channel and / or per-PC alert signaling in response to a row hammer attack or associated conditions without using dedicated pins or interfaces. As described herein, per-channel and / or per-PC alert information can be transmitted by overloading existing pins and / or interfaces of a memory system. Advantageously, systems, apparatus, and methods for overloaded per-channel alert signaling can indicate to the host a specific channel (or PC) of a device that is subject to a row hammer attack, thereby enabling the host to maintain normal operation with all other channels (or PCs) without requiring additional pins and / or signal routing between the HBM device and the host. Although described as per-channel alert signaling in some cases, in embodiments of a memory system where channels are divided into PCs, the systems, apparatus, and methods described herein can provide per-PC alert signaling.

[0024] A memory device that provides per-channel alert signaling of overload (which includes an HBM device) can signal the occurrence of a row hammer attack or related conditions through an existing per-channel or per-PC interface between the memory device and a host during a window in which a conventional memory device would not normally use the interface. In some embodiments, a severity interface of an HBM3 device or other HBM device (e.g., an HBM4 device) is used to signal alerts of individual channels or PCs to a coupled host. That is, the HBM device may include a per-PC severity interface through which the HBM device may transmit data indicating the severity of errors detected by on-die error correction code (ECC) processing. For example, an HBM3 device may include two severity (SEV) pins per PC, but embodiments of a memory device that provides per-channel alert signaling of overload may have other numbers of SEV pins per PC and / or per channel.

[0025] As described herein, an HBM device that provides per-channel warning signaling of overload may transmit ECC severity information through the SEV pin only during certain windows. For example, in response to a read request from a host, the HBM device may transmit severity information through the SEV pin when some read data is transmitted by the HBM device to the host. In some embodiments, the read data requested by the host is transmitted by the HBM device over multiple clock cycles and / or clock phases and is referred to as a burst. A portion of the read data may be transmitted by the HBM device during a unit interval (UI), and each UI may occupy one clock cycle, one clock phase, etc. The number of UIs (e.g., the number of clock cycles and / or clock phases) used to transmit the requested read data represents the burst length (BL) of the HBM device, and the burst position represents an ordered sequence during the burst. That is, the first burst position (e.g., burst position 0) represents the first clock cycle and / or phase (e.g., UI0) of the burst, the second burst position (e.g., burst position 1) represents the second clock cycle and / or phase (e.g., UI1) of the burst, and so on. For example, the burst length of an HBM3 device may be 8 (BL8), which means that the read data requested by the host is transmitted by the HBM3 device across 8 burst positions (e.g., UI0-UI7), each burst position being a clock phase. Conventional HBM3 devices transmit severity information via the SEV pin during UI4-UI7 of a read data burst (e.g., when the requested read data is transmitted), and the SEV pin is not used during other burst positions (e.g., UI0-UI3) of the read data transmission. Other HBM devices may have other burst lengths, and similarly transmit severity data via the SEV pin only during some burst positions. For example, in some embodiments, an HBM4 device may have a burst length of up to 32 (BL32), and transmit severity information only during some of the burst positions (e.g., only some of UI0-UI31) of the burst positions where the requested read data is transmitted. In some embodiments, an HBM4 device may be configured for BL8, and transmit severity information during UI4-UI7.

[0026] In an embodiment of a memory system utilizing per-channel alert signaling of overload, a memory device (e.g., an HBM device) transmits alert information indicating a row hammer attack or an associated condition when the SEV pin is not used to transmit severity information. For example, in an HBM3 device configured for BL8 operation, the alert information may be transmitted during any of UI0-UI3, alone or in any combination, during the transmission of read data. As another example, in an HBM4 device configured for BL8 operation, during the transmission of read data, the alert information may be transmitted during any of UI0-UI7, alone or in any combination (and excluding the burst position where the severity information is transmitted). As yet another example, in an HBM4 device configured for BL32 operation, during the transmission of read data, the alert information may be transmitted during any of UI0-UI31, alone or in any combination (and excluding the burst position where the severity information is transmitted). In still further examples, a memory device utilizing overloaded per-channel alert signaling may conform to any version of the HBM specification (e.g., HBM2, HBM3, HBM4, etc.) and may be configured for any burst length (e.g., BL4, BL8, BL16, BL24, BL32, etc.), and may transmit alert information during other burst positions within a burst.

[0027] A memory device that provides per-channel warning signaling of overload may include logic per channel and / or per PC that detects row hammer warning conditions that potentially affect the memory device storage associated with the channel or PC. For example, an HBM device may include logic for detecting when any PC of the HBM device is under attack. In some embodiments, and as described herein, the logic is replicated in the HBM device. For example, each DRAM die within the HBM device may include row hammer warning logic to detect a row hammer attack that affects the PC of the DRAM die. In some embodiments, the row hammer warning logic is replicated for each PC on the DRAM die (e.g., a DRAM die with four PCs will include four instances of row hammer warning logic, a DRAM die with 16 PCs will include 16 instances of row hammer warning logic, etc.). As described herein, the row hammer warning logic may detect conditions indicating that the associated PC is under attack, and it may be beneficial for the host to temporarily suspend sending new requests to the PC and assert the warning signal accordingly. For example, the row hammer alert logic may detect when the number of memory array rows associated with the PC that exceeds a threshold has a per-row activation count (e.g., stored in the row) that is close to exceeding a refresh threshold (e.g., being triggered for refresh), and assert an alert signal accordingly. As another example, the row hammer alert logic may detect when the mitigation queue has a number of victim rows associated with the PC that exceeds a threshold, and assert an alert signal accordingly. As described herein, the row hammer alert logic may then drive the alert signal onto one or more SEV pins associated with the PC when the SEV pins are available (e.g., not being used to transmit severity information as part of a read response from a memory device). Advantageously, the row hammer alert logic may detect conditions indicative of a row hammer attack on individual channels and / or PCs, and may utilize the SEV pins associated with each channel and / or PC to communicate the occurrence of a row hammer attack to a host on a per-channel or per-PC basis without adding a new alert interface and / or alert pin between the memory device and the host.

[0028] In an embodiment of a memory system utilizing per-channel warning signaling for overload, a control device (e.g., a host and / or controller) may be configured to monitor the SEV pin from the memory device outside of a window in which severity information is transmitted. For example, if a conventional host coupled to an HBM3 device monitors the SEV pin of the PC only during UI4-UI7 when data is being transmitted by the HBM3 device, a host according to an embodiment of the described technology may also monitor the SEV pin at other times. In some embodiments, a host providing per-channel warning for overload monitors the SEV pin during other burst positions of read data transmissions. In some embodiments, a host providing per-channel warning for overload monitors the SEV pin even when read data is not being transmitted to the host (e.g., outside of a read burst). In other words, a host providing per-channel warning signaling for overload may monitor the SEV when severity information is conventionally sent (e.g., UI4-UI7 of a read transmission when the host is coupled to an HBM3 device) and additionally monitor the SEV pin when severity information is not conventionally sent to detect a row hammer warning condition. The host may further be configured to detect whether the information transmitted on the SEV pin is severity information or a row hammer alert condition, depending on when the information is transmitted. Advantageously, signaling a row hammer alert condition on a per-PC interface (e.g., SEV pin) enables the host to suspend requests sent to the affected PC while operating normally with other PCs without requiring a new alert interface and / or alert pin between the host and the memory device.

[0029] Figure 1 A simplified block diagram is shown schematically illustrating a memory device 100 according to an embodiment of the present technology. The memory device 100 may be, for example, a semiconductor die assembly including a three-dimensional integrated (3DI) device or a die stack package. The memory device 100 may include a DRAM or a portion thereof including one or more dies / chips. For example, the memory device 100 may be an HBM device including one or more DRAM dies / chips, an interface die, and / or a DRAM die / chip or an interface die within an HBM device.

[0030] Memory device 100 may include an array of memory cells, such as memory array 150. Memory array 150 may include a plurality of groups (e.g., Figure 11-15 in the example of ), and each group may include a plurality of word lines (WL), a plurality of bit lines (BL), and a plurality of memory cells arranged at the intersection of the word lines and the bit lines. The selection of the word lines WL may be performed by a row decoder 140, and the selection of the bit lines BL may be performed by a column decoder 145. A sense amplifier (SAMP) may be provided for the corresponding bit line BL and connected to at least one corresponding local input / output (I / O) line pair (LIOT / B), which in turn may be coupled to at least one corresponding main I / O line pair (MIOT / B) via a transmission gate (TG) that may act as a switch.

[0031] The memory device 100 may employ a plurality of external terminals, including a command terminal and an address terminal coupled to a command bus and an address bus (e.g., a command / address bus) to receive a command signal CMD and an address signal ADDR, respectively. The memory device may further include a chip select terminal for receiving a chip select signal CS, a clock terminal for receiving clock signals CK and CKF, a data clock terminal for receiving data clock signals WCK and WCKF, data terminals DQ, RDQS, DBI (for a data bus inversion function), DMI (for a data mask inversion function), a severity terminal SEV (for severity information and a row hammer warning indication), power supply terminals VDD, VSS, VDDQ, and VSSQ, and an on-die termination terminal ODT.

[0032] The address signal and the group address signal may be supplied to the command terminal and the address terminal from the outside. The address signal and the group address signal supplied to the address terminal may be transmitted to the address decoder 110 via the address / command input circuit 105. The address decoder 110 may receive the address signal and supply the decoded row address signal (XADD) to the row decoder 140 and the decoded column address signal (YADD) to the column decoder 145. The address decoder 110 may also receive the group address portion of the ADDR input and supply the decoded group address signal (BADD) and the group address signal to both the row decoder 140 and the column decoder 145.

[0033] A command signal CMD, an address signal ADDR, and a chip select signal CS may be supplied from a memory controller to the command terminal and the address terminal. The command signal may represent various memory commands (e.g., including access commands, which may include read commands and write commands) from the memory controller. The select signal CS may be used to select the memory device 100 to respond to the commands and addresses provided to the command terminals and the address terminals. When a valid CS signal is provided to the memory device 100, the commands and addresses may be decoded, and memory operations may be performed. The command signal CMD may be provided to the command decoder 115 as an internal command signal ICMD via the address / command input circuit 105. The command decoder 115 may include a circuit for decoding the internal command signal ICMD to generate various internal signals and commands (e.g., a row command signal for selecting a word line and a column command signal for selecting a bit line) for performing memory operations. The internal command signal may also include an output activation command and an input activation command, such as a timing command CMDCK ( Figure 1 not shown).

[0034] In some embodiments, command decoder 115 may further include one or more registers for tracking various counts or values ​​(e.g., a count of refresh commands received by memory device 100 or a count of self-refresh operations performed by memory device 100). In some embodiments, a subset of registers may be referred to as mode registers and configured to store user-defined variables to provide flexibility in executing various functions, features, and modes and / or to provide information characterizing various aspects of memory device 100. For example, memory device 100 may receive signaling from a host device to program a mode register with a specified value (e.g., to configure the memory device). As another example, memory device 100 may receive signaling from a host device to read out values ​​from certain mode registers (e.g., to obtain certain status information from the memory device).

[0035] When a read command is issued to a group with an open row and a column address is supplied in time as part of the read command, read data may be read from a memory cell in the memory array 150 specified by a row address (which may have been provided as part of an activation command identifying the open row) and a column address. The read command may be received by a command decoder 115, which may provide an internal command to the IO circuit 160 so that read data may be output from data terminals DQ, RDQS, DBI, and DMI via the read / write amplifier 155 and the IO circuit 160 according to the RDQS clock signal. The read data may be provided at a time defined by read latency information (RL), which may be programmed in the memory device 100, such as in a mode register. The read latency information RL may be defined in terms of clock cycles of a CK clock signal. For example, the read latency information RL may be the number of clock cycles of the CK signal after the memory device 100 receives the read command when the associated read data is provided. The read data may also be processed by an ECC engine (not shown) that may detect and correct a certain number of errors in the data read from the memory array 150. Information about the severity of any errors detected by the ECC engine in the read data may be output from the severity terminal SEV along with the read data. As described herein, read data may be output from a data terminal (e.g., DQ) during a burst consisting of a plurality of burst positions (e.g., UI0-UI7, UI0-UI31, etc.), while severity information may be output through the severity terminal SEV during only some of the burst positions (e.g., UI0-UI3) of the burst positions of the read data burst.

[0036] When a write command is issued to a group with an open row and a column address is supplied in time as part of the write command, write data may be supplied to data terminals DQ, DBI, and DMI according to WCK and WCKF clock signals. The write command may be received by a command decoder 115, which may provide an internal command to an IO circuit 160, so that the write data may be received by a data receiver in the IO circuit 160 and supplied to the memory array 150 via the IO circuit 160 and the read / write amplifier 155. The write data may be written to a memory cell specified by a row address and a column address. The write data may be provided to the data terminal at a time defined by write latency WL information. The write latency WL information may be programmed in the memory device 100, such as in a mode register. The write latency WL information may be defined in terms of clock cycles of a CK clock signal. For example, the write latency information WL may be the number of clock cycles of a CK signal after the memory device 100 receives the write command when the associated write data is received.

[0037] The power supply terminal may be supplied with power supply potentials VDD and VSS. These power supply potentials VDD and VSS may be supplied to the internal voltage generator circuit 170. The internal voltage generator circuit 170 may generate various internal potentials VPP, VOD, VARY, VPERI, etc. based on the power supply potentials VDD and VSS. The internal potential VPP may be used in the row decoder 140, the internal potentials VOD and VARY may be used in the SAMP included in the memory array 150, and the internal potential VPERI may be used in many other circuit blocks.

[0038] The power supply terminal may also be supplied with a power supply potential VDDQ. The power supply potential VDDQ may be supplied to the IO circuit 160 together with the power supply potential VSS. In an embodiment of the present technology, the power supply potential VDDQ may be the same potential as the power supply potential VDD. In another embodiment of the present technology, the power supply potential VDDQ may be a potential different from the power supply potential VDD. However, a dedicated power supply potential VDDQ may be used for the IO circuit 160 so that the power supply noise generated by the IO circuit 160 does not propagate to other circuit blocks.

[0039] The on-die termination terminal may be supplied with an on-die termination signal ODT. The on-die termination signal ODT may be supplied to the IO circuit 160 to instruct the memory device 100 to enter an on-die termination mode (e.g., to provide one of a predetermined number of impedance levels at one or more of the other terminals of the memory device 100).

[0040] An external clock signal and a complementary external clock signal may be supplied to the clock terminal and the data clock terminal. External clock signals CK, CKF, WCK, and WCKF may be supplied to the clock input circuit 120. CK and CKF signals may be complementary, and WCK and WCKF signals may also be complementary. Complementary clock signals may have opposite clock levels and simultaneously switch between opposite clock levels. For example, when the clock signal is at a low clock level, the complementary clock signal is at a high level, and when the clock signal is at a high clock level, the complementary clock signal is at a low clock level. In addition, when the clock signal changes from a low clock level to a high clock level, the complementary clock signal changes from a high clock level to a low clock level, and when the clock signal changes from a high clock level to a low clock level, the complementary clock signal changes from a low clock level to a high clock level.

[0041] An input buffer included in the clock input circuit 120 may receive an external clock signal. For example, when enabled by the CKE signal from the command decoder 115, the input buffer may receive the CK and CKF signals and the WCK and WCKF signals. The clock input circuit 120 may receive an external clock signal to generate an internal clock signal ICLK. The internal clock signal ICLK may be supplied to the internal clock circuit 130. The internal clock circuit 130 may provide various phase-controlled and frequency-controlled internal clock signals based on the received internal clock signal ICLK and the clock enable signal CKE from the command decoder 115. For example, the internal clock circuit 130 may include a clock path ( CK_CLOCK_STOP_LOGO ) that receives the internal clock signal ICLK and provides various clock signals to the command decoder 115. Figure 1 100). The internal clock circuit 130 may further provide an input / output (IO) clock signal. The IO clock signal may be supplied to the IO circuit 160 and may be used as a timing signal for determining the output timing of read data and the input timing of write data. The IO clock signal may be provided at multiple clock frequencies so that data may be output from and input to the memory device 100 at different data rates. When high memory speeds are desired, higher clock frequencies may be desirable. When lower power consumption is desired, lower clock frequencies may be desirable. The internal clock signal ICLK may also be supplied to the timing generator 135, and various internal clock signals may be generated accordingly.

[0042] Memory device 100 may additionally include circuits implementing mechanisms to detect and mitigate attacks on the memory device, such as row hammer mitigation circuit 190 and / or row hammer alert circuit 192 .

[0043] The row hammer mitigation circuit 190 may be configured to determine when the memory device 100 is the target of a row hammer attack by determining that the victim row has experienced an extremely high number of disturb effects caused by neighboring row activate commands since the last refresh operation at the victim row. In some embodiments, for each row in the memory array 150, the row hammer mitigation circuit 190 maintains a count of activate commands that targeted the row since the last refresh operation of the row (e.g., from which the amount of row hammer disturb effects imposed on neighboring rows can be determined). In some embodiments, for each row in the memory array 150, the row hammer mitigation circuit 190 maintains a count of activate commands involving neighboring rows (e.g., rows that are immediately adjacent and / or within a predetermined physical distance from the tracked row) since the last refresh of the tracked row. In some embodiments, the count is stored in the memory array 150 (e.g., each row in the memory array includes an additional count bit for storing the count). In some embodiments, the row hammer mitigation circuit 190 generates a probability-based count based on a random sampling of accessed row addresses. Based on these maintained counts, the row hammer mitigation circuit 190 can determine when a row should be refreshed to mitigate the row hammer effect. To accomplish this, the row hammer mitigation circuit 190 can monitor the maintained counts, determine if the count for any row exceeds a row hammer mitigation threshold, and initiate a refresh operation for the row whose count exceeds the threshold. For example, the row hammer mitigation circuit 190 can add the address of any victim row that exceeds the threshold to a mitigation queue so that the row will be refreshed. (e.g., add the address of the row to the mitigation queue).

[0044] The row hammer alert circuit 192 may be configured to detect conditions associated with a row hammer attack and generate an alert signal. As described herein, the row hammer alert circuit 192 may generate an alert signal without intervention by a host coupled to the memory device 100 based on conditions indicating that an undesirable result may occur (e.g., data loss in the memory array 150). For example, the row hammer alert circuit 192 may detect a condition indicating that the row hammer mitigation circuit 190 may not be able to continue to mitigate an ongoing attack if the host continues to generate requests to access rows in the memory array 150. In some embodiments, the row hammer alert circuit 192 may determine which rows in the memory array 150 are fired (e.g., have an activation count just less than but not yet exceeding an activation threshold at which the rows are queued for refresh) and compare the number of fired rows to the fired row threshold. If the number of fired rows equals or exceeds the fired row threshold (e.g., indicating that the number of rows in the memory array 150 may need to be refreshed soon), the row hammer alert circuit 192 may generate a row hammer alert signal. In some embodiments, the row hammer alert circuit 192 may evaluate the utilization of a mitigation queue (e.g., a portion of the row hammer mitigation circuit 190) to determine how many victim row addresses have been queued for refresh. In some embodiments, the row hammer alert circuit 192 may evaluate the mitigation queue utilization associated with a portion of the memory array 150. For example, the row hammer alert circuit may determine the number of entries in the mitigation queue associated with individual groups of the memory array 150 (e.g., generate a per-group count of mitigation queue entries), and may evaluate whether the count for any group exceeds a per-group queue threshold. If the mitigation queue utilization equals or exceeds a threshold (e.g., indicating that a certain number of victim rows are queued for refresh and / or that the mitigation queue has only a certain available capacity left), the row hammer alert circuit 192 may generate a row hammer alert signal.

[0045] The row hammer warning circuit 192 may output the generated row hammer warning signal through the severity terminal SEV. As described above, the severity terminal SEV may also be used to output severity information (e.g., generated in response to a read request). Thus, the row hammer warning circuit 192 may be configured to output the row hammer warning signal on the severity terminal SEV when the severity terminal SEV is not being used to output severity information (and to allow any severity information to be output through the severity terminal SEV when the severity information would be conventionally output on the terminal). When the row hammer warning circuit 192 generates the row hammer warning signal, it may determine whether it is possible to output severity information through the severity terminal SEV during that time. For example, the row hammer warning circuit 192 may determine whether the memory device 100 is outputting read data through the data terminal (e.g., DQ) in response to a read request from the host. If the memory device is outputting read data in response to a read request, the row hammer warning circuit 192 may further determine the current burst position within the read burst. If the row hammer alert circuit 192 determines that severity information can be output using severity terminal SEV at that time (e.g., it determines that the memory device 100 is currently outputting burst positions UI4-UI7 of the BL8 burst of read data), it can save a state (e.g., a flip-flop, a mode register, etc.) indicating that a row hammer alert condition has been detected. Once the row hammer alert circuit 192 determines that severity terminal SEV is available for alert information (e.g., the memory device 100 is not outputting read data through the data terminal and / or a burst position during which severity information will not be transmitted), it can output the generated row hammer alert signal and / or the saved row hammer alert state through severity terminal SEV. In an embodiment, the row hammer alert circuit 192 continues to output the row hammer alert indication through severity terminal SEV until it determines that the attack condition has been resolved (e.g., enough victim rows have been refreshed).

[0046] As described herein, a host coupled to the memory device 100 may be configured to monitor the severity terminal SEV and determine whether the terminal is being used to output severity information or row hammer warning information based on whether the memory device is also outputting read data (and if so, in which burst position within the burst). That is, while a conventional host may monitor the severity terminal SEV only during certain burst positions of read data, a host configured according to an embodiment of the present technology may continuously monitor the terminal. If the host detects that the severity terminal SEV is being used to output a row hammer warning indication, and the terminal is asserted, the host may suspend further operations with the memory device 100 until the row hammer warning indication is deasserted. That is, for example, the host may stop a read request, a write request, etc. being transmitted to the memory device 100.

[0047] although Figure 1 An embodiment of the memory device 100 is described in which the row hammer mitigation circuit 190 and the row hammer warning circuit 192 are described as different components, but in some embodiments, one or more of the aforementioned circuits can be combined. For example, in some embodiments, the row hammer mitigation circuit 190 and the row hammer warning circuit 192 are a single circuit that performs row hammer detection, mitigation, and warning functions.

[0048] although Figure 1 An embodiment of a memory device 100 having a single channel (e.g., a single command terminal and address terminal, a single data terminal, etc.) is described, but embodiments of memory devices may have multiple channels that may be further divided into PCs. In an embodiment, the row hammer mitigation circuit 190 may be configured to detect and mitigate row hammer attacks (e.g., attacks that affect rows of the memory array 150 associated with a particular channel or PC) on a per-channel or per-PC basis. Similarly, the row hammer alert circuit 192 may be configured to generate a per-channel or per-PC row hammer alert. In an embodiment, the memory device 100 includes multiple severity terminals SEV, each of which is associated with a single channel or PC. Thus, the memory device 100 may alert a host to a row hammer attack condition on a per-channel or per-PC basis.

[0049] Figure 2 A simplified block diagram is shown schematically illustrating an HBM device 200 according to an embodiment of the present technology. The HBM device 200 includes a stack of multiple DRAM devices 205 and an interface die 210. Figure 2 In the embodiment illustrated in FIG. 1 , HBM device 200 includes a stack of four DRAM devices (i.e., DRAM device 205-1, DRAM device 205-2, DRAM device 205-3, and DRAM device 205-4), but it should be understood that in other embodiments, HBM device 200 may include a different number of DRAM devices. DRAM device 205 and / or interface die 210 may provide the above-described Figure 1 One or more of the memory storage devices, functions, interfaces, etc. discussed in the memory device 100.

[0050] DRAM device 205 may include one or more channels 215, each of which provides an independent interface to DRAM memory device 220. For example, Figure 2 As illustrated in FIG. 1 , DRAM device 205-1 may include four channels: a first channel 215-1, a second channel 215-2, a third channel 215-3, and a fourth channel 215-4, wherein each channel is associated with a DRAM memory device 220 that can only be accessed using that channel. Figure 2Only the channel of DRAM device 205-1 is illustrated, but it should be understood that other DRAM devices 205 of HBM device 200 may have one or more channels. Figure 2 An embodiment is described in which DRAM device 205-1 has four channels, but in embodiments, DRAM devices may have other numbers of channels. In addition, different DRAM devices 205 within HBM device 200 may have different numbers of channels.

[0051] The channel 215 and the DRAM memory devices 220 therein may be further divided into pseudo-channels that may operate semi-independently from other pseudo-channels of the channel. Figure 2 As illustrated in FIG. 2 , the first channel 215 - 1 can be divided into a first dummy channel 225 - 1 and a second dummy channel 225 - 2 . The other channels 215 of the DRAM device 205 can be similarly divided into dummy channels 225 .

[0052] DRAM device 205 may further include row hammer warning circuitry configured to generate a row hammer warning signal. In an embodiment, the row hammer warning circuitry may be configured to generate individual row hammer warning signals associated with individual channels or pseudo channels of HBM device 200. For example, in Figure 2 In the embodiment illustrated in FIG. 1 , the row hammer warning circuitry 230-1 may generate a warning signal associated with the first pseudo channel 225-1, and the row hammer warning circuitry 230-2 may generate a warning signal associated with the second pseudo channel 225-2 of the first channel 215-1. The HBM device 200 may include additional row hammer warning circuitry (not shown) for other DRAM devices 205, channels 215, and pseudo channels 225. Although Figure 2 An embodiment is described in which the row hammering circuitry is part of the DRAM device 205 , but in an embodiment, the row hammering circuitry may be part of the interface die 210 or another component of the HBM device 200 .

[0053] The interface die may include a severity interface 235 through which one or more severity signals may be transmitted to a host coupled to the HBM device. In an embodiment, the severity interface 235 includes one or more severity signals per pseudo channel 225 of the HBM device 200. The severity interface 235 may also be configured to transmit a row hammer warning signal (e.g., generated by a row hammer warning circuit system) to the host. As described herein, the severity interface 235 may be configured to transmit severity signals during certain operations of the HBM device 200 and to transmit row hammer warning signals during other operations of the HBM device 200. In addition, both severity signals and row hammer warning signals may be transmitted on a per-channel or per-pseudo-channel basis through the severity interface 235. For example, a portion of the severity interface 235 associated with one pseudo channel may be used to transmit severity information while a different portion of the severity interface associated with another pseudo channel may be used to transmit row hammer warning information.

[0054] Figure 3 A severity interface encoding 300 according to an embodiment of the present technology is described. The severity interface encoding 300 may be used by a component of a memory system that provides per-channel warning signaling of an overload. For example, an HBM device may encode information to be transmitted through a severity interface 302 according to the severity interface encoding 300, and a host and / or a memory controller may decode information received through the severity interface according to the severity interface encoding 300. The severity interface encoding 300 may be used to encode information transmitted through any of a plurality of severity interfaces 302 between an HBM device and a host in a memory system. That is, there may be a plurality of severity interfaces 302 (each severity interface associated with a channel and / or a pseudo-channel), each of which may be encoded according to the severity interface encoding 300.

[0055] The severity interface encoding 300 illustrates how information is encoded on the severity interface 302 during a read operation (e.g., in response to a read request from a host). In addition, the severity interface encoding 300 illustrates the operation of the severity interface 302 during a burst in which data is transferred over a data interface (e.g., DQ) as part of a read operation. The severity interface encoding 300 illustrates an embodiment of transferring data over a burst of length 8 (e.g., BL8) consisting of burst positions 0-7. In other embodiments, the severity interface encoding 300 may be adapted for other burst lengths for transferring data (e.g., BL16, BL24, BL32, etc.).

[0056] During the severity portion 305 of the burst, the severity interface 302 may be used to encode severity information. For example, during the severity portion 305, the severity interface 302 may be used to encode whether the transmitted read data contains no errors 310, contains corrected single-bit errors 315, contains corrected multi-bit errors 320, or contains uncorrectable errors 325. Figure 3 In the embodiment of the severity interface encoding 300 illustrated in FIG. 1 , the severity portion 305 occupies burst positions 4-7 of the burst. However, it should be appreciated that in other embodiments of the severity interface encoding 300, the severity portion 305 may occupy other burst positions of the burst. For example, in a burst of length 32 (burst positions 0-31), the severity portion 305 may occupy burst positions 28-31.

[0057] During the alert portion 330 of the burst, the severity interface may be used to transmit row hammer alert information. As described herein, the row hammer alert information may indicate to the host whether a channel, pseudo channel, etc. associated with the severity interface 302 is under attack. For example, if the severity interface 302 is asserted during the alert portion 330, it may indicate to the host that the corresponding channel, pseudo channel, etc. is under attack. Additionally, if the severity interface 302 is not asserted during the alert portion 330, it may indicate to the host that the corresponding channel, pseudo channel, etc. is not under attack.

[0058] Figure 3 An embodiment of the severity interface encoding 300 is illustrated in which the warning portion 330 occupies burst positions 0-3. It should be appreciated that in other embodiments, the warning portion 330 may occupy other burst positions, fewer burst positions, etc. For example, although Figure 3 An embodiment is described in which all burst positions outside the severity portion 305 are used as the alert portion 330, but in an embodiment, only a subset of the burst positions outside the severity portion are used as the alert portion. Figure 3 An embodiment is described in which the severity interface 302 includes two pins (e.g., SEV[1:0]), both of which are used to indicate row hammer warning information during the warning portion 330, but in embodiments, the severity interface may include more or fewer pins, some of which may not be used to transmit row hammer warning information during the warning portion (e.g., these pins may be unconcerned or may be used to transmit other information).

[0059] As described above, severity interface encoding 300 illustrates an embodiment of encoding for severity interface 302 during a burst in which read data is being transferred as part of a read operation (e.g., in response to a read request from a host). When read data is not being transferred in a burst, other encodings not shown may be used for severity interface 302. In some embodiments, if read data is not being transferred over the data interface in a burst, severity interface 302 is used to encode row hammer warning information.

[0060] Figure 4 4 is a flow chart illustrating a process 400 for warning of a row hammer attack according to an embodiment of the present technology. Aspects of the process 400 may be performed, for example, by a memory device (e.g., a DRAM device, an HBM device, etc.) and / or components thereof (e.g., a row hammer warning circuit).

[0061] Process 400 begins at block 405, where a memory device detects a condition for a row hammer attack on the memory device (or a portion thereof). For example, the memory device may detect that a threshold number of rows in a memory array of the memory device have been fired, a threshold number of rows require refresh, a mitigation queue of the memory device is at a threshold utilization level, etc.

[0062] At decision block 410, the memory device determines whether a severity interface between the memory device and a coupled host is being used to transmit severity information. For example, the memory device may determine whether it is transmitting read data to the host (e.g., in response to a read request), and if so, in what burst position within a read burst the transmission is being performed. If the memory device determines that the severity interface is being used to transmit severity information, the process returns to decision block 410 (e.g., to re-evaluate whether the severity interface is being used to transmit severity information). If the memory device determines that the severity interface is not being used to transmit severity information, processing continues to block 415.

[0063] At block 415, the memory device transmits a row hammer alert indication via the severity interface. For example, the memory device may assert a signal of the severity interface (eg, set to a logic 1) to indicate the occurrence of a row hammer attack.

[0064] At decision block 420, the memory device determines whether the condition for the row hammer attack has been resolved. For example, the memory device may determine whether a sufficient number of rows of a memory array of the memory device have been refreshed. If the memory device determines that the condition for the row hammer attack has not been resolved, the process 400 returns to block 415 (e.g., to continue asserting the row hammer warning indication). If the memory device determines that the condition for the row hammer attack has been resolved, processing continues to block 425.

[0065] At block 425, the memory device deasserts the row hammer alert indication on the severity interface. Process 400 then ends.

[0066] Figure 5 A block diagram of an example machine is shown in which a computer system 500 may be executed in which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., using a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0067] The machine may be a personal computer, a tablet computer, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions that specify actions to be taken by the machine. Further, while a single machine is described, the term "machine" should also be construed to include any collection of machines that individually or collectively execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0068] The example computer system 500 includes a processing device 502, a main memory 504 (e.g., ROM, flash memory, DRAM, such as SDRAM or Rambus DRAM (RDRAM), etc.), a static memory 506 (e.g., flash memory, static RAM (SRAM), etc.), and a data storage system 518 that communicate with each other via a bus 530. According to one aspect of the disclosure, the main memory 504 can report (e.g., to the processing device 502) per-channel instances of row hammering attacks on the main memory.

[0069] The processing device 502 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, the processing device can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. The processing device 502 can also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. The processing device 502 is configured to execute instructions 526 for performing the operations and steps discussed herein. The computer system 500 can also include a network interface device 508 to communicate through a network 520.

[0070] The data storage system 518 may include a machine-readable storage medium 524 (also referred to as a computer-readable medium) on which is stored one or more sets of instructions 526 or software embodying any one or more of the methodologies or functions described herein. The instructions 526 may also reside, completely or at least partially, within the main memory 504 and / or within the processing device 502 during execution thereof by the computer system 500, the main memory 504 and the processing device 502 also constituting machine-readable storage media.

[0071] Although the machine-readable storage medium 524 is shown as a single medium in the example embodiment, the term "machine-readable storage medium" should be considered to include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" should also be understood to include any medium capable of storing or encoding a set of instructions for execution by a machine, the instructions causing the machine to perform any one or more of the methods of the present disclosure. Thus, the term "machine-readable storage medium" should be considered to include, but not be limited to, solid-state memory, optical media, and magnetic media.

[0072] The devices discussed herein, including memory devices, may be formed on a semiconductor substrate or die, such as silicon, germanium, silicon-germanium alloys, gallium arsenide, gallium nitride, etc. In some cases, the substrate is a semiconductor wafer. In other cases, 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 a semiconductor material on another substrate. The conductivity of a substrate or a sub-region of a 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 during the initial formation or growth of the substrate or by any other doping means.

[0073] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. Other examples and implementations are within the scope of the present disclosure and the appended claims. Features implementing the functions may also be physically located at various locations, including being distributed so that parts of the functions are implemented at different physical locations.

[0074] As used herein, including as used in the claims, "or" used in a list of items (e.g., a list of items preceding, for example, "at least one of" or "one or more of") indicates an inclusive list, such that a list of, for example, at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Additionally, as used herein, the phrase "based on" should not be construed as referring to a closed set of conditions. For example, an exemplary step 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 understood in the same manner as the phrase "based at least in part on."

[0075] As used herein, the terms "vertical," "lateral," "upper," "lower," "above," and "below" may refer to the relative direction or position of features in a semiconductor device in view of the orientation shown in the figure. For example, "upper" or "uppermost" may refer to a feature that is positioned closer to the top of the page than another feature. However, these terms should be interpreted broadly to include semiconductor devices having other orientations, such as inverted or tilted orientations, where top / bottom, up / down, over / below, up / down, and left / right may be interchanged depending on the orientation.

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

[0077] It should be understood from the foregoing that specific embodiments of the present invention have been described herein for illustrative purposes, but various modifications may be made without departing from the scope of the present invention. In fact, in the foregoing description, numerous specific details are discussed to provide a thorough and inspiring description of embodiments of the present invention. However, those skilled in the relevant art will recognize that the present disclosure may be practiced without one or more of the specific details. In other cases, well-known structures or operations typically associated with memory systems and devices are not shown or described in detail to avoid confusing other aspects of the technology. In general, it should be understood that various other devices, systems, and methods other than those specific embodiments disclosed herein may be within the scope of the present invention.

Claims

1. A high bandwidth memory HBM device, comprising: a plurality of channels coupled to a host computer, each channel being associated with a command / address bus and a severity bus; as well as A plurality of vertically stacked memory dies, each of the memory dies comprising: one or more memory groups, each memory group being associated with one of the plurality of channels; one or more interfaces, each interface being associated with a channel from the plurality of channels, the channel being associated with a memory bank of the one or more memory banks; and A hammer warning circuit is provided, which is configured to: detecting a row hammer attack on a memory bank of the one or more memory banks; determining whether the severity bus of the channel associated with the memory bank is transmitting severity information; and A row hammer alert is transmitted over the severity bus when the severity bus of the channel associated with the memory bank is not being used to transmit severity information.

2. The HBM device of claim 1 , wherein each memory bank comprises a plurality of rows of memory cells, and wherein detecting the row hammering attack on the memory bank comprises: determining a number of rows in the memory bank associated with an activation count that exceeds a first threshold and does not exceed a second threshold; as well as It is evaluated whether the determined number of rows exceeds a third threshold.

3. The HBM device of claim 1 , wherein each memory bank comprises a plurality of rows of memory cells, wherein the HBM device further comprises a mitigation queue configured to queue row addresses associated with rows to be refreshed, and wherein detecting the row hammer attack on the memory banks comprises: determining a number of mitigation queue entries associated with a row address corresponding to the memory bank; as well as Evaluates whether the number of mitigation queue entries determined exceeds the queue threshold.

4. The HBM device of claim 1 , wherein each channel is associated with a data bus, wherein the HBM device is configured to transmit read data to the host over each data bus throughout a burst comprising a plurality of burst positions, and wherein determining whether the severity bus is transmitting severity information comprises: determining whether the data bus of the channel associated with the severity bus is being used to transmit read data to the host; determining a current burst position of a current read burst based on the determining that the data bus is being used to transfer read data; and An evaluation is made as to whether the current burst position is used for severity information.

5. The HBM device of claim 4, wherein the burst comprises 8 burst positions (UI0-UI7), and wherein the row hammer alert is transmitted during at least UI0-UI3. The HBM device of claim 1 , wherein the HBM device comprises 32 channels.

7. The HBM device of claim 1 , wherein each channel is divided into a first pseudo channel and a second pseudo channel, wherein a first portion of the severity bus associated with a channel is associated with the first pseudo channel of the channel, wherein a second portion of the severity bus associated with the channel is associated with the second pseudo channel of the channel, wherein the row hammer alert is transmitted via the first portion of the severity bus, and wherein the row hammer alert circuit is further configured to transmit a second row hammer alert via the second portion of the severity bus in response to detecting a row hammer attack on a portion of the memory bank associated with the second pseudo channel.

8. A memory device comprising: a memory array comprising a plurality of rows of memory cells; a row hammer mitigation circuit configured to determine whether to perform a mitigation action on a row of the plurality of rows; as well as A hammer warning circuit is provided, which is configured to: Produce a hammer strike warning; as well as The row hammer alert is transmitted via a severity interface of the memory device.

9. The memory device of claim 8, wherein determining whether to perform the mitigation action on a row comprises: randomly sampling requests received by the memory device from a host, each sampled request including a memory address; determining, for each sampled request, the row of the plurality of rows associated with the memory address; and The frequency of the samples associated with the row is evaluated.

10. The memory device of claim 8, wherein each of the plurality of rows comprises an activation count bit, wherein the memory device is configured to increment the activation count bit of the row when the row is activated, and wherein determining whether to perform the mitigation action on the row comprises comparing the activation count bit of the row to an activation threshold.

11. The memory device of claim 8, wherein generating the row hammer alert comprises: determining a number of rows in the memory array associated with an activation count that exceeds a first threshold and does not exceed a second threshold; as well as It is evaluated whether the determined number of rows exceeds a third threshold.

12. The memory device of claim 8, wherein the memory device further comprises a mitigation queue configured to queue row addresses associated with rows for which mitigation actions are to be performed, and wherein generating the row hammer alert comprises: determining utilization of the mitigation queue; as well as It is evaluated whether the utilization exceeds a utilization threshold.

13. The memory device of claim 8, wherein the row hammer warning circuit is further configured to: determining whether severity information is being transmitted via the severity interface; maintaining the generated row hammer alert in a row hammer alert state while the severity information is being transmitted via the severity interface; as well as The maintained row hammer alert is transmitted from the row hammer alert state via the severity interface when severity information is no longer being transmitted.

14. The memory device of claim 13, wherein the memory device is configured to transmit read data to a host throughout a burst that includes a burst position, and wherein determining whether severity information is being transmitted over the severity interface comprises determining a current burst position of a current burst of read data.

15. The memory device of claim 14, wherein the burst comprises eight burst positions (UI0-UI7), and wherein the row hammer alert circuit determines that severity information is being transmitted over the severity interface if the memory device is in UI4-UI7 of a read data burst.

16. The memory device of claim 8, wherein the memory device further comprises a plurality of channel interfaces coupled to a host, and wherein the generated row hammer alert is associated with a first channel interface of the plurality of channel interfaces.

17. The memory device of claim 16, wherein the row hammer alert circuit is further configured to generate a second row hammer alert associated with a second channel interface of the plurality of channel interfaces and transmit the second row hammer alert through a second severity interface associated with the second channel interface.

18. The memory device of claim 8, wherein the memory device is a high bandwidth memory device.

19. A method comprising: receiving, by a memory controller through a severity interface, data from a high bandwidth memory (HBM) device coupled to the severity interface; determining whether the data is associated with severity information or row hammer warning information; If the data is associated with row hammer warning information, evaluating the data to determine whether a row hammer warning is indicated; as well as Based on the determination indicating a hammer alert, requests transmitted to the HBM device via a command / address interface associated with the severity interface are suspended.

20. The method of claim 19, further comprising: While suspending the request through the command / address interface, transmitting the request to the HBM device through a second command / address interface.

Images