(57)【特許請求の範囲】
【請求項１】
エラー修正を扱うための方法であって、
ａ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持するステップと、
ｂ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出すステップと、
ｃ）消去カウントに基づいて、遷移条件および読み出しデータ中のエラーを修正するために使用されるエラー修正パラメータを識別するポリシーを確立して実行するステップと、
ｄ）関連する消去カウントにしたがって、
ｉ）遷移条件と、
ｉｉ）エラー修正試行リソースバジェットのうちの少なくとも１つを決定するステップと、
ｅ）エラー修正パラメータの第１のセットを使用して読み出しデータ中のエラーを修正する第１の試行を行うステップと、
ｆ）エラーを修正する第１の試行が失敗した場合、エラー修正パラメータに基づいて、エラー修正パラメータの第２のセットを使用して識別された異なるデコーダまたはデコーダの異なるデコーダモードに遷移することによって読み出しデータ中のエラーを修正する第２の試行を行うステップと、を含み、
前記第２の試行が、
ｉ）第１の試行による、エラーを修正せずに遷移条件が満たされる場合にトリガされるモード遷移条件のトリガと、
ｉｉ）第１の試行によるリソースバジェットの消耗のうちの少なくとも１つに依存し、
エラー修正パラメータの第２のセットは、エラー修正パラメータの第１のセットとは異なり、
前記第１および第２のセット用のエラー修正パラメータは、
（ｉ）複数のデコーダからデコーダを選択する選択パラメータと、
（ｉｉ）特定のデコーダのために複数のデコーダモードからデコーダモードを選択するデコーダモードパラメータのうちの少なくとも１つによって定義される方法。
【請求項２】
請求項１記載の方法において、
前記方法が、モード遷移条件を決定するステップをさらに含み、
第２の試行が、少なくとも第１の試行による決定されたモード遷移条件のトリガに依存する方法。
【請求項３】
請求項１記載の方法において、
前記方法が、リソースバジェットを決定するステップをさらに含み、
第２の試行が、少なくとも第１の試行によるリソースバジェットの消耗に依存する方法。
【請求項４】
請求項１記載の方法において、
少なくとも１つのエラー修正パラメータが、
ｉ）複数のデコーダからデコーダを選択する選択パラメータと、
ｉｉ）特定のデコーダのために複数のデコーダモードからデコーダモードを選択するデコーダモードパラメータと、
ｉｉｉ）読み出しデータのためのビット確率値と、
ｉｖ）ソフトビット数と、
ｖ）デコーダバス幅のうちの少なくとも１つによって定義される方法。
【請求項５】
請求項１記載の方法において、
遷移条件が、
ｉ）タイムアウト条件と、
ｉｉ）繰り返し条件数と、
ｉｉｉ）ＣＰＵサイクル条件数のうちの少なくとも１つによって定義される方法。
【請求項６】
請求項１記載の方法において、
エラー修正試行リソースバジェットが、
ｉ）時間バジェットと、
ｉｉ）ＣＰＵサイクルバジェットと、
ｉｉｉ）繰り返しバジェットのうちの少なくとも１つによって定義される方法。
【請求項７】
請求項１記載の方法において、
前記維持するステップ、読み出すステップ、決定するステップ、および１つ以上の試行のうちの少なくとも１つが、ソリッドステートメモリが存するストレージデバイスのデバイスコントローラによって実行される方法。
【請求項８】
エラー修正を扱うための方法であって、
ａ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持するステップと、
ｂ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出すステップと、
ｃ）消去カウントに基づいて、読み出しデータ中のエラーを修正するために使用されるエラー修正パラメータを識別するポリシーを確立して実行するステップと、
ｄ）関連する消去カウントにしたがって、
ｉ）データのために読み出されるソフトビット数を決定するステップと、
ｉｉ）デコーディングバス幅のサイズを選択するステップのうちの少なくとも１つを実行するステップと、
ｅ）ソフトビット数が決定された場合、データのためにソフトビット数を読み出すステップと、
ｆ）データ中のエラー修正を試行するステップであって、
ｉ）選択されたデコーディングバス幅のサイズと、
ｉｉ）読み出しソフトビットのうちの少なくとも１つを使用してエラー修正を試行するステップと、
ｇ）読み出しソフトビットを使用してエラーを修正する試行が失敗した場合、
ｉ）関連する消去カウントにしたがって、追加で読み出されるソフトビット数を決定するステップと、
ｉｉ）読み出された追加のソフトビット数を使用してデータ中のエラー修正を再度試行するステップと、
を含む方法。
【請求項９】
請求項８記載の方法において、
前記方法が、
データのために読み出されるソフトビット数を決定し、データのためにソフトビット数を読み出すステップと、
少なくとも読み出しソフトビットを使用してデータ中のエラー修正を試行するステップと、
をさらに含む方法。
【請求項１０】
請求項８記載の方法において、
前記方法が、
デコーディングバス幅のサイズを選択するステップと、
選択されたデコーディングバス幅のサイズを使用してデータ中のエラー修正を試行するステップと、
をさらに含む方法。
【請求項１１】
請求項８記載の方法において、
前記維持するステップ、１つ以上の読み出すステップ、決定するステップ、選択するステップ、および試行するステップのうちの少なくとも１つが、ソリッドステートメモリが存するストレージデバイスのデバイスコントローラによって実行される方法。
【請求項１２】
データストレージデバイスであって、
ａ）ソリッドステートメモリと、
ｂ）デバイスコントローラであって、
ｉ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持し、
ｉｉ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出し、
ｉｉｉ）消去カウントに基づいて、遷移条件および読み出しデータ中のエラーを修正するために使用されるエラー修正パラメータを識別するポリシーを確立して実行し、
ｉｖ）関連する消去カウントにしたがって、
Ａ）遷移条件と、
Ｂ）エラー修正試行リソースバジェットのうちの少なくとも１つを決定し、
ｖ）エラー修正パラメータの第１のセットを使用して読み出しデータ中のエラーを修正する第１の試行を行い、かつ
ｖｉ）エラーを修正する第１の試行が失敗した場合、エラー修正パラメータに基づいて、エラー修正パラメータの第２のセットを使用して識別された異なるデコーダまたはデコーダの異なるデコーダモードに遷移することによって読み出しデータ中のエラーを修正する第２の試行を行うように動作可能なデバイスコントローラと、を備え、
前記第２の試行が、
Ａ）第１の試行による、エラーを修正せずに遷移条件が満たされる場合にトリガされるモード遷移条件のトリガと、
Ｂ）第１の試行によるリソースバジェットの消耗のうちの少なくとも１つに依存し、
前記第１および第２のセット用のエラー修正パラメータは、
（ｉ）複数のデコーダからデコーダを選択する選択パラメータと、
（ｉｉ）特定のデコーダのために複数のデコーダモードからデコーダモードを選択するデコーダモードパラメータのうちの少なくとも１つによって定義されるデータストレージデバイス。
【請求項１３】
データストレージデバイスであって、
ａ）ソリッドステートメモリと、
ｂ）デバイスコントローラであって、
ｉ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持し、
ｉｉ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出し、
ｉｉｉ）消去カウントに基づいて、読み出しデータ中のエラーを修正するために使用されるエラー修正パラメータを識別するポリシーを確立して実行し、
ｉｖ）関連する消去カウントにしたがって、
Ａ）データのために読み出されるソフトビット数を決定することと、
Ｂ）デコーディングバス幅のサイズを選択することのうちの少なくとも１つを実行し、
ｖ）ソフトビット数が決定された場合、データのためにソフトビット数を読み出し、
ｖｉ）データ中のエラー修正を試行することであって、
Ａ）選択されたデコーディングバス幅のサイズと、
Ｂ）読み出しソフトビットのうちの少なくとも１つを使用してエラー修正を試行し、かつ
ｖｉｉ）読み出しソフトビットを使用してエラーを修正する試行が失敗した場合、
ｉ）関連する消去カウントにしたがって、追加で読み出されるソフトビット数を決定し、
ｉｉ）読み出された追加のソフトビット数を使用してデータ中のエラー修正を再度試行するように動作可能なデバイスコントローラと、
を備えるデータストレージデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フラッシュメモリなどのメモリから読み出されたデータにおけるエラーを修正する装置、方法、およびコンピュータ媒体に関する。
【０００２】
関連出願の相互参照
本願は、本願発明者により２００８年６月２４日に出願された米国仮特許出願第６１／０７５，０６５号（特許文献１）の利益を主張する。
【背景技術】
【０００３】
不揮発性メモリは、電源なしで記憶データを保持できるタイプのメモリである。種々の読み出し機能と書き込み機能と消去機能、アクセス時間、データ保持、データ持続サイクルなどを有するいくつかのタイプの不揮発性メモリがある。電気的に消去可能でプログラム可能なリードオンリーメモリ（ＥＥＰＲＯＭ）は、１バイトあたりのレベルで読み出し／書き込み操作を実行でき、個別にそれぞれの記憶域を読み書きできることを意味する。
フラッシュ形のフローティングゲートトランジスタまたはセルで構成されたフラッシュメモリは、機能性と性能においてＥＥＰＲＯＭメモリと同様の不揮発性メモリである。フラッシュメモリは、ある制限を伴って動作するものの比較的安価であることが利点である。フラッシュメモリは、最初に全体のメモリ部を消去せずに、前に書き込まれた位置に書き直すことができない。すなわち、フラッシュセルを再びプログラムすることができるようになる前に、フラッシュセルを消去しなければならない（例えば、「１」にプログラムする）。フラッシュメモリは通常消去ブロックと呼ばれるセルの比較的大きいグループを消去することができるだけである（例えば、多くの現在の市販のデバイスのサイズは１６ＫＢから２ＭＢであるが、より高い容量を有するデバイスが商業的に利用可能になる場合には、消去ブロックのサイズが将来増加すると予想されている）。
【０００４】
フラッシュメモリデバイスのエラー修正
フラッシュメモリおよび他のメモリ（例えば、磁気メモリ、光記憶、および揮発性メモリ）も同様に、これらのメモリに関する１つの顕著な特徴は、これらのメモリが「壊乱媒体」であるということであって、データがメモリから読み戻されるときに、１つ以上の情報ビットが「反転された」状態でメモリから読み出されてしまうかもしれないので、１つ以上のエラーがメモリに書き込まれているオリジナルのデータに時々取り込まれてしまうことである。
この現象を克服し、実際のアプリケーションでＮＡＮＤタイプのメモリを使用可能にするために、これらのメモリに関連してエラー修正コード（ＥＣＣ）を使用することは慣用技術である。
フラッシュメモリデバイスおよびフラッシュメモリ以外のソリッドステートメモリを含むストレージデバイスにおけるエラー修正を扱うための改善された技術と装置に対する継続した必要性が求められている。
【０００５】
デバイスアーキテクチャの議論
図１Ａ（従来技術）は、フラッシュメモリストレージデバイス２６０（従来技術）のブロック図である。フラッシュメモリストレージデバイスは、フラッシュメモリ２７０と、フラッシュメモリ２７０に対してデータを読み出し、かつデータを書き込むように動作可能なフラッシュコントローラ２８０とを含む。「プログラム」、「プログラミング」、「プログラムされた」、および「プログラム可能な」という用語は、フラッシュメモリでのデータの保存を指示するためにそれぞれ「書き込む」、「書き込み」、「書き込まれた」、および「書き込み可能な」という用語と共に本願明細書において互換性を持って使用される。
フラッシュメモリストレージデバイスの１つの実施形態が「周辺フラッシュストレージデバイス」である。周辺フラッシュストレージデバイスは、ＵＳＢフラッシュドライブ（ＵＦＤ）、ＰＣカード、デジタルカメラ、ならびに音楽プレーヤ、ハンドヘルドおよびパームトップコンピュータ、および携帯電話と共に使用される小形形状のストレージカードなどのフォームファクタにおけるコンピュータの技術分野において周知である。
【０００６】
図１Ｂ（従来技術）は、デバイス側インターフェイス２５０を介してデータを交換するためにホストデバイス３１０（例えば、ラップトップもしくはデスクトップもしくはハンドヘルドコンピュータ、デジタルカメラ、移動電話、音楽プレーヤ、およびテレビゲーム機）と「結合される」かまたは構成される周辺フラッシュメモリストレージデバイス２６０＊（＊は、フラッシュメモリストレージデバイスが周辺フラッシュストレージデバイスであることを示す）のブロック図である。周辺フラッシュメモリストレージデバイス２６０＊とホストデバイス３１０が、ホスト側インターフェイス３５０とデバイス側インターフェイス２５０（例えば、それぞれのＵＳＢまたはＳＤインターフェイス）を使用して通信リンク３００を通して互いにやり取りする。
周辺フラッシュメモリストレージデバイス２６０＊は、ホストデバイス３１０から分離されたデバイスとして図に示されているが、いくつかの実装形態では、フラッシュメモリストレージデバイス２６０＊は、ホストデバイス３１０のハウジングの中に配置され得ることが理解できるはずである。
１つの実施形態では、フラッシュメモリストレージデバイス２６０＊はホストデバイス３１０に対するデータの読み出しとデータの書き込みサービスを提供する。フラッシュメモリストレージデバイス２６０＊によって受け取られたホストデバイス３１０からのデータは、フラッシュコントローラ２８０によってフラッシュメモリ２７０に書き込まれる。さらに、フラッシュメモリストレージで受け取られた「データ読み出し」要求に対応して、フラッシュコントローラ２８０はフラッシュメモリ２７０からデータを読み出す。
「読み出し時」または読み出し後のいつでも読み出しデータ中のエラーを修正できる。エラー修正は、少なくとも一部をフラッシュコントローラ２８０により、少なくとも一部をホストデバイス３１０（例えば、ホスト側プロセッサ３２０によるＲＡＭ３３０内の実行可能コード３４０の実行またはいかなる他の方法）により行うことができ、またその他の位置やその他の方法でも行うことができる。
【０００７】
当業者であれば、「周辺フラッシュストレージデバイス」が唯一の類のフラッシュメモリストレージデバイスでないことが理解できるはずである。例えば、ある携帯電話、デスクトップ、ラップトップコンピュータ、ＰＤＡデバイスまたは他の電子装置もまた、フラッシュメモリとフラッシュコントローラを含むことができるが、必ずしもホストデバイスと結合するように構成され、かつ／またはホストデバイスのためのデータの読み出しサービスおよび／またはデータの書き込みサービスを提供することができるわけではない。
当業者であれば、図１Ａ〜１Ｂに示されているフラッシュメモリデバイスが、まさに１つの類の周辺不揮発性ストレージメモリデバイスであり、他のメモリデバイスが、光記憶や磁気抵抗のランダムアクセスメモリ（ＭＲＡＭ）のような他のタイプのソリッドステートメモリを含むことができることが理解できるはずである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】米国仮特許出願第６１／０７５，０６５号
【特許文献２】米国特許第６，２３０，２３３号
【特許文献３】米国特許第５，３４１，３３９号
【特許文献４】米国特許第５，５６８，４２３号
【特許文献５】米国特許第５，３８８，０８３号
【特許文献６】米国特許第５，７１２，８１９号
【特許文献７】米国特許第６，５７０，７９０号
【特許文献８】米国特許第５，９６３，４８０号
【特許文献９】米国特許第６，８３１，８６５号
【特許文献１０】米国特許第７，０２３，７３５号
【発明の概要】
【０００９】
様々な実施形態は前述したような項目および関連する項目を扱い、方法とシステムを含む実施形態が本願明細書で提供される。
エラー修正を扱うための方法が今回初めて開示され、この方法は、ａ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持することと、ｂ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出すことと、ｃ）メモリブロックの関連する消去カウントにしたがって、ｉ）第１のデコーダと第２のデコーダのうちの１つを選択することと、ｉｉ）第１のデコーダモードと第２のデコーダモードのうちの１つを選択することのうちの少なくとも１つを実行することと、ｄ）選択されたデコーダまたは選択されたモードだけを使用して読み出しデータ中のエラーを修正することと、を含む。
いくつかの実施形態では、ソリッドステートメモリは、フラッシュメモリである。
いくつかの実施形態では、維持すること、読み出すこと、実行すること、および修正することのうちの少なくとも１つが、ソリッドステートメモリが存するストレージデバイスのデバイスコントローラによって実行される。
いくつかの実施形態では、ストレージデバイスをデバイス間インターフェイスを介して動作可能にホストデバイスと結合し、前述した方法が、ｅ）エラー修正済みデータをストレージデバイスからホストデバイスに送信することをさらに含む。
【００１０】
エラー修正を扱うための方法が今回初めて開示され、この方法は、ａ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持することと、ｂ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出すことと、ｃ）関連する消去カウントにしたがって、ｉ）決定することであって、Ａ）より軽い重みデコーダを使用してエラー修正を試行するか、あるいはＢ）より軽い重みデコーダよりも重いより重い重みデコーダだけを使用してエラー修正を試行するかのいずれかを決定することと、ｉｉ）決定することであって、Ａ）より速いデコーダを使用してエラー修正を試行するか、あるいあＢ）より速いデコーダよりも遅いより遅いデコーダだけを使用してエラー修正を試行するかのいずれかを決定することと、ｉｉｉ）決定することであって、Ａ）特定のデコーダのより軽い重みモードを使用してエラー修正を試行するか、あるいはＢ）より軽い重みモードよりも重い、特定のデコーダのより重い重みモードだけを使用してエラー修正を試行するかのいずれかを決定することと、ｉｖ）決定することであって、Ａ）特定のデコーダのより速いモードを使用してエラー修正を試行するか、あるいはＢ）より速いモードよりも遅い、特定のデコーダのより遅いモードだけを使用してエラー修正を試行するかのいずれかを決定することのうちの少なくとも１つを実行することと、ｄ）決定することのうちの少なくとも１つにしたがって、読み出しデータ中のエラーを修正することと、を含む。
いくつかの実施形態では、維持すること、読み出すこと、１つ以上の決定すること、および修正することのうちの少なくとも１つが、ソリッドステートメモリが存するストレージデバイスのデバイスコントローラによって実行される。
【００１１】
エラー修正を扱うための方法が今回初めて開示され、この方法は、ａ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持することと、ｂ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出すことと、ｃ）関連する消去カウントにしたがって、ｉ）モード遷移条件と、ｉｉ）エラー修正試行リソースバジェットのうちの少なくとも１つを決定することと、ｄ）エラー修正パラメータの第１のセットを使用して読み出しデータ中のエラーを修正する第１の試行を行うことと、ｅ）エラーを修正する第１の試行が失敗した場合、エラー修正パラメータの第２のセットを使用して読み出しデータ中のエラーを修正する第２の試行を行うことであって、第２の試行が、ｉ）第１の試行によるモード遷移条件のトリガと、ｉｉ）第１の試行によるリソースバジェットの消耗のうちの少なくとも１つに依存する、第２の試行を行うことと、を含む。
【００１２】
いくつかの実施形態では、ｉ）前述した方法が、モード遷移条件を決定することを含み、ｉｉ）第２の試行が、少なくとも第１の試行によるモード遷移条件のトリガに依存する。
いくつかの実施形態では、ｉ）前述した方法が、リソースバジェットを決定することを含み、ｉｉ）第２の試行が、少なくとも第１の試行によるリソースバジェットの消耗に依存する。
いくつかの実施形態では、少なくとも１つのエラー修正パラメータが、ｉ）複数のデコーダからデコーダを選択する選択パラメータ（例えば、デコーダの「重み」または「デコーダの速度」を説明するパラメータ）と、ｉｉ）特定のデコーダのために複数のデコーダモードからデコーダモードを選択するデコーダモードパラメータ（例えば、デコーダの「重み」またはデコーダモードの「速度」を説明するパラメータ）と、ｉｉｉ）読み出しデータのためのビット確率値と、ｉｖ）ソフトビット数と、ｖ）デコーダバス幅と、からなるグループから選択される。
いくつかの実施形態では、モード遷移条件が、ｉ）タイムアウト条件と、ｉｉ）繰り返し条件数と、ｉｉｉ）ＣＰＵサイクル条件数と、からなるグループから選択される。
いくつかの実施形態では、エラー修正試行リソースバジェットが、ｉ）時間バジェットと、ｉｉ）ＣＰＵサイクルバジェットと、ｉｉｉ）繰り返しバジェットと、からなるグループから選択される。
いくつかの実施形態では、維持すること、読み出すこと、決定すること、および１つ以上の試行のうちの少なくとも１つが、ソリッドステートメモリが存するストレージデバイスのデバイスコントローラによって実行される。
【００１３】
エラー修正を扱うための方法が今回初めて開示され、この方法は、ａ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持することと、ｂ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出すことと、ｃ）関連する消去カウントにしたがって、ｉ）データのために読み出されるソフトビット数を決定することと、ｉｉ）デコーダバス幅のサイズを選択することのうちの少なくとも１つを実行することと、ｄ）ソフトビット数が決定された場合、データのためにソフトビット数を読み出すことと、ｅ）データ中のエラー修正を試行することであって、ｉ）選択されたデコーダバス幅のサイズと、ｉｉ）読み出しソフトビットのうちの少なくとも１つを使用してエラー修正を試行することと、を含む。
いくつかの実施形態では、ｉ）前述した方法が、データのために読み出されるソフトビット数を決定し、データのためにソフトビット数を読み出すことを含み、ｉｉ）試行することは、少なくとも読み出しソフトビットを使用してデータ中のエラー修正を試行することを含む。
いくつかの実施形態では、ｉ）前述した方法は、デコーダバス幅のサイズを選択することを含み、ｉｉ）試行することは、選択されたデコーダバス幅のサイズを使用してデータ中のエラー修正を試行することを含む。
いくつかの実施形態では、維持すること、１つ以上の読み出すこと、決定すること、選択すること、および試行することのうちの少なくとも１つが、ソリッドステートメモリが存するストレージデバイスのデバイスコントローラによって実行される。
【００１４】
データストレージデバイスが今回初めて開示され、このデータストレージデバイスは、ａ）ソリッドステートメモリと、ｂ）デバイスコントローラであって、ｉ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持し、ｉｉ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出し、ｉｉｉ）メモリブロックの関連する消去カウントにしたがって、Ａ）第１のデコーダと第２のデコーダのうちの１つを選択することと、Ｂ）第１のデコーダモードと第２のデコーダモードのうちの１つを選択することのうちの少なくとも１つを実行し、かつｉｖ）選択されたデコーダまたは選択されたモードだけを使用して読み出しデータ中のエラーを修正するように動作可能なデバイスコントローラと、を備える。
【００１５】
データストレージデバイスが今回初めて開示され、このデータストレージデバイスは、ａ）ソリッドステートメモリと、ｂ）コントローラであって、ｉ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持し、ｉｉ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出し、ｉｉｉ）関連する消去カウントにしたがって、Ａ）決定することであって、Ｉ）より軽い重みデコーダを使用してエラー修正を試行するか、あるいはＩＩ）より軽い重みデコーダよりも重いより重い重みデコーダだけを使用してエラー修正を試行するかのいずれかを決定することと、Ｂ）決定することであって、Ｉ）より速いデコーダを使用してエラー修正を試行するか、またはＩＩ）より速いデコーダよりも遅いより遅いデコーダだけを使用してエラー修正を試行するかのいずれかを決定することと、Ｃ）決定することであって、Ｉ）特定のデコーダのより軽い重みモードを使用してエラー修正を試行するか、あるいはＩＩ）より軽い重みモードよりも重い、特定のデコーダのより重い重みモードだけを使用してエラー修正を試行するかのいずれかを決定することと、Ｄ）決定することであって、Ｉ）特定のデコーダのより速いモードを使用してエラー修正を試行するか、あるいはＩＩ）より速いモードよりも遅い、特定のデコーダのより遅いモードだけを使用してエラー修正を試行するかのいずれかを決定することのうちの少なくとも１つを実行し、かつｉｖ）決定することのうちの少なくとも１つにしたがって、読み出しデータ中のエラーを修正するように動作可能なコントローラと、を備える。
【００１６】
データストレージデバイスが今回初めて開示され、このデータストレージデバイスは、ａ）ソリッドステートメモリと、ｂ）デバイスコントローラであって、ｉ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持し、ｉｉ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出し、ｉｉｉ）関連する消去カウントにしたがって、Ａ）モード遷移条件と、Ｂ）エラー修正試行リソースバジェットのうちの少なくとも１つを決定し、ｉｖ）エラー修正パラメータの第１のセットを使用して読み出しデータ中のエラーを修正する第１の試行を行い、かつｖ）エラーを修正する第１の試行が失敗した場合、エラー修正パラメータの第２のセットを使用して読み出しデータ中のエラーを修正する第２の試行を行い、第２の試行が、Ａ）第１の試行によるモード遷移条件のトリガと、Ｂ）第１の試行によるリソースバジェットの消耗のうちの少なくとも１つに依存するように動作可能なデバイスコントローラと、を備える。
【００１７】
データストレージデバイスが今回初めて開示され、このデータストレージデバイスは、ａ）ソリッドステートメモリと、ｂ）デバイスコントローラであって、ｉ）ソリッドステートメモリの少なくとも１つのブロックのための消去カウントを維持し、ｉｉ）関連する消去カウントを有するメモリブロックのうちの１つからデータを読み出し、ｉｉｉ）関連する消去カウントにしたがって、Ａ）データのために読み出されるソフトビット数を決定することと、Ｂ）デコーダバス幅のサイズを選択することのうちの少なくとも１つを実行し、ｉｖ）ソフトビット数が決定された場合、データのためにソフトビット数を読み出し、かつｖ）データ中のエラー修正を試行することであって、Ａ）選択されたデコーダバス幅のサイズと、Ｂ）読み出しソフトビットのうちの少なくとも１つを使用してエラー修正を試行するように動作可能なデバイスコントローラと、を備える。
【００１８】
ある実施形態に関係して前に説明した特徴は、以下の本願明細書においてそれら特徴と反対のことが示されないかぎり他の実施形態にも含まれ得ることに留意するべきである。
【図面の簡単な説明】
【００１９】
【図１Ａ】フラッシュメモリストレージデバイスのブロック図である。
【図１Ｂ】ホストデバイスに結合される周辺フラッシュメモリストレージデバイスのブロック図である。
【図２Ａ】１つ以上のメモリブロックの消去カウントにしたがって選択されたデコーダを使用してエラーを修正するルーチンのフローチャートである。
【図２Ｂ】１つ以上のメモリブロックの消去カウントにしたがって選択されたデコーダモードを使用してエラーを修正するルーチンのフローチャートである。
【図３Ａ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントに依存して、より軽い重みデコーダを使用してエラー修正の試行が行われる。
【図３Ｂ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントに依存して、より速いデコーダを使用してエラー修正の試行が行われる。
【図３Ｃ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントに依存して、より軽い重みデコーダモードを使用してエラー修正の試行が行われる。
【図３Ｄ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントに依存して、より速いデコーダモードを使用してエラー修正の試行が行われる。
【図４Ａ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントにしたがってモード遷移トリガ条件が決定される。
【図４Ｂ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントにしたがってエラー修正試行のためのリソースバジェットが決定される。
【図５Ａ】ルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントにしたがってエラー修正試行のために読み出されるソフトビット数が決定される。
【図５Ｂ】ルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントにしたがってエラー修正試行のために読み出されるソフトビット数が決定される。
【図６Ａ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントにしたがってデコーダバス幅が決定される。
【図６Ｂ】エラーを修正するルーチンのフローチャートであって、ここで１つ以上のメモリブロックのための消去カウントにしたがってデコーダバス幅が決定される。
【発明を実施するための形態】
【００２０】
図面を参照する例示の実施形態の本願における詳細な説明について言及することによって、添付の特許請求の範囲をより良く理解することができる。説明、実施形態、および図面が特許請求の範囲を限定するものとみなされてはならない。エラー修正を扱うための本願で開示された方法と装置のあらゆる特徴が、すべてのインプリメンテーションでも必要であるというわけではないことが理解されるべきである。また、本願での開示の全体にわたり、１つのステップが先に実行された別のものに依存することが文脈から明確でない場合であっても、明示もしくは説明したところのプロセスまたは方法にて、方法のステップが順不同または同時に実行され得ることが理解されるべきである。本願全体にわたり使用されているように、「・・かもしれない」 という用語は、義務的な感覚（すなわち、「・・すべきである」という意味）というよりはむしろ許容的な意味（すなわち、「・・可能性を持っている」という意味）で使用されている。
【００２１】
本願発明者は、データが読み出されるメモリブロックの消去カウントにしたがって、ソリッドステートメモリから読み出されたデータのためのＥＣＣデコーディングを行ういくつかの技法をここで開示する。
どんな特定の理論によっても拘束されることを願わず、ソリッドステートメモリ（例えば、フラッシュメモリ、ＭＲＡＭまたはいかなる他のタイプのソリッドステートメモリ）が複数回消去されるときには、このことが記憶媒体としてメモリの品質を下げ得ることに留意するべきである。そういうものとして、比較的「大きい」回数データが消去されたソリッドステートメモリ（またはその区分）は、比較的「小さい」回数データが消去されたソリッドステートメモリ（またはその区分）よりも、「より質が悪い」または「より信頼性が低い」かまたは「より壊乱的」な記憶媒体であるかもれない。
データが読み出される１つのブロックの消去カウントにしたがって、メモリから読み出されたデータのためのＥＣＣデコーディングを行ういくつかの技法をここで説明する。データが「高い消去カウント」を有するブロックから読み出される場合、メモリブロックが記憶媒体として比較的「より信頼性が低い」ことを示すことができる。そういうものとして、「より信頼性が低い」メモリブロックから読み戻されたデータは、比較的「大きい」エラー回数を含むかもれない。この場合、比較的「大きな数」のエラーを有するデータ中のエラー修正に適切な「悲観的」な技法が使用できる。逆に、データが「低い消去カウント」を有するブロックから読み出される場合、ブロックが記憶媒体として「より信頼性が高い」ことを示すことができ、比較的「小さい数」のエラーを有するデータ中のエラー修正に適切な「楽観的」な技法が使用できる。
【００２２】
第１の技法（図２Ａに関する議論を参照する）は、１つ以上のメモリブロックから読み出されたデータにおけるエラーを修正する場合に使用できる「より軽い重み」デコーダまたは「より重い重み」デコーダのいずれかの状況に関する。データが読み出されるメモリブロックの消去カウントが比較的「高い」（メモリブロックが比較的多くの「消耗」にさらされてきていることを示す）場合、データが読み出されたメモリブロックの「品質」が比較的「低い」傾向があることを示すかもしれない。この場合、このように「高い」消去カウントは、たとえより重い重みデコーダがより遅く、かつ／またはより多くのコンピュータリソース（例えば、ＣＰＵサイクル、電力、および／またはメモリリソース）を必要としても、エラーを修正する場合により「悲観的」な技法を使うことや、「より重い重み」デコーダを使うことが有利であり得ることを示すことができる。逆に、消去カウントが比較的「低い」場合、データが読み出されたメモリブロックの「品質」が比較的「高い」傾向にあり、「より軽い重み」デコーダを使うことが有利であり得ることを示すことができる。
【００２３】
第２の技法（図３Ａ〜３Ｄに関する議論を参照する）は、「試行錯誤」デコーディングルーチンに関する。「試行錯誤」デコーディングルーチンは、以下のように動作する。まず最初に、比較的「軽い」または「速い」デコーダ（または、デコーダモード）を使用してエラーを修正する試行が行われる。この試行が成功した場合には、比較的高速なデコーディングおよび／または比較的わずかなコンピュータリソースを消費するデコーディングを「享受」することが可能である。そうではなくて、この試行が失敗した場合には、より遅く、かつ／またはより多くのコンピュータリソースを消費するが、エラー修正をより失敗しない傾向にある、「より重い重み」（またはより遅い）デコーダ（またはデコーダモード）が、データ中のエラーを修正するのに使用される。
この第２の技法にしたがって、比較的「高い」消去カウントを有するブロックからデータが読み出される場合には、悲観的なアプローチが取られるべきであって、より軽い重みまたはより速い（が、信頼性が低い）デコーダ（またはモード）を使用してエラーをデコードするのを試行するステップを「悲観的に」スキップすることは有利であることがここで開示されている。この場合、この「悲観的な」アプローチは、どんな試行でもとにかく失敗しそうな軽い重みおよび／または速いデコーダを使用させられないところで、時間の節約および／またはコンピュータリソースを節約するのに役立つかもしれない。逆に、比較的「低い」消去カウントを有するブロックからデータが読み出されるならば、軽い重みおよび／または速いデコーダがより失敗しそうにないと想定されるかもしれない。このように、データがこの「より低い」消去カウントに対応しているブロックから読み出される場合、より軽い重みおよび／またはより速いデコーダが失敗するかもしれないという「リスクを取ること」に対して有利であるかもしれない。したがって、データがこの「より低い」消去カウントに対応しているブロックから読み出される場合、「より信頼性の高い」より重い重みおよび／またはより遅いデコーダ（またはモード）を試行する前に、より軽い重みおよび／またはより速いデコーダ（またはモード）を使用してデータをデコードするのを試行することは有利であるかもしれない。
【００２４】
また、第３の技法（例えば、図４Ａ〜４Ｂに関する議論を参照する）は、「試行錯誤」デコーディングルーチンに関する。この第３の技法に関連するいくつかの実施形態によると、最初に、「より小さい」エラー回数を扱うのに適当なより軽い重みデコーダおよび／またはより速いデコーダおよび／またはデコーダモード（またはデコーダ）を使用してエラーを修正するように試行がなされる。この第１の試行が失敗した場合（例えば、ある種の「タイムアウト」条件によりトリガされ、その結果として、この第１の試行が特定の時間内に成功しなかった場合）には、「より大きい」エラー回数を扱うのに適当なより重い重みおよび／またはより遅いデコーダおよび／またはモード（またはデコーダ）を使用してエラーを修正するように第２の試行がなされる。
【００２５】
「高い」消去カウントを有する１つのブロックのソリッドステートメモリからデータ（すなわち、そこでのエラーを修正することが望ましい）が読み出される場合、次により軽い重みまたはより速い（が、それほど信頼性が高くない）デコーダ（またはモード）を使用して単に「悲観的」な方法で、すなわち比較的「わずかな」リソースを投入することによって、エラーをデコードするように試行するステップを行うことが有利であり得ることがここで開示されている。このように１つの実施形態において、「より軽い重み」または「より速いデコーダ」を使用してエラーを修正する試行が比較的「高速に」（「小さいタイムアウト値」の中で）成功しなかった場合には、次に、（ｉ）この試行は比較的「高速に」断念され（すなわち、「失敗」であると見なされ）、（ｉｉ）より遅くかつ／またはより重い重み、および／または「より大きい」エラー回数の取り扱いにより適している別のデコーダおよび／またはデコーダモードを使用してエラーを修正する「新しい」試行がなされる。
【００２６】
逆に、修正するべきデータが「高い」消去カウントを有する１つのブロックのソリッドステートメモリから読み出される場合、より「楽観的」な方法で、より軽い重みまたはより速い（が、信頼性の低い）デコーダ（またはモード）を使用してエラーをデコードし、すなわち「より多く」のリソースを軽い重みおよび／またはより速いデコーダ（またはデコーダモード）に投入することによって、試行するステップを行うことが有利であるかもしれない。このように１つの実施形態では、「より軽い重み」または「より速いデコーダ」を使用することでエラーを修正する試行が比較的「高速に」成功しなかった場合でも、それにもかかわらず、まだこの試行が結局成功するという何らかの見込みがあると考えることができる。このように、この実施形態では、「より重い重み」および／または「より遅い」デコーダまたはモードでエラーを修正する試行を「進める」前に、「より重い重み」および／または「より遅い」デコーダまたはモードでエラーを修正する初期の試行に「機会が与えられ」、例えば、失敗として明示される前に、より長い期間（またはより多くのＣＰＵサイクルで）動作するのが容認される。
【００２７】
第４の技法（例えば、図５Ａ〜５Ｂに関する議論を参照する）は、エラー修正のために読み出されるソフトビット数を決定することに関する。その全体が本願明細書において参照により援用されている、米国特許出願第１１／６４２，７０８号および第１１／６５１，４８３号では、メモリにおけるエラー修正能力を改善するためのソフトビットの使用について議論されている。ソフトビットの読み出しには時間と電力というコストを招くので、ＥＣＣデコーダが全くソフトビットを読み出さずに（または「低い」数のソフトビットだけを読み出して）最初にデータをデコードするのを試行する多くの状況がある。それが失敗したのであれば、１つ以上のソフトビットを読み出すことができ、別のデコーディング試行を行うことができる。また、この第２の試行も失敗したのであれば、より多くのソフトビットが読み出され、別のデコーディング試行が行われる。デコーディングが成功するかあるいは有効なソフトビットの最大限度の数に達するまで、このプロセスを繰り返し続けることができる。
【００２８】
初期の試行用にいくつのソフトビットを読み出したり、使用したりするべきかの決定（例えば、図５ＡのステップＳ４１９を参照する）、および／または初期の試行が失敗した後に、いくつの追加のソフトビットを読み出すべきかの決定（例えば、図５ＢのステップＳ４７３を参照する）が、データが読み出されるメモリブロックの消去カウントにしたがって行われ得ることがここで開示されている。
このように、この消去カウントが比較的「高い」場合、「悲観的」なアプローチが取られるかもしれず、ゼロまたは「小さい」数のソフトビットを使用した繰り返しが、これらの繰り返しが成功しそうにない（すなわち、データが多くのエラーを含んでいそうであり、このようにより多くのソフトビットが「ノイジー」データ中でエラーを修正する必要がありそうである）という前提でスキップされるかもしれない（し、もしくは失敗した後に、相対的に「大きい」数のソフトビットが読み出されるかもしれない）。
【００２９】
逆に、この消去カウント（すなわち、データが読み出されるメモリのブロックの消去カウント）が比較的「低い」場合、「楽観的」なアプローチが取られるかもしれず、、データが比較的「高い」品質であるか、ソフトビットなし、あるいは比較的「小さい」数のソフトビットを使用することにおいて妥当な成功の機会が得られそうであるという前提の、ゼロまたは「小さい」数のソフトビットを使用することでエラー修正の試行を行うことは、この状況では有利であるかもしれない。
【００３０】
第５の技法（例えば、図６Ａを参照する）は、デコーダバスの幅に関する。データが比較的「高い」消去カウントを有するメモリブロックから読み出される場合、データが低品質であるかもしれず、エラーを修正することへの比較的「悲観的」なアプローチが好まれ得ることが開示されている。このように、エラーを修正するには、より大きいデコーダバスが、より遅くかつ／またはより多くのコンピュータリソースを必要とするかもしれないが、この状況ではより大きいデコーダバスを使用することが有利であるかもしれない。逆に、データが比較的「低い」消去カウントを有するメモリブロックから読み出される場合、データが高品質であって、より小さいデコーダバスでエラー修正を試行する、エラーを修正することへの比較的「楽観的」なアプローチが好ましいことを示している。
【００３１】
本願での開示全体を通じて、ある教示について「フラッシュメモリ」の表現で説明した場合には、この教示はフラッシュメモリ以外の他のソリッドステートメモリ（例えば、光記憶またはＭＲＡＭ）にも適切なものであり得ることを理解するべきである。
当業者であれば、ここで開示されたエラー修正の技法がメモリから読み出されたデータにおけるエラーを修正するためのいかなる他の技法とも組み合わせることができることが理解できるはずである。
図面についての説明の前に、フラッシュメモリにおけるＥＣＣ使用の概要を提示し、（次の２つのセクションで）様々な用語の定義を提供する。
【００３２】
フラッシュメモリデバイスのエラー修正
フラッシュメモリにおけるＥＣＣ使用の概要は、以下に提示され、以下のステップを含む。
（１）メモリにデータを書き込む前に、後で誤り検出・修正に使用される、追加の（すなわち、冗長な）ビットを計算するためにＥＣＣアルゴリズムがデータに適用される。これらの冗長ビットはしばしば「パリティビット」または「パリティ」と呼ばれる。ＥＣＣモジュールとパリティ出力へのそのモジュールによるデータ入力の組み合わせは符号語と呼ばれる。ＥＣＣモジュールへの入力データの各々異なる値は符号語の異なる処理結果をもたらす。
（２）符号語全体（すなわち、オリジナルのデータとパリティ）はフラッシュメモリに記録される。ＮＡＮＤタイプのフラッシュメモリの実際のサイズはオリジナルデータのサイズよりも大きく、またメモリはパリティにも対応するように設計されていることに留意するべきである。
（３）データがメモリから取り出されるときに、符号語全体が再度読み出され、また検出、修正することが可能な「ビットフリップ」（すなわち、エラー）データおよびパリティにＥＣＣアルゴルズムが適用される。
【００３３】
ＥＣＣインプリメンテーションがハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせで行われ得ることに留意するべきである。さらに、ＥＣＣをメモリデバイス中、メモリデバイスコントローラ中、またはホストコンピュータ中にインプリメントすることもできるし、あるいはシステムのこれらのコンポーネント中に「分散」することもできる。
共用のアルゴリズムは、リード−ソロモン、ＢＣＨ、ハミング、および多くの他のものを含む。それぞれのＥＣＣアルゴリズムは、２つの部分、すなわちデータビットを受信しパリティビットを生成する部分（もしくは符号語を生成するのと同等）と、符号語を受信し修正済みデータビットを生成する部分とで構成される。第１の部分が「エンコーダ」と呼ばれて、書き込み中に使用され、第二の部分が「デコーダ」と呼ばれて、読み出し中に使用される。ハードウェアまたはソフトウェアのいずれかでそれぞれの２つの部分をインプリメントすることもできるし、また一方の部分をハードウェアでインプリメントし、もう一方の部分をソフトウェアでインプリメントすることも可能である。また、それぞれの部分がハードウェアとソフトウェアとの組み合わせでインプリメントすることも可能である。
【００３４】
データビットを受信し対応する符号語を生成することを「エンコーディング」と呼ぶ。符号語を受信し修正済みデータビットを生成することを「デコーディング」と呼ぶ。
２種類のＥＣＣが実際にあることに留意するべきである。前に説明したＥＣＣの種類は「システム的」なＥＣＣと呼ばれ、データビットのアイデンティティは符号語で保持される。「非システム的」なＥＣＣでは、データビットは元のデータビットのアイデンティティが保持されない符号語に変換される。
フラッシュメモリシステムで使用されるべきＥＣＣアルゴリズムとして、ＢＣＨのようなアルゴリズムを選択することが唯一選択されたソリューションを定義するものではない。どのようなＥＣＣアルゴリズムであっても実際にはただ一つのアルゴリズムではなく、アルゴリズムのファミリー（一群）である。同じファミリーの中のアルゴリズムがその中でそれらが保護できるデータビットの量は異なる。２つのアルゴリズムが通常非常に類似し、かつ同じ原理で動作するものであったとしても、１００のデータビットを保護する必要があるアルゴリズムは、１万のデータビットを保護する必要があるアルゴリズムと同じではない。
【００３５】
ともに同じ数のデータビットを保護する同じファミリーの２つのアルゴリズムであっても必ず同じであるというわけではない。アルゴリズムはそのアルゴリズムが修正することができるデータのビットエラーの数において提供される信頼度のレベルまたは等価なもので異なるかもしれない。例えば、あるシステムでは、３ビットエラーまでのいかなる組み合わせに対しても１，０００のデータビットのチャンクの保護を必要とするかもしれない（が、４ビットエラー以上の出現に対しては不可能である）一方で、別のシステムでは、はるかに高い信頼性が望まれ、したがって、１０ビットエラーまでのいかなる組み合わせに対しても１，０００のデータビットのチャンクの保護を必要とする。通常、より多くのエラーに対する保護は、より多くのパリティビット（またはより長い符号語）の使用を必要とし、ＥＣＣスキームをより非「効率的」にし、ここで効率とは符号語のデータビットの数対符号語のビットの総数の比率によって測られる（システム的なＥＣＣにデータビットとパリティビットの両方を含む）。この計測は通常ＥＣＣコード化の「レート」と呼ばれる。
【００３６】
また、種々のＥＣＣアルゴリズムとインプリメンテーションとは他のアスペクトでも異なる。例えば、エンコーディングプロセスの速度、デコーディングプロセスの速度、エンコーディングプロセスの複雑さ、デコーディングプロセスの複雑さ、デコーダへの入力における許容エラーレート（記憶セルの品質にしたがって定義される）等々である。単に動作の速度に影響するだけではなく、ＥＣＣスキームのハードウエアインプリメンテーションの消費電力とシリコン面積にも影響するので、エンコーディングとデコーディングの複雑さは重要である。
【００３７】
このように、メモリシステムに対するＥＣＣソリューションの選択が複数の考慮事項間の複雑なトレードオフに関わることは明らかである。ＥＣＣの設計における当該技術分野での典型ないくつかの非限定的な経験則は以下のとおりである。
ａ．特定のメモリ信頼性において、出力信頼性が良ければ良いほど（修正可能なエラーの数がより大きいのと同等）コードのレートがより低くなる（システム的なＥＣＣにおいて、より多くのパリティビットが必要であることと同等）。
ｂ．特定のメモリ信頼性において、出力信頼性が良ければ良いほどデコーダはより複雑になる。
ｃ．特定のレベルの出力信頼性において、コードのレートが高ければ高いほどデコーダはより複雑になる。
ｄ．特定のレベルの出力信頼度において、コードのレートが高ければ高いほどデコーディングはより遅くなる。
【００３８】
ＥＣＣソリューションを設計する場合には、デコーダの入力におけるエラーレート（記憶セルの品質によって決定される）と所望の出力信頼性（アプリケーションの必要条件によって決定される）から通常始める。これらの数に基づいて、特定のＥＣＣファミリーを通常選択し、パリティビットの必要数を算出して、エンコーダとデコーダの速度と複雑さを見積もっている。
【００３９】
いくつかの場合、システムの設計者にとって最も重要な考慮すべき事柄はデコーディングの速度であり、このことがメモリからデータを読み出す速度に制限を設けるかもしれない。そのような場合には、設計者はジレンマに遭遇するかもしれない。出力信頼性の要求を満たすのに必要なＥＣＣ方式が、システムのスピード目標を満たさない、低速動作のかなり複雑なデコーダとなってしまうかもしれないからである。しかし、その一方で、高速なデコーディングをもたらす比較的簡単なＥＣＣ方式を選択することは、必要な出力信頼性レベルを提供しない。
【００４０】
定義
利便上、ここで記述される文脈の中で様々な用語が提示されている。本願における明細書の色々なところで、定義が明確または暗黙に提供されている範囲にわたり、そのような定義が関連する技術のその技術により定義された用語の語法とで一貫性を持つべきであることが理解されるはずである。さらに、そのような定義はそのような用語の語法と一致した可能な限り広い意味で解釈されるべきある。
ソリッドステートメモリのあるタイプは「壊乱媒体」である（例えば、フラッシュメモリ、光記憶、またはＭＲＡＭ）ので、時々１つ以上のエラーがメモリに書き込まれる「オリジナル」のデータに取り込まれてしまい、データ（すなわち、オリジナルデータの表示）がメモリから読み戻されるときに１情報ビット以上が「フリップ」されてしまう。
【００４１】
本発明の実施形態は、「メモリブロック」のための「消去カウント」に関連する。メモリ「ブロック」とは、消去のための最も小さい「チャンク」またはメモリ容量である。フラッシュメモリに関する１つの例では、ブロックは、いくつかのフラッシュセル、例えば、少なくとも数十、数百または数千、あるいはそれ以上のフラッシュセルを含む。他のタイプのメモリ、例えばＲＡＭでは、「ブロック」は単一のメモリセルまたはいくつかの複数のメモリセルであるかもしれない。
メモリの特定のブロックのための「消去カウント」は、ソリッドステートメモリのブロックが今までに何回消去されたかを示すカウンタである。メモリのブロックが消去されるときはいつでもこの消去カウントが増加されることになるかもしれない。前に言及したように、ブロックが比較的「大きい」消去カウントを有する場合には、ブロックがエラーを起こしがちな比較的「プア」な記憶媒体であることを示すかもしれない。
【００４２】
本発明の実施形態は、「フラッシュメモリの少なくとも１つのブロックのための消去カウントを維持する」ことに関する。消去カウントを、ホスト側および／またはデバイス側のいずれかの上で維持でき、揮発性（例えば、ＲＡＭまたはレジスタ）および／または不揮発性メモリ（例えば、フラッシュメモリ）のどのような組み合わせにも保存できる。１つの例では、消去カウントはコントローラのダイ上に保存される。別の例では、消去カウントはフラッシュダイの１つの中に保存される。消去カウントを、単一な場所および／または複数の場所に分散して保存することができる。１つの非限定的な例では、消去カウントはフラッシュブロックの中でウェアレベリングをインプリメントするのに使用されるデータ構造に保存することができる。
【００４３】
いくつかの非限定的な例（しかし、すべての実施形態ではない）では、ソリッドステートメモリの書き込み時はいつでも、最初に書き込みプロセスの一部としてソリッドステートメモリを消去しなければならない。そのようなシステムでは、「消去カウント」は特定のブロックに書き込まれた回数を少なくとも部分的に表現できる。
その全体が本願明細書において参照により援用されている、Lofgren らによる米国特許第６，２３０，２３３号（特許文献２）、Wells による米国特許第５，３４１，３３９号（特許文献３）、Jou らによる米国特許第５，５６８，４２３号（特許文献４）、Assar らによる米国特許第５，３８８，０８３号（特許文献５）、Harariによる米国特許第５，７１２，８１９号（特許文献６）、Harariによる米国特許第６，５７０，７９０号（特許文献７）、Harariによる米国特許第５，９６３，４８０号（特許文献８）、Chang らによる米国特許第６，８３１，８６５号（特許文献９）に開示された技法を含むが、これらに限定されないどのような技法も消去カウントを維持するために使用できる。
【００４４】
メモリから読み戻されたデータからオリジナルのエラーのないデータを復元するプロセスが「エラー修正」である。「エラー修正」という用語を複数形で使用しているが、「エラー修正」がただ一つのエラーをも修正することを示すことを理解するべきである。また、いくつかの実施形態では、エラー「修正」がエラー修正の１つ以上の試行の失敗を含み得ることも理解されるべきである。
前に言及したように、エラーを修正するために「デコーダ」を使用でき、オリジナルのデータを符号語の表示から復元するためにも使用できる。いくつかの実施形態では、「より軽い重み」デコーダと「より重い重み」デコーダを含む、複数のデコーダを伴っている。
用語「より重い重み」と「より軽い重み」は、２つのデコーダおよび／または単一のデコーダの２つのモードを比較するのに使用される。「より重い重み」デコーダ（単一のデコーダのより重い重みモード）は、（ｉ）「より軽い重み」対照物（デコーダ）より多くの電流を消費し、かつ／または（ｉｉ）「より軽い重み」対照物より多くのメモリ（デコーダ自体のコンピュータ実行可能コードのためのメモリおよび／またはエラー修正時の計算の「中間結果」を保存するためのメモリのいずれか）を必要とし、かつ／または（ｉｉｉ）「より軽い重み」対照物より多くのコンピュータによる動作を必要とする。
【００４５】
いくつかの実施形態が、データが読み出されるメモリブロックの消去カウントにしたがって、エラー修正時に読み出されかつ／または使用される「ソフトビット」数を決定することに関する。「ソフトビット」は見積りの信頼性尺度に結合されたビット値の見積りである。多くの場合、同じ数がビット値の見積りと信頼性尺度の両方に役立つ。例えば、対数尤度比（ＬＬＲ：log-likelihood-ratio）のサインはＬＬＲによって表されたビット値の見積りであり、またＬＬＲの大きさはその見積りの信頼性の基準である。
【００４６】
いくつかの実施形態では、「ソフトビット」はデータがセルの中に書き込まれた分解能よりも「より高い分解能」を使用することでメモリから読み出すことによって、計算したりかつ／または決定したりすることができる。「より高い分解能」を使用して読み出された追加のビットはデータのビット値のあらゆる見積りの「信頼性」のある種の指標を与えることができる。１つの例では、電圧バンドの境界を画定する異なった「基準電力値」を使用してメモリにデータを書き込み、また電圧バンドまたは「断片的な基準電力値」に属する基準電力値を使用してデータを読み戻すことによりソフトビットを生成し得る。当業者は、例えばその全体が本願明細書において参照により援用されている、Ban の米国特許第７，０２３，７３５号（特許文献１０）に言及している。１つ以上のソフトビットにしたがってデータが修正される場合には、エラー修正ルーチンを改善するのに役立つかもしれない。しかし、ソフトビットを決定することに関連した時間および／またはコンピュータリソースというコストが存在する。
【００４７】
事前の議論：消去カウントの維持とソリッドステートメモリからのデータ読み出し（図２Ａ〜２Ｂ、３Ａ〜３Ｄ、４Ａ〜４Ｂ、５Ａ〜５Ｂ、６Ａ〜６ＤのステップＳ４１１とＳ４２３の議論）
ステップＳ４１１では、消去カウントは少なくとも１つのメモリブロックのために維持される。前に言及したように、どのような場所および／またはどのような方法でも消去カウントを維持できる。１つの非限定的な例では、消去カウントはフラッシュコントローラ２８０によって維持される。１つの非限定的な例では、消去カウントはデータ構造内に維持される（例えば、不揮発性メモリに保存される。）例えば、データ構造はウェアレベリングの目的にも使用される。ステップＳ４２３では、データはメモリブロックの１つ以上から読み戻される。データが読み出される１つ以上のメモリブロックの消去カウントを、例えば、適切なデータ構造における「ルックアップ」に作用することによって決定できる。
【００４８】
図２Ａ〜２Ｂ、３Ａ〜３Ｄの議論
以下の特性を有する２つのデコーダ（または２つの異なったモードで動作可能な１つのデコーダ）を検討する。
ａ．第１のデコーダ（またはデコーダモード）は、より速いおよび／または「より軽い重み」のものであるが、一方では、デコーディングプロセスの結果を生成するのを成功するように保証されてはいない。
ｂ．第２のデコーダ（またはデコーダモード）は、より遅いおよび／または「より重い重み」のものであるが、いつもデコーディングプロセスの正しい結果を生成するように保証される（または少なくともデコーディングプロセスの正しい結果をより生成しそうである）。
通常、データのエラー数が高ければ高いほど、最初のデコーダはより頻繁に失敗する。残念ながら、メモリからデータを読み戻すときに、読み戻したデータ中にいくつのエラーがあるのかはいつも先験的に知られているというわけではない。このように、「より重い重み」デコーダ（または単一のデコーダのより重い重みモード）が必要であるかどうか、あるいは「より軽い重み」デコーダで十分であるかどうかがいつも知られているというわけではない。
【００４９】
本願発明者は、データが読み出されるメモリブロックの消去カウント数が比較的「低い」場合には、読み戻しているデータが良い「品質」でありそうなことを示し、またステップＳ６１５またはＳ６２５におけるデータの読み出し中のエラーを修正するための比較的「楽観的」な技法が選択され得ることをここで開示する。このように、この場合には、「より軽い重み」デコーダ（または単一のデコーダのより軽い重みモード）を使用してエラーを修正する「危険を冒す」ことは有利であるかもしれない。そうでなければ、エラーを修正するのは単一のデコーダの「より重い重み」デコーダまたはより重い重みモードを使用することが望ましいかもしれない。
【００５０】
図２Ａをここで参照する。ステップＳ６１５では、デコーダはデータが読み出されるブロックの消去カウントにしたがって複数の候補デコーダから選択される。
ステップＳ６１９では、選択されたデコーダのみを使用し、選択されていない「排除された」デコーダを使用せずに、エラーは修正される。
【００５１】
図２Ｂをここで参照する。ステップＳ６２５では、特定のデコーダのモードはデータが読み出されるブロックの消去カウントにしたがって複数の候補デコーダモードから選択される。
ステップＳ６２９では、選択されたデコーダモードのみを使用し、選択されていない「排除された」デコーダモードを使用せずに、エラーは修正される。
【００５２】
図３Ａをここで参照する。
ステップＳ６５１では、データが読み出されるブロックの消去カウントにしたがってより軽い重みデコーダ（すなわち、複数の候補デコーダ内のデコーダ）を使用してエラー修正の試行を行うかどうかの決定が行われる。
データが読み出されるソリッドステートメモリのブロックの消去カウントが比較的「低い」場合、読み戻しているデータが良い「品質」でありそうなことを示し、比較的「楽観的」なエラー修正ストラテジーを採用できる。このように、このシナリオでは、ステップＳ６５５でより軽い重みデコーダを使用してエラー修正の試行が行われる。より軽い重みデコーダが成功した場合（ステップＳ６５９を参照する）には、より重い重みデコーダを使用してエラー修正の試行を行う必要はない（ステップＳ６６７を参照する）。より軽い重みデコーダがエラー修正に失敗したのであれば、次により重い重みデコーダを使用してエラー修正の試行がＳ６６３で行われる。
さらに、ステップＳ６５１を参照すると、データが読み出されるブロックの消去カウントが比較的「高い」場合、読み戻しているデータが「プア」な品質でありそうであり、比較的「悲観的」なエラー修正ストラテジーを採用できることを示していることを言及している。このシナリオでは、ステップＳ６６５をスキップして、より軽い重みデコーダよりもむしろより重い重みデコーダを使用してエラー修正の試行を行うこと（ステップＳ６６３で）が可能である。
【００５３】
図３Ｂをここで参照する。
ステップＳ８５１では、消去カウントにしたがって、より速いデコーダ（すなわち、複数の候補デコーダ内のデコーダ）を使用してエラー修正の試行を行うかどうかを決定する。
消去カウントが「低く」、比較的「楽観的」なエラー修正ストラテジーが採用される場合には、ステップＳ８５５でより速いデコーダを使用してエラー修正の試行を行うことができる。より速いデコーダが成功した場合（ステップＳ８５９を参照する）には、より遅いデコーダを使用してエラー修正の試行を行う必要はない（ステップＳ８６７を参照する）。より速いデコーダがエラー修正に失敗したのであれば、次により遅いデコーダを使用してエラー修正の試行がＳ８６３で行われる。
さらに、ステップＳ８５１を参照すると、消去カウントが「高く」、比較的「悲観的」なエラー修正ストラテジーが採用される場合、ステップＳ８６５をスキップして、より速いデコーダよりもむしろより遅いデコーダを使用してエラー修正の試行を（ステップＳ８６３で）行うことが可能であることを言及している。
【００５４】
図３Ｃをここで参照する。
ステップＳ６７１では、ブロックの消去カウントにしたがって、より軽い重みモード（すなわち、特定のデコーダの複数の候補デコーダモード内のデコーダ）を使用してエラー修正の試行を行うかどうかを決定する。
消去カウントが「低く」、比較的「楽観的」なエラー修正ストラテジーが採用される場合には、ステップＳ６７５で、より軽い重みモードを使用してエラー修正の試行を行うことができる。より軽い重みモードが成功した場合（ステップＳ６７９を参照する）には、より重い重みモードを使用してエラー修正の試行を行う必要はない（ステップＳ６８７を参照する）。より軽い重みモードがエラー修正に失敗したのであれば、次により重い重みモードを使用してエラー修正の試行がＳ６８３で行われる。
さらに、ステップＳ６７１を参照すると、消去カウントが「高く」、比較的「悲観的」なエラー修正ストラテジーが採用される場合には、ステップＳ６７５をスキップして、より軽い重みモードよりもむしろより重い重みモードを使用してエラー修正の試行を（ステップＳ６８３で）行うことが可能であることを言及している。
【００５５】
図３Ｄをここで参照する。
ステップＳ８７１では、メモリブロックの消去カウントの結果にしたがって、より速いデコーダモード（すなわち、複数の候補デコーダモード内のデコーダ）を使用してエラー修正の試行を行うかどうかを決定する。消去カウントが「低く」、比較的「楽観的」なエラー修正ストラテジーが採用される場合には、ステップＳ８７５で、より速いデコーダモードを使用してエラー修正の試行を行うことができる。より速いデコーダモードが成功した場合（ステップＳ８７９を参照する）には、より遅いデコーダモードを使用してエラー修正の試行を行う必要はない（ステップＳ８８７を参照する）。より速いデコーダモードがエラー修正に失敗したのであれば、より遅いデコーダモードを使用してエラー修正の試行がＳ８８３で行われる。
さらに、ステップＳ８７１を参照すると、消去カウントが「高く」、比較的「悲観的」なエラー修正ストラテジーが採用される場合には、ステップＳ８６５をスキップして、より速いデコーダモードよりもむしろより遅いデコーダモードを使用してエラー修正の試行を（ステップＳ８６３で）行うことが望ましいかもしれないことを言及している。
【００５６】
図４Ａ〜４Ｂの議論
図４Ａ〜４Ｂは、以下の技法のブロック図である。すなわち、（ｉ）（ステップＳ５１９で）エラー修正の第１の試行が行われ、（ｉｉ）何らかの時点で、第１の試行がエラー修正に成功しなかった場合、（ステップＳ５３９で）第１の試行を中止して、エラー修正の第２の試行が行われる。図４Ａ〜４Ｂは、第１の試行が失敗であったと見なされて中止された場合を決定するためのポリシーを確立し実行することに関する。この決定は些細なことではない。（ステップＳ５１９で）エラー修正の第１の試行が「時期尚早」に失敗であると見なされた場合、不必要に遅いエラー修正プロセスおよび／またはリソース消費をもたらすかもしれない。なぜならば、第１の試行が行われたときにその過程を実行することが容認されていれば、成功した／満足したであろう場合に、エラー修正の１つ以上の「余分／不要」な試行が行われてしまうからである。その一方で、第２の試行への遷移が不必要に遅れて「あまりにも余分」な時間／リソースが第１の試行を行うのに費やされた場合、また不必要に遅いエラー修正プロセスおよび／またはリソース消費をもたらすことになるかもしれない。
【００５７】
図４Ａ〜４Ｂでは、エラー修正されるデータが読み出されるメモリブロックの消去カウントにしたがって、いつ第１の試行が失敗であると見なされる（その結果、中止される）かを決定するためのポリシーが確立され実行され得るかを開示している。
図４Ａ〜４Ｂでは、第１の試行は、ステップＳ５１５で確立されたエラー修正パラメータの「第１のセット」を使用して、ステップＳ５１９で行われ、また第２の試行は、ステップＳ５３５で確立されたエラー修正パラメータの「第２のセット」を使用して、ステップＳ５３９で行われる。図４Ａと図４Ｂの両方とも、第１の試行がステップＳ５２３で成功であると決定された場合には、ステップＳ５３９で追加の試行を行う必要はない（ステップＳ５２７を参照する）。
【００５８】
図４Ａは、ステップＳ５１９でのエラー修正の第１の試行（その結果、第１の試行を中止する）から、ステップＳ５３９でのエラー修正の第２の試行にいつ「遷移」するかを決定する基準に関する。
メモリブロックの消去カウントが「低い」場合、次に第１の試行が成功するという比較的「高い」見込みがあるという仮定にしたがって、楽観的アプローチを採用できる。このように、この場合には、ステップＳ５１１で決定する「モード遷移条件」は、比較的「速い」かまたは「軽い」エラーを修正する試行を開始するために比較的「寛容な」ものであるかもしれない（試行がどの程度「速い」か「遅い」か「重い重み」か「軽い重み」かはステップＳ５１５および／またはステップＳ５３５で少なくとも一部は確定できる）。逆に、消去カウントが「高い」場合、次に悲観的なアプローチが採用されるかもしれず、これらの初期の試行がとにかく失敗するという高い可能性があると仮定されるので、ステップＳ５１１で決定する「モード遷移条件」は比較的「速い」かまたは「軽い」エラー修正試行を開始するために「よりけちな」ものであるかもしれない。
【００５９】
「モード遷移条件」は、第１の試行が失敗して、エラー修正のための「第２の」試行または「異なる」試行を行うために、異なる「モード」への遷移が保証されることを決定するための条件である。図４Ａに示されているように、モード遷移条件がステップＳ５３１でトリガされる場合には、エラー修正の新しい試行がステップＳ５３５とＳ５３９とで行われる。条件が第１の試行の間のいかなる特定の時間にもトリガされない場合には、第１の試行がステップＳ５２５に続く。
【００６０】
１つの例では、「遷移条件」は「タイムアウト条件」に関連する。すなわち、ステップＳ５３１では、ステップＳ５１９とＳ５３４の第１の試行が、その試行を「中止」せず、異なるエラー修正パラメータで「新しい試行」も開始せずに、「実行」することがどのくらいの時間許容されるかを決定する。別の例では、第１の試行自体は繰り返しルーチンを使用し、「遷移条件」は「繰り返し条件数」に関する。すなわち、「使用している繰り返しルーチン」のどのくらいのステップが、この「使用している繰り返しルーチン」が失敗であると見なされて、「新しい」または第２の試行が選択され中止される前に、エラーを成功裏に修正せずに実行するのを許容されているかということである。さらに別の例では、「遷移条件」は、この第１の試行を中止する前に、第１の試行で「消費」するかまたは使用できるＣＰＵサイクル数に関する。
【００６１】
図４Ａ（および図４Ｂ）の教示は、「第１の試行」がステップＳ５１９で行われ、第１の試行が「成功しなかった」場合には、「第２の試行」が後で行われるというどんな「繰り返しルーチン」にも適用される。
このように、異なった実施形態では、「モード遷移」が以下のように言及される。すなわち、（ｉ）特定のデコーダのより軽いモードからより重いモードに移行するか、あるいは（ｉｉ）複数のデコーダから選択された第１のデコーダが使用される第１の「モード」から、複数のデコーダから選択された第２のデコーダが使用される第２の「モード」に移行するか、あるいは（ｉｉｉ）ソフトデコーダに関して、ビット確率値の第１のセットに関連している第１のモードから、ビット確率値の第２のセットに関連している第２のモードに移行するか、あるいは（ｉｖ）ソフトビットの第１の数（すなわち、非負整数）が使用される第１のモードから、ソフトビットの第２の数が使用される第２のモードに移行し、また（ｖ）第１のデコーダバス幅を有する第１のモードから、第２のデコーダバス幅を有する第２のモードに移行する（図６Ｂを参照する）。
この提供されたリストは、例示であって、完全なリストではないことが理解されるべきである。
【００６２】
図４Ｂでは、データが読み出される（すなわち、エラー修正が試行される）メモリブロックの消去カウントにしたがった「バジェット」を伴った第１の試行が提供されている。このバジェットは、最初の試行で「消費できる」時間バジェット、ＣＰＵサイクル数バジェット、繰り返し数バジェットまたはいかなる他のタイプの「リソース」バジェットであってもよい。別の実施形態では、このバジェットは、第１の試行に使用される「中間結果」を保存するために割り当てることができる最大の量の揮発性メモリであるかもしれない。
【００６３】
消去カウントが比較的「低い」場合、ステップＳ５６１で「より大きい」バジェットを割り当てることができ、消去カウントが比較的「高い」場合には、「より小さい」バジェットを割り当てることができる。ステップＳ５６１で、この繰り返しステップのエラー修正リソースバジェットを決定し、またステップＳ５６５で、このリソースバジェットが消耗した場合にはその決定がなされる。バジェットが消耗した場合には、エラー修正の新しい試行がステップＳ５３５とＳ５３９とで行われれ、バジェットが第１の試行の間まだ消耗していない場合には、エラー修正の第１の試行がステップＳ５２５で持続する。
【００６４】
図５Ａ〜５Ｂの議論
図５Ａ〜５Ｂは、エラー修正のために読み出されるソフトビット数を決定するための技法に関する（図５Ａ〜５Ｂに言及した前述した議論も参照する）。図５ＡのステップＳ４１９で、エラー修正のために初期の試行用に読み出されるソフトビット数が決定される。このソフトビット数は、エラー修正されるべきデータが（ステップＳ４２３で）読み出される１つ以上の対象メモリブロック（ステップＳ４１５で決定されている）に関連している消去カウントにしたがって決定される。
ステップＳ４２７で、決定されたソフトビット数が読み出され、またステップＳ４３１で、ソフトビットを使用してデータ（すなわち、ステップＳ４２３で読み出されたデータ）中のエラー修正の試行が行われる。試行が成功している場合（ステップＳ４３９を参照する）には、エラー修正プロセスを持続させる必要はない（ステップＳ４４３を参照する）。試行が成功しなかった場合には、ステップＳ４３５で１つ以上の追加のソフトビットを読み出すことができる。
図５Ａにおけるステップの順番（および本願の開示によって示されているすべての図）は限定的ではないことに留意するべきである。例えば、ステップＳ４２３のソリッドステートメモリの対象ブロックからのデータ読み出しを、ステップＳ４１９の決定の前に行うこともできる。
【００６５】
図５Ｂをここで参照する。オプションのステップＳ４６１で、ソフトビット数Ｎが読み出され、Ｎは非負整数である（Ｎがゼロであれば、ステップＳ４６１をスキップし、またステップＳ４３１でエラー修正の第１の試行はソフトビットを使用しない）。ステップＳ４３１で、（ソフトビットが使用可能であれば、ソフトビットを使用して）エラー修正の試行は行われる。この試行が成功した場合（ステップＳ６６５を参照する）には、エラー修正プロセスを持続させる必要はない（ステップＳ４６９を参照する）。この試行が成功しなかった場合には、（すなわち、エラー修正の次の試行における使用のために）ソフトビットがいくつ読み出されるかの決定をステップＳ４７３で行う。この数は、ステップＳ４１５とＳ４２３の１つ以上の対象メモリブロックに関連している消去カウントにしたがって、決定される。
ステップＳ４７７で、ソフトビット数（すなわち、ステップＳ４７３で決定されている）が読み出される。これらのソフトビットはステップＳ４３１で使用される。
【００６６】
図６Ａの議論
図６Ａは、データが読み出されるメモリのブロックの消去カウントにしたがってエラーを修正するための技法のフローチャートである。
ソフトデコーダは、符号語の各ビットに確率を割り当てて（例えば、ビットの値が１であり０ではないという確率）、また他のビットの現在の確率にしたがってそれぞれのビットが変更される確率のそれぞれの複数の繰り返しを実行することによって動作する。
ソフトデコーダではないどんなデコーダもここで「代数的なデコーダ」と呼ばれる。
【００６７】
このタイプの計算は、各ビットがピアに「メッセージをパスする」ので、「メッセージパッシング」技法を使用すると言われる。そのようなデコーダをインプリメントする主要な設計の決定は、メッセージパッシングのバス幅である。広いバス（例えば、１０ビット）を使用するのは、アルゴリズムがエラーに対処できるのであれば、真にアルゴリズムが正しいデータに収束することを保証する。しかし、その一方で、そのような設計ではデコーダの消費電力が高い。狭いバス（例えば、３ビット）を使用すれば、より低い消費電力を提供することができるが、比較的大きいエラー数の場合、（データとエラーの同じパターンが、対応する広いバスデコーダでは正しくデコードされるものであったとしても）デコーダは正しいデータに収束するのを失敗するかもしれない。メッセージパッシングに使用されるビット数はデコーディングプロセスの消費電力に主要な影響を与える、より高いビット数であれば、より高い消費電力となる。
【００６８】
この現象の理由の１つに、ソフトデコーダのメッセージとチャネル入力（ソフト値）がデコーディング操作の間、大きい消費電力のＲＡＭに保存されるということが挙げられる。例えば、１メッセージあたり１０ビットの代わりに３ビットを使用すると、ＲＡＭの７０％をシャットダウンすることができる。消費電力の節約の別の本元は、これらのパッシングメッセージを処理する処理装置である。１０ビットの代わりに３ビットで計算を実行することが、より小さく、そしてより消費電力の低いユニットを要するのは明らかである。
【００６９】
デコーディングの始めに「メッセージパッシング」におけるビット数を設定できるソフトデコーダをインプリメントすることは可能である。このように、いくつかの実施形態では、データが読み出されるブロックの消去カウントにしたがって、デコーダバス幅のサイズが選択される。「楽観的な状況」を示している、消去カウントが「低い」場合には、それにより、より小さいデコーダバス幅のサイズを選択してエラーを修正することができる。そうでなければ、より大きいデコーダバス幅のサイズを選択するのが望ましいかもしれない。
このことは、図６Ａに表を用いて示されている。ステップＳ７５１で、データが読み出されるブロックの消去カウントにしたがって、デコーダバス幅が選択される。ステップＳ７５５で、選択されたデコーダバス幅の値にしたがって、エラーが修正される。
【００７０】
図６Ｂの議論
図６ＢのステップのＳ４１１、Ｓ４２３、およびＳ７５１は、図６Ａと同じである。
ステップＳ７７５で、ステップＳ７５１で選択された、選択されたデコーダバス幅を使用してエラー修正の試行が行われる。この試行が成功した場合（ステップＳ７７９を参照する）には、エラー修正プロセスを持続させる必要はない（ステップＳ７８７を参照する）。そうでなければ、この試行が成功しなかった場合（ステップＳ７８３を参照する）に、新しいデコーダバス幅が選択され、エラー修正の新しい試行が行われる。
【００７１】
追加の議論
ここで開示されたいかなる技法も「デバイス側」上にまたは「ホスト側」上でインプリメントすることができることに留意するべきである。１つの特定の実施形態で、ここで開示されたいかなるステップまたはそのようなステップの組み合わせも（消去カウントを維持するステップ、データまたはソフトビットを読み出すステップ、エラーを修正するステップ、エラー修正の試行を行うステップ、デコーダまたはモードまたはソフトビット数を選択するステップ、特定のデコーダまたはデコーダモードを使用するかどうかを決定するステップ、デコーダバス幅を選択するステップ、遷移条件またはリソースバジェットを決定するかまたは実施するステップなどのステップを含むが、それらに限定されるものではない）、フラッシュデバイス２６０（またはソリッドステートメモリを含むその他のデータストレージデバイスでも）のデバイスコントローラ２８０によって実行することができる。例えば、周辺ストレージデバイス２６０＊のデバイスコントローラによって実行してもよい。
【００７２】
いくつかの実施形態では、「デバイス側」でデータ中のエラーが修正された後に、エラー修正データはストレージデバイス２６０＊からホストデバイス３１０へそれぞれのデバイス間インターフェイスを介して送信され得る。（ステップＳ４２３のデータ読み出しとあらゆるエラー修正とともに）、ソリッドステート不揮発性メモリ（例えば、フラッシュメモリ２７０）に保存されたデータを読み出すために、ホスト３１０から周辺ストレージデバイス２６０＊に送信された要求に応答して行われ得る。
【００７３】
デバイスコントローラ２８０は、いかなるソフトウェアおよび／またはファームウェアおよび／またはフィールドプログラマブル論理アレイ（ＦＰＬＡ）素子、配線論理素子、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）素子、および特定用途向け集積回路（ＡＳＩＣ）素子を含むが、これらに限定されないハードウェア素子も含むことができる。縮小命令セットコンピュータ（ＲＩＳＣ）のアーキテクチャおよび／または複合命令セットコンピュータ（ＣＩＳＣ）のアーキテクチャを含むがこれらに限定されないいかなる命令セットのアーキテクチャも、コントローラ２８０で使用できる。
【００７４】
ハードウェア、ハードウェアが実行するコンピュータ可読コードモジュール、およびファームウェアのどのような組み合わせにおいてもここで開示されたいかなる技法をインプリメントすることができる。
本発明の実施形態は、開示されたいかなる技法をもインプリメントするための装置またはコンピュータ媒体を提供する。
本願明細書で引用されたすべての参考文献は、その全体が参照により援用されている。参考文献からの引用がこの参考文献が従来技術であるという認容を構成するものではない。
前に説明した実施形態のいずれもが、図に関連して前に説明した操作をインプリメントするための、コンピュータ可読媒体上の、命令および／またはデータを、受信したり、送信したり、あるいは保存したりすることをさらに含むことができることにさらに留意するべきである。一般的には、コンピュータ可読媒体は、ストレージメディアまたは磁気、フラッシュまたは光学メディアなどのメモリメディア、例えばディスクまたはＣＤ−ＲＯＭ、ＲＡＭ／ＲＯＭなどの揮発性または不揮発性メディアを含むことができ、またネットワークおよび／またはワイヤレスリンクなどの通信媒体を通して転送される、電気信号、電磁気信号またはデジタル信号などの伝送メディアまたは信号を含むことができる。
【００７５】
このように、前に説明した実施形態に関して、添付の特許請求の範囲で列挙されている範囲と趣旨から逸脱せずに、様々な同等物、それらの改変、修正および改良が可能であることが当業者にとって明らかである。特に、種々の実施形態が本願明細書に記載されたもの以外の特徴の組み合わせを含むことができる。したがって、特許請求の範囲は前述した議論に限定されるものではない。
【図１Ａ】
0005887589.tif 000002
【図１Ｂ】
0005887589.tif 000003
【図２Ａ】
0005887589.tif 000004
【図２Ｂ】
0005887589.tif 000005
【図３Ａ】
0005887589.tif 000006
【図３Ｂ】
0005887589.tif 000007
【図３Ｃ】
0005887589.tif 000008
【図３Ｄ】
0005887589.tif 000009
【図４Ａ】
0005887589.tif 000010
【図４Ｂ】
0005887589.tif 000011
【図５Ａ】
0005887589.tif 000012
【図５Ｂ】
0005887589.tif 000013
【図６Ａ】
0005887589.tif 000014
【図６Ｂ】
0005887589.tif 000015