メモリの管理方法
【課題】リードディスターブエラーの防止とｂａｄブロック処理を効率よく行うメモリの管理方法の提供。
【解決手段】
フラッシュメモリデバイスにリフレッシュ管理テーブルを設け、物理ブロック毎のデータ読み出し回数、消去回数を随時記憶、更新する。データ読み出し回数が予め決定してなる閾値に至ったときに、該物理ブロックにフラグ“Low”を設定する。またデータ読み出し時にECCエラーが発見された物理ブロックにはフラグ“High”を設定する。そして適宜リフレッシュ管理テーブルをサーチし、フラグ“Low”のブロックはリフレッシュし、フラグ“High”のブロックはｂａｄブロック処理を行う。
【解決手段】
フラッシュメモリデバイスにリフレッシュ管理テーブルを設け、物理ブロック毎のデータ読み出し回数、消去回数を随時記憶、更新する。データ読み出し回数が予め決定してなる閾値に至ったときに、該物理ブロックにフラグ“Low”を設定する。またデータ読み出し時にECCエラーが発見された物理ブロックにはフラグ“High”を設定する。そして適宜リフレッシュ管理テーブルをサーチし、フラグ“Low”のブロックはリフレッシュし、フラグ“High”のブロックはｂａｄブロック処理を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メモリ、取り分けNAND型フラッシュメモリの管理方法に関する。
【背景技術】
【０００２】
EEPROM（電気的にデータの消去及び書き換えが可能な不揮発性メモリ）の一種としてフラッシュメモリが知られている。フラッシュメモリは、ワード線とビット線の交点に位置するセルに電荷を蓄積し、データの書き込み（プログラムともいう）を行うメモリである。電荷がセルに蓄積されている以上、電源をOFFにしてもデータは失われない。しかしフラッシュメモリにおいては、リードディスターブエラー（read disturb error）といって、所定物理ブロックの所定ページのデータが読み出されると、同一ブロック内の他のページのセルに記憶されているデータが変化してしまう現象が生じる場合がある。これは、データの読み出し対象となった選択セルからデータが読み出される際、非選択セル（データ読み出し対象となっていないページのセル）の浮遊ゲートに電荷が注入されてしまい、これにより非選択セルが弱くプログラムされたのと同じ状態になるためであり、読み出し回数が増えるに従い、より多くのメモリセルが影響を受ける。このためフラッシメモリでは、通常、読み出し回数制限値がベンダーによって指定されている。例えば、現行製品で、SLC（Single-Level-Cell）では、１０万回乃至１００万回、MLC（Multi-Level-Cell）では、１万回乃至１０万回である。一般に、データ書き換え回数が増大すると、読み出し回数はより制限される。
【０００３】
（従来技術の問題点）
このリードディスターブエラーに対処するため、該エラーが生じない特別な回路を予め用意したり、電荷の変化したセル単体を個別に探し出してこれを補正しエラーデータが読み出されないようにする方法などが提案されているが、回路や処理が複雑で高価となり、実用的ではない。
【０００４】
また、他の対処方法としては、物理ブロックごとにデータ読み出し回数をカウントし、ベンダー指定のデータ読み出し回数制限値に至ったときにそのブロックのリフレッシュを都度実行している。即ち、読み出し対象となった当該ブロックがデータ読み出し回数制限に至ったとき、データ読み出しの直前又は直後にリフレッシュを実行している。このため、複数の物理ブロックが一度にデータ読み出し制限に至ったとき、連続したリフレッシュ実行のために一定のデータ転送レートが保証できずユーザに不快感を与えたり、ホストに読み出されるデータが一時的に中断しプレイに支障が生じるといった問題が生じる。
【特許文献１】特開１０−２２８７８３
【特許文献２】特開２００２−１５０７８３
【特許文献３】特開２００４−３２６８６７
【特許文献４】特許第３６４１０６６号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、このような問題点に鑑みてなされたものであり、NAND型フラッシュメモリデバイスのリードディスターブエラーの防止とｂａｄブロック処理を効率よく行うメモリの管理方法を提供することにある。その他の目的は、明細書、図面、特に特許請求の範囲から自ずと明らかとなろう。
【課題を解決するための手段】
【０００６】
上記課題解決のため、本発明は、請求項記載の新規な特徴的構成を採用する。
【発明を実施するための最良の形態】
【０００７】
以下、本発明を実施するための最良の形態について図面を用いて説明するが、本発明は特許請求の範囲内において種々の形態を採ることができ、下記実施形態に限定されないことはいうまでもない。
【０００８】
（システム基本構成）
図１に示すように、本発明は、NAND型フラッシュメモリ２２（本明細書において、特に必要のない限り、単に“フラッシュメモリ”という）と該フラッシュメモリ２２に対するデータの書き込みや読み出しの実行、その他の制御を行うコントローラ２１を有するフラッシュメモリデバイス２（特許請求の範囲の「記憶装置」に相当）において実行される。本願では、フラッシュメモリデバイス２と、該デバイス２にデータの書き込みや読み出しのコマンドを発行するホスト１からなる構成をシステムという。コントローラ２１には、必要に応じ作業領域としてのRAM２３を接続する。RAM２３はコントローラ２１の内部に設けてもよい。システムは、例えばMPEG音楽プレーヤのように、所定の機器として一体に構成されていてもよいし、ホスト１がPC（パーソナルコンピュータ）で構成され、フラッシュメモリデバイス２がSSD（Solid State Drive）としてPCとUSBインターフェースやIDEインターフェースで接続される構成であってもよい。その他、遊技機等所定の機器に搭載される基板上に構成されてもよい。
【０００９】
フラッシュメモリ２２は、ユーザデータ領域、予備領域、管理領域を有する。ユーザデータ領域は、主記憶領域とも呼ばれる。ユーザデータ領域を構成する物理ブロックは、論理ブロックと対応する関係を有し、その関係は論理／物理ブロック管理テーブルで管理され、その対応関係が変わると、随時該テーブルで更新される。予備ブロック（予備領域を構成するブロック）は、ユーザデータ領域を構成する物理ブロックがｂａｄブロックとなったときに使用される代替ブロックである。また、フラッシュメモリ２２には空きブロックが少なくとも一つ確保される。この空きブロックは、通常、ユーザデータ領域の物理ブロックにデータを上書きするときに使用されるブロックである。この場合空きブロックは、予備ブロック同様、論理ブロックアドレスと関連付けされない。なお、詳細は後述するが、本願のリフレッシュは、この空きブロック若しくは予備ブロックのいずれかを使用して実行する。
【００１０】
図２は、フラッシュメモリ２２のメモリアレイを示している。図示するように、ユーザデータ領域は物理ブロック番号“０”から“４０４１”で構成され、物理ブロック番号“４０４２”が空きブロック、物理ブロック番号“４０４３”から“４０９１”までが予備ブロックで構成されている。その他、物理ブロック番号“４０９２”から“４０９５”までの管理領域が存在する。コントローラ１１は、空きブロックの物理ブロック番号及び予備ブロックの物理ブロック番号を把握するため、それぞれ不図示の空きブロックテーブル、予備ブロックテーブルで管理する。論理／物理ブロック管理テーブル、空きブロックテーブル、予備ブロックテーブルを総称して、ブロック管理テーブルというものとする。
【００１１】
図３はリフレッシュ管理テーブルの内容例を表している。リフレッシュ管理テーブルは、システム稼動中RAM２３において、物理ブロックごとのデータ読み出し回数や消去回数を記憶するものである。システム稼動中はその内容が適宜更新される。システムの電源が遮断されるとき、その内容は管理領域に保存される。システム稼動の度にこれが繰り返される。
【００１２】
フラッシュメモリデバイス２がホスト１からデータ読み出しコマンドを受けると、コントローラ２１は、ホスト１から指定されたアドレスを論理ブロックアドレスとして、その論理ブロックアドレスに対応する物理ブロックアドレスを論理／物理ブロック管理テーブルから割り出してデータを読み出す。そしてその都度、リフレッシュ管理テーブルに、当該物理ブロックに対するデータ読み出し回数を記録する（図３参照）。また、物理ブロックのデータを消去するごとに消去回数をインクリメントして記録する。消去はそのブロック内のデータの書き換えを含む概念である。
【００１３】
物理ブロックのデータ読み出し回数制限値（図４のベンダー指定値）は、一般に過去の消去回数に依存する。即ち、過去にデータ消去された回数が多いほど、読み出し回数は制限される。このデータ読み出し回数制限値は、例えば図４に示すように、物理ブロックの消去回数が０回から９９９回までは１,０００,０００回（図４のフェーズＡ）、消去回数が１,０００回から９,９９９回までは３００,０００回（図４のフェーズＢ）、消去回数が１００００回から９９,９９９回までは１００,０００回（図４のフェーズＣ）と設定される。
【００１４】
従来、そのブロックのデータ読み出し回数が制限値に至ったとときに、読み出しを実行する直前又は直後に、その都度リフレッシュを実行していたが、read時間が増大するという問題があった。そこで本発明では、リフレッシュ管理テーブルを用い、後述する方法により、対象となるブロックを時分割に一括してリフレッシュし、read時間の増大を防止するものである。
【００１５】
まず、リフレッシュを実行する基準（コントローラ閾値）をベンダー指定値より小さい値に設定することにより、データ読み出し回数がベンダー指定値に至る前に有効にリフレッシュを実行できるようにした。図４のフェーズＡ，Ｂ，Ｃのベンダー指定値とコントローラ閾値の関係を参照されたい。データ読み出し回数が、コントローラ閾値に至ると、コントローラ２１（正確にはコントローラ２１のCPU（図示せず））は、リフレッシュ管理テーブルの当該物理ブロックにフラグ“Low”（特許請求の範囲の第１種フラグに相当）を設定する（図３）。
【００１６】
システムの電源が遮断される際は、リフレッシュ管理テーブルの内容を管理領域に不揮発的に記録し、次回システム稼動時に再度RAM２３に展開し、過去の記録を利用する。システム稼動中に何らかの理由により電源が遮断される可能性があるので、所定時間間隔ごとに（例えば１０分おき）、リフレッシュ管理テーブルの内容を、管理領域に記録してもよい。
【００１７】
以下、本発明のリフレッシュ方法の実施形態例を説明する。
（第1実施例：オートリフレッシュ）
オートリフレッシュは、デバイス２に電源投入直後、ホスト１よりコントローラ２１に、ENABLE/DISABLE AUTO REFRESH コマンド（デバイス提供者で定義するユニークコマンド。以下、単にオートリフレッシュコマンドという。）を発行しておき、所定時刻及び／又は所定時間間隔にリフレッシュを実行させる方法である。デバイス２に定常的に電源が投入されているようなシステムの場合は、所定時刻ごと（秒単位で設定可能）にリフレッシュを実行してもよい。またはコントローラ２１に、ENABLE/DISABLE AUTO REFRESH コマンドで実行すると同様なプログラム（ファームウエア）を予めインストールしておいてもよい。これらオートリフレッシュは、フラッシュメモリデバイス２が有するタイマー（図示せず）を利用して自動的にリフレッシュを実行する方法であるため、本願では以下、タイマーイベントという。オートリフレッシュの場合、特許請求の範囲のステップｄ）、ｅ）、ｆ）がタイマーイベントで実行される。
【００１８】
Ａ.フラグ“Low”の設定されている物理ブロックが一つだけ存在する場合
オートリフレッシュコマンドまたはファームウエアにより、タイマーイベントが、ホスト１がメディアアクセスをしていないときに発生した場合は、コントローラ２１はリフレッシュ管理テーブルをサーチし、フラグ“Low”が設定されている物理ブロックが一つ存在することが確認された場合、コントローラ２１は当該フラグが設定されている物理ブロックのリフレッシュを直ちに実行する。尚、メディアアクセスとは、ホストがコマンドを発行することにより、フラッシュメモリ２２からデータの読み出しや、データの書き込みを行うことをいう。
【００１９】
タイマーイベントが、ホスト１がメディアアクセスしているときに発生した場合は、一の物理ブロックに対するメディアアクセスの処理を完了し次のメディアアクセスの処理開始前に割り込んでリフレッシュを実行する。
【００２０】
Ｂ.フラグ“Low”の設定されている物理ブロックが二つ以上存在する場合
タイマーイベントが、ホスト１がメディアアクセスを実行していないときに発生した場合であって、リフレッシュ管理テーブルでフラグ“Low”が設定されている物理ブロックが二つ存在することが確認された場合、コントローラ２１は当該フラグが設定されている物理ブロックを一つずつ、即ち、ブロック単位でリフレッシュする。まずデータ消去回数が、図４のフェーズＡ，Ｂ，Ｃのいずれに該当するかを判定し、データ読み出し回数がそれぞれの閾値（コントローラ閾値）を超えた値が大きいもの順にリフレッシュを実行する。又は、データ読み出し回数がベンダー指定値に近いもの順にリフレッシュを実行する。図４では、フェーズＡ，Ｂ，Ｃのそれぞれで、ベンダー指定値とコントローラ閾値の差がすべて同じであるため、上記２例において実質的に同一の結果となるが、フェーズＡ，Ｂ，Ｃのそれぞれで、ベンダー指定値とコントローラ閾値の差を異なる値に設定した場合は、前者の実行方法を採った場合と後者の実行方法を採った場合とではリフレッシュの順番が異なる。このような方法を採ることにより、リードディスターブエラーを生起する可能性の高い順番で物理ブロックがリフレッシュされるため、リードディスターブエラーの発生をより確実に防止することができる。
【００２１】
Ｃ.タイマーイベントがホスト１がメディアアクセスしているときに発生した場合、若しくはホスト１のメディアアクセス中にタイマーイベントが発生した場合であって、フラグ“Low”の設定されている物理ブロックが複数存在することが確認された場合。
この場合は、物理ブロック単位で、時分割にリフレッシュを実行する。即ち１物理ブロック当たりのタイマーイベントの処理は、その開始から終了までせいぜい１００ｍｓ（ミリ秒）程度であるから、リフレッシュ間隔（一の物理ブロックのリフレッシュ開始から次の物理ブロックのリフレッシュ開始まで）を、例えば１秒以上に設定する。そしてコントローラ２１は、まず一の物理ブロックに対するメディアアクセスの処理の完了後、次のブロックのメディアアクセスの処理開始前に割り込んで１物理ブロックのリフレッシュを実行する。その後1秒経過してから同様なタイミングで次の物理ブロックのリフレッシュを実行する。
【００２２】
このようにすれば、リフレッシュ対象ブロックが複数存在する場合でも、ホスト１にデータを転送している最中にデータが途切れてユーザに不快感を与えたり、プレイに支障を生じさせることがない。特に、フラッシュメモリ２２に記憶されているデータが音楽や動画などのコンテンツであって、多数の物理ブロックが一度にコントローラ閾値に達するような事態が生じても、物理ブロックごと時分割にリフレッシュを実行することにより、一定のデータ転送レートを担保することができ、ユーザに支障を来たすことがない。
【００２３】
以下、図を用いて、フラグ“Low”の設定された物理ブロックに対するリフレッシュのやり方について説明する。
【００２４】
図３に示す通り、リフレッシュフラグの設定されている物理ブロックが、物理ブロック番号“２”、“６”及び“９９９９”の三つあるとする。データ消去回数は、物理ブロック番号“２”も物理ブロック番号“６”もどちらも０回で、フェーズＡに該当する。データ読み出し回数は、物理ブロック番号“２”は990,100回、物理ブロック番号“６”は990、515回であり、コントローラ閾値990,000に対して、物理ブロック番号“６”が、より閾値を超えているため、リフレッシュは物理ブロック番号“６”が、物理ブロック番号“２”に優先する。また物理ブロック番号“９９９９”のデータ消去回数は1050回であるためフェーズＢに該当し、コントローラ閾値290,000に対して読み出し回数が290,050回であり、コントローラ閾値を越える回数は、物理ブロック番号“２”より少ないから、リフレッシュは物理ブロック番号“２”が優先する。以上より、物理ブロック番号“６”、“２”、“９９９９”の順にリフレッシュを実行することになる。
【００２５】
物理ブロック番号“６”のリフレッシュに当たっては、まず空きブロック（物理ブロック番号“４０４２”）を新たなデータ書き込み用のブロックとして選定する。次にリフレッシュ対象物理ブロックである物理ブロック番号“６”から１ページずつフラッシュメモリ２２内のバッファにすべてのデータを読み出し、続いてバッファから前記新たなデータ書き込み用ブロックに全てのページのデータを１ページずつプログラム（書き込み）する。そして元のブロックである物理ブロック番号“６”のデータを一括消去する（図５参照）。１ブロック分のデータすべてを読み出してから新たなデータ書き込み用ブロックへ書き込むのではなく、バッファへの読み出しと新たなデータ書き込み用ブロックへの書き込みを、ページ単位で、順次行ってもよい。この場合、バッファの容量は１ページ分で足りる。
【００２６】
そして、元の物理ブロックである物理ブロック番号“６”に対応していた論理ブロック番号を、新たなデータ書き込み用ブロックとなった物理ブロック番号（“４０４２”）に新たに対応させて、論理/物理ブロック管理テーブルを更新するとともに、物理ブロック番号“６”を空きブロックとして、空きブロック管理テーブルを更新する（“４０４２は空きブロック管理テーブルから削除する”）。また、リフレッシュ管理テーブル上で、消去した元のブロックである物理ブロック番号“６”のデータ読み出し回数をゼロに変更し、データ消去回数を1つインクリメントする。以上で物理ブロック番号“６”に対するリフレッシュが完了する。物理ブロック番号“６”のリフレッシュが終了したら、以降、物理ブロック番号“２”、”９９９９”についても、上記例に倣ってリフレッシュを実行する。なお新たなデータ書き込み用のブロックは、予備ブロックの一つ(例えば、物理ブロック番号“４０４３”)から選定してもよい。この場合は、元の物理ブロックに対応していた論理ブロック番号を、新たなデータ書き込み用ブロックとなった物理ブロック番号（“４０４３”）に新たに対応させて、論理／物理ブロック管理テーブルを更新するとともに、元の物理ブロック番号を空きブロックとして、空きブロック管理テーブルを更新する（“４０４２は空きブロック管理テーブルから削除する”）。
【００２７】
尚、必ずしもホスト１への高速なデータ転送が要求されない場合は、リフレッシュ対象物理ブロックである物理ブロック番号“６”から１ページずつエラー訂正しながらRAM２３（リフレッシュ管理テーブルを記録する領域意外の領域を利用）にすべてのデータを読み出して格納し、続いてRAM２３から前記新たなデータ書き込み用ブロックに全てのページのデータを１ページずつプログラム（書き込み）してもよい。こうすれば、ブロックの潜在的なエラーをすべて訂正するので、データの信頼性が高まる。この場合もバッファへの読み出しと新たなデータ書き込み用ブロックへの書き込みを、ページ単位で、順次行ってもよいことは言うまでもない。
【００２８】
従来リフレッシュは、データの読み出し中にイレギュラーに必要となり、ホストへのデータのread時間が増大していたが、本発明では、リフレッシュ管理テーブルを用いて、所定のタイミングで一括して行うので、斯かる不都合は生じない。また従来のリフレッシュのやり方は、１）その物理ブロックのデータをフラッシュメモリ２２内のバッファに待避し、次に２）当該ブロックのデータを消去し、その後３）待避しておいたデータを元のブロックに再書き込みしている。この場合、当該ブロックのデータを消去した後であってかつバッファに待避しておいたデータを元のブロックに再書き込み完了する前に何らかの原因で電源が遮断された場合、本来のデータが消失してしまう危険性がある。この点、上記実施形態例によれば、新たなデータ書き込み用ブロックにデータが完全にコピーされるまで、元のブロックのデータは消去されないから、リフレッシュ中のどの段階で電源が遮断されても本来のデータが失われることがない。尚本発明においても、上記１）乃至３）のやり方でリフレッシュしてもよいことは言うまでもない。その場合は元のブロックを再利用するので、ブロック管理テーブルのいずれも変更しなくてよい。
【００２９】
（第２実施例:ホストからのコマンド発行によるリフレッシュ）
上述のオートリフレッシュの他、メディアアクセスを実行しないときに、ホスト１がコントローラ２１に以下のようなコマンドを発行してリフレッシュを実行してもよい。
１．GET REFRESH PENDING STATUS コマンド
本コマンドは、コントローラ２１に対し、リフレッシュ管理テーブルをサーチさせ
て、リフレッシュフラグ（“Low”又は後述する“High”）が設定されている物理ブロックの総数をホスト１に通知させるものである。
２．EXECUTE
REFRESH コマンド
本コマンドは、コントローラ２１にリフレッシュを実行させるものである。リフレ
ッシュが終了するとコマンドが終了する。リフレッシュを実行する物理ブロック数を指定できる。
３．SAVE
REFRESH TABLE コマンド
本コマンドは、コントローラ２１に、RAM２３上のリフレッシュ管理テーブルの内
容を、管理領域に保存させるものである。リフレッシュ管理テーブルの保存が終了するとコマンドが終了する。
【００３０】
ホスト１のドライバには、GET REFRESH PENDING STATUS コマンドを発行して、リフレッシュの必要なブロックの有無及びその数を把握し、リフレッシュの必要なブロックがあれば、ホスト１がメディアアクセスしていないときにコントローラ２１にEXECUTE REFRESHコマンドを発行するようプログラムしておく。
【００３１】
このようにすれば、ホスト１は必要に応じて適宜コントローラ２１にリフレッシュを実行させることができる。即ち、コントローラ２１は、必要なときにのみ、効果的にリフレッシュを実行することができる。またSAVE REFRESH TABLE コマンドにより、必要に応じ、コントローラ２１にRAM２３上のリフレッシュ管理テーブルの内容をフラッシュメモリのリフレッシュ管理テーブルに不揮発的に保存させることができる。
【００３２】
以上のように、本発明は上記第１実施例、第２実施例のいずれのリフレッシュ方法を採用しても、リフレッシュを実行すべき物理ブロックが複数存在する場合、一定のタイムインターバルを以って複数の物理ブロックを時分割でリフレッシュするため、音楽や動画などのコンテンツの読み出しが途中で途切れ、ユーザに不快感を与えたり、プレイに支障を生じることがない。また、メディアアクセスする必要のないタイミングに上記ベンダーコマンドを発行するようホスト１のドライバにプログラムしておくことにより、コントローラ２１の動作効率をより向上させることができる。
【００３３】
（ｂｉｔエラーの対応及びｂａｄブロックの処理）
フラッシュメモリデバイスは、データ書き込みの際、ユーザデータに対してエラーチェックコード（ECC）を付加して書き込んでいる。データ読み出し時にはデコーダがこのエラーチェックコードを基に、読み出したデータにエラー（本願ではこれを「ｂｉｔエラー」という）がないかをチェックし、ｂｉｔエラー数がコントローラの能力値（例えば８ｂｉｔ）以内であれば、コントローラ２１内のエラー訂正回路（図示せず）がｂｉｔエラーを訂正し、正しいデータをホスト１に送出する。ｂｉｔエラーは、データの消去、リードディリスターブ、経年変化（データリテンション）、セルの物理的欠陥（たとえば絶縁膜の劣化、破壊）などに起因して生じる。ｂｉｔエラー数がコントローラ能力値を超えると、その欠陥セルを含むブロックは、もはやエラー訂正ができず、使用に耐えないｂａｄブロックとなる。
【００３４】
そこで本発明では、安全性を担保するため、コントローラ２１の能力値と同じかそれより小さい所定値（例えば７ｂｉｔ）を予め閾値（「ｂａｄブロック閾値」という）として設定しておき、ｂｉｔエラーがｂａｄブロック閾値に至ったセルを含むブロックをｂａｄブロックと看做し、お蔵入りとするものである。
【００３５】
以下、この処理を簡単に説明する。まず、読み出したデータのｂｉｔエラー数がｂａｄブロック閾値未満であったときは、通常通り、ｂｉｔエラーを訂正してデータをホスト１に送出する。ｂｉｔエラーがｂａｄブロック閾値以上かつコントローラの能力値以下であったときは、ｂｉｔエラーを訂正したデータをホスト１に送出するとともに、リフレッシュ管理テーブルの当該エラーを含む物理ブロックに、第２種フラグ“High”を設定する。図３には、物理ブロック番号“４”において、読み出し回数３００回でフラグ“High”が設定されている様子が示されている。
【００３６】
タイマーイベントが発生し、若しくはリフレッシュコマンドがホスト１から発行され、コントローラ２１がリフレッシュ管理テーブルをサーチした結果、フラグ“High”が設定された物理ブロックが確認されたときは、予備ブロック（ここでは物理ブロック番号“４０４４”）を新たなデータ書き込み用ブロックに割り当てる。次にｂａｄブロックと看做された物理ブロックの全データを１ページずつエラー訂正しながらRAM２３に一旦格納し、前記予備ブロックに書き込む。ｂａｄブロックと看做された物理ブロックの全データをフラッシュメモリ内２２のバッファに読み出して、エラー訂正することなく予備ブロックに書き込んでもよいが、エラー訂正して書き込む方がデータの信頼性が高まる。データの書き込み処理が完了したら、元の物理ブロックの論理ブロック番号と予備ブロックの物理ブロック番号“４０４４”を新たに対応させて、論理／物理ブロック管理テーブルを更新する。このとき元のブロックの物理ブロック番号がブロック管理テーブルから削除されるので、元の物理ブロックは以降使用されることはない。
【００３７】
そして、リフレッシュ管理テーブル上において、ｂａｄブロックと看做された物理ブロックアドレス“４”のフラグ“High”をNoneにする。この場合、元ブロックは以降使用しないので、ブロックに記憶されているデータは消去しなくてよい。以上で、フラグ“High”の設定された物理ブロック番号“４”に対する処理が完了する（本願では以上の処理を“ｂａｄブロック処理”というものとする）。
【００３８】
尚、万一ｂｉｔエラー数がコントローラ能力値を超えた場合は、エラー訂正ができないため、コントローラ２１はホスト１にエラーを返すことになるが、ｂａｄブロックと看做すための前記ｂａｄブロック閾値を、アプリケーションや使用環境に応じて適切な値に設定することにより、斯かる事態の発生を防ぐことができる。
【００３９】
そして、コントローラ２１がリフレッシュ管理テーブルをサーチしたとき、フラグ“Low”の設定されている物理ブロックとフラグ“High”の設定されている物理ブロックが並存する場合は、フラグ“High”の設定されている物理ブロックに対するｂａｄブロック処理を、フラグ“Low”の設定されている物理ブロックのリフレッシュに優先して実行する。
【００４０】
上記第1実施例（オートリフレッシュ）において、タイマーイベントが、ホストがメディアアクセス実行中に発生した場合若しくはタイマーイベントの処理中にホスト１からメディアアクセスコマンドが発行された場合であって、その時点でリフレッシュ管理テーブル上に、フラグ“Low”及び／又は“High”の設定されている物理ブロックが複数存在する場合は、フラグ“High”の設定されている物理ブロックの処理を優先しつつ、フラグ“High”及び／又は“Low”の設定されている物理ブロックに対する処理を、前述した方法（段落００２１参照）と同様に、ブロック単位で時分割に実行する。
【００４１】
また上記第２実施例（ホストからのコマンド発行によるリフレッシュ）において、コントローラ２１がリフレッシュの実行中にさらにホスト１からメディアアクセスコマンドが発行された場合であって、その時点でリフレッシュ管理テーブル上に、フラグ“Low”及び／又は“High”の設定されている物理ブロックが複数存在する場合も、フラグ“High”の設定されている物理ブロックの処理を優先しつつ、フラグ“High”及び／又は“Low”の設定されている物理ブロックに対する処理を、前述した方法（段落００２１参照）と同様に、ブロック単位で時分割に実行する。
【００４２】
尚、万一ｂｉｔエラー数がコントローラ能力値を超えた場合は、エラー訂正ができないため、コントローラ２１はホスト１にエラーを返すことになるが、ｂａｄブロックと看做すための前記ｂａｄブロック閾値を、アプリケーションや使用環境に応じて適切な値に設定することにより、斯かる事態の発生を防ぐことができる。
【００４３】
以下、コントローラ２１がホスト１からコマンドを発行された場合の処理（リフレッシュコマンドに基づきリフレッシュを行う場合の例）を、図７乃至図９のフローチャートを用いて説明する。はじめに図７を用いて説明する。コントローラ２１は常時ホスト１からコマンドが発行されたかを確認する（SP１）。コマンドが発行された場合、その発行されたコマンドがデータの上書きを伴う書き込みコマンド又は消去コマンドか確認し（SP２）、ｙｅｓの場合は、当該コマンドを実行し（SP３）、リフレッシュ管理テーブルの当該コマンドが実行された物理ブロックの“消去回数”を１つインクリメントする（SP４）。初期値は０である。発行されたコマンドがデータの上書きを伴う書き込みコマンド又は消去コマンドでない場合は、引き続きデータの読み出しコマンドであるか確認し（SP５）、ｙｅｓの場合は※１（図８）へ進む。即ち、そのコマンドに従ってデータの読み出しを実行し（SP６）、データを読み出したページを含む物理ブロックの“読み出し回数”を一つインクリメントする（SP７）。そして、そのブロックに係る読み出し回数がコントローラ閾値以上であるか確認し（SP８）、ｙｅｓであれば、リフレッシュ管理テーブルにフラグ“Low”を設定する（SP９）。そして読み出したデータにｂｉｔエラーがないか確認し（SP１０）、ない場合はデータをそのままホストに送出する（SP１１）。ｂｉｔエラーがあった場合は，ｂａｄブロック閾値未満であるか確認し（SP１２）、ｙｅｓであればエラー訂正した上で（SP１３）、データをホストに送出する（SP１１）。ｂｉｔエラーがｂａｄブロック閾値以上であった場合はコントローラ能力値以下であるかを確認し（SP１４）、ｙｅｓであればリフレッシュ管理テーブルの当該物理ブロックにフラグ“High”を設定し（SP１５）、エラー訂正した上で（SP１３）、データをホストに送出する（SP１１）。仮にｂｉｔエラーがコントローラ能力値を超えていた場合はホストにエラーを返し（SP１６）、※３（図８参照）に進む。
【００４４】
SP５でnoであった場合は、※２へ進む（図９参照）。即ち、ホストから発行されたコマンドがリフレッシュコマンドであるか確認し（SP１７）、noであれば当該処理を実行して（SP１８）、※３に進む。ｙｅｓであればリフレッシュ管理テーブルをサーチし（SP１９）、フラグ（“High”及び／又は“Low”）が設定されているかを確認する（SP２０）。そしてｙｅｓであれば、フラグ“High”のブロックに対する処理を、フラグ“Low”のブロックに優先して行う（SP２１）。そして、論理/物理ブロック管理テーブルを更新し（SP２２）、※３へと進む。
【００４５】
以上のように、上記実施形態例では、リードディスターブエラー発生の未然防止（リフレッシュ）と、種々の原因により発生したｂａｄブロックの処理を、リフレッシュ管理テーブルを用いて一括して処理することができるため、従来にはないシステムパフォーマンスを提供することができる。
【００４６】
尚、RAM２３は、コントローラ２１に外付けする場合、Random Access Memoryの他、DRAM、SDRAM（synchronous DRAM）でもよい。
【００４７】
また、図６に示ように、リフレッシュ管理テーブルは、工場出荷時に物理ブロックごとに異なるデータ読み出し回数（ダミー）を記録しておいてもよい。このようにすれば、専らシーケンシャルリード（sequential read）されるアプリケーションの場合、リフレッシュをさらに分散して実行することができる。
【００４８】
また、本システムが遊戯機に搭載される場合、一日のプレイ中に何度もコンテンツデータが読み出される。コンテンツは例えば、図柄である。このコンテンツデータは複数の物理ブロックに跨ってファイルとして管理されている場合もある（これをコンテンツファイルという）。この場合、一日における当該図柄の読み出し回数を記憶しておくとともに、システム電源をオンしたときに、一日における当該図柄の読み出し回数の最大値や毎日の平均値を求め、当日にフラグ“Low”が設定され得る状況であるかを予想し、設定される可能性がある場合は、システム本稼動前にリフレッシュを前倒しで実行してもよい(フィードフォワード制御)。或いは、システム稼動終了後に翌日にフラグ“Low”が設定されるかを予想し、設定される可能性がある場合、電源OFF前にリフレッシュを実行してもよい。このようにすれば、プレイ途中のリフレッシュを極力少なくすることができ、システムパフォーマンスを一層向上させることができる。パチンコ遊技機やスロットマシンのように、一日中稼動する遊技機の場合は特に有効である。
【００４９】
以上説明したように、本発明は、リフレッシュをデータ読み出し回数制限値（ベンダー閾値）に至る前に実行するとともに、リフレッシュとｂａｄブロック処理の両者をjust in time方式ではなくリフレッシュ管理テーブルを使用して集中して実行するため、リードディステーブエラーの防止とｂａｄブロック処理を有効且つ効率的に行うことができる。またホストからの継続したデータ読み出し要求がなされた場合でも一定のタイムインターバルで時分割にリフレッシュやｂａｄブロック処理を実行するので、データ転送レートを保証でき、ユーザに不快感を与えたり、ホストに転送されるデータが一時的に中断しプレイに支障が生じることを防止することができる。ホストがメディアアクセスしないときにコマンドを発行してリフレッシュを実行する場合は、データ転送レートをより一層保証することができる。
【図面の簡単な説明】
【００５０】
【図１】本発明の実施形態を実行するシステムの基本構成例である。
【図２】フラッシュメモリの領域例である。
【図３】リフレッシュ管理テーブルの内容例である。
【図４】データ消去回数範囲（フェーズ）ごとの、データ読み出し回数のベンダー指定値及びコントローラ閾値の関係例である。
【図５】リフレッシュの実行方法例である。
【図６】工場出荷時（初期状態）のリフレッシュ管理テーブル例である。
【図７】コントローラが実行する処理のフローチャート例である。
【図８】コントローラが実行する処理のフローチャート例（続き）である。
【図９】コントローラが実行する処理のフローチャート例（続き）である。
【符号の説明】
【００５１】
１ ホスト
２ フラッシュメモリデバイス
２１ コントローラ
２２ NAND型フラッシュメモリ
２３ RAM
【技術分野】
【０００１】
本発明は、メモリ、取り分けNAND型フラッシュメモリの管理方法に関する。
【背景技術】
【０００２】
EEPROM（電気的にデータの消去及び書き換えが可能な不揮発性メモリ）の一種としてフラッシュメモリが知られている。フラッシュメモリは、ワード線とビット線の交点に位置するセルに電荷を蓄積し、データの書き込み（プログラムともいう）を行うメモリである。電荷がセルに蓄積されている以上、電源をOFFにしてもデータは失われない。しかしフラッシュメモリにおいては、リードディスターブエラー（read disturb error）といって、所定物理ブロックの所定ページのデータが読み出されると、同一ブロック内の他のページのセルに記憶されているデータが変化してしまう現象が生じる場合がある。これは、データの読み出し対象となった選択セルからデータが読み出される際、非選択セル（データ読み出し対象となっていないページのセル）の浮遊ゲートに電荷が注入されてしまい、これにより非選択セルが弱くプログラムされたのと同じ状態になるためであり、読み出し回数が増えるに従い、より多くのメモリセルが影響を受ける。このためフラッシメモリでは、通常、読み出し回数制限値がベンダーによって指定されている。例えば、現行製品で、SLC（Single-Level-Cell）では、１０万回乃至１００万回、MLC（Multi-Level-Cell）では、１万回乃至１０万回である。一般に、データ書き換え回数が増大すると、読み出し回数はより制限される。
【０００３】
（従来技術の問題点）
このリードディスターブエラーに対処するため、該エラーが生じない特別な回路を予め用意したり、電荷の変化したセル単体を個別に探し出してこれを補正しエラーデータが読み出されないようにする方法などが提案されているが、回路や処理が複雑で高価となり、実用的ではない。
【０００４】
また、他の対処方法としては、物理ブロックごとにデータ読み出し回数をカウントし、ベンダー指定のデータ読み出し回数制限値に至ったときにそのブロックのリフレッシュを都度実行している。即ち、読み出し対象となった当該ブロックがデータ読み出し回数制限に至ったとき、データ読み出しの直前又は直後にリフレッシュを実行している。このため、複数の物理ブロックが一度にデータ読み出し制限に至ったとき、連続したリフレッシュ実行のために一定のデータ転送レートが保証できずユーザに不快感を与えたり、ホストに読み出されるデータが一時的に中断しプレイに支障が生じるといった問題が生じる。
【特許文献１】特開１０−２２８７８３
【特許文献２】特開２００２−１５０７８３
【特許文献３】特開２００４−３２６８６７
【特許文献４】特許第３６４１０６６号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、このような問題点に鑑みてなされたものであり、NAND型フラッシュメモリデバイスのリードディスターブエラーの防止とｂａｄブロック処理を効率よく行うメモリの管理方法を提供することにある。その他の目的は、明細書、図面、特に特許請求の範囲から自ずと明らかとなろう。
【課題を解決するための手段】
【０００６】
上記課題解決のため、本発明は、請求項記載の新規な特徴的構成を採用する。
【発明を実施するための最良の形態】
【０００７】
以下、本発明を実施するための最良の形態について図面を用いて説明するが、本発明は特許請求の範囲内において種々の形態を採ることができ、下記実施形態に限定されないことはいうまでもない。
【０００８】
（システム基本構成）
図１に示すように、本発明は、NAND型フラッシュメモリ２２（本明細書において、特に必要のない限り、単に“フラッシュメモリ”という）と該フラッシュメモリ２２に対するデータの書き込みや読み出しの実行、その他の制御を行うコントローラ２１を有するフラッシュメモリデバイス２（特許請求の範囲の「記憶装置」に相当）において実行される。本願では、フラッシュメモリデバイス２と、該デバイス２にデータの書き込みや読み出しのコマンドを発行するホスト１からなる構成をシステムという。コントローラ２１には、必要に応じ作業領域としてのRAM２３を接続する。RAM２３はコントローラ２１の内部に設けてもよい。システムは、例えばMPEG音楽プレーヤのように、所定の機器として一体に構成されていてもよいし、ホスト１がPC（パーソナルコンピュータ）で構成され、フラッシュメモリデバイス２がSSD（Solid State Drive）としてPCとUSBインターフェースやIDEインターフェースで接続される構成であってもよい。その他、遊技機等所定の機器に搭載される基板上に構成されてもよい。
【０００９】
フラッシュメモリ２２は、ユーザデータ領域、予備領域、管理領域を有する。ユーザデータ領域は、主記憶領域とも呼ばれる。ユーザデータ領域を構成する物理ブロックは、論理ブロックと対応する関係を有し、その関係は論理／物理ブロック管理テーブルで管理され、その対応関係が変わると、随時該テーブルで更新される。予備ブロック（予備領域を構成するブロック）は、ユーザデータ領域を構成する物理ブロックがｂａｄブロックとなったときに使用される代替ブロックである。また、フラッシュメモリ２２には空きブロックが少なくとも一つ確保される。この空きブロックは、通常、ユーザデータ領域の物理ブロックにデータを上書きするときに使用されるブロックである。この場合空きブロックは、予備ブロック同様、論理ブロックアドレスと関連付けされない。なお、詳細は後述するが、本願のリフレッシュは、この空きブロック若しくは予備ブロックのいずれかを使用して実行する。
【００１０】
図２は、フラッシュメモリ２２のメモリアレイを示している。図示するように、ユーザデータ領域は物理ブロック番号“０”から“４０４１”で構成され、物理ブロック番号“４０４２”が空きブロック、物理ブロック番号“４０４３”から“４０９１”までが予備ブロックで構成されている。その他、物理ブロック番号“４０９２”から“４０９５”までの管理領域が存在する。コントローラ１１は、空きブロックの物理ブロック番号及び予備ブロックの物理ブロック番号を把握するため、それぞれ不図示の空きブロックテーブル、予備ブロックテーブルで管理する。論理／物理ブロック管理テーブル、空きブロックテーブル、予備ブロックテーブルを総称して、ブロック管理テーブルというものとする。
【００１１】
図３はリフレッシュ管理テーブルの内容例を表している。リフレッシュ管理テーブルは、システム稼動中RAM２３において、物理ブロックごとのデータ読み出し回数や消去回数を記憶するものである。システム稼動中はその内容が適宜更新される。システムの電源が遮断されるとき、その内容は管理領域に保存される。システム稼動の度にこれが繰り返される。
【００１２】
フラッシュメモリデバイス２がホスト１からデータ読み出しコマンドを受けると、コントローラ２１は、ホスト１から指定されたアドレスを論理ブロックアドレスとして、その論理ブロックアドレスに対応する物理ブロックアドレスを論理／物理ブロック管理テーブルから割り出してデータを読み出す。そしてその都度、リフレッシュ管理テーブルに、当該物理ブロックに対するデータ読み出し回数を記録する（図３参照）。また、物理ブロックのデータを消去するごとに消去回数をインクリメントして記録する。消去はそのブロック内のデータの書き換えを含む概念である。
【００１３】
物理ブロックのデータ読み出し回数制限値（図４のベンダー指定値）は、一般に過去の消去回数に依存する。即ち、過去にデータ消去された回数が多いほど、読み出し回数は制限される。このデータ読み出し回数制限値は、例えば図４に示すように、物理ブロックの消去回数が０回から９９９回までは１,０００,０００回（図４のフェーズＡ）、消去回数が１,０００回から９,９９９回までは３００,０００回（図４のフェーズＢ）、消去回数が１００００回から９９,９９９回までは１００,０００回（図４のフェーズＣ）と設定される。
【００１４】
従来、そのブロックのデータ読み出し回数が制限値に至ったとときに、読み出しを実行する直前又は直後に、その都度リフレッシュを実行していたが、read時間が増大するという問題があった。そこで本発明では、リフレッシュ管理テーブルを用い、後述する方法により、対象となるブロックを時分割に一括してリフレッシュし、read時間の増大を防止するものである。
【００１５】
まず、リフレッシュを実行する基準（コントローラ閾値）をベンダー指定値より小さい値に設定することにより、データ読み出し回数がベンダー指定値に至る前に有効にリフレッシュを実行できるようにした。図４のフェーズＡ，Ｂ，Ｃのベンダー指定値とコントローラ閾値の関係を参照されたい。データ読み出し回数が、コントローラ閾値に至ると、コントローラ２１（正確にはコントローラ２１のCPU（図示せず））は、リフレッシュ管理テーブルの当該物理ブロックにフラグ“Low”（特許請求の範囲の第１種フラグに相当）を設定する（図３）。
【００１６】
システムの電源が遮断される際は、リフレッシュ管理テーブルの内容を管理領域に不揮発的に記録し、次回システム稼動時に再度RAM２３に展開し、過去の記録を利用する。システム稼動中に何らかの理由により電源が遮断される可能性があるので、所定時間間隔ごとに（例えば１０分おき）、リフレッシュ管理テーブルの内容を、管理領域に記録してもよい。
【００１７】
以下、本発明のリフレッシュ方法の実施形態例を説明する。
（第1実施例：オートリフレッシュ）
オートリフレッシュは、デバイス２に電源投入直後、ホスト１よりコントローラ２１に、ENABLE/DISABLE AUTO REFRESH コマンド（デバイス提供者で定義するユニークコマンド。以下、単にオートリフレッシュコマンドという。）を発行しておき、所定時刻及び／又は所定時間間隔にリフレッシュを実行させる方法である。デバイス２に定常的に電源が投入されているようなシステムの場合は、所定時刻ごと（秒単位で設定可能）にリフレッシュを実行してもよい。またはコントローラ２１に、ENABLE/DISABLE AUTO REFRESH コマンドで実行すると同様なプログラム（ファームウエア）を予めインストールしておいてもよい。これらオートリフレッシュは、フラッシュメモリデバイス２が有するタイマー（図示せず）を利用して自動的にリフレッシュを実行する方法であるため、本願では以下、タイマーイベントという。オートリフレッシュの場合、特許請求の範囲のステップｄ）、ｅ）、ｆ）がタイマーイベントで実行される。
【００１８】
Ａ.フラグ“Low”の設定されている物理ブロックが一つだけ存在する場合
オートリフレッシュコマンドまたはファームウエアにより、タイマーイベントが、ホスト１がメディアアクセスをしていないときに発生した場合は、コントローラ２１はリフレッシュ管理テーブルをサーチし、フラグ“Low”が設定されている物理ブロックが一つ存在することが確認された場合、コントローラ２１は当該フラグが設定されている物理ブロックのリフレッシュを直ちに実行する。尚、メディアアクセスとは、ホストがコマンドを発行することにより、フラッシュメモリ２２からデータの読み出しや、データの書き込みを行うことをいう。
【００１９】
タイマーイベントが、ホスト１がメディアアクセスしているときに発生した場合は、一の物理ブロックに対するメディアアクセスの処理を完了し次のメディアアクセスの処理開始前に割り込んでリフレッシュを実行する。
【００２０】
Ｂ.フラグ“Low”の設定されている物理ブロックが二つ以上存在する場合
タイマーイベントが、ホスト１がメディアアクセスを実行していないときに発生した場合であって、リフレッシュ管理テーブルでフラグ“Low”が設定されている物理ブロックが二つ存在することが確認された場合、コントローラ２１は当該フラグが設定されている物理ブロックを一つずつ、即ち、ブロック単位でリフレッシュする。まずデータ消去回数が、図４のフェーズＡ，Ｂ，Ｃのいずれに該当するかを判定し、データ読み出し回数がそれぞれの閾値（コントローラ閾値）を超えた値が大きいもの順にリフレッシュを実行する。又は、データ読み出し回数がベンダー指定値に近いもの順にリフレッシュを実行する。図４では、フェーズＡ，Ｂ，Ｃのそれぞれで、ベンダー指定値とコントローラ閾値の差がすべて同じであるため、上記２例において実質的に同一の結果となるが、フェーズＡ，Ｂ，Ｃのそれぞれで、ベンダー指定値とコントローラ閾値の差を異なる値に設定した場合は、前者の実行方法を採った場合と後者の実行方法を採った場合とではリフレッシュの順番が異なる。このような方法を採ることにより、リードディスターブエラーを生起する可能性の高い順番で物理ブロックがリフレッシュされるため、リードディスターブエラーの発生をより確実に防止することができる。
【００２１】
Ｃ.タイマーイベントがホスト１がメディアアクセスしているときに発生した場合、若しくはホスト１のメディアアクセス中にタイマーイベントが発生した場合であって、フラグ“Low”の設定されている物理ブロックが複数存在することが確認された場合。
この場合は、物理ブロック単位で、時分割にリフレッシュを実行する。即ち１物理ブロック当たりのタイマーイベントの処理は、その開始から終了までせいぜい１００ｍｓ（ミリ秒）程度であるから、リフレッシュ間隔（一の物理ブロックのリフレッシュ開始から次の物理ブロックのリフレッシュ開始まで）を、例えば１秒以上に設定する。そしてコントローラ２１は、まず一の物理ブロックに対するメディアアクセスの処理の完了後、次のブロックのメディアアクセスの処理開始前に割り込んで１物理ブロックのリフレッシュを実行する。その後1秒経過してから同様なタイミングで次の物理ブロックのリフレッシュを実行する。
【００２２】
このようにすれば、リフレッシュ対象ブロックが複数存在する場合でも、ホスト１にデータを転送している最中にデータが途切れてユーザに不快感を与えたり、プレイに支障を生じさせることがない。特に、フラッシュメモリ２２に記憶されているデータが音楽や動画などのコンテンツであって、多数の物理ブロックが一度にコントローラ閾値に達するような事態が生じても、物理ブロックごと時分割にリフレッシュを実行することにより、一定のデータ転送レートを担保することができ、ユーザに支障を来たすことがない。
【００２３】
以下、図を用いて、フラグ“Low”の設定された物理ブロックに対するリフレッシュのやり方について説明する。
【００２４】
図３に示す通り、リフレッシュフラグの設定されている物理ブロックが、物理ブロック番号“２”、“６”及び“９９９９”の三つあるとする。データ消去回数は、物理ブロック番号“２”も物理ブロック番号“６”もどちらも０回で、フェーズＡに該当する。データ読み出し回数は、物理ブロック番号“２”は990,100回、物理ブロック番号“６”は990、515回であり、コントローラ閾値990,000に対して、物理ブロック番号“６”が、より閾値を超えているため、リフレッシュは物理ブロック番号“６”が、物理ブロック番号“２”に優先する。また物理ブロック番号“９９９９”のデータ消去回数は1050回であるためフェーズＢに該当し、コントローラ閾値290,000に対して読み出し回数が290,050回であり、コントローラ閾値を越える回数は、物理ブロック番号“２”より少ないから、リフレッシュは物理ブロック番号“２”が優先する。以上より、物理ブロック番号“６”、“２”、“９９９９”の順にリフレッシュを実行することになる。
【００２５】
物理ブロック番号“６”のリフレッシュに当たっては、まず空きブロック（物理ブロック番号“４０４２”）を新たなデータ書き込み用のブロックとして選定する。次にリフレッシュ対象物理ブロックである物理ブロック番号“６”から１ページずつフラッシュメモリ２２内のバッファにすべてのデータを読み出し、続いてバッファから前記新たなデータ書き込み用ブロックに全てのページのデータを１ページずつプログラム（書き込み）する。そして元のブロックである物理ブロック番号“６”のデータを一括消去する（図５参照）。１ブロック分のデータすべてを読み出してから新たなデータ書き込み用ブロックへ書き込むのではなく、バッファへの読み出しと新たなデータ書き込み用ブロックへの書き込みを、ページ単位で、順次行ってもよい。この場合、バッファの容量は１ページ分で足りる。
【００２６】
そして、元の物理ブロックである物理ブロック番号“６”に対応していた論理ブロック番号を、新たなデータ書き込み用ブロックとなった物理ブロック番号（“４０４２”）に新たに対応させて、論理/物理ブロック管理テーブルを更新するとともに、物理ブロック番号“６”を空きブロックとして、空きブロック管理テーブルを更新する（“４０４２は空きブロック管理テーブルから削除する”）。また、リフレッシュ管理テーブル上で、消去した元のブロックである物理ブロック番号“６”のデータ読み出し回数をゼロに変更し、データ消去回数を1つインクリメントする。以上で物理ブロック番号“６”に対するリフレッシュが完了する。物理ブロック番号“６”のリフレッシュが終了したら、以降、物理ブロック番号“２”、”９９９９”についても、上記例に倣ってリフレッシュを実行する。なお新たなデータ書き込み用のブロックは、予備ブロックの一つ(例えば、物理ブロック番号“４０４３”)から選定してもよい。この場合は、元の物理ブロックに対応していた論理ブロック番号を、新たなデータ書き込み用ブロックとなった物理ブロック番号（“４０４３”）に新たに対応させて、論理／物理ブロック管理テーブルを更新するとともに、元の物理ブロック番号を空きブロックとして、空きブロック管理テーブルを更新する（“４０４２は空きブロック管理テーブルから削除する”）。
【００２７】
尚、必ずしもホスト１への高速なデータ転送が要求されない場合は、リフレッシュ対象物理ブロックである物理ブロック番号“６”から１ページずつエラー訂正しながらRAM２３（リフレッシュ管理テーブルを記録する領域意外の領域を利用）にすべてのデータを読み出して格納し、続いてRAM２３から前記新たなデータ書き込み用ブロックに全てのページのデータを１ページずつプログラム（書き込み）してもよい。こうすれば、ブロックの潜在的なエラーをすべて訂正するので、データの信頼性が高まる。この場合もバッファへの読み出しと新たなデータ書き込み用ブロックへの書き込みを、ページ単位で、順次行ってもよいことは言うまでもない。
【００２８】
従来リフレッシュは、データの読み出し中にイレギュラーに必要となり、ホストへのデータのread時間が増大していたが、本発明では、リフレッシュ管理テーブルを用いて、所定のタイミングで一括して行うので、斯かる不都合は生じない。また従来のリフレッシュのやり方は、１）その物理ブロックのデータをフラッシュメモリ２２内のバッファに待避し、次に２）当該ブロックのデータを消去し、その後３）待避しておいたデータを元のブロックに再書き込みしている。この場合、当該ブロックのデータを消去した後であってかつバッファに待避しておいたデータを元のブロックに再書き込み完了する前に何らかの原因で電源が遮断された場合、本来のデータが消失してしまう危険性がある。この点、上記実施形態例によれば、新たなデータ書き込み用ブロックにデータが完全にコピーされるまで、元のブロックのデータは消去されないから、リフレッシュ中のどの段階で電源が遮断されても本来のデータが失われることがない。尚本発明においても、上記１）乃至３）のやり方でリフレッシュしてもよいことは言うまでもない。その場合は元のブロックを再利用するので、ブロック管理テーブルのいずれも変更しなくてよい。
【００２９】
（第２実施例:ホストからのコマンド発行によるリフレッシュ）
上述のオートリフレッシュの他、メディアアクセスを実行しないときに、ホスト１がコントローラ２１に以下のようなコマンドを発行してリフレッシュを実行してもよい。
１．GET REFRESH PENDING STATUS コマンド
本コマンドは、コントローラ２１に対し、リフレッシュ管理テーブルをサーチさせ
て、リフレッシュフラグ（“Low”又は後述する“High”）が設定されている物理ブロックの総数をホスト１に通知させるものである。
２．EXECUTE
REFRESH コマンド
本コマンドは、コントローラ２１にリフレッシュを実行させるものである。リフレ
ッシュが終了するとコマンドが終了する。リフレッシュを実行する物理ブロック数を指定できる。
３．SAVE
REFRESH TABLE コマンド
本コマンドは、コントローラ２１に、RAM２３上のリフレッシュ管理テーブルの内
容を、管理領域に保存させるものである。リフレッシュ管理テーブルの保存が終了するとコマンドが終了する。
【００３０】
ホスト１のドライバには、GET REFRESH PENDING STATUS コマンドを発行して、リフレッシュの必要なブロックの有無及びその数を把握し、リフレッシュの必要なブロックがあれば、ホスト１がメディアアクセスしていないときにコントローラ２１にEXECUTE REFRESHコマンドを発行するようプログラムしておく。
【００３１】
このようにすれば、ホスト１は必要に応じて適宜コントローラ２１にリフレッシュを実行させることができる。即ち、コントローラ２１は、必要なときにのみ、効果的にリフレッシュを実行することができる。またSAVE REFRESH TABLE コマンドにより、必要に応じ、コントローラ２１にRAM２３上のリフレッシュ管理テーブルの内容をフラッシュメモリのリフレッシュ管理テーブルに不揮発的に保存させることができる。
【００３２】
以上のように、本発明は上記第１実施例、第２実施例のいずれのリフレッシュ方法を採用しても、リフレッシュを実行すべき物理ブロックが複数存在する場合、一定のタイムインターバルを以って複数の物理ブロックを時分割でリフレッシュするため、音楽や動画などのコンテンツの読み出しが途中で途切れ、ユーザに不快感を与えたり、プレイに支障を生じることがない。また、メディアアクセスする必要のないタイミングに上記ベンダーコマンドを発行するようホスト１のドライバにプログラムしておくことにより、コントローラ２１の動作効率をより向上させることができる。
【００３３】
（ｂｉｔエラーの対応及びｂａｄブロックの処理）
フラッシュメモリデバイスは、データ書き込みの際、ユーザデータに対してエラーチェックコード（ECC）を付加して書き込んでいる。データ読み出し時にはデコーダがこのエラーチェックコードを基に、読み出したデータにエラー（本願ではこれを「ｂｉｔエラー」という）がないかをチェックし、ｂｉｔエラー数がコントローラの能力値（例えば８ｂｉｔ）以内であれば、コントローラ２１内のエラー訂正回路（図示せず）がｂｉｔエラーを訂正し、正しいデータをホスト１に送出する。ｂｉｔエラーは、データの消去、リードディリスターブ、経年変化（データリテンション）、セルの物理的欠陥（たとえば絶縁膜の劣化、破壊）などに起因して生じる。ｂｉｔエラー数がコントローラ能力値を超えると、その欠陥セルを含むブロックは、もはやエラー訂正ができず、使用に耐えないｂａｄブロックとなる。
【００３４】
そこで本発明では、安全性を担保するため、コントローラ２１の能力値と同じかそれより小さい所定値（例えば７ｂｉｔ）を予め閾値（「ｂａｄブロック閾値」という）として設定しておき、ｂｉｔエラーがｂａｄブロック閾値に至ったセルを含むブロックをｂａｄブロックと看做し、お蔵入りとするものである。
【００３５】
以下、この処理を簡単に説明する。まず、読み出したデータのｂｉｔエラー数がｂａｄブロック閾値未満であったときは、通常通り、ｂｉｔエラーを訂正してデータをホスト１に送出する。ｂｉｔエラーがｂａｄブロック閾値以上かつコントローラの能力値以下であったときは、ｂｉｔエラーを訂正したデータをホスト１に送出するとともに、リフレッシュ管理テーブルの当該エラーを含む物理ブロックに、第２種フラグ“High”を設定する。図３には、物理ブロック番号“４”において、読み出し回数３００回でフラグ“High”が設定されている様子が示されている。
【００３６】
タイマーイベントが発生し、若しくはリフレッシュコマンドがホスト１から発行され、コントローラ２１がリフレッシュ管理テーブルをサーチした結果、フラグ“High”が設定された物理ブロックが確認されたときは、予備ブロック（ここでは物理ブロック番号“４０４４”）を新たなデータ書き込み用ブロックに割り当てる。次にｂａｄブロックと看做された物理ブロックの全データを１ページずつエラー訂正しながらRAM２３に一旦格納し、前記予備ブロックに書き込む。ｂａｄブロックと看做された物理ブロックの全データをフラッシュメモリ内２２のバッファに読み出して、エラー訂正することなく予備ブロックに書き込んでもよいが、エラー訂正して書き込む方がデータの信頼性が高まる。データの書き込み処理が完了したら、元の物理ブロックの論理ブロック番号と予備ブロックの物理ブロック番号“４０４４”を新たに対応させて、論理／物理ブロック管理テーブルを更新する。このとき元のブロックの物理ブロック番号がブロック管理テーブルから削除されるので、元の物理ブロックは以降使用されることはない。
【００３７】
そして、リフレッシュ管理テーブル上において、ｂａｄブロックと看做された物理ブロックアドレス“４”のフラグ“High”をNoneにする。この場合、元ブロックは以降使用しないので、ブロックに記憶されているデータは消去しなくてよい。以上で、フラグ“High”の設定された物理ブロック番号“４”に対する処理が完了する（本願では以上の処理を“ｂａｄブロック処理”というものとする）。
【００３８】
尚、万一ｂｉｔエラー数がコントローラ能力値を超えた場合は、エラー訂正ができないため、コントローラ２１はホスト１にエラーを返すことになるが、ｂａｄブロックと看做すための前記ｂａｄブロック閾値を、アプリケーションや使用環境に応じて適切な値に設定することにより、斯かる事態の発生を防ぐことができる。
【００３９】
そして、コントローラ２１がリフレッシュ管理テーブルをサーチしたとき、フラグ“Low”の設定されている物理ブロックとフラグ“High”の設定されている物理ブロックが並存する場合は、フラグ“High”の設定されている物理ブロックに対するｂａｄブロック処理を、フラグ“Low”の設定されている物理ブロックのリフレッシュに優先して実行する。
【００４０】
上記第1実施例（オートリフレッシュ）において、タイマーイベントが、ホストがメディアアクセス実行中に発生した場合若しくはタイマーイベントの処理中にホスト１からメディアアクセスコマンドが発行された場合であって、その時点でリフレッシュ管理テーブル上に、フラグ“Low”及び／又は“High”の設定されている物理ブロックが複数存在する場合は、フラグ“High”の設定されている物理ブロックの処理を優先しつつ、フラグ“High”及び／又は“Low”の設定されている物理ブロックに対する処理を、前述した方法（段落００２１参照）と同様に、ブロック単位で時分割に実行する。
【００４１】
また上記第２実施例（ホストからのコマンド発行によるリフレッシュ）において、コントローラ２１がリフレッシュの実行中にさらにホスト１からメディアアクセスコマンドが発行された場合であって、その時点でリフレッシュ管理テーブル上に、フラグ“Low”及び／又は“High”の設定されている物理ブロックが複数存在する場合も、フラグ“High”の設定されている物理ブロックの処理を優先しつつ、フラグ“High”及び／又は“Low”の設定されている物理ブロックに対する処理を、前述した方法（段落００２１参照）と同様に、ブロック単位で時分割に実行する。
【００４２】
尚、万一ｂｉｔエラー数がコントローラ能力値を超えた場合は、エラー訂正ができないため、コントローラ２１はホスト１にエラーを返すことになるが、ｂａｄブロックと看做すための前記ｂａｄブロック閾値を、アプリケーションや使用環境に応じて適切な値に設定することにより、斯かる事態の発生を防ぐことができる。
【００４３】
以下、コントローラ２１がホスト１からコマンドを発行された場合の処理（リフレッシュコマンドに基づきリフレッシュを行う場合の例）を、図７乃至図９のフローチャートを用いて説明する。はじめに図７を用いて説明する。コントローラ２１は常時ホスト１からコマンドが発行されたかを確認する（SP１）。コマンドが発行された場合、その発行されたコマンドがデータの上書きを伴う書き込みコマンド又は消去コマンドか確認し（SP２）、ｙｅｓの場合は、当該コマンドを実行し（SP３）、リフレッシュ管理テーブルの当該コマンドが実行された物理ブロックの“消去回数”を１つインクリメントする（SP４）。初期値は０である。発行されたコマンドがデータの上書きを伴う書き込みコマンド又は消去コマンドでない場合は、引き続きデータの読み出しコマンドであるか確認し（SP５）、ｙｅｓの場合は※１（図８）へ進む。即ち、そのコマンドに従ってデータの読み出しを実行し（SP６）、データを読み出したページを含む物理ブロックの“読み出し回数”を一つインクリメントする（SP７）。そして、そのブロックに係る読み出し回数がコントローラ閾値以上であるか確認し（SP８）、ｙｅｓであれば、リフレッシュ管理テーブルにフラグ“Low”を設定する（SP９）。そして読み出したデータにｂｉｔエラーがないか確認し（SP１０）、ない場合はデータをそのままホストに送出する（SP１１）。ｂｉｔエラーがあった場合は，ｂａｄブロック閾値未満であるか確認し（SP１２）、ｙｅｓであればエラー訂正した上で（SP１３）、データをホストに送出する（SP１１）。ｂｉｔエラーがｂａｄブロック閾値以上であった場合はコントローラ能力値以下であるかを確認し（SP１４）、ｙｅｓであればリフレッシュ管理テーブルの当該物理ブロックにフラグ“High”を設定し（SP１５）、エラー訂正した上で（SP１３）、データをホストに送出する（SP１１）。仮にｂｉｔエラーがコントローラ能力値を超えていた場合はホストにエラーを返し（SP１６）、※３（図８参照）に進む。
【００４４】
SP５でnoであった場合は、※２へ進む（図９参照）。即ち、ホストから発行されたコマンドがリフレッシュコマンドであるか確認し（SP１７）、noであれば当該処理を実行して（SP１８）、※３に進む。ｙｅｓであればリフレッシュ管理テーブルをサーチし（SP１９）、フラグ（“High”及び／又は“Low”）が設定されているかを確認する（SP２０）。そしてｙｅｓであれば、フラグ“High”のブロックに対する処理を、フラグ“Low”のブロックに優先して行う（SP２１）。そして、論理/物理ブロック管理テーブルを更新し（SP２２）、※３へと進む。
【００４５】
以上のように、上記実施形態例では、リードディスターブエラー発生の未然防止（リフレッシュ）と、種々の原因により発生したｂａｄブロックの処理を、リフレッシュ管理テーブルを用いて一括して処理することができるため、従来にはないシステムパフォーマンスを提供することができる。
【００４６】
尚、RAM２３は、コントローラ２１に外付けする場合、Random Access Memoryの他、DRAM、SDRAM（synchronous DRAM）でもよい。
【００４７】
また、図６に示ように、リフレッシュ管理テーブルは、工場出荷時に物理ブロックごとに異なるデータ読み出し回数（ダミー）を記録しておいてもよい。このようにすれば、専らシーケンシャルリード（sequential read）されるアプリケーションの場合、リフレッシュをさらに分散して実行することができる。
【００４８】
また、本システムが遊戯機に搭載される場合、一日のプレイ中に何度もコンテンツデータが読み出される。コンテンツは例えば、図柄である。このコンテンツデータは複数の物理ブロックに跨ってファイルとして管理されている場合もある（これをコンテンツファイルという）。この場合、一日における当該図柄の読み出し回数を記憶しておくとともに、システム電源をオンしたときに、一日における当該図柄の読み出し回数の最大値や毎日の平均値を求め、当日にフラグ“Low”が設定され得る状況であるかを予想し、設定される可能性がある場合は、システム本稼動前にリフレッシュを前倒しで実行してもよい(フィードフォワード制御)。或いは、システム稼動終了後に翌日にフラグ“Low”が設定されるかを予想し、設定される可能性がある場合、電源OFF前にリフレッシュを実行してもよい。このようにすれば、プレイ途中のリフレッシュを極力少なくすることができ、システムパフォーマンスを一層向上させることができる。パチンコ遊技機やスロットマシンのように、一日中稼動する遊技機の場合は特に有効である。
【００４９】
以上説明したように、本発明は、リフレッシュをデータ読み出し回数制限値（ベンダー閾値）に至る前に実行するとともに、リフレッシュとｂａｄブロック処理の両者をjust in time方式ではなくリフレッシュ管理テーブルを使用して集中して実行するため、リードディステーブエラーの防止とｂａｄブロック処理を有効且つ効率的に行うことができる。またホストからの継続したデータ読み出し要求がなされた場合でも一定のタイムインターバルで時分割にリフレッシュやｂａｄブロック処理を実行するので、データ転送レートを保証でき、ユーザに不快感を与えたり、ホストに転送されるデータが一時的に中断しプレイに支障が生じることを防止することができる。ホストがメディアアクセスしないときにコマンドを発行してリフレッシュを実行する場合は、データ転送レートをより一層保証することができる。
【図面の簡単な説明】
【００５０】
【図１】本発明の実施形態を実行するシステムの基本構成例である。
【図２】フラッシュメモリの領域例である。
【図３】リフレッシュ管理テーブルの内容例である。
【図４】データ消去回数範囲（フェーズ）ごとの、データ読み出し回数のベンダー指定値及びコントローラ閾値の関係例である。
【図５】リフレッシュの実行方法例である。
【図６】工場出荷時（初期状態）のリフレッシュ管理テーブル例である。
【図７】コントローラが実行する処理のフローチャート例である。
【図８】コントローラが実行する処理のフローチャート例（続き）である。
【図９】コントローラが実行する処理のフローチャート例（続き）である。
【符号の説明】
【００５１】
１ ホスト
２ フラッシュメモリデバイス
２１ コントローラ
２２ NAND型フラッシュメモリ
２３ RAM
【特許請求の範囲】
【請求項１】
ユーザデータ領域と予備領域と管理領域を有するメモリと該メモリを制御するコントローラからなる記憶装置における、当該コントローラが行うメモリの管理方法であって、
ａ）物理ブロック毎のデータ読み出し回数、消去回数を、リフレッシュ管理テーブルに随時記録、更新するステップと、
ｂ）物理ブロックのデータ読み出し回数が各物理ブロックのデータ消去回数のフェーズごとに異なる値に設定されている各閾値に至ったとき、リフレッシュ管理テーブル上の当該物理ブロックに第１種フラグを設定するステップと、
ｃ）メモリから読み出されたデータにｂｉｔエラーがあった場合であって、該ｂｉｔエラー数が予め定めた閾値以上であったとき、リフレッシュ管理テーブルの当該エラーのあった物理ブロックに第２種フラグを設定するステップと、
ｄ）リフレッシュ管理テーブルをサーチするステップと、
ｅ）ステップｄ）において第１種フラグの設定された物理ブロックが確認されたとき、そのブロックをリフレッシュするステップと、
ｆ）ステップｄ）において第２種フラグの設定された物理ブロックが確認されたとき、その物理ブロックのデータを予備ブロックに書き写し、ブロック管理テーブルを更新するステップ、
を有することを特徴とするメモリの管理方法。
【請求項２】
リフレッシュは、第１種フラグの設定された物理ブロックのデータをバッファにコピーするとともに、元のデータを消去してから前記バッファにコピーしたデータを元のブロックに書き戻し、リフレッシュ管理テーブル上の当該物理ブロックのデータ読み出し回数を“０”に変更することを有することを特徴とする請求項１記載のメモリの管理方法。
【請求項３】
リフレッシュは、第１種フラグの設定された物理ブロックのデータを空きブロック若しくは予備ブロックにコピーするとともに、元のデータを消去して、ブロック管理テーブルを更新し、リフレッシュ管理テーブル上の当該物理ブロックのデータ読み出し回数を“０”に変更することを特徴とする請求項１記載のメモリの管理方法。
【請求項４】
ステップｄ）乃至ステップｆ）を、タイマーイベントとして実行することを特徴とする請求項１記載のメモリの管理方法。
【請求項５】
システムに電源投入後、ホストからコントローラにタイマーイベントを発生させるコマンドを予め発行しておくことを特徴とする請求項４記載のメモリの管理方法。
【請求項６】
タイマーイベントを発生させるファームウエアをコントローラに予めプログラムしておくことを特徴とする請求項４記載のメモリの管理方法。
【請求項７】
ステップｄ）で、第１種フラグの設定されている物理ブロックと第２種フラグ設定されている物理ブロックの両者が存在することが確認されたとき、ステップｆ）をステップｅ）に優先して実行することを特徴とする請求項１乃至請求項６いずれか１項記載のメモリの管理方法。
【請求項８】
ステップｄ）で第１種フラグ及び／又は第２種フラグの設定されている物理ブロックが複数存在する状況下において、コントローラがタイマーイベントとホストのメディアアクセスを同時処理する場合、ステップｅ）及び／又はステップｆ）を所定のタイムインターバルで、当該ブロック単位で実行することを特徴とする請求項７項記載のメモリの管理方法。
【請求項９】
ホストが、メディアアクセスコマンドを発行していないときにステップｄ）を実行させるコマンドを発行し、これにより第１種フラグ及び／又は第２種フラグの設定された物理ブロックがあることが確認された場合は、引き続きコマンドを発行してステップｅ）及び／又はステップｆ）を実行することを特徴とする請求項１乃至請求項３いずれか1項記載のメモリの管理方法。
【請求項１０】
前記ステップｅ）及び／又はステップｆ）を実行させるコマンドの処理中にホストからメディアアクセスコマンドが発行され、その時点で第１種フラグ及び／又は第２種フラグの設定されている物理ブロックが複数存在する場合、それら物理ブロックに対するステップｅ）及び／又はステップｆ）の実行を、所定のタイムインターバルで、当該ブロック単位で実行することを特徴とする請求項９記載のメモリの管理方法。
【請求項１１】
工場出荷時、リフレッシュ管理テーブルの読み出し回数としてダミーデータを予め記録しておくことを特徴とする請求項１乃至請求項１０いずれか１項記載のメモリの管理方法。
【請求項１２】
ユーザデータ領域の読み出し回数を物理ブロック単位で毎日記憶しておくとともに、システム電源をオンしたときに、当該物理ブロック単位の読み出し回数の最大値又は平均値を求めて、当日に第１種フラグが設定される物理ブロックが存在するか否かを予想し、設定される可能性がある物理ブロックは、システム本稼動前にリフレッシュを前倒しで実行することを特徴とする請求項１乃至請求項１１いずれか１項記載のメモリの管理方法。
【請求項１３】
ユーザデータ領域の読み出し回数を物理ブロック単位で毎日記憶しておくとともに、システム稼動終了後、当該物理ブロック単位毎の読み出し回数の最大値又は平均値を求めて、翌日に第１種フラグが設定される物理ブロックが存在するか否かを予想し、設定される可能性がある物理ブロックは、システム電源をOFFする前にリフレッシュを前倒しで実行することを特徴とする請求項１乃至請求項１１いずれか１項記載のメモリの管理方法。
【請求項１】
ユーザデータ領域と予備領域と管理領域を有するメモリと該メモリを制御するコントローラからなる記憶装置における、当該コントローラが行うメモリの管理方法であって、
ａ）物理ブロック毎のデータ読み出し回数、消去回数を、リフレッシュ管理テーブルに随時記録、更新するステップと、
ｂ）物理ブロックのデータ読み出し回数が各物理ブロックのデータ消去回数のフェーズごとに異なる値に設定されている各閾値に至ったとき、リフレッシュ管理テーブル上の当該物理ブロックに第１種フラグを設定するステップと、
ｃ）メモリから読み出されたデータにｂｉｔエラーがあった場合であって、該ｂｉｔエラー数が予め定めた閾値以上であったとき、リフレッシュ管理テーブルの当該エラーのあった物理ブロックに第２種フラグを設定するステップと、
ｄ）リフレッシュ管理テーブルをサーチするステップと、
ｅ）ステップｄ）において第１種フラグの設定された物理ブロックが確認されたとき、そのブロックをリフレッシュするステップと、
ｆ）ステップｄ）において第２種フラグの設定された物理ブロックが確認されたとき、その物理ブロックのデータを予備ブロックに書き写し、ブロック管理テーブルを更新するステップ、
を有することを特徴とするメモリの管理方法。
【請求項２】
リフレッシュは、第１種フラグの設定された物理ブロックのデータをバッファにコピーするとともに、元のデータを消去してから前記バッファにコピーしたデータを元のブロックに書き戻し、リフレッシュ管理テーブル上の当該物理ブロックのデータ読み出し回数を“０”に変更することを有することを特徴とする請求項１記載のメモリの管理方法。
【請求項３】
リフレッシュは、第１種フラグの設定された物理ブロックのデータを空きブロック若しくは予備ブロックにコピーするとともに、元のデータを消去して、ブロック管理テーブルを更新し、リフレッシュ管理テーブル上の当該物理ブロックのデータ読み出し回数を“０”に変更することを特徴とする請求項１記載のメモリの管理方法。
【請求項４】
ステップｄ）乃至ステップｆ）を、タイマーイベントとして実行することを特徴とする請求項１記載のメモリの管理方法。
【請求項５】
システムに電源投入後、ホストからコントローラにタイマーイベントを発生させるコマンドを予め発行しておくことを特徴とする請求項４記載のメモリの管理方法。
【請求項６】
タイマーイベントを発生させるファームウエアをコントローラに予めプログラムしておくことを特徴とする請求項４記載のメモリの管理方法。
【請求項７】
ステップｄ）で、第１種フラグの設定されている物理ブロックと第２種フラグ設定されている物理ブロックの両者が存在することが確認されたとき、ステップｆ）をステップｅ）に優先して実行することを特徴とする請求項１乃至請求項６いずれか１項記載のメモリの管理方法。
【請求項８】
ステップｄ）で第１種フラグ及び／又は第２種フラグの設定されている物理ブロックが複数存在する状況下において、コントローラがタイマーイベントとホストのメディアアクセスを同時処理する場合、ステップｅ）及び／又はステップｆ）を所定のタイムインターバルで、当該ブロック単位で実行することを特徴とする請求項７項記載のメモリの管理方法。
【請求項９】
ホストが、メディアアクセスコマンドを発行していないときにステップｄ）を実行させるコマンドを発行し、これにより第１種フラグ及び／又は第２種フラグの設定された物理ブロックがあることが確認された場合は、引き続きコマンドを発行してステップｅ）及び／又はステップｆ）を実行することを特徴とする請求項１乃至請求項３いずれか1項記載のメモリの管理方法。
【請求項１０】
前記ステップｅ）及び／又はステップｆ）を実行させるコマンドの処理中にホストからメディアアクセスコマンドが発行され、その時点で第１種フラグ及び／又は第２種フラグの設定されている物理ブロックが複数存在する場合、それら物理ブロックに対するステップｅ）及び／又はステップｆ）の実行を、所定のタイムインターバルで、当該ブロック単位で実行することを特徴とする請求項９記載のメモリの管理方法。
【請求項１１】
工場出荷時、リフレッシュ管理テーブルの読み出し回数としてダミーデータを予め記録しておくことを特徴とする請求項１乃至請求項１０いずれか１項記載のメモリの管理方法。
【請求項１２】
ユーザデータ領域の読み出し回数を物理ブロック単位で毎日記憶しておくとともに、システム電源をオンしたときに、当該物理ブロック単位の読み出し回数の最大値又は平均値を求めて、当日に第１種フラグが設定される物理ブロックが存在するか否かを予想し、設定される可能性がある物理ブロックは、システム本稼動前にリフレッシュを前倒しで実行することを特徴とする請求項１乃至請求項１１いずれか１項記載のメモリの管理方法。
【請求項１３】
ユーザデータ領域の読み出し回数を物理ブロック単位で毎日記憶しておくとともに、システム稼動終了後、当該物理ブロック単位毎の読み出し回数の最大値又は平均値を求めて、翌日に第１種フラグが設定される物理ブロックが存在するか否かを予想し、設定される可能性がある物理ブロックは、システム電源をOFFする前にリフレッシュを前倒しで実行することを特徴とする請求項１乃至請求項１１いずれか１項記載のメモリの管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００９−２２４０１２（Ｐ２００９−２２４０１２Ａ）
【公開日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願番号】特願２００８−２５７３０２（Ｐ２００８−２５７３０２）
【出願日】平成２０年１０月２日（２００８．１０．２）
【出願人】（５９４０９６９６６）株式会社ハギワラシスコム (32)
【Ｆターム（参考）】
【公開日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願日】平成２０年１０月２日（２００８．１０．２）
【出願人】（５９４０９６９６６）株式会社ハギワラシスコム (32)
【Ｆターム（参考）】
[ Back to top ]