Method and circuit for protecting a dram memory device from row hammer effect

Abstract

The invention relates to a method for protecting a DRAM memory device against row hammer effect, the memory device comprising a plurality of memory banks consisting of memory rows, the method being implemented by at least one logic prevention device configured to associate a contiguous portion of rows of a memory bank with a sub-bank respectively. The prevention logic is further configured to perform a preventive refresh cycle of the sub-bank in its entirety before the number of rows activated in the sub-bank exceeds a critical hammer value. The invention also relates to a DRAM memory device, a buffer circuit or a controller of such a memory comprising a logic for preventing row hammer effect.

Description

TECHNICAL FIELD

[0001] The present invention relates to the field of DRAM ("Dynamic Random Access Memory") circuits and in particular to the management of the "row hammer" effect. The "row hammer" effect is the fact that repeatedly activating a row of a given DRAM within a given bank of a DRAM memory can cause physically adjacent rows to flip the value of some of their bits. The repeatedly activated row is called the "aggressor row" while the adjacent rows are called the "victim rows". BACKGROUND

[0002] Kim Dae-Hyun et al. in the article "Architectural support for mitigating row hammering in DRAM memories", IEEE computer Architecture Letters, IEEE Volume 14, Issue 1 (1 January 2015) disclose various methods to prevent row hammering in DRAM devices. In a first method called "counter-based row activation", a counter associated with a row of a memory device is incremented upon activation of that row. When the counter associated with a given row exceeds a threshold, the adjacent rows of the given row are refreshed. Although this method is effective in preventing the effects of row hammering, it employs a large storage capacity to accommodate the required number of counters, i.e. one counter per row.

[0003] Seyedzadeh Seyed Mohammad et al. in the article "Computer based Tree structure for row hammering mitigation in DRAM", IEEE computer Architecture Letters, IEEE Volume 16, Issue 1 (1 January 2017) propose to associate a counter with a group of rows to limit the number of counters instead of associating a counter with each row. The counter is incremented each time a row from the group of rows is activated. When the counter associated with a given group of rows exceeds a threshold, then all rows of the given group are refreshed. Although this method does limit the number of required counters, it causes the problem of not being able to access the group of rows for activation when the group of rows is being refreshed. Increasing the number of rows in each group reduces the number of required counters but extends the time during which the group of rows is blocked from access while it completes the refresh. Conversely, reducing the number of rows in each group reduces the refresh duration of the group but increases the number of counters.

[0004] Document FR3066842A1 describes in detail an algorithm for preventing row hammer effect, which implements the use of tables. This algorithm is particularly suitable for relatively large critical hammer values, typically 40000 or more. However, the use of increasingly fine manufacturing geometries for DRAM has led to the observation of memories with relatively low critical hammer values, for example as low as 4800.

[0005] In the above-mentioned document, the number of entries of the tables used during the deployment of the algorithm is inversely proportional to the critical hammer value, which imposes an 8-fold greater number of entries in the case where it is necessary to apply the algorithm proposed for DRAMs using these finer geometries. It is problematic to browse so many entries in the time separating the two activation commands of a row, even if these entries are distributed over several tables accessed in parallel.

[0006] Moreover, it is undeniable that, in these fine-geometry DRAM memories, the row hammer also affects, to a lesser extent, the victim rows that are close to but not directly adjacent to the aggressor row that is hammered. However, the solution proposed by document FR3066842 only manages the hammer that affects only the two adjacent rows that are directly adjacent to the aggressor row that is hammered, such a phenomenon being referred to in this document as a hammer of scope 1.

[0007] In general, a hammer of scope 1 means that the aggressor row of topological index i of the memory bank can affect rows i-1 and i+1. A hammer of scope 2 means that rows i-2 and i+2 are also affected, but to a lesser extent, and so on for higher scopes. The level of hammer attack in scope p experienced by the victim row i can be expressed as a weighted sum of the activations of 2xp adjacent rows:

[0008] + (number of activations of row i-p) x RH_coeff_p

[0009] + (number of activations of row i-(p-1)) x RH_coeff_(p-1)

[0010] +...

[0011] + (number of activations of row i-2) x RH_coeff_2

[0012] + (number of activations of row i-1) x 1

[0013] + (number of activations of row i+1) x 1

[0014] + (number of activations of row i+2) x RH_coeff_2

[0015] +...

[0016] + (number of activations of row i + (p - 1)) x RH_coeff_(p-1)

[0017] + (number of activations of row i + p) x RH_coeff_p

[0018] When the attack level resulting from this sum exceeds a threshold, then the data stored in row i can have changed. The threshold is defined in such a way that the coefficients (RH_coeff) applied to the number of activations of rows i-1 and i+1 are 1, so that the definition of the attack level in scope 1 is in line with the usual and previous row hammer definition. Of course, the coefficients RH_coeff_n become weaker and weaker as one moves away from the hammered row. This is the reason why it is useful to take into account the row hammer phenomenon in a limited scope (1, 2, 3...).

[0019] The logic to monitor the row hammer phenomenon in scope 2 or greater can be too complex and too slow to be efficiently integrated into a DRAM using the general definition of this weighted sum.

[0020] There is therefore a need for an algorithm that makes it possible to manage row hammering in a scope greater than 1 (2, 3, etc.), which therefore also impacts neighboring rows that are not directly adjacent to the attacker row that is hammered.

[0021] Document US9214216 discloses a logic for protecting a DRAM memory device against the row hammer effect. According to this document, the rows of memory cells are organized in blocks, and the number of activations of the rows is calculated for each block. When the counter of a block reaches a critical hammering value, the rows of this block are refreshed by redirecting all the refresh operations that try to prevent row hammering towards this block. During this block refresh period, the logic cannot perform preventive refreshes in the other blocks, which makes this logic fragile with respect to complex hammering scenarios, and does not completely protect the memory device against this phenomenon.

[0022] Document US20200111525 discloses a method that aims to send refresh management commands in addition to the periodic refresh commands in order to try to limit the impact of the hammering phenomenon on the memory device. This document in particular tries to integrate preventive refresh operations into other operations in order to efficiently use the bus that connects the host to the memory device. To this end, a memory bank activation counter is incremented each time the memory bank concerned is activated. When this counter exceeds a threshold value, a refresh management command is sent in order to perform a memory bank refresh operation. This operation does not necessarily have to be performed immediately, and the activation counter is decremented when this operation is performed. This document does not in any way specify which row of the memory bank must be the object of the refresh operation, nor is it possible to build a logic that prevents the impact of the row hammer, let alone guarantee a specific and provable prevention.

[0023] Invention subject

[0024] The main object of the present invention is to provide a method for protecting DRAM memory devices from row hammer effect which at least partially solves these limitations. More specifically, the object of the present invention is to provide a method for monitoring the row activation of a DRAM memory bank which is simple enough to be executed without any problem in the minimum time separating two activations and which can prevent the effects of hammering with a scope greater than 1. This method is particularly suitable for memories for which the critical hammering value is relatively low, for example less than 40 000, although it can in practice be used for any type of DRAM memory.

[0025] The present invention can be integrated in a memory controller, in a buffer circuit or in a DRAM memory device. The DRAM memory can be integrated in a processor. SUMMARY

[0026] To achieve this object, the object of the present invention proposes a method for protecting a DRAM memory device from row hammer effect, the memory device comprising a plurality of banks consisting of rows of memory, the method being implemented by at least one prevention logic configured to define sub-banks as respective contiguous portions of rows of a bank.

[0027] The prevention logic is configured to increment, by a progression coefficient less than 1, the required number of preventive refreshes of the ranks of a given sub-bank when activating a row of the given sub-bank.

