特許 7142946 統合プロセッサを備えたＤＲＡＭのロウハンマー修正ロジック

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-09-16

(45)【発行日】2022-09-28

(54)【発明の名称】統合プロセッサを備えたＤＲＡＭのロウハンマー修正ロジック

(51)【国際特許分類】

   G11C 11/406 20060101AFI20220920BHJP

   G06F 12/00 20060101ALI20220920BHJP

【ＦＩ】

G11C11/406 140

G06F12/00 550B

【請求項の数】 8

(21)【出願番号】P 2019564461

(86)(22)【出願日】2018-05-18

(65)【公表番号】

(43)【公表日】2020-07-16

(86)【国際出願番号】 FR2018051200

(87)【国際公開番号】W WO2018215715

(87)【国際公開日】2018-11-29

【審査請求日】2021-05-07

(31)【優先権主張番号】17/70532

(32)【優先日】2017-05-24

(33)【優先権主張国・地域又は機関】FR

(73)【特許権者】

【識別番号】517287280

【氏名又は名称】アップメム

(74)【代理人】

【識別番号】110000338

【氏名又は名称】特許業務法人ＨＡＲＡＫＥＮＺＯ ＷＯＲＬＤ ＰＡＴＥＮＴ ＆ ＴＲＡＤＥＭＡＲＫ

(72)【発明者】

【氏名】ドゥヴォ，ファブリス

(72)【発明者】

【氏名】ハム，ジル

【審査官】後藤 彰

(56)【参考文献】

【文献】特開２０１６－２１２９３４（ＪＰ，Ａ）

【文献】特表２０１６－５０４７０２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１１Ｃ １１／４０６

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

１つまたは複数のバンク（１２６）を含むメモリデバイス（１２０）であって、当該バンク（１２６）がＤＲＡＭメモリの複数の行を含んでいる、メモリデバイス（１２０）であって、
前記メモリデバイス（１２０）は、外部アクセスポート（１２１）と、１つまたは複数の内部プロセッサ（１２２）と、ロウハンマートリガ検出ロジック（１２３）と、予防的リフレッシュ送信ロジック（１２４）とをさらに含み、
前記外部アクセスポート（１２１）は、外部メモリコントローラ（１１１）が前記バンク（１２６）の前記行をアクティブにして、次いでアクセスすることを可能にするように構成されており、
前記内部プロセッサ（１２２）は、前記バンク（１２６）の前記行をアクティブにして、次いでアクセスすることができる構成となっており、
前記ロウハンマートリガ検出ロジック（１２３）は、各バンクについて、前記外部メモリコントローラ（１１１）および前記内部プロセッサ（１２２）の少なくとも何れかによって発せられたアクティベーションコマンドを監視する構成となっており、
前記ロウハンマートリガ検出ロジック（１２３）は、１つまたは複数のテーブルと、追加のカウント値と、を記憶するメモリを含み、
前記１つまたは複数のテーブルは、前記バンクに含まれる複数の行のサブセットの各行について、当該行のアクティベーションコマンド数に基づいているカウント値を示す当該テーブルであって、当該テーブル内のカウント値に関連する行のサブセットが、複数のカウント値に基づいて前記ロウハンマートリガ検出ロジックによって、前記バンクに含まれる各行のアクティベーションコマンド数の検出値に基づいて最も頻繁にアクティベーションされた行を示すように動的に修正されるテーブルであり、
前記追加のカウント値とは、前記行のサブセットに含まれない任意の行にある可能性があるアクティベーションコマンド数の最大値を示し、
前記ロウハンマートリガ検出ロジックは、前記カウント値のそれぞれを閾値レベルと比較して前記サブセット内の１つまたは複数の行を識別する構成となっているとともに、当該識別された行それぞれに隣接する１つまたは複数の行をリフレッシュする動作を始動させる構成となっており、
前記ロウハンマートリガ検出ロジックは、前記追加のカウント値に基づいて、前記サブセットに含まれている行をアクティベーションコマンド対象の行と置換し、
前記予防的リフレッシュ送信ロジック（１２４）は、前記外部メモリコントローラによって生成された周期的リフレッシュ要求の代わりにリフレッシュ要求を発し、それによって前記周期的リフレッシュ要求の１つまたは複数を遅延させることによって、識別された各行の１つまたは複数の隣接行のリフレッシュ動作を実施するように構成されている、
メモリデバイス（１２０）。

【請求項2】

前記１つまたは複数のテーブルは、前記サブセットの各行に関連するエントリを含んでおり、
前記エントリは、前記カウント値を含み、
前記１つまたは複数のテーブルの前記エントリの数は、バンク（１２６）に含まれる行の数の１００分の１未満である、
請求項１に記載のメモリデバイス。

【請求項3】

前記周期的リフレッシュ要求が遅延される持続時間は、各メモリが時間の経過と共にそのデータを正しく保持することを可能にする最大持続時間を超えない、
請求項１または２に記載のメモリデバイス。

【請求項4】

前記予防的リフレッシュ送信ロジックは、識別された行ごとに、リフレッシュされるべき１つまたは複数の隣接する行の指示を記憶するメモリ（ＦＩＦＯ）を含む、
請求項１から３のいずれか１項に記載のメモリデバイス。

【請求項5】

前記外部メモリコントローラによって使用される外部プロトコルは、前記メモリデバイスに自発的にリフレッシュ動作をおこなわせることを可能にする、
請求項１から４のいずれか１項に記載のメモリデバイス。

【請求項6】

前記ロウハンマートリガ検出ロジック（１２３）は、前記外部メモリコントローラまたは前記内部プロセッサによって発せられる各アクティベーションコマンドの後に、対象の行が前記サブセットの行の一部である場合には、アクティベーションコマンドによって対象とされる行に関連するカウント値を変更し、アクティベーションコマンド対象の行が前記サブセットの行の一部ではなく、且つ前記テーブル内の或るエントリのカウント値が追加カウント値に等しい場合には、当該或るエントリを、当該アクティベーションコマンド対象の行に対応するエントリに置換し、アクティベーションコマンド対象の行が前記サブセットの行の一部ではなく、且つ前記テーブルのカウント値のいずれも追加カウント値と等しくない場合には、前記追加カウント値を変更する、
請求項１から５のいずれか１項に記載のメモリデバイス。

