JP3555456B2 - フラッシュ型メモリの管理装置 - Google Patents
フラッシュ型メモリの管理装置 Download PDFInfo
- Publication number
- JP3555456B2 JP3555456B2 JP20335798A JP20335798A JP3555456B2 JP 3555456 B2 JP3555456 B2 JP 3555456B2 JP 20335798 A JP20335798 A JP 20335798A JP 20335798 A JP20335798 A JP 20335798A JP 3555456 B2 JP3555456 B2 JP 3555456B2
- Authority
- JP
- Japan
- Prior art keywords
- block
- area
- program
- blocks
- header
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Read Only Memory (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
- Memory System (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、フラッシュ型メモリの管理装置にかかり、更に具体的には、フラッシュ型メモリの管理の効率化に関するものである。
【０００２】
【従来の技術】
一般にフラッシュタイプのフローティングゲートトランジスタを含む電気的に消去可能なプログラマブル読出専用メモリ（ＥＥＰＲＯＭ）は、市場で容易に入手することができる。これらのいわゆるフラッシュメモリは、機能・性能面でＥＰＲＯＭメモリと類似した不揮発メモリであり、メモリ内を分割するブロックを消去する回路内プログラマブル動作を可能にするという機能を更に有する。フラッシュメモリでは、以前に書き込まれたメモリの領域を前もって消去することで、その書き換えが行われる。
【０００３】
典型的なコンピュータシステムでは、オペレーティングシステム（以下、単に「ＯＳ」という）のプログラムがそのシステムのデータ記憶装置のデータ管理を担う。ＯＳプログラムとの互換性を達成するために必要かつ十分であるデータ記憶装置のアトリビュート（属性）は、データ記憶装置のいかなる位置からもデータを読み出すことができ、これにデータを書き込むことができることである。しかし、フラッシュメモリの場合、データが既に書き込まれている領域には、その領域のデータを消去しなければデータを書き込むことはできない。このため、フラッシュメモリは、典型的な既存のＯＳプログラムとは互換性がない。
【０００４】
このような点に着目し、既存のＯＳプログラムによってフラッシュメモリを管理することを可能にするソフトウエアが先行技術において提案されている。この先行技術のプログラムでは、フラッシュメモリを「書込み１回読出し複数回」の装置として動作させるか、「書込み複数回読出し複数回」の装置として動作させている。前者は、以前に書き込まれているメモリ場所を再利用することはできない装置であり、補助記憶装置や拡張記憶装置として使用できる。後者は、以前に書き込まれているメモリ領域を再利用可能とし、その領域中にはフラッシュメモリの書換回数を少なくするような制御を持つ補助記憶装置（半導体ファイル記憶装置）がある。
【０００５】
このような従来技術によれば、フラッシュメモリを使用した拡張記憶装置上では書換回数を少なくなるような制御構造を持たずに実行プログラムを動作させている。つまり、フラッシュメモリに対して新たにデータの書換えを行うときは、全ブロックを一括して消去し、その後、データを記憶させる必要がある。また、マルチタスク，マルチスレッド，マルチプロセスに代表される並列実行プログラムやデータの共有あるいは占有という管理を行う場合において、一般のＭＭＵ（メモリ管理ユニット）を駆使してフラッシュメモリをブロック（ページ）毎に管理する方式では、書換回数の管理と書換回数の低減を図ることは困難である。
【０００６】
フラッシュメモリを使用した拡張記憶装置上でプログラムの実行を可能とする装置にはないものの、フラッシュメモリの書換回数を少なくするような制御構造を持つ装置として補助記憶装置（半導体ファイル記憶装置）がある。これは、補助記憶装置において書換回数を少なくするためにその情報（書換回数テーブル）を異なるメモリ上に記憶する方式である。しかし、実行プログラムを主記憶装置にロードすることなく、フラッシュメモリ上で動作させるプログラムにおいて、単純に同一フラッシュメモリ上に記憶する方式では、ブロック間にまたがるデータを無駄なく完全に連続的な配置を可能にすることは困難である。
【０００７】
これに対し、特願平９−３１７６１２号として出願されたものがある。これによれば、プログラム領域は、連続する複数のブロックに確保される。複数の連続するブロックに確保されたプログラム領域は、１つのヘッダ領域によって管理される。データファイル領域は、例え複数の連続するブロックに確保されたとしても、各ブロック毎にヘッダ領域によって管理される。これによって、ブロック消去方式のフラッシュ型メモリを使用してプログラムの実行が可能となる。
【０００８】
【発明が解決しようとする課題】
しかしながら、以上のような背景技術には、次のような不都合がある。
（１）複数ブロックを保有するプログラム領域の各々をデータファイル領域に変更するためには、それぞれのブロックにおける消去回数や消去時刻などの情報が必要となる。しかし、それらの情報として、先頭ブロックのヘッダ領域に存在するもののみであり、領域変更には不十分である。
（２）また、各ブロックの実際の消去情報を、そのブロックに保存するための手段が存在しない。
（３）運用の制約上、複数個の連続するデータファイル領域を複数個のブロックを保有するプログラム領域に変更するときは、それらのブロックの消去回数や消去時刻などの情報を無視せざるを得ず、フラッシュメモリの寿命を延命させるような効果的な管理を行うことができない。
（４）複数ブロックを保有する１つのプログラム領域を複数個のプログラム領域に分割する際にも、それらのブロックの消去回数などの管理情報を格納する手段がない。
【０００９】
本発明は、以上の点に着目したもので、その目的は、プログラム領域とデータファイル領域の割り当て変更を適宜に行って、使用目的に柔軟に対応するとともに、各ブロックの書き込みや消去の均一化を図ることである。
【００１０】
他の目的は、補助記憶装置としてデータファイルを格納する際には、アプリケーションプログラムからのアクセスを容易にするとともに、排他的なデータアクセスを行う際には、高速化を実現するための整合性を保つことができるデータ構造を実現することである。
【００１１】
更に他の目的は、マルチプロセッシング，マルチスレッド，マルチタスクといった高度な拡張記憶装置上のプログラムの実行環境においても、安全にデータファイルの管理を可能とすることである。
【００１２】
【課題を解決するための手段】
前記目的を達成するために、本発明は、記憶内容の消去単位を１つのブロックとし、プログラムの格納されたブロックと、データの格納されたブロックとが混在しているフラッシュ型メモリを制御する管理装置であって、データファイル領域としてデータの格納された各ブロックにはそれぞれ該ブロックの管理情報を記憶するヘッダ領域が設けられており、連続する複数のブロックを使用してプログラムを格納した状態のプログラム領域では、前記連続する複数のブロックのいずれかに管理情報を記憶するヘッダ領域が設けられ、このヘッダ領域に前記連続する複数のブロックの管理情報が集積されて格納されている状態において、前記連続する複数のブロックを使用したプログラム領域内の領域割り当て変更を、前記集積されて格納されている管理情報に基づき行う際に、再度プログラム領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納すると共に、新たにデータファイル領域として割り当てるブロックがある場合には、その新たにデータファイル領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納することを特徴とする。
【００１３】
あるいは、記憶内容の消去単位を１つのブロックとし、プログラムの格納されたブロックと、データの格納されたブロックとが混在しているフラッシュ型メモリを制御する管理装置であって、
データファイル領域としてデータの格納された各ブロックにはそれぞれ該ブロックの管理情報を記憶するヘッダ領域が設けられており、連続する複数のブロックを使用してプログラムを格納した状態のプログラム領域では、前記連続する複数のブロックのいずれかに管理情報を記憶するヘッダ領域が設けられ、このヘッダ領域に前記連続する複数のブロックの管理情報が集積されて格納されている状態において、前記連続する複数のブロックを使用したプログラム領域内の領域割り当て変更を、前記集積されて格納されている管理情報に基づき行う際に、
再度プログラム領域として細分化した複数のプログラム領域を割り当て、その細分化した各プログラム領域においては、前記細分化した各プログラム領域毎にヘッダ領域を設け、前記細分化した各プログラム領域に含まれるブロックの管理情報を、それぞれ該当する各プログラム領域のヘッダ領域に格納すると共に、新たにデータファイル領域として割り当てるブロックがある場合には、その新たにデータファイル領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納することを特徴とする。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態について詳細に説明する。本形態は、例えば図１に示すように、プロセッサ１０，フラッシュメモリ１２およびその制御装置１４を含む拡張もしくは補助の記憶装置１５，ＲＡＭ（主記憶装置）１６を含むコンピュータシステムに適用される。そして、フラッシュメモリ１２の書換寿命を延命させるプログラムやデータの格納方法，更には管理・制御のための装置を得ようとするものである。
【００２０】
まず、プログラム領域あるいはデータファイル領域を管理するため、フラッシュメモリ１２の管理単位をその最小消去（イレース）単位である１ブロック（物理ブロック）とする。この最小単位である物理ブロック（以下単に「ブロック」という）内には、プログラム領域もしくはデータファイル領域と、そのブロックを管理する情報を持つヘッダ領域とが存在する。なお、同一ブロックの記憶領域には、プログラム領域とデータファイル領域の混在は認めないことにする。また、プログラム領域については、複数のブロックが連続するときはそれらを一括して管理し、そのブロック群を管理する情報を持つヘッダ領域を設ける。
【００２１】
図２には、本形態におけるソフトウエアの基本構造の一例が示されている。同図のように、ＯＳ２０やアプリケーションソフト２２とのソケットインターフェースとして、いわゆるドライバ層２４に相当する部分にフラッシュ管理マネージャ２６を設ける。このフラッシュ管理マネージャ２６は、本形態のシステム用ドライバと考えることができる。このフラッシュ管理マネージャ２６によって、ブロック情報の管理やデータのリード／ライトの制御が行なわれる。
【００２２】
このようなシステムにおける補助記憶装置，拡張記憶装置，あるいはそれらの混在装置上で、特願平９−３１７６１２号として開示されたヘッダ構造と管理手法が適用される。図３［Ａ］は、連続する８個のブロック０〜７をプログラム領域として割り当て、それ以外のブロック８〜ｎをデータファイル領域として割り当てた例である。上述したように、複数の連続するブロックに確保されたプログラム領域は、１つのヘッダ領域によって管理される。一方、データファイル領域は、例え複数の連続するブロックに確保されたとしても、各ブロック毎にヘッダ領域によって管理される。従って、プログラム領域３２のブロックヘッダ３２Ａはブロック０にのみ存在し、ブロック１〜７には存在しない。ブロック１〜７の管理情報等は、ブロック０のヘッダ領域３２Ａにまとめられる。一方、ブロック８〜ｎにはデータファイル領域３８Ｂ〜３ｎＢがそれぞれ確保されるが、各ブロックにそれぞれヘッダ領域３８Ａ〜３ｎＡが存在し、これらによってブロック毎に管理される。
【００２３】
次に、図３［Ｂ］の例は、ブロック０をデータファイル領域として割り当て、ブロック１〜Ａをプログラム領域として割り当て、それ以後はデータファイル領域として割り当てた例である。図３［Ｃ］の例は、ブロック０〜ｎ−９をデータファイル領域に、ブロックｎ−８〜ｎ−３をプログラム領域に、それ以後をデータファイル領域に、それぞれ割り当てた例である。
【００２４】
このように、連続して確保されたプログラム領域は一つのヘッダ領域によって管理される。そして、ブロック数の制限や固定したアドレス配置にすることはない。しかし、データファイル領域は、連続して確保されたとしても、各ブロック毎に管理される。
【００２５】
本形態は、以上の背景技術を改良したもので、連続する複数ブロックを保有するプログラム領域に対するブロックヘッダ内に、それら複数ブロックの管理情報が集積して格納される。上述したように、実行プログラムに対しては連続してファイル領域が確保されるため、ブロックが連結されることになる。この連結の方法として、プログラム領域として確保された連続領域の先頭のブロックに、そのブロックヘッダと、実行プログラム用のブロックヘッダを格納する。
【００２６】
具体的な例で説明すると、例えば図４［Ａ］に示すように、プログラム領域としてブロックｔから４ブロックを確保したとする（ｔは１６進数）。この場合、従属するブロックｔ＋１，ｔ＋２，ｔ＋３の消去回数などの管理情報を、同図［Ｂ］に示すように、先頭のブロックｔのブロックヘッダに格納する。なお、従属ブロックｔ＋１，ｔ＋２，ｔ＋３のブロックヘッダを、先頭ブロックｔ中ではなく、プログラム領域内にあるブロックのいずれかに割り付けてもよい。ただし、フラッシュ管理マネージャ２６側（図２参照）がその旨を認識することができるような情報，例えば割り付けられたブロックの位置情報や運用規程などを明らかにする。以下の説明では、理解を容易にするため、プログラム領域の先頭ブロックに従属ブロックのブロックヘッダも割り付けられているものとする。
【００２７】
図４において更に詳述すると、プログラム領域に対するブロックヘッダは、先頭ブロックｔのブロックヘッダ情報と、従属ブロックｔ＋１，ｔ＋２，ｔ＋３のブロックヘッダ情報を、それぞれ集積した形態となっている。例えば、１ブロックのみで構成される各ブロックヘッダのデータサイズをＨ１バイトとし、実行プログラムあるいはデータファイルが格納される領域のデータサイズをＨ２バイトとする。ブロック全体では、（Ｈ１＋Ｈ２）バイトとなる。
【００２８】
一方、前記従属ブロックのブロックヘッダを集積化した情報のサイズをＨ３バイトとすると、４ブロック連結したプログラム領域に対するブロックヘッダのサイズは、Ｈ１＋Ｈ３バイトとなる（図４［Ｂ］参照）。従って、プログラム領域のサイズは、Ｈ２×４＋Ｈ１×３−Ｈ３バイトとなる。一般的に、Ｊ個の連続するブロックで構成されるプログラム領域の場合、そのブロックヘッダのサイズはＨ１バイト＋Ｈ３バイトとなり、その実行プログラムファイルのデータサイズはＨ２バイト×Ｊ＋Ｈ１バイト×（Ｊ−１）−Ｈ３バイトとなる。
【００２９】
次に、ブロックのヘッダ領域について説明する。ブロックヘッダに含まれる情報としては、図５に示すように、
▲１▼状態（有効／無効／遷移中／初期化完了）を示すフラグ
▲２▼プログラム領域／データファイル領域を示すマーカフラグ
▲３▼連続予約ブロックの領域数
▲４▼パーティション名
▲５▼自己のブロックの消去情報
▲６▼自己のブロックの付加情報（必要があるときに付加）
▲７▼従属ブロックのブロック番号あるいはブロック情報（固有名称）と、その消去情報及び付加情報
がある。
【００３０】
これらのうち、まず▲１▼のフラグについて説明する。フラッシュ管理マネージャ２６（図２参照）は、各ブロックヘッダの内容を読み、フラッシュメモリがどのように管理されているかを把握する。フラッシュメモリのメモリセル内のビットデータは、論理値の「１」→「０」への変化の処理時間は比較的短いが、「０」→「１」への変化は、一度ブロック消去又は消去をしなければならず、長時間を要する。つまり、１ビットのデータの書換えを行なうために、そのブロック内のデータを一時待避させるとともに、ブロック消去後に書き戻す必要があり、処理時間としては大きい。
【００３１】
そこで、実際には、状態を示すフラグを利用してブロックの状態を管理することになる。すなわち、上述した書換えに伴うオーバーヘッドを軽減すため、ブロックヘッダ内にそのブロックが有効な状態か，それとも無効な状態か，初期化が完了した状態か，有効な状態から無効な状態への遷移状態か，といった状態をそれぞれのブロック毎に認識し、データの書込み，データの無効化，ブロックの消去，ブロックの初期化などの操作を行なう。
【００３２】
次に、▲２▼のマーカフラグは、該当するブロックがデータファイル領域に割り当てられたか、それとも、プログラム領域に割り当てられたかを示すフラグである。これによって、プログラム領域に指定されたとき、▲３▼の連続予約ブロック数に実行プログラムとして後に続くブロックの数を指定する。しかし、データファイル領域に指定されているときは、連続予約ブロック数を０とする。▲４▼のパーティション名は、実行プログラムやデータファイルに割り当てた固有の名称である。
【００３３】
▲５▼の自己のブロックの消去情報としては、ブロックを消去した回数を記録する。ブロック消去するときは、記録されている以前の消去回数を一時的に保持し、ブロック消去終了後、一時的に保持している以前の消去回数に１インクリメントしてデータを格納する。▲６▼の自己のブロックの付加情報としては、例えば、イレースシーケンスナンバあるいは消去時刻など、そのブロックに関連する情報がある。
【００３４】
▲７▼の従属ブロックのブロック番号と消去情報及び付加情報としては、従属ブロックに関する消去回数や、イレースシーケンスナンバあるいは消去時刻などの従属ブロックに関連する情報が該当する。これら情報の集積の順番は、その情報がいずれの従属ブロックのものか認識できれば、どのような順序でもよい。また、従属ブロックの消去回数を示す情報は、最低限集積する必要がある。図示の例では、先頭ブロックｔに対して、従属ブロックがｔ＋１，ｔ＋２，……，ｔ＋ｎまで存在する。従って、それらの従属ブロックの各々について、ブロック番号と消去情報や付加情報が先頭ブロックｔのヘッダに集積化されている。
【００３５】
このように、本形態によれば、従属ブロックの消去情報が先頭ブロックのヘッダ情報に含まれている。本形態によれば、これを利用して、次のような運用が可能である。
▲１▼連続する複数個のブロックを占めるプログラム領域を、各ブロック毎のデータファイル領域に変更する。
▲２▼連続する複数個のブロックを占めるプログラム領域を分割し、細分化されたプログラム領域を作成する。
▲３▼連続する複数個のブロックを占めるプログラム領域を分割もしくは目的変更し、細分化されたプログラム領域を作成するとともに、データファイル領域に変更する。
▲４▼連続する複数個のブロックを占めるデータファイル領域を、一つのプログラム領域に変更する。
▲５▼従属するブロックの関連管理情報などが、プログラム領域の先頭ブロックのヘッダ内に収まらない場合に、拡張ヘッダ領域をブロックヘッダ領域の後に付加する。
以下、これらの運用について順に説明する。
【００３６】
（１）まず、複数個のブロックで構成される一つのプログラム領域を、ブロック一個で構成されるデータファイル領域あるいはプログラム領域に変更する方法から説明する。
【００３７】
例えば、図６［Ａ］に示すように、ブロックｔ〜ｔ＋ｎの連続した一つのプログラム領域があるとする。これを、同図［Ｂ］に示すように、一つのブロックのみで構成されるプログラム領域に変更する場合を想定する。変更前のブロックヘッダは、上述した図５のようになっている。これに対し、変更後の各ブロックのブロックヘッダは、図７に示すようになる。つまり、各ブロック毎に、上述した状態を示すフラグ，マーカフラグ，連続予約ブロックの領域数，パーティション名，ブロックの消去回数，ブロックの付加情報を含むブロックヘッダが生成される。
【００３８】
このような図５の状態から図７の状態への変更の手順は、まず、ブロックｔのブロックヘッダ情報と、ブロックｔ＋１〜ｔ＋ｎの管理情報を、ＲＡＭ領域などに待避させる。そして、ブロックｔ〜ｔ＋ｎの領域をブロック消去する。ここで、１ブロック消去する毎に、必ずブロックヘッダを付加する。つまり、ブロックｔのブロックを消去し、完了後にブロックヘッダを初期化する。このとき、ブロックｔに対する待避させた管理情報を更新し、ブロックｔのブロックヘッダに格納する。情報の更新には、例えば消去回数を１インクリメントすることなどが含まれる。
【００３９】
このようにして、一つのブロックｔのみで構成されるプログラム領域に変更が行われる。ブロックｔ＋１についても、同様にブロック消去を行い、完了後にブロックヘッダを初期化し、待避させたブロックｔ＋１の管理情報を更新してそのブロックヘッダに格納する。このような操作をブロックｔ＋ｎまで繰り返し行う。なお、図６の例は、一つのブロックで構成されるプログラム領域に変更したが、一つのブロックで構成されるデータファイル領域への変更についても同様である。
【００４０】
（２）次に、複数個のブロックで構成される一つのプログラム領域を、ブロックｔ〜ｔ＋ｍで構成される第１のプログラム領域と、ブロックｔ＋ｍ＋１〜ｔ＋ｎ個で構成される第２のプログラム領域とに、２分割する方法を説明する。
【００４１】
例えば、図８［Ａ］に示すように、ブロックｔ〜ｎ＋１の連続した一つのプログラム領域があるとする。これは、前記図６［Ａ］と同様である。これを、同図［Ｂ］に示すように、２つのプログラム領域に変更する場合を想定する。変更前のブロックヘッダは、上述した図５のようになっている。これに対し、変更後の各プログラム領域のブロックヘッダは、図９及び図１０にそれぞれ示すようになる。つまり、各プログラム領域毎に、上述した状態を示すフラグ，マーカフラグ，連続予約ブロックの領域数，パーティション名，ブロックの消去回数，ブロックの付加情報，従属ブロックのブロック番号と消去情報及び付加情報を含むブロックヘッダが生成される。
【００４２】
すなわち、分割後の第１のプログラム領域のブロックヘッダは、図９に示すように、先頭ブロックｔの情報と、従属ブロックｔ＋１〜ｔ＋ｍの情報を集積化した情報を含む。分割後の第２のプログラム領域のブロックヘッダは、図１０に示すように、先頭ブロックｔ＋ｍ＋１の情報と、従属ブロックｔ＋ｍ＋２〜ｔ＋ｎの情報を集積化した情報を含む。
【００４３】
図５の状態から図９，図１０の状態への分割変更の手順は、まず、ブロックｔのブロックヘッダ情報と、ブロックｔ＋１〜ｔ＋ｎの管理情報を、ＲＡＭ領域などに待避させる。そして、ブロックｔ〜ｔ＋ｎまでの領域をブロック消去する。ここで、まず、図９の状態にするため、ブロックｔ〜ｔ＋ｍをブロック消去する。そして、完了後に、ブロックｔにブロックヘッダを形成して初期化する。このとき、ブロックｔに対する待避させた管理情報を更新し、ブロックｔのブロックヘッダに格納する。その後、従属ブロックｔ＋１〜ｔ＋ｍの管理情報を順に更新し、各ブロックのブロックヘッダに付加する。
【００４４】
一方、更に図１０の状態にするため、ブロックｔ＋ｍ＋１〜ｔ＋ｎをブロック消去する。そして、完了後に、ブロックｔ＋ｍ＋１にブロックヘッダを形成して初期化する。このとき、ブロックｔ＋ｍ＋１に対する待避させた管理情報を更新し、ブロックｔ＋ｍ＋１のブロックヘッダに格納する。その後、従属ブロックｔ＋ｍ＋２〜ｔ＋ｎの管理情報を順に更新し、各ブロックのブロックヘッダに付加する。
【００４５】
なお、以上の例は、一つのプログラム領域を二つのプログラム領域に二分割した例であるが、更に複数に分割する場合も同様である。
【００４６】
（３）次に、複数個のブロックで構成される一つのプログラム領域を、
▲１▼ブロックｔのみで構成されるデータファイル領域（もしくはプログラム領域），
▲２▼ブロックｔ＋１〜ｔ＋ｍで構成されるプログラム領域，
▲３▼ブロックｔ＋ｍ＋１〜ｔ＋ｍ＋ｏ−１まではそれぞれブロック一つで構成されるデータファイル領域，
▲４▼ブロックｔ＋ｍ＋ｏ〜ｔ＋ｎで構成されるプログラム領域
に変更する方法を説明する。
【００４７】
例えば、図１１［Ａ］に示すように、ブロックｔ〜ｔ＋ｎの連続した一つのプログラム領域があるとする。これは、前記図６［Ａ］と同様である。これを、同図［Ｂ］〜［Ｅ］に示すように、多数のデータファイル領域やプログラム領域に変更する場合を想定する。前記▲１▼〜▲４▼が、同図［Ｂ］〜［Ｅ］に対応する。変更前のブロックヘッダは、上述した図５のようになっている。これに対し、分割後の各プログラム領域のブロックヘッダは、図１２及び図１３にそれぞれ示すようになる。
【００４８】
図５の状態から図１２，図１３の状態への分割変更の手順は、まず、ブロックｔのブロックヘッダ情報と、ブロックｔ＋１〜ｔ＋ｎの管理情報を、ＲＡＭ領域などに待避させる。そして、ブロックｔ〜ｔ＋ｎまでの領域をブロック消去する。ここで、まず、図１２の状態にするため、ブロックｔをブロック消去する。そして、完了後に、ブロックｔにブロックヘッダを形成して初期化する。このとき、ブロックｔに対する待避させた管理情報を更新し、ブロックｔのブロックヘッダに格納する。
【００４９】
次に、ブロックｔ＋１〜ｔ＋ｍまでを消去し、完了後にブロックｔ＋１にブロックヘッダを付加し初期化する。このとき、同様に、ブロックｔで待避させたブロックｔ＋１の管理情報を更新し、ブロックｔ＋１のブロックヘッダに格納する。その後、順にブロックｔ＋２〜ｔ＋ｍまでの従属ブロックの管理情報を更新し、先頭ブロックであるブロックｔ＋１のブロックヘッダに付加する。
【００５０】
更に、図１３の状態にするため、前記ブロックｔと同様の操作を、ブロックｔ＋ｍ＋１〜ｔ＋ｍ＋ｏ−１まで繰り返し行う。最後に、ブロックｔ＋ｍ＋ｏ〜ｔ＋ｎに対して、前記ブロックｔ＋１〜ｔ＋ｍと同様の動作を繰り返し行う。
【００５１】
なお、以上の例は、プログラム領域を２つ設けるとともに、いくつかのデータファイル領域も設けた例であるが、複数のプログラム領域と複数のデータファイル領域に分割変更する場合も同様である。なお、連結するブロックについては、その該当ブロックを連続的に消去し、完了後にその先頭ブロックのブロックヘッダに従属ブロックのヘッダ情報も集積した情報を格納することができれば、ブロックの消去の順番やブロックヘッダの初期化の順番などは、上述した方法でなくてもよい。
【００５２】
（４）次に、使用頻度が高いデータファイル領域からプログラム領域に変更する方法を説明する。使用頻度の高いデータファイル領域を検出し、このデータファイル領域に移動可能なプログラム領域を移動する。
【００５３】
まず、移動可能なプログラム領域のサイズ（ブロック数）分の連続するデータファイル領域を決定する。この決定方法として、
▲１▼単純に消去回数の多いブロックを検出し、そのブロックを含むように前後のブロックを割り当てる方法，
▲２▼必要とする分の連続するブロックでの平均の消去回数が最大のところに割り当てる方法，
▲３▼前記▲１▼及び▲２▼を組み合わせて最適化を図る方法，
▲４▼平均化ではなく、標準偏差などによって最適ブロックを選定する方法，
がある。
【００５４】
平均化の例を取って説明すると、例えば連続するブロックを３ブロック選定する場合を想定する。図１４に示すように、ブロックｘからブロックｘ＋ｎまでのブロックがデータファイル領域として存在すると仮定する。各ブロックの消去回数Ｙ０〜Ｙｎに対し、連続する３つのブロックの消去回数の平均値Ｚ０，Ｚ１，…，Ｚｎ２を求める。例えば、平均値Ｚ０は、ブロックｘ〜ｘ＋２の消去回数Ｙ０〜Ｙ２から、Ｚ０＝（Ｙ０＋Ｙ１＋Ｙ２）／３で求められる。他の平均値についても同様である。これら平均値のうちから最大値を検出して、それに該当する連続する３つのブロックをプログラム領域として割り当てるようにすればよい。
【００５５】
連続する複数個のプログラム領域に割り当てるデータファイル領域のブロックの候補が決定すれば、それぞれの該当するブロックのブロックヘッダの管理情報をＲＡＭ領域などに待避する。そして、候補の各データファイル領域について、それぞれブロック消去を行う。完了後、先頭のブロックにのみブロックヘッダを生成して初期化し、その先頭ブロックに対応する待避した管理情報を更新する。管理情報の更新としては、少なくとも消去回数を１インクリメントする。更に、従属ブロックの管理情報も更新し、先頭ブロックのヘッダ情報の後に従属するそれぞれのブロックのヘッダ管理情報を更新して格納する。このような結合の方法は、上述した分割変更と逆の操作を行えばよい。また、割り当てられるブロックの候補が決まった後における該当ブロックの消去の順番は、いずれから行ってもよい。
【００５６】
（５）次に、効果的な運用として、連続する複数個のブロックで構成されるプログラム領域を、いくつかのプログラム領域に細分化する方法を説明する。これは、上述した（１），（２）及び（３）の方法を応用することで実現できる。まず、分割するプログラム領域のブロックヘッダ及びその従属するブロックヘッダの情報をＲＡＭ上などに待避させる。また、分割するプログラム領域のプログラムもＲＡＭ上に待避させる。
【００５７】
そして、細分化されたブロック数をもつプログラム領域として、前記（１），（２）及び（３）の方法と同様に、データファイル領域のブロックからプログラム領域に変更する候補ブロックをそれぞれ細分化された場合毎に選択する。この選択結果をもとに、待避させたブロックヘッダの管理情報及び従属ブロックの管理付加情報をもとに、分割された新プログラム領域毎に、ブロックヘッダ従属ブロックの管理情報について更新と再構成を行い、該当するヘッダ領域へそれぞれ格納する。そして、待避させておいたプログラム領域のプログラムを、分割されたブロックの内容に対応すように分割し、それぞれのプログラムデータを該当領域に移動させればよい。
【００５８】
（６）また、細分化されたブロックによってプログラム領域を構成する方法として、データファイル領域のブロックからプログラム領域に変更する候補ブロックを、それぞれ細分化された場合毎に選択する。そして、前記（４）の方法のように、データファイル領域からプログラム領域への変更を細分化した形態で行えばよい。
【００５９】
選択結果をもとに、それぞれのデータファイル領域のブロックヘッダ内にある管理情報と対応するデータファイル領域内のデータをＲＡＭ上に各々待避させる。そして、そのブロック領域を細分化できるような形態で、それぞれ分割したプログラム領域に割り当て、対応するブロックヘッダと従属ブロックの管理情報を更新して再構成を行う。更に、分割するプログラム領域に対応するように、プログラムをコピーしていけばよい。そして、前記（４）の方法と同様に、細分化される前のプログラム領域が保有しているブロックを消去するとともに、ブロックヘッダの初期化を行う。その後、待避させておいたデータのブロック管理情報とそれに対するデータなどを書換回数の少ないデータファイル領域の候補ブロックにそれぞれ書き戻すことで、操作は完了する。
【００６０】
フラッシュ管理マネージャ２６（図２参照）は、ユーザの操作による実行開始の指示か、あるいは自己の判断で自動的に最適化タイミングを検出し、上述した分割や変更の操作を実行する。本形態は、少なくとも１個のフラッシュメモリ上でＲＯＭ実行可能なプログラムとデータファイルとが混在できる装置であり、その装置上でプログラム領域からデータファイル領域への変更、あるいはデータファイル領域からプログラム領域へ変更することが可能となる。このため、フラッシュメモリ上における各ブロックの消去回数の均一化を図ることができ、更にはフラッシュメモリの長寿命化も可能となる。以下、主要な実施例について説明する。
【００６１】
（１）実施例１……この実施例は、従属ブロックの管理付加情報として、ブロック番号を備えた例である。本例では、図１７の構造を持つブロックヘッダとプログラム領域からデータファイル領域への移動方法を説明する。
【００６２】
図１５，図１６には、フラッシュメモリに対するブロックヘッダなどの格納例が示されている。なお、これらの図中、図１５［Ａ］は図１６［Ａ］に連続し、図１５［Ｂ］は図１６［Ｂ］に連続する。これらの図において、［Ａ］は、６４Ｋバイトを消去ブロック単位とする２Ｍ×８ビットのフラッシュメモリで、ブロック数が１Ｆ個（１６進表示）あるシステムである。各ブロックに「０」から「１Ｆ」と順に番号をつける。各ブロックの先頭には、［Ｂ］に示すように、各ブロックの管理情報であるヘッダ領域として２５６バイトが割り当て可能となっている。もちろん、データファイル領域の場合には該当するブロック内に必ずブロックヘッダを付随させるが、プログラム領域の場合はその限りではない。
【００６３】
そして、ブロック０〜７をプログラム領域（１）に割り当て、ブロック９〜Ｂをプログラム領域（２）に割り当てる。他のブロックはデータファイル領域に割り当てる。それらプログラム領域の先頭ブロックのブロックヘッダには、例えば図１７に示す情報を付加する。順に説明すると、まず１バイト目には、有効／遷移中／無効，初期化完了状態，予約のフラグがある。これらのうち、有効／遷移中／無効のフラグは、このブロック領域が有効状態か，それとも有効から無効になる遷移中（過渡期）の状態か，完全に無効になった状態かを示す。初期化完了状態のフラグは、ブロックのイレース後にブロックヘッダの初期化（フォーマット）が完了したことを指し示す。予約のフラグは、システムを拡張するときに使用するための予備フラグである。
【００６４】
次に、２バイト目には、プログラム／データ，連続予約ブロック領域数のフラグがある。これらのうち、プログラム／データのマーカフラグは、プログラム，データファイルのいずれがそのブロックに割り当てられたかを決定するフラグである。連続予約ブロック領域数のフラグは、プログラム領域に指定した残りのブロック数が１６進数で表記されている。
【００６５】
次に、３〜５バイト目は、そのブロックの消去回数を１６進で表記している。３バイト目がその回数の下位の桁、４バイト目がその回数の中位の桁、５バイト目にはその回数の上位の桁として、それぞれデータを格納する。６バイト目は上述したイレースシーケンスナンバで、ブロックの消去回数が他のブロックと同じときに、どの順番でブロックの初期化がなされたかを記録するものである。７バイト目から１２ｈバイト目までは、該当するブロックの領域名などのパーティション名を記録する。実行プログラムファイルの場合、パーティション名やディレクトリ名などに利用すると、システム運用が容易になる。
【００６６】
更に、本実施例では、プログラム領域として使用した場合、ブロックヘッダを４Ｋバイトまで拡張し、１３ｈ〜Ｂｈ＋４ｎバイトに従属ブロックの付加情報を格納する。図示の例では、１３ｈ〜１６ｈに、ブロックｔ＋１のブロック番号と、消去回数の下位，中位，上位とがそれぞれ格納されている。以下、同様である。
【００６７】
図１に示した装置を使用していくと、消去回数はプログラム領域のブロックよりもデータファイル領域のブロックの方が多くなる。そこで、図１５［Ｂ］のブロック９〜Ｂまでの連続する３ブロックで構成されているプログラム領域（２）をデータファイル領域へ再割り当てする。フラッシュ管理マネージャ２６は、次のような操作を行う。再割り当てを行う候補ブロックの選定方法として、平均消去回数の多いものを優先させることにする。フラッシュ管理マネージャ２６は、データファイル領域に割り当てられているブロック８，Ｃ〜１Ｆまでのブロックの中から、連続する３ブロックの間で平均消去回数が最も大きいものを選択する。
【００６８】
ブロック８の近辺では、連続するブロックの候補がないため、適用から外れる。次に、ブロックＣ，Ｄ，Ｅの平均消去回数、ブロックＤ，Ｅ，Ｆの平均消去回数、ブロックＥ，Ｆ，１０の平均消去回数、……、ブロック１Ｄ，１Ｅ，１Ｆの平均消去回数をそれぞれ計算する。この結果、仮にブロック１Ｄ，１Ｅ，１Ｆの組み合わせが最大の平均消去回数だったとすると、それらのブロックが再割り当てを行うためのブロックの候補となる。
【００６９】
フラッシュ管理マネージャ２６は、ブロック１Ｄ，１Ｅ，１Ｆにおけるそれぞれのブロックヘッダの情報をＲＡＭ上に待避させる。次に、ブロック１Ｄのブロックヘッダが有効状態のときは、データファイル領域のデータをそれぞれＲＡＭ上に待避させる。しかし、そのブロックが無効であれば、データファイル領域のデータをＲＡＭ上に待避させる必要はない。また、そのブロックが遷移中のときは、移動操作を中断する。この操作を、ブロック１Ｅ，１Ｆにも同様に行う。そして、ブロック１Ｄ，１Ｅ，１Ｆをそれぞれ消去する。
【００７０】
ブロック消去完了後、ブロック１Ｄ，１Ｅ，１Ｆをプログラム領域として使用するため、ブロックヘッダを初期化する。このとき、先頭ブロック１Ｄにおけるブロックヘッダの管理情報において、初期化完了フラグをＯＮにし、有効／無効／遷移中の状態フラグでは、遷移中のフラグをたてることにより、ブロック１Ｄ，１Ｅ，１Ｆのプログラム領域はコピー中であることを宣言する。また、プログラム／データのマーカフラグを、プログラム領域であることを示すためにＯＮにし、連続予約ブロック領域数を２（０ｂ０００００１０）にする。更に、前記ＲＡＭ上に待避させたブロック１Ｄの消去回数の情報を更新するとともに、イレースシーケンスナンバ情報を再構築する。なお、パーティション名は、移動元であるブロック９のブロックヘッダ情報の中にあるパーティション名と同等にする。
【００７１】
次に、従属するブロック１Ｅ，１Ｆのブロック番号と、前記ＲＡＭ上に待避させたブロック１Ｅ，１Ｆの消去回数を１インクリメントし、その値を格納する。そして、移動元のプログラム領域（２）（メモリ空間０９０１０００〜０ＢＦＦＦＦＦ）のデータを、移動先のプログラム領域（２）（メモリ空間０Ｄ０１０００〜１ＦＦＦＦＦＦ）にコピーする。コピー完了後、ブロック９にあるブロックヘッダの拡張ヘッダ領域にある管理情報をＲＡＭ上に待避する。そして、ブロック９のブロックヘッダ内にある有効／遷移中／無効フラグを無効フラグＯＮにし、有効から無効状態に遷移する。
【００７２】
次に、ブロック９の中にあるブロックヘッダ情報及びその拡張ヘッダ（ブロック９，Ａ，Ｂの各管理情報やブロック情報）をＲＡＭ上に待避する。そして、ブロック９，Ａ，Ｂをそれぞれ消去する。それぞれのブロックの消去完了後、各ブロックをデータファイル領域として使用するために、各ブロックヘッダを初期化する。すなわち、ブロックヘッダ内の初期化完了フラグをＯＮにし、プログラム／データのマーカフラグをデータ状態にし、連続予約ブロック数に０を格納する。更に、待避しているブロック９における管理情報の消去回数の情報を更新し、イレースシーケンスナンバを再構築する。これをブロックＡ，Ｂにも適用する。
【００７３】
ここで、データファイル領域から退避したデータを戻す方法は、次のようになる。データファイル領域として割り当てられているブロックの中から、消去回数がもっとも少ないものに、待避したブロック１Ｄのデータファイル領域を割り当てる。ここではその割り当てるブロックの候補として、ブロックＢが選択されたとすると、まず有効／遷移中／無効フラグを有効状態にする。ブロックＢのブロックヘッダ情報として、先ほど待避させたブロック１Ｄに対応するファイル名を格納する。そして、待避させたブロック１Ｄのデータファイル領域のデータをブロックＢのデータファイル領域に格納し、復元する。このように、割り当てるブロックの候補を選択し、ブロック１Ｅ，１Ｆのデータファイル領域も復元する。ただし、ブロック１Ｄ，１Ｅ，１Ｆのデータファイル領域が無効となっている場合は、そのデータの復元操作を行う必要はない。
【００７４】
以上の説明は、連続する３ブロックからなるプログラム領域のプログラムを、消去回数の多いデータファイル領域のブロックに移動する方法であるが、このような手法は、複数ブロックを持つプログラム領域の場合において一般的に適用することができる。
【００７５】
（２）実施例２……この例は、従属ブロックの管理付加情報として、ブロックのイレースシーケンスナンバを備えた例である。本例では、図１８の構造を持つブロックヘッダとデータファイル領域からプログラム領域への移動方法を説明する。
【００７６】
前記実施例と同様に、ブロック１Ｄ，１Ｅ，１Ｆの組み合わせが最大の平均消去回数であったとする。本例では、まず、ブロック９上にあるブロックヘッダと拡張ブロックヘッダの情報（ブロック９におけるブロックヘッダの管理情報と、従属ブロックＡ，Ｂに関するそれぞれのブロックヘッダの情報）をＲＡＭ上に待避する。そして、ブロック９，Ａ，Ｂ上のプログラム領域におけるプログラム（メモリ空間０９０１０００〜０ＢＦＦＦＦＦ）をＲＡＭ上に待避する。
【００７７】
次に、ブロック９のブロック消去を行い、完了後、データファイル領域として使用するために、ブロックヘッダの初期化を行う。すなわち、ブロックヘッダ内の初期化完了フラグをＯＮにし、プログラム／データのマーカフラグをデータ側とし、連続予約ブロック数に０を格納する。そして、待避しているブロック９における管理情報の消去回数の情報を更新し、イレースシーケンスナンバを再構築する。ブロックＡ，Ｂについても同様である。
【００７８】
ブロック１Ｄにおけるデータファイル領域のデータの移動を説明すると、ブロック１Ｄのブロックヘッダ内にある有効／無効／遷移中の状態フラグを遷移中状態とすることにより、ブロック１Ｄのプログラム領域のデータを移動することを宣言する。そして、ブロック９のブロックヘッダ内にある有効／無効／遷移中の状態フラグを有効状態にする。更に、ブロック１Ｄのデータファイル領域のデータ（メモリ空間１Ｄ００１００〜１ＤＦＦＦＦＦ）をブロック９のデータファイル領域のデータ（メモリ空間０９００１００〜０９ＦＦＦＦＦ）にコピーする。そして、ブロック１Ｄのブロックヘッダ内にある有効／無効／遷移中の状態フラグを無効状態にする。同様の操作を、ブロック１ＥからブロックＡに、ブロック１ＦからブロックＢに対して行い、データファイル領域のデータをそれぞれコピーする。
【００７９】
これにより、ブロック１Ｄ，１Ｅ，１Ｆは無効状態となる。このため、フラッシュ管理マネージャ２６は、それらのブロックをプログラムファイル領域として確保できるように、ブロック消去及び初期化を行う。ブロック消去完了後、ブロック１Ｄ，１Ｅ，１Ｆをプログラム領域として利用するため、ブロックヘッダを初期化する。このとき、先頭ブロック１Ｄにおけるブロックヘッダの管理情報において、初期化完了フラグをＯＮにし、有効／無効／遷移中の状態フラグを有効状態にする。また、プログラム／データのマーカフラグをＯＮにするとともに、連続予約ブロック領域数を２（０ｂ０００００１０）にする。
【００８０】
更に、前記ＲＡＭ上に待避させたブロック１Ｄの消去回数の情報を更新し、イレースシーケンスナンバの情報を再構築する。そして、パーティション名にを、待避させた情報，すなわちブロック９のブロックヘッダ情報中にあったパーティション名と同等にする。また、従属ブロック１Ｅ，１Ｆのブロック番号とＲＡＭ上に待避させた従属ブロック１Ｅ，１Ｆの消去回数を１インクリメントし、その値を格納するとともに、従属ブロック１Ｅ，１Ｆのイレースシーケンスナンバの情報を再構築する。その後、先ほど待避させたプログラム領域（２）（メモリ空間０９０１０００〜０ＢＦＦＦＦＦをＲＡＭ上に待避）のデータを、ブロック１Ｄ，１Ｅ，１Ｆのプログラム領域（２）（メモリ空間０Ｄ０１０００〜１ＦＦＦＦＦＦ）へ移動することにより、復元が行われる。
【００８１】
以上の例は、連続する３ブロックからなるプログラム領域のプログラムを、消去回数の多いデータファイル領域のブロックに移動する場合であるが、複数ブロックを持つプログラム領域の場合に、一般的に適用することができる。
【００８２】
（３）実施例３……図１９及び図２０は、付加情報として初期化された時刻情報を備えたブロックヘッダの例である。本例では、図１９，図２０の構造を持つブロックヘッダとプログラム領域からデータファイル領域への移動を説明する。なお、図２０は図１９に連続する図である。これの例では、前記実施例（１）のブロック番号の代わりに、そのブロックの初期化時刻が含まれており、プログラム領域における従属ブロックの管理情報の中に付加情報として初期化時刻が格納されている。運用方法としては、前記実施例（１）に示した操作をほぼ適用できる。ただし、初期化時刻の情報は，ブロックヘッダ初期化時点で付加される情報であり、従属ブロックヘッダの情報を更新するときに格納される。
【００８３】
（４）実施例４……前記実施例３の運用方法として、実施例（１）の代わりに実施例（２）を適用することも可能である。この例は、図１９，図２０の構造を持つブロックヘッダとデータファイル領域からプログラム領域への移動方法の例である。この場合は、実施例（２）のイレースシーケンスナンバの情報の代わりに、そのブロックの初期化時刻の情報を備えたことになる。これを付加情報とすることにより、実施例（２）をほとんどそのまま適用できる。
【００８４】
（５）実施例５……連続する複数個のブロックからなるプログラム領域をいくつかのプログラム領域に細分化する方法、あるいは、そのプログラム領域をいくつかのプログラム領域とデータファイル領域とに分割細分化する方法は、前述の実施例（１）〜（４）を応用すれば実現できる。例えば、データの移動先の候補ブロックを選択し、その該当するブロックヘッダ（プログラム領域の場合は従属ブロックヘッダも含む）の情報をＲＡＭ上などに待避する。また、データあるいはプログラムの内容をＲＡＭ上に待避する。この後、細分化や分割化したブロック構成を実現するために、該当ブロックのブロック消去及びブロックヘッダの初期化を行う。このとき、待避したブロックヘッダや従属ブロックヘッダの情報を元に、情報の更新や再構成を行う。その後、プログラムやデータの内容をそれぞれ対応させるようにする。
【００８５】
この発明は数多くの実施形態が存在し、以上の開示に基づいて多様に改変することが可能である。例えば次のようなものが含まれる。
【００８６】
（１）上述した実施例の他に、図１８の構造を持つブロックヘッダとプログラム領域からデータファイル領域への移動，図１７の構造を持つブロックヘッダとデータファイル領域からプログラム領域への移動なども可能である。
【００８７】
（２）複数個の連続するブロックの再割り当てを行う対象候補ブロックの選定方法として、上述した方法のほかに、消去回数の最大値を探索し、その対象となる前後ブロックにおける平均値の最大値をもつブロックを候補として選択するようにしてもよい。例えば、候補ブロックを３ブロック選定する場合、消去回数の最大値を持つものがブロックｔであるとすると、ブロックｔ−２，ｔ−１，ｔの平均値と、ブロックｔ−１，ｔ，ｔ−１の平均値と、ブロックｔ，ｔ＋１，ｔ＋２の平均値とをそれぞれ求め、それらの中から最大の平均値をもつ３ブロックを候補とする。
【００８８】
（３）複数個の連続するブロックの再割り当てを行う際の対象候補ブロックの選定方法として、消去回数の値を標準偏差などの統計的手法を利用するようにしてもよい。
【００８９】
（４）前記形態はフラッシュメモリに本発明を適用したものであるが、他の類似するメモリがフラッシュメモリと同じ書込み，読出し機能を備えており、かつ、書込前ブロック消去特性を有するメモリであれば、同様に適用可能である。
【００９０】
（５）フラッシュメモリのイレース単位である物理ブロックは、バイト単位やワード単位の他、どのようなデータ単位であっても、同様に適用可能である。
【００９１】
【発明の効果】
以上説明したように、本発明によれば、次のような効果がある。
【００９２】
（１）プログラム領域の従属ブロックの管理情報を持つこととしたので、領域変更を行う際に、該当するブロックの管理情報を正しく反映させることができ、フラッシュ型メモリにおける各ブロックの消去回数を管理できる。また、プログラム領域とデータファイル領域の割り当て変更を適宜に行って、使用目的に柔軟に対応するとともに、各ブロックの書き込みや消去の均一化を図ることができ、各ブロックの消去回数の平準化や長寿命化に極めて有効である。
【００９３】
（２）プログラム領域の先頭ブロックのヘッダ領域あるいはそれに続くブロックの拡張ヘッダ領域に管理情報を集積化したので、ブロックの管理情報に少ないオーバヘッドでアクセスでき、更にはプログラム領域の先頭を常に固定的に特定することが可能になる。
【００９４】
（３）マルチプロセッシング，マルチスレッド，マルチタスクといった高度な拡張記憶装置上のプログラムの実行環境においても、安全にデータファイルの管理を行うことができる。
【００９５】
（４）フラッシュ型メモリのブロック消去回数を平準化させ、フラッシュ型メモリの寿命を長くすることができるだけでなく、コピー元のデータファイル領域のデータをマルチタスク、マルチスレッドという環境の中で、別プログラムがその中のデータを参照しながらコピー先にデータをコピーすることが可能となる。この結果、システムの効果的な運用と、従来よりも数倍以上の実用的長寿命を得ることができる。
【図面の簡単な説明】
【図１】この発明の一形態を利用したシステムの基本構成を示す図である。
【図２】前記形態におけるソフトウェアの構造を示す図である。
【図３】プログラム領域とデ−タファイル領域を物理ブロックに割り当てた例を示す図である。
【図４】プログラム領域として確保された複数のブロックの一元管理の様子を示す図である。
【図５】前記図４におけるブロックヘッダの管理情報を示す図である。
【図６】一つのプログラム領域を、ブロック毎のプログラム領域に分割する場合のマッピング例を示す図である。
【図７】前記図６におけるブロックヘッダの管理情報を示す図である。
【図８】一つのプログラム領域を、二つのプログラム領域に分割する場合のマッピング例を示す図である。
【図９】前記図８におけるブロックヘッダの管理情報を示す図である。
【図１０】前記図８におけるブロックヘッダの管理情報を示す図である。
【図１１】一つのプログラム領域を、二つのプログラム領域と多数のデータファイル領域に分割する場合のマッピング例を示す図である。
【図１２】前記図１１におけるブロックヘッダの管理情報を示す図である。
【図１３】前記図１１におけるブロックヘッダの管理情報を示す図である。
【図１４】データファイル領域からプログラム領域に変更するための候補ブロックを選定する手法を示す図である。
【図１５】ブロック構成の一例と、プログラム領域及びデータファイル領域のマッピング例を示す図である。
【図１６】ブロック構成の一例と、プログラム領域及びデータファイル領域のマッピング例を示す図である。
【図１７】本発明の実施例における管理情報の態様を示す図である。
【図１８】本発明の実施例における管理情報の態様を示す図である。
【図１９】本発明の実施例における管理情報の態様を示す図である。
【図２０】本発明の実施例における管理情報の態様を示す図である。
【符号の説明】
１０…プロセッサ
１２…フラッシュメモリ
１４…フラッシュメモリ制御装置
１６…ＲＡＭ
２０…オペレーティングシステム
２２…アプリケーションソフト
２４…ドライバ層
２６…フラッシュ管理マネージャ
【発明の属する技術分野】
本発明は、フラッシュ型メモリの管理装置にかかり、更に具体的には、フラッシュ型メモリの管理の効率化に関するものである。
【０００２】
【従来の技術】
一般にフラッシュタイプのフローティングゲートトランジスタを含む電気的に消去可能なプログラマブル読出専用メモリ（ＥＥＰＲＯＭ）は、市場で容易に入手することができる。これらのいわゆるフラッシュメモリは、機能・性能面でＥＰＲＯＭメモリと類似した不揮発メモリであり、メモリ内を分割するブロックを消去する回路内プログラマブル動作を可能にするという機能を更に有する。フラッシュメモリでは、以前に書き込まれたメモリの領域を前もって消去することで、その書き換えが行われる。
【０００３】
典型的なコンピュータシステムでは、オペレーティングシステム（以下、単に「ＯＳ」という）のプログラムがそのシステムのデータ記憶装置のデータ管理を担う。ＯＳプログラムとの互換性を達成するために必要かつ十分であるデータ記憶装置のアトリビュート（属性）は、データ記憶装置のいかなる位置からもデータを読み出すことができ、これにデータを書き込むことができることである。しかし、フラッシュメモリの場合、データが既に書き込まれている領域には、その領域のデータを消去しなければデータを書き込むことはできない。このため、フラッシュメモリは、典型的な既存のＯＳプログラムとは互換性がない。
【０００４】
このような点に着目し、既存のＯＳプログラムによってフラッシュメモリを管理することを可能にするソフトウエアが先行技術において提案されている。この先行技術のプログラムでは、フラッシュメモリを「書込み１回読出し複数回」の装置として動作させるか、「書込み複数回読出し複数回」の装置として動作させている。前者は、以前に書き込まれているメモリ場所を再利用することはできない装置であり、補助記憶装置や拡張記憶装置として使用できる。後者は、以前に書き込まれているメモリ領域を再利用可能とし、その領域中にはフラッシュメモリの書換回数を少なくするような制御を持つ補助記憶装置（半導体ファイル記憶装置）がある。
【０００５】
このような従来技術によれば、フラッシュメモリを使用した拡張記憶装置上では書換回数を少なくなるような制御構造を持たずに実行プログラムを動作させている。つまり、フラッシュメモリに対して新たにデータの書換えを行うときは、全ブロックを一括して消去し、その後、データを記憶させる必要がある。また、マルチタスク，マルチスレッド，マルチプロセスに代表される並列実行プログラムやデータの共有あるいは占有という管理を行う場合において、一般のＭＭＵ（メモリ管理ユニット）を駆使してフラッシュメモリをブロック（ページ）毎に管理する方式では、書換回数の管理と書換回数の低減を図ることは困難である。
【０００６】
フラッシュメモリを使用した拡張記憶装置上でプログラムの実行を可能とする装置にはないものの、フラッシュメモリの書換回数を少なくするような制御構造を持つ装置として補助記憶装置（半導体ファイル記憶装置）がある。これは、補助記憶装置において書換回数を少なくするためにその情報（書換回数テーブル）を異なるメモリ上に記憶する方式である。しかし、実行プログラムを主記憶装置にロードすることなく、フラッシュメモリ上で動作させるプログラムにおいて、単純に同一フラッシュメモリ上に記憶する方式では、ブロック間にまたがるデータを無駄なく完全に連続的な配置を可能にすることは困難である。
【０００７】
これに対し、特願平９−３１７６１２号として出願されたものがある。これによれば、プログラム領域は、連続する複数のブロックに確保される。複数の連続するブロックに確保されたプログラム領域は、１つのヘッダ領域によって管理される。データファイル領域は、例え複数の連続するブロックに確保されたとしても、各ブロック毎にヘッダ領域によって管理される。これによって、ブロック消去方式のフラッシュ型メモリを使用してプログラムの実行が可能となる。
【０００８】
【発明が解決しようとする課題】
しかしながら、以上のような背景技術には、次のような不都合がある。
（１）複数ブロックを保有するプログラム領域の各々をデータファイル領域に変更するためには、それぞれのブロックにおける消去回数や消去時刻などの情報が必要となる。しかし、それらの情報として、先頭ブロックのヘッダ領域に存在するもののみであり、領域変更には不十分である。
（２）また、各ブロックの実際の消去情報を、そのブロックに保存するための手段が存在しない。
（３）運用の制約上、複数個の連続するデータファイル領域を複数個のブロックを保有するプログラム領域に変更するときは、それらのブロックの消去回数や消去時刻などの情報を無視せざるを得ず、フラッシュメモリの寿命を延命させるような効果的な管理を行うことができない。
（４）複数ブロックを保有する１つのプログラム領域を複数個のプログラム領域に分割する際にも、それらのブロックの消去回数などの管理情報を格納する手段がない。
【０００９】
本発明は、以上の点に着目したもので、その目的は、プログラム領域とデータファイル領域の割り当て変更を適宜に行って、使用目的に柔軟に対応するとともに、各ブロックの書き込みや消去の均一化を図ることである。
【００１０】
他の目的は、補助記憶装置としてデータファイルを格納する際には、アプリケーションプログラムからのアクセスを容易にするとともに、排他的なデータアクセスを行う際には、高速化を実現するための整合性を保つことができるデータ構造を実現することである。
【００１１】
更に他の目的は、マルチプロセッシング，マルチスレッド，マルチタスクといった高度な拡張記憶装置上のプログラムの実行環境においても、安全にデータファイルの管理を可能とすることである。
【００１２】
【課題を解決するための手段】
前記目的を達成するために、本発明は、記憶内容の消去単位を１つのブロックとし、プログラムの格納されたブロックと、データの格納されたブロックとが混在しているフラッシュ型メモリを制御する管理装置であって、データファイル領域としてデータの格納された各ブロックにはそれぞれ該ブロックの管理情報を記憶するヘッダ領域が設けられており、連続する複数のブロックを使用してプログラムを格納した状態のプログラム領域では、前記連続する複数のブロックのいずれかに管理情報を記憶するヘッダ領域が設けられ、このヘッダ領域に前記連続する複数のブロックの管理情報が集積されて格納されている状態において、前記連続する複数のブロックを使用したプログラム領域内の領域割り当て変更を、前記集積されて格納されている管理情報に基づき行う際に、再度プログラム領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納すると共に、新たにデータファイル領域として割り当てるブロックがある場合には、その新たにデータファイル領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納することを特徴とする。
【００１３】
あるいは、記憶内容の消去単位を１つのブロックとし、プログラムの格納されたブロックと、データの格納されたブロックとが混在しているフラッシュ型メモリを制御する管理装置であって、
データファイル領域としてデータの格納された各ブロックにはそれぞれ該ブロックの管理情報を記憶するヘッダ領域が設けられており、連続する複数のブロックを使用してプログラムを格納した状態のプログラム領域では、前記連続する複数のブロックのいずれかに管理情報を記憶するヘッダ領域が設けられ、このヘッダ領域に前記連続する複数のブロックの管理情報が集積されて格納されている状態において、前記連続する複数のブロックを使用したプログラム領域内の領域割り当て変更を、前記集積されて格納されている管理情報に基づき行う際に、
再度プログラム領域として細分化した複数のプログラム領域を割り当て、その細分化した各プログラム領域においては、前記細分化した各プログラム領域毎にヘッダ領域を設け、前記細分化した各プログラム領域に含まれるブロックの管理情報を、それぞれ該当する各プログラム領域のヘッダ領域に格納すると共に、新たにデータファイル領域として割り当てるブロックがある場合には、その新たにデータファイル領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納することを特徴とする。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態について詳細に説明する。本形態は、例えば図１に示すように、プロセッサ１０，フラッシュメモリ１２およびその制御装置１４を含む拡張もしくは補助の記憶装置１５，ＲＡＭ（主記憶装置）１６を含むコンピュータシステムに適用される。そして、フラッシュメモリ１２の書換寿命を延命させるプログラムやデータの格納方法，更には管理・制御のための装置を得ようとするものである。
【００２０】
まず、プログラム領域あるいはデータファイル領域を管理するため、フラッシュメモリ１２の管理単位をその最小消去（イレース）単位である１ブロック（物理ブロック）とする。この最小単位である物理ブロック（以下単に「ブロック」という）内には、プログラム領域もしくはデータファイル領域と、そのブロックを管理する情報を持つヘッダ領域とが存在する。なお、同一ブロックの記憶領域には、プログラム領域とデータファイル領域の混在は認めないことにする。また、プログラム領域については、複数のブロックが連続するときはそれらを一括して管理し、そのブロック群を管理する情報を持つヘッダ領域を設ける。
【００２１】
図２には、本形態におけるソフトウエアの基本構造の一例が示されている。同図のように、ＯＳ２０やアプリケーションソフト２２とのソケットインターフェースとして、いわゆるドライバ層２４に相当する部分にフラッシュ管理マネージャ２６を設ける。このフラッシュ管理マネージャ２６は、本形態のシステム用ドライバと考えることができる。このフラッシュ管理マネージャ２６によって、ブロック情報の管理やデータのリード／ライトの制御が行なわれる。
【００２２】
このようなシステムにおける補助記憶装置，拡張記憶装置，あるいはそれらの混在装置上で、特願平９−３１７６１２号として開示されたヘッダ構造と管理手法が適用される。図３［Ａ］は、連続する８個のブロック０〜７をプログラム領域として割り当て、それ以外のブロック８〜ｎをデータファイル領域として割り当てた例である。上述したように、複数の連続するブロックに確保されたプログラム領域は、１つのヘッダ領域によって管理される。一方、データファイル領域は、例え複数の連続するブロックに確保されたとしても、各ブロック毎にヘッダ領域によって管理される。従って、プログラム領域３２のブロックヘッダ３２Ａはブロック０にのみ存在し、ブロック１〜７には存在しない。ブロック１〜７の管理情報等は、ブロック０のヘッダ領域３２Ａにまとめられる。一方、ブロック８〜ｎにはデータファイル領域３８Ｂ〜３ｎＢがそれぞれ確保されるが、各ブロックにそれぞれヘッダ領域３８Ａ〜３ｎＡが存在し、これらによってブロック毎に管理される。
【００２３】
次に、図３［Ｂ］の例は、ブロック０をデータファイル領域として割り当て、ブロック１〜Ａをプログラム領域として割り当て、それ以後はデータファイル領域として割り当てた例である。図３［Ｃ］の例は、ブロック０〜ｎ−９をデータファイル領域に、ブロックｎ−８〜ｎ−３をプログラム領域に、それ以後をデータファイル領域に、それぞれ割り当てた例である。
【００２４】
このように、連続して確保されたプログラム領域は一つのヘッダ領域によって管理される。そして、ブロック数の制限や固定したアドレス配置にすることはない。しかし、データファイル領域は、連続して確保されたとしても、各ブロック毎に管理される。
【００２５】
本形態は、以上の背景技術を改良したもので、連続する複数ブロックを保有するプログラム領域に対するブロックヘッダ内に、それら複数ブロックの管理情報が集積して格納される。上述したように、実行プログラムに対しては連続してファイル領域が確保されるため、ブロックが連結されることになる。この連結の方法として、プログラム領域として確保された連続領域の先頭のブロックに、そのブロックヘッダと、実行プログラム用のブロックヘッダを格納する。
【００２６】
具体的な例で説明すると、例えば図４［Ａ］に示すように、プログラム領域としてブロックｔから４ブロックを確保したとする（ｔは１６進数）。この場合、従属するブロックｔ＋１，ｔ＋２，ｔ＋３の消去回数などの管理情報を、同図［Ｂ］に示すように、先頭のブロックｔのブロックヘッダに格納する。なお、従属ブロックｔ＋１，ｔ＋２，ｔ＋３のブロックヘッダを、先頭ブロックｔ中ではなく、プログラム領域内にあるブロックのいずれかに割り付けてもよい。ただし、フラッシュ管理マネージャ２６側（図２参照）がその旨を認識することができるような情報，例えば割り付けられたブロックの位置情報や運用規程などを明らかにする。以下の説明では、理解を容易にするため、プログラム領域の先頭ブロックに従属ブロックのブロックヘッダも割り付けられているものとする。
【００２７】
図４において更に詳述すると、プログラム領域に対するブロックヘッダは、先頭ブロックｔのブロックヘッダ情報と、従属ブロックｔ＋１，ｔ＋２，ｔ＋３のブロックヘッダ情報を、それぞれ集積した形態となっている。例えば、１ブロックのみで構成される各ブロックヘッダのデータサイズをＨ１バイトとし、実行プログラムあるいはデータファイルが格納される領域のデータサイズをＨ２バイトとする。ブロック全体では、（Ｈ１＋Ｈ２）バイトとなる。
【００２８】
一方、前記従属ブロックのブロックヘッダを集積化した情報のサイズをＨ３バイトとすると、４ブロック連結したプログラム領域に対するブロックヘッダのサイズは、Ｈ１＋Ｈ３バイトとなる（図４［Ｂ］参照）。従って、プログラム領域のサイズは、Ｈ２×４＋Ｈ１×３−Ｈ３バイトとなる。一般的に、Ｊ個の連続するブロックで構成されるプログラム領域の場合、そのブロックヘッダのサイズはＨ１バイト＋Ｈ３バイトとなり、その実行プログラムファイルのデータサイズはＨ２バイト×Ｊ＋Ｈ１バイト×（Ｊ−１）−Ｈ３バイトとなる。
【００２９】
次に、ブロックのヘッダ領域について説明する。ブロックヘッダに含まれる情報としては、図５に示すように、
▲１▼状態（有効／無効／遷移中／初期化完了）を示すフラグ
▲２▼プログラム領域／データファイル領域を示すマーカフラグ
▲３▼連続予約ブロックの領域数
▲４▼パーティション名
▲５▼自己のブロックの消去情報
▲６▼自己のブロックの付加情報（必要があるときに付加）
▲７▼従属ブロックのブロック番号あるいはブロック情報（固有名称）と、その消去情報及び付加情報
がある。
【００３０】
これらのうち、まず▲１▼のフラグについて説明する。フラッシュ管理マネージャ２６（図２参照）は、各ブロックヘッダの内容を読み、フラッシュメモリがどのように管理されているかを把握する。フラッシュメモリのメモリセル内のビットデータは、論理値の「１」→「０」への変化の処理時間は比較的短いが、「０」→「１」への変化は、一度ブロック消去又は消去をしなければならず、長時間を要する。つまり、１ビットのデータの書換えを行なうために、そのブロック内のデータを一時待避させるとともに、ブロック消去後に書き戻す必要があり、処理時間としては大きい。
【００３１】
そこで、実際には、状態を示すフラグを利用してブロックの状態を管理することになる。すなわち、上述した書換えに伴うオーバーヘッドを軽減すため、ブロックヘッダ内にそのブロックが有効な状態か，それとも無効な状態か，初期化が完了した状態か，有効な状態から無効な状態への遷移状態か，といった状態をそれぞれのブロック毎に認識し、データの書込み，データの無効化，ブロックの消去，ブロックの初期化などの操作を行なう。
【００３２】
次に、▲２▼のマーカフラグは、該当するブロックがデータファイル領域に割り当てられたか、それとも、プログラム領域に割り当てられたかを示すフラグである。これによって、プログラム領域に指定されたとき、▲３▼の連続予約ブロック数に実行プログラムとして後に続くブロックの数を指定する。しかし、データファイル領域に指定されているときは、連続予約ブロック数を０とする。▲４▼のパーティション名は、実行プログラムやデータファイルに割り当てた固有の名称である。
【００３３】
▲５▼の自己のブロックの消去情報としては、ブロックを消去した回数を記録する。ブロック消去するときは、記録されている以前の消去回数を一時的に保持し、ブロック消去終了後、一時的に保持している以前の消去回数に１インクリメントしてデータを格納する。▲６▼の自己のブロックの付加情報としては、例えば、イレースシーケンスナンバあるいは消去時刻など、そのブロックに関連する情報がある。
【００３４】
▲７▼の従属ブロックのブロック番号と消去情報及び付加情報としては、従属ブロックに関する消去回数や、イレースシーケンスナンバあるいは消去時刻などの従属ブロックに関連する情報が該当する。これら情報の集積の順番は、その情報がいずれの従属ブロックのものか認識できれば、どのような順序でもよい。また、従属ブロックの消去回数を示す情報は、最低限集積する必要がある。図示の例では、先頭ブロックｔに対して、従属ブロックがｔ＋１，ｔ＋２，……，ｔ＋ｎまで存在する。従って、それらの従属ブロックの各々について、ブロック番号と消去情報や付加情報が先頭ブロックｔのヘッダに集積化されている。
【００３５】
このように、本形態によれば、従属ブロックの消去情報が先頭ブロックのヘッダ情報に含まれている。本形態によれば、これを利用して、次のような運用が可能である。
▲１▼連続する複数個のブロックを占めるプログラム領域を、各ブロック毎のデータファイル領域に変更する。
▲２▼連続する複数個のブロックを占めるプログラム領域を分割し、細分化されたプログラム領域を作成する。
▲３▼連続する複数個のブロックを占めるプログラム領域を分割もしくは目的変更し、細分化されたプログラム領域を作成するとともに、データファイル領域に変更する。
▲４▼連続する複数個のブロックを占めるデータファイル領域を、一つのプログラム領域に変更する。
▲５▼従属するブロックの関連管理情報などが、プログラム領域の先頭ブロックのヘッダ内に収まらない場合に、拡張ヘッダ領域をブロックヘッダ領域の後に付加する。
以下、これらの運用について順に説明する。
【００３６】
（１）まず、複数個のブロックで構成される一つのプログラム領域を、ブロック一個で構成されるデータファイル領域あるいはプログラム領域に変更する方法から説明する。
【００３７】
例えば、図６［Ａ］に示すように、ブロックｔ〜ｔ＋ｎの連続した一つのプログラム領域があるとする。これを、同図［Ｂ］に示すように、一つのブロックのみで構成されるプログラム領域に変更する場合を想定する。変更前のブロックヘッダは、上述した図５のようになっている。これに対し、変更後の各ブロックのブロックヘッダは、図７に示すようになる。つまり、各ブロック毎に、上述した状態を示すフラグ，マーカフラグ，連続予約ブロックの領域数，パーティション名，ブロックの消去回数，ブロックの付加情報を含むブロックヘッダが生成される。
【００３８】
このような図５の状態から図７の状態への変更の手順は、まず、ブロックｔのブロックヘッダ情報と、ブロックｔ＋１〜ｔ＋ｎの管理情報を、ＲＡＭ領域などに待避させる。そして、ブロックｔ〜ｔ＋ｎの領域をブロック消去する。ここで、１ブロック消去する毎に、必ずブロックヘッダを付加する。つまり、ブロックｔのブロックを消去し、完了後にブロックヘッダを初期化する。このとき、ブロックｔに対する待避させた管理情報を更新し、ブロックｔのブロックヘッダに格納する。情報の更新には、例えば消去回数を１インクリメントすることなどが含まれる。
【００３９】
このようにして、一つのブロックｔのみで構成されるプログラム領域に変更が行われる。ブロックｔ＋１についても、同様にブロック消去を行い、完了後にブロックヘッダを初期化し、待避させたブロックｔ＋１の管理情報を更新してそのブロックヘッダに格納する。このような操作をブロックｔ＋ｎまで繰り返し行う。なお、図６の例は、一つのブロックで構成されるプログラム領域に変更したが、一つのブロックで構成されるデータファイル領域への変更についても同様である。
【００４０】
（２）次に、複数個のブロックで構成される一つのプログラム領域を、ブロックｔ〜ｔ＋ｍで構成される第１のプログラム領域と、ブロックｔ＋ｍ＋１〜ｔ＋ｎ個で構成される第２のプログラム領域とに、２分割する方法を説明する。
【００４１】
例えば、図８［Ａ］に示すように、ブロックｔ〜ｎ＋１の連続した一つのプログラム領域があるとする。これは、前記図６［Ａ］と同様である。これを、同図［Ｂ］に示すように、２つのプログラム領域に変更する場合を想定する。変更前のブロックヘッダは、上述した図５のようになっている。これに対し、変更後の各プログラム領域のブロックヘッダは、図９及び図１０にそれぞれ示すようになる。つまり、各プログラム領域毎に、上述した状態を示すフラグ，マーカフラグ，連続予約ブロックの領域数，パーティション名，ブロックの消去回数，ブロックの付加情報，従属ブロックのブロック番号と消去情報及び付加情報を含むブロックヘッダが生成される。
【００４２】
すなわち、分割後の第１のプログラム領域のブロックヘッダは、図９に示すように、先頭ブロックｔの情報と、従属ブロックｔ＋１〜ｔ＋ｍの情報を集積化した情報を含む。分割後の第２のプログラム領域のブロックヘッダは、図１０に示すように、先頭ブロックｔ＋ｍ＋１の情報と、従属ブロックｔ＋ｍ＋２〜ｔ＋ｎの情報を集積化した情報を含む。
【００４３】
図５の状態から図９，図１０の状態への分割変更の手順は、まず、ブロックｔのブロックヘッダ情報と、ブロックｔ＋１〜ｔ＋ｎの管理情報を、ＲＡＭ領域などに待避させる。そして、ブロックｔ〜ｔ＋ｎまでの領域をブロック消去する。ここで、まず、図９の状態にするため、ブロックｔ〜ｔ＋ｍをブロック消去する。そして、完了後に、ブロックｔにブロックヘッダを形成して初期化する。このとき、ブロックｔに対する待避させた管理情報を更新し、ブロックｔのブロックヘッダに格納する。その後、従属ブロックｔ＋１〜ｔ＋ｍの管理情報を順に更新し、各ブロックのブロックヘッダに付加する。
【００４４】
一方、更に図１０の状態にするため、ブロックｔ＋ｍ＋１〜ｔ＋ｎをブロック消去する。そして、完了後に、ブロックｔ＋ｍ＋１にブロックヘッダを形成して初期化する。このとき、ブロックｔ＋ｍ＋１に対する待避させた管理情報を更新し、ブロックｔ＋ｍ＋１のブロックヘッダに格納する。その後、従属ブロックｔ＋ｍ＋２〜ｔ＋ｎの管理情報を順に更新し、各ブロックのブロックヘッダに付加する。
【００４５】
なお、以上の例は、一つのプログラム領域を二つのプログラム領域に二分割した例であるが、更に複数に分割する場合も同様である。
【００４６】
（３）次に、複数個のブロックで構成される一つのプログラム領域を、
▲１▼ブロックｔのみで構成されるデータファイル領域（もしくはプログラム領域），
▲２▼ブロックｔ＋１〜ｔ＋ｍで構成されるプログラム領域，
▲３▼ブロックｔ＋ｍ＋１〜ｔ＋ｍ＋ｏ−１まではそれぞれブロック一つで構成されるデータファイル領域，
▲４▼ブロックｔ＋ｍ＋ｏ〜ｔ＋ｎで構成されるプログラム領域
に変更する方法を説明する。
【００４７】
例えば、図１１［Ａ］に示すように、ブロックｔ〜ｔ＋ｎの連続した一つのプログラム領域があるとする。これは、前記図６［Ａ］と同様である。これを、同図［Ｂ］〜［Ｅ］に示すように、多数のデータファイル領域やプログラム領域に変更する場合を想定する。前記▲１▼〜▲４▼が、同図［Ｂ］〜［Ｅ］に対応する。変更前のブロックヘッダは、上述した図５のようになっている。これに対し、分割後の各プログラム領域のブロックヘッダは、図１２及び図１３にそれぞれ示すようになる。
【００４８】
図５の状態から図１２，図１３の状態への分割変更の手順は、まず、ブロックｔのブロックヘッダ情報と、ブロックｔ＋１〜ｔ＋ｎの管理情報を、ＲＡＭ領域などに待避させる。そして、ブロックｔ〜ｔ＋ｎまでの領域をブロック消去する。ここで、まず、図１２の状態にするため、ブロックｔをブロック消去する。そして、完了後に、ブロックｔにブロックヘッダを形成して初期化する。このとき、ブロックｔに対する待避させた管理情報を更新し、ブロックｔのブロックヘッダに格納する。
【００４９】
次に、ブロックｔ＋１〜ｔ＋ｍまでを消去し、完了後にブロックｔ＋１にブロックヘッダを付加し初期化する。このとき、同様に、ブロックｔで待避させたブロックｔ＋１の管理情報を更新し、ブロックｔ＋１のブロックヘッダに格納する。その後、順にブロックｔ＋２〜ｔ＋ｍまでの従属ブロックの管理情報を更新し、先頭ブロックであるブロックｔ＋１のブロックヘッダに付加する。
【００５０】
更に、図１３の状態にするため、前記ブロックｔと同様の操作を、ブロックｔ＋ｍ＋１〜ｔ＋ｍ＋ｏ−１まで繰り返し行う。最後に、ブロックｔ＋ｍ＋ｏ〜ｔ＋ｎに対して、前記ブロックｔ＋１〜ｔ＋ｍと同様の動作を繰り返し行う。
【００５１】
なお、以上の例は、プログラム領域を２つ設けるとともに、いくつかのデータファイル領域も設けた例であるが、複数のプログラム領域と複数のデータファイル領域に分割変更する場合も同様である。なお、連結するブロックについては、その該当ブロックを連続的に消去し、完了後にその先頭ブロックのブロックヘッダに従属ブロックのヘッダ情報も集積した情報を格納することができれば、ブロックの消去の順番やブロックヘッダの初期化の順番などは、上述した方法でなくてもよい。
【００５２】
（４）次に、使用頻度が高いデータファイル領域からプログラム領域に変更する方法を説明する。使用頻度の高いデータファイル領域を検出し、このデータファイル領域に移動可能なプログラム領域を移動する。
【００５３】
まず、移動可能なプログラム領域のサイズ（ブロック数）分の連続するデータファイル領域を決定する。この決定方法として、
▲１▼単純に消去回数の多いブロックを検出し、そのブロックを含むように前後のブロックを割り当てる方法，
▲２▼必要とする分の連続するブロックでの平均の消去回数が最大のところに割り当てる方法，
▲３▼前記▲１▼及び▲２▼を組み合わせて最適化を図る方法，
▲４▼平均化ではなく、標準偏差などによって最適ブロックを選定する方法，
がある。
【００５４】
平均化の例を取って説明すると、例えば連続するブロックを３ブロック選定する場合を想定する。図１４に示すように、ブロックｘからブロックｘ＋ｎまでのブロックがデータファイル領域として存在すると仮定する。各ブロックの消去回数Ｙ０〜Ｙｎに対し、連続する３つのブロックの消去回数の平均値Ｚ０，Ｚ１，…，Ｚｎ２を求める。例えば、平均値Ｚ０は、ブロックｘ〜ｘ＋２の消去回数Ｙ０〜Ｙ２から、Ｚ０＝（Ｙ０＋Ｙ１＋Ｙ２）／３で求められる。他の平均値についても同様である。これら平均値のうちから最大値を検出して、それに該当する連続する３つのブロックをプログラム領域として割り当てるようにすればよい。
【００５５】
連続する複数個のプログラム領域に割り当てるデータファイル領域のブロックの候補が決定すれば、それぞれの該当するブロックのブロックヘッダの管理情報をＲＡＭ領域などに待避する。そして、候補の各データファイル領域について、それぞれブロック消去を行う。完了後、先頭のブロックにのみブロックヘッダを生成して初期化し、その先頭ブロックに対応する待避した管理情報を更新する。管理情報の更新としては、少なくとも消去回数を１インクリメントする。更に、従属ブロックの管理情報も更新し、先頭ブロックのヘッダ情報の後に従属するそれぞれのブロックのヘッダ管理情報を更新して格納する。このような結合の方法は、上述した分割変更と逆の操作を行えばよい。また、割り当てられるブロックの候補が決まった後における該当ブロックの消去の順番は、いずれから行ってもよい。
【００５６】
（５）次に、効果的な運用として、連続する複数個のブロックで構成されるプログラム領域を、いくつかのプログラム領域に細分化する方法を説明する。これは、上述した（１），（２）及び（３）の方法を応用することで実現できる。まず、分割するプログラム領域のブロックヘッダ及びその従属するブロックヘッダの情報をＲＡＭ上などに待避させる。また、分割するプログラム領域のプログラムもＲＡＭ上に待避させる。
【００５７】
そして、細分化されたブロック数をもつプログラム領域として、前記（１），（２）及び（３）の方法と同様に、データファイル領域のブロックからプログラム領域に変更する候補ブロックをそれぞれ細分化された場合毎に選択する。この選択結果をもとに、待避させたブロックヘッダの管理情報及び従属ブロックの管理付加情報をもとに、分割された新プログラム領域毎に、ブロックヘッダ従属ブロックの管理情報について更新と再構成を行い、該当するヘッダ領域へそれぞれ格納する。そして、待避させておいたプログラム領域のプログラムを、分割されたブロックの内容に対応すように分割し、それぞれのプログラムデータを該当領域に移動させればよい。
【００５８】
（６）また、細分化されたブロックによってプログラム領域を構成する方法として、データファイル領域のブロックからプログラム領域に変更する候補ブロックを、それぞれ細分化された場合毎に選択する。そして、前記（４）の方法のように、データファイル領域からプログラム領域への変更を細分化した形態で行えばよい。
【００５９】
選択結果をもとに、それぞれのデータファイル領域のブロックヘッダ内にある管理情報と対応するデータファイル領域内のデータをＲＡＭ上に各々待避させる。そして、そのブロック領域を細分化できるような形態で、それぞれ分割したプログラム領域に割り当て、対応するブロックヘッダと従属ブロックの管理情報を更新して再構成を行う。更に、分割するプログラム領域に対応するように、プログラムをコピーしていけばよい。そして、前記（４）の方法と同様に、細分化される前のプログラム領域が保有しているブロックを消去するとともに、ブロックヘッダの初期化を行う。その後、待避させておいたデータのブロック管理情報とそれに対するデータなどを書換回数の少ないデータファイル領域の候補ブロックにそれぞれ書き戻すことで、操作は完了する。
【００６０】
フラッシュ管理マネージャ２６（図２参照）は、ユーザの操作による実行開始の指示か、あるいは自己の判断で自動的に最適化タイミングを検出し、上述した分割や変更の操作を実行する。本形態は、少なくとも１個のフラッシュメモリ上でＲＯＭ実行可能なプログラムとデータファイルとが混在できる装置であり、その装置上でプログラム領域からデータファイル領域への変更、あるいはデータファイル領域からプログラム領域へ変更することが可能となる。このため、フラッシュメモリ上における各ブロックの消去回数の均一化を図ることができ、更にはフラッシュメモリの長寿命化も可能となる。以下、主要な実施例について説明する。
【００６１】
（１）実施例１……この実施例は、従属ブロックの管理付加情報として、ブロック番号を備えた例である。本例では、図１７の構造を持つブロックヘッダとプログラム領域からデータファイル領域への移動方法を説明する。
【００６２】
図１５，図１６には、フラッシュメモリに対するブロックヘッダなどの格納例が示されている。なお、これらの図中、図１５［Ａ］は図１６［Ａ］に連続し、図１５［Ｂ］は図１６［Ｂ］に連続する。これらの図において、［Ａ］は、６４Ｋバイトを消去ブロック単位とする２Ｍ×８ビットのフラッシュメモリで、ブロック数が１Ｆ個（１６進表示）あるシステムである。各ブロックに「０」から「１Ｆ」と順に番号をつける。各ブロックの先頭には、［Ｂ］に示すように、各ブロックの管理情報であるヘッダ領域として２５６バイトが割り当て可能となっている。もちろん、データファイル領域の場合には該当するブロック内に必ずブロックヘッダを付随させるが、プログラム領域の場合はその限りではない。
【００６３】
そして、ブロック０〜７をプログラム領域（１）に割り当て、ブロック９〜Ｂをプログラム領域（２）に割り当てる。他のブロックはデータファイル領域に割り当てる。それらプログラム領域の先頭ブロックのブロックヘッダには、例えば図１７に示す情報を付加する。順に説明すると、まず１バイト目には、有効／遷移中／無効，初期化完了状態，予約のフラグがある。これらのうち、有効／遷移中／無効のフラグは、このブロック領域が有効状態か，それとも有効から無効になる遷移中（過渡期）の状態か，完全に無効になった状態かを示す。初期化完了状態のフラグは、ブロックのイレース後にブロックヘッダの初期化（フォーマット）が完了したことを指し示す。予約のフラグは、システムを拡張するときに使用するための予備フラグである。
【００６４】
次に、２バイト目には、プログラム／データ，連続予約ブロック領域数のフラグがある。これらのうち、プログラム／データのマーカフラグは、プログラム，データファイルのいずれがそのブロックに割り当てられたかを決定するフラグである。連続予約ブロック領域数のフラグは、プログラム領域に指定した残りのブロック数が１６進数で表記されている。
【００６５】
次に、３〜５バイト目は、そのブロックの消去回数を１６進で表記している。３バイト目がその回数の下位の桁、４バイト目がその回数の中位の桁、５バイト目にはその回数の上位の桁として、それぞれデータを格納する。６バイト目は上述したイレースシーケンスナンバで、ブロックの消去回数が他のブロックと同じときに、どの順番でブロックの初期化がなされたかを記録するものである。７バイト目から１２ｈバイト目までは、該当するブロックの領域名などのパーティション名を記録する。実行プログラムファイルの場合、パーティション名やディレクトリ名などに利用すると、システム運用が容易になる。
【００６６】
更に、本実施例では、プログラム領域として使用した場合、ブロックヘッダを４Ｋバイトまで拡張し、１３ｈ〜Ｂｈ＋４ｎバイトに従属ブロックの付加情報を格納する。図示の例では、１３ｈ〜１６ｈに、ブロックｔ＋１のブロック番号と、消去回数の下位，中位，上位とがそれぞれ格納されている。以下、同様である。
【００６７】
図１に示した装置を使用していくと、消去回数はプログラム領域のブロックよりもデータファイル領域のブロックの方が多くなる。そこで、図１５［Ｂ］のブロック９〜Ｂまでの連続する３ブロックで構成されているプログラム領域（２）をデータファイル領域へ再割り当てする。フラッシュ管理マネージャ２６は、次のような操作を行う。再割り当てを行う候補ブロックの選定方法として、平均消去回数の多いものを優先させることにする。フラッシュ管理マネージャ２６は、データファイル領域に割り当てられているブロック８，Ｃ〜１Ｆまでのブロックの中から、連続する３ブロックの間で平均消去回数が最も大きいものを選択する。
【００６８】
ブロック８の近辺では、連続するブロックの候補がないため、適用から外れる。次に、ブロックＣ，Ｄ，Ｅの平均消去回数、ブロックＤ，Ｅ，Ｆの平均消去回数、ブロックＥ，Ｆ，１０の平均消去回数、……、ブロック１Ｄ，１Ｅ，１Ｆの平均消去回数をそれぞれ計算する。この結果、仮にブロック１Ｄ，１Ｅ，１Ｆの組み合わせが最大の平均消去回数だったとすると、それらのブロックが再割り当てを行うためのブロックの候補となる。
【００６９】
フラッシュ管理マネージャ２６は、ブロック１Ｄ，１Ｅ，１Ｆにおけるそれぞれのブロックヘッダの情報をＲＡＭ上に待避させる。次に、ブロック１Ｄのブロックヘッダが有効状態のときは、データファイル領域のデータをそれぞれＲＡＭ上に待避させる。しかし、そのブロックが無効であれば、データファイル領域のデータをＲＡＭ上に待避させる必要はない。また、そのブロックが遷移中のときは、移動操作を中断する。この操作を、ブロック１Ｅ，１Ｆにも同様に行う。そして、ブロック１Ｄ，１Ｅ，１Ｆをそれぞれ消去する。
【００７０】
ブロック消去完了後、ブロック１Ｄ，１Ｅ，１Ｆをプログラム領域として使用するため、ブロックヘッダを初期化する。このとき、先頭ブロック１Ｄにおけるブロックヘッダの管理情報において、初期化完了フラグをＯＮにし、有効／無効／遷移中の状態フラグでは、遷移中のフラグをたてることにより、ブロック１Ｄ，１Ｅ，１Ｆのプログラム領域はコピー中であることを宣言する。また、プログラム／データのマーカフラグを、プログラム領域であることを示すためにＯＮにし、連続予約ブロック領域数を２（０ｂ０００００１０）にする。更に、前記ＲＡＭ上に待避させたブロック１Ｄの消去回数の情報を更新するとともに、イレースシーケンスナンバ情報を再構築する。なお、パーティション名は、移動元であるブロック９のブロックヘッダ情報の中にあるパーティション名と同等にする。
【００７１】
次に、従属するブロック１Ｅ，１Ｆのブロック番号と、前記ＲＡＭ上に待避させたブロック１Ｅ，１Ｆの消去回数を１インクリメントし、その値を格納する。そして、移動元のプログラム領域（２）（メモリ空間０９０１０００〜０ＢＦＦＦＦＦ）のデータを、移動先のプログラム領域（２）（メモリ空間０Ｄ０１０００〜１ＦＦＦＦＦＦ）にコピーする。コピー完了後、ブロック９にあるブロックヘッダの拡張ヘッダ領域にある管理情報をＲＡＭ上に待避する。そして、ブロック９のブロックヘッダ内にある有効／遷移中／無効フラグを無効フラグＯＮにし、有効から無効状態に遷移する。
【００７２】
次に、ブロック９の中にあるブロックヘッダ情報及びその拡張ヘッダ（ブロック９，Ａ，Ｂの各管理情報やブロック情報）をＲＡＭ上に待避する。そして、ブロック９，Ａ，Ｂをそれぞれ消去する。それぞれのブロックの消去完了後、各ブロックをデータファイル領域として使用するために、各ブロックヘッダを初期化する。すなわち、ブロックヘッダ内の初期化完了フラグをＯＮにし、プログラム／データのマーカフラグをデータ状態にし、連続予約ブロック数に０を格納する。更に、待避しているブロック９における管理情報の消去回数の情報を更新し、イレースシーケンスナンバを再構築する。これをブロックＡ，Ｂにも適用する。
【００７３】
ここで、データファイル領域から退避したデータを戻す方法は、次のようになる。データファイル領域として割り当てられているブロックの中から、消去回数がもっとも少ないものに、待避したブロック１Ｄのデータファイル領域を割り当てる。ここではその割り当てるブロックの候補として、ブロックＢが選択されたとすると、まず有効／遷移中／無効フラグを有効状態にする。ブロックＢのブロックヘッダ情報として、先ほど待避させたブロック１Ｄに対応するファイル名を格納する。そして、待避させたブロック１Ｄのデータファイル領域のデータをブロックＢのデータファイル領域に格納し、復元する。このように、割り当てるブロックの候補を選択し、ブロック１Ｅ，１Ｆのデータファイル領域も復元する。ただし、ブロック１Ｄ，１Ｅ，１Ｆのデータファイル領域が無効となっている場合は、そのデータの復元操作を行う必要はない。
【００７４】
以上の説明は、連続する３ブロックからなるプログラム領域のプログラムを、消去回数の多いデータファイル領域のブロックに移動する方法であるが、このような手法は、複数ブロックを持つプログラム領域の場合において一般的に適用することができる。
【００７５】
（２）実施例２……この例は、従属ブロックの管理付加情報として、ブロックのイレースシーケンスナンバを備えた例である。本例では、図１８の構造を持つブロックヘッダとデータファイル領域からプログラム領域への移動方法を説明する。
【００７６】
前記実施例と同様に、ブロック１Ｄ，１Ｅ，１Ｆの組み合わせが最大の平均消去回数であったとする。本例では、まず、ブロック９上にあるブロックヘッダと拡張ブロックヘッダの情報（ブロック９におけるブロックヘッダの管理情報と、従属ブロックＡ，Ｂに関するそれぞれのブロックヘッダの情報）をＲＡＭ上に待避する。そして、ブロック９，Ａ，Ｂ上のプログラム領域におけるプログラム（メモリ空間０９０１０００〜０ＢＦＦＦＦＦ）をＲＡＭ上に待避する。
【００７７】
次に、ブロック９のブロック消去を行い、完了後、データファイル領域として使用するために、ブロックヘッダの初期化を行う。すなわち、ブロックヘッダ内の初期化完了フラグをＯＮにし、プログラム／データのマーカフラグをデータ側とし、連続予約ブロック数に０を格納する。そして、待避しているブロック９における管理情報の消去回数の情報を更新し、イレースシーケンスナンバを再構築する。ブロックＡ，Ｂについても同様である。
【００７８】
ブロック１Ｄにおけるデータファイル領域のデータの移動を説明すると、ブロック１Ｄのブロックヘッダ内にある有効／無効／遷移中の状態フラグを遷移中状態とすることにより、ブロック１Ｄのプログラム領域のデータを移動することを宣言する。そして、ブロック９のブロックヘッダ内にある有効／無効／遷移中の状態フラグを有効状態にする。更に、ブロック１Ｄのデータファイル領域のデータ（メモリ空間１Ｄ００１００〜１ＤＦＦＦＦＦ）をブロック９のデータファイル領域のデータ（メモリ空間０９００１００〜０９ＦＦＦＦＦ）にコピーする。そして、ブロック１Ｄのブロックヘッダ内にある有効／無効／遷移中の状態フラグを無効状態にする。同様の操作を、ブロック１ＥからブロックＡに、ブロック１ＦからブロックＢに対して行い、データファイル領域のデータをそれぞれコピーする。
【００７９】
これにより、ブロック１Ｄ，１Ｅ，１Ｆは無効状態となる。このため、フラッシュ管理マネージャ２６は、それらのブロックをプログラムファイル領域として確保できるように、ブロック消去及び初期化を行う。ブロック消去完了後、ブロック１Ｄ，１Ｅ，１Ｆをプログラム領域として利用するため、ブロックヘッダを初期化する。このとき、先頭ブロック１Ｄにおけるブロックヘッダの管理情報において、初期化完了フラグをＯＮにし、有効／無効／遷移中の状態フラグを有効状態にする。また、プログラム／データのマーカフラグをＯＮにするとともに、連続予約ブロック領域数を２（０ｂ０００００１０）にする。
【００８０】
更に、前記ＲＡＭ上に待避させたブロック１Ｄの消去回数の情報を更新し、イレースシーケンスナンバの情報を再構築する。そして、パーティション名にを、待避させた情報，すなわちブロック９のブロックヘッダ情報中にあったパーティション名と同等にする。また、従属ブロック１Ｅ，１Ｆのブロック番号とＲＡＭ上に待避させた従属ブロック１Ｅ，１Ｆの消去回数を１インクリメントし、その値を格納するとともに、従属ブロック１Ｅ，１Ｆのイレースシーケンスナンバの情報を再構築する。その後、先ほど待避させたプログラム領域（２）（メモリ空間０９０１０００〜０ＢＦＦＦＦＦをＲＡＭ上に待避）のデータを、ブロック１Ｄ，１Ｅ，１Ｆのプログラム領域（２）（メモリ空間０Ｄ０１０００〜１ＦＦＦＦＦＦ）へ移動することにより、復元が行われる。
【００８１】
以上の例は、連続する３ブロックからなるプログラム領域のプログラムを、消去回数の多いデータファイル領域のブロックに移動する場合であるが、複数ブロックを持つプログラム領域の場合に、一般的に適用することができる。
【００８２】
（３）実施例３……図１９及び図２０は、付加情報として初期化された時刻情報を備えたブロックヘッダの例である。本例では、図１９，図２０の構造を持つブロックヘッダとプログラム領域からデータファイル領域への移動を説明する。なお、図２０は図１９に連続する図である。これの例では、前記実施例（１）のブロック番号の代わりに、そのブロックの初期化時刻が含まれており、プログラム領域における従属ブロックの管理情報の中に付加情報として初期化時刻が格納されている。運用方法としては、前記実施例（１）に示した操作をほぼ適用できる。ただし、初期化時刻の情報は，ブロックヘッダ初期化時点で付加される情報であり、従属ブロックヘッダの情報を更新するときに格納される。
【００８３】
（４）実施例４……前記実施例３の運用方法として、実施例（１）の代わりに実施例（２）を適用することも可能である。この例は、図１９，図２０の構造を持つブロックヘッダとデータファイル領域からプログラム領域への移動方法の例である。この場合は、実施例（２）のイレースシーケンスナンバの情報の代わりに、そのブロックの初期化時刻の情報を備えたことになる。これを付加情報とすることにより、実施例（２）をほとんどそのまま適用できる。
【００８４】
（５）実施例５……連続する複数個のブロックからなるプログラム領域をいくつかのプログラム領域に細分化する方法、あるいは、そのプログラム領域をいくつかのプログラム領域とデータファイル領域とに分割細分化する方法は、前述の実施例（１）〜（４）を応用すれば実現できる。例えば、データの移動先の候補ブロックを選択し、その該当するブロックヘッダ（プログラム領域の場合は従属ブロックヘッダも含む）の情報をＲＡＭ上などに待避する。また、データあるいはプログラムの内容をＲＡＭ上に待避する。この後、細分化や分割化したブロック構成を実現するために、該当ブロックのブロック消去及びブロックヘッダの初期化を行う。このとき、待避したブロックヘッダや従属ブロックヘッダの情報を元に、情報の更新や再構成を行う。その後、プログラムやデータの内容をそれぞれ対応させるようにする。
【００８５】
この発明は数多くの実施形態が存在し、以上の開示に基づいて多様に改変することが可能である。例えば次のようなものが含まれる。
【００８６】
（１）上述した実施例の他に、図１８の構造を持つブロックヘッダとプログラム領域からデータファイル領域への移動，図１７の構造を持つブロックヘッダとデータファイル領域からプログラム領域への移動なども可能である。
【００８７】
（２）複数個の連続するブロックの再割り当てを行う対象候補ブロックの選定方法として、上述した方法のほかに、消去回数の最大値を探索し、その対象となる前後ブロックにおける平均値の最大値をもつブロックを候補として選択するようにしてもよい。例えば、候補ブロックを３ブロック選定する場合、消去回数の最大値を持つものがブロックｔであるとすると、ブロックｔ−２，ｔ−１，ｔの平均値と、ブロックｔ−１，ｔ，ｔ−１の平均値と、ブロックｔ，ｔ＋１，ｔ＋２の平均値とをそれぞれ求め、それらの中から最大の平均値をもつ３ブロックを候補とする。
【００８８】
（３）複数個の連続するブロックの再割り当てを行う際の対象候補ブロックの選定方法として、消去回数の値を標準偏差などの統計的手法を利用するようにしてもよい。
【００８９】
（４）前記形態はフラッシュメモリに本発明を適用したものであるが、他の類似するメモリがフラッシュメモリと同じ書込み，読出し機能を備えており、かつ、書込前ブロック消去特性を有するメモリであれば、同様に適用可能である。
【００９０】
（５）フラッシュメモリのイレース単位である物理ブロックは、バイト単位やワード単位の他、どのようなデータ単位であっても、同様に適用可能である。
【００９１】
【発明の効果】
以上説明したように、本発明によれば、次のような効果がある。
【００９２】
（１）プログラム領域の従属ブロックの管理情報を持つこととしたので、領域変更を行う際に、該当するブロックの管理情報を正しく反映させることができ、フラッシュ型メモリにおける各ブロックの消去回数を管理できる。また、プログラム領域とデータファイル領域の割り当て変更を適宜に行って、使用目的に柔軟に対応するとともに、各ブロックの書き込みや消去の均一化を図ることができ、各ブロックの消去回数の平準化や長寿命化に極めて有効である。
【００９３】
（２）プログラム領域の先頭ブロックのヘッダ領域あるいはそれに続くブロックの拡張ヘッダ領域に管理情報を集積化したので、ブロックの管理情報に少ないオーバヘッドでアクセスでき、更にはプログラム領域の先頭を常に固定的に特定することが可能になる。
【００９４】
（３）マルチプロセッシング，マルチスレッド，マルチタスクといった高度な拡張記憶装置上のプログラムの実行環境においても、安全にデータファイルの管理を行うことができる。
【００９５】
（４）フラッシュ型メモリのブロック消去回数を平準化させ、フラッシュ型メモリの寿命を長くすることができるだけでなく、コピー元のデータファイル領域のデータをマルチタスク、マルチスレッドという環境の中で、別プログラムがその中のデータを参照しながらコピー先にデータをコピーすることが可能となる。この結果、システムの効果的な運用と、従来よりも数倍以上の実用的長寿命を得ることができる。
【図面の簡単な説明】
【図１】この発明の一形態を利用したシステムの基本構成を示す図である。
【図２】前記形態におけるソフトウェアの構造を示す図である。
【図３】プログラム領域とデ−タファイル領域を物理ブロックに割り当てた例を示す図である。
【図４】プログラム領域として確保された複数のブロックの一元管理の様子を示す図である。
【図５】前記図４におけるブロックヘッダの管理情報を示す図である。
【図６】一つのプログラム領域を、ブロック毎のプログラム領域に分割する場合のマッピング例を示す図である。
【図７】前記図６におけるブロックヘッダの管理情報を示す図である。
【図８】一つのプログラム領域を、二つのプログラム領域に分割する場合のマッピング例を示す図である。
【図９】前記図８におけるブロックヘッダの管理情報を示す図である。
【図１０】前記図８におけるブロックヘッダの管理情報を示す図である。
【図１１】一つのプログラム領域を、二つのプログラム領域と多数のデータファイル領域に分割する場合のマッピング例を示す図である。
【図１２】前記図１１におけるブロックヘッダの管理情報を示す図である。
【図１３】前記図１１におけるブロックヘッダの管理情報を示す図である。
【図１４】データファイル領域からプログラム領域に変更するための候補ブロックを選定する手法を示す図である。
【図１５】ブロック構成の一例と、プログラム領域及びデータファイル領域のマッピング例を示す図である。
【図１６】ブロック構成の一例と、プログラム領域及びデータファイル領域のマッピング例を示す図である。
【図１７】本発明の実施例における管理情報の態様を示す図である。
【図１８】本発明の実施例における管理情報の態様を示す図である。
【図１９】本発明の実施例における管理情報の態様を示す図である。
【図２０】本発明の実施例における管理情報の態様を示す図である。
【符号の説明】
１０…プロセッサ
１２…フラッシュメモリ
１４…フラッシュメモリ制御装置
１６…ＲＡＭ
２０…オペレーティングシステム
２２…アプリケーションソフト
２４…ドライバ層
２６…フラッシュ管理マネージャ
Claims (2)
- 記憶内容の消去単位を１つのブロックとし、プログラムの格納されたブロックと、データの格納されたブロックとが混在しているフラッシュ型メモリを制御する管理装置であって、
データファイル領域としてデータの格納された各ブロックにはそれぞれ該ブロックの管理情報を記憶するヘッダ領域が設けられており、連続する複数のブロックを使用してプログラムを格納した状態のプログラム領域では、前記連続する複数のブロックのいずれかに管理情報を記憶するヘッダ領域が設けられ、このヘッダ領域に前記連続する複数のブロックの管理情報が集積されて格納されている状態において、前記連続する複数のブロックを使用したプログラム領域内の領域割り当て変更を、前記集積されて格納されている管理情報に基づき行う際に、
再度プログラム領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納すると共に、新たにデータファイル領域として割り当てるブロックがある場合には、その新たにデータファイル領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納することを特徴とするフラッシュ型メモリの管理装置。 - 記憶内容の消去単位を１つのブロックとし、プログラムの格納されたブロックと、データの格納されたブロックとが混在しているフラッシュ型メモリを制御する管理装置であって、
データファイル領域としてデータの格納された各ブロックにはそれぞれ該ブロックの管理情報を記憶するヘッダ領域が設けられており、連続する複数のブロックを使用してプログラムを格納した状態のプログラム領域では、前記連続する複数のブロックのいずれかに管理情報を記憶するヘッダ領域が設けられ、このヘッダ領域に前記連続する複数のブロックの管理情報が集積されて格納されている状態において、前記連続する複数のブロックを使用したプログラム領域内の領域割り当て変更を、前記集積されて格納されている管理情報に基づき行う際に、
再度プログラム領域として細分化した複数のプログラム領域を割り当て、その細分化した各プログラム領域においては、前記細分化した各プログラム領域毎にヘッダ領域を設け、前記細分化した各プログラム領域に含まれるブロックの管理情報を、それぞれ該当する各プログラム領域のヘッダ領域に格納すると共に、新たにデータファイル領域として割り当てるブロックがある場合には、その新たにデータファイル領域として割り当てられたブロックにおいては、各ブロック毎にヘッダ領域を設け、これらのヘッダ領域に該ブロックの管理情報を各々格納することを特徴とするフラッシュ型メモリの管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20335798A JP3555456B2 (ja) | 1998-07-17 | 1998-07-17 | フラッシュ型メモリの管理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20335798A JP3555456B2 (ja) | 1998-07-17 | 1998-07-17 | フラッシュ型メモリの管理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000035919A JP2000035919A (ja) | 2000-02-02 |
| JP3555456B2 true JP3555456B2 (ja) | 2004-08-18 |
Family
ID=16472701
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20335798A Expired - Lifetime JP3555456B2 (ja) | 1998-07-17 | 1998-07-17 | フラッシュ型メモリの管理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3555456B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005071522A1 (ja) * | 2004-01-27 | 2005-08-04 | Nec Corporation | 高速再起動方法および情報処理装置ならびにプログラム |
| KR100791325B1 (ko) * | 2006-10-27 | 2008-01-03 | 삼성전자주식회사 | 비휘발성 메모리를 관리하는 장치 및 방법 |
| JP2008225576A (ja) * | 2007-03-08 | 2008-09-25 | Ricoh Co Ltd | Ｎａｎｄ型フラッシュメモリの制御装置 |
| JP4710918B2 (ja) * | 2008-02-20 | 2011-06-29 | Ｔｄｋ株式会社 | メモリコントローラ、メモリコントローラを備えるフラッシュメモリシステム、並びにフラッシュメモリの制御方法 |
| JP2011175377A (ja) * | 2010-02-23 | 2011-09-08 | Renesas Electronics Corp | フラッシュメモリ制御装置及び方法 |
| JP5976729B2 (ja) | 2014-07-22 | 2016-08-24 | 京セラドキュメントソリューションズ株式会社 | 電子機器 |
| JP6448571B2 (ja) | 2016-03-08 | 2019-01-09 | 東芝メモリ株式会社 | ストレージシステム、情報処理システムおよび制御方法 |
-
1998
- 1998-07-17 JP JP20335798A patent/JP3555456B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000035919A (ja) | 2000-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100849221B1 (ko) | 비휘발성 메모리의 관리 방법 및 비휘발성 메모리 기반의장치 | |
| US9489301B2 (en) | Memory systems | |
| KR100453053B1 (ko) | 플래쉬 메모리용 파일 시스템 | |
| KR100495722B1 (ko) | 개선된 플래시 파일 시스템 | |
| JP4695801B2 (ja) | 不揮発性メモリ上で実行されるブロック書き込み動作時間を低減させる方法および装置 | |
| US7529882B2 (en) | Dynamic volume management for flash memories | |
| EP1729304B1 (en) | Space management for managing high capacity nonvolatile memory | |
| JP2007280428A (ja) | メモリ管理 | |
| JP2003085037A (ja) | メモリ管理方法 | |
| JPH11126488A (ja) | フラッシュメモリを複数使用した外部記憶装置のデータ記憶制御方法及び装置 | |
| JP2008242944A (ja) | 統合メモリ管理装置及び方法 | |
| JP3555456B2 (ja) | フラッシュ型メモリの管理装置 | |
| KR20020092261A (ko) | 멀티-플레인 구조의 플래시 메모리 관리 방법 | |
| JP3503448B2 (ja) | フラッシュ型メモリ及びその管理装置 | |
| JPH113287A (ja) | 記憶装置およびそれに用いられる記憶領域管理方法 | |
| JP2001101071A (ja) | フラッシュ型メモリを用いたデータ記憶装置及びフラッシュ型メモリのデータ管理方法 | |
| JP3552490B2 (ja) | フラッシュ型メモリを備えた記憶装置，フラッシュ型メモリの管理方法 | |
| JP4419415B2 (ja) | 記録方式 | |
| JPH11272537A (ja) | フラッシュ型メモリ及びその管理装置 | |
| JPH10289144A (ja) | メモリの制御方法 | |
| JP3904182B2 (ja) | データ管理システムおよびそれを用いたデータ管理方法 | |
| JP4443705B2 (ja) | データファイリングシステム及びデータファイリング方法 | |
| JP4474928B2 (ja) | ファイル記録方法 | |
| JP2004038237A (ja) | 情報処理装置およびプログラム | |
| JP2004038236A (ja) | 情報処理装置およびプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040127 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040324 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040420 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040503 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090521 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090521 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100521 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110521 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120521 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120521 Year of fee payment: 8 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120521 Year of fee payment: 8 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120521 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130521 Year of fee payment: 9 |
|
| EXPY | Cancellation because of completion of term |