[0028] The prevention logic is also configured to perform a preventive refresh sequence to preventively refresh at least one but not all ranks of a sub-bank, the preventive refresh sequence comprising:

[0029] - a step of identifying a need for a preventive refresh of a rank of a determined sub-bank among the sub-banks of the memory device, and, on such a need, applying the following steps:

[0030] - a step of triggering an operation for refreshing a current row designated by a current row index associated with the determined sub-bank;

[0031] - a step of incrementing the current row index (RELATIVE_INDEX) associated with the determined sub-bank;

[0032] - a step of decrementing the required number of preventive refreshes of the ranks of the determined sub-bank (j) (REFRESH_ACC, FRACTION_ACC; FRACTION_ACC / PARAM_D);

[0033] According to the application, the preventive refresh sequence forms the step of causing a preventive refresh cycle which refreshes at least all the rows of the determined sub-banks, and the preventive refresh cycle of the determined sub-banks is performed in full before the number of rows activated in the determined sub-banks exceeds the critical hammer value.

[0034] According to other advantageous and non-limiting features of the application, the following operations are performed, alone or in any technically feasible combination:

[0035] - each sub-bank is associated with an activation threshold, and the preventive logic is configured to perform, each time a row of a given sub-bank among the sub-banks of the memory device is activated, a step of incrementing an activation counter associated with the given sub-bank;

[0036] - the required number of preventive refreshes of each given sub-bank is stored in a data structure;

[0037] - the data structure is organized in a tree structure;

[0038] - the step of identifying the need for a preventive refresh of the determined sub-banks consists in browsing the data structure to identify the sub-banks whose required number of preventive refreshes is greater than or equal to 1 ;

[0039] - determining the required number of preventive refreshes comprises a step of incrementing a pending refresh counter, the preventive refresh sequence comprises a step of decrementing the pending refresh counter, and the preventive refresh sequence is performed repeatedly as long as the pending refresh counter exceeds a floor value;

[0040] - when the required number of preventive refreshes of a given sub-bank reaches the value 1, the index of the given sub-bank is inserted into a list of sub-banks waiting for refresh;

[0041] - said list is formed by chaining the entries of the data structure;

[0042] - the step of identifying the need for a preventive refresh of the determined sub-banks consists in identifying that the list of sub-banks waiting for refresh is not empty;

[0043] - when the required number of preventive refreshes of a given sub-bank is lower than the value 1, the index of the given sub-bank is removed from the list;

[0044] - the required number of preventive refreshes of all the sub-banks is less than 1, and the step of identifying the need for a preventive refresh of the determined sub-banks consists in identifying, in the data structure, the sub-bank whose activation counter is the greatest, and in resetting the activation counter after triggering the operation for refresh;

[0045] - the step of identifying the need for a preventive refresh of the determined sub-bank is performed at the end of the step of incrementing the activation counter of the given sub-bank and comprises comparing the required number of preventive refreshes of the given sub-bank to a determined threshold value;

[0046] - the triggering of the operation for refreshing the current line comprises temporarily storing in a buffer memory a description of the refresh operation to be implemented;

[0047] - determining the required number of preventive refreshes comprises:

[0048] - the step of incrementing the activation counter of the given sub-bank, modulo the activation threshold value;

[0049] - in the case where the incrementing modulo the activation threshold value has reset the activation counter of the given sub-bank to zero, incrementing the required number of preventive refreshes of the given sub-bank;

[0050] - the activation counter is incremented by a parameter strictly less than the activation threshold value;

[0051] - the preventive refresh period also causes the refreshing at least twice of the low and high inner border lines of the determined sub-bank;

[0052] - the step of incrementing the activation counter associated with the given sub-bank each time a line of the given sub-bank of the memory device is activated also increments the activation counters of all other sub-banks having at least one line that can be hammered as a result of said activation;

[0053] - the activation threshold value of a sub-bank varies as a function of temperature, power supply voltage, activation frequency of the sub-bank or memory characteristics;

[0054] - the activation threshold values of different sub-banks are different;

[0055] - the step of triggering the operation for refreshing the current line comprises inserting a preventive refresh request into the control traffic intended for the memory bank in which the determined sub-bank is located;

[0056] - the activation threshold value defines a variable progress coefficient during the complete cycle of preventive refreshes of the determined sub-bank;

[0057] - the bank is decomposed into sub-banks of different sizes;

[0058] - the preventive logic is associated with a plurality of banks;

[0059] - each sub-bank is associated with an activation threshold value and the preventive logic is configured to periodically perform the step of incrementing the activation counter associated with each sub-bank and to determine the required number of preventive refreshes of the sub-bank.

[0060] According to another aspect, the application provides a DRAM memory device comprising row hammer effect prevention logic, a buffer circuit or a controller of a DRAM memory device, the row hammer effect prevention logic being configured to implement the presented protection method.

[0061] According to other advantageous and non-limiting features of the application, the following operations are performed, alone or in any technically possible combination:

[0062] - the DRAM memory device comprises at least one integrated processor;

[0063] - the DRAM memory device comprises a plurality of replacement blocks, the replacement blocks being mutually separated by any means preventing the rows of a block from being subjected to an attack due to hammering of the rows of another replacement block;

[0064] - the rows of a replacement block are intended to replace defective rows of a single sub-memory bank;

[0065] - the rows of a replacement block are intended to replace defective rows of a plurality of sub-memory banks, the rows constituting a replacement block being all the parts of the preventive refresh cycle of the sub-memory banks sharing the replacement block;

[0066] - the replacement block defines a sub-memory bank;

[0067] - the DRAM sub-memory bank comprises replacement rows, these replacement rows being part of the preventive refresh cycle of the sub-memory bank. BRIEF DESCRIPTION OF DRAWINGS

[0068] Other features and advantages of the application will become apparent in the light of the following detailed description of specific embodiments of the application, made with reference to the attached drawings, in which:

[0069] [ Figure 1a ]

[0070] Figure 1a representing part of the steps of an embodiment of the method for protecting a DRAM memory device;

[0071] [ Figure 1b ]

[0072] Figure 1b representing a preventive refresh sequence of an embodiment of the method for protecting a DRAM memory device;

[0073] [ Figure 2 ]

[0074] Figure 2 representing a second embodiment of the method for protecting a DRAM memory device;

[0075] [ Figure 3 ]

[0076] Figure 3 represents a tree data structure in an embodiment of a method for protecting a DRAM memory device. DETAILED DESCRIPTION

[0077] Definitions and reminders

[0078] In this document, the term row "topology index" designates the physical order of the row within the DRAM memory bank. By default, when referring to a row index or more simply to a row, it is the row topology index. The row logical index refers to the row index passed as a parameter of the ACTIVATE command used to activate the row, as defined in JEDEC DDR3 / 4 / 5 and similar protocols. Depending on the implementation, a row of logical index i can have the same value i as the topology index, or also a different value j, and in this case the function makes it possible to get j from i.

[0079] It can be recalled that the rows of a DRAM memory bank are periodically refreshed to compensate for the electrical charge drop of their storage points over time. The time during which all the rows of the bank are refreshed is called a refresh window. The refresh windows follow one another in time, the end of a refresh window r being followed by the beginning of a refresh window r+1.

[0080] It is also possible to refresh rows preventively, to prevent hammering effects, as is the case in this description. As described in document FR3066842A1, the execution of a preventive refresh can be done in a refresh slot initially set for a periodic refresh, the periodic refresh thus being delayed. The refresh window having inserted a preventive refresh thus has a longer duration than a refresh window executing only a periodic refresh, this increase in refresh window duration not posing a problem as long as it remains moderate. Alternative methods include, for example, reserving a slot for preventive refreshes in advance, at a fixed or variable rate relative to the periodic refreshes or relative to the number of row activations performed.