【請求項7】

複数のＤＲＡＭメモリ行を含む１つまたは複数のバンク（１２６）を備えたメモリデバイス（１２０）を、ロウハンマー効果から保護する方法であって、
ロウハンマートリガ検出ロジック（１２３）を使用して、外部メモリコントローラ（１１１）およびメモリデバイス（１２０）の１つまたは複数の内部プロセッサ（１２２）の少なくとも何れかによって発せられるロウアクティベーションコマンドを監視するステップであって、各ロウアクティベーションコマンドは外部メモリコントローラまたは１つまたは複数の内部プロセッサによってアクセスされる前に、前記バンクの行をアクティベートさせるステップと、
前記ロウハンマートリガ検出ロジック（１２３）を使用して、各バンクに含まれる複数の行のサブセットの各行について、当該行についてのアクティベーションコマンドの数に基づくカウント値を示す１つまたは複数のテーブルを記憶するステップであって、１つまたは複数のテーブル内のカウント値に関連する行のサブセットは、カウント値に基づいて前記ロウハンマートリガ検出ロジック（１２３）によって動的に修正され、各バンクの各行についてのアクティベーションコマンドの検出に基づいて最も頻繁にアクティベートされた行を示すステップと、
前記ロウハンマートリガ検出ロジック（１２３）を使用して、行の前記サブセットに属さない任意の行に向けられたことが可能であったアクティブ化コマンドの最大数を示す追加カウント値を記憶するステップと、
前記ロウハンマートリガ検出ロジック（１２３）を使用して、１つまたは複数のテーブル内の１つまたは複数の行を識別するために、カウント値のそれぞれをしきい値レベルと比較するステップと、
前記ロウハンマートリガ検出ロジック（１２３）を使用して、識別された行に隣接する１つまたは複数の行をリフレッシュするための動作をトリガするステップと、
前記ロウハンマートリガ検出ロジック（１２３）は、前記追加カウント値に基づいて、前記サブセットに含まれている行をアクティベーションコマンド対象の行と置換するステップと、
外部メモリコントローラによって生成された周期的リフレッシュ要求の代わりにリフレッシュ要求を発行することによって、識別された行の１つまたは複数の隣接する行のためのリフレッシュ動作を、予防的リフレッシュ送信ロジック（１２４）を使用して実施するステップであって、それによって、１つまたは複数の前記周期的リフレッシュ要求を遅延させるステップと、を含む、
方法。

【請求項8】

前記外部メモリコントローラまたは前記内部プロセッサによって発せられる各アクティベーションコマンドの後に、以下のステップ：
対象となる行が前記サブセットの行の一部である場合には、アクティベーションコマンドによって対象とされる行に関連するカウント値を変更するステップ、
アクティベーションコマンド対象の行が前記サブセットの行の一部ではなく、且つ１つまたは複数のテーブル内の或るエントリのカウント値が前記追加カウント値と等しい場合には、当該或るエントリを、当該アクティベーションコマンドによって対象とされる行に対応するエントリに置換するステップ、
アクティベーションコマンド対象の行が前記サブセットの行の一部ではなく、且つ１つまたは複数のテーブルのカウント値のいずれもが前記追加カウント値と等しくない場合には、前記追加カウント値を変更するステップ、
をさらに含む、請求項７に記載の方法。

【発明の詳細な説明】

【発明の詳細な説明】

【0001】

〔技術分野〕
本発明は、統合プロセッサを有するＤＲＡＭ（ダイナミック・ランダム・アクセス・メモリ）回路の分野に関する。

【0002】

〔従来技術の概要〕
ロウハンマー効果（Row Hammer effect）によれば、所与のＤＲＡＭメモリバンク内で、所与のＤＲＡＭ行を繰り返しアクティブにすることによって、物理的に隣接する行がそれらのビットのいくつかの値を反転させる。アクティブされすぎた行は「アグレッサ行」（aggressor row）と呼ばれ、その２つの隣接する行は「被害行」（victim rows）と呼ばれる。

【0003】

具体的にはＤＲＡＭバンク内のメモリ行をアクティブにすることはバンクをプリロード状態にすることを意味し、この状態はプリロードコマンドを介して、次いでアクティベーションコマンドをおこなうことによって以前に到達されている。いったんアクティブにされると、行は、読出しまたは書込み動作のためにアクセスされることができる。

【0004】

所与の行をターゲットとするアクティベーションがカウントされる場合、このカウントがある値に達すると、その行がアグレッサ行になり、２つの隣接する行が被害行になる。

【0005】

この問題に対する解決策は行がアグレッサ行になりそうことを検出し、それが起こる前に、２つの隣接する行（その潜在的な被害行）をリフレッシュすることにあり、そのようなリフレッシュは、本明細書では「予防的リフレッシュ」と呼ばれる。

【0006】

そうする際、またロウハンマー効果の観点から言えば、２つの隣接する行をリフレッシュすることが、潜在的なアグレッサ行のアクティベーションのカウントを「リセット」することになる。

【0007】

ロウハンマー問題（Row Hammer issue）に関わらず、ＤＲＡＭメモリは何らかの方法でリフレッシュされる必要がある。ＤＤＲ４仕様書は、ＤＤＲ４バンクのすべての行が６４ｍｓごとにリフレッシュされなければならず、対応するリフレッシュは「定期的なリフレッシュ」と呼称される。

【0008】

したがって、ロウハンマー問題は、６４ｍｓの時間窓内で、所与の行がアグレッサになるのに十分な時間アクティブ化される場合にのみ起きる。

【0009】

ロウハンマー現象（Row Hammer phenomenon）に関する研究は、被害行のアグレッションが２つの隣接する行のアグレッションの合計の結果であることを示す。例えば、行がアグレッサになるのに２５０，０００のアクティベーションを要する場合、ロウハンマーを軽減するためのロジックは、２つのアグレッサが同じ被害行をアグレッションするために「協働」（cooperate）することができるので、１２５，０００のアクティベーションをトリガ値として考慮すべきである。

