JP3503448B2 - フラッシュ型メモリ及びその管理装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、フラッシュ型メ
モリ及びその管理装置にかかり、更に具体的には、フラ
ッシュ型メモリの効率的な管理手法の改良に関するもの
である。

【０００２】

【背景技術】一般にフラッシュタイプのフロ−ティング
ゲ−トトランジスタを含む電気的に消去可能なプログラ
マブル読出専用メモリ（ＥＥＰＲＯＭ）は、現在市場で
容易に入手できる。これらのいわゆるフラッシュメモリ
は、機能・性能面でＥＰＲＯＭメモリと類似した不揮発
メモリであり、メモリ内に分割されているブロックを消
去する回路内プログラマブル動作を可能にするという機
能を更に有する。フラッシュメモリでは、以前に書き込
まれたメモリの領域を前もって消去することで、その書
き換えが行われる。

【０００３】典型的なコンピュ−タシステムでは、オペ
レ−ティングシステム（以下、単に「ＯＳ」という）の
プログラムがそのシステムのデ−タ記憶装置のデ−タ管
理を担う。ＯＳプログラムとの互換性を達成するために
必要かつ十分であるデ−タ記憶装置のアトリビュ−ト
（属性）は、デ−タ記憶装置のいかなる位置からもデ−
タを読み出すことができ、これにデ−タを書き込むこと
ができることである。しかし、フラッシュメモリの場
合、デ−タが既に書き込まれている領域には、その領域
のデ−タを消去しなければデ−タを書き込むことはでき
ない。このため、フラッシュメモリは、典型的な既存の
ＯＳプログラムとは互換性がない。

【０００４】このような点に着目し、既存のＯＳプログ
ラムによってフラッシュメモリを管理することを可能に
するソフトウエアが先行技術において提案されている。
この先行技術のプログラムでは、フラッシュメモリを
「書込み１回読出し複数回」の装置として動作させる
か、「書込み複数回読出し複数回」の装置として動作さ
せている。前者は、以前に書き込まれているメモリ場所
を再利用することはできない装置であり、補助記憶装置
や拡張記憶装置として使用できる。後者は、以前に書き
込まれているメモリ領域を再利用可能とし、その領域中
にはフラッシュメモリの書換回数を少なくするような制
御を持つ補助記憶装置（半導体ファイル記憶装置）があ
る。

【０００５】

【発明が解決しようとする課題】しかしながら、以上の
ような背景技術には、次のような不都合がある。 (1)上述のような先行技術に見られる装置によれば、フ
ラッシュメモリを使用した拡張記憶装置上では書換回数
を少なくなるような制御構造を持たずに実行プログラム
を動作させている。つまり、フラッシュメモリに対して
新たにデ−タの書換えを行うときは、全ブロックを一括
して消去し、その後、デ−タを記憶させる必要がある。
また、マルチタスク，マルチスレッド，マルチプロセス
に代表される並列実行プログラムやデ−タの共有あるい
は占有という管理を行う場合において、一般のＭＭＵ
（メモリ管理ユニット）を駆使してフラッシュメモリを
ブロック（ペ−ジ）毎に管理する方式では、書換回数の
管理と書換回数の低減を図ることは困難である。

【０００６】(2)フラッシュメモリを使用した拡張記憶
装置上でプログラムの実行を可能とする装置にはないも
のの、フラッシュメモリの書換回数を少なくするような
制御構造を持つ装置として補助記憶装置（半導体ファイ
ル記憶装置）がある。補助記憶装置において書換回数を
少なくするためにその情報（書換回数テ−ブル）を異な
るメモリ上に記憶する方式である。しかし、実行プログ
ラムを主記憶装置にロ−ドすることなく、フラッシュメ
モリ上で動作させるプログラムにおいて、単純に同一フ
ラッシュメモリ上に記憶する方式では、ブロック間にま
たがるデ−タを無駄なく完全に連続的な配置を可能にす
ることは困難である。

【０００７】この発明は、以上の点に着目したもので、
その目的は、フラッシュメモリを使用した拡張記憶装置
上でフラッシュメモリの書換回数を少なくするような制
御構造を持つ場合に、主記憶装置に実行プログラムをロ
−ドすることなく拡張記憶装置上でプログラムの実行を
可能とすることである。他の目的は、同一のフラッシュ
メモリを使用し、補助記憶装置として書換回数を少なく
する制御構造を持ちながら、マルチプロセッシング，マ
ルチスレッド，マルチタスクといった高度なプログラム
の実行環境においても、メモリ管理装置によって、安全
に実行プログラムのモジュ−ルやデ−タファイルの管理
の実現を可能とすることである。更に他の目的は、同一
フラッシュメモリ上で、拡張記憶装置および補助記憶装
置の混在を可能とするファイル管理技術を提供すること
である。

【０００８】

【課題を解決するための手段】本発明のフラッシュ型メ
モリは、ブロック単位で記憶内容を消去できるフラッシ
ュ型メモリが第１，第２，第３のブロックを含んでお
り、第１のブロックは、そのブロックの管理情報を記憶
するヘッダ領域と、ブロック単位に分割されたデータフ
ァイルを格納する記憶領域とを備えており、第３のブロ
ックは、実行プログラムファイルが格納されたブロック
の管理情報を記憶するヘッダ領域と、ブロックごとに分
割された実行プログラムファイルを格納する記憶領域を
備えており、第２のブロックは、第３のブロックに隣接
し、実行プログラムファイルが、第３のブロックの実行
プログラムファイルを格納する記憶領域の容量を越えた
場合、第３のブロックに実行プログラムファイルが分割
され格納された続きのデータを格納する記憶領域を備え
ていることを特徴とする。

【０００９】

【００１０】本発明のフラッシュ型メモリの管理装置
は、隣接する複数の前記第２及び第３のブロックに対し
て実行プログラムファイルを割り当てるとともに、それ
ら実行プログラムファイルが割り当てられたブロックの
管理情報を前記第３のブロックに格納する手段を備えた
ことを特徴とする。

【００１１】