[0081] Fast row hammer prevention algorithm

[0082] A first embodiment of a method for protecting a DRAM memory device from row hammering effects, called delayed generation, is now described in detail. This process is implemented by at least one preventive logic. A memory bank comprising R rows is divided into N sub-banks of the same size, or identical within 1 row, the sub-banks comprising S rows or S+1 rows, with S equal to the integer division of R by N. (S = R / N).

[0083] For simplicity of the description, the sub-banks are considered to have the same number of rows. The skilled person will know how to extrapolate the description given below to apply them to the case where the number of rows of certain sub-banks is greater than the number of rows of other sub-banks.

[0084] A sub-bank is composed of rows that are topologically ordered, the sub-banks are topologically ordered, and typically sub-bank b contains rows with topological indices Sx b to (Sx (b+1))-1. Thus, we can designate a row by its relative row topological index as follows:

[0085] • The sub-bank notation [b] [0] designates the first row of sub-bank b,

[0086] • The sub-bank notation [b] [1] designates the second row of sub-bank b,

[0087] • The sub-bank notation [b] [2] designates the third row of sub-bank b,

[0088] •...

[0089] • The sub-bank notation [b] [i] designates the (i+1)th row of sub-bank b,

[0090] • The sub-bank notation [b] [S-1] designates the last row of sub-bank b.

[0091] The prevention logic is associated with at least one memory bank and comprises storing the following elements, which can include:

[0092] • A pending refresh variable or counter, named NBR_REFRESH_PENDING.

[0093] • A data structure, for example a table named RH_TABLE and comprising N entries (N is the number of sub-banks), each entry of the table comprising the following three fields:

[0094] o A field named FRACTION_ACC, forming an activation counter and counting from 0 to the value PARAM_D-1. PARAM_D is a parameter that can be constant for a given implementation and defines a threshold for the activation of a sub-bank.

[0095] o A REFRESH_ACC field, which can take values from 0 to a sufficient value. In a first implementation mode, this field defines the required number of preventive refreshes of the arrangement in the sub-bank (and more precisely, the integer part of this number, as will be detailed later).

[0096] o A current index named RELATIVE_INDEX, which can take values from 0 to S-1.

[0097] When the DRAM memory device is reset (RESET), the logic is initialized as follows:

[0098] • The NBR_REFRESH_PENDING refresh counter is set to 0.

[0099] • all fields of all entries in the RH TABLE data structure are set to 0.

[0100] In the described first implementation mode and with reference to Figure 1a During normal operation of the DRAM memory device and at each activation of a bank targeting a row belonging to a sub-bank b, the prevention logic performs the following processing:

[0101] • if RH TABLE[b].FRACTION ACC == PARAM D - 1, then:

[0102] o RH TABLE[b].FRACTION ACC is set to 0,

[0103] o RH TABLE[b].REFRESH ACC is incremented by 1,

[0104] o NBR_REFRESH_PENDING is incremented by 1,

[0105] • else RH TABLE[b].FRACTION ACC is incremented by 1.

[0106] In other words, in this first implementation mode, at each activation of a row of a sub-bank b of the memory, the step of incrementing the required number of preventive refreshes REFRESH ACC is performed by executing the following steps:

[0107] • if the activation counter FRACTION ACC of the sub-bank b equals the activation threshold PARAM D - 1, the required number of preventive refreshes REFRESH ACC of the sub-bank b is incremented, the pending refresh counter NBR_REFRESH_PENDING is incremented, and the FRACTION ACC activation counter associated with the sub-bank b is reset to 0.

[0108] • else, the activation counter FRACTION ACC of the sub-bank b including the activated row is incremented.

[0109] Hence, the increment of FRACTION ACC is done modulo the activation threshold PARAM D.

[0110] In parallel, in the background, the prevention logic of this first implementation mode performs as long as there is at least one pending refresh, i.e. as long as NBR_REFRESH_PENDING > 0, the following processing: Figure 1bThe preventive refresh sequence is illustrated in the figure. As long as the pending refresh counter NBR_REFRESH_PENDING is not zero (and more generally as long as it exceeds a bottom value), then the preventive logic inserts in the command stream to the memory bank a preventive refresh of a row as fast as possible, the preventive logic computing the topological index for this row as follows:

[0111] • The RH TABLE data structure is scanned to identify the entry j (i.e. sub-bank) having the highest value of the required number of preventive refreshes REFRESH ACC. In case several entries are equal, one of them is chosen. In this way, during the locating step, the sub-bank j of the memory device most in need of preventive refresh is identified.

[0112] • The RH TABLE [j]. REFRESH ACC field is decremented by 1, i.e. the required number of preventive refreshes associated with the sub-bank j is decremented by 1.

[0113] • The logic decrements the pending refresh counter NBR_REFRESH_PENDING.

[0114] • The relative topological index of the row of the sub-bank j selected for preventive refresh is the value of the data structure RH TABLE [j]. RELATIVE INDEX, and the preventive refresh operation of the current index row RELATIVE INDEX of the sub-bank j concerned is triggered.

[0115] • RH TABLE [j]. RELATIVE INDEX is incremented modulo S, that is to say the current index RELATIVE INDEX of the sub-bank j is incremented modulo S to cycle through this sub-bank.

[0116] Note that the use of the pending refresh counter NBR_REFRESH_PENDING as presented in this particular implementation mode is not essential. Unlike the execution of the preventive refresh sequence (and in particular the identification of the need for preventive refresh of a sub-bank j) can be performed unconditionally, even without knowing whether the entries of the data structure contain a required number of preventive refreshes REFRESH ACC not equal to zero, conditioned by the non-emptiness of this NBR_REFRESH_PENDING counter.

[0117] As the preventive refresh sequence inserts in the command stream to the memory bank a preventive refresh of a single row (or several rows), this sequence does not block the access to the sub-bank. This is the reason why the preventive refresh sequence is said to be performed "simultaneously" with the normal access to the sub-bank.

[0118] It is also noted that the pair {REFRESH ACC, FRACTION ACC} represents a non-integer number of preventive refreshes of the lineup, the REFRESH ACC of the pair being the integer part, the latter indicating the number of pending preventive refresh operations of the given sub-bank. In this first implementation mode with deferred generation, it can be strictly greater than 1, that is to say that the sub-bank can have been activated enough times to require several preventive refreshes, but has not yet initiated any such operation. Depending on the memory protocol considered, the delay for inserting a preventive refresh into the memory traffic can be such that the backlog of pending preventive refreshes, possibly belonging to different sub-banks, can temporarily exceed several tens of preventive refreshes.

[0119] As presented later in this description, the required number of preventive refreshes can also have a non-integer value.

[0120] Unlike the solution proposed by FR 3066842 Al, the search in the RH TABLE data structure is not limited by the very short minimum time separating two activations, but by the longer and more flexible time separating the insertion of two preventive refreshes.

[0121] In a first implementation mode, the required number of preventive refreshes of the lineup REFRESH ACC, FRACTION ACC of each sub-bank is stored in the data structure RH TABLE. The counters and the current index of this structure, associated with a sub-bank, are stored in such a way that the preventive refreshes wait to be implemented. The refresh operations themselves are triggered when they can be performed. The advantage is that no buffer memory is required, but a background task must scan the counters associated with the sub-banks to search for pending refresh operations.

[0122] The preventive refresh sequence can take other forms than the one aiming at browsing the data structure RH TABLE in the background during the identification step, as just presented in the implementation mode with deferred generation.