【0010】

要約すると、コーアグレッション（co-aggression）のような最悪の可能な場合を考慮にそのような固有のロウハンマートリガ値は、今や、最近のＤＲＡＭプロセスの記述の一部である追加のパラメータである。

【0011】

仮に、或るリフレッシュ窓内で、所与の行のアクティベーションの数がこの固有のロウハンマートリガ値に到達しようとしている場合、２つの隣接する行を予防的にリフレッシュしなければならない。

【0012】

米国特許出願第２０１４０００６７０４号はロウハンマー効果を軽減する解決策を記載している。しかしながら、以下の欠点を有する：
－ 当該解決策の方法は埋め込みプロセッサを有するＤＲＡＭメモリには適していない。
－ 当該解決策の完全に詳細な方法（および他の方法はこのテキストから直接推論することができない）では、パラメータが当該方法によって説明される通りに計算されていても、比較的単純なシナリオでハンマーロウ状態（Hammer Row conditions）を検出することが困難である。
－当該解決策の詳細な方法は、各アクティベーションコマンドに対して、数十個のエントリを有するテーブルのエントリの分類を完全に必要とする。そのような分類は、同じＤＤＲ４バンク内の２つの連続するアクティベーション間の最小時間である４５ｎｓ未満で達成することが困難である時間のかかるプロセスである。

【0013】

したがって、米国特許出願公開第２０１４０００６７０４号明細書に記載された解決策は、統合プロセッサを有するＤＲＡＭには適していない。本明細書の目的の１つは、これらの制限のうちの少なくとも部分的に１つ以上を改善することである。

【0014】

国際公開第２０１７０４８４４１号パンフレットおよび米国特許第６４６３００１号パンフレットは、従来のＤＲＡＭメモリをリフレッシュする問題に対処している。

【0015】

国際公開第２０１７／０５５７３２号パンフレットで公開された特許出願は、プロセッサをＤＤＲ４互換ＤＲＡＭチップに組み込むことがどのように実現可能であるかを概説している。

【0016】

米国特許第２０１４０００６７０４号は外部メモリコントローラがＤＲＡＭ内部プロセッサによって生成されたアクティベーションを知らないため、内部プロセッサを有するＤＲＡＭには適していないが、所与の行がアグレッサになる可能性は以下の合計から生じる：
－ この所与の行に対して外部メモリコントローラによって生成されたアクティベーション、および、
－ この所与の行に対してＤＲＡＭメモリの内部プロセッサによって生成されたアクティベーション。

【0017】

ＵＳ ２０１４０００６７０４は、いくつかの単純なシナリオでは機能しない。考慮される固有トリガ値は１２５，０００行のアクティベーションであり、すべての重要なパラメータは、米国特許出願公開第２０１４０００６７０４号明細書に記載された方法に従って計算される。

【0018】

時間窓Ｎは時間Ｔで始まる。

【0019】

２００００行は、Ｔ＋１６ｍｓとＴ＋３２ｍｓとの間でリフレッシュされる。

【0020】

時間Ｔ＋３２ｍｓとＴ＋６４ｍｓとの間で、該２００００層は１２００００回、すなわち、固有トリガ値１２５０００未満でアクティベートされ、したがって、その隣接する行に対して予防的リフレッシュは開始されない。

【0021】

時間窓Ｎによれば、新しい時間窓Ｎ＋１はＴ＋６４ｍｓで開始し、検出論理テーブルは各時間窓の開始時に初期化されるので（米国特許出願第２０１４０００６７０４号に説明されているように）、検出論理テーブルは初期化され、この初期化は特に、２００００行に対応したアクティベーションカウンタのゼロ化につながる。

【0022】

時間Ｔ＋６４ｍｓとＴ＋８０ｍｓとの間では、２００００行はまだリフレッシュされず（６４＋１６ｍｓと６４＋３２ｍｓとの間でリフレッシュされる）、２００００行は１００００回以上アクティベートされる。故に、
２０，０００行は６４ｍｓ未満（Ｔ＋３２ｍｓからＴ＋８０ｍｓ）の期間にわたって１２５，０００回（１３０，０００回）を超えてアクティベートされて、なおかつ、その２つの隣接行に対する予防的リフレッシュが必要であることは、米国特許出願公開第２０１４０００６７０４号によって提案された論理によって発見されていない。

【0023】

ＵＳ２０１４０００６７０４は、ＤＲＡＭへの統合には適していない。外部ＤＲＡＭコントローラは典型的には高速論理を生成するように適合されたプロセスを使用して製造されたＡＳＩＣの一部であり、このようなプロセスは「論理プロセス」と呼ばれる。

【0024】

ＤＲＡＭは特殊な処理で製造され、メモリセルに使用されるコンデンサを構築することを可能にし、そのような処理を使用して構築される論理は、論理処理を使用して構築される場合よりもはるかに遅い。

【0025】

したがって、ＤＲＡＭに実装されるアルゴリズムは、通常、ＡＳＩＣに実装される同じアルゴリズムよりもはるかに遅い。

【0026】

０５２０１４０００６７０４で説明されている唯一の方法は、行アクティベーション数のテーブルをソートすることを必要とする（テーブルソートを除去する方法を説明する実際的な説明はない）。

【0027】

ソートは高価な手順であり、論理プロセス上で実施される場合には十分に高速であり得るが、ＤＲＡＭプロセス上で実施される場合には特に、アルゴリズム全体が同じバンク上の２つのアクティベーションコマンド間の最小時間である４５ｎｓ未満で実行されなければならないことを考慮すると、おそらく十分に高速ではない。

【0028】

〔発明の目的〕
提示される説明の実現の１つは、従来技術の問題のうちの少なくとも部分的に１つまたは複数を解決することである。

【0029】