【００１２】

【００１３】

【００１４】この発明の前記及び他の目的，特徴，利点
は、以下の詳細な説明及び添付図面から明瞭になろう。

【００１５】

【発明の実施の形態】以下、本発明の実施の形態につい
て詳細に説明する。本形態は、例えば図１に示すよう
に、プロセッサ１０，フラッシュメモリ１２およびその
制御装置１４を含む拡張もしくは補助の記憶装置，ＲＡ
Ｍ（主記憶装置）１６を含むコンピュ−タシステムに適
用される。このようなシステムで、同一フラッシュメモ
リを使用して、実行プログラムモジュ−ルとデ−タファ
イルのデ−タを共存させるとともに、デ−タの書換回数
をできる限り低減するデ−タの格納方法と管理・制御の
ための装置を得ようとするものである。

【００１６】まず、実行プログラム領域とデ−タ領域を
管理するため、フラッシュメモリ１２の管理単位をその
最小イレ−ス（消去）単位である１ブロックとする。そ
して、この最小単位であるブロック内に、実行プログラ
ム領域とデ−タ領域の混在を認めないこととする。各ブ
ロックには、実行プログラム領域もしくはデ−タ領域
と、そのブロックを管理する情報を持つヘッダ領域とが
存在する。

【００１７】ここで、デ−タ領域に割り当てようとする
ブロックには、そのブロックのヘッダ領域内にデ−タの
属性を持つことを宣言する。同様に、実行プログラム領
域に割り当てようとするブロックには、そのブロックの
ヘッダ領域内に実行プログラムの属性を持つことを宣言
する。ただし、この実行プログラム領域については、１
つのブロックに１つのヘッダ領域が必ずしも必要という
ことではない。すなわち、連鎖する複数ブロックを連続
的に実行プログラム領域として確保したい場合は、確保
ブロック数をヘッダ領域内で宣言する。これによって、
宣言した連鎖する複数ブロックは、ヘッダ情報を持たな
くてもよい。つまり、実行プログラムのメモリ配置とし
て、１つのヘッダ領域により複数の連続するブロックに
実行プログラム領域を確保する。一方、デ−タ領域は１
つのブロック内にヘッダ領域と混在することになる。こ
のデ−タ領域内には、該当するブロックに関する情報を
付加する。

【００１８】図２には、本形態におけるソフトウエアの
基本構造の一例が示されている。同図のように、ＯＳ２
０やアプリケ−ションソフト２２とのソケットインタ−
フェ−スとして、いわゆるドライバ層２４に相当する部
分にフラッシュ管理マネ−ジャ２６を設ける。このフラ
ッシュ管理マネ−ジャ２６は、本形態のシステム用ドラ
イバと考えることができる。このフラッシュ管理マネ−
ジャ２６によって、ブロック情報の管理やデ−タのリ−
ド／ライトの制御が行なわれる。

【００１９】例えば、図３［Ａ］に示すように、ブロッ
ク消去がｉバイト単位で可能で、かつブロック数がｎ＋
１（１６進数）個あるフラッシュメモリが１つあるとす
る。これら各ブロックを、物理ブロックと呼ぶことにす
る。そして、各物理ブロックに、アドレスの低い方から
高い方へ順に物理ブロックナンバを「０」から「ｎ」ま
で割り振る。図示の例では、図の上方がアドレスが低
く、物理ブロック０，物理ブロック１，物理ブロック
２，……，物理ブロックｎとなっている。

【００２０】ここで、それぞれの物理ブロックを管理し
ている情報のヘッダ領域としてｊバイト分を確保したと
すると、各物理ブロックに割り当てられる実行プログラ
ム領域あるいはデ−タファイル領域のサイズは、ｉ−ｊ
バイトとなる。そして、同一ブロックの記憶領域には、
実行プログラム領域とデ−タファイル領域の混在は認め
ないことにする。この様子を示すと、図３［Ｂ］のよう
になる。例えば、最上位の物理ブロック０には、ｊバイ
トのヘッダ領域３０Ａと、ｉ−ｊバイトの記憶領域３０
Ｂが存在する。次の物理ブロック１には、ｊバイトのヘ
ッダ領域３１Ａと、ｉ−ｊバイトの記憶領域３１Ｂが存
在する。以下の物理ブロックについても同様である。

【００２１】次に、実行プログラム領域の確保例につい
て、図４を参照しながら説明する。図４［Ａ］には、連
続する８個の物理ブロック０〜７を実行プログラム領域
として割り当て、それ以外の物理ブロック８〜ｎをデ−
タファイル領域として割り当てた例である。上述したよ
うに、複数の連続する物理ブロックに確保された実行プ
ログラム領域は、１つのヘッダ領域によって管理され
る。一方、デ−タファイル領域は、例え複数の連続する
物理ブロックに確保されたとしても、各ブロック毎にヘ
ッダ領域によって管理される。従って、図４［Ａ］の例
では、実行プログラム領域３２の物理ブロックヘッダ３
２Ａは物理ブロック０にのみ存在し、物理ブロック１〜
７には存在しない。そして、後述するように、物理ブロ
ック１〜７の管理情報等は、物理ブロック０のヘッダ領
域３２Ａにまとめられることになる。一方、物理ブロッ
ク８〜ｎにはデ−タファイル領域３８Ｂ〜３ｎＢがそれ
ぞれ確保されるが、各ブロックにそれぞれヘッダ領域３
８Ａ〜３ｎＡが存在し、これらによってブロック毎に管
理される。

【００２２】次に、図４［Ｂ］の例は、物理ブロック０
をデ−タファイル領域として割り当て、物理ブロック１
〜Ａを実行プログラム領域として割り当て、それ以後は
デ−タファイル領域として割り当てた例である。図４
［Ｃ］の例は、物理ブロック０〜ｎ−９をデ−タファイ
ル領域に、物理ブロックｎ−８〜ｎ−３を実行プログラ
ム領域に、それ以後をデ−タファイル領域にそれぞれ割
り当てた例である。このように、連続して確保された実
行プログラム領域は一つのヘッダ領域によって管理され
る。そして、物理ブロック数の制限や固定したアドレス
配置にすることはない。しかし、デ−タファイル領域
は、連続して確保されたとしても、各ブロック毎に管理
される。