[0123] Thus, according to a second implementation mode called "immediate generation", the preventive refresh sequence is directly performed at the end of the step of incrementing the required number of preventive refreshes REFRESH ACC of the sub-bank b. In this case, and with reference to Figure 2, in the case where the required number of preventive refreshes REFRESH ACC of this sub-bank reaches or exceeds the threshold value 1, the preventive refresh operation of the sub-bank b concerned is prepared. This comparison constitutes the step of identifying the need for a preventive refresh of the rank of the sub-bank concerned. If the following steps of the preventive refresh sequence are continued, the required number REFRESH ACC is decremented. Thus, REFRESH ACC cannot exceed the value 1 and can only have this value very briefly, thus making it possible in a mode called "on-the-fly generation" not to need the REFRESH ACC field, then the required number of preventive refreshes being represented only by the non-integer value (in fact a fraction) FRACTION ACC, which always remains less than 1. This is the reason why the optional incrementation step and the decrementation step of REFRESH ACC in Figure 2

[0124] In this second implementation mode of on-the-fly generation, the preventive refresh operation is triggered exactly at the moment when the need is discovered and, in the case where it cannot be executed immediately, the request is stored briefly in a buffer memory (like a non-limiting example FIFO buffer) to make the implementation of this request pending. In other words, the triggering of the operation to refresh the current row comprises the temporary storage in the buffer memory of a description of the refresh operation to be implemented. The step of identifying the need for a preventive refresh of the rank of the sub-bank is performed in conjunction with the step of incrementing the REFRESH ACC counter (or the FRACTION ACC counter), no longer forming a background task, but as soon as the need is identified, as in Figure 2 It can be seen that the addition is made on the sequence triggered at each activation of the row.

[0125] This second mode has the advantage of not needing a background task running by the counter associated with the sub-bank.

[0126] General operation principles

[0127] As mentioned in the previous part, in both delayed generation or on-the-fly generation, the preventive refresh sequence triggers an operation to refresh a single row of the sub-bank. Possibly, the preventive refresh sequence can trigger an operation to refresh several rows of the sub-bank but always much less than the total number of rows in this sub-bank. This principle will limit the time during which the sub-bank is accessed for the preventive refresh operation to the time needed to perform a single or several activations.

[0128] ​According to the logic of the application, the refresh of all the rows of a given sub-bank forms a preventive refresh cycle of this sub-bank. Unlike the refresh window, the preventive refresh cycle is not related to the concept of time or delay, the time taken by the preventive refresh cycle is not limited: in case the rows of a sub-bank are never activated, the required number of preventive refreshes does not increase and the current refresh cycle of this sub-bank does not advance and thus takes an infinite time.

[0129] Each activation of a row belonging to a sub-bank contributes to advancing the required number of preventive refreshes and thus to advancing the current preventive refresh cycle of this sub-bank, which cycles through the rows of this sub-bank. The PARAM_D activation threshold makes it possible to establish, for each activation of a row of this sub-bank, a percentage of advancement of the refresh cycle of the sub-bank. This parameter, i.e. this percentage of advancement, also designated by "advancement coefficient" or "preventive refresh coefficient" in the rest of this description, is chosen, i.e. defined by the value 1 / PARAM_D; or more generally, as detailed below, by the value PARAM_N / PARAM_D, in such a way that the preventive refresh cycle is performed in less activations than the minimum number of activations required to destroy the content of a row by hammering its adjacent rows (critical hammering value).

[0130] Thus, in case the FRACTION_ACC activation counter is 5 bits wide, the possible range of values for the PARAM_D activation threshold ranges from 1 to 32:

[0131] • PARAM_D = 1

[0132] o 1 activation causes 1 preventive refresh

[0133] o preventive refresh coefficient = 100%

[0134] • PARAM_D = 2

[0135] o 2 activations cause 1 preventive refresh

[0136] o preventive refresh coefficient = 50%

[0137] •...

[0138] • PARAM_D = 31

[0139] o 31 activations cause 1 preventive refresh

[0140] o preventive refresh coefficient = 3.2%

[0141] • PARAM_D = 32

[0142] o 32 activations cause 1 preventive refresh

[0143] o Preventive refresh coefficient = 3.1%

[0144] By way of example, and considering that a memory bank composed of 65536 lines is divided into 256 sub-banks, each having 256 lines, the data structure RH TABLE has 256 entries, one for each sub-bank. For a critical hammer value of 5000 for a line with respect to a directly adjacent line, the method according to the application does not compute the attack hammer value, and therefore does not require a hammer coefficient with a scope greater than 1. However, in 5000 activations, the 256 lines of the sub-bank must be refreshed preventively, that is to say, the progress coefficient must be 256 / 5000, or 5.12%. The value of the activation threshold PARAM D, which provides a progress coefficient of 5.2%, provides a minimal progress coefficient which seems appropriate. Considering that the preventive refresh itself is indeed an activation, the computation of the progress coefficient can be:

[0145] 256 / (5000 - 256) = 5.39%

[0146] Thus, the value of the activation threshold PARAM D, which provides a progress coefficient of 5.55%.

[0147] In general, the activation threshold PARAM D of a given sub-bank should be chosen according to the following formula:

[0148] PARAM D < E[(C-S) / S]

[0149] In the formula, the function E is the integer part function, C is the critical hammer value for a line in the given sub-bank, and S is the number of lines in the given sub-bank.

[0150] Then, between two preventive refresh cycles, it becomes impossible to destroy the content of adjacent lines with such a progress coefficient S / (C-S) by hammering a line enough times, because these adjacent lines are already preventively refreshed before reaching the critical hammer value.

[0151] In other words, the complete preventive refresh cycle of a sub-bank is operated before the number of activations of a line in the sub-bank exceeds the critical hammer value.

[0152] The smaller the size of the sub-bank, the lower the required progress coefficient, and therefore the lower the performance penalty (% of preventive refresh per activation).

[0153] Management of the impact at the borders of sub-banks

[0154] The sub-banks of a DRAM bank can be physically separated by a distance and / or hardware elements, such that an activation of a row located near one of the two ends of a sub-bank does not cause damage to the content of rows of the adjacent sub-bank due to hammering. This is particularly true in case the sub-banks are separated by sense amplifiers in the middle of several rows. In this case, the logic described in the previous section has accurately prevented the hammering effect.

[0155] A first solution for making the refresh period intrusive in the adjacent sub-banks can be implemented when the hammering effect crosses the border of a sub-bank. This solution uses the concepts of low border, high border and core of a sub-bank:

[0156] • The low outer border of sub-bank b is the set of last rows of sub-bank b-1 that can be affected by an activation of one of the first rows of sub-bank b.

[0157] • The low inner border of sub-bank b is the set of first rows of sub-bank b that can be affected by an activation of one of the last rows of sub-bank b-1.

[0158] • The high outer border of sub-bank b is the set of first rows of sub-bank b+1 that can be affected by an activation of one of the last rows of sub-bank b.

[0159] • The high inner border of sub-bank b is the set of last rows of sub-bank b that can be affected by an activation of one of the first rows of sub-bank b+1.

[0160] • The core of sub-bank b is the set of rows of sub-bank b that do not belong to the inner borders of sub-bank b.

[0161] As the row hammering effect is symmetrical (the way an activated row i attacks row i+n is similar to the way an activated row i+n attacks row i), the border definition implies that:

[0162] • The low inner border of bank b is the high outer border of bank b-1,

[0163] • The high inner border of bank b is the low outer border of bank b+1.

[0164] The full refresh period of a sub-bank is then extended such that it refreshes twice the rows that belong to the low and high borders (inner and outer) of this sub-bank.