一態様によれば、メモリデバイスは、１つまたは複数のバンクを備え、各バンクは、複数のＤＲＡＭメモリ行を備える。更にメモリデバイスは、外部アクセスポートと、１つまたは複数の内部プロセッサと、ロウハンマートリガ検出ロジックと、予防的リフレッシュ送信ロジックとを備えている。当該外部アクセスポートは、外部メモリコントローラが各バンクのメモリ行をアクティブにして、次いで、アクセスすることを可能にするように構成されている。前記内部プロセッサは、前記バンクの前記行をアクティブにして、次いでアクセスすることができる。前記ロウハンマートリガ検出ロジックは、外部メモリコントローラおよび１つまたは複数の内部プロセッサからのアクティベーションコマンドを監視する。前記トリガ検出ロジックは、メモリストレージを含む。メモリストレージには、各バンクにおける行のサブセットの各行についての１つまたは複数のテーブルと、追加のカウント値とが記憶されている。当該テーブルは、各行に対するアクティベーションコマンドの数に基づくカウント値を示している。１つまたは複数のテーブル内の当該カウント値に関連する行のサブセットは、当該カウント値に基づいてロウハンマー検出ロジックによって、最も頻繁にアクティブ化されている行を示すように動的に変更される。当該追加のカウント値は、バンクに含まれる各行に対するアクティベーションコマンドの検出に基づいて、各行のアクティベーションコマンド数の最大値を示し、その時点で行のサブセットの一部に含まれない任意の行にある可能性があるアクティベーションコマンド数の最大値を示す。また、当該トリガ検出ロジックは、前記カウント値のそれぞれをしきい値レベルと比較して行のサブセット内の１つまたは複数の行を識別するように構成されているとともに、識別された各行に隣接する行のうちの１つまたは複数の行のリフレッシュ動作を開始するように構成される。前記予防的リフレッシュ送信ロジックは、外部メモリコントローラによって生成された周期的リフレッシュ要求の代わりにリフレッシュ要求を発行することによって、識別された各行の隣接する行のうちの１つまたは複数の行に対するリフレッシュ動作を実施するように構成され、それによって、前記周期的リフレッシュ要求のうちの１つまたは複数を遅延させる。

【0030】

実施形態のうちの１つによれば、前記１つまたは複数のテーブルは、前記サブセットの各行に関連するエントリを含んでおり、前記エントリは、前記カウント値を含み、前記１つまたは複数のテーブルの前記エントリの数は、バンク（１２６）に含まれる行の数の１００分の１未満である。

【0031】

実施形態の１つによれば、前記周期的リフレッシュ要求が遅延される持続時間は、各メモリが時間の経過と共にそのデータを正しく保持することを可能にする最大持続時間を超えない。

【0032】

実施形態のうちの１つによれば、前記予防的リフレッシュ送信ロジックは、識別された行ごとに、リフレッシュされるべき１つまたは複数の隣接する行の指示を記憶するメモリを含む。

【0033】

実施形態の１つによれば、前記外部メモリコントローラによって使用される外部プロトコルは、前記メモリデバイスに自発的にリフレッシュ動作をおこなわせることを可能にする。

【0034】

実施形態のうちの１つによれば、前記ロウハンマートリガ検出ロジック（１２３）は、前記外部メモリコントローラまたは前記内部プロセッサによって発せられる各アクティベーションコマンドの後に、対象の行が前記サブセットの行の一部である場合には、アクティベーションコマンドによって対象とされる行に関連するカウント値を変更し、前記テーブル内の或るエントリのカウント値が追加カウント値に等しい場合には、当該或るエントリを、アクティベーションコマンド対象の行に対応するエントリに置換し、アクティベーションコマンド対象の行が前記サブセットの行の一部ではなく、且つ前記テーブルのカウント値のいずれも追加カウント値と等しくない場合には、前記追加カウント値を変更する。

【0035】

追加の態様によれば、いくつかのメモリ行が含まれる１つまたは複数のＤＲＡＭバンクを含んだメモリデバイスを、ロウハンマー効果から保護する方法が提供される。当該方法は、ロウハンマートリガ検出ロジックを使用して、外部メモリコントローラおよびメモリデバイスの１つまたは複数の内部プロセッサの少なくとも何れかによって発せられるロウアクティベーションコマンドを監視するステップであって、各ロウアクティベーションコマンドは外部メモリコントローラまたは１つまたは複数の内部プロセッサによってアクセスされる前に、前記バンクの行をアクティベートさせるステップと、前記ロウハンマートリガ検出ロジックを使用して、各バンクに含まれる複数の行のサブセットの各行について、当該行についてのアクティベーションコマンドの数に基づくカウント値を示す１つまたは複数のテーブルを記憶するステップであって、１つまたは複数のテーブル内のカウント値に関連する行のサブセットは、カウント値に基づいて前記ロウハンマートリガ検出ロジックによって動的に修正され、各バンクの各行についてのアクティベーションコマンドの検出に基づいて最も頻繁にアクティベートされた行を示すステップと、前記ロウハンマートリガ検出ロジックを使用して、行の前記サブセットに属さない任意の行に向けられたことが可能であったアクティブ化コマンドの最大数を示す追加のカウント値を記憶するステップと、前記ロウハンマートリガ検出ロジックを使用して、１つまたは複数のテーブル内の１つまたは複数の行を識別するために、カウント値のそれぞれをしきい値レベルと比較するステップと、前記ロウハンマートリガ検出ロジックを使用して、識別された行に隣接する１つまたは複数の行をリフレッシュするための動作をトリガするステップと、外部メモリコントローラによって生成された周期的リフレッシュ要求の代わりにリフレッシュ要求を発行することによって、識別された行の１つまたは複数の隣接する行のためのリフレッシュ動作を、予防的リフレッシュ送信ロジックを使用して実施するステップであって、それによって、１つまたは複数の前記周期的リフレッシュ要求を遅延させるステップと、を含む。

【0036】

実施形態のうちの１つによれば、この方法はまた、予防的リフレッシュを送信するためのロジックを使用して、外部メモリコントローラによって生成された定期的なリフレッシュ要求の代わりにリフレッシュ要求を送信することによって、識別された行のそれぞれに隣接する１つまたは複数の行のリフレッシュ動作を実装し、それによって、前記定期的なリフレッシュ要求のうちの１つまたは複数を遅延させることを含む。

【0037】