【００２３】図５に示す例では、実行プログラム領域が
分割して配置されている。まず、図５［Ａ］の例では、
物理ブロック０〜７に実行プログラム領域(1)が割り当
てられており、物理ブロック８にはデ−タファイル領域
が割り当てられている。そして、物理ブロック９〜Ｆ−
１に実行プログラム(2)が割り当てられており、物理ブ
ロックＦ以後はデ−タファイル領域用に確保されてい
る。この例でも、連続する実行プログラム領域は、一つ
のヘッダ領域で管理されている。

【００２４】図５［Ｂ］では、物理ブロック０がデ−タ
ファイル領域用に割り当てられており、物理ブロック１
〜８が実行プログラム領域(1)に割り当てられている。
そして、物理ブロック９〜ｎ−９までがデ−タファイル
領域用に割り当てられており、それ以後最後までが実行
プログラム領域(2)として割り当てられている。図５
［Ｃ］では、物理ブロック０，１がデ−タファイル領域
として割り当てられており、物理ブロック２〜４が実行
プログラム領域(1)に割り当てられている。そして、そ
の後の物理ブロック５〜ｎ−９がデ−タファイル領域と
して割り当てられており、物理ブロックｎ−８〜ｎ−１
が実行プログラム領域(2)として割り当てられており、
最後の物理ブロックｎがデ−タファイル領域に割り当て
られている。これら図５では、実行プログラム領域とし
て２つの領域(1)，(2)が指定されている例を示してい
る。しかし、本形態では、実行プログラム領域を更に複
数の領域で配置することが可能である。

【００２５】次に、物理ブロックのヘッダ領域について
説明する。物理ブロックヘッダには、実行プログラム領
域用とデ−タファイル領域用とがある。この２種類の領
域を判断するために、ヘッダは共通部分の構造を持つこ
とが望ましい。そこで、物理ブロックヘッダの共通する
部分の構造を、例えば次のように割り当てる。

【００２６】(1)状態（有効／無効／遷移中／初期化完
了）を示すフラグ (2)実行プログラム領域／デ−タファイル領域を示すマ
−カ−フラグ (3)連続予約ブロックの領域数 (4)ブロックの消去回数 (5)ブロックの消去した順番を示す番号（イレ−スシ−
ケンスナンバ） (6)ブロックを初期化した時刻 (7)ブロック領域名

【００２７】これらのうち、まず(1)のフラグについて
説明する。フラッシュ管理マネ−ジャ２６（図２参照）
は、各物理ブロックヘッダの内容を読み、フラッシュメ
モリがどのように管理されているかを把握する。フラッ
シュメモリのメモリセル内のビットデ−タは、論理値の
「１」→「０」への変化の処理時間は比較的短いが、
「０」→「１」への変化は、一度ブロックイレ−ス又は
イレ−スをしなければならず、長時間を要する。つま
り、１ビットのデ−タの書換えを行なうために、そのブ
ロック内のデ−タを一時待避させるとともに、ブロック
イレ−ス後に書き戻す必要があり、処理時間としては大
きい。

【００２８】そこで、実際には、状態を示すフラグを利
用して物理ブロックの状態を管理することになる。すな
わち、上述した書換えに伴うオ−バ−ヘッドを軽減すた
め、物理ブロックヘッダ内にその物理ブロックが有効な
状態か，それとも無効な状態か，初期化が完了した状態
か，有効な状態から無効な状態への遷移状態か，といっ
た状態をそれぞれの物理ブロック毎に認識し、デ−タの
書込み，デ−タの無効化，物理ブロックのイレ−ス，物
理ブロックの初期化などの操作を行なう。

【００２９】次に、(2)のマ−カ−フラグは、該当する
物理ブロックがデ−タファイル領域に割り当てられた
か、それとも、実行プログラム領域に割り当てられたか
を示すフラグである。これによって、実行プログラム領
域に指定されたとき、(3)の連続予約ブロック数に実行
プログラムとして後に続くブロックの数を指定する。し
かし、デ−タファイル領域に指定されているときは、連
続予約ブロック数を０とする。

【００３０】次に、(4)のブロックの消去回数には、各
ブロックを消去（ブロックイレ−ス）した回数を記録す
る。ブロックイレ−スするときは、記録されている以前
の消去回数を一時的に保持し、ブロックイレ−ス終了
後、一時的に保持している以前の消去回数に１インクリ
メントしてデ−タを格納する。

【００３１】次に、(5)のブロックの消去した順番を示
す番号は、同じときにどの順番に物理ブロックのイレ−
スを行なったかを判別するためのものである。ある物理
ブロックをブロックイレ−スし、その後、他の物理ブロ
ックのブロック消去回数が同じものがあれば、その消去
回数のブロックのイレ−スシ−ケンスナンバ−に１イン
クリメントしたものを該当ブロックヘッダのイレ−スシ
−ケンスナンバ−に格納する。すなわち、消去回数が同
じものが複数ブロック存在するとき、それらの中の最大
のイレ−スシ−ケンスナンバの値に１インクリメントし
て該当ブロックヘッダ内のイレ−スシ−ケンスナンバに
格納する。

【００３２】次に、(6)のブロックを初期化した時刻に
は、該当する物理ブロックをブロックイレ−スしたとき
の時刻を記入する。なお、リアルタイムクロックを持た
ないシステムの場合は不要である。

【００３３】次に、(7)のブロック領域名は、実行プロ
グラムやデ−タファイルの中でそのブロックに割り当て
た固有の名称である。