[0165] In a refresh period that includes P preventive refreshes, the two refreshes of the border row MR are distributed in an even way: the first preventive refresh of row MR is separated from the second preventive refresh of row MR by P / 2 preventive refreshes for the other rows.

[0166] This double refresh of the border row is advantageous because:

[0167] • The border row will be attacked by activating its own sub-bank up to the critical hammer value -1.

[0168] • The border row will be attacked by activating the sub-bank closest to the border row up to the critical hammer value -1.

[0169] Therefore, the border row is under twice the attack threat of one of the non-border rows, and therefore needs to be refreshed twice as fast as the non-border rows (core rows) by preventive refresh cycles, which is achieved by having each refresh cycle refresh the border rows (inner and outer) of its corresponding sub-bank twice in an equalized manner.

[0170] If necessary, the field storing the current RELATIVE_INDEX index is widened so as to have enough power to scan the border twice in addition to scanning the sub-bank core once.

[0171] Another solution to the hammering problem at the junction of a sub-bank aims at increasing the required number of preventive refreshes REFRESH_ACC associated with the neighboring sub-banks. This solution can be achieved by applying the following rules:

[0172] • The step of incrementing the field RH_TABLE[b - 1].REFRESH_ACC is also performed during the activation of one of the first rows of the sub-bank b.

[0173] • The step of incrementing the field RH_TABLE[b + 1].REFRESH_ACC is also performed during the activation of one of the last rows of the sub-bank b.

[0174] In other words, when the activated row of the sub-bank b is one of the first rows of the sub-bank b, the row hammer management operation is performed on the bank b as previously described, but also on the bank b - 1 as if the activation also involved rows of this bank b - 1. Similarly, when the activated row of the sub-bank b is one of the last rows of the sub-bank b, the row hammer management operation is performed on the bank b as previously described, but also on the bank b + 1 as if the activation also involved rows of this bank b + 1. For example, these first / last rows can be related to the first / last 2, 3 or 5 rows of the sub-bank b.

[0175] Generalized sub-bank activation rules

[0176] More generally, this method can advantageously be incorporated into the implementation mode of "delayed generation" first described: during the activation of a given row, the step of incrementing the number of preventive refreshes REFRESH ACC is performed for all sub-banks containing rows that can be hammered by the activation of the given row. It will be clear later that this can apply to sub-banks replacing their rows for defective rows used to replace standard sub-banks.

[0177] In the case where the scope of the row hammer effect is significant (or even greater) with respect to the scale of the sub-banks, this generalized sub-bank activation rule is particularly useful for resolving border hammering, since in these cases more than one sub-bank in the vicinity of the activated sub-bank can be hammered.

[0178] In a first example, in the case where the scope of the row hammer is greater than half the scale of the sub-bank, activating a row in the middle of the sub-bank can hammer a row in the preceding sub-bank and a row in the following sub-bank at the same time.

[0179] In a second example, in the case where the scope of the row hammer is slightly greater than the scale of the sub-bank:

[0180] - activating one of the first rows of the sub-bank will hammer the two preceding sub-banks and the following sub-bank

[0181] - activating one of the middle rows of the sub-bank will hammer the preceding sub-bank and the following sub-bank

[0182] - activating one of the last rows of the sub-bank will hammer the preceding sub-bank and the two following sub-banks

[0183] These two examples are completely covered by the generalized sub-bank activation rule. The person skilled in the art will realize that the generalized sub-bank activation rule allows for the handling of any kind of border, including borders extending across several sub-banks, and that this rule is particularly applicable in the case where the scope of the row hammer is significant with respect to the scale of the sub-banks.

[0184] Thus, advantageously, the step of incrementing the activation counter, each time a row of a sub-bank of the memory is activated, increments the activation counter of all the sub-banks having at least one row that can be hammered as a result of this activation.

[0185] Index scan order in sub-banks

[0186] The order of the row scan is not important whether the refresh period includes a border or not, as long as the order of the row scan is fixed for a given sub-bank (and associated border, if applicable) and the double preventive refreshes are distributed in a balanced manner in the preventive refresh period. For simplicity of the illustration, an increment modulo S is assumed, but any scan order respecting the previously mentioned rules is suitable as long as each row of the considered sub-bank and each row of the border is reached by the scan. It is in particular possible to very advantageously provide over-refreshs of the rows of the DRAM memory device identified as more sensitive to row hammer attacks (these over- refreshes must also be distributed in a balanced manner in the refresh period).

[0187] Thus, the refresh period can be such that the rows identified as more particularly sensitive to hammer attacks during the manufacturing test can be configured in such a way that the refresh period running in the sub-bank to which they belong will refresh them several times. The multiple refreshes of the sensitive rows are advantageously regularly distributed in the corresponding refresh period.

[0188] In the preventive refresh period, the rows identified as robust can be refreshed only the normal number of times (once for the rows belonging to the core, twice for the rows belonging to the inner or outer border).

[0189] Thus, by way of non-limiting example, in the case where the sensitive row S is refreshed twice in the refresh period, these two refreshes are distributed in a balanced manner in the corresponding refresh period, then the critical hammer value protecting the row S will be twice as low as the critical hammer value of the other rows of the corresponding sub-bank.

[0190] Other methods to implement the processing

[0191] Variations of the first and second implementation modes of the method can apply an alternative representation of the percentage of progress of the refresh period caused by the activation to ensure that the complete preventive refresh period of the sub-bank is operated before the number of row activations in the sub-bank exceeds the critical hammer value.

[0192] Thus, according to the variation of the implementation mode of the method just presented, called "by fractional representation with fixed denominator", it can be implemented without the activation counter REFRESH_ACC. In such a mode, the activation counter FRACTION_ACC field of the RH_TABLE data structure will be at least as wide as the activation counter REFRESH_ACC has.

[0193] In such a case, the required number of preventive refreshes is given by the integer part of the ratio FRACTION ACC / PARAM D, and the method comprises, at each activation, incrementing the activation counter FRACTION ACC by the value PARAM N. PARAM N is a parameter associated with the sub-bank, which is strictly lower than the activation threshold PARAM D of this sub-bank, and which can be constant for a given implementation. When a preventive refresh operation is triggered (to be performed immediately or stored in a buffer), the corresponding FRACTION ACC field is decreased by the activation threshold PARAM D.

[0194] This method expresses the progress coefficient by the ratio PARAM N / PARAM D.

[0195] This expression has the drawback of making it more difficult to update the pending refresh counter NBR_REFRESH_PENDING, but as has been pointed out, this variable is not necessary for implementing the method according to the application.

[0196] When hammering effects are likely to cross the boundaries of a sub-bank, the process can be adapted to the use of a parameter PARAM N:

[0197] • during the activation of one of the first lines of a sub-bank b, a step is performed of incrementing the RH TABLE[b-1].FRACTION ACC field, using an increment value which is less than or equal to the parameter PARAM N.

[0198] • when one of the last lines of a sub-bank b is activated, a step is performed of incrementing the RH TABLE[b+1].FRACTION ACC field, using an increment value which is less than or equal to the parameter PARAM N.

[0199] In the case where the power of the hammering effect across the boundaries of a sub-bank is lower than the power of the hammering effect between two adjacent lines of the same sub-bank, the increment value is chosen to be lower than the parameter PARAM N.

[0200] Simplification of the search in the RH TABLE data structure to identify the need for preventive refresh of a sub-bank

[0201] The skilled person will understand that the preventive refresh sequence running in the background of the so-called first delay generation implementation mode can be simplified while remaining within the framework of the application. By way of example, instead of looking in the RH TABLE data structure for the entry having the REFRESH ACC field (or FRACTION ACC field) with the highest value (representing the required number of preventive refreshes in line) we can select from this structure the first entry having the REFRESH ACC field (or FRACTION ACC field) with a value presenting the fact that at least one refresh is pending (for example, a number greater than or equal to 1 in the case of the first implementation mode of the process).