実施形態のうちの１つによれば、この方法は、前記外部メモリコントローラまたは前記内部プロセッサによって発せられる各アクティベーションコマンドの後に、以下のステップ：対象となる行が前記サブセットの行の一部である場合には、アクティベーションコマンドによって対象とされる行に関連するカウント値を変更するステップ、１つまたは複数のテーブル内の或るエントリのカウント値が前記追加カウント値と等しい場合には、当該或るエントリを、アクティベーションコマンドによって対象とされる行に対応するエントリに置換するステップ、アクティベーションコマンド対象の行が前記サブセットの行の一部ではなく、且つ１つまたは複数のテーブルのカウント値のいずれもが前記追加カウント値と等しくない場合には、前記追加カウント値を変更するステップ、をさらに含む。

【0038】

［図面の簡単な説明］
利点および前の特徴および他の特徴は、関連する図面を参照して、限定されない例として提供される、実施形態の以下の詳細な説明から明らかになるのであろう：
図１は、例示的な実施形態による、プロセッサを統合するメモリデバイスを備えるコンピューティングシステムの一部を概略的に示す。

【0039】

［発明を実施するための形態］
＜概要＞
各ＤＲＡＭバンクについて、以下に説明する実施形態は例えば次の２つのブロック；
－トリガ検出ユニット（またはロジック）と、
－リフレッシュ送信ユニット（またはロジック）と、
を含む。ここで、トリガ検出ユニットがリフレッシュ送信ユニットに供給する。

【0040】

バンクに関する各アクティベーションコマンドについて、以下に詳述するトリガ検出ユニットは、このアクティベーションコマンドによってターゲットとされる行がトリガ値（「しきい値レベル」として知られる）に潜在的に到達したかどうかを示す。用語「潜在的に」は偽陽性が可能であるが、以下に示すように、それらが十分にまれであるため、結果なしであるという事実を反映する。

【0041】

リフレッシュ送信ユニットは例えば、ここでは予防的リフレッシュＦＩＦＯと呼ばれるＦＩＦＯを含み、所与の行をターゲットとするアクティベーションコマンドがそのトリガ値に達したとマークされると、この所与の行の２つの隣接する行の２つのインデックスが計算され、このＦＩＦＯにプッシュされる。

【0042】

予防的リフレッシュＦＩＦＯが空でないとき、予防的リフレッシュが発せられるべきであるが、ＤＲＡＭバンクはそれ自体のイニシアティブでこれらの予防的リフレッシュを開始することができる：
プロトコルの観点から言えば、ＤＲＡＭメモリチップは、外部ＤＲＡＭメモリコントローラのスレーブであるが、自発的にリフレッシュを実行することができるＤＲＡＭチップのバンクを有することは、そのプロトコルを完全に破壊する。

【0043】

ＤＲＡＭに接続された外部メモリコントローラは、定期的にリフレッシュ要求を発生する。定期的なリフレッシュはリフレッシュされるべき行のインデックスを指定せず、このインデックスはリフレッシュカウンタロジックと呼ばれる内部ＤＲＡＭロジックによって生成される（通常、「リフレッシュカウンタ」と呼ばれる単なるカウンタであるため）。

【0044】

したがって、本発明の実施形態では、各バンクがそれ自体のリフレッシュカウンタロジックを有し、ＤＲＡＭバンクが外部ＤＲＡＭコントローラによって生成された定期的なリフレッシュ要求を受け取るたびに、以下のようになる：
－ このバンクの予防的リフレッシュＦＩＦＯが空でない場合、リフレッシュされる行のインデックスはリフレッシュカウンタによって提供されず、予防的リフレッシュＦＩＦＯから除去され、このバンクのリフレッシュカウンタは変更されないままである。
－ 予防的リフレッシュＦＩＦＯが空である場合、リフレッシュされるべき行のインデックスは、このバンクのリフレッシュカウンタによって提供され、このカウンタは更新される。

【0045】

予防的リフレッシュの実行は定期的なリフレッシュによって中断されるので、トリガ値は周期的リフレッシュが必要とされるという発見とその実際の実行との間の最悪の場合の遅延の間に行われることができるアクティベーションの数だけ低減されなければならず、この最悪の場合の遅延は以下のことから生じる：
－ 予防的リフレッシュがペアになって生成されるという事実によって促進される、ＦＩＦＯに、複数の予防的リフレッシュが蓄積され得るという事実
－ 各保留中の予防的リフレッシュの効果的な実現のために、定期的なリフレッシュ要求を待つ必要性。

【0046】

ロジックの固有の待ち時間を無視すると、最悪の場合の遅延は、約Ｍａｘ＿Ｔｒｉｇｇｅｒｅｄ ×２×Ｍａｘ＿Ｔｉｍｅｄ Ｒｅｆｒｅｓｈ＿Ｐｅｒｉｏｄである：ここで、「Ｍａｘ＿Ｔｒｉｇｇｅｒｅｄ」は６４ｍｓの時間窓内にトリガ値に達するのに十分な回数アクティベートできるバンクの行の数であり、「Ｍａｘ＿Ｔｉｍｅｄ Ｒｅｆｒｅｓｈ＿Ｐｅｒｉｏｄ」は、２つの定期的なリフレッシュ要求間の最大時間である。

【0047】

＜リフレッシュウィンドウの延伸＞
予防的リフレッシュの効果的な実行は定期的なリフレッシュを遅延させるが、最大遅延は重要でないほど十分に小さい：
典型的なＤＲＡＭバンクは６５５３６行を有するので、外部メモリコントローラは、１つのバンクに対して、平均して９７６ｎｓ（６４ミリ秒／６５５３６）毎に定期的なリフレッシュを生成する。

【0048】

典型的にはアクティベーションコマンドが所与のバンクに対して４５ｎｓ毎に発信されることができ、これは６４ミリ秒の時間窓に対して、１４２３０００未満のアクティベーションコマンドが同じバンクに発信されることができることを意味し、この数はウィンドウ内で最大アクティベートと呼ばれる。

【0049】

ロウハンマーの固有値の１２５，０００（つまり６４ミリ秒のウィンドウを意味する）を考慮すると、所与のＤＲＡＭバンク内に最高１１のアグレッサが存在し得る。