【００３４】新たにブロックの割り当てを行なう際、全
体のブロックが効率よく、つまり特定のブロックに偏ら
ず、消去回数がすべてのブロックで均一化されるように
管理するために、上述した管理情報が利用される。ま
ず、フラッシュ管理マネ−ジャ２６は、新たに物理ブロ
ックを割り当てるとき、消去回数の少ないものに対して
優先的に割り当てを行なう。もし、消去回数が同じブロ
ックがあるとき、その中でイレ−スシ−ケンスナンバの
もっとも若い番号のものを割り当てる。最も若いイレ−
スシ−ケンスナンバのブロックは、消去した時刻が最も
古いものである。また、リアルタイムクロックを持つシ
ステムでは、イレ−スシ−ケンスナンバの代わりにその
クロックを使用する。すなわち、消去回数が同じブロッ
クがあるとき、その中の物理ブロック内のもっとも古い
時刻を持つブロックを割り当てる。このように、イレ−
スシ−ケンスナンバあるいはリアルタイムクロックのう
ちのいずれか一方をもてば、少しでも効率よくブロック
の割り当てを均一化することができる。

【００３５】実行プログラムの配置は、物理ブロックヘ
ッダの後からその領域内において、実行プログラムデ−
タをＲＯＭの場合と同じように配置することによって行
なう。これは、ＯＳ２０に依存する部分が大きいため、
従来の方法によって対応することになる。

【００３６】一方、デ−タファイルの配置は、フラッシ
ュ管理マネ−ジャ２６によって行われる。図６［Ａ］に
示すように、デ−タファイルは、物理ブロックヘッダ４
０Ａの領域を除く記憶領域４０Ｂに格納されることにな
る。デ−タの格納構造として、デ−タファイル内の論理
的なデ−タレコ−ドをブロッキングし、図６［Ｂ］に示
すように、デ−タレコ−ドヘッダ４２Ａ，デ−タレコ−
ドフッダ４２Ｃを付随させた形でデ−タレコ−ド４２Ｂ
のパケット４２を構成する。ブロッキングの方法として
は、固定長レコ−ド，可変長レコ−ド，スパンドレコ−
ドがあり、本形態ではいずれの手法であってもよい。こ
のブロッキングは、ＯＳ２０やアプリケ−ションソフト
２２に依存することが多いため、システム上、フラッシ
ュ管理マネ−ジャ２６がブロッキングの方法を決定して
制御する。

【００３７】また、デ−タレコ−ドヘッダ４２Ａ，フッ
ダ４２Ｃには、線形リスト構造を持たせるようにする。
デ−タレコ−ドの方法によっては、ブロック領域名の最
適な利用方法が異なる。システム設計する際、ブロック
領域名として、パ−ティション名，デ−タファイル名，
ディレクトリ名などのように、最適なものを割り当てる
ようにする。最適なブロック領域名は、デ−タレコ−ド
の方法に依存することが多い。

【００３８】デ−タファイルの論理的なデ−タレコ−ド
４２Ｂは、上述したようにデ−タレコ−ドパケット４２
として、割り当てられた物理ブロックのデ−タファイル
領域４０Ｂに格納される。図６［Ｂ］にはその様子が示
されており、デ−タレコ−ドパケット(1)〜(n)が、ｉ−
ｊバイトのデ−タファイル領域４０Ｂ中に格納される。
フラッシュ管理マネ−ジャ２６は、デ−タレコ−ドパケ
ット４２の管理と物理ブロック４０Ｂによる管理という
２重の管理を行なう。

【００３９】次に、物理ブロックの初期化の手順につい
て説明する。フラッシュ管理マネ−ジャ２６は、フラッ
シュメモリが初期化されていなければ、まず最初に各物
理ブロックを初期化する。初期化する場合は、一度すべ
てのブロックをイレ−スし、各物理ブロックのブロック
ヘッダに初期化完了フラグ，消去回数（１回），イレ−
スシ−ケンスナンバあるいは、初期化時刻などの情報を
格納する。次に、通常は、実行プログラムやデ−タファ
イルを格納するため、各物理ブロックの領域を宣言（確
保）する。つまり、実行プログラム領域やデ−タファイ
ル領域を示すマ−カ−フラグ，連続予約ブロックの領域
数の情報を格納する。このときに、ブロックの領域名を
割り当るようにしてもよい。また、後でブロックの領域
名を割り当てるのであれば、フラッシュ管理マネ−ジャ
２６がその対応を行なう。

【００４０】次に、デ−タファイルを格納するときの手
順を説明する。物理ブロックヘッダの有効フラグをＯＮ
にし、その後ブロッキングされたデ−タレコ−ドをデ−
タ領域内に順次格納して行く。デ−タレコ−ドはデータ
領域に追記していくことになるが、デ−タレコ−ドを書
き換えたい場合は、フラッシュメモリの特徴からその部
分を書き換えることはオ−バ−ヘッドが大きい。

【００４１】そこで、旧論理デ−タレコ−ドから新論理
デ−タレコ−ドへのデ−タ格納は、旧デ−タレコ−ドを
無効とし、新たにデ−タレコ−ドを追記していく方法で
行う。無効となったデ−タレコ−ドは、デ−タレコ−ド
ヘッダ内に無効フラグを持たせることによって、フラッ
シュ管理マネ−ジャ２６が無効と判断できる。物理ブロ
ックのデ−タ領域内のデ−タレコ−ドパケットのすべて
が無効となった場合は、その物理ブロックヘッダ内の無
効フラグをＯＮすることによって、フラッシュ管理マネ
−ジャ２６はこの物理ブロックをブロックイレ−スする
ことができる。ブロックイレ−スが完了すると、前述の
ブロックヘッダの初期化を行なう。

【００４２】次に、実行プログラムを格納するときの手
順を説明する。最初に実行プログラム領域として複数ブ
ロックを確保するときは、まず、物理ブロックヘッダ内
の有効フラグ，実行プログラム領域を示すマ−カ−フラ
グ，予約領域ブロック数の各情報を格納する。これによ
り、実行プログラム領域内に実行プログラムをＲＯＭ化
したデ−タを格納する。