[0202] In this hypothesis, even the search in the background can be eliminated without having to rely on additional buffers, which is necessary in the second implementation mode. To this end, the TABLE RH data structure is extended by adding to each of the entries of this structure a field named NEXT, intended to contain the index of the entry in the RH table, or the end of list value IST END indicating that this field does not point to any entry in the RH table. This logic is also provided with a variable FIRST specifying the head of the list, having the same storage capacity as the field NEXT of the TABLE RH data structure.

[0203] The list head variable FIRST and the field NEXT of the entries in the TABLE RH data structure allow the construction of a chained list of entries within the TABLE RH data structure itself, each element of the list corresponding to a sub-memory bank requiring a preventive refresh operation. The first entry in the list is specified by the content of the head variable FIRST. An empty list is indicated by the fact that the head variable FIRST contains the end of list value LIST END. Any element L of the list points via its field RH[L].NEXT to the next element M of the list, that is to say RH[L].NEXT = M. The last element of the list is identified by the fact that its NEXT field has the end of list value LIST END.

[0204] This chained list is updated in such a way that it contains all the entries of the TABLE RH data structure having a required number of preventive refreshes that is non-zero.

[0205] At the initialization (reset) of the memory device, the list head FIRST variable is set to the end of list value LIST END, indicating that the list of sub-memory banks having a required number of preventive refreshes that is non-zero is initially empty:

[0206] • FIRST = LIST END,

[0207] When the increment step performed after the activation of the sub-bank changes the required number of precautionary flushes of the entry (i.e. of the entry of the sub-bank) J from 0 to 1, then the corresponding entry J is inserted in the list as follows:

[0208] • RH[J].NEXT = FIRST,

[0209] • FIRST... = J,

[0210] In case the required number of precautionary flushes of an entry is not zero, then incrementing this number does not modify neither the head variable FIRST nor any field NEXT. In other words, when the required number of precautionary flushes changes from 0 to 1, an entry of the data structure is inserted in the list only once. Changing this number to a value greater than 1 has no effect on the list.

[0211] In case there is an opportunity to trigger a precautionary flush operation, the precautionary flush sequence is initiated and, during the identification step, we select the entry of the data structure TABLE_RH designated by the head variable FIRST of the list. In case this variable FIRST presents a value corresponding to the end of the list LIST_END, then there is no precautionary flush to perform.

[0212] When the trigger of the precautionary flush operation of a sub-bank changes, for the corresponding entry J, the required number of precautionary flushes changes from 1 to 0 and then the entry J is deleted from the list as follows:

[0213] • FIRST = RH[J].NEXT

[0214] Thus, during the tracking step, there is no more need to perform a background search in the RH table since the list of entries with pending flushes is maintained permanently:

[0215] • When the increment step is performed: the list is permanently maintained, if necessary, by inserting the corresponding entry in the list.

[0216] • When a flush operation is triggered: the list is permanently maintained, if necessary, by deleting the corresponding entry from the list.

[0217] The skilled person will understand that the method aiming at forming a list of sub-banks having a required number of preventive refreshes different from zero has been described for the purpose of presenting a non-limiting example. The management of the list can be modified in various ways, for example by adding a list variable tail LAST specifying the last element of the list, allowing to insert new elements at the end of the list instead of at its beginning. Such a method can be advantageous to perform a preventive refresh management process making it possible to prevent the need for a preventive refresh linked to a given sub-bank from being indefinitely delayed due to new activations for other sub-banks.

[0218] It should be noted that the fact of using a simplified search algorithm or of using a list can lead to the need to provide an increased margin when calculating the processing parameters, in particular in the case where the time slots available to perform preventive refreshes suffer from significant delays. The only constraint that the preventive refresh sequence running in the background must prioritize is to avoid starvation: in the case where the number of activations completed is not deterministic, it is not possible to refuse an entry of the data structure RH TABLE having a required number of preventive refreshes different from zero without having the possibility to advance the corresponding preventive refresh period.

[0219] Default use of preventive refresh slots

[0220] In the case where a time slot to perform a preventive refresh is available and can only be used for such a refresh, and in the case where the search in the RH TABLE data structure or in the list does not provide a candidate for the targeted refresh, the best default strategy consists in selecting the refresh period of the sub-bank whose entry in the RH TABLE structure has the largest and thus the closest to the threshold determining whether a preventive refresh is pending FRACTION ACC field (that is to say to trigger the refresh operation).

[0221] The execution of the preventive refresh is not such that FRACTION ACC is decremented, but the field is set to 0, preventing the field from taking negative or inconsistent values.

[0222] Insertion of preventive refresh

[0223] The hammering prevention logic inserts the preventive refresh in the control traffic to the sub-banks. This can be achieved for example in the following ways:

[0224] • by borrowing a periodic refresh time slot, the periodic refresh being delayed for a period short enough that this does not cause any problem,

[0225] • by having enough time slots for preventive refreshes in the memory protocol,

[0226] • the prevention logic provides the topology row index by indicating to the memory controller that it has to generate one or more time slots for preventive refreshes.

[0227] The skilled person will understand that the solution to the problem of inserting preventive refresh traffic also depends on the location where the logic described herein is implemented (controller of the DRAM, RCD buffer circuit, i.e. register clock driver buffer circuit placed between the memory controller and the DRAM, or the DRAM memory itself), and on the capabilities of the protocol between the memory controller and the memory. It should be noted that in the case where the logic is placed in the DRAM memory comprising one or more integrated processors, the insertion method described by document FR3066842A1 can be used. Other methods can also be used, with or without the need to cooperate with the memory controller.

[0228] Support of sub-banks of different sizes

[0229] Due to manufacturing variability, the row hammer sensitivity can vary significantly from one row to another within a bank.

[0230] Instead of configuring the row hammer logic for the worst case, considering the row most sensitive to row hammer, a first possibility consists in providing a dedicated activation threshold PARAM_D for each sub-bank according to the row hammer sensitivity of the rows of this sub-bank and the row hammer sensitivity of its neighboring rows. Depending on the row hammer sensitivity of the activated row, this induces a fluctuation of the amount of preventive refreshes per activation. This dedicated activation threshold PARAM_D can be determined according to initial tests of the memory device, to identify the sensitivity of each sub-bank to row hammering, and the appropriate activation threshold for each entry of the data structure RH TABLE.

[0231] A second possibility is to use sub-banks of different sizes. This can be achieved by Figure 3 in a non-limiting example manner, i.e. by adding a bit to each data structure RH TABLE entry:

[0232] When this bit is cleared, the data structure RH TABLE entry holds the corresponding activation counter FRACTION ACC, the required number of preventive refreshes REFRESH ACC and the current index RELATIVE INDEX as previously described.

[0233] When this bit is set, the data structure RH_TABLE entry does not represent this information, but designates, in a dedicated memory or in the same memory as the one holding the data structure RH_TABLE, the location (address) of a smaller additional data structure SUB-RH_TABLE corresponding to the subdivision of the sub-bank b into smaller sub-banks. The algorithm described previously applies to the sub-banks: the normal size sub-banks and the similar smaller sub-banks. In the case where the size of the smaller additional data structure SUB-RH_TABLE is not inherent (i.e. predetermined and constant), the entry additionally designating the location of the SUB-RH_TABLE will designate its size.