【0050】

前の例を考慮すると、最悪の場合、６４ｍｓで６５５３６行をリフレッシュする代わりに、６５５３６＋（１１×２）行をリフレッシュすることができ、これは、６４ｍｓから６４，０２２ｍｓへのリフレッシュウィンドウの延伸につながる。６４ｍｓの数字は保守的に低い値であるので、このような小さな延伸は絶対的に問題ではない。

【0051】

＜図１に示す実施形態＞
図１は、本発明による装置を示す。

【0052】

ＡＳＩＣ１１０の一部である外部メモリコントローラ１１１は例えば、メモリデバイス１２０のメモリデバイスのインターフェース１２１に取り付けられたバスを介してメモリデバイス１２０に結合される。

【0053】

ＤＲＡＭバンク１２６は、外部メモリコントローラ１１１および統合プロセッサ１２２によってアクセスすることができる。

【0054】

トリガ検出ロジック１２３は、外部メモリコントローラ１１１および統合プロセッサ１２２によって生成されたアクティベーションコマンドを監視する。

【0055】

トリガ検出ロジック１２３は、「ＴＲＩＧ到達」信号のアサーションを介して、現在アクティベート中の行のアクティベーションによってこの行がトリガ値に潜在的に到達できそうかを示す。

【0056】

リフレッシュ送信ロジック１２４は「ＴＲＩＧ到達」信号を受信すると、「アグレッサになりそうな」行に隣接する２つの行のインデックスを決定し、次いで、例えば、リフレッシュ送信ロジック１２４のＦＩＦＯにこれら２つのインデックスをプッシュする。

【0057】

例えば、ＦＩＦＯは、定期的なリフレッシュスロットを予め空にすることによって空にされる。対応するリフレッシュは、リフレッシュカウンタロジック１２５が更新されないので、例えば失われず、単に遅延される。

【0058】

＜トリガ検出ユニット（またはロジック）＞
後述するように、トリガ検出ユニットによって使用されるアルゴリズムは例えば、近似的であり、これを補償するために、保持される実際のトリガ値Ｔｒｉｇ＿Ｅｆｆは、次に例示されるものである：
－ 第一には、固有のトリガ値の半値に基づく（理由は後述）
－ 別のものとしては、先述したように、実際に実行される予防的リフレッシュを有するために最悪の場合の遅延を考慮に入れるためにさらに低減される。最悪の場合の遅延は主に、Ｔｒｉｇ Ｅｆｆに依存する、保留中の予防的リフレッシュの最大数に依存するので、正確なＴｒｉｇ Ｅｆｆ値は例えば繰り返し算出される。

【0059】

実際的な結果は、厳密に必要とされるよりも多くの予防的リフレッシュを発することができるということである。これは、次のような理由から、これらの予防的リフレッシュの回数が定期的なリフレッシュ回数と比較すれば取るに足らないため、問題ではない。すなわち、
－ 予防的リフレッシュが定期的なリフレッシュスロットを盗用するので、不必要な予防的リフレッシュの放出に起因する性能上の不利益はない、
－ 唯一の実際的な影響としては、６４ｍｓリフレッシュウィンドウを厳密に必要以上に延伸できることである。なぜなら、この延伸はパーセンテージの数値で非常に小さいままであり、問題にならない。

【0060】

これは偽陽性を生成するが、提案されたアルゴリズムはＵＳ２０１４０００６７０４に記載されたシステムとは異なり、偽陰性を生成しない。

【0061】

＜トリガ検出ユニット（またはロジック）のアルゴリズム＞
トリガ検出ロジックは例えば、テーブル、Ｎｂｒのエントリが入力されるＲＡＣＴ（Row Activate Count Table：行アクティベートカウントテーブル）を含む。ここで、Ｎｂｒのエントリ（Ｎｂｒ＿ｏｆ＿ｅｎｔｒｉｅｓ）は、例えば、以下のように計算される：
Ｎｂｒ＿ｏｆ＿ｅｎｔｒｉｅｓ ＝ ＩＮＴ （最大アクティブインウィンドウ ／ Ｔｒｉｇ Ｅｆｆ）
ここで、ＩＮＴ関数は、そのエントリ値を、続くホール値（next whole value）にそれ以下で返す。

【0062】

例えば、各ＲＡＣＴエントリは、次の二つのフィールドを含む：
－ Ｔｒｉｇ＿Ｅｆｆまでの値を含むのに十分な大きさの行カウントフィールド（ROW COUNT field）、
－ 行インデックスのすべての可能な値を含むのに十分な大きさの行インデックスフィールド（ROW INDEX field）、
および、
ｎｏ＿ｒｏｗと呼ばれる行インデックスではない追加の値。

【0063】

さらに、トリガ検出ロジックは、例えば、ＴｒｉｇＥｆｆ－１までの値を含むのに十分な大きさのＯＴＨＥＲ－ＲＯＷＳ－ＣＯＵＮＴと呼ばれるレジスタを含む。

【0064】

任意の周期的な時間参照を使用することができるが、説明を簡単にするために、１つのバンクにおいて、リフレッシュウィンドウは例えば、以下の場合に開始されると言われる：
－ 今期のバンクリフレッシュカウンタロジックは行０を示す場合
－ 外部メモリコントローラによって定期的なリフレッシュ要求が生成される場合。

【0065】

リフレッシュウィンドウが開始するたびに、トリガ検出ロジックは、例えば：
－ すべてのＲＡＣＴエントリの行カウントフィールドをゼロに設定する、
－ すべてのＲＡＣＴテーブルの行インデックスフィールドをｎｏ＿ｒｏｗに初期化する、
－ ＯＴＨＥＲ＿ＲＯＷＳ＿ＣＯＵＮＴレジスタをゼロに設定する。

【0066】