【００４３】以上をシステムとして運用し、その途中結
果として、デ−タファイル領域の書換回数と実行プログ
ラム領域の書換回数と比較する。そして、大幅な回数の
開きがあれば、現在配置されている領域を変更し、デフ
ラグメンテ−ションを行なうことが望ましい。フラッシ
ュ管理マネ−ジャ２６は、それぞれの領域を管理してい
るためデフラグメンテ−ション操作における動的配置に
対応でき、システムとして矛盾を起こす心配もない。こ
れらを行なうことで効率的な領域配置を実現できる。ま
た、結果として運用時間を延ばし、フラッシュメモリの
書換寿命（回数ではなく時間）を延ばすこともできる。
なお、フラッシュメモリによっては、ライト（書込）操
作中に他のオペレ−ションができないチップが存在す
る。このようなときは、タスク，スレッドのようなプロ
グラミング技法により、排他制御を行なうようにする。

【００４４】図７には、フラッシュメモリに対する物理
ブロックヘッダの格納例が示されている。図７［Ａ］の
例は、６４Ｋバイトを消去ブロック単位とするフラッシ
ュメモリで、ブロック数がｎ＋１個あるシステムであ
る。各物理ブロックの先頭には、図７［Ｂ］に示すよう
に、各物理ブロックの管理情報であるヘッダ領域とし
て、２５６バイトが割り当てられている。上述したよう
に、デ−タファイルの場合には、該当する物理ブロック
内に必ず物理ブロックヘッダを付随させる。しかし、実
行プログラムファイルの場合はその限りではない。以
下、本形態の実施例について説明する。

【００４５】（1）実施例１ この実施例１は、ブロックシ−ケンスナンバを用いる例
である。本例のファイル管理装置では、図８［Ａ］に示
すように、ブロック消去が６４Ｋバイト単位で可能な２
Ｍ×８ビットのフラッシュメモリが使用される。図８
［Ａ］に示すように、各ブロックに「０」から「１Ｆ」
と順に番号を付ける。このようなフラッシュメモリに対
して、図５［Ａ］のように実行プログラム領域を連続領
域として確保したとすると、図８に［Ｂ］に示すように
なる。当然、実行プログラム領域(1)に領域指定されて
いる物理ブロック１〜７には物理ブロックヘッダはな
い。同様に、実行プログラム(2)に領域指定されている
物理ブロック１０〜Ｅには、物理ブロックヘッダはな
い。

【００４６】そこで、本実施例では、図９に示すよう
に、１バイト目から１８バイト目までを共通のデ−タ構
造をもつことにする。これにより、この共通部分をフラ
ッシュ管理マネ−ジャ２６によってスキャンすれば、全
体の構造を把握することができる。そして、次の１９バ
イト目から実行プログラム領域あるいはデ−タファイル
領域に割り当てられた内容を追記していけばよい。

【００４７】共通部分の内容を順に説明すると、まず１
バイト目には、図１０［Ａ］に示すように、有効／遷移
中／無効，初期化完了状態，予約のフラグがある。これ
らのうち、有効／遷移中／無効のフラグは、このブロッ
ク領域が有効状態か，それとも有効から無効になる遷移
中（過渡期）の状態か，完全に無効になった状態かを示
す。初期化完了状態のフラグは、ブロックのイレ−ス後
にブロックヘッダの初期化（フォ−マット）が完了した
ことを指し示す。予約のフラグは、システムを拡張する
ときに使用するための予備フラグである。実際のビット
の割付例を示すと、表１［Ａ］のようになる。

【００４８】

【表１】

【００４９】次に、図１０［Ｂ］を参照してブロックイ
レースの手順を説明する。フラッシュ管理マネ−ジャ２
６の判定により、ブロックイレ−ス命令が出されたとき
（図１０［Ｂ］の５０）、次の状態として旧ブロックヘ
ッダの消去回数などを一時保存し（５２）、このブロッ
クのブロックイレ−スを行なう（５４）。ブロックイレ
−スを行なった直後、イレースされたブロックの記憶エ
リアのデ−タ値は、すべてＦＦｈとなっている（５
６）。この後すぐに、フラッシュ管理マネ−ジャ２６が
初期化（フォ−マット）操作（５８）によって、ビット
４が０となり、この記憶エリアのデ−タ値はＦＦｈから
ＥＦｈに遷移する（６０）。

【００５０】更にその後、このブロックのヘッダに、イ
レ−ス前に一時保存しておいた消去回数に＋１した値を
書き込み、物理ブロックの初期化を行なう。そして、新
たにこのブロックへの使用要求によってフラッシュ管理
マネ−ジャ２６が割り当てを行ったとすると（６２）、
ビット７に０を書き込み、このエリアのデ−タの値はＥ
Ｆｈから６Ｆｈに遷移する（６４）。更に、フラッシュ
管理マネ−ジャ２６がこのブロックの無効要求を認めれ
ば（６６）、ビット６に０を書き込み、このエリアのデ
−タの値は６Ｆｈから２Ｆｈに遷移する（６８）。

【００５１】デフラグメンテ−ションを行なう際、フラ
ッシュ管理マネ−ジャ２６の機能により、物理ブロック
にはコピ−元，コピ−先，ム−ブなどのような遷移中の
状態が存在する。デ−タファイル領域としての物理ブロ
ック内の有効な状態から遷移中の状態にするには（７
０）、ビット５を０にし、このエリアのデ−タの値は６
Ｆｈから４Ｆｈに遷移させればよい（７２）。この遷移
中の状態を存在させることは、遷移に要する時間が少な
くないことの他に、電池の消耗による動作の不安定や、
カ−ド型フラッシュメモリが外されたときなどにおける
安全性を高めるためである。つまり、本発明では、この
遷移段階の状態を管理し、故障・事故などによるデ−タ
の消失を最小限に抑え、復旧させるように構成されてい
る。

【００５２】次に、図９に示す共通部分の２バイト目に
ついて説明する。この２バイト目には、図９に示すよう
に、プログラム／データ，連続予約ブロック領域数のフ
ラグがあり、図１０［Ｃ］，表１［Ｃ］に示すようにな
っている。これらのうち、プログラム／データのマーカ
ーフラグは、実行プログラム，デ−タファイルのいずれ
がそのブロックに割り当てられたかを決定するフラグで
ある。このマ−カ−フラグが０のとき、実行プログラム
領域にこのブロックが指定されたことになる。

