(57)【特許請求の範囲】
【請求項１】
メモリのターゲット行への期間内でのアクセスの最大数を示す値を取得する検出ロジックと、
前記値と、前記期間内での前記ターゲット行へのアクセス数との比較に少なくとも部分的に基づいて、前記ターゲット行に物理的に隣接する少なくとも１つの行のリフレッシュを前記メモリが行うことを引き起こすメモリコントローラと、
を備える、ロウハンマを監視する装置。
【請求項２】
前記ターゲット行に物理的に隣接する前記少なくとも１つの行は、少なくとも１つのビクティム行を有する、請求項１に記載の装置。
【請求項３】
前記検出ロジックおよび前記メモリコントローラに通信可能に結合された前記メモリを備え、
前記メモリは、複数のメモリセルの多数の物理的な行を有する、請求項１または２に記載の装置。
【請求項４】
前記メモリコントローラは、前記検出ロジックを有する、請求項１から３の何れか１項に記載の装置。
【請求項５】
前記メモリは、前記検出ロジックを有する、請求項３に記載の装置。
【請求項６】
前記メモリに情報を格納するネットワークインターフェースと、
前記メモリからアクセスされたデータに基づいてユーザディスプレイを提供するディスプレイデバイスと
をさらに備える、請求項３に記載の装置。
【請求項７】
前記メモリの設定情報を格納するレジスタをさらに備え、
前記レジスタは、前記値を格納する、請求項１から６の何れか１項に記載の装置。
【請求項８】
前記期間内での前記ターゲット行への前記アクセス数は、
前記検出ロジックによる、アクティベートコマンドに関連するアドレスの特定と、前記アドレスへのアクセス数のカウントの維持とに基づく、請求項１から７の何れか１項に記載の装置。
【請求項９】
前記値と、前記期間内での前記ターゲット行へのアクセス数との前記比較は、前記期間内での前記ターゲット行へのアクセス数が前記値に達したかの判断を含む、請求項１から８の何れか１項に記載の装置。
【請求項１０】
前記値と、前記期間内での前記ターゲット行へのアクセス数との前記比較は、前記期間内での前記ターゲット行へのアクセス数が前記値を超えたかの判断を含む、請求項１から８の何れか１項に記載の装置。
【請求項１１】
前記検出ロジックは、
１または複数のプロセッサにより実行されるソフトウェア、ハードウェア、またはファームウェアの何れかまたは組み合わせを含む回路の１または複数を有し、
前記メモリコントローラは、
１または複数のプロセッサにより実行されるソフトウェア、ハードウェア、またはファームウェアの何れかまたは組み合わせを含む、請求項１から１０の何れか１項に記載の装置。
【請求項１２】
ロウハンマを監視するメモリであって、
リフレッシュのコマンドの受信に応じてターゲット行に物理的に隣接する少なくとも１つの行のリフレッシュを引き起こすロジックを備え、
前記リフレッシュのコマンドは、前記ターゲット行への期間内でのアクセス数が値に達する、または値を超える条件に少なくとも基づく、メモリ。
【請求項１３】
前記ターゲット行に物理的に隣接する前記少なくとも１つの行は、少なくとも１つのビクティム行を有する、請求項１２に記載のメモリ。
【請求項１４】
前記ターゲット行を含む複数のメモリセルの多数の物理的な行を備える、請求項１２または１３に記載のメモリ。
【請求項１５】
当該メモリの設定情報を格納するレジスタをさらに備え、
前記レジスタは、前記値を格納し、
前記値は、当該メモリの前記ターゲット行への期間内でのアクセスの最大数を示す、請求項１２から１４の何れか１項に記載のメモリ。
【請求項１６】
前記ターゲット行への前記期間内でのアクセス数が前記値に達する、または前記値を超える前記条件は、前記期間内で受信されたアクティベートコマンド数のカウントに基づく、請求項１２から１５の何れか１項に記載のメモリ。
【請求項１７】
前記ロジックは、
１または複数のプロセッサにより実行されるソフトウェア、ハードウェア、またはファームウェアの何れかまたは組み合わせを含む、請求項１２から１６の何れか１項に記載のメモリ。
【請求項１８】
メモリのターゲット行への期間内でのアクセスの最大数を示す値を取得する手段と、
前記値と、前記期間内での前記ターゲット行へのアクセス数との比較に少なくとも部分的に基づいて、前記ターゲット行に物理的に隣接する少なくとも１つの行のリフレッシュを前記メモリが行うことを引き起こす手段と、
を備える、ロウハンマを監視する装置。
【請求項１９】
前記ターゲット行に物理的に隣接する前記少なくとも１つの行は、少なくとも１つのビクティム行を有する、請求項１８に記載の装置。
【請求項２０】
前記値と、前記期間内での前記ターゲット行へのアクセス数との前記比較は、前記期間内での前記ターゲット行へのアクセス数が前記値に達したかの判断を含む、請求項１８または１９に記載の装置。
【請求項２１】
前記値と、前記期間内での前記ターゲット行へのアクセス数との前記比較は、前記期間内での前記ターゲット行へのアクセス数が前記値を超えたかの判断を含む、請求項１８または１９に記載の装置。
【請求項２２】
前記期間内での前記ターゲット行への前記アクセス数は、
アクティベートコマンドに関連するアドレスの特定と、前記アドレスへのアクセス数のカウントとに基づく、請求項１８または１９に記載の装置。
【請求項２３】
メモリのターゲット行への期間内でのアクセスの最大数を示す値を取得する段階と、
前記値と、前記期間内での前記ターゲット行へのアクセス数との比較に少なくとも部分的に基づいて、前記ターゲット行に物理的に隣接する少なくとも１つの行のリフレッシュを前記メモリが行うことを引き起こす段階と、
を備える、ロウハンマを監視する方法。
【請求項２４】
前記ターゲット行に物理的に隣接する前記少なくとも１つの行は、少なくとも１つのビクティム行を有する、請求項２３に記載の方法。
【請求項２５】
前記期間内での前記ターゲット行への前記アクセス数は、
アクティベートコマンドに関連するアドレスを特定する段階と、前記アドレスへのアクセス数のカウントを維持する段階とに基づく、請求項２３または２４に記載の方法。
【請求項２６】
前記値と、前記期間内での前記ターゲット行へのアクセス数との前記比較は、前記期間内での前記ターゲット行へのアクセス数が前記値に達したかの判断を含む、請求項２３から２５の何れか１項に記載の方法。
【請求項２７】
前記値と、前記期間内での前記ターゲット行へのアクセス数との前記比較は、前記期間内での前記ターゲット行へのアクセス数が前記値を超えたかの判断を含む、請求項２３から２５の何れか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、概してメモリ管理に関し、より具体的には、格納され、プログラムされた値に基づいてロウハンマイベントを監視することに関する。
【０００２】
＜著作権に関する注意書＞
この特許文献の開示の複数の部分は、著作権保護の対象となる題材を含むかも知れない。著作権所有者は、特許商標庁の特許包袋もしくは記録の通りに特許文献もしくは特許開示が何人により再現されようと異議を申し立てないが、その他のあらゆる著作権およびその他の権利を留保する。著作権表示は、以下に記載されるあらゆる情報、本明細書に添付される図面に記載されるあらゆる情報、および、以下に記載されるいかなるソフトウェアにも適用される：著作権、２０１２年、インテル・コーポレーション、無断複写・複製・転載を禁ず。
【背景技術】
【０００３】
コンピューティング技術の進展により、複数のコンピューティングデバイスはより小さくなり、より多くの処理力を持つようになっている。さらに、それらは、デバイス上で実行されるプログラミング及びコンピューティングのニーズを満たすべく、ますます多くのストレージ及びメモリを含むようになっている。記憶容量の増加と共にデバイスサイズの縮小は、デバイスを高密度にすることで達成されており、ここではますます多くの極小のストレージユニットがメモリデバイス内に存在するが、それぞれはますます小さな寸法を有している。
【０００４】
高密度デバイスの最新世代では、いくつかのデバイスで間欠故障が発生している。例えば、いくつかの既存のＤＤＲ３（デュアルデータレート、バージョン３）ベースシステムは、大きな作業負荷によって間欠故障を経験する。研究員は、メモリセルのリフレッシュウィンドウ内でメモリの単一の行に対して繰り返されたアクセスの障害を追跡した。例えば、３２ｎｍプロセスに関し、６４ｍｓリフレッシュウィンドウにおいて５５０Ｋまたはそれより多い回数、行がアクセスされると、アクセスされた行に物理的に隣接するワードラインは、高確率でデータ破壊を体験する。この状態は、元も頻繁にその状態が観察されるＤＲＡＭ（ダイナミックランダムアクセスメモリ）の産業では、「ロウハンマ」または「シングルロウディスターブ」と称されており、本明細書で当該状態を概して説明するために用いられる。ロウハンマはパスゲートを越えた移行を引き起こすことができる。１つの行に対して繰り返されたアクセスにより引き起こされる漏れ及び寄生電流は、アクセスされていない、物理的に隣接した行でのデータ破壊を引き起こす。
【０００５】
しかしながら、デバイスの種々の世代間でメモリデバイスが異なり、類似デバイスの種々のメーカ間でメモリデバイスが異なり、さらには、同一のメーカ内の種々のバッチ間でメモリデバイスが異なることを、当業者はまた理解している。従って、大きな作業負荷が間欠故障を引き起こすことが観察される一方、全てのデバイスに当てはまる「大きな作業負荷」の明確な定義は存在しない。よって、ロウハンマコンディション（ｒｏｗ  ｈａｍｍｅｒｉｎｇ  ｃｏｎｄｉｔｉｏｎ）は、全てのデバイスに当てはまる一般的なパラメータとして明確には定義されていない。
【図面の簡単な説明】
【０００６】
以下の記載は、本発明の実施形態の実施例として提供する図を示す図面についての記載である。図面は、限定としてではなく、例示としてだけ理解されるべきである。本明細書における一つ以上の「実施形態」についての言及においては、本発明の少なくとも一つの実施例に含まれる特定の特性、構造、もしくは特徴が記載されるものと理解されるべきである。したがって、本明細書に記載される「一つの実施形態において」もしくは「別の実施形態において」等の文言は、本発明の多様な実施形態および実施例を記載しており、必ずしも全てが同じ実施形態について言及しているとは限らない。しかし、必ずしも互いに排他的であるとも限らない。
【図１Ａ】プログラム可能なロウハンマ閾値を用いてロウハンマコンディションを監視するシステムの実施形態のブロック図である。
【図１Ｂ】プログラム可能なロウハンマ閾値に従って検出されたロウハンマイベントを示す、メモリデバイスの列／アドレス情報ロジック及び分散検出ロジックを含むシステムの実施形態のブロック図である。
【図２】ロウハンマ検出ロジックと、メモリデバイスのビクティムロジックを含むシステムの実施形態のブロック図である。
【図３Ａ】メモリデバイスの設定ストレージからの閾値に従ってロウハンマコンディションを監視するシステムの実施形態のブロック図である。
【図３Ｂ】メモリモジュールの設定ストレージからの閾値に従ってロウハンマコンディションを監視するシステムの実施形態のブロック図である。
【図４】プログラム可能なロウハンマ閾値に従ってロウハンマコンディションを検出するプロセスの実施形態のフロー図である。
【図５】メモリデバイスのロウハンマコンディションを監視するプロセスの実施形態のフロー図である。
【図６】ターゲットリフレッシュコマンドをサポートするコマンド真理表の実施形態である。
【図７】ロウハンマの監視が実行可能なコンピューティングシステムの実施形態のブロック図である。
【図８】ロウハンマの監視が実行可能なモバイルデバイスの実施形態のブロック図である。  以下に記載する実施形態のいくつか、または全てを示し、また、本明細書に提示する発明のコンセプトのその他の在り得る実施形態もしくは実施例を示す図面についての記載を含む所定の詳細事項および実施例についての記載が以下に続く。
【発明を実施するための形態】
【０００７】
本明細書中に述べるように、メモリデバイスは、ロウハンマイベントを監視する検出ロジックを含む。検出ロジックはメモリデバイスに対する閾値を取得し、閾値は物理的に隣接した行でのデータ破壊のリスクを生じさせる、タイムウィンドウ内でのアクセス数を示す。検出ロジックは、メモリデバイスの設定情報を格納するレジスタから閾値を取得する。レジスタは、メモリデバイス自体のレジスタであってよく、及び／または、メモリデバイスが属するメモリモジュールの設定ストレージデバイスのエントリであってよい。検出ロジックは、メモリデバイスの行に対するアクセス数が閾値を超過するか判断する。閾値を超過したアクセス数の検出に応じて、検出ロジックは、物理的に隣接したビクティム行を標的とするリフレッシュをメモリデバイスが実行することを引き起こすトリガを生成することができる。
【０００８】
ロウハンマに起因する障害を扱うべく以前に特定された１つのアプローチは、行ごと、リフレッシュサイクルごとに許可されるアクセス数を限定することであり、システム内の性能に対する影響を有している。ロウハンマの障害に対処するべく特定された別のアプローチは、ドレイン誘導障壁低下（ＤＩＢＬ）を改善すべく、埋め込みチャネルアレイトランジスタ（ＢＣＡＴ）内の底部限界寸法（ｂｏｔｔｏｍ  ｃｒｉｔｉｃａｌ  ｄｉｍｅｎｓｉｏｎ（ＢＣＤ））を減少させること、及び／または、チャネル長さを増加させることを含む。しかしながら、デバイスの寸法サイズの変更は、物理的及び現実的な限界の両方を有する。いま特定の寸法が変更されうる限り、製造処理への変更がさらに必要とされるであろう。
【０００９】
また、次世代製品の問題にどう対処するかの問題が未解決で残る。
【００１０】
ロウハンマ問題に対処する別のアプローチは、リフレッシュの間の時間を減らすことである。しかしながら、デバイスの密度が高められたときでさえも、リフレッシュ時間は既に一定に保たれてきている。現在のデバイスは、同一期間内にますます大きな領域をリフレッシュするよう要求されている。よって、リフレッシュ時間をさらに減らすことは、メモリデバイスにおける追加のリフレッシュのオーバーヘッドを要求すること等により、システム内の性能への影響を引き起こすだろう。
【００１１】
現在提案されている、ロウハンマを扱うこれらのアプローチは性能へのネガティブな影響を有する一方、一般的にロウハンマを解決するのに何の処理変更が行われる必要があり、または、どの程度、リフレッシュ時間が変更される必要があるかでさえ明らかではない。
【００１２】
メモリコントローラメーカとメモリデバイスメーカは、概して同一の法人ではない。多くのメモリコントローラメーカは、種々のデバイスメーカからの複数のメモリデバイスとインターフェースすることができるコントローラを製造したい。しかしながら、現在提案されているアプローチは、単一メーカからの複数のメモリデバイスの特定のバッチに対してメモリコントローラを固定するか、そうでなければ、今まで通りロウハンマを承知で製造する。
【００１３】
メモリデバイスの設計変更、または、複数の動作パラメータの変更の代わりに、本明細書中に述べたようなシステムは、ロウハンマイベントを監視して対処するアクティブランタイムメカニズムを提供することができる。監視は、プログラムされた設定値、または、他の閾値に従って積極的に実行されることができ、他の閾値はメモリデバイスに格納され、及び／または、多数のメモリデバイスを含むメモリモジュールに格納される。一実施形態では、メモリコントローラは、任意の行に対するアクセス数がロウハンマコンディションを引き起こすかを判断すべく、メモリデバイスへの各アクセスを監視する。代わりに、監視ロジックは、メモリデバイス及び／またはメモリモジュールに分配されることができる。監視メカニズムは、どこに位置付けられても、ストレージ位置から取得された、格納された閾値の値に従って監視を行う。以下でより詳細に説明されるように、取得された閾値の値に基づいてロウハンマコンディションが検出されると、検出ロジックは、ロウハンマリフレッシュまたはターゲットリフレッシュを引き起こすことができる。
【００１４】
ロウハンマ閾値を格納することは、複数のメモリデバイスサプライヤにまたがってロウハンマ限界が異なり、同一サプライヤまたはメーカ内の種々のバッチにもまたがって異なるという事実を認める。さらに、複数のメモリデバイスは、歴史的に、メモリデバイスの密度を増加させる新たな処理技術に移行している。近い将来にこの傾向が止まることを信じる理由はない。ロウハンマコンディションがメモリ密度の問題である以上、新たな処理技術への移行はまた、ロウハンマ限界または複数のメモリデバイスの閾値を変更する。複数のメモリデバイスを、上述の何らかの理由に対し異なるロウハンマイベント閾値を有することができる、より新しい複数のデバイスに置き換えることは一般的である。閾値を格納し、それを監視に用いることは、メモリサブシステムが、メモリサブシステム内に存在するデバイスに固有のロウハンマを追跡することを可能にする。
【００１５】
従って、複数のメモリコントローラは、複数の行へのアクセス数を追跡し（ロウハンマの追跡）、標的とされる複数の隣接する行をリフレッシュするコマンドを複数のメモリデバイスに対して発行することができる。一実施形態では、閾値情報は、メモリデバイス（例えばＤＲＡＭ）自体のレジスタに格納される。そのような情報は、メーカ、デバイス分析者などにより融合されることができる。一実施形態では、この値は設定レジスタ内のフィールドとして格納される。フィールドは、その特性が決定された後に、特定のメモリデバイスに書き込まれるか、或いは、メモリモジュール（例えばＤＩＭＭ（デュアルインラインメモリモジュール））に書き込まれる。
【００１６】
この情報の格納が多数の異なる方法の何れにおいても実行され得ることは理解されるだろう。一実施形態では、情報はデバイス及び／またはメモリモジュール内でエンコードされる。例えば、３ビットコードが、閾値の限界を提供するために用いられ得る。エンコードは、複数のメモリコントローラサプライヤ、複数のメモリデバイスサプライヤ、種々のサードパーティ、またはいくつかの組み合わせによって取り決められる任意の方法で確立され得る。エンコードが設定され得る様々な態様の、複数の例は以下の通りである。エンコードの例１：０００‐限定なし；００１‐５００Ｋ；０１０‐４００Ｋ；０１１−３００Ｋ；１００−２５０Ｋ；１０１−２００Ｋ；１１０−１５０Ｋ；１１１−１００Ｋ。例２：０００−１００Ｋまたは定義されず；００１−１５０Ｋ；０１０−２００Ｋ；０１１−２５０Ｋ；１００−３００Ｋ；１０１−４００Ｋ；１１０−４５０Ｋ＋；１１１−未知のＲＨ限定。これらの例で用いられる複数の特定の値に対し、現実的には無数の変形が存在することは当業者であれば理解するであろう。従って、これらの例はエンコードを説明することを意図しており、限定として理解されることを意図していない。
【００１７】
本明細書で提供される例は、基本的にＤＲＡＭに関するロウハンマ問題について論じる。しかしながら、ロウハンマ問題はより一般的には、メモリ密度の増加に伴って生じる、メモリデバイスの拡大縮小の問題であることが理解されるだろう。従って、ＤＲＡＭに関する説明は、メモリコントローラ、または等価なロジックを含む他のメモリ技術に適用可能な、非限定的な例として理解されるだろう。本明細書で説明されるターゲットリフレッシュコマンドは、ＤＤＲ４（デュアルデータレート  バージョン４、本願出願時の開発における仕様）、ＬＰＤＤＲ４（低電力デュアルデータレート  バージョン４、本願出願時の開発における仕様）、またはＷＩＤＥＩＯ（本願出願時の開発における仕様）のような多数のメモリ技術の全てと互換性を有する。同様に、ロウハンマコンディションの限界情報の格納は、メモリデバイスが自身に設定情報を格納でき、及び／または、メモリモジュールが設定情報を格納できる全てのメモリ技術と互換性を有する。
【００１８】
図１Ａは、プログラム可能なロウハンマ閾値を用いてロウハンマコンディションを監視するシステムの実施形態のブロック図である。一実施形態では、格納された閾値の使用は、プログラム可能なロウハンマ閾値と称され得る。システム１００は、メモリコントローラ１２０に結合されたメモリデバイス１１０を含む。メモリデバイス１１０は、ワードラインまたは同等のものを介してデータがアクセス可能な、複数のメモリセルからなる複数の隣接する行を有する任意のタイプのメモリ技術を含むことができる。一実施形態では、メモリデバイス１１０はダイナミックランダムアクセスメモリ（ＤＲＡＭ）技術を含む。
【００１９】
メモリデバイス１１０は、メモリの１または複数の論理及び／または物理グループ（これは複数のランク（ｒａｎｋ）、複数のバンク（ｂａｎｋ）及び／または他のグルーピングを含み得る）を表すメモリアレイ１１２を含む。システム１００内では具体的に示されていないが、メモリアレイ１１２は、タイムウィンドウ内で繰り返されたアクセスのターゲットである１または複数の行を含んでよい。そのような行は、ロウハンマコンディションの対象となる。多くの近代的なメモリデバイスにおいて、半導体レイアウトのアーキテクチャは、１または複数の物理的に隣接した行を破損のリスクにさらす。ロウハンマコンディションに起因して破損されるリスクにさらされるこの１つの行、または、複数の行は、本明細書でビクティム行と称される。
【００２０】
メモリデバイス１１０は、メモリアレイ１１２内の適切なメモリ位置に対するアクセス命令をデコードするために用いられる列ロジック１１４及び行ロジック１１６を含む。行数及び列数が等しい必要はなく、実際に、それらは一般的に等しくない。メモリコントローラ１２０は、コマンドバス（例えば、コマンド／アドレス（Ｃ／Ａ）バス）を通じて複数のコマンドまたは複数の命令をメモリデバイス１１０に送信し、これらは次にメモリデバイス１１０によって解釈される。メモリデバイス１１０は、コマンド情報をデコードして、メモリ内で様々なアクセス機能を実行するとともに、列ロジック１１４及び行ロジック１１６を介してアドレス情報をデコードする。ロジックは、列アドレスストローブまたは信号（ＣＡＳ）及び行アドレスストローブまたは信号（ＲＡＳ）の組み合わせを用いてメモリ内の特定位置にアクセスする。メモリの複数の行は、既知の複数のメモリアーキテクチャまたはそれらの派生に従って実施されうる。簡単にいえば、メモリの行は、列ロジック１１４により生成されるＣＡＳによって特定されるような、複数のメモリセルの１または複数のアドレス指定可能な列を含む。複数の行は、行ロジック１１６により生成されるＲＡＳを介してアドレス指定可能である。
【００２１】
一実施形態では、メモリデバイスは設定１１８を含む。一実施形態では、設定１１８はメモリデバイス１1０内に格納される。代わりに、設定１１８は、メモリデバイス１１０に関連する設定を表し、メモリデバイス１１０以外のどこかに格納される。設定１１８は、メモリデバイス内のレジスタデバイスまたは他のストレージデバイスに格納されうる。
【００２２】
システム１００は検出器１３０を含み、検出器１３０は、ハードウェア及び／またはソフトウェア、またはシステム１００がロウハンマイベントまたはロウハンマコンディションを検出することを可能にする他のロジックを表す。ロウハンマコンディションを検出するために用いられる多数の異なるメカニズムが存在し得る。システム１００は、検出器１３０を介してロウハンマコンディションを検出する。検出器１３０は、一実施形態では、メモリの複数の選択行へのアクセスを監視するための表またはログを含む。従って、検出器１３０は、メモリアレイ１１２の行がいつ閾値の期間内で繰り返されたアクセスを体験するかを判断することができる。検出器１３０は、メモリデバイス１１０、メモリコントローラ１２０に、及び／または、メモリデバイスまたはメモリコントローラのいずれかと別個に、ハードウェア及び／またはロジックを含んでよい。
【００２３】
検出器１３０は、期間内に行がアクセスされた回数を特定する。
【００２４】
検出器は、設定１１８からのロウハンマ閾値情報にアクセスするか、さもなければ設定１１８から取得する。ロウハンマイベントは、単純に、行がアクセスされた回数に関するのではなく、所定期間内にアクセスされた回数に関する。一旦、行がリフレッシュされると、データ破壊を引き起こしうる状態は克服される。従って、監視期間はリフレッシュレートの少なくとも一部に基づいてよい。一実施形態では、検出器１３０が閾値のアクセス数を監視する期間は、メモリデバイス１１０のリフレッシュサイクル時間に等しい。
【００２５】
期間内のアクセス数は設定１１８から決定される。
【００２６】
一実施形態では、メモリコントローラ１２０はターゲットリフレッシュコマンド１２２を生成し、メモリコントローラがロウハンマイベントの検出に応じてターゲットリフレッシュ（ｔａｒｇｅｔｅｄ  ｒｅｆｒｅｓｈ）を実行することを引き起こす。ターゲットリフレッシュコマンド１２２は、「オフスケジュール」で発生するリフレッシュコマンドであり、リフレッシュ実行時間になったことをタイマが示すという理由でコマンドを送信することとは対照的に、当該コマンドがロウハンマイベントの検出に応じて送信されることを意味する。一実施形態では、メモリコントローラ１２０はターゲットリフレッシュコマンドを送信するための既存のコマンドを倍加（ｄｏｕｂｌｅｓ  ｕｐ）する。例えば、ターゲットリフレッシュコマンド１２２は、ＤＲＡＭ（ダイナミックランダムアクセスメモリ）に対して定義されるように、アクティブ化またはリフレッシュのコマンドを用いて倍加されることができる。メモリコントローラは、例えば、別のピン及び／またはモードレジスタ状態の使用によって倍加を達成することができる。これらは、メモリデバイスがコマンドを、アクティブ化または（標準）リフレッシュコマンドではなく、ターゲットリフレッシュとして解釈することを引き起こし得る。メモリコントローラ１２０はハンマロウを示すアドレス情報を提供する。検出器１３０は、行を特定するアドレス情報を示すことができ、アドレス情報は、メモリコントローラ１２０がメモリデバイス１１０に示すことができ、どのビクティム行がリフレッシュされるべきかをメモリデバイスに判断させる。アドレスはメモリデバイスに具体的に示すことができ、或いは、より一般的に提供することができる。従って、メモリの特定の行がロウハンマコンディションの対象になったと検出器１３０が判断したとき（アクセスが閾値に達したか、或いは閾値を超過したとき）には、それはメモリコントローラ１２０に当該行を示し、メモリコントローラ１２０は逐次、ターゲットリフレッシュコマンドを送信することができる。
【００２７】
ターゲットリフレッシュコマンド１２２に言及するとき、複数のデバイスの複数のメモリリソースを利用するべく、種々のメモリデバイスメーカが種々のロジック及びアーキテクチャを使用することが理解されるだろう。例えば、種々のメモリデバイスメーカは、ホストプロセッサ（不図示）で使用される複数の論理メモリアドレスと、メモリデバイス１１０に対して内部で使用される複数の物理メモリアドレスとをマッピングするべく、種々のオフセットを使用することができる。一実施形態では、メモリコントローラ１２０はホストプロセッサによって用いられるのと同一の論理メモリアドレスを用いる。従って、一実施形態では、メモリコントローラ１２０は、ハンマロウを示す行アドレスをメモリデバイス１１０に提供する。メモリコントローラは、メモリコントローラがメモリデバイス１１０に対して発行するコマンドと合わせて、及び／または、コマンドの一部として、行アドレスを示すことができる。次に、メモリデバイスは、任意のビクティム行の特定のアドレス、または複数のアドレスを算出することができる。次に、メモリデバイス１１０は、物理的に隣接したビクティム行でターゲットリフレッシュを実行する。
【００２８】
一実施形態では、検出器１３０は、特定のメモリデバイスに対して取得された情報に基づいて、ターゲットリフレッシュをメモリコントローラに引き起こさせるロウハンマイベントを定義するアクセス数をセットするための設定だけでなく、ロウハンマコンディションを監視するためのタイムフレームをセットするための設定を含む。検出器１３０は、システム１００における行の総数のサブセットのデータを維持する。一実施形態では、検出器１３０は、設定されたタイムフレームに対して予期される最大ビクティムカウントであるＭＶＣに基づいて、多数の行のデータを維持する。例えば、検出器１３０は、ＭＶＣ＋１個のエントリ、または、これより多いエントリを有する表を維持する。次に、検出器１３０は、アクセスされた複数のメモリ位置に対するエントリを表にロールインし、表の最低カウントの複数のエントリをロールアウトして、それらを置き換える。
【００２９】
説明された閾値がまた、ロウハンマコンディションを引き起こすメモリの複数の行へのアクセスレートを指すアクセスレートの閾値、ロウハンマコンディションが存在すると検出され得る閾値を指すロウハンマ閾値、または、データ破壊のリスクが存在する点を表す、ウィンドウ内でのアクセス数の限界を指すロウハンマ限界として説明され得ることは理解されるだろう。タイムウィンドウ内で検出される多数のアクセスがデータ破壊を避けるべくシステムによって対処され得るという事実を指す他の表現もまた使用されてよい。
【００３０】
図１Ｂは、プログラム可能なロウハンマ閾値に従って検出されたロウハンマイベントを示す、メモリデバイスの列／アドレス情報ロジック及び分散検出ロジックを含むシステムの実施形態のブロック図である。システム１５０は、本明細書に記載された任意の実施形態に係る、メモリデバイスまたはメモリサブシステム、及び、メモリコントローラを含むシステムである。システム１５０は、メモリコントローラ１２０に結合されたメモリデバイス１１０を含む。メモリデバイス１１０は、複数のメモリセルの複数の隣接する行を有する任意のタイプのメモリ技術を含んでよく、データがワードラインまたは同等のものを介してアクセス可能である。
【００３１】
メモリデバイス１１０は、メモリの１または複数の論理及び／または物理グループを表すメモリアレイ１１２を含む。一実施形態では、メモリデバイス１１０は、メモリアレイ１１２内の特定のメモリ位置へのアクセス命令をデコードするために用いられるＣ／Ａロジック１６６を含む。Ｃ／Ａロジック１６６は、読み取り及び／または書き込みのためにメモリ位置をアクティブ化する列ロジック及び行ロジックのようなデコードロジック１６８を含む。Ｃ／Ａロジック１６６は、Ｃ／Ａレジスタ（例えばＲＤＩＭＭまたはＬＲＤＩＭＭデバイスのレジスタ）として、Ｃ／Ａバッファまたは他のロジックバッファ（例えば３ＤＳ（３次元スタック）設定またはバッファオンボード実装におけるレジスタ）、または他のロジックデバイスとして実装され得る。
【００３２】
一実施形態では、Ｃ／Ａロジック１６６は、ハイブリッドメモリキューブ（ＨＭＣ）のような、３次元スタックされたメモリデバイス内のロジックバッファとして実装され、複数のＤＲＡＭデバイスがロジックバッファの上部にスタックされる。
【００３３】
メモリコントローラ１２０は、コマンドバス（例えばコマンド／アドレス（Ｃ／Ａ）バス）を通じてメモリデバイス１１０に複数のコマンドまたは複数の命令（Ｃ／Ａ情報１２４）を送信し、これらは次に、メモリデバイス１１０により解釈される。
【００３４】
メモリデバイス１１０は、コマンド情報をデコードして、メモリ内で様々なアクセス機能を実行し、デコードロジック１６８を介してアドレス情報をデコードする。このロジックは、列アドレスストローブまたは信号（ＣＡＳ）、及び、行アドレスストローブまたは信号（ＲＡＳ）の組み合わせを用いてメモリ内の特定位置にアクセスする。メモリの複数の行は、既知の複数のメモリアーキテクチャまたはそれらの派生に従って実施されうる。簡単にいえば、メモリの行は、ＣＡＳによって特定されるような、複数のメモリセルの１または複数のアドレス指定可能な列を含む。複数の行は、ＲＡＳを介してアドレス指定可能である。
【００３５】
一実施形態では、メモリデバイス１１０は検出器１６４を含み、検出器１６４は、メモリデバイス１１０がロウハンマイベントまたはロウハンマコンディションを検出することを可能にするハードウェア及び／またはソフトウェア、または他のロジックを表す。一実施形態では、検出器１６４はＣ／Ａロジック１６６内に含まれる。いずれの場合でも、検出器１６４は、ロウハンマコンディションを監視すべくメモリデバイス１１０においてロジックを含むという点で、分散していると言うことができる。ロウハンマイベントの検出は、メモリリソースのアレイ、デバイス、ランク、または、他の区切りごとに実行される。
【００３６】
ロウハンマコンディションを検出するために用いられる多数の異なるメカニズムが存在し得る。
【００３７】
検出器１６４は、メモリの選択行へのアクセスを監視するための表またはログを含んでよい。メモリデバイス１１０が検出器のロジックを含む場合には、検出器１６４は、設定１１８に格納された閾値情報に基づいてロウハンマコンディションを監視することができる。ロウハンマイベントまたはロウハンマコンディションが検出されたときには、一実施形態では、Ｃ／Ａロジック１６６は、警告信号１２６を生成してメモリコントローラ１２０に当該状態を示す。本明細書に記載された任意の実施形態に従い、メモリコントローラ１２０は、警告に応じて、ロウハンマイベントの検出に応じて、ターゲットリフレッシュを引き起こす。
【００３８】
図２は、ロウハンマ検出ロジックと、メモリデバイスのビクティムロジックを含むシステムの実施形態のブロック図である。システム２００は、本明細書に記載された任意の実施形態に係る、メモリサブシステムの一例であり得る。システム２００は、メモリサブシステムの論理的な１つの理解を示す。ＤＲＡＭ２１０は、既知のメモリアーキテクチャまたはその派生に係るメモリの複数の行である、メモリ２１２内のメモリの複数の行を含む。簡単にいえば、メモリの行は、複数のメモリセルの１または複数のアドレス指定可能な列を含む。一実施形態では、ＤＲＡＭ２１０は、メモリコントローラ２３０からの論理アドレス情報をメモリ２１２における物理メモリ位置にマッピングする。
【００３９】
メモリコントローラ２３０により提供される、「隣接する」メモリアドレス（一般的に論理アドレス）が、ＤＲＡＭ２１０における物理的に隣接したメモリ位置に必ずしもマッピングされないような態様で一般的にメモリがアクセスされることは理解される。むしろ、隣接した各メモリアドレスは、メモリコントローラ２３０により提供されるときに、いくらかの一貫したオフセットに従って位置付けられる複数のアドレスにマッピングされる。いくつかのメモリデバイスはアドレスをスクランブルし、従って、アドレス情報を逆スクランブルすることによってメモリデバイス自体で特定される複数のビクティム行をもたらす。例えば、アドレス０ｘＸ０ｈ、０ｘＸ１ｈ及び０ｘＸ２ｈは、オフセットが「４」の場合に、それぞれ物理的位置０ｘＹ０ｈ、０ｘＹ３ｈ及び０ｘＹ７ｈに位置付けられる。この例において、「Ｘ」はメモリコントローラから提供されるときに複数のアドレスの上位ビット情報を表し、「Ｙ」はＤＲＡＭ２１０内にマッピングされるときに複数のアドレスの上位ビット情報を表す。
【００４０】
従って、メモリコントローラによりターゲットリフレッシュコマンドと共に提供されたアドレス情報と合わせて、デバイスの設定に基づいて、メモリデバイス自体がビクティム行を特定することができる。
【００４１】
ホストプロセッサ２４０は、プロセッシングユニット、プロセッサ、中央処理ユニット（ＣＰＵ）、グラフィクスプロセッシングユニット（ＧＰＵ）、マイクロコントローラ、またはプロセッシングデバイスの任意のタイプであってよい。概して、ホストプロセッサ２４０は、メモリコントローラ２３０を介してＤＲＡＭ２１０及び他のメモリデバイスにアクセスする。一実施形態では、メモリコントローラ２３０は、ホストプロセッサ２４０、または、ホストプロセッサ２４０のプロセッサパッケージの一部である。代替的な実施形態では、メモリコントローラ２３０は、サポートされた「チップセット」またはハードウェアロジックの一部であり、これらはホストプロセッサ２４０を一部とするハードウェアプラットフォームに対し、電力及びインターフェースロジックのための基盤を提供する。一実施形態では、ＤＲＡＭ２１０は、揮発性メモリであるか、或いは、電力がデバイスに対して遮断されたか否かが非決定性の複数のコンテンツを有するメモリデバイスである。従って、揮発性メモリは、データの損失または破損を避けるべく、揮発性メモリにメモリセルのリフレッシュを可能にする常用電源を必要とする。上述のように、検出ロジック２３４は、ロウハンマコンディションを識別するシステム２００がターゲットリフレッシュを用いてロウハンマコンディションに反応できるようにすることを可能にする。
【００４２】
ＤＲＡＭ２１０は、ロウハンマコンディションに起因してどの行または複数の行が破損のリスクにさらされているかを判断するロジックを表すビクティムロジック２１４を含む。一実施形態では、ビクティムロジック２１４は少なくとも部分的にメモリコントローラ２３０で実行されうる。しかしながら、メモリコントローラ２３０と、他のタイプのメモリデバイスとの間での、より広い相互運用性を目的として、概して、ビクティムロジック２１４はＤＲＡＭ２１０に存在する。従って、メモリコントローラ２３０は、ターゲットリフレッシュを引き起こすためのターゲットリフレッシュトリガをＤＲＡＭ２１０に提供しさえすればよい。ＤＲＡＭ２１０は、どの行または複数行が潜在的にビクティムであるかを判断するべく、マッピングまたは他のロジックを使用してよい。
【００４３】
ＤＲＡＭ２１０は、メモリ２１２のリフレッシュを行うロジックを含む制御ロジック２１６を有する。各メモリデバイスは、どのメモリセルがリフレッシュされており、どの行が次にリフレッシュされるべきかを記録するいくつかのロジックを含む。制御ロジック２１６は、ターゲットリフレッシュコマンドの受信に基づいて、実際のターゲットリフレッシュを実施することができる。
【００４４】
ＤＲＡＭ２１０は、ＤＲＡＭ２１０の設定、及び／または、ＤＲＡＭ２１０及びメモリコントローラ２３０の間の通信の設定を考慮に入れる１または複数レジスタ２１８を含んでよい。一実施形態では、レジスタ２１８は、ロウハンマコンディションを表すアクセス数を示す閾値情報を格納する。メモリコントローラ２３０は、コマンドロジック２３２を含む。
【００４５】
コマンドロジック２３２は、メモリコントローラ２３０がレジスタ２１８に対して読み出し及び／または書き込みを行うことを可能にする。一実施形態では、メモリコントローラ２３０は、ターゲットリフレッシュをメモリデバイスに行わせるべく、ＤＲＡＭ２１０のレジスタ２１８に値をセットすることで、ターゲットリフレッシュを引き起こす。一実施形態では、メモリコントローラ２３０は、レジスタ２１８から読み出された閾値を、行へのアクセス数が超過したことが検出されると、ターゲットリフレッシュを引き起こす。検出ロジック２３４は、本明細書に記載された任意の実施形態に係るロジックを表し、レジスタ２１８から読み出された閾値を、行へのアクセス数が超過したことをメモリコントローラ２３０が判断することを可能にする。
【００４６】
図３Ａは、メモリデバイスの設定ストレージからの閾値に従ってロウハンマコンディションを監視するシステムの実施形態のブロック図である。システム３０２は、メモリコントローラ３３０、メモリデバイス３２０及び検出器３１０を有するメモリサブシステムを含むシステムの一例を表す。システム３０２は、上述のシステム１００、１５０または２００に係るシステムの一例を提供する。一実施形態では、検出器３１０はメモリコントローラ３３０の一部である。メモリコントローラ３３０は、検出器３１０によるロウハンマコンディションの検出に応じて、ターゲットリフレッシュコマンドを発行しうる。
【００４７】
メモリデバイス３２０は、メモリの多数の行を含む。複数の行のなかにターゲット行３２２があり、ターゲット行３２２は期間内で繰り返されたアクセスのターゲットの行である。ビクティム行３２４は、ターゲット行３２２のハンマリングに起因するデータ破壊のリスクにさらされている行である。ハンマロウに関連して２以上のビクティム行が存在してよい（例えばハンマロウに物理的に隣接する各行など）。一実施形態では、メモリデバイス３２０は、ロウハンマまたはアクセスレートの閾値を表すべくメモリデバイスに対して決定された特定の値を示す設定３４０を含む。ロウハンマ閾値は、メーカにより決定されてよい。
【００４８】
一実施形態では、検出器３１０はアクセスログ３１２を含む。アクセスログ３１２は、情報の多数のフィールドを有する複数のエントリを格納するリストまたはアレイまたは表または他の論理構造として実装されてよい。各エントリは、メモリの特定の行に対するアドレスまたは識別子と、エントリに対するアクセスカウントとを少なくとも含む。アクセスログ３１２におけるエントリの数は、メモリデバイス３２０における行の総数よりもずっと小さい。従って、検出器３１０は、全ての行のサブセットに対するカウントを維持することによって監視することができる。各行のカウントは、その行が再びアクセスされるときにインクリメントされ得る。カウントは、その行が閾値に等しい回数だけアクセスされたかを判断するべく、閾値に対して比較され得る。
【００４９】
検出ロジック３１４は、アクセスコマンドがメモリの行に向けられたことを検出器３１０が判断できるようにするロジックを含む。検出ロジック３１４は、ターゲット行３２２へのラインと共に具体的に示されているが、検出ロジック３１４は、設定または構成情報３４０に明記されたロウハンマ閾値に従ってすべての行へのアクセスを監視することができる。一実施形態では、検出ロジック３１４は、メモリコントローラ３３０により発行されたアクティベートコマンドのアドレスを特定するメカニズムを含む。従って、メモリの行をアクティブ化するコマンドをメモリコントローラ３３０がメモリデバイス３２０に送信する度に、検出器３１０は、コマンドに関連付けられるアドレスを識別し、そのアドレスに対するアクセスをアクセスログ３１２に記録する。
【００５０】
検出器３１０は、行に対するアクセスが閾値を超過するときを特定し、メモリコントローラにその行アドレス情報を示す。アクセスログ３１２におけるアドレス情報が、物理メモリリソースにアクセスすべくメモリデバイス３２０によって用いられるアドレスと必ずしも同一でないことは理解されよう。
【００５１】
メモリデバイス３２０は、メモリコントローラ３３０により複数の物理リソースに送信された複数のアドレスをデコードする。従って、アクセスが閾値に達したか、または超過した行を検出器３１０が特定したとき、その情報は、ターゲット行３２２の物理リソースを識別するべく、さらにデコードされる必要があるかも知れず、これにより、物理的に隣接したビクティム行３２４が特定できる。
【００５２】
検出器３１０はタイマ情報３１６を受信し、これを通じて検出器３１０は、タイムフレームの終了と同様に、タイムフレームまたは期間またはタイムウィンドウの開始を識別することができる。監視は、タイムフレームの開始と終了の間で行われる。一実施形態では、タイムフレームは、１つのスケジュールされたリフレッシュから、次のスケジュールされたリフレッシュまでである。
【００５３】
一実施形態では、エントリのカウントが閾値に達し、メモリコントローラに特定されたときに、検出器３１０は、アクセスログ３１２のエントリのカウントをクリアする。検出がランク及び／またはバンクの粒度に基づいて実行されることは理解されるだろう。メモリコントローラに対して必ずしも単一の検出器３１０は存在しない。各バンクは追跡されることができ、各メモリチャネルは監視を受けることができる。
【００５４】
図３Ｂは、メモリモジュールの設定ストレージからの閾値に従ってロウハンマコンディションを監視するシステムの実施形態のブロック図である。システム３０４は、本明細書で説明されるシステム３０２または任意の他のメモリサブシステムの実施形態の一例を示す。システム３０２は単一のメモリデバイス３２０を示すのに対し、システム３０４は、多数のメモリデバイス３２０を含むメモリモジュール３５０を示す。いくつかのシステムにおいて、メモリデバイスは、ホストデバイスのマザーボードまたは主要な回路基板上に直に配置される。システム３０２は、ホストシステム基板上にメモリデバイス３２０が直に置かれたメモリサブシステムを表す。システム３０４は、一般的にコネクタを介してホストシステム基板に接続されるモジュールボードの使用を表す。システム３０２におけるメモリコントローラ３３０、検出器３１０、アクセスログ３１２、検出ロジック３１４及びタイマ３１６に関する説明は、システム３０４に対しても同様に適切に適用される。
【００５５】
メモリモジュール３５０は、多数のメモリデバイス３２０を含み、分散した検出器３５４はメモリモジュール３５０に含まれうる。一実施形態では、メモリモジュール３５０は設定３５２で表される構成デバイスを含む。一実施形態では、設定または構成情報３５２は、一般に複数のＤＩＭＭまたは互換性のあるモジュールデバイス上で使用される直列プレゼンス検出（ＳＰＤ）デバイスに含まれる。
【００５６】
一般的に、ＳＰＤは、サイズ、スピード、アーキテクチャの詳細に関するデータ、及び／または、他の製造データを含むメモリモジュール上に設けられた小型のシリアルＥＥＰＲＯＭ（ｅｌｅｃｔｒｏｎｉｃａｌｌｙ  ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）またはフラッシュデバイスである。概して、メモリのメーカまたは分析者または他の下請け業者は、製造／確認プロセスの間にＳＰＤをプログラムする。
【００５７】
メモリコントローラ３３０及び／または検出器３１０は、設定３５２からデータを読み出しうる。従って、メモリサプライヤは、メモリモジュール３５０上のメモリデバイス３２０のグループ全体に対する情報をプログラムすることができる。
【００５８】
一実施形態では、設定３５２を格納するメモリモジュール３５０に加えて、各メモリデバイス３２０が設定または構成情報３４０を含む。さまざまなデバイス内でバリエーションを有することは可能であり、この場合、１つのデバイスが１つの閾値に従って動作し、別のデバイスが別の閾値に従って動作する。ＳＰＤは、最悪の場合の値を、それに備えて有してよく、各デバイス（例えばＭＰＲにおける）は、例えば、デバイスに特定の値を格納してよい。メモリコントローラは、モジュールごとに追跡してよく（例えば、ＤＩＭＭごと）、或いは、最低の閾値によって追跡してよい。
【００５９】
メモリモジュール３５０上の１または複数のメモリデバイス３２０が異なる閾値を持ちうることは理解されるだろう。一実施形態では、検出器３１０は、個々のメモリデバイス３２０の設定レジスタからの個々の設定情報３４０に基づいてロウハンマコンディションを監視する。そのような実施形態は、設定３５２がメモリモジュールに対して存在する実装を含んでよい。代わりに、各メモリデバイス３２０が個々の設定３４０を備えるにも関わらず検出器３１０が設定３５２に基づいて監視してもよい。一実施形態では、検出器３１０は、コンフリクト（すなわち異なる閾値）が無い限り、個々の設定３４０に基づいて監視し、コンフリクトがある場合には設定３５２に基づいて監視する。
【００６０】
一実施形態では、メモリモジュール３５０上の閾値設定３５２は、任意のメモリデバイス３２０の、最も限定的な閾値、または、低い方の閾値を格納する。メモリモジュール３５０は、そのような判断を行って値を格納するロジックを含んでよい。代わりに、メモリコントローラ３３０は、各メモリデバイス３２０の複数の構成デバイスから閾値を読み出し、設定３５２に閾値情報を書き込んでよい。一実施形態では、ロウハンマ閾値情報は、単純に、設定３５２の、及び／または、設定情報３４０の１つのフィールドである。一実施形態では、設定３４０は、ベンダー特有の情報に用いることができる、多目的のレジスタ（ＭＰＲ）または各ストレージデバイス３２０のページ３に格納される。従って、種々の複数のロット、複数の処理、複数のメモリデバイス３２０のサプライヤに起因する複数の異なる閾値は、システム３０２および３０４において効率的に追跡されうる。
【００６１】
図４は、プログラム可能なロウハンマ閾値に従ってロウハンマコンディションを検出するプロセスの実施形態のフロー図である。サプライヤは、メモリデバイスを製造する（４０２）。このコンテキストにおけるメモリデバイスは、そのパッケージング（例えばメモリ「チップ」）における別個のメモリダイを参照する。製造されたメモリチップを受け取るサプライヤまたは別の当事者は、メモリデバイスに対するロウハンマ閾値を決定する（４０４）。この決定は、使用される処理の情報、及び、メモリデバイスの製造の間に存在する状態に基づいて決定すること、及び／または、デバイスについての１または複数のテストの実行を通じて決定することを含んでよい。
【００６２】
サプライヤまたは他の当事者は、メモリデバイス設定レジスタへロウハンマ閾値をプログラムしてよい（４０６）。
【００６３】
閾値は必ずしもメモリデバイス自体に配置されなくてもよい。一実施形態では、メモリデバイスは他のメモリデバイスを有するモジュールに配置される（４０８）。メモリモジュール内で使用されるとき、異なるメモリデバイスがその時々においてモジュールに配置されてよい。同様に、種々のメモリモジュールがホストコンピュータシステムのメモリバス上に、別個の複数の時間に配置されてよい。いずれの場合にも、複数のメモリデバイスの間、及び／または、複数のメモリモジュールの間で閾値のミスマッチが生じ得る。一実施形態では、ロウハンマコンディションは、デバイスごとの基準で、それらの閾値情報に基づいて監視される。一実施形態では、異なる閾値に基づいて種々のメモリモジュールが監視される。一実施形態では、システムにおけるすべてのメモリデバイスは単一の閾値に従って監視され、この閾値はこのとき、一般的に、メモリサブシステムにおける全てのデバイスの最低閾値に設定される。
【００６４】
従って、メモリサプライヤまたはメモリモジュールサプライヤのいずれかは、メモリモジュールにおける複数のデバイスに基づいて、メモリモジュールのロウハンマ閾値をプログラムすることができる（４１０）。一実施形態では、ホストシステムは（例えばメモリコントローラまたは他のロジックを介して）、メモリモジュールのロウハンマ閾値を検出してプログラムする。一実施形態では、メモリモジュールは、自身のロウハンマ閾値を自己発見する。
【００６５】
メモリデバイス及び／またはメモリモジュールを有するアクティブなシステムにおいて、検出ロジックは、メモリデバイスに関連する、或いは適用し得るロウハンマ閾値により定義されるようなロウハンマコンディションに関してメモリデバイスを監視する（４１２）。閾値は、デバイス自身、または、デバイスを一部とするメモリモジュールに格納される場合、さもなければ、それを監視する検出ロジックによって取得されて用いられる場合には、メモリデバイスに関連するか、或いは適用し得る。従って、検出ロジックは、メモリデバイスに対する閾値を取得し（４１４）、メモリデバイスの行に対するアクセス数が閾値を超過したかを判断する（４１６）。
【００６６】
閾値を超過しない場合（４１８  ＮＯ分岐）には、検出ロジックはロウハンマコンディションに関して監視を続ける（４１２）。閾値を超過した場合（４１８  ＹＥＳ分岐）には、検出ロジックはメモリデバイスのターゲットリフレッシュを引き起こすトリガを生成する（４２０）。このトリガは、本明細書に記載された任意の実施形態に従う。
【００６７】
図５は、メモリデバイスのロウハンマコンディションを監視するプロセスの実施形態のフロー図である。メモリデバイス及び分散検出ロジックは、許容レベルとして設定されたものを超えて、メモリの行に対するアクセスがいつビクティム行における破損の可能性を高めたかを示すロウハンマコンディションを監視する任意のメカニズムを使用することができる。いくつかのメカニズムは、全ての行に対するカウントを維持することの代わりに、全ての行の１つのサブセットのみに対するカウントを維持することを含むができる。いくつかのメカニズムは、複数のアクセスの順序付きの表を含み得る表を維持する。いくつかのメカニズムは、演算された最大ビクティムカウント（ＭＶＣ）に基づいてよい。１つの実装が以下のように説明される。
【００６８】
管理者は、ロウハンマ監視タイムウィンドウまたはタイムフレームと、ロウハンマコンディションを示すアクセス閾値とを用いてメモリサブシステムを設定することができる（５０２）。管理者は、タイムフレーム及び複数の閾値を示す複数の入力を受信するようシステムを事前に設定してよい。一実施形態では、設定することは、メモリサブシステムの複数のレジスタ値またはファームウェアの設定のセッティングの一部である。システムは、閾値のアクセス数を監視しながらタイムフレームでの監視を実行するよう構成された検出器または検出ロジックを含む。さらに、本明細書中に述べたように、特定の閾値は、メモリデバイス、または、メモリデバイスのグループ（例えばモジュール）に対して取得される。
【００６９】
従って、タイムフレーム及びアクセス数は、システム内で定義される。一実施形態では、タイムフレームは６４ミリ秒である。閾値を構成するアクセス数は、メモリコントローラが接続されたメモリデバイスのアーキテクチャに依存し、メモリサイズ及びメモリ密度を含む（例えば、最小処理機能サイズ）。ロウハンマイベントを示すアクセス数は、タイムウィンドウの間での１５０Ｋから５５０Ｋのアクセスの範囲内のいずれかであり得る。そのような情報は、メモリデバイス及び／またはメモリモジュールのメモリ位置（例えばレジスタ）に格納される。
【００７０】
メモリコントローラまたは検出器は、システム内で生じうるビクティム行の最大数を算出しうる（５０４）。後述の複数のオペレーションは、実装に応じて検出器またはメモリコントローラにより実行されるとみなされうる。説明を簡単にするために、以下の説明は、検出器によるオペレーションに言及するが、検出器及びメモリコントローラのいずれか、或いは両方によって実行され得ること、または、検出器がメモリコントローラの一部であり得ることは理解されるだろう。管理者は、代わりにビクティム行の最大数を算出してよい。この算出は、タイムフレーム内で閾値に等しい回数、アクセスされうる行の最大数がいくつであるかの決定に基づく。１つの簡単な例として、閾値を定義するアクセス数が２５０Ｋであり、タイムフレームが６４ｍｓであるシステムを考える。各アクセスが１０ｎｓのオーダーでどこかで生じる場合には、このときビクティム行の最大数は２６に近似する（６４ｍｓ／（２５０Ｋ＊１０ｎｓ）＝２５．６）。ビクティムの最大数は、ＭＶＣ（ｍａｘｉｍｕｍ  ｖｉｃｔｉｍ  ｃｏｕｎｔ）と称されうる。各行を個別に監視する単純な場合より、この数が小さい桁であることに気付くであろう。
【００７１】
一実施形態では、検出器は、ＭＶＣの値に基づいてエントリのアレイを形成する（５０６）。アレイは表またはログまたは他の構造であってよい。
【００７２】
一実施形態では、エントリの数は少なくともＭＶＣ＋１である。エントリの数はＭＶＣの倍数である。一実施形態では、表またはログのエントリのそれぞれは、ＣＡＭ（ｃｏｎｔｅｎｔ  ａｄｄｒｅｓｓａｂｌｅ  ｍｅｍｏｒｙ）によりアクセス可能な行アドレスと、アクセスカウント値を含む。ＣＡＭがアドレスの比較に基づいてアクセスを許可することは理解されるだろう。他の情報もまた、複数のエントリに含まれてよい。
【００７３】
一実施形態では、検出器は、タイムフレームの開始においてアレイを初期化する（５０８）。初期化は、多数の異なるオペレーションを含んでよい。一実施形態では、タイムフレームが開始すると、検出器はアレイの各エントリを初期化して無効にする（例えば、エントリにおける値の入力またはフラグのセッティング、または、アレイとは別個の複数の有効なエントリのビットマップの維持による）。一実施形態では、検出器は各エントリのカウント値をゼロにリセットする。
【００７４】
一実施形態では、検出器は、アクティベートコマンドの複数のアドレスフィールドにおける行を特定するアクティブ化によって、各行を監視し得る（例えばＣＡＭを用いる）（５１０）。一実施形態では、検出器は、カウンタ値の順序によってアレイをソートする（例えば、最高のものから最低のものへ、または最低のものから最高のものへ）。アレイのソートは、ソート（ｓｏｒｔ）、リンクリストまたは他のメカニズムによって達成されうる。
【００７５】
検出器により検出される行の新たなアクティブ化それぞれに対し（５１２）、検出器は、その行が既にアレイにあるかを判断し得る（５１４）。行がアレイにある場合（５１４  ＹＥＳ分岐）には、検出器は、そのエントリに対するカウントをインクリメントする（５１６）。エントリを有効であるようにもする追加的な条件があってもよい（従って、行がアレイにあり、かつエントリが有効である場合にインクリメントする）。行がまだアレイにない状況に対処する多くの方法があってよい（５１４  ＮＯ分岐）。一実施形態では、検出器は、アレイ内に利用可能な複数の空のエントリまたは複数の無効なエントリがあるかを判断する（５１８）。
【００７６】
アレイ内に利用可能なエントリがある場合（５１８  ＹＥＳ分岐）には、検出器は、アクティブ化が検出された行に関連する情報をエントリに入力する（５２０）。特定の実施態様に必要とされるように、検出器はまた、エントリを有効としてマークしてよい。検出器は、次にそのエントリのカウントをインクリメントする（５１６）。
【００７７】
利用可能なエントリがアレイにない場合（５１８  ＮＯ分岐）には、検出器は、最低アクセスカウント値を有するエントリを、アクティブ化が検出された行の行アドレスで置き換えてよい（５２２）。一実施形態では、エントリのアクセスカウントは、特には、リセットまたはゼロ化されない。むしろ、そのエントリに対するアドレス情報は、ちょうどアクティベートされた行に対して置き換えられる。メモリ内の特定の行が繰り返しアクセスされることはできるものの、繰り返されたアクセスが別のエントリへのアクセスと共にあちこちへ行ったり来たりし得ることは理解されるだろう。従って、アクセスカウントを維持しつつインクリメントすることにより、それは行に対するアクセス数よりもほぼ確実に多くなるものの、実際のアクセス数よりも小さくなることはないだろう。
【００７８】
従って、検出器は、前のアクセスカウント値または行カウントを維持し、それをインクリメントする（５１６）。インクリメントの最も単純な形態は行カウントを毎回１つずつ増やすことによって行われるが、インクリメントの他の形態が行われてよいことは理解されるだろう。インクリメント（５１６）の後に、検出器は、行カウントが最大カウントであるか、即ち、行が閾値に達したかを判断する（５２４）。一実施形態では、検出器は、行のアクティブ化を検出する度に閾値に達したかを調べるべく検査するが、他の複数の実装が可能である。特に、新たに追加された複数のエントリに対し、閾値に対するカウントを検査する必要はないかもしれない。
【００７９】
実装に関わらず、行が閾値であるかを検出器が判断するときに、検出器は、ロウハンマコンディションに対処するべく、その行に対するターゲットリフレッシュコマンドを発行してよい。行が閾値に達していない場合（５２４  ＮＯ分岐）には、検出器は監視を維持する（５１０）。行が閾値に達した場合（５２４  ＹＥＳ分岐）には、検出器はターゲットリフレッシュコマンドを引き起こすべく、メモリコントローラにその行のアドレス情報を示す（５２６）。一実施形態では、エントリが閾値に達したときに、検出器はまた、そのエントリの最小のカウント値を、そのアレイの全てのエントリの最小のカウント値にリセットする。改めて、そのような動作は、繰り返しアクセスされているが少なくとも最初には他の複数の行ほど頻繁にアクセスされていないエントリに対するカウント情報をアレイが損失することを防ぐ。検出器はまた、エントリの有効ビットをクリアしてよい。
【００８０】
本明細書で説明されるオペレーションが、最も頻繁なアクセス行を「浮き上がらせる（ｆｌｏａｔ  ｕｐ）」させる傾向があることは理解されるだろう。説明されるように実装された場合に、アレイまたはリストにおける全てのエントリの最小アクセスカウントよりも実際のアクセスカウントが大きくなる行が存在するような状況は決して生じないであろう。さらに、ターゲットリフレッシュを引き起こす行数がＭＶＣの値を超過し得ないという事実に起因して、フォールスアラームのリスクが制限される。
【００８１】
複数の実施形態が複数の図を具体的に参照して上述された。概して、システムの様々な変更が行われ得ることは理解されるだろう。一実施形態では、ロウハンマ検出ロジックはメモリデバイス自体にある。例えば、メモリデバイスは、メモリデバイスに入ってくるコマンド及びアドレス情報を処理するデバイス内に検出ロジックを含んでよい。例えば、ＲＤＩＭＭ（レジスタＤＩＭＭ）またはＬＲＤＩＭＭ（負荷軽減ＤＩＭＭ）上のＣ／Ａ（コマンド／アドレス）レジスタまたはバッファまたは他の類似デバイスである。一実施形態では、システムは、そのようなＣ／Ａデバイス、または他の分散したロジックを介して分散した監視または分散した追跡を行う。ロジックは、メモリの複数の部分への複数のアクセスを監視及び／または追跡する任意の方法、例えば、図５に関して後述される方法または任意の他の方法を使用することができる。
【００８２】
一実施形態では、検出ロジックはメモリデバイスの多数の論理部分にわたって分散してよい。従って、全ての検出ロジックがＣ／Ａデバイス内で実行されるとしても、それぞれ独立に種々の論理部分にわたって監視することができる場合には、本明細書の目的上、分散したロジックと見なされてよい。メモリデバイス内の検出ロジックは、ロウハンマイベントが検出されたときにメモリコントローラに警告する。一実施形態では、警告は、アラートピン（例えばアラート＃）上のパルス幅を介して引き起こされる。一実施形態では、メモリデバイスは、アラートピンのセッティングを行うことを介して警告を引き起こし、メモリコントローラがアラートピンをリセットすることを待つ。メモリコントローラはまた、何の警告が示されているかを判断すべく、警告に応じてメモリデバイスをポーリングしてよい。この方法において、多数の警告が同一のアラートピン上で生成されうる。従って、例えば、現在のＤＤＲ  ＤＲＡＭ設計において、ロウハンマイベントの兆候がピンのセッティングとして示されるか、或いは、ロウハンマイベントの兆候がピンを律動させてポーリングを待つ場合には、ホストまたはメモリコントローラは、Ｃ／Ａパリティエラーの兆候（パルス幅によってアサートされる）と、ロウハンマイベントの兆候とを区別し得る。
【００８３】
一実施形態では、メモリコントローラはロウハンマイベントを検出すべくメモリデバイスを設定する。例えば、メモリコントローラは、何回のアクセスがロウハンマイベントを引き起こすかに関して、レジスタ制御ワードで複数の閾値をプログラムしうる。一実施形態では、メモリコントローラは、ロウハンマコンディションを判断すべく、メモリデバイスに対してタイムウィンドウをプログラムする。例えば、いくつかのメモリサブシステムにおいて、リフレッシュウィンドウとは異なるタイムウィンドウが使用され得る。他の複数のサブシステムにおいて、リフレッシュウィンドウはプログラム可能である。所定のタイムウィンドウ内でのアクセス数の閾値に達した場合には、メモリデバイスは（例えばＣ／Ａレジスタデバイスを介して）、ホストに対し（例えばメモリコントローラに対し）警告信号を送信する。
【００８４】
メモリコントローラがメモリデバイスからロウハンマコンディションの兆候を受信したときには、メモリコントローラは、ロウハンマコンディションを直すべく、ビクティム行に対してターゲットリフレッシュをメモリデバイス内で引き起こす。メモリコントローラがターゲットリフレッシュを引き起こしうる方法には多くの代替例が存在する。一実施形態では、メモリコントローラはメモリデバイスに対してロウハンマリフレッシュコマンドを発行し、ロウハンマコンディションを引き起こしたアドレスを示す。メモリコントローラは、メモリデバイス内のＣ／Ａデバイスからアドレスを取得しうる（例えば制御ワードの読み取りを介して）。メモリコントローラは、ロウハンマコンディションを引き起こした行の正確なアドレスを特定し、どの行がビクティム（または物理的に隣接）であるかをメモリデバイスに解決させうる。代わりに、メモリコントローラは、具体的なビクティム行アドレスを特定しうる。メモリコントローラは、ロウハンマコンディションを引き起こした行の正確な位置の代わりに、メモリの領域を特定するアドレスを送信しうる。
【００８５】
一実施形態では、メモリコントローラはメモリデバイスがロウハンマコマンドを生成することを引き起こすトリガを発行する。例えば、メモリコントローラは、Ｃ／Ａデバイス内の制御ビットに書き込んでよく、逐次ロウハンマリフレッシュコマンドを生成してよい。そのようなトリガは、メモリコントローラの一部において多くの処理を必要としないであろうが、メモリデバイスによる多くの処理を必要とする。しかしながら、メモリデバイスがロウハンマイベントを検出した場合には、ロウハンマイベントを引き起こす行アドレスを持つはずであり、それ故、メモリデバイス及びメモリコントローラの間で往復してアドレスの交換をする必要なく、コマンドを発行し得る。代替的な実施形態において、メモリコントローラは、アドレス情報を含めることなくロウハンマリフレッシュコマンド（ターゲットリフレッシュコマンドとも称される）を発行する。メモリデバイスは、（例えばＣ／Ａデバイスを介して）アドレス情報を提供し、ターゲットリフレッシュを実行する複数のメモリリソースにコマンドを送ることができる。
【００８６】
Ｃ／Ａデバイスへの言及が非限定的であることは理解されるだろう。分散したロウハンマイベントの管理は、ＲＤＩＭＭサブシステムのＣ／Ａレジスタ、ＬＲＤＩＭＭサブシステムのＣ／Ａレジスタ、バッファオンボード（ＢｏＢ）実装のバッファ、３ＤＳ（３次元スタック）構成におけるロジックバッファデバイス、または、コマンド及びアドレス情報を扱う他のいくつかのデバイスによって実現され得る。
【００８７】
上述したように、メモリコントローラは、アドレス情報を含む、または含まないターゲットリフレッシュトリガを送信し得る。アドレス情報は、どの行がハンマになっているかを示すことができ、そのため、ビクティム行（またはターゲットリフレッシュコマンドのターゲット）を直に示さなくてよい。一般的なリフレッシュシナリオにおいて、メモリデバイス自体は、何がいつリフレッシュされることを必要とするかを追跡する。従って、メモリデバイス自体は、メモリデバイスによって用いられたメモリレイアウトに基づき、どの１つのビクティム行または複数のビクティム行がロウハンマイベントにより影響されるかを計算し得る。メモリデバイスは、リフレッシュする行をオープンし、次にクローズすることで、ビクティム行をリフレッシュする。
【００８８】
メモリデバイスにハンマロウのビクティム行をリフレッシュさせるべく、メモリコントローラがハンマロウのアドレスを示すことが、特定アドレスを識別するための特定数のビットを必要とすることは理解されるだろう。一実施形態では、メモリコントローラは特定アドレスを識別する。他の実施形態では、メモリコントローラは特定の行より大きい領域を識別する。従って、メモリコントローラは、選択された設定に応じて、特定のブロック、特定の行、または領域を識別することができる。まさに特定アドレスを識別するコストは、必要とされるビット数である。より一般的にアドレスの識別コストは、メモリデバイスがより大きな領域をリフレッシュする必要があるということであり、メモリデバイスがより長いリフレッシュ時間で、利用不可能になる。
【００８９】
一実施形態では、メモリコントローラはメモリデバイスにアドレス情報を送信することでアドレス情報を示す。一実施形態では、１または複数の追加ピンまたはラインは、メモリコントローラと、アドレス情報を識別するべく既存のコマンドにアドレス情報を埋め込むメモリデバイスとの間に追加されうる。従って、ターゲットリフレッシュコマンドは、修正された既存のコマンド、及び／または、１または複数の追加ピンまたはラインの使用と合わせた、修正された既存のコマンドでありうる。一実施形態では、ターゲットリフレッシュコマンドはコマンド及びアドレスを複数回（例えば３回）、送信することを含む。一実施形態では、アドレスは連続コマンドにおいて修正されてよい（例えば、２つの連続コマンドにおいてアドレス＋１を送信し、次に、アドレス−１を送信する）。複数の他の実施形態が可能である。一実施形態では、メモリコントローラは、メモリデバイスが１または複数のアクティブ化及びプレチャージコマンド（Ａｃｔｉｖａｔｅ  ａｎｄ  Ｐｒｅｃｈａｒｇｅ  ｃｏｍｍａｎｄｓ）のグループに分解するターゲットリフレッシュコマンドを送信する。他の複数のコマンドは、ターゲットリフレッシュの目的で倍加されうる。
【００９０】
６４ｍｓウィンドウ（例えばリフレッシュウィンドウ）内で行がアクセスされることのできる理論的な最大数は、現在のＤＲＡＭ（ダイナミックランダムアクセスメモリ）では、１．３５ミリオン回（６４ｍｓリフレッシュウィンドウが４７ｎｓのアクセス時間で割られる）である。ビクティム行におけるデータ破壊のリスクがない現実的な最大値はずっと低く、使用される処理技術に依存する。しかしながら、ロウハンマイベントの検出及びターゲットリフレッシュコマンドの送信により、データ破壊のリスクは、メモリの特定の行へのアクセスを制限することなく減少し得る。
【００９１】
メモリデバイスにおいて、物理的に隣接する複数の行は、しばしばメーカごとに論理的に異なってラベルされ得る。一般的に、メーカは、メモリの論理的に隣接する複数の行を物理アドレスのオフセットによってマッピングし、複数のオフセットは種々の別のメーカの間で異なり得る。メモリデバイス自体は、複数の物理メモリリソースへのアクセス要求をマッピングする方法を判断するよう構成される。概して、複数のメモリコントローラは、多くの異なるタイプのメモリデバイスと互換性があるよう設計されており、そのため、概して、具体的に何らかのメーカのデバイスに関して設計されてはいない。従って、複数のメモリコントローラは、慣例上、どの行が物理的に隣接するかを示すロジックまたは情報を有してはいない。分散検出ロジックを用いて、メモリデバイス自体は、ターゲットリフレッシュコマンドの生成に関する１または複数オペレーションだけではなく、ハンマロウ及びビクティム行の特定に関するいくつかのオペレーションを行うことができる。
【００９２】
図６は、ターゲットリフレッシュコマンドをサポートするコマンド真理表の実施形態である。コマンド真理表６００は、メモリデバイスの真理表の一例を表す。表６００に従って、ターゲットリフレッシュトリガの送信の１つの実施形態は、メモリコントローラがターゲットリフレッシュコマンドを発行することである（ロウハンマコマンドはコマンド６３０として特定される）。代替的な実施形態において、種々のメカニズムが、メモリデバイスによる、ターゲットリフレッシュの実行を引き起こすために用いられる。左側の列は、サポートされる機能を特定する。右側の複数の列は、特定の機能を指定する種々の信号の値を特定する。
【００９３】
特に、表６００には、説明の目的でコマンド６３０があり、これはロウハンマコマンドである。一実施形態では、メモリデバイスに対しＣ／Ａバス上にコマンド６３０をセッティングするより前に、メモリコントローラは、モードレジスタ（ＭＲ）の１ビットまたは複数ビットを介して、メモリデバイスをロウハンマモードに置く。一実施形態では、メモリコントローラは行アドレスを、バンクグループ及びバンクアドレスと共にメモリデバイスに提供する。メモリデバイスは、提供されたアドレスを用いて、このアドレスに隣接する物理的な行に対し、ターゲットリフレッシュを行う。リフレッシュコマンドが生じる期間を割り当てた後、メモリコントローラは次に、ＭＲビットをリセットすることにより、メモリデバイスをロウハンマモードから移行させ得る。従って、ＭＲビットがメモリコントローラによってセットされたときには、メモリデバイスはコマンド６３０をロウハンマコマンドであると理解するが、さもなければバンクアクティベートコマンドとして理解され得る。
【００９４】
一実施形態では、ロウハンマは、信号６１０の値ＡＣＴ  ｎを例外として、バンクアクティブ（ロウハンマの上のコマンド）と同一である。従って、一実施形態では、ロウハンマコマンドは、ＡＣＴ  ｎにより引き起こされる。ＡＣＴ  ｎは、以前のメモリ規格のものではないピンまたは信号である。ＡＣＴ  ｎの信号は、コマンドがロウハンマまたはバンクアクティブであるか否かを示し得る。負論理として示されているが、代わりに正論理であるよう構成されてもよい。両方のコマンドが、複数の行アドレスビットにより示されるように、アドレスを特定することができる
【００９５】
６２０としてラベルされた３つの列がＲＡＳ、ＣＡＳ及びＷＥ信号を含むことが観察されるだろう。しかしながら、これらのコマンドは、メモリデバイス自体により内部で制御され得る。従って、追加のアドレス情報（それぞれアドレスビットＡ１６、Ａ１５及びＡ１４）と共にこれらの信号を多重化することにより、ロウハンマコンディションのターゲットのアドレスをより具体的に特定するべく、より多くのアドレス情報が提供されることが可能となる。
【００９６】
ＡＣＴが設定されると（例えば列６２０）、メモリデバイスは、ＲＡＳ／ＣＡＳ／ＷＥを行アドレス情報として読み出す。ＡＣＴが設定されないと、メモリデバイスは、ＲＡＳ／ＣＡＳ／ＷＥを伝統的なメモリアクセスのエンコードとして読み出す。上述したように、アドレス情報は、ブロック、特定の行、または他のいくつかのサイズの領域について特定され得る。リフレッシュは、システムにより望まれる程度に具体的または広範囲であり得る。
【００９７】
信号ＡＣＴ  ｎの使用によりアクティベートコマンドは２倍であるとして示されているが、リフレッシュまたは他の任意のコマンドが使用され得る。代わりに、ターゲットリフレッシュのために完全に新しいコマンドが使用されてよい。説明したように、ターゲットリフレッシュコマンドは、アクティベートコマンドに埋め込まれていると言える。メモリデバイスは、ロウハンマコマンド６３０内のアドレスに基づいてビクティム行を特定する。
【００９８】
図７は、ロウハンマの監視が実行可能なコンピューティングシステムの実施形態のブロック図である。システム７００は、本明細書に記載された任意の実施形態に係る、コンピューティングデバイスを表し、ラップトップコンピュータ、デスクトップ型コンピュータ、サーバ、ゲームまたはエンターテイメント制御システム、スキャナ、コピー機、プリンタ、または他の電子デバイスであり得る。システム７００はプロセッサ７２０を含み、プロセッサ７２０は、システム７００のために処理、動作管理、及び命令の実行を提供する。プロセッサ７２０は、システム７００のために処理を提供するマイクロプロセッサ、中央処理ユニット（ＣＰＵ）、処理コア、または他の処理ハードウェアの任意のタイプを含んでよい。プロセッサ７２０は、システム７００のオペレーション全体を制御し、１または複数のプログラマブルな汎用または特定用途のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、プログラマブルコントローラ、特定用途向け集積回路（ＡＳＩＣ）、プログラム式論理デバイス（ＰＬＤ）など、またはそのようなデバイスの組み合わせである、または、を含んでよい。
【００９９】
メモリサブシステム７３０は、システム７００のメインメモリを表し、プロセッサ７２０により実行されるコード、またはルーチンの実行で使用されるデータ値のための一時ストレージを提供する。メモリサブシステム７３０は、リードオンリメモリ（ＲＯＭ）、フラッシュメモリ、１または複数の様々なランダムアクセスメモリ（ＲＡＭ）、他のメモリデバイス、またはそのようなデバイスの組み合わせ等の、１または複数のメモリデバイスを含んでよい。メモリサブシステム７３０は、とりわけ、システム７００における命令の実行のためのソフトウェアプラットフォームを提供するオペレーティングシステム（ＯＳ）７３６を格納して提供する。さらに、複数の他の命令７３８が格納されメモリサブシステム７３０から実行され、システム７００のロジック及び処理を提供する。ＯＳ７３６及び複数の命令７３８は、プロセッサ７２０により実行される。
【０１００】
メモリサブシステム７３０は、データ、命令、プログラムまたは他のアイテムを格納するメモリデバイス７３２を含む。一実施形態では、メモリサブシステムは、本明細書に記載された任意の実施形態に係るメモリコントローラであるメモリコントローラ７３４を含む。メモリコントローラ７３４は、ロウハンマコンディションに基づいてメモリデバイス７３２にターゲットリフレッシュコマンドを提供する。ロウハンマコンディションは、本明細書に記載された任意の実施形態に係るメモリデバイスに対して格納された閾値に基づいて検出され得る。ターゲットリフレッシュコマンドは、ターゲットリフレッシュをメモリデバイス７３２に行わせる。ターゲットリフレッシュは、オフサイクルのリフレッシュオペレーションであり、定期的にスケジューリングされたリフレッシュサイクルから外れており、リフレッシュする隣の領域とは異なり、必ずしも、メモリデバイスによって追跡される領域上ではないことを意味する。むしろ、リフレッシュされる領域は、ターゲットリフレッシュコマンドに関連付けられるアドレスに基づいて特定されるビクティム行または領域に基づく。メモリコントローラ７３４は、本明細書に記載された任意の実施形態に係る分散検出ロジックによる検出に応じて、メモリ７３２内でのターゲットリフレッシュを引き起こし得る。
【０１０１】
プロセッサ７２０及びメモリサブシステム７３０は、バス／バスシステム７１０に結合される。バス７１０は、適切な複数のブリッジ、アダプタ及び／またはコントローラにより接続された、任意の１または複数の別個の物理的なバス、通信ライン／インターフェース、及び／または、ポイントツーポイント接続を表す抽象概念である。故に、バス７１０は、例えば、１又は複数のシステムバス、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）バス、ハイパートランスポートまたはインダストリスダンダードアーキテクチャ（ＩＳＡ）バス、スモールコンピュータシステムインターフェース（ＳＣＳＩ）バス、ユニバーサルシリアルバス（ＵＳＢ）、または、Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ）規格１３９４バス（通常、「ファイヤワイヤ」と称される）を含んでよい。バス７１０の複数のバスはまた、ネットワークインターフェース７５０における複数のインターフェースに対応してよい。
【０１０２】
システム７００はまた、バス７１０に結合された１または複数の入出力Ｉ／Ｏインターフェース７４０、ネットワークインターフェース７５０、１または複数の内部大容量ストレージデバイス７６０、及び周辺インターフェース７７０を含む。Ｉ／Ｏインターフェース７４０は、ユーザがシステム７００と相互作用する１または複数のインターフェースコンポーネントを含んでよい（例えば、ビデオ、オーディオ及び／または英数字インターフェーシング）。ネットワークインターフェース７５０は、１または複数のネットワークを通じて複数のリモートデバイス（例えばサーバ、他のコンピューティングデバイス）と通信する機能をシステム７００に提供する。ネットワークインターフェース７５０は、イーサネット（登録商標）アダプタ、無線インターコネクションコンポーネント、ＵＳＢ（ユニバーサルシリアルバス）、または他の有線または無線規格ベースの、または独占所有権のあるインターフェースを含んでよい。
【０１０３】
ストレージ７６０は、１または複数の磁気、ソリッドステートまたは光ベースのディスク、またはそれらの組み合わせのように、大容量データを不揮発な態様で格納するための任意の従来の媒体である、または、を含んでよい。ストレージ７６０は、永続的な状態でコードまたは命令及びデータ７６２を保持する（すなわちシステム７００への電力の中断に関わらず値は保持される）。メモリ７３０はプロセッサ７２０に複数の命令を提供する実行または動作メモリ（ｅｘｅｃｕｔｉｎｇ  ｏｒ  ｏｐｅｒａｔｉｎｇ  ｍｅｍｏｒｙ）であるが、ストレージ７６０は概して「メモリ」と見なされ得る。ストレージ７６０は不揮発性であるが、メモリ７３０は揮発性メモリを含み得る（すなわちシステム７００への電力が中断すると、データの値または状態は不確定である）。
【０１０４】
周辺インターフェース７７０は、具体的に上述されていない任意のハードウェアインターフェースを含み得る。周辺機器は概して、システム７００に従属的に接続する複数のデバイスを参照する。従属的な接続は、システム７００は、オペレーションが動作し、ユーザが相互作用するソフトウェア及び／またはハードウェアプラットフォームを提供するものである。
【０１０５】
図８は、ロウハンマの監視が実行可能なモバイルデバイスの実施形態のブロック図である。デバイス８００は、コンピューティングタブレット、携帯電話またはスマートフォン、ワイヤレス可能な電子書籍リーダ、または他のモバイルデバイスなどのモバイルコンピューティングデバイスを表す。概して、デバイス８００において複数のコンポーネントのいくつかが示されており、そのようなデバイスの全てのコンポーネントが示されていないことは理解されるだろう。
【０１０６】
デバイス８００は、デバイス８００の主要な処理オペレーションを実行するプロセッサ８１０を含む。プロセッサ８１０は、マイクロプロセッサ、アプリケーションプロセッサ、マイクロコントローラ、プログラム式論理デバイス、または他の処理手段等の１または複数の物理的なデバイスを含み得る。一実施形態では、プロセッサ８１０は、プロセッサダイに加えて、光インターフェースコンポーネントを含む。従って、プロセッサダイ及びフォトニックコンポーネントが同一のパッケージ内に存在する。そのようなプロセッサパッケージは、本明細書に記載された任意の実施形態に係る光コネクタと光学的にインターフェースをとり得る。
【０１０７】
プロセッサ８１０により実行される処理オペレーションは、複数のアプリケーション及び／またはデバイス機能が実行されるオペレーティングプラットフォームまたはオペレーティングシステムの実行を含む。処理オペレーションは、人間のユーザまたは他のデバイスとのＩ／Ｏ（入出力）に関する複数のオペレーション、電力管理に関する複数のオペレーション、及び／または、デバイス８００と別のデバイスとの接続に関する複数のオペレーションを含む。処理オペレーションはまた、オーディオＩ／Ｏ、及び／または、ディスプレイＩ／Ｏに関する複数のオペレーションを含んでよい。
【０１０８】
一実施形態では、デバイス８００は、コンピューティングデバイスにオーディオ機能を提供することに関連する、ハードウェア（例えばオーディオハードウェア及び回路）及びソフトウェア（例えばドライバ、コーデック）の複数のコンポーネントを表すオーディオサブシステム８２０を含む。
【０１０９】
オーディオ機能は、マイク入力と同様に、スピーカ及び／またはヘッドフォンの出力を含み得る。そのような機能のための複数のデバイスは、デバイス８００に統合されるか、或いはデバイス８００に接続され得る。一実施形態では、ユーザは、プロセッサ８１０により受信され処理されるオーディオコマンドを提供することによりデバイス８００と相互作用する。
【０１１０】
ディスプレイサブシステム８３０は、ユーザがコンピューティングデバイスと情報をやりとりするための視覚的な及び／または触覚を有するディスプレイを提供するハードウェア（例えば複数のディスプレイデバイス）及びソフトウェア（例えば複数のドライバ）の複数のコンポーネントを表す。ディスプレイサブシステム８３０は、ユーザに対してディスプレイを提供するために用いられる特定のスクリーンまたはハードウェアデバイスを含むディスプレイインターフェース８３２を含む。一実施形態では、ディスプレイインターフェース８３２は、ディスプレイに関する少なくともいくつかの処理を実行するべく、プロセッサ８１０とは別個のロジックを含む。一実施形態では、ディスプレイサブシステム８３０は、ユーザに対して入力及び出力の両方を提供するタッチスクリーンデバイスを含む。
【０１１１】
Ｉ／Ｏコントローラ８４０は、ユーザとのインタラクションに関するハードウェアデバイス及びソフトウェアコンポーネントを表す。Ｉ／Ｏコントローラ８４０は、オーディオサブシステム８２０及び／またはディスプレイサブシステム８３０の一部であるハードウェアを管理すべく動作し得る。さらに、Ｉ／Ｏコントローラ８４０は、デバイス８００に接続される追加のデバイスに対する接続点を示し、この追加のデバイスを通じてユーザはシステムと相互作用しうる。例えば、デバイス８００に装着され得る複数のデバイスは、マイクデバイス、スピーカまたはステレオシステム、ビデオシステムまたは他のディスプレイデバイス、キーボードまたはキーパッドデバイス、または、カードリーダのように特定の用途を有した使用のための他のＩ／Ｏデバイス若しくは他のデバイスを含み得る。
【０１１２】
上述したように、Ｉ／Ｏコントローラ８４０は、オーディオサブシステム８２０及び／またはディスプレイサブシステム８３０と相互作用しうる。例えば、マイクまたは他のオーディオデバイスを通じた入力は、デバイス８００の１または複数のアプリケーションまたは機能に対して入力またはコマンドを提供し得る。
【０１１３】
さらに、オーディオ出力は、ディスプレイ出力の代わりに、またはディスプレイ出力に加えて提供され得る。他の例において、ディスプレイサブシステムがタッチスクリーンを含む場合には、ディスプレイデバイスはまた、Ｉ／Ｏコントローラ８４０によって少なくとも部分的に管理され得る入力デバイスとして動作する。Ｉ／Ｏコントローラ８４０により管理されるＩ／Ｏ機能を提供するべく、デバイス８００上には追加の複数のボタンまたは複数のスイッチが存在してもよい。
【０１１４】
一実施形態では、Ｉ／Ｏコントローラ８４０は、加速度計、カメラ、光センサまたは他の環境センサ、ジャイロスコープ、全地球測位システム（ＧＰＳ）、または、デバイス８００に含まれ得る他のハードウェアなどのデバイスを管理する。入力は、（騒音のフィルタリング、輝度検出のためのディスプレイ調整、カメラに対するフラッシュの適用、または他の機能などの）オペレーションに影響を与えるためのシステムへの環境の入力と同様に、直接的なユーザインタラクションの一部であり得る。
【０１１５】
一実施形態では、デバイス８００は、バッテリ電源の使用、バッテリの充電、及び、省電力化オペレーションに関する複数の機能を管理する電力管理８５０を含む。メモリサブシステム８６０は、デバイス８００内に情報を格納するためのメモリデバイス８６２を含む。メモリサブシステム８６０は、不揮発性（メモリデバイスへの電力が中断された場合に状態が変化しない）及び／または揮発性（メモリデバイスへの電力が中断された場合に状態が不確定である）のメモリデバイスを含み得る。
【０１１６】
メモリ８６０は、システム８００の複数のアプリケーションおよび複数の機能の実行に関するシステムデータ（長期または一時のいずれにせよ）と同様に、アプリケーションデータ、ユーザデータ、音楽、写真、文書、または他のデータを格納し得る。
【０１１７】
一実施形態では、メモリサブシステム８６０は、メモリコントローラ８６４を含む（メモリコントローラ８６４はまた、システム８００の制御の一部であるとみなすことができ、潜在的にプロセッサ８１０の一部であるとみなすことができる）。メモリコントローラ８６４は、メモリデバイス８６２のメモリの特定の行でのロウハンマコンディションに基づいてターゲットリフレッシュコマンドを発行する。メモリコントローラ８６４は、本明細書に記載された任意の実施形態に係るメモリデバイスに対して格納された閾値に基づいてロウハンマコンディションを検出し得る。メモリコントローラ８６４は、本明細書に記載された任意の実施形態に係る分散検出ロジックによる検出に応じて、メモリ８３２内でのターゲットリフレッシュを引き起こし得る。
【０１１８】
コネクティビティ８７０は、デバイス８００が外部の複数のデバイスと通信することを可能にすべく、ハードウェアデバイス（例えば、無線及び／または有線コネクタ及び通信ハードウェア）と、ソフトウェアコンポーネント（例えば、ドライバ、プロトコルスタック）を含む。デバイスは、ヘッドセット、プリンタまたは他のデバイス等の周辺機器だけではなく、他のコンピューティングデバイス、無線アクセスポイント、または基地局等の別個の複数のデバイスであってよい。
【０１１９】
コネクティビティ８７０は、多数の異なるタイプの接続性を含み得る。一般化するべく、デバイス８００は、セルラー接続８７２及び無線接続８７４を有して図示されている。概して、セルラー接続８７２は、複数の無線企業により提供されるセルラーネットワーク接続、例えば、ＧＳＭ（登録商標）（ｇｌｏｂａｌ  ｓｙｓｔｅｍ  ｆｏｒ  ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）またはバリエーションまたは派生物、ＣＤＭＡ（符号分割多元接続）またはバリエーションまたは派生物、ＴＤＭ（時分割多重）またはバリエーションまたは派生物、ＬＥＴ（ロングタームエボリューション‐「４Ｇ」とも称される）、または他のセルラーサービス規格を介して提供されるセルラーネットワーク接続を参照する。無線接続８７４は、セルラー方式ではない無線接続を指し、パーソナルエリアネットワーク（ブルートゥースなど）、ローカルエリアネットワーク（ＷｉＦｉなど）、及び／または広域ネットワーク（ＷｉＭａｘなど）、または他の無線通信を含み得る。無線通信は、非固体媒体を介した、変調された電磁放射の使用によるデータの転送を指す。有線通信は、固体通信媒体によって生じる。
【０１２０】
周辺接続８８０は、周辺接続を形成するソフトウェアコンポーネント（例えばドライバ、プロトコルスタック）だけでなく、ハードウェアインターフェース及びコネクタを含む。デバイス８００が、それに接続される周辺機器（「ｆｒｏｍ」８８４）を有することだけでなく、他のコンピューティングデバイスに対する周辺機器（「ｔｏ」８８２）であることの両方が可能であることは理解されるだろう。デバイス８００は、一般に、デバイス８００上のコンテンツの管理（例えばダウンロード、及び／またはアップロード、変更、同期）などの目的で、他のコンピューティングデバイスに接続するための「ドッキング」コネクタを有する。さらに、ドッキングコネクタは、デバイス８００が例えばオーディオビジュアルまたは他のシステムへのコンテンツの出力を制御することを可能にする特定の周辺機器にデバイス８００が接続されることを可能にし得る。
【０１２１】
独占所有権のあるドッキングコネクタまたは他の、独占所有権のある接続ハードウェアに加えて、デバイス８００は、一般的なまたは規格に準拠した複数のコネクタを介して周辺接続８８０を形成し得る。一般的な複数のタイプは、ユニバーサルシリアルバス（ＵＳＢ）コネクタ（多数の異なるハードウェアインターフェースの何れかを含み得る）、ＭｉｎｉＤｉｓｐｌａｙＰｏｒｔ（ＭＰＤ）を含むディスプレイポート、高解像度マルチメディアインターフェース（ＨＤＭＩ（登録商標））、ファイヤワイヤ、または他のタイプを含み得る。
【０１２２】
１つの態様において、メモリサブシステムは、複数のメモリセルの多数の物理的な行を有するメモリデバイスと、メモリデバイスに結合されたロウハンマの検出ロジックとを備え、検出ロジックは、メモリデバイスの設定情報を格納するレジスタから、メモリデバイスに対するアクセスレートの閾値を得て、閾値に基づいて、メモリデバイスの多数の物理的な行の１つへのアクセス数が閾値を超過するかを判断し、閾値をアクセス数が超過したことの検出に応じて、アクセス数が閾値を超過した行に物理的に隣接するビクティム行を標的とするリフレッシュをメモリデバイスが行うことを引き起こし、閾値は、タイムウィンドウ内でのメモリの特定の行に対するアクセス数であって、アクセスされる行に物理的に隣接する行でのデータ破壊のリスクを生じさせるアクセス数を特定する。
【０１２３】
一実施形態では、ロウハンマの検出ロジックは、メモリデバイスに結合されたメモリコントローラの検出ロジックを有する。一実施形態では、ロウハンマの検出ロジックは、メモリデバイスの分散検出ロジックを有する。一実施形態では、メモリデバイスに対する設定情報を格納するレジスタは、メモリモジュールの設定ストレージデバイスを有し、メモリデバイスはメモリモジュールの一部である。
【０１２４】
一実施形態では、メモリデバイスの設定情報を格納するレジスタは、メモリデバイスに設定レジスタを有する。一実施形態では、検出ロジックは、閾値を示す３ビットコードを得る。
【０１２５】
一実施形態では、メモリデバイスに対する閾値は、第１の閾値であり、メモリサブシステムにおける異なるメモリデバイスに対する第２の閾値とは異なる。一実施形態では、検出ロジックは、各メモリデバイスを、その異なる閾値に従って監視する。一実施形態では、検出ロジックは、さらに、どの閾値がより低いかを特定し、より低い閾値に従って複数のメモリデバイスを監視する。
【０１２６】
１つの態様では、電子デバイスは、複数のメモリセルの多数の物理的な行を有するメモリデバイス、及び、メモリデバイスに結合されたロウハンマの検出ロジック、を有するメモリサブシステムと、メモリデバイスからアクセスされたデータに基づいてユーザディスプレイを提供するよう構成されたタッチスクリーンディスプレイデバイスとを備え、検出ロジックは、メモリデバイスの設定情報を格納するレジスタからメモリデバイスに対するアクセスレートの閾値を得て、閾値に基づいて、メモリデバイスの多数の物理的な行の１つへのアクセス数が閾値を超過するかを判断し、閾値をアクセス数が超過したことの検出に応じて、アクセス数が閾値を超過した行に物理的に隣接するビクティム行を標的とするリフレッシュをメモリデバイスが行うことを引き起こし、閾値は、タイムウィンドウ内でのメモリの特定の行に対するアクセス数であって、アクセスされる行に物理的に隣接する行でのデータ破壊のリスクを生じさせるアクセス数を特定する。
【０１２７】
一実施形態では、メモリデバイスの設定情報を格納するレジスタは、メモリモジュールの設定ストレージデバイスを有し、メモリデバイスはメモリモジュールの一部である。一実施形態では、メモリデバイスの設定情報を格納するレジスタは、メモリデバイスに設定レジスタを有する。一実施形態では、メモリデバイスに対する閾値は、第１の閾値であり、メモリサブシステムにおける異なるメモリデバイスに対する第２の閾値とは異なる。一実施形態では、検出ロジックは、各メモリデバイスを、その異なる閾値に従って監視する。一実施形態では、検出ロジックは、さらに、どの閾値がより低いかを特定し、より低い閾値に従ってメモリデバイスを監視する。一実施形態では、検出ロジックは、閾値を示すコードを格納する設定レジスタのフィールドを得る。
【０１２８】
１つの態様では、方法は、メモリデバイスの設定情報を格納するレジスタから、メモリデバイスに対するアクセスレートの閾値を得る段階と、閾値に基づいて、メモリデバイスの多数の物理的な行の１つへのアクセス数が閾値を超過するかを判断する段階と、閾値をアクセス数が超過したことの検出に応じて、アクセス数が閾値を超過した行に物理的に隣接するビクティム行を標的とするリフレッシュをメモリデバイスが行うことを引き起こすトリガを生成する段階と、を含み、閾値は、タイムウィンドウ内でのメモリの特定の行に対するアクセス数であって、アクセスされる行に物理的に隣接する行でのデータ破壊のリスクを生じさせるアクセス数を特定する。
【０１２９】
一実施形態では、トリガを生成する段階は、メモリデバイスに対するターゲットリフレッシュコマンドをメモリコントローラが発行することを引き起こすべく、メモリデバイスの分散検出ロジックからメモリコントローラへ警告を送信する段階を含む。一実施形態では、アクセス数が閾値を超過するかを判断する段階は、さらに、タイムウィンドウにおけるメモリデバイスの複数の行への複数のアクセスを監視する段階と、複数の行の何れかに対するアクセス数が閾値を超過するかを判断する段階と、タイムウィンドウにおけるアクセス数が超過したと判断された行についてのアドレス情報を示す段階とを含む。一実施形態では、メモリデバイスに対する閾値は第１の閾値であり、メモリデバイスとメモリサブシステムを共有する異なるメモリデバイスに対する第２の閾値とは異なり、閾値に基づいて判断する段階は、さらに、第１及び第２の閾値の何れがより低いかを判断する段階と、より低いと判断された閾値に基づいて両方のメモリデバイスを監視する段階とを含む。
【０１３０】
本明細書で示すフロー図は、多様な処理動作のシーケンスの例を提示する。特定のシーケンスもしくは順序で示されるが、特段明記しない限り、動作の順序は変更することができる。したがって、示される実施形態は、単に一例として理解されるべきであり、処理は異なる順序で実行することができ、並列に実行してよい動作もある。さらに、多様な実施形態において、１または複数の動作を省略することができ、したがって、全ての動作が全実施形態で必要とされるのではない。その他の処理フローも可能である。
【０１３１】
本明細書において多様な動作もしくは機能を記載する程度において、それらは、ソフトウェアコード、命令、設定、及び／またはデータとして記載もしくは定義されることができる。コンテンツは、直接実行可能な（「オブジェクト」もしくは「実行可能」形式の）ソースコードまたは差分コード（「デルタ」もしくは「パッチ」コード）であることができる。本明細書に記載した実施形態のソフトウェアコンテンツは、コンテンツを格納した製品を介して、または通信インターフェースを操作し、通信インターフェース上でデータを送信する方法を介して、提供することができる。記載した機能もしくは動作を機械可読記憶媒体によって機械に実行させてよく、機械可読記憶媒体は、機械（たとえば、コンピューティング装置、電子システム等）によりアクセス可能な形態で情報を格納する、たとえば、記録可能／記録不可能媒体（たとえば、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置等）等の任意のメカニズムである。通信インターフェースは、ハードワイヤード、無線、光等の媒体へのインターフェースとなって別のデバイスと通信を行う、たとえば、メモリバスインターフェース、プロセッサバスインターフェース、インターネット接続、ディスクコントローラ等の任意のメカニズムである。通信インターフェースの設定は、設定パラメータを設けることにより、及び／または、ソフトウェアコンテンツを記述したデータ信号を発生するよう通信インターフェースに信号を送信することにより、行うことができる。通信インターフェースには、１または複数のコマンドにより、もしくは、通信インターフェースに送信される信号によりアクセスすることができる。
【０１３２】
本明細書に記載した多用なコンポーネントは、記載した動作もしくは機能を実行する手段であってよい。本明細書に記載した各コンポーネントは、ソフトウェア、ハードウェア、もしくはこれらの組み合わせである。コンポーネントは、ソフトウェアモジュール、ハードウェアモジュール、専用ハードウェア（たとえば、特定用途向けハードウェア、特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）等）、組み込みコントローラ、ハードワイヤード回路等として実装することができる。
【０１３３】
本明細書に記載した内容に加え、本発明の範囲から逸脱することなく、本発明について開示した実施形態および実施例に多様な変更を行ってよい。本明細書によれば、以下の各項目に記載の事項もまた開示される。
［項目１］
複数のメモリセルの多数の物理的な行を有するメモリデバイスと、
前記メモリデバイスに結合された検出ロジックと
を備え、
前記検出ロジックは、
前記メモリデバイスの設定情報を格納するレジスタから、前記メモリデバイスに対するアクセスレートの閾値を得て、
前記閾値に基づいて、前記メモリデバイスの前記多数の物理的な行の１つへのアクセス数が前記閾値を超過するかを判断し、
前記閾値をアクセス数が超過したこと検出に応じて、アクセス数が前記閾値を超過した前記行に物理的に隣接するビクティム行を標的とするリフレッシュを前記メモリデバイスが行うことを引き起こし、
前記閾値は、タイムウィンドウ内でのメモリの特定の行に対するアクセス数であって、アクセスされる前記行に物理的に隣接する行でのデータ破壊のリスクを生じさせるアクセス数を特定するメモリサブシステム。
［項目２］
前記検出ロジックは、前記メモリデバイスに結合されたメモリコントローラの検出ロジックを有する、項目１に記載のメモリサブシステム。
［項目３］
前記検出ロジックは、前記メモリデバイスの分散検出ロジックを有する、項目１に記載のメモリサブシステム。
［項目４］
前記メモリデバイスの設定情報を格納する前記レジスタは、メモリモジュールの設定ストレージデバイスを有し、前記メモリデバイスは前記メモリモジュールの一部である、項目１から３の何れか１項に記載のメモリサブシステム。
［項目５］
前記メモリデバイスの設定情報を格納する前記レジスタは、前記メモリデバイスに設定レジスタを有する、項目１から３の何れか１項に記載のメモリサブシステム。
［項目６］
前記検出ロジックは、前記閾値を示す３ビットコードを得る、項目１から５の何れか１項に記載のメモリサブシステム。
［項目７］
前記メモリデバイスに対する前記閾値は、第１の閾値であり、前記メモリサブシステムにおける異なるメモリデバイスに対する第２の閾値とは異なる、項目１から６の何れか１項に記載のメモリサブシステム。
［項目８］
前記検出ロジックは、各メモリデバイスを、その異なる閾値に従って監視する、項目７に記載のメモリサブシステム。
［項目９］
前記検出ロジックは、さらに、どの閾値がより低いかを特定し、より低い前記閾値に従って複数の前記メモリデバイスを監視する、項目７または８に記載のメモリサブシステム。
［項目１０］
複数のメモリセルの多数の物理的な行を有するメモリデバイス、及び、前記メモリデバイスに結合された検出ロジック、を有するメモリサブシステムと、
前記メモリデバイスからアクセスされたデータに基づいてユーザディスプレイを提供するタッチスクリーンディスプレイデバイスと
を備え、
前記検出ロジックは、
前記メモリデバイスの設定情報を格納するレジスタから前記メモリデバイスに対するアクセスレートの閾値を得て、
前記閾値に基づいて、前記メモリデバイスの前記多数の物理的な行の１つへのアクセス数が前記閾値を超過するかを判断し、
前記閾値をアクセス数が超過したこと検出に応じて、アクセス数が前記閾値を超過した前記行に物理的に隣接するビクティム行を標的とするリフレッシュを前記メモリデバイスが行うことを引き起こし、
前記閾値は、タイムウィンドウ内でのメモリの特定の行に対するアクセス数であって、アクセスされる前記行に物理的に隣接する行でのデータ破壊のリスクを生じさせるアクセス数を特定する電子デバイス。
［項目１１］
前記メモリデバイスの設定情報を格納する前記レジスタは、メモリモジュールの設定ストレージデバイスを有し、前記メモリデバイスは前記メモリモジュールの一部である、項目１０に記載の電子デバイス。
［項目１２］
前記メモリデバイスの設定情報を格納する前記レジスタは、前記メモリデバイスに設定レジスタを有する、項目１０に記載の電子デバイス。
［項目１３］
前記メモリデバイスに対する前記閾値は、第１の閾値であり、前記メモリサブシステムにおける異なるメモリデバイスに対する第２の閾値とは異なる、項目１０から１２の何れか１項に記載の電子デバイス。
［項目１４］
前記検出ロジックは、各メモリデバイスを、その異なる閾値に従って監視する、項目１３に記載の電子デバイス。
［項目１５］
前記検出ロジックは、さらに、どの閾値がより低いかを特定し、より低い前記閾値に従って前記メモリデバイスを監視する、項目１３または１４に記載の電子デバイス。
［項目１６］
前記検出ロジックは、前記閾値を示すコードを格納する設定レジスタのフィールドを得る、項目１０から１５の何れか１項に記載の電子デバイス。
［項目１７］
メモリデバイスの設定情報を格納するレジスタから、前記メモリデバイスに対するアクセスレートの閾値を得る段階と、
前記閾値に基づいて、前記メモリデバイスの多数の物理的な行の１つへのアクセス数が前記閾値を超過するかを判断する段階と、
前記閾値をアクセス数が超過したことの検出に応じて、アクセス数が前記閾値を超過した前記行に物理的に隣接するビクティム行を標的とするリフレッシュを前記メモリデバイスが行うことを引き起こすトリガを生成する段階と、
を含み、
前記閾値は、タイムウィンドウ内でのメモリの特定の行に対するアクセス数であって、アクセスされる前記行に物理的に隣接する行でのデータ破壊のリスクを生じさせるアクセス数を特定する方法。
［項目１８］
前記トリガを生成する前記段階は、前記メモリデバイスに対するターゲットリフレッシュコマンドをメモリコントローラが発行することを引き起こすべく、前記メモリコントローラの検出ロジックから警告を送信する段階を含む、項目１７に記載の方法。
［項目１９］
前記トリガを生成する前記段階は、前記メモリデバイスに対するターゲットリフレッシュコマンドをメモリコントローラが発行することを引き起こすべく、前記メモリデバイスの分散検出ロジックから前記メモリコントローラへ警告を送信する段階を含む、項目１７に記載の方法。
［項目２０］
前記レジスタから得る前記段階は、メモリモジュールの設定ストレージデバイスにアクセスする段階を含み、
前記メモリデバイスは前記メモリモジュールの一部である、項目１７から１９の何れか１項に記載の方法。
［項目２１］
前記レジスタから得る前記段階は、前記メモリデバイスの設定ストレージデバイスにアクセスする段階を含む、項目１７から１９の何れか１項に記載の方法。
［項目２２］
前記レジスタから前記閾値を得る前記段階は、前記閾値を示す３ビットコードにアクセスする段階を含む、項目１７から２１の何れか１項に記載の方法。
［項目２３］
アクセス数が前記閾値を超過するかを判断する前記段階は、さらに、
前記タイムウィンドウにおける前記メモリデバイスの複数の行への複数のアクセスを監視する段階と、
前記複数の行の何れかに対するアクセス数が前記閾値を超過するかを判断する段階と、
前記タイムウィンドウにおけるアクセス数が前記閾値を超過したと判断された行についてのアドレス情報を示す段階と
を含む、項目１７から２２の何れか１項に記載の方法。
［項目２４］
前記メモリデバイスに対する前記閾値は第１の閾値であり、前記メモリデバイスとメモリサブシステムを共有する異なるメモリデバイスに対する第２の閾値とは異なる、項目１７から２３の何れか１項に記載の方法。
［項目２５］
前記閾値に基づいて判断する前記段階は、さらに、前記第１及び第２の閾値の何れがより低いかを判断する段階と、より低いと判断された前記閾値に基づいて両方のメモリデバイスを監視する段階とを含む、項目２４に記載の方法。
［項目２６］
前記メモリデバイスは、それぞれ異なる閾値を有する多数のメモリデバイスの１つであり、
前記閾値に基づいてアクセス数が前記閾値を超過するかを判断する前記段階は、各メモリデバイスについて、その異なる閾値に従って別々に判断する段階を含む、項目２４または２５に記載の方法。
［項目２７］
メモリデバイスの設定情報を格納するレジスタから前記メモリデバイスに対するアクセスレートの閾値を取得する手段と、
前記閾値に基づいて、前記メモリデバイスの多数の物理的な行の１つへのアクセス数が前記閾値を超過するかを判断する手段と、
前記閾値をアクセス数が超過したことの検出に応じて、アクセス数が前記閾値を超過した前記行に対して物理的に隣接するビクティム行を標的とするリフレッシュを前記メモリデバイスが行うことを引き起こすトリガを生成する手段と
を備え、
前記閾値は、タイムウィンドウ内でのメモリの特定の行に対するアクセス数であって、アクセスされる前記行に物理的に隣接する行でのデータ破壊のリスクを生じさせるアクセス数を特定する装置。
［項目２８］
前記トリガを生成する前記手段は、前記メモリデバイスに対するターゲットリフレッシュコマンドをメモリコントローラが発行することを引き起こすべく、前記メモリコントローラの検出ロジックから警告を送信する手段を含む、項目２７に記載の装置。
［項目２９］
前記トリガを生成する前記手段は、前記メモリデバイスに対するターゲットリフレッシュコマンドをメモリコントローラが発行することを引き起こすべく、前記メモリデバイスの分散検出ロジックから前記メモリコントローラへ警告を送信する手段を含む、項目２７に記載の装置。
［項目３０］
前記レジスタから得る前記手段は、メモリモジュールの設定ストレージデバイスにアクセスする手段を含み、
前記メモリデバイスは前記メモリモジュールの一部である、項目２７から２９の何れか１項に記載の装置。
［項目３１］
前記レジスタから得る前記手段は、前記メモリデバイスの設定ストレージデバイスにアクセスする手段を含む、項目２７から２９の何れか１項に記載の装置。
［項目３２］
前記レジスタから前記閾値を得る前記手段は、前記閾値を示す３ビットコードにアクセスする手段を含む、項目２７から３１の何れか１項に記載の装置。
［項目３３］
アクセス数が前記閾値を超過するかを判断する前記手段は、さらに、
前記タイムウィンドウにおける前記メモリデバイスの複数の行への複数のアクセスを監視する手段と、
前記複数の行の何れかに対するアクセス数が前記閾値を超過するかを判断する手段と、
前記タイムウィンドウにおけるアクセス数が前記閾値を超過したと判断された行についてのアドレス情報を示す手段と
を含む、項目２７から３２の何れか１項に記載の装置。
［項目３４］
前記メモリデバイスに対する前記閾値は第１の閾値であり、前記メモリデバイスとメモリサブシステムを共有する異なるメモリデバイスに対する第２の閾値とは異なる、項目２７から３３の何れか１項に記載の装置。
［項目３５］
前記閾値に基づいて判断する前記手段は、さらに、前記第１及び第２の閾値の何れがより低いかを判断する手段と、より低いと判断された前記閾値に基づいて両方のメモリデバイスを監視する手段とを含む、項目３４に記載の装置。
［項目３６］
前記メモリデバイスは、それぞれ異なる閾値を有する多数のメモリデバイスの１つであり、
前記閾値に基づいてアクセス数が前記閾値を超過するかを判断する前記手段は、各メモリデバイスについて、その異なる閾値に従って別々に判断する手段を含む、項目３４または３５に記載の装置。
【０１３４】
したがって、本明細書における説明および例示は、限定的意図としてではなく、説明的意図として解釈されるべきである。本発明の範囲は、以下の特許請求の範囲を参照することによってだけ、評価されるべきである。
【図１Ａ】
0005987234.tif 000002
【図１Ｂ】
0005987234.tif 000003
【図２】
0005987234.tif 000004
【図３Ａ】
0005987234.tif 000005
【図３Ｂ】
0005987234.tif 000006
【図４】
0005987234.tif 000007
【図５】
0005987234.tif 000008
【図６】
0005987234.tif 000009
【図７】
0005987234.tif 000010
【図８】
0005987234.tif 000011