[0234] The smaller sub-banks have a smaller preventive refresh period, and therefore support a lower critical activation value for a given activation threshold PARAM_D. Advantageously, the smaller sub-banks will be defined so that the weakest row in the bank, the one most sensitive to row hammering, will belong to the smaller sub-bank. Similarly to the first possibility above, after initial testing of the memory device, the division of the memory bank into sub-banks of different sizes can be performed, and the corresponding configuration of the data structure RH_table using pointers to additional data structures to identify the sensitivity of each bank and the need to divide it into smaller sub-banks can be performed.

[0235] The person skilled in the art will understand that, while remaining within the framework of the application;

[0236] - the previously explained border handling strategy can be extrapolated to handle sub-banks of different sizes, the generalized sub-bank activation rule becomes particularly relevant, since the row hammering scope is necessarily more significant relative to the size of the smaller sub-banks.

[0237] - the sub-banks of different sizes do not exclude having an activation threshold PARAM_D personalized for each sub-bank, whether the sub-bank is of normal size or of smaller size.

[0238] - other mechanisms can be used to determine whether the data structure RH_TABLE entry includes the usual fields or describes a smaller sub-RH_TABLE, in particular the use of other unused values in one of the usual fields, and the looping of other usual fields into a field designating a location (address), and possibly into the size of an additional data structure SUB-RH_TABLE in a dedicated memory or in the same memory as the one holding the data structure RH_TABLE.

[0239] - more than 2 levels of data structure RH_TABLE (with SUB-SUB-RH_TABLE, etc.) can be used, the division of the bank into sub-banks of different sizes can be achieved by a tree structure.

[0240] - Other mechanisms including the use of memories with a discontinuous and configurable address mapping can be used to implement data structures that handle sub-banks of different sizes, so that the size of any sub-bank can be determined and the fields associated with any sub-bank can be accessed.

[0241] Preventive logic common to several banks

[0242] Instead of associating row hammer prevention logic with each bank, such logic can be associated with several banks. For example, in the case where the same logic is associated with two banks B1 and B2, then when a row is activated in a sub-bank b of B1 or B2, the entry of the table RH TABLE [b] will be updated as previously explained. When the logic detects that a preventive refresh must be performed on a row R, then the row R of the banks B1 and B2 is preventive refreshed. In the case where the row hammer prevention logic is adjusted according to the weakest row, for example by having each sub-bank have an activation threshold PARAM D or / and sub-banks of different sizes, then for this adjustment, the weakest row from both B1 and B2 must be considered.

[0243] Row replacement and hammering

[0244] During the manufacturing of a DRAM memory, rows that are detected as defective can be replaced by replacement rows, also called spare rows, a set of which can be used to repair a memory bank. These replacements are made by programming, electrically or by laser, from a repair configuration fuse. Thus, the topology of the memory bank is altered. For example, the topology index row 30 and the topology index row 20 30 of the same memory bank are replaced by the replacement rows 0 and 1 respectively, the two latter being physically adjacent.

[0245] Because the rows 30 and 20 30 are too far apart, belonging to even not neighbor sub-banks, the prevention logic naturally does not consider the possibility of hammering between row 30 and row 20 30. But in fact, they can influence each other via the hammering effect, because the rows that replace them are actually adjacent.

[0246] To solve such a situation, replacement rows are grouped into replacement blocks, the latter being configured to respect the following principles:

[0247] • Within a replacement block, rows are separated by a distance that is typically separating two rows and thus they can cause a hammering between them.

[0248] • Replacement blocks are separated from each other by electrical shields or any other means that prevent the rows of a replacement block from causing a row hammer to the rows of another replacement block. For example, these shields can be produced by rows that are not used as memory, the selection lines of which are maintained at a constant electrical value.

[0249] • The rows of a replacement block can only be used to replace defective rows of a single sub-memory, while on the other hand several replacement blocks can be used to replace defective rows of a single sub-memory.

[0250] Respecting these principles ensures that the accuracy of the method according to the application is not affected by the replacement of rows in sub-memories.

[0251] By ensuring that all rows of the replacement block are part of the refresh period of all sub-memories sharing the block, the replacement block can be shared between several sub-memories.

[0252] Another way of sharing a replacement block is to make the replacement block a sub-memory itself, the replacement sub-memory likely having a different number of rows, these replacement sub-memories preferably not having a boundary, activating any row of a regular sub-memory that has a row replaced with a replacement row from one or more replacement sub-memories results in an increment step with respect to both the regular sub-memory and the one or more replacement sub-memories, these later increment steps using an activation threshold adapted to the number of rows of the replacement sub-memory.

[0253] Another way of sharing a replacement sub-memory is to have a row index translation step executed by logic configured with a repair fuse, wherein a defective row changes its topological index to the topological index of the row replacing it, the replacement row being located in a replacement sub-memory, upon activating initially for the replacement row, this replacement sub-memory instead of the sub-memory comprising the replacement row undergoes a compliance increment step.

[0254] Integration of periodic refresh

[0255] It is feasible to integrate the periodic refresh logic partially into the preventive refresh logic: the periodic refresh logic periodically selects a sub-memory and executes an increment step, possibly using a different PARAM_N value when using a PARAM_N value, by doing so, ensuring that even in the absence of an activation for a sub-memory, the preventive refresh period of each sub-memory is completed within a limited time, by the fact, ensuring the function of the periodic refresh, such refresh period is now called hybrid refresh period.

[0256] When the original preventive refresh period has no margin, each sub-memory cannot attack the other sub-memories and the hybrid refresh period can be executed in an optimal way.

[0257] When the original preventive refresh period is extended to include the boundary rows, the hybrid refresh period is slightly sub-optimal as the boundary rows are refreshed periodically with a factor of two.

[0258] When the handling of the boundaries is done by implementing an increment step on the neighboring sub-banks, the hybrid refresh cycle is here again slightly sub-optimal, as some rows will be refreshed periodically more often than needed.

[0259] Of course, the application is not limited to the described embodiments and variants can be added thereto without departing from the scope of the application as defined by the claims.

[0260] Thus, for example, we can consider:

[0261] • representing the progress coefficient of the preventive refresh cycle by other methods and mathematical representations;

[0262] • representing a variable progress coefficient during the preventive refresh cycle, during which the average value of the refresh cycle is equal to or greater than the value that should be used for a constant rate.

[0263] • advancing the preventive refresh cycle by a set of preventive refreshes instead of by a preventive refresh;

[0264] • having a progress coefficient of the preventive refresh cycle according to fluctuations in the activation frequency;

[0265] • fluctuating the progress coefficient of the preventive refresh cycle with fluctuations in the temperature or supply voltage, which parameters affect the power of the row hammer phenomenon;

[0266] • having a progress coefficient of the preventive refresh cycle that fluctuates with fluctuations in the variable characteristics of the manufacturing process (speed of the transistors or other capacitors, leakage, resistance of the various components of the circuit, inductance);

[0267] • adapting the progress coefficient of the preventive refresh cycle to the specific sensitivity of the rows of the preventive refresh cycle that make up the sub-bank: during the manufacturing tests, such sensitivities can be determined and each sub-bank can be associated with its own progress coefficient of the preventive refresh cycle. The progress coefficient specific to each sub-bank is recorded in a laser fuse, an electrician or other, or loaded from a non-volatile memory or any other similar device during initialization.

Claims

1. A method for protecting a DRAM memory device from row hammer effects, the memory device comprising a plurality of memory banks consisting of memory banks, the method being implemented by at least one prevention logic configured to define sub-banks dividing each memory bank as portions of consecutive rows, the prevention logic being configured to, each time a row of a given sub-bank is activated, perform a step of incrementing an activation counter associated with the given sub-bank, and the prevention logic being configured to perform a preventive refresh sequence comprising: - The step of identifying the need for preventative refresh of a determined sub-memory in the sub-memory of the memory device; - The step that triggers the operation to refresh the current row specified by the current row index associated with the determined sub-store; - The step of incrementing the current row index associated with the determined sub-store; The preventive refresh sequence forms a progress percentage of the preventive refresh cycle, the preventive refresh cycle causing at least a refresh of all rows of the determined sub-memory, and the preventive refresh cycle of the determined sub-memory is fully executed before the number of active rows in the determined sub-memory exceeds a critical hammer value.