【００５３】連続予約ブロック領域数のフラグは、実行
プログラム領域に指定した残りのブロック数が１６進数
で表記されている。しかし、このマ−カ−フラグが１
で、この物理ブロックはデ−タファイル領域として割り
当てているとき、連続予約ブロック数には００００００
０ｂを書く。

【００５４】次に、図９の３〜５バイト目は、表１
［Ｄ］に示すように、そのブロックの消去回数を１６進
で表記している。３バイト目がその回数の下位の桁、４
バイト目がその回数の中位の桁、５バイト目にはその回
数の上位の桁として、それぞれデ−タを格納する。従っ
て、ＦＦＦＦＦＦｈ回がブロック連続の最大数値とな
る。なお、この最大値のとき、更なるインクリメントは
行われない。

【００５５】次に、図９の６バイト目であるが、これ
は、各物理ブロックの消去回数が同じときに、フラッシ
ュ管理マネ−ジャ２６が最適な物理ブロックの割り当て
を行なうために用意されたもので、上述したイレースシ
ーケンスナンバである。このイレ−スシ−ケンスナンバ
は、物理ブロックの消去回数が他の物理ブロックと同じ
ときに、どの順番で物理ブロックの初期化がなされたか
を記録するものである。イレ−スシ−ケンスナンバ−の
割付の流れとして、まず該当する物理ブロックの消去回
数と他のブロックで消去回数で同一のものがなければ、
該当する物理ブロックのイレ−スシ−ケンシナンバは０
ｘ００となる。

【００５６】もし、他のブロックで消去回数が同じもの
があるときは、その中で最も大きいイレ−スシ−ケンス
ナンバを検出し、該当ブロックのイレ−スシ−ケンスナ
ンバには先ほど検出したイレ−スシ−ケンスナンバの値
に１インクリメントした値を記録する。このようなアル
ゴリズムによって、イレースシ−ケンスナンバの割付を
行なう。イレースシーケンスナンバは、フラッシュ管理
マネ−ジャ２６が物理ブロックの割り当てを行なうとき
の判断材料となる。

【００５７】次に、図９の７バイト目から１８バイト目
までは、該当するブロックの領域名を記録する。実行プ
ログラムファイルの場合、パ−ティション名やディレク
トリ名などに利用すると、システム運用が容易になる。
また、デ−タファイルの場合は、デ−タレコード方式に
よって最適となるようなブロック領域名の扱いが考えら
れる。例えば、デ−タレコ−ドの方法が固定長，可変長
レコ−ド，スパンドレコ−ドのようなファイルを二重管
理する場合には、パ−ティション名，ディレクトリ名な
どが適している。しかし、固定長や可変長レコ−ドでフ
ァイルを一元管理する場合には、デ−タファイル名とし
て扱うほうが望ましい。本実施例では、ブロック領域名
は８．３形式で、ＭＳ−ＤＯＳのような表現方法を利用
する。

【００５８】以上のような構造の物理ブロックヘッダを
用いてフラッシュファイル管理システムを実現する。フ
ラッシュ管理マネ−ジャ２６は、ＯＳ２０やアプリケ−
ションソフト２２などの要求により、実行プログラムや
デ−タファイルなどの読み出し，書き込みを制御する。
まず、書き込みに際しては、フラッシュメモリの特徴と
して書き込み遅延の影響がある。このため、オ−バヘッ
ドを少なくして効率よく書き込みを行なうためには、他
のデ−タファイル領域に新たに追記していく方式をとる
ことになる。この方式を実行するためには、書換前の旧
デ−タと書換後の新デ−タが論理的には変更されている
が、物理的には旧デ−タが無効となり、新デ−タが追記
されることになる。

【００５９】つまり、物理的には旧デ−タと新デ−タは
共存するものの、旧デ−タに無効フラグを記すことによ
って論理的に削除することになる。このような動作をフ
ラッシュファイルシステムが繰り返すと、論理的な無効
デ−タが数多く存在することになる。場合によっては、
新規のデ−タファイル領域がなくなる危険性すらある。
このことを避けるために、フラッシュ管理マネ−ジャ２
６は、デ−タの無効化を定期的に検知し、デフラグメン
テ−ションの操作を行なって効率よくデ−タファイル領
域を確保する。

【００６０】デ−タファイル領域としての物理ブロック
の割り当ては、フラッシュ管理マネ−ジャ２６が行な
う。このとき、ＯＳ２０やアプリケ−ションンソフト２
２の要求によってデ−タファイル領域を与えることにな
るが、本実施例のアルゴリズムでは、優先的に消去回数
が少ない物理ブロックに割り当てられる。また、デフラ
グメンテ−ション操作を行なうときなどは、消去回数が
少ないブロックについて優先的にデ−タレコ−ドパケッ
トの無効化を行ない、その物理ブロックのデ−タファイ
ル領域内をすべて無効化することによって、ブロックの
使用回数の均一化が図られる。そしてそれらの中で少し
でも物理ブロックの使用回数を効率的に均一化するた
め、イレ−スシ−ケンスナンバの若いものを優先させ
て、割り当てる物理ブロックやブロックイレ−スの管理
が行われる。

【００６１】フラッシュファイルシステムを運用してい
くと、結果として実行プログラム領域とデ−タファイル
領域の消去回数が大きく違ってくるようになる。そし
て、ある程度消去回数に開きが生じると、フラッシュ管
理マネ−ジャ２６は、実行プログラム領域で使用してい
る物理ブロックとデ−タファイル領域で使用している物
理ブロックとを入れ替え、これによってフラッシュファ
イルシステムの運用寿命の延命化が図られる。

