• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to a memory device comprising one or more banks (126), each bank comprising a plurality of memory ranks, the memory device further comprising: a Row Hammer trigger detection logic (123) configured to monitor, for each bank, the activation commands issued by both an external memory controller and one or more internal processors of the memory device, in order to trigger refresh operations accordingly.
    公开号:FR3066842A1
    申请号:FR1770532
    申请日:2017-05-24
    公开日:2018-11-30
    发明作者:Fabrice Devaux；Gilles Hamou
    申请人:Upmem SAS；
    IPC主号:
    专利说明:

    ROW HAMMER correction logic for DRAM WITH INTEGRATED PROCESSOR
    Field of the invention
    The present description relates to the field of DRAM circuits (dynamic random access s memory) with integrated processors.
    Discussion of the Prior Art The Row Hammer effect is the fact that, inside a given DRAM memory bank, repeatedly activate a row ("Row") ) Given DRAM could cause the physically adjacent ranks to invert the value of some of their bits. The rank which is too active will be called “aggressor rank” and its two adjacent ranks will be called “victim ranks”.
    In particular, the activation of a memory row inside a DRAM bank implies having this bank in a preloaded state, this state having been previously reached by means of a preloading command, then by playing a activation command. Once activated, the row can be accessed for the purposes of a read or write operation.
    If we count the activations that target a given rank, then when this count reaches a certain value, the rank becomes an aggressor and the 2 adjacent ranks become its victims.
    The solution to this problem is to detect that a rank is on the verge of becoming an aggressor, and, before this is the case, to refresh the two adjacent ranks (its potential victims), such refreshments being called in this "Preventive refreshments" document.
    In doing so, and from the Row Hammer effect's perspective, refreshing two adjacent rows "resets" the number of activations of the potential attacker.
    Regardless of Row Hammer's problem, DRAM memory needs to be refreshed anyway. The DDR4 specification indicates that all rows of a DDR4 bank must be refreshed every 64 ms, the corresponding refreshments being called "periodic refreshes".
    Therefore, the Row Hammer problem can only happen if, within a 64 ms time window, a given row is activated enough times to become an attacker.
    Studies on the Row Hammer phenomenon show that the aggression of a victim rank is the result of the sum of attacks from the two adjacent rows. For example, if it takes 250,000 activations for a row to become an attacker, the Row Hammer's mitigation logic should consider 125,000 activations as a trigger value, since two attackers can "cooperate" to attack the same victim rank.
    To summarize, an intrinsic Row Hammer trigger value, which takes into account the worst possible cases, such as co-aggression, is now an additional parameter which is part of the description of any recent DRAM process.
    If, within a refresh window, the number of activations for a given row is about to reach this intrinsic Row Hammer trigger value, then the two adjacent rows must be preventively refreshed.
    The patent 201400 '' describes a solution to mitigate the Row Hammer effect, but it has the following disadvantages: • The method is not suitable for DRAM memory incorporating a processor, • The completely detailed method (and no other method can be directly inferred from this text,) does not allow Row Hammer conditions to be detected in relatively simple scenarios, when the parameters are calculated as explained by this precise method, • The detailed method requires completely, for each activation command , the classification of the entries of a table, with a few tens of entries. Such a classification constitutes a time consuming process that would be difficult to achieve in less than 45 ns, the minimum time separating two activations of rank within the same DDR4 bench. One of the objectives for achieving this description is to at least partially remedy one or more of these limitations. not suitable for DRAM incorporating a processor
    The submission of the patent published under WO 2017/055732 describes how it is feasible to have an integrated processor inside a DDR4 compatible DRAM chip.
    The patent is not suitable for a DRAM with an internal processor, since the external memory controller does not know the activations generated by the internal processor of the DRAM, whereas the possibility for a given rank to become an attacker results from the sum: • activations generated by the external memory controller targeting this given rank, • and activations generated by the internal processor of the DRAM memory targeting this given rank. US 20140006704 A1 does not work in some simple scenarios
    The intrinsic trigger value considered is 125,000 rank activations, and all the significant parameters are calculated according to the method described in US 20140006704 A1.
    The time window N begins at time T.
    Row 20000 is refreshed between T + 16 ms and T + 32 ms.
    Between times T + 32 ms and T + 64 ms, row 20000 is activated 120,000 times, less than the intrinsic trigger value 125000, so no preventive refresh is initiated for its neighboring rows.
    According to the time window N, the new time window N + 1 starts at T + 64 ms, and the detection logic table is initialized, since initialized at the beginning of each time window (as explained in), this initialization leading in particular to the reset of the activation counter associated with row 20000.
    Between times T + 64 ms and T + 80 ms, rank 20000 is not yet refreshed (it will be refreshed between 64 + 16 ms and 64 + 32 ms), and rank 20000 is activated 10,000 times more, so :
    Rank 20,000 has been activated more than 125,000 times (130,000 times) over a period of time less than 64 ms (from T + 32 ms to T + 80 ms) and yet the need for refreshments
    preventive measures for its two neighbors has not been discovered by the logic proposed by US 20140006704 Al.
    not suitable for integration into a DRAM
    An external DRAM controller will typically be part of an ASIC fabricated on a process suitable for creating fast logic, such a process being called logic process.
    DRAMs are made with specialized processes, allowing the capacitors used for memory cells to be built, and the logic built using such processes is much slower than if it was using a logical process.
    Consequently, an algorithm implemented in a DRAM will typically be much slower than the same algorithm implemented in an ASIC.
    The only method explained in US 2014 requires sorting a row activation count table (there is nowhere to be a practical explanation of how to get rid of table sorting).
    Sorting is an expensive procedure, which can be fast enough if it is implemented on a logical process, but it is probably not fast enough when it is implemented on a DRAM process, in particular considering that the whole algorithm must be executed in less than 45 ns, the minimum time separating two activation commands targeting the same bench. Summary One of the embodiments of the description presented is to at least partially solve one or more of the problems of the prior art.
    According to one aspect, there is provided a memory device comprising one or more benches, each bench comprising a plurality of memory rows, the memory device further comprising: an external access port configured to allow an external memory controller to activate , then access the memory rows of each bank; one or more internal processors capable of activating and then accessing the memory ranks of each bank; Row Hammer trigger detection logic configured to monitor, for each bench, the activation commands from one hand from the external memory controller and from one or more internal processors, the trigger detection logic comprising memory storage: one or more tables indicating, for each row of a subset of rows of each bench, a count value based on the number of activation commands targeting the row, where the associated subset of rows at the count value in one or more tables is dynamically variable, to indicate the most frequently activated rows, based on the detection of activation commands targeting each row of each bench; an additional count value indicating the maximum number of activation orders which could have been aimed at one of the rows not belonging at that time to the said subset of rows; and in which the Row Hammer trigger detection logic is configured to compare each of said count values with a threshold level in order to identify one or more rows in the subset of rows, and to trigger a refresh operation one or more of the rows adjacent to each row identified.
    According to one of the embodiments, one or more tables comprise an entry associated with each row of the row subset, each entry comprising said count value, in which the number of entries in the said additional table or tables is less to one hundredth of the number of rows in each bench.
    According to one of the embodiments, the memory device also comprises a logic for sending preventive refreshment for one or more adjacent rows of each identified row by issuing refresh requests in place of the periodic refresh requests generated by the expert memory controller, thereby delaying one or more of said periodic refresh requests.
    According to one of the embodiments, the amount of time by which the periodic refresh requests are delayed does not exceed a maximum amount which allows each memory bank to correctly retain this data over time.
    According to one of the embodiments, the logic for sending preventive refresh includes a memory storing an indication on the row, or the adjacent rows of each of the rows identified as needing to be refreshed.
    According to one of the embodiments, an external protocol used by the external memory controller allows the memory device to take the initiative to generate refreshes.
    According to one of the embodiments, the trigger detection logic of the Row Hammer is configured, after each activation command from the external memory controller or from one of the internal processors: to modify the count value associated with the row targeted by the activation command if the targeted row belongs to the subset of rows; or to replace an entry in one or more of the tables with an entry corresponding to the rank targeted by the activation command if the count value of this entry is equal to the additional count value; or to modify the additional count value if the target rank does not belong to one of the subsets of ranks and none of the count values in one or more of the tables is equal to the value of additional counting.
    According to an additional aspect, a method is provided for protecting a memory device from the Row Hammer effect, the memory device comprising one or more benches, each of the benches comprising several memory rows, the method comprising: monitoring, by logic Row Hammer trigger detection and for each bench, the row activation commands generated by an external memory controller on the one hand and one or more internal processors on the other hand; memorize, by Row Hammer trigger detection logic, one or more tables indicating, for each row of a subset of rows of each bench, a count value based on the number of activation commands aimed at the rank, in which the subset of rows associated with the count value in one or more tables is dynamically variable to indicate the most frequently activated rows based on a detection of the activation commands targeting each row of each bench; memorize, by a Row Hammer trigger detection logic, an additional count value indicating the maximum number of activation commands which could have targeted any of the rows not at that time part of said subset of rows ; compare, using Row Hammer trigger detection logic, each of the count values with a threshold level in order to identify one or more rows in one or more tables; and trigger, by a trigger detection logic, an operation of refreshing one or more rows adjacent to each of the identified rows.
    According to one of the embodiments, the method also includes the implementation, by a logic of sending a preventive refresh, a refresh operation for one or more rows adjacent to each of the identified rows by sending refresh requests to the places periodic refresh requests generated by the external memory controller, thereby delaying one or more of said periodic refresh requests.
    According to one of the embodiments, the method also comprises: after each activation command issued by the external memory controller or by one of the internal processors: modify the count value associated with the rank targeted by the activation command if the target row belongs to the subset of rows; and replace an entry in one or more tables with an entry corresponding to the rank targeted by the activation command if the count value of this entry is equal to the additional count value; and modify the additional count value if the target rank does not belong to or subset of ranks and none of the count values in one or more tables is equal to the additional count value.
    Brief description of the drawings
    The advantages and the preceding and other characteristics will appear from the following detailed description of the embodiments, provided by way of nonlimiting example, with references to the associated drawing, in which:
    FIG. 1 schematically illustrates part of a computing system comprising a memory device which integrates processors according to an exemplary embodiment.
    Operating principles of the embodiments of the present invention
    For each DRAM bench, the embodiments described below for example include two blocks: • A trigger detection unit, and • A refresh sending unit where the trigger detection unit feeds the unit sending refresh. At each activation command concerning the bench, the trigger detection unit, detailed below, indicates whether the rank targeted by this activation command has potentially reached the trigger value. The term "potentially" reflects the fact that false positives are possible, but without consequence since they are not frequent enough, as shown below. The refresh sending unit comprises for example a FIFO, here called the preventive refresh FIFO, and when an activation command, targeting a given rank, is marked as having reached its trigger count value, then the two indexes of the two neighboring ranks of this given rank are calculated and then pushed into this FIFO.
    When the preventive refresh FIFO is not empty, the preventive refreshes will have to be sent, but the DRAM bank will be able to initiate these preventive refreshes on its own initiative: • From the protocol point of view, the DRAM memory chip is a slave of the external DRAM memory controller, and having a bank of a DRAM chip capable of performing refreshes on its own initiative would break the protocol entirely.
    The external memory controller which is connected to the DRAM regularly generates periodic refresh requests. A periodic refresh does not specify the rank index to refresh: this index being generated by an internal DRAM logic called refresh counter logic (since it is generally just a counter).
    So in the embodiments of this present invention, each bank has its own refresh counter logic and each time a DRAM bank receives a periodic refresh request generated by the external DRAM controller then: • if the preventive refresh FIFO for this bank is not empty then the index of the row to be refreshed is not provided by the refresh counter, but is taken out of the preventive refresh FIFO, the refresh counter of this bench remaining unchanged. • if the preventive refresh FIFO is empty then the index of the row to be refreshed is provided by the refresh counter of this bank, this one being updated.
    Since the execution of preventive refreshes is punctuated by periodic refreshes, the trigger value must be reduced by the number of activations that can be waxed during the worst-case delay between the discovery that a periodic refresh is necessary and its actual execution , this worst-case delay resulting from: • the fact that several preventive refreshes could have been accumulated in the FIFO, this being facilitated by the fact that the preventive refreshes are generated in pairs • from the need to wait for the actual realization of each refreshment preventive pending, a periodic refresh request.
    Ignoring the intrinsic latency of the logic, the worst-case delay is roughly Max_Triggered x 2 x Max_Timed_Refresh_Period, where: • Max_Triggered is the number of rows of a bank that can be activated enough times to reach the trigger value in a 64 ms time window, • Max_Timed_Refresh_Period is the maximum time between two periodic refresh requests.
    Extension of the refresh window The actual execution of preventive refreshes delays periodic refreshes, but the maximum delay is small enough to be of no consequence:
    A typical DRAM bank having 65536 rows, the external memory controller generates on average, for a bank, a periodic refresh every 976 ns (64 ms / 65536).
    Typically an activation command can be issued every 45 ns to a given bank, which means that for a time window of 64 ms, less than 1,423,000 activation commands can target the same bank, this number being called Max_activate_m_wmdow.
    Considering an intrinsic Row Hammer value of 125000, this means that in a window of 64 ms, there can be a maximum of 11 attackers in a given DRAM bank.
    Considering the previous example, in the worst case, instead of refreshing 65536 rows in 64 ms, then 65536+ (11x2) rows can be refreshed, which leads to the extension of the refresh window from 64 ms to 64.022 ms . Such a small extension is absolutely not a problem since the 64 ms figure is a cautiously low value.
    Figure 1
    Figure 1 summarizes the explanation so far:
    An external memory controller 111, which is for example part of an ASIC 110, is coupled to a memory device 120 through a bus attached to the interface of the memory device 121 of the memory device 120.
    A bench 126 can be accessed by the external memory controller 111 and by the integrated processor 122.
    Trigger detection logic 123 monitors activation commands generated by the external memory controller 111 and by the integrated processor 122.
    The trigger detection logic 123 indicates, through the insertion of a "TRIG reached" signal, when the activation of the rank currently activated implies that this rank can potentially reach the trigger value.
    The refresh sending logic 124 receives the signal "TRIG reached" and then determines the indexes of the two rows which are adjacent to the row "on the point of becoming" aggressor, then for example pushes these two indexes into the logic LILO sending refresh 124.
    The LILO is for example emptied by preempting the periodic refresh slots. The corresponding refreshes are not lost, for example, but simply delayed, since the refresh counter logic 125 is not updated. The trigger detection unit
    As will become apparent later, the algorithm used by the trigger detection unit is for example approximate, and to compensate for this, the effective trigger value retained Trig_Eff is for example: • initially based on half the value of intrinsic triggering, the reason for this being detailed below, • further reduced to take into account the worst-case delay for having a preventive refresh actually carried out, as previously explained. Since the worst-case delay depends mainly on the maximum number of pending preventive refreshes, which depend on Trig_Eff, the exact Trig_Eff value is for example calculated iteratively.
    The practical consequence is that more preventive refreshments than strictly necessary could be issued. This is not a problem since the number of these preventive refreshes remains marginal compared to the number of periodic refreshes: • since the preventive refreshes steal periodic refresh slots, there is no performance penalty resulting from the emission of unnecessary preventive refreshes • the only practical impact is that the 64 ms refresh window can be extended more than strictly necessary. This is of no consequence since this extension remains very small in percentage.
    While it generates false positives, the proposed algorithm does not generate false negatives, unlike the system described in US 2014
    Trigger detection unit algorithm The trigger detection logic unit includes for example a table, the Row Activate Count Table (RACT) which has Nbr_of_entries entries, where Nbr_of_entries is for example calculated as follows:
    Nbr_of_entries = INT (Max_activate_m_wmdow / Trig_Eff) Where the INT function returns its rounded input value to the integer value immediately lower or equal.
    Each RACT entry includes, for example, two fields: • A ROW_COUNT field which is large enough to contain a value up to TrigEff, • A R0W_INDEX field which is large enough to contain all the possible row index values, and an additional value which is never a rank index, called no_row.
    In addition, the trigger detection logic includes, for example, a register called OTHER_ROWS_COUNT, large enough to hold a value up to Trig_Eff-l. Any periodic time reference can be used, but for the simplicity of the explanation, in a bank, a refresh window is said to have started, for example when: • the bank's refresh counter logic designates at this time the rank 0, • a periodic refresh request is generated by the external memory controller. Each time a refresh window starts, the trigger detection logic for example:
    • sets the ROW_COEfNT fields of all RACT entries to zero • initializes the R0W_INDEX fields of all RACT tables to no_row, • sets the OTHER_ROWS_COUNT register to zero.
    Each time an activation command, aimed at a row with an index J, is executed by a bench, then the trigger detection logic reads for example the RACT inputs to reach a first objective and a second objective, the second being taken into account only if the first is not reached: • The first objective is to find an entry of RACT whose field R0W_INDEX has the value J, • The second objective is to find an entry of RACT whose field R0W_C0UNT is OTHER_ROWS_COUNT.
    First objective reached As soon as the first objective is reached, then the reading of the entries is for example stopped and: • the field R0W_C0UNT of the found entry is incremented, • if the value of the field ROW_COUNT of the found entry is equal to Trig_Eff , then: o the ROW_INDEX field of the entry found is for example set to no row. o the indexes of the ranks of the two neighbors of rank J are for example pushed into the preventive refresh FIFO.
    First objective not reached is second objective achieved
    In the following explanation, the RACT table index for the entry found is called Fidx (Found Index), so we have:
    OTHER_ROWS_COUNT == RACT [Fidx] .ROW_COUNT
    The trigger detection logic then performs: • RACT [Fidx] .ROW_COUNT is incremented, • RACT [Fidx], ROW_INDEX is set to J.
    First and second goals not met • OTHER_ROW_COUNT is incremented
    In this algorithm, a rank is always associated with an activation counter, a rank R for example being: • either associated with the number of activations contained by the ROW_COUNT field of a RACT entry whose ROW_INDEX field is equal to R , • or associated with the number of activations contained in the OTHER_ROWS_COUNT register. The algorithm ensures, for example, that the number commonly associated with a rank is always greater than or equal to the actual number of activations since the start of the refresh window. The algorithm also ensures for example that OTHER_ROWS_COUNT is smaller than the smallest RACT.ROW_COUNT fields, so the algorithm ensures that if the effective number of activations of rank R reaches Trig_Eff, this will happen in a RACT entry, and not in the OTHER_ROWS_COUNT registry.
    Size the preventive refresh FIFO
    Since preventive refreshes potentially accumulate in the preventive refresh FIFO, in some embodiments a high limit to the maximum numbers of preventive refreshes that can be pushed into this FIFO is determined, in order to properly size it.
    An entry only reaches Trig Eff by counting Trig_Eff activations, potentially targeting different ranks (this is how false positives can happen) or by targeting a single rank (and it is certainly a true positive).
    It is therefore impossible for the trigger detection logic to generate more than a preventive refresh pair not input from RACT.
    Variant of algorithm
    In the algorithm described above, the register value OTHER_ROWS_COUNT is for example necessarily less than or equal to the field ROW_COUNT the smallest of the RACT entries.
    Therefore OTHER_ROW_COUNT cannot reach Trig_Eff, because otherwise the value would have resulted in an additional RACT entry.
    The trigger detection logic is basically a cache, whose associativity is equal to the number of inputs. The previously explained algorithm has its reduced associativity each time an entry reaches Trig_Eff, the entry being effectively removed since: • Its ROW_INDEX is initialized at no_row: no activated rank can reach this entry anymore • Its ROW_COUNT field remains at the value Trig_Eff: it cannot be equal to OTHER_ROWS_COUNT.
    The following variation of the initial algorithm maintains constant associativity by recycling RACT entries that reach Trig_Eff:
    First objective reached As soon as the first objective is reached, then the reading of the RACT entries is for example stopped and: • If the value of the ROWCOUNT field of the entry found is equal to Trig_Eff-l, then: • The ROW_INDEX field of the entry found is for example set to no row. • The field ROW_COUNT the entry found is for example set to the value contained by OTHER_ROWS_COUNT, • The rank indexes of the two neighbors of row J are for example pushed into the LILO of preventive refresh. • Otherwise the ROW_COUNT field of the entry found is incremented.
    First objective not reached and second objective achieved
    The trigger detection logic then implements for example the following: • RACT [Fidx] .ROW_COUNT is incremented, • RACT [Fidx], ROW_INDEX is set to J.
    First goal and second goal not met • OTHER_ROW_COUNT is incremented, for example
    Size the preventive refresh FIFO for the algorithm variant
    This variant of the algorithm maintains the associativity constant instead of reducing it gradually, and therefore necessarily leads to fewer false positives. Therefore, it cannot generate more preventive refreshes than the initial algorithm, and therefore cannot generate more than two preventive refreshes per RACT entry.
    Justification of the Trig_Eff calculation
    The exposed logic is able to detect if a rank has reached Trig_Eff. So when a new refresh window starts, the maximum "activation past" of any rank is up to Trig_Eff_trig-l, since such a value does not yet generate preventive refresh.
    So, before reaching the value Trig_Eff in a given refresh window, a rank may have accumulated in fact (Trig_Eff-l) + (Trig_Eff-l), the first value (Trig_Eff-l) being inherited from the previous window of refreshment. So the logic will in fact only reliably detect (Trig_Eff x 2) -1 activations, explaining why the iterative calculation Trig_Eff for example starts from half the intrinsic trigger value. generalizations
    The embodiments of the present description have been described in the context of DRAM banks, but obviously the techniques described here could be applied to any memory table which would be equivalent to a high density DRAM bank (having a refresh operation and suffering from the Row Hammer effect).
    References have been made to the DDR4 protocol, as an example, in various places in this document. Obviously, the techniques described here could be applied to all affiliated memory protocols, such as: • DDR, DDR2, DDR3, DDR4 in their low consumption versions, • GDDR, GDDR2, GDDR3, GDDR4, GDDR5, • HBM.
    In addition, the embodiments described here could be applied to memory devices, with integrated processors, using protocols which allow the DRAM to take initiatives to execute refreshes, such as the HMC protocol. In this case, the preventive refresh sending unit described here can be omitted, only the trigger detection unit remaining.
    For simplicity, a refresh window of 64 ms has been considered, as this value is the one currently used. Obviously, the embodiments described here could be applied to any duration of refresh window which would be used by a given DRAM technology, and even to a DRAM where the refresh durations continuously adapt to the variation of external parameters. , such as temperature, voltage, radiation level, etc.
    Likewise, the number of rows equal to 65536 has been given as an example because it is representative of the DRAMs currently manufactured. Obviously the embodiments described here could be applied independently of the number of rows present in the bench. The algorithm presented so far and its variations can be modified in many ways while remaining within the scope of the invention. The following list provides examples of such modifications which can be implemented individually or combined in any sub-combination, this list being given as an example and not as a limitation: • Factorize some of the material resources described on several benches DRAM, • Replace a table with different fields with different tables with fewer fields, • Replace a table with different smaller tables, the algorithm being modified in order to handle several entries at the same time • Use a valid bit instead of a no_row value, this valid bit being positioned on an additional field of each entry, or in an additional table, • Count the activation commands instead of counting them, the ROW_COUNT field of RACT and the register OTHER_ROWS_COUNT being initialized with a number of activation commands allowed for the refresh window, • Group the ran gs in packets of topologically adjacent ranks, activation being followed at the level of the rank packet, and when the number of activation reaches Trig_Eff, then: o All the rows of the aggressors packet are refreshed o The two rows which are neighbors of the aggressor packet are refreshed (or the two corresponding rank packets are refreshed, if the refreshes are managed at the granularity level of the rank packet).
    权利要求:
    Claims (10)
    [1" id="c-fr-0001]
    1. A memory device comprising one or more banks (126), each bank comprising several rows of memory, the memory device further comprising: an external access port (121) configured to allow an external memory controller (111) activate, then access, the memory rows of each bench; one or more internal processors (122) capable of activating and then accessing the memory rows of each bank; Row Hammer trigger detection logic (123) configured to monitor, for each bench, the activation commands issued by the external memory controller and by one or more internal processors, the Row Hammer trigger detection logic comprising memory memorizing: one or more tables indicating, for each row of a subset of rows of each bench, a count value based on the number of activation commands targeting the row, in which the subset of rows associated with the count value in one or more tables is dynamically variable to indicate the most frequently activated rows based on a detection of the activation commands targeting each row of each bench; an additional count value indicating the maximum number of activation commands which could have targeted any rank not forming part of said subset of ranks; and wherein the Row Hammer trigger detection logic is configured to compare each of said count values with a threshold level to identify one or more rows in the subset of rows, and initiate a refresh operation one or more rows adjacent to each row identified.
    [2" id="c-fr-0002]
    2. The memory device of claim 1, wherein one or more tables comprise an entry associated with each row of the subset of rows, each entry comprising said count value, wherein the number of entries of said where of said tables is less than one hundredth of the number of rows in each bench.
    [3" id="c-fr-0003]
    3. The memory device of claim 1 or 2, further comprising a preventive refresh sending logic (124) configured to implement a refresh operation for one or more of the adjacent rows of each identified row by issuing requests instead of the periodic refresh requests generated by the external memory controller, thereby delaying one or more of said periodic refresh requests.
    [4" id="c-fr-0004]
    4. The memory device of claim 3, in which the duration of which said periodic refresh requests are delayed does not exceed a maximum duration which allows each memory to correctly retain its data over time.
    [5" id="c-fr-0005]
    5. The memory device of claim 3 or 4, in which the logic for sending preventive refresh comprises a memory (FIFO) storing, for each identified row, an indication of one or more adjacent rows to be refreshed.
    [6" id="c-fr-0006]
    6. The memory device of claim 1 or 2, wherein an external protocol used by the external memory controller allows the memory devices to take the initiative to generate refreshes.
    [7" id="c-fr-0007]
    7. Fe memory device of any one of claims 1 to 6, in which the trigger detection logic of the Row Hammer is configured, after each activation command issued by the external memory controller or by one of the internal processors, to: - modify the count value associated with the row targeted by the activation command if the targeted row is part of the subset of rows; and - replace an entry in one or more tables with an entry corresponding to the rank targeted by the activation command if the count value of this entry is equal to the additional count value; and - modify the additional count value if the target row is not part of the subset of rows and none of the count values in one or more tables is equal to the additional count value.
    [8" id="c-fr-0008]
    8. A method of protecting the memory device of the Row Hammer effect, the memory device comprising one or more benches (126), each bench comprising several memory rows, the method comprising: monitoring, by the logic of detection of triggering of the Row Hammer (123) and for each bench, the row activation commands issued by the external memory controller and by one or more internal processors of the memory device, each row activation command causing the row of said bench to be activated before being accessed by the external memory controller or by one or more internal processors; store, by the Row Hammer's trigger detection logic, one or more tables indicating for each row of a subset of rows of each bench, a count value based on the number of activation commands targeting the row, wherein the subset of rows associated with a count value in one or more tables is dynamically variable to indicate the most frequently activated rows based on the detection of activation commands targeting each row of each bench; memorize, by the Row Hammer's trigger detection logic, an additional count value indicating the maximum number of activation commands which could target any row not forming part of said row subsets; compare, using the Row Hammer's trigger detection logic, each of the count values with a threshold level in order to identify one or more rows in one or more tables; and trigger, by the Row Hammer's trigger detection logic, an operation to refresh one or more rows adjacent to the identified row.
    [9" id="c-fr-0009]
    9. The method of claim 8, further comprising the implementation, by the preventive refresh sending logic (124), of a refresh operation for one or more adjacent rows of each identified row by issuing requests for refresh in place of periodic refresh requests generated by the external memory controller, thereby delaying one or more of said periodic refresh requests.
    [10" id="c-fr-0010]
    10. The method of claim 8 or 9, further comprising: after each activation command issued by the external memory controller or by one of the internal processors: - modify the count value associated with the rank targeted by the command activation if the target rank is part of the rank subset; and - replace an entry in one or more tables with an entry corresponding to the rank targeted by the activation command if the count value of this entry is equal to the additional count value; and - modify the additional count value if the target row is not part of the subset of rows and none of the count values in one or more tables is equal to the additional count value.
    类似技术:
    公开号 | 公开日 | 专利标题
    FR3066842B1|2019-11-08|ROW HAMMER CORRECTION LOGIC FOR DRAM WITH INTEGRATED PROCESSOR
    US9812185B2|2017-11-07|DRAM adjacent row disturb mitigation
    US10572377B1|2020-02-25|Row hammer refresh for content addressable memory devices
    EP0935781A1|1999-08-18|Method for allocating memory in a multiprocessor data processing system
    US10658025B2|2020-05-19|Apparatuses and methods for detecting a row hammer attack with a bandpass filter
    FR2809841A1|2001-12-07|METHOD AND APPARATUS FOR REDUCING POWER IN HIDDEN MEMORIES AND DATA PROCESSING SYSTEM COMPRISING HOT MEMORIES
    FR3045183A1|2017-06-16|METHOD FOR PREDICTING DATA TO BE PRELOADED IN A CACHE MEMORY
    EP1876601B1|2011-06-01|Method for refreshing a dynamic RAM, in particular in standby mode and in active operation mode, and corresponding dynamic RAM device, for example incorporated in a cellular mobile telephone
    EP1248261A2|2002-10-09|Random and rapid DRAM memory access management method
    EP2043103B1|2016-04-06|Electronic memory device
    EP2666092B1|2015-02-25|Multi-core system and data coherency method
    FR3086788A1|2020-04-03|BMI MEMORY CIRCUIT WITH 6T CELLS
    EP3259674B1|2020-12-16|Dram circuit provided with a built-in processor
    EP3671470B1|2021-05-19|Method for managing an electronic computer cache memory
    FR3111730A1|2021-12-24|Method and circuit for protecting a DRAM memory device from the rank hammering effect
    EP0908828B1|2007-01-03|Distributed access control system for memory and method
    EP3693862A1|2020-08-12|Method for managing an electronic computer cache memory
    EP3729768A1|2020-10-28|Method for automatically constructing computer attack scenarios, computer program product and associated construction system
    FR3074936A1|2019-06-14|METHOD OF WRITING AN INFORMATION SET, FOR EXAMPLE A PROGRAM CODE, ENCRYPTED IN AN EXTERNAL MEMORY OF AN INTEGRATED CIRCUIT AND INTEGRATED CIRCUIT CORRESPONDING
    FR3055715A1|2018-03-09|METHODS AND DEVICES FOR CONTOURING INTERNAL CACHE OF ADVANCED DRAM MEMORY CONTROLLER
    WO2015189505A1|2015-12-17|Search for element correspondence in a list
    FR3022057A1|2015-12-11|PROTECTION OF DATA STORED IN A VOLATILE MEMORY
    同族专利:
    公开号 | 公开日
    US20210012832A1|2021-01-14|
    US11049544B2|2021-06-29|
    WO2018215715A1|2018-11-29|
    KR20200014805A|2020-02-11|
    JP2020521267A|2020-07-16|
    FR3066842B1|2019-11-08|
    CN110741436A|2020-01-31|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US6463001B1|2000-09-15|2002-10-08|Intel Corporation|Circuit and method for merging refresh and access operations for a memory device|
    WO2017048441A1|2015-09-17|2017-03-23|Intel Corporation|Hybrid refresh with hidden refreshes and external refreshes|FR3111730A1|2020-06-23|2021-12-24|Upmem|Method and circuit for protecting a DRAM memory device from the rank hammering effect|
    WO2021259593A1|2020-06-23|2021-12-30|Upmem|Method and circuit for protecting a dram memory device from the row hammer effect|US8938573B2|2012-06-30|2015-01-20|Intel Corporation|Row hammer condition monitoring|
    FR3042049A1|2015-10-01|2017-04-07|Upmem|
    KR102358563B1|2018-05-09|2022-02-04|삼성전자주식회사|Memory device performing refresh operation with row hammer handling and memory system comprising the same|
    US11037617B2|2018-08-03|2021-06-15|Micron Technology, Inc.|Methods for row hammer mitigation and memory devices and systems employing the same|
    US10950288B2|2019-03-29|2021-03-16|Intel Corporation|Refresh command control for host assist of row hammer mitigation|US11222685B2|2020-05-15|2022-01-11|Advanced Micro Devices, Inc.|Refresh management for DRAM|
    US20210374006A1|2020-05-29|2021-12-02|Advanced Micro Devices, Inc.|Refresh management for dram|
    法律状态:
    2018-09-27| PLFP| Fee payment|Year of fee payment: 3 |
    2018-11-30| PLSC| Search report ready|Effective date: 20181130 |
    2020-03-10| PLFP| Fee payment|Year of fee payment: 4 |
    2021-05-18| PLFP| Fee payment|Year of fee payment: 5 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1770532|2017-05-24|
    FR1770532A|FR3066842B1|2017-05-24|2017-05-24|ROW HAMMER CORRECTION LOGIC FOR DRAM WITH INTEGRATED PROCESSOR|FR1770532A| FR3066842B1|2017-05-24|2017-05-24|ROW HAMMER CORRECTION LOGIC FOR DRAM WITH INTEGRATED PROCESSOR|
    JP2019564461A| JP2020521267A|2017-05-24|2018-05-18|DRAM low hammer correction logic with integrated processor|
    KR1020197038136A| KR20200014805A|2017-05-24|2018-05-18|Low Hammer Correction Logic in DRAMs with Integrated Processors|
    CN201880034535.7A| CN110741436A|2017-05-24|2018-05-18|Row hammer correction logic module for DRAM with integrated processor|
    US16/615,636| US11049544B2|2017-05-24|2018-05-18|Row hammer correction logic for dram with integrated processor|
    PCT/FR2018/051200| WO2018215715A1|2017-05-24|2018-05-18|Row hammer correction logic for dram with integrated processor|
    [返回顶部]