2. The method according to claim 1, wherein, Each sub-memory is associated with an activation threshold, and the prevention logic is configured to determine the required number of preventative refreshes for a given sub-memory.

3. The method according to claim 2, wherein, Determining the required number of preventative refreshes includes incrementing a pending refresh counter, the preventative refresh sequence includes decrementing the pending refresh counter, and the preventative refresh sequence is repeated as long as the pending refresh counter exceeds a minimum value.

4. The method according to claim 2, wherein, When the required number of preventative refreshes for a given sub-memory reaches a value of 1, the index of the given sub-memory is inserted into the list of sub-memories awaiting refresh.

5. The method according to claim 4, wherein, The list is formed by linking entries in the data structure.

6. The method according to claim 4, wherein, The step of identifying the need for preventative refresh of the identified sub-memory is to ensure that the list of sub-memory awaiting refresh is not empty.

7. The method according to claim 4, wherein, When the required number of preventative refreshes for a given sub-store is less than 1, the index of the given sub-store is removed from the list.

8. The method according to claim 2, wherein, The step of identifying the need for preventative refresh of the determined sub-memory is performed at the end of the step of incrementing the activation counter of the given sub-memory, and includes comparing the required number of preventative refreshes of the given sub-memory with a determined threshold.

9. The method according to claim 2, wherein, Determining the required number of preventative refreshes includes: The steps of incrementing the activation counter of the given sub-memory and taking the modulo of the activation threshold; If the step of incrementing the activation threshold has already reset the activation counter of the given sub-memory to zero, the required number of preventative refreshes of the given sub-memory is incremented.

10. The method according to claim 9, wherein, The activation counter increments by a parameter that is strictly less than the activation threshold.

11. The method according to claim 2, wherein, The step of incrementing the activation counter associated with the given sub-memory each time a row of the memory device is activated also increments the activation counters of all other sub-memory cells that may be hammered due to the activation.

12. The method according to claim 2, wherein, The activation threshold of the sub-memory varies with temperature, power supply voltage, activation frequency of the sub-memory, or memory characteristics.

13. The method according to claim 2, wherein, The activation thresholds differ for different sub-memories.

14. The method according to claim 1, wherein, Triggering an operation to refresh the current row includes storing the operation in a buffer.

15. The method according to claim 1, wherein, The preventative refresh cycle also causes the rows at the low inner boundary and the high inner boundary of the identified sub-memory to be refreshed at least twice.

16. The method according to claim 1, wherein, The steps to trigger the operation to refresh the current row include inserting a preventative refresh request into the control flow intended for the memory bank where the identified sub-memory resides.

17. The method according to claim 1, wherein, The storage block is broken down into sub-storage blocks of different sizes.

18. The method according to claim 1, wherein, The prevention logic is associated with multiple memory banks.

19. The method according to claim 1, wherein, Each sub-memory is associated with an activation threshold, and the prevention logic is configured to periodically execute steps to increment the activation counter associated with each sub-memory, and to determine the required number of preventative refreshes of the sub-memory.

20. A DRAM memory device including row hammer prevention logic, a buffer circuit or controller for the DRAM memory device, the row hammer prevention logic being configured to implement the method according to claim 1.

21. The DRAM memory device of claim 20, wherein, The DRAM memory device includes at least one integrated processor.

22. The DRAM memory device of claim 20, wherein, The DRAM memory device includes a plurality of replacement blocks that are separated from each other in any way to prevent rows of the replacement blocks from being attacked by hammering rows of another replacement block.

23. The DRAM memory device, the buffer circuit or controller of the DRAM memory device according to claim 22, wherein, The rows of the replacement block are designed to replace defective rows in a single sub-memory.

24. The DRAM memory device according to claim 22, wherein, The rows of the replacement block are designed to replace defective rows in multiple sub-stores, and the rows that make up the replacement block are all parts of the preventative refresh cycle of the sub-stores that share the replacement block.

25. The DRAM memory device, the buffer circuit or controller of the DRAM memory device according to claim 22, wherein, Replace the block-limited sub-storage.

26. The DRAM memory device, the buffer circuit or controller of the DRAM memory device according to claim 20, wherein, The sub-memory includes replacement lines that are part of the preventative refresh cycle of the sub-memory.

27. A method for protecting a DRAM memory device from line hammer effect, the memory device comprising: A plurality of memory banks consisting of memory rows, the method being implemented by at least one prevention logic, the at least one prevention logic being configured to define each sub-memory bank as a portion of a consecutive row of the memory bank, the prevention logic being configured to execute a preventive refresh sequence, the preventive refresh sequence comprising: - The step of identifying the need for preventative refresh of the determined sub-memory in the sub-memory of the memory device; - The step that triggers the operation to refresh the current row specified by the current row index associated with the determined sub-store; - The step of incrementing the current row index associated with the determined sub-store; The step of forming the preventive refresh sequence to cause a preventive refresh cycle that refreshes at least all rows of the determined sub-memory is wherein the preventive refresh cycle of the determined sub-memory is fully executed before the number of active rows in the determined sub-memory exceeds a critical hammer value. Each sub-memory is associated with an activation threshold, and the prevention logic is configured to increment an activation counter associated with the given sub-memory each time a row of a given sub-memory in the sub-memory of the memory device is activated, and the prevention logic is configured to determine the required number of preventive refreshes for the given sub-memory, wherein the required number of preventive refreshes for each given sub-memory is stored in a data structure.

28. The method according to claim 27, wherein, The data structure is a tree structure.

29. The method according to claim 27, wherein, The step of identifying the need for preventative refresh of the determined sub-memory includes browsing the data structure to identify a number of sub-memory that require preventative refresh of greater than or equal to 1.

30. The method according to claim 27, wherein, The required number of preventive refreshes for all said sub-memories is less than 1, and the step of identifying the need for preventive refreshes for the determined sub-memories includes: identifying the sub-memory with the largest activation counter in the data structure, and resetting the activation counter after triggering the operation for refresh.

31. A method for protecting a DRAM memory device from line hammer effect, the memory device comprising: A plurality of memory banks consisting of memory rows, the method being implemented by at least one prevention logic, the at least one prevention logic being configured to define each sub-memory bank as a portion of a consecutive row of the memory bank, the prevention logic being configured to execute a preventive refresh sequence, the preventive refresh sequence comprising: - The step of identifying the need for preventative refresh of the determined sub-memory in the sub-memory of the memory device; - The step that triggers the operation to refresh the current row specified by the current row index associated with the determined sub-store; - The step of incrementing the current row index associated with the determined sub-store; The step of forming the preventive refresh sequence to cause a preventive refresh cycle that refreshes at least all rows of the determined sub-memory is wherein the preventive refresh cycle of the determined sub-memory is fully executed before the number of active rows in the determined sub-memory exceeds a critical hammer value. Each sub-memory is associated with an activation threshold, and the prevention logic is configured to increment an activation counter associated with the given sub-memory each time a row of a given sub-memory in the sub-memory of the memory device is activated, and the prevention logic is configured to determine the required number of preventive refreshes of the given sub-memory, and wherein the activation threshold defines a variable progress coefficient during the full cycle of the determined preventive refreshes of the sub-memory.

Images