【００６２】読み出しの場合は、フラッシュ管理マネ−
ジャ２６がフラッシュメモリの読み出しを行なうことを
要求し、許可確認後、ブロッキングされたデ−タレコ−
ドパケットを論理的なデ−タレコ−ドとして扱うことに
よって可能となる。また、書き込みの場合、フラッシュ
管理マネ−ジャ２６にフラッシュメモリへの書き込みを
行なうことを要求し、許可確認後、論理的なデ−タレコ
−ドをブロッキングし、デ−タレコ−ドパケット化して
指定エリアに格納する。デ−タの書換えは、物理的にデ
−タレコ−ドパケットを無効化し、新たに追記すること
によって実現する。ただし、物理的にメモリエリアは縮
小する。これらのデ−タのブロッキング方法は、上述し
た通りであり、背景技術により実現されている。

【００６３】物理ブロックのデ−タファイル領域内です
べてのデータが無効化された場合、その物理ブロックヘ
ッダの無効フラグをＯＮとすることによって、その物理
ブロック全体が無効化されたことになる。そして、フラ
ッシュ管理マネ−ジャ２６はこのことを検知し、そのブ
ロックをイレ−スして初期化操作を始める。また、デフ
ラグメンテ−ション操作により、コピ−元のデ−タファ
イルの属する物理ブロックヘッダの遷移中フラグをＯＮ
にする。そして、必要なデ−タが全部コピ−されたな
ら、その物理ブロックヘッダの無効フラグをＯＮにし、
前述のブロックイレ−ス・初期化操作を行なう。遷移中
フラグのＯＮから無効フラグのＯＮまでの間に何らかの
原因による異常な状態があり、システムが再起動したと
きなどには、これらの状態フラグを監視し、解析するこ
とによって、どの状態から停止あるいは異常となったか
を検出することができる。そして、システムを修復・復
旧させるための貴重な情報源となる。

【００６４】フラッシュ管理マネ−ジャ２６は、それぞ
れの物理ブロックの状態を監視，管理していくことにな
る。ＯＳ２０やアプリケ−ションソフト２２の要求に応
じて該当する物理ブロックを割り当て、有効→（遷移
中）→無効→初期化の状態の監視，管理を実行する。そ
して、フラッシュファイルシステムを運用していくと、
各物理ブロックの状態の変化として、初期化→有効，有
効→無効，有効→遷移中，移中→無効，無効→初期化，
初期化→無効などが挙げられる。

【００６５】［初期化→有効］は、物理ブロックが初期
化状態から、その物理ブロックがデ−タファイル領域等
として割り当てられたとき、有効フラグＯＮによって有
効状態となる。

【００６６】［有効→無効］は、デ−タファイルとして
その物理ブロックが有効でデ−タファイル領域内に少な
くとも一つは論理的に有効なデ−タがある状態から、デ
−タファイル領域内がすべて論理的に無効なデ−タとな
り、フラッシュ管理マネ−ジャ２６が、その後この物理
ブロックの無効フラグをＯＮとし、物理ブロックの無効
化を行なう。

【００６７】［有効→遷移中］は、少なくとも一つは存
在する論理的に有効なデ−タレコ−ドパケットを、異な
る物理ブロックのデ−タファイル領域にコピ−すると
き、コピ−元となる物理ブロックに対して遷移中フラグ
をＯＮにする。この状態のとき、デ−タレコ−ドパケッ
トがコピ−されていることになる。

【００６８】［遷移中→無効］は、前述の遷移中の状態
が終了し、物理ブロックが無効となったことを示す。つ
まり、デ−タレコ−ドパケットのコピ−が完了し、フラ
ッシュ管理マネ−ジャ２６が無効フラグをＯＮにする。

【００６９】［無効→初期化］は、物理ブロックが無効
な状態からその物理ブロックをブロックイレ−スし、物
理ブロックヘッダを初期化が完了したとき、フラッシュ
管理マネ−ジャ２６が初期化フラグをＯＮにする。この
とき、物理ブロックヘッダの初期化が完了し、デ−タフ
ァイル領域として使用可能な状態となる。

【００７０】［初期化→無効］は、物理ブロックが初期
化された状態から、その物理ブロックが無効になった状
態を示す。これは、状態として存在する可能性はある
が、システムとしては多用すべきではない。

【００７１】フラッシュ管理マネ−ジャ２６は、各物理
ブロックの状態を管理・監視し、何らかの原因による異
常状態からの脱却後、有効／無効／遷移中／初期化フラ
グを、異常状態以前のデ−タの復元や復旧をするための
情報源とする。つまり、これらの変化状態を考慮するこ
とで、システムの停止や異常が生じたシステムの修復や
デ−タレコ−ドパケットの復元を行なうとき、どの状態
から異常になったかを検出することができる。

【００７２】（2）実施例２ この実施例２は、実施例１のイレースシ−ケンスナンバ
の代わりに初期化した時刻を記録する方法である。すな
わち、図１１にブロックヘッダの構成を示すように、１
９バイト目から２１バイト目までに初期化が行われた年
／月／日／時／分／秒を記録する。実施例１のイレ−ス
シ−ケンスナンバは、同一消去回数のときの初期化され
た順番を指していたが、実施例２では、ブロックの使用
回数の均一化を図るアルゴリズムにおいて、すべての物
理ブロックの使用回数を少しでも効率的に向上させるた
めに、消去回数が同じときは最も古い時刻のものを優先
させることによって、割り当てる物理ブロックやブロッ
クイレ−スの管理が行なわれる。

【００７３】（3）実施例３ この実施例３は、実施例１と実施例２を組み合わせ、イ
レースシ−ケンスナンバと初期化時刻の双方を記録する
方法である。図１２に示すように、６バイト目にイレー
スシーケンスナンバを記録し、１９バイト目から２１バ
イト目までに初期化の年／月／日／時／分／秒を記録す
る。実施例１，実施例２とほとんど同じであるが、ブロ
ックの使用回数の均一化を図るアルゴリズムにおいて、
すべての物理ブロックの使用回数を少しでも効率的に向
上させるために、消去回数が同じときはイレ−スシ−ケ
ンスナンバの若いものから優先させるようにする。ま
た、最も古い初期化時刻の物理ブロックが存在するとき
は、消去回数を他と見比べて効率がよいと判断できると
き、その物理ブロックを優先的に割り当てるアルゴリズ
ムによって、割り当てる物理ブロックやブロックイレ−
スの管理が行なわれる。