インデックス「Ｊ」を有する行に照準をあてたアクティベーションコマンドがバンクによって実行されるたびに、続いて、トリガ検出ロジックは、例えば、第１の目標及び第２の目標を達成するためにＲＡＣＴエントリを読み出す。ここで、当該第２の目標は、第１の目標に到達しない場合にのみ考慮される：
－ 当該第１の目標は、行インデックスフィールドがＪの値を有するＲＡＣＴエントリを見つけること
－ 当該第２の目標は、行カウントフィールドがＯＴＨＥＲ＿ＲＯＷＳ＿ＣＯＵＮＴに等しいＲＡＣＴエントリを見つけることである。

【0067】

＜第１の目標の達成＞
第１の目標が達成されるとすぐに、エントリの読み取りが停止され、次のようになる：
－ 見つかったエントリの行カウントフィールドの値がインクリメントされ、
－ 見つかったエントリの行カウントフィールドの値がＴｒｉｇ Ｅｆｆに等しい場合は、
－ 見つかったエントリの行インデックスフィールドは例えば、ｎｏ＿ｒｏｗに設定され、
－ 行Ｊに隣接する２つの行の行インデックスが例えば予防的リフレッシュＦＩＦＯにプッシュされる。

【0068】

＜第１の目標は達成されず、第２の目標が達成される場合＞
以下の説明では、見つかったエントリのＲＡＣＴテーブルのインデックスをＦｉｄｘ（Ｆｏｕｎｄ Ｉｎｄｅｘ）と呼ぶことにすると、次の式が与えられる：
ＯＴＨＥＲ＿ＲＯＷＳ＿ＣＯＵＮＴ ＝＝ ＲＡＣＴ［Ｆｉｄｘ］．ＲＯＷＣＯＵＮＴ
次に、トリガ検出ロジックは、以下を実行する：
－ ＲＡＣＴ［Ｆｉｄｘ］．ＲＯＷＣＯＵＮＴがインクリメントされ、
－ ＲＡＣＴ［Ｆｉｄｘ］．ＲＯＷＩＮＤＥＸはＪに設定される。

【0069】

＜第１の目標および第２の目標がともに達成されない場合＞
－ ＯＴＨＥＲ＿ＲＯＷ＿ＣＯＵＮＴがインクリメントされる、
このアルゴリズムでは、行は常に活性化カウンタに関連付けられ、行Ｒは例えば以下である：
－ 行インデックスフィールドがＲに等しいＲＡＣＴエントリの行カウントフィールドに含まれるアクティベーションの数に関連付けられるか、
－ＯＴＨＥＲ ＲＯＷＳ ＣＯＵＮＴレジスタに含まれるアクティベーションの数に関連付けられる。

【0070】

このアルゴリズムは例えば、行に共通に関連付けられた数が、リフレッシュウィンドウの始まり以来、常に実際のアクティベーションの数以上であることを保証する。

【0071】

また、このアルゴリズムは例えば、他ＲＯＷＳ ＣＯＵＮＴが最小のＲＡＣＴ．ＲＯＷＣＯＵＮＴフィールドよりも小さいことを保証し、したがって、このアルゴリズムは行Ｒのアクティブ化の実際の数がＴｒｉｇ Ｅｆｆに達した場合に、これがＯＴＨＥＲ＿ＲＯＷＳ＿ＣＯＵＮＴレジスタではなくＲＡＣＴエントリに起こることを保証する。

【0072】

＜ＦＩＦＯ予防的リフレッシュのサイズ設定＞
予防的リフレッシュは予防的リフレッシュＦＩＦＯに蓄積される可能性があるため、いくつかの実施形態では、このＦＩＦＯにプッシュすることができる予防的リフレッシュの最大数の上限値がそれを適切にサイズ設定するために決定される。

【0073】

Ｔｒｉｇ＿Ｅｆｆアクティベーションをカウントすることによって、潜在的に異なる行をターゲットにすることによって（これは偽陽性がどのように起こり得るかということである）、または単一の行をターゲットにすることによって（そして、それは確かに真の陽性である）、一つのエントリのみがＴｒｉｇ Ｅｆｆの値に到達する。

【0074】

したがって、トリガ検出ロジックが、ＲＡＣＴに入らずに複数の予防的リフレッシュペアを生成することは不可能である。

【0075】

＜代替アルゴリズム＞
上述のアルゴリズムでは、レジスタ値ＯＴＨＥＲ＿ＲＯＷＳ＿ＣＯＵＮＴが例えば、ＲＡＣＴエントリの最小のＲＯＷ＿ＣＯＵＮＴフィールド以下である必要がある。

【0076】

したがって、ＯＴＨＥＲ＿ＲＯＷ＿ＣＯＵＮＴはＴｒｉｇ Ｅｆｆに到達することができず、そうでなければ値は追加のＲＡＣＴエントリになるからである。

【0077】

トリガ検出ロジックは基本的にキャッシュであり、その連想性はエントリの数に等しい。先に説明したアルゴリズムはエントリがＴｒｉｇ Ｅｆｆに到達するたびに、その低減された連想性を有し、エントリは、以下のようにして効果的に除去される：
－ その行インデックスは、ｎｏ＿ｒｏｗに初期化され、アクティブ化された行は、もはやこのエントリに到達することができない
－ その行カウントフィールドは値Ｔｒｉｇ＿Ｅｆｆのままであり、それはＯＴＨＥＲ ＲＯＷＳ ＣＯＵＮＴに等しくすることはできない。

【0078】

初期アルゴリズムの以下の変動は、Ｔｒｉｇ＿Ｅｆｆに到達するＲＡＣＴエントリを再循環させることによって、一定の連想性を維持する：
＜第１の目標の達成＞
第１の目的が達成されるとすぐに、ＲＡＣＴエントリの読み取りが停止される。また、見つかったエントリの行カウントフィールドの値がＴｒｉｇ Ｅｆｆ－１に等しいと、続いて、
－ 見つかったエントリの行インデックスフィールドを、例えばｎｏ＿ｒｏｗに設定し、
－ 見つかったエントリの行カウントフィールドは例えば、他の行カウントによって含まれる値に設定され、行Ｊの２つの隣接の行インデックスは例えば、予防的リフレッシュのためにＦＩＦＯにプッシュされ、
－ そうでなければ、見つかったエントリの行カウントフィールドがインクリメントされる。