【００７４】この発明には数多くの実施形態があり、以
上の開示に基づいて多様に改変することが可能である。
例えば、次のようなものも含まれる。 (1)前記形態はフラッシュメモリに本発明を適用したも
のであるが、他の類似するメモリがフラッシュメモリと
同じ書込み，読出し機能を備えており、かつ、書込前ブ
ロック消去特性を有するメモリであれば、同様に適用可
能である。 (2)フラッシュメモリのイレース単位である物理ブロッ
クは、バイト単位やワード単位の他、どのようなデータ
単位であっても、同様に適用可能である。

【００７５】

【発明の効果】以上説明したように本発明によれば、次
のような効果がある。 (1)フラッショ型メモリを使用した拡張記憶装置上で、
フラッシュ型メモリの書換回数を少なくするような制御
構造を持ち、かつ、主記憶装置に実行プログラムをロ−
ドすることなく、フラッシュ型メモリ上でプログラムの
実行が可能となる。また、書換回数を少なくする制御構
造をもつ補助記憶装置としても、無駄の少ないデ−タ構
造で記憶を行うことが可能となる。

【００７６】(2)各ブロックの書換回数等の情報テ−ブ
ルのためのエリアをブロック内に設けることとしたの
で、別にメモリを設ける必要がなく、コストの削減が可
能となる。特に、拡張記憶装置と補助記憶装置を１つの
フラッシュ型メモリ上で混在させることができ、システ
ムとして省スペ−ス，コスト削減を図ることができる。

【００７７】(3)物理ブロックの有効／遷移中／無効／
初期化という状態フラグをもつこととしたので、コンピ
ュータシステムの異常による停止からの復旧やデ−タの
復元に有効である。

【図面の簡単な説明】

【図１】この発明の一形態を利用したシステムの基本構
成を示す図である。

【図２】一形態におけるソフトウエア構造を示す図であ
る。

【図３】一形態におけるフラッシュメモリ内での物理ブ
ロックの割付を行なったメモリマップを示す図である。

【図４】１つの実行プログラム領域と複数のデ−タファ
イル領域を物理ブロックに割り当てた例を示す図であ
る。

【図５】複数の実行プログラム領域と複数のデ−タファ
イル領域を物理ブロックに割り当てた例を示す図であ
る。

【図６】デ−タファイル領域のデ−タレコ−ドパケット
の例と格納方法の例を示す図である。

【図７】ブロックイレ−スが６４Ｋバイト単位のフラッ
シュメモリを物理ブロック単位に分割して２５６バイト
のブロックヘッダを確保した例を示す図である。

【図８】実施例１で使用しているフラッシュメモリを実
行プログラム領域とデ−タファイル領域に分割したメモ
リマップの例を示す図である。

【図９】実施例１で使用している物理ブロックヘッダの
メモリマップの例を示す図である。

【図１０】実施例１における物理ブロックヘッダの一部
とシ−ケンスを表す図である。

【図１１】実施例２で使用している物理ブロックヘッダ
のメモリマップの例を示す図である。

【図１２】実施例２で使用している物理ブロックヘッダ
のメモリマップの例を示す図である。

【符号の説明】

１０…プロセッサ １２…フラッシュメモリ １４…フラッシュメモリ制御装置 １６…ＲＡＭ ２０…オペレーティングシステム ２２…アプリケーションソフト ２４…ドライバ層 ２６…フラッシュ管理マネージャ ３０Ａ，３１Ａ，３８Ａ，３９Ａ，３（ｎ−１）Ａ，３
ｎＡ，４０Ａ…ヘッダ領域 ３０Ｂ，３１Ｂ，３８Ｂ，３９Ｂ，３（ｎ−１）Ｂ，３
ｎＢ，４０Ｂ…記憶領域 ３２…実行プログラム領域 ４２…データレコードパケット ４２Ａ…データレコードヘッダ ４２Ｂ…データレコード ４２Ｃ…データレコードフッダ

フロントページの続き (56)参考文献 特開 平８−272654（ＪＰ，Ａ) 特開 平６−322795（ＪＰ，Ａ) 特開 平６−250798（ＪＰ，Ａ) 特開 平７−200418（ＪＰ，Ａ) 特開 平８−172373（ＪＰ，Ａ) 特開 平７−160597（ＪＰ，Ａ) 特開 平９−297713（ＪＰ，Ａ) 特開 平６−175917（ＪＰ，Ａ) 特開 平11−96779（ＪＰ，Ａ) 特開 昭59−58699（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 3/06 - 3/08 G06F 12/00 - 12/06 G06F 12/16 G11C 16/02

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】 ブロック単位で記憶内容を消去できるフ
   ラッシュ型メモリが第１，第２，第３のブロックを含ん
   でおり、 第１のブロックは、そのブロックの管理情報を記憶する
   ヘッダ領域と、ブロック単位に分割されたデータファイ
   ルを格納する記憶領域とを備えており、 第３のブロックは、実行プログラムファイルが格納され
   たブロックの管理情報を記憶するヘッダ領域と、ブロッ
   クごとに分割された実行プログラムファイルを格納する
   記憶領域を備えており、 第２のブロックは、第３のブロックに隣接し、実行プロ
   グラムファイルが、第３のブロックの実行プログラムフ
   ァイルを格納する記憶領域の容量を越えた場合、第３の
   ブロックに実行プログラムファイルが分割され格納され
   た続きのデータを格納する記憶領域を備えていることを
   特徴とするフラッシュ型メモリ。
2. 【請求項２】 隣接する複数の前記第２及び第３のブロ
   ックに対して実行プログラムファイルを割り当てるとと
   もに、それら実行プログラムファイルが割り当てられた
   ブロックの管理情報を前記第３のブロックに格納する手
   段を備えたことを特徴とする請求項１記載のフラッシュ
   型メモリの管理装置。