【0079】

＜第１の目標は達成されず、第２の目標が達成される場合＞
トリガ検出ロジックは、例えば、以下を実行する：
－ ＲＡＣＴ［Ｆｉｄｘ］．ＲＯＷＣＯＵＮＴがインクリメントされる
－ＲＡＣＴ［Ｆｉｄｘ］．ＲＯＷＩＮＤＥＸがＪに設定される。

【0080】

＜第１の目標および第２の目標がともに達成されない場合＞
－ ＯＴＨＥＲ＿ＲＯＷ＿ＣＯＵＮＴが例えばインクリメントされる。

【0081】

＜代替アルゴリズムにおける予防的リフレッシュＦＩＦＯのサイズ設定＞
この代替アルゴリズムは徐々に減少させる代わりに、一定の連想性を維持し、したがって、必然的に、より少ない偽陽性をもたらす。したがって、それは、初期アルゴリズムよりも多くの予防的リフレッシュを生成することができず、したがって、ＲＡＣＴエントリ毎に２つ以上の予防的リフレッシュを生成することができない。

【0082】

＜Ｔｒｉｇ Ｅｆｆ計算の正当化＞
ロジックは行がＴｒｉｇＥｆｆに到達したかどうかを検出することができる。したがって、新しいリフレッシュウィンドウが開始するとき、任意の行の最大の「過去のアクティベーション」は、そのような値がまだ予防的リフレッシュを生成しないので、Ｔｒｉｇ Ｅｆｆ ｔｒｉｇ－１まで上がる価値がある。

【0083】

したがって、所与のリフレッシュウィンドウ内の値Ｔｒｉｇ＿Ｅｆｆに到達する前に、行は実際に累積（Ｔｒｉｇ Ｅｆｆ－１）＋（Ｔｒｉｇ Ｅｆｆ－１）しており、第１の値（Ｔｒｉｇ＿Ｅｆｆ－１）は前のリフレッシュウィンドウから継承されている。したがって、ロジックは、例えば、反復計算Ｔｒｉｇ Ｅｆｆが固有トリガ値の半値から開始する理由を説明するように、実際には（Ｔｒｉｇ＿Ｅｆｆ×２）－１のアクティベーションのみを確実に検出することができる。

【0084】

＜総括＞
本明細書の実施形態はＤＲＡＭバンクの文脈で説明されてきたが、本明細書で説明される技法は高密度ＤＲＡＭバンク（リフレッシュ動作を有し、ロウハンマー効果を受ける）と同等である任意のメモリアレイに適用することができることは明らかである。

【0085】

例えば、本明細書の異なる部分において、ＤＤＲ４プロトコルが参照されている。明らかに、本明細書に記載される技術は、以下のような、全ての関連するメモリプロトコルに適用され得る：
－ 低電力バージョンのＤＤＲ、ＤＤＲ２、ＤＤＲ３、ＤＤＲ４
－ ＧＤＤＲ、ＧＤＤＲ２、ＧＤＤＲ３、ＧＤＤＲ４、ＧＤＤＲ５
－ ＨＢＭ。

【0086】

さらに、本明細書で説明する実施形態はＤＲＡＭがリフレッシュを実行するためのイニシアチブをとることを可能にするプロトコル（例えば、ＨＭＣプロトコル）を使用して、プロセッサが統合されたメモリデバイスに適用することができる。この場合、ここで説明する予防的リフレッシュ送信部は省略することができ、トリガ検出ユニットのみが残る。

【0087】

簡単にするために、この値が現在使用されているので、６４ｍｓのリフレッシュウィンドウが考慮された。明らかに、本明細書に記載された実施形態は所与のＤＲＡＭ技術によって使用される任意のリフレッシュウィンドウ持続時間に適用することができ、リフレッシュ時間が、温度、電圧、放射レベルなどの外部パラメータの変動に連続的に適応するＤＲＡＭにも適用することができる。

【0088】

同様に、６５５３６に等しい行の数は、現在製造されているＤＲＡＭを代表するものであるため、一例として与えられた。言うまでもなく、本明細書に記載の実施形態は、バンク内に存在する行の数とは無関係に適用することができる。

【0089】

これまでに提示されたアルゴリズムおよびその変形は本発明の範囲内に留まりながら、多くの方法で修正することができる。以下のリストは個々に、または任意のサブコンビネーションにおいて組み合わされて実施され得るそのような変化の例を提供し、このリストは、例として与えられ、限定として与えられるものではない。すなわち、：
－ いくつかのＤＲＡＭバンクで説明されているいくつかの材料資源の因子、
－ 異なるフィールドを持つテーブルを、より少ないフィールドを持つ異なるテーブルに置き換える、
－ テーブルを異なるより小さなテーブルに置き換える。アルゴリズムは、複数のエントリを一度に処理するように変更される。
－ ｎｏ＿ｒｏｗ値の代わりに有効ビットを使用する。この有効ビットは各エントリの追加のフィールドに配置されている。または追加のテーブルではＲＡＣＴ ｒｏｗ ＣｏｕｎｔフィールドとＯＴＨＥＲ ｒｏｗｓ Ｃｏｕｎｔレジスタをカウントする代わりに、有効化コマンドをカウントする。
－ ＲＡＣＴ ＲＯＷ ＣＯＵＮＴ フィールドとＯＴＨＥＲ ＲＯＷ ＣＯＵＮＴレジスタはリフレッシュウィンドウで許可されているアクティベーションコマンドの数で初期化される。
－ 行をトポロジ的に隣接する行パッケージにグループ化し、アクティベーションは行パッケージレベルで行われ、アクティブ化の数がＴｒｉｇ Ｅｆｆに達すると、：
－ アグレッサパッケージのすべての行がリフレッシュされる、
－ アグレッサパッケージに隣接する２つの行がリフレッシュされる（または、リフレッシュが行パッケージの粒度レベルで管理される場合、２つの対応する行がリフレッシュされる）。

【図面の簡単な説明】

【0090】

【図1】例示的な実施形態による、プロセッサを統合するメモリデバイスを備えるコンピューティングシステムの一部を概略的に示す。

【図1】