JP2009518698A - 改良されたホストインターフェイス - Google Patents

改良されたホストインターフェイス Download PDF

Info

Publication number
JP2009518698A
JP2009518698A JP2008525201A JP2008525201A JP2009518698A JP 2009518698 A JP2009518698 A JP 2009518698A JP 2008525201 A JP2008525201 A JP 2008525201A JP 2008525201 A JP2008525201 A JP 2008525201A JP 2009518698 A JP2009518698 A JP 2009518698A
Authority
JP
Japan
Prior art keywords
host
file
data
memory
protocol
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.)
Granted
Application number
JP2008525201A
Other languages
English (en)
Other versions
JP5068754B2 (ja
Inventor
ウェルシュ シンクレア,アラン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SanDisk Corp
Original Assignee
SanDisk Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US11/316,577 external-priority patent/US20070033326A1/en
Application filed by SanDisk Corp filed Critical SanDisk Corp
Publication of JP2009518698A publication Critical patent/JP2009518698A/ja
Application granted granted Critical
Publication of JP5068754B2 publication Critical patent/JP5068754B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604Improving or facilitating administration, e.g. storage management
    • G06F3/0607Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0661Format or protocol conversion arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671In-line storage system
    • G06F3/0673Single storage device
    • G06F3/0679Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/08Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers from or to individual record carriers, e.g. punched card, memory card, integrated circuit [IC] card or smart card

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Communication Control (AREA)

Abstract

異なるプロトコルを使用するホストに適合するメモリシステムは、異なるプロトコルのためのプロトコルアダプタを含む。プロトコルアダプタは、異なる形式で提供されるデータに共通のバックエンドシステムを使用できるようにする。プロトコルアダプタは、ホストに対する応答を、バックエンドのためのコマンドを、適宜生成する。

Description

本願は、半導体フラッシュメモリなどの再プログラム可能な不揮発性メモリシステムの動作に関し、より具体的にはホストデバイスとメモリとのインターフェイスの管理に関する。本願明細書で参照される特許、特許出願、記事、その他の出版物、文書および事柄はいずれもあらゆる目的のためにその全体が本願明細書において参照により援用されている。
初期世代の商用フラッシュメモリシステムでは、メモリセルからなる矩形のアレイが、標準ディスクドライブセクタのデータ量、すなわち512バイトを、各々記憶する多数のセルグループに分割されていた。さらに通常ならば、誤り訂正符号(ECC)を記憶し、、ことによるとユーザデータおよび/またはこれを記憶するメモリセルグループに、関係する他のオーバーヘッドデータを記憶するため、16バイトなどの一定量のデータが各グループに加わる。このような各グループの中にあるメモリセルは、ともに消去可能な最低数のメモリセルである。すなわち、消去単位は事実上、1つのデータセクタを、そしてオーバーヘッドデータが含まれる場合はオーバーヘッドデータを、記憶するメモリセル数である。米国特許第5,602,987号(特許文献1)および第6,426,893号(特許文献2)には、このタイプのメモリシステムの例が記載されている。フラッシュメモリの特徴として、メモリセルにデータを再度プログラムする前にメモリセルを消去する必要がある。
フラッシュメモリシステムは多くの場合、パーソナルコンピュータやカメラ等、様々なホストと着脱可能な状態で接続するメモリカードまたはフラッシュドライブの形で提供されるが、このようなホストシステムの中に埋め込まれることもある。ホストは通常、メモリへデータを書き込む場合、メモリシステムの連続する仮想アドレス空間の中でセクタ、クラスタまたはその他のデータ単位に一意な論理アドレスを割り当てる。ホストは、ディスクオペレーティングシステム(DOS)のように、メモリシステムの論理アドレス空間の中のアドレスにデータを書き込み、かつこれからデータを読み出す。メモリシステムの中のコントローラは、ホストから受け取った論理アドレスをメモリアレイの中のデータが実際に記憶される物理アドレスに翻訳し、これらのアドレス翻訳の経緯を把握する。メモリシステムのデータ記憶容量は少なくとも、メモリシステムのために設定される論理アドレス空間全体にわたってアドレスされるデータ量に相当する。
後続世代のフラッシュメモリシステムでは、消去単位のサイズが複数セクタのデータを十分に記憶するメモリセルブロックまで拡大した。メモリシステムの接続先にあたるホストシステムがセクタなどの小さな最小単位でデータをプログラムし読み出すとしても、フラッシュメモリの1消去単位には多数のセクタが記憶される。ホストが論理セクタのデータの更新や置き換えを行うときに、ブロック内のいくつかのデータセクタが用済みになることは多々ある。ブロックに記憶されたデータに上書きを行うには事前にブロック全体を消去しなければならないから、新規または更新済みデータは通常、あらかじめ消去されデータのための容量が残っている別のブロックに記憶される。この過程で元のブロックには用済みデータが残り、メモリ内の貴重な空間を取る。しかし、このブロックは、その中に有効データが残っていると消去できない。
したがって、メモリ記憶容量の有効利用を図るため、有効な不完全ブロックのデータ量を消去済みブロックにコピーすることによってこれを整理または回収するのが一般的であり、こうすればデータのコピー元にあたるブロックを消去でき、その記憶容量の全体を再利用できる。ブロック内のデータセクタをそれぞれの論理ブロックの順にグループ分けするためにデータをコピーすることも望ましく、こうすればデータを読み出して、読み出したデータをホストへ転送する速度が上がる。そのようなデータコピーがあまりにも頻繁に行われると、メモリシステムの動作性能が低下することがある。これは特に、メモリの記憶容量が、システムの論理アドレス空間を通じてホストによってアドレス指定可能なデータ量と大差ない場合、つまりよくある場合、メモリシステムの動作に影響する。この場合は、ホストプログラミングコマンドが実行される前にデータを整理または回収する必要がある。そうするとプログラミングの時間が長引く。
所与の半導体エリアに記憶できるデータのビット数を増やすため、ブロックのサイズはメモリシステムの世代交代を通じて拡大している。256以上のデータセクタを記憶するブロックが一般的になりつつある。加えてデータのプログラミングと読み出しにあたって並列度を高めるため、アレイまたはサブアレイからなる2つ、4つ、またはそれ以上のブロックがしばしばメタブロックとして論理的にともにリンクされる。そのような大容量操作単位には、それらを効率的に操作するという課題がともなう。
新しい技術革新によってメモリの容量と速度が拡大するにつれ、このような技術革新を使用しつつ、このような技術革新を使用しない製品とも適合する、製品を提供することが一般的に望ましい。これは、新しい製品が技術革新を活かすと同時に後方互換性でもあるので、古い技術を使用する製品とともに使用できることを意味する。このような後方互換性は、特に、様々な構成の中で様々な技術とともに使用される携帯用製品にとって重要である。着脱可能なフラッシュメモリカードはこのような携帯用製品の一例である。
米国特許第5,602,987号 米国特許第6,426,893号 米国特許出願第11/060,174号 米国特許出願第11/060,248号 米国特許出願第11/060,249号 米国仮特許出願第60/705,388号 米国特許出願第10/915,039号 米国特許第5,570,315号 米国特許第5,774,397号 米国特許第6,046,935号 米国特許第6,373,746号 米国特許第6,456,528号 米国特許第6,522,580号 米国特許第6,771,536号 米国特許第6,781,877号 米国公開特許出願第2003/0147278号 米国公開特許出願第2003/0109093号 米国特許第6,763,424号 米国特許出願第10/749,831号 米国特許出願第10/750,155号 米国特許出願第10/917,888号 米国特許出願第10/917,867号 米国特許出願第10/917,889号 米国特許出願第10/917,725号 米国特許出願第10/749,189号 米国特許出願第10/841,118号 米国特許出願第11/016,271号 米国特許出願第10/897,049号 米国特許出願第11/022,369号 アラン・W・シンクレア(Alan W. Sinclair)およびバリー・ライト(Barry Wright)によって出願された「フラッシュメモリにおける直接データファイル記憶(Direct Data File Storage in Flash Memories)」という米国仮特許出願 米国特許出願第11/196,869号 米国特許出願第11/302,764号
メモリシステムは、ホストと、メモリアレイにデータを記憶するバックエンドと、通信する、インターフェイス層を含む。インターフェイス層とバックエンドとの間にある翻訳層は、ホストで使われている各種プロトコルに従ってインターフェイス層で受信するデータおよびコマンドをバックエンドが認識できる形に変換する。この翻訳層によって、様々なプロトコルを使用する様々なホストに共通のバックエンドを使用することが可能となる。これは特に、着脱可能なメモリカード内のメモリシステムにとって有益である。翻訳層は1つ以上のプロトコルアダプタを収容する。プロトコルアダプタは、ホストで使われているプロトコルに従ってホストから通信(コマンドおよびデータ)を受信し、これに応じてデータおよびコマンドをバックエンド向けに変換する。プロトコルアダプタはホストに対して信号を生成することもでき、ここでこのような信号はホストプロトコルの一部である。
メモリシステムはオブジェクトプロトコルアダプタを含み、このオブジェクトプロトコルアダプタは、オブジェクトプロトコルに従って送信されるデータおよびコマンドを不揮発性メモリにおけるファイル本位記憶に適合する形に変換する。具体的に、オブジェクトプロトコルアダプタはオブジェクトを受信する前にオブジェクトに関するメタデータを受信する。このメタデータにはオブジェクトのサイズが含まれる。オブジェクトプロトコルアダプタは、受信データ量をメタデータ情報によって指示されるサイズに比較することによってオブジェクト全体が受信済みと判断する。オブジェクト全体が受信済みと判断したオブジェクトプロトコルアダプタはホストに向けて応答を生成し、メモリシステムのバックエンドに向けてファイル終了標識を生成し、かくしてファイルはバックエンドによって閉鎖される。これによりバックエンドはそのファイルでガーベッジコレクションのスケジュールを組むことができ、それによりファイルデータの記憶および管理で効率を上げることができる。
メモリシステムはLBAプロトコルアダプタを含み、このLBAプロトコルアダプタは、LBAプロトコルに従ってデータおよびコマンドを不揮発性メモリにおけるファイル本位記憶に適合するデータおよびコマンドに変換する。一例において、メモリシステムのために規定される論理アドレス空間からホストによって割り当てられた論理アドレスを有する受信データが、論理ファイルにマッピングされる。論理ファイルは、バックエンドによって他のファイルと同様に扱われる。論理ファイルは普通、メタブロック全体を占めるから、他のデータとメタブロックを共用しない。しかし、あるときは論理ファイルのため、またあるときは別のファイルのため、同じブロックを使用することはあり、ファイルのタイプの違いに応じた不動の区画はメモリアレイに存在しない。
メモリシステムはファイルプロトコルアダプタを含み、このファイルプロトコルアダプタは、ファイルプロトコルに従ってデータおよびコマンドを不揮発性メモリにおけるファイル本位記憶に適合するデータおよびコマンドに変換する。バックエンドがホストと同じプロトコルを使用する(例えば、双方が直接データファイルプロトコルを使用する)場合、翻訳は必要ない。しかし、ホストによって異なるファイルプロトコルが使用される場合は、ファイルプロトコルアダプタが適切な翻訳を行う。
メモリシステムは、場合によっては2つ以上のプロトコルアダプタを使用する2つ以上のホストと通信することがある。この場合、翻訳層はバックエンドと通信するために一度に1つのプロトコルアダプタを選択できる。翻訳層は場合によっては、異なるプロトコルアダプタをかわるがわるに選択しながらバックエンドへの交互のアクセスを提供することになり、異なるホスト間で調停を行うことができる。
インターフェイス層は、複数のホストに適合する論理インターフェイスを含む。場合によっては、ホストデバイス側の対応するインターフェイスとの接続のために物理インターフェイスが別途あってもよい。しかし、これは必須ではなく、場合によってはUSBコネクタなどの単一の物理インターフェイスが提供され、全論理インターフェイスによって使用される。インターフェイス層と翻訳層の機能は専用回路によって遂行でき、あるいはコントローラ上のファームウェアによって遂行できる。これは、メモリアレイを管理するメモリコントローラであってよい。メモリアレイはNANDメモリアレイであってよく、1つ以上の半導体チップ上に形成されてよい。メモリシステムは、時を異にして異なるホストへ接続される着脱可能なカードに収容されてよい。
バックエンドシステムはデータをファイルとして管理でき、ファイルは、場合によってはホストファイルに相当する(しかし、場合によってはホストファイルとの1対1の対応はない)。米国特許出願第11/060,174号(特許文献3)、第11/060,248号(特許文献4)、および第11/060,249号(特許文献5)と米国仮特許出願第60/705,388号(特許文献6)で説明されている直接データファイルバックエンドは、ファイル本位バックエンドシステムの一例である。
フラッシュメモリの概説
現在のフラッシュメモリシステムおよびホストデバイスとの典型的な動作を、図1〜8との関係で説明する。このようなシステムで本発明の様々な態様を実施できる。図1のホストシステム1は、フラッシュメモリ2の中にデータを記憶し、かつフラッシュメモリ2からデータを引き出す。フラッシュメモリはホストの中に埋め込むこともできるが、メモリ2はそれよりも一般的なカードの形で図に示され、このカードは、機械的および電気的コネクタの嵌合部分3および4を通じて着脱可能な状態でホストへ接続される。例えばコンパクトフラッシュ(CF)、マルチメディアカード(MMC)、セキュアデジタル(SD)、ミニSD、メモリスティック、スマートメディア、トランスフラッシュカード等、様々なフラッシュメモリカードが現在多く市販されている。これらのカードの各々はそれぞれの規格化された仕様に従い独特の機械的および/または電気的インターフェイスを有するが、各々に内蔵されたフラッシュメモリシステムは類似する。これらのカードはいずれも、本願の譲受人であるサンディスク コーポレイション(SanDisk Corporation) から入手できる。サンディスク コーポレイションはまた、クルーザー(Cruzer)という商標のもとで一連のフラッシュドライブを提供し、フラッシュドライブは、ホストのユニバーサル・シリアル・バス(USB)差込口に差し込まれることによってホストと接続するUSBプラグを有する小形の手持ち式メモリシステムである。これらのメモリカードとフラッシュドライブの各々は、ホストと連動して内蔵されたフラッシュメモリの動作を制御するコントローラを内蔵する。
このようなメモリカードとフラッシュドライブとを使用するホストシステムは数多くあり様々である。パーソナルコンピュータ(PC)、ラップトップおよび他の携帯用コンピュータ、携帯電話、個人用携帯情報端末(PDA)、デジタル静止画カメラ、デジタル動画カメラ、携帯形オーディオプレイヤ等が含まれる。ホストは通常ならば1種類以上のメモリカードまたはフラッシュドライブのための一体化された差込口を内蔵するが、一部のホストはメモリカードを差し込むアダプタを要する。
図1のホストシステム1は、メモリ2が接続される限りにおいて、回路とソフトウェアとの組み合わせからなる、2つの主要部分を有するものとみなすことができる。それらはアプリケーション部5と、メモリ2と連動するドライバ部6である。例えばパーソナルコンピュータの場合、アプリケーション部5は、ワープロ、グラフィック、コントロールまたはその他一般的なアプリケーションソフトウェアを実行するプロセッサを含むことがある。カメラ、携帯電話、または専ら1組の機能を遂行するためのその他のホストシステムの場合、アプリケーション部5は、写真を撮影したり記憶したりするためにカメラを動作させる、電話をかけたり受けたりするために携帯電話を動作させる、ソフトウェアを含む。
図1のメモリシステム2はフラッシュメモリ7および回路8を含み、回路はいずれも、データをやり取りし、かつメモリ7を制御するため、カードの接続先にあたるホストと連動する。コントローラ8は通常、データのプログラミングと読み出しの際にホスト1によって使用されるデータの論理アドレスとメモリ7の物理アドレスとの変換を行う。
図2を参照し、図1の不揮発性メモリ2として使用できる典型的フラッシュメモリシステムの回路が説明される。システムコントローラは普通、システムバス13沿いに1つ以上の集積回路メモリチップと並列で接続される単一集積回路チップ11上で実施され、図2にはただひとつのこのようなメモリチップ15が示されている。図に示された特定のバス13は、データを搬送する1セットの導体17と、メモリアドレスのためのセット19と、制御および状態信号のためのセット21とを含む。あるいは、これらの3機能の間で1セットの導体を時分割共用できる。さらに、2004年8月9日に出願された米国特許出願第10/915,039号「リングバス構造とフラッシュメモリシステムにおけるその使用(Ring Bus Structure and It's Use in Flash Memory Systems) 」(特許文献7)で説明されているリングバスなど、これとは別のシステムバス構成を使用できる。
典型的コントローラチップ11は、インターフェイス回路25を通じてシステムバス13と連動する独自の内部バス23を有する。このバスへ通常接続される主要機能には、プロセッサ27(例えば、マイクロプロセッサまたはマイクロコントローラ)と、システムを初期化(「ブート」)するためのコードを収容する読み出し専用メモリ(ROM)29と、主にメモリとホストとの間で転送されるデータをバッファするために使われるランダムアクセスメモリ(RAM)31と、コントローラを通じてメモリとホストとの間を行き来するデータのために誤り訂正符号(ECC)を計算し検査する回路33とがある。コントローラバス23は回路35を通じてホストシステムと連動し、これは、メモリカードに収容される図2のシステムの場合、コネクタ4の一部をなすカードの外部接点37を通じて果たされる。クロック39は、コントローラ11の他のコンポーネントの各々に接続され、他のコンポーネントの各々によって利用される。
メモリチップ15と、システムバス13に接続される他のメモリチップは通常、複数のサブアレイまたはプレーンに編制されたメモリセルアレイを収容し、簡潔を図るために2つのこのようなプレーン41および43が図に示されているが、これよりも多い、例えば4つ、または8つの、このようなプレーンを代わりに使用することもできる。あるいは、チップ15のメモリセルアレイはプレーンに分割しなくともよい。しかし、分割するなら、各々のプレーンは互いに独立して動作できる独自の列制御回路45および47を有する。回路45および47は、システムバス13のアドレス部19からそれぞれのメモリセルアレイのアドレスを受け取り、それぞれのビット線49および51のうちの、特定の1つ以上のビット線をアドレス指定するため、それらを復号化する。ワード線53は、アドレスバス19で受け取るアドレスに応じて行制御回路55を通じてアドレス指定される。ソース電圧制御回路57および59もまたそれぞれのプレーンに接続され、pウェル電圧制御回路61および63も同様である。メモリチップ15がただひとつのメモリセルアレイを有し、2つ以上のこのようなチップがシステムに存在する場合、各チップのアレイは、前述したマルチプレーンチップ内のプレーンまたはサブアレイと同様に動作させることができる。
データは、システムバス13のデータ部17に接続されたそれぞれのデータ入出力回路65および67を通じてプレーン41および43を出入りする。回路65および67は、それぞれの列制御回路45および47を通じてプレーンへ接続する線69および71を通じて、メモリセルの中にデータをプログラムし、かつそれぞれのプレーンのメモリセルからデータを読み出すためにある。
コントローラ11は、データをプログラムし、読み出し、消去し、かつ様々なハウスキーピング作業に応対するためにメモリチップ15の動作を制御するが、各々のメモリチップもまた、このような機能を遂行するためにコントローラ11からのコマンドを実行する何らかの制御回路を収容する。インターフェイス回路73はシステムバス13の制御および状態部21へ接続される。コントローラからのコマンドは状態マシン75へ提供され、状態マシンは、これらのコマンドを実行するために他の回路の特定の制御も提供する。制御線77〜81は、図2に示す他の回路に状態マシン75を接続する。状態マシン75からの状態情報は、バス部21に沿ってコントローラ11へ送信するため、ライン83に沿ってインターフェイス73へ伝達される。
現在はメモリセルアレイ41および43のNANDアーキテクチャが好まれているが、NORなどの他のアーキテクチャを代わりに使用することもできる。NANDフラッシュメモリおよびメモリシステムの一部としてのこれの動作の例が、米国特許第5,570,315号(特許文献8)、第5,774,397号(特許文献9)、第6,046,935号(特許文献10)、第6,373,746号(特許文献11)、第6,456,528号(特許文献12)、第6,522,580号(特許文献13)、第6,771,536号(特許文献14)、および第6,781,877号(特許文献15)ならびに米国公開特許出願第2003/0147278号(特許文献16)を参照することによって得られる。
図2のメモリシステムのメモリセルアレイ41の一部分にあたる図3の回路図には、NANDアレイの例が示されている。多数のグローバルビット線が提供されるが、説明の簡潔を図るため、図3には4つのこのような線91〜94だけが示されている。これらのビット線の1ビット線と基準電位との間には、いくつかの直列接続メモリセルストリング97〜104が接続される。メモリセルストリング99を代表として使用し、ストリングの両端にある選択トランジスタ111および112には複数の電荷記憶メモリセル107〜110が直列で接続される。1ストリングの選択トランジスタが通電すると、ストリングがそのビット線と基準電位との間で接続される。次いで、そのストリングの中で一度に1つのメモリセルがプログラムされ、または読み出される。
図3のワード線115〜118は、数々のメモリセルストリングの各々で1つのメモリセルの電荷記憶素子にわたって個別に延在し、ゲート119および120は、ストリングの各末端にある選択トランジスタの状態を制御する。共通のワードおよびコントロールゲート線115〜120を共用するメモリセルストリングは、ともに消去されるメモリセルのブロック123を形成する。このセルからなるブロックは、一度に物理的に消去できる最小数のセルを収容する。ワード線115〜118の1ワード線沿いの1行のメモリセルが一度にプログラムされる。通常、NANDアレイの行は規定の順序でプログラムされ、この場合は、接地または共通電位へ接続されたストリングの末端に最も近いワード線118沿いの行から始まる。次にワード線117沿いのメモリセル行がプログラムされ、ブロック123の全体を通じて同様に進むなどである。最後にワード線115沿いの行がプログラムされる。
第2のブロック125は類似し、そのメモリセルストリングは第1のブロック123のストリングと同じグローバルビット線へ接続されるが、異なる1組のワード線およびコントロールゲート線を有する。ワード線およびコントロールゲート線は、行制御回路55によって適切な動作電圧まで駆動される。図2のプレーン1および2のような、2つ以上のプレーンまたはサブアレイがシステムにある場合、それらの間に延在する共通ワード線を1つのメモリアーキテクチャで使用する。代わりに、共通ワード線を共用する3つ以上のプレーンまたはサブアレイがあってもよい。別のメモリアーキテクチャでは、個々のプレーンまたはサブアレイのワード線が別々に駆動される。
前に参照されているNAND特許および公開特許出願のいくつかで説明されているように、3つ以上の検出可能な電荷レベルを各電荷記憶素子または領域に記憶するようメモリシステムを動作させることができ、これにより2ビット以上のデータを各々に記憶する。メモリセルの電荷記憶素子は一般的には導電性フローティングゲートであるが、代わりに米国公開特許出願第2003/0109093号(特許文献17)で説明される非導電性誘電性電荷捕獲材であってもよい。
図4は、以降のさらなる説明で一例として使用するフラッシュメモリセルアレイ7(図1)の編制を概念的に示している。1つの集積メモリセルチップ、2つのチップ(各チップ上のプレーンのうちの2つ)、または4つの別々のチップの上に、メモリセルの4つのプレーンまたはサブアレイ131〜134があってよい。具体的な配置は以降の説明にとって重要でない。もちろん、1、2、8、16以上などの、これ以外の数のプレーンがシステムの中にあってもよい。プレーンは、それぞれのプレーン131〜134に位置するブロック137、138、139、および140の矩形によって図4に示すメモリセルブロックに各々分割される。各プレーンには何十、何百ものブロックがあってよい。前述したように、メモリセルのブロックは消去の単位、すなわちともに物理的に消去できる最小数のメモリセルである。しかし、並列性を高めるためには、これよりも大きいメタブロック単位でブロックを操作する。各プレーンから1つのブロックが論理的にリンクされることによってメタブロックを形成する。4つのブロック137〜140によって1つのメタブロック141が形成される様子が図に示されている。通常ならば、1メタブロック内の全てのセルが一緒に消去される。ブロック145〜148からなる第2のメタブロック143に見られるように、メタブロックを形成するように使用されるブロックを、それぞれのプレーンの中の同じ相対的位置に制限する必要はない。通常は全てのプレーンにわたってメタブロックを延在させるのが好ましいが、高いシステム性能のためには、異なるプレーンにある1つ、2つ、または3つのブロックのいずれかまたは全部からなるメタブロックを動的に形成する能力を用いてメモリシステムを操作することができる。これにより、1回のプログラミング操作で記憶のために使用できるデータ量にメタブロックのサイズをより近づけることが可能となる。
個々のブロックはさらに、動作上の目的のため、図5に示すようにメモリセルのページに分割される。例えば、ブロック131〜134の各々のメモリセルは8つのページP0〜P7に各々分割されている。代わりに、16、32、またはそれ以上のメモリセルページが各ブロックの中にあってよい。ページは、ブロックの中でデータをプログラムし読み出す単位であり、一度にプログラムされる、または読み出される、最少量のデータを収容する。図3のNANDアーキテクチャでは、ブロックの中でワード線沿いのメモリセルからページが形成されている。しかし、メモリシステムの動作上の並列性を高めるために、2つ以上のブロックの中にあるこのようなページをメタページの中に論理的にリンクできる。図5には、4つのブロック131〜134の各々にある1つの物理ページから形成されたメタページ151が示されている。メタページ151は、例えば4つのブロックの各々にあるページP2を含むが、メタページのページは、ブロックの各々の中で同じ相対的位置になくてもよい。全4つのプレーンにわたって最大量のデータを並行してプログラムし読み出すことが望ましいが、高いシステム性能のため、異なるプレーンの中にある別々のブロックの1つ、2つ、または3つのページのいずれかまたは全てからメタページを形成するべくメモリシステムを操作することもできる。これにより、並行して簡便に扱えるデータ量にプログラミングおよび読み出し動作を適合させることができ、さらにデータがプログラムされない部分がメタページに残る機会は減る。
単一ページと単一ブロックとを一度に使用しながらデータを管理するように使用されるメモリ管理手法のほとんどは、メタページとメタブロックとにも応用できる。同様に、メタページとメタブロックとを使用する手法は概して単一ブロックと単一ページとにも応用できる。総じて、ページおよびブロックを用いて提示される例はメタページおよびメタブロックに応用可能と理解される。同様に、メタページおよびメタブロックに関して提示される例は概してページおよびブロックに応用可能と理解される。
図5に示す複数のプレーンの物理ページからなるメタページは、それらの複数のプレーンのワード線行に沿ってメモリセルを収容する。1つのワード線行にある全てのセルを同時にプログラムするよりは、2つ以上のインターリーブされたグループでそれらを交互にプログラムするほうがむしろ一般的であり、各グループは、(単一ブロック内の)1ページのデータまたは(複数のブロックにまたがる)1メタページのデータを記憶する。交互のメモリセルを一度にプログラムすることにより、データレジスタやセンス増幅器を含むひとまとまりの周辺回路を各ビット線のために用意する必要はなく、むしろ隣接するビット線の間で時分割共用される。これは、周辺回路に要する基板空間の量を節約し、メモリセルの行沿いの実施密度を増やすことができる。さもなくば、所与のメモリシステムから最大限の並列性を引き出すために、行沿いの全セルを同時にプログラムするのが望ましい。
図3を参照し、行沿いの互い違いのメモリセルへのデータの同時プログラミングを最も簡便に果たすには、NANDストリングの少なくとも一端に沿って2行の選択トランジスタ(図示せず)を、図に示された1行の代わりに、提供することである。この場合、一方の行の選択トランジスタは、1つの制御信号に応じてブロック内の互い違いのストリングをそれぞれのビット線へ接続し、他方の行の選択トランジスタは、別の制御信号に応じて介在する互い違いのストリングをそれぞれのビット線へ接続する。したがって、メモリセルの各行には2ページ分のデータが書き込まれる。
各論理ページのデータ量は通常、1つ以上の整数のデータセクタ数であって、各セクタは慣例上512バイトのデータを収容する。図6は、1ページまたはメタページの、2つのデータのセクタ153および155からなる論理データページを示している。各セクタは普通、512バイトのユーザデータまたはシステムデータが記憶される部分157と、部分157にあるデータまたはこれを記憶する物理ページまたはブロックに関係するオーバーヘッドデータのための別のバイト数159を収容する。オーバーヘッドデータのバイト数は通常ならば16バイトであり、セクタ153および155の各々につき合計528バイトになる。オーバーヘッド部分159は、プログラミング中にデータ部分157から算出されるECC、その論理アドレス、ブロックが消去され再プログラムされる回数の経験カウント、1つ以上の制御フラグ、動作電圧レベル等に加え、このようなオーバーヘッドデータ159から算出されるECCを収容できる。代わりに、オーバーヘッドデータ159またはオーバーヘッドデータ159の一部分は、他のブロックの別のページに記憶できる。
メモリの並列性が高まるにつれメタブロックのデータ記憶容量は増し、その結果、データページおよびメタページのサイズも増す。データページは3セクタ以上のデータを収容できる。1データページ内に2つのセクタと、各メタページにつき2つのデータページとで、1メタページ内のセクタは4つになる。よって、各メタページは2,048バイトのデータを記憶する。これは高度な並列性であり、行内のメモリセル数の増加にともないさらに高めることができる。このため、ページおよびメタページ内のデータ量を増やすために、フラッシュメモリの幅が拡大されつつある。
前述した物理的に小さい再プログラム可能な不揮発性メモリカードおよびフラッシュドライブは市販され、データ記憶容量は512メガバイト(MB)、1ギガバイト(GB)、2GB、および4GB以上になる。図7は、ホストとこのような大容量メモリシステムとの間の最も一般的なインターフェイスを示している。ホストは、ホストによって実行されるアプリケーションソフトウェアまたはファームウェアプログラムによって生成または使用されるデータファイルを処理する。ワープロデータファイルはその一例であり、コンピュータ支援設計(CAD)ソフトウェアの描画ファイルもこれにあたり、主にPC、ラップトップコンピュータ等、一般的なコンピュータホストに見られる。pdf形式の文書もこのようなファイルである。静止画デジタルビデオカメラは各写真につきデータファイルを生成し、データファイルはメモリカードに記憶される。携帯電話は、電話帳などの内蔵メモリカード上のファイルからデータを利用する。PDAは、住所ファイル、カレンダーファイル等、数通りのファイルを記憶し使用する。このような用途において、メモリカードはホストを操作するソフトウェアを収容することもある。
メモリシステム、特に着脱可能なカードに埋め込まれるメモリシステムは、標準インターフェイスを通じて様々なホストと通信することができる。メモリシステムとの通信のためにホストが使用するインターフェイスは、ホストによって異なることがある。インターフェイスには、共通論理アドレス空間とともに論理アドレス指定システムを使用するものと、ファイル本位アドレス指定システムを使用するものとの2種類がある。
LBAインターフェイス
図7には、ホストとメモリシステムとの間の一般的な論理インターフェイスが示されている。連続する論理アドレス空間161は、メモリシステムに記憶される全データのためアドレスを提供するにあたって十分に大きい。ホストアドレス空間は通常、データクラスタの単位に分割される。所与のホストシステムにおいて、いくつかのデータセクタを収容するように各クラスタを設計でき、4から64セクタあたりが一般的である。標準的なセクタは512バイトのデータを収容する。
図7の例では、3つのファイル1,2,および3が作成されたものとして示されている。ホストシステムで実行するアプリケーションプログラムは、整列された1組のデータとして各ファイルを作成し、一意な名前またはその他の参照符によってこれを識別する。ファイル1にはホストによって、他のファイルにまだ割り振られていない十分に使用可能な論理アドレス空間が、割り当てられる。ファイル1は、一連の使用可能な論理アドレス範囲が割り当てられた状態で示されている。このほかに通常ならば、ホストオペレーティングソフトウェアのための特定の範囲などの、特定の目的のためにアドレス範囲が割り振られ、これらのアドレス範囲は、たとえホストがデータに論理アドレスを割り当てようとするときに、これらのアドレスがまだ利用されていなくとも、データの記憶にあたって回避される。
ホストは同様に、後ほどホストによってファイル2が作成されるときに、論理アドレス空間161の中の2つの異なる連続アドレス範囲を、図7に示すように割り当てる。ファイルに連続する論理アドレスを割り当てる必要はなく、すでに他のファイルに割り振られているアドレス範囲の間にあるアドレスの断片であってもよい。この例はさらに、ホストによって作成されたもうひとつのファイル3に、ファイル1および2やその他のデータにまだ割り振られていないホストアドレス空間の別の部分が割り振られる様子を示している。この例で、ファイル1、ファイル2、およびファイル3にはいずれも、共通論理アドレス空間(論理アドレス空間161)の一部分が割り当てられる。
ホストは、ファイルアロケーションテーブル(FAT)を保守することによってメモリ論理アドレス空間を絶えず把握し、このファイルアロケーションテーブルでは、ホストが様々なホストファイルに割り当てる論理アドレスが保守される。FATテーブルは通常、ホストメモリと同様に不揮発性メモリに記憶され、新しいファイルが記憶されるとき、他のファイルが削除されるとき、ファイルが修正されるとき等に、ホストによって頻繁に更新される。ホストは、例えばホストファイルが削除されるときに、FATテーブルを更新することによって削除ファイルに前に割り振られていた論理アドレスを解除して、それらの論理アドレスを別のデータファイルに使用できることを明らかにする。FATの中で使われる論理アドレスは論理ブロックアドレス(LBA)と呼ばれることがあり、それ故、異なるファイルのデータにとって共通の論理アドレス空間にわたってこのような論理アドレス指定を使用するインターフェイスはLBAインターフェイスと呼ばれることがある。同様に、転送されるデータのために論理アドレスを使用する通信プロトコルはLBAプロトコルとみなすことができる。
ホストは、メモリシステムコントローラがファイルを記憶するために選択する物理位置を顧慮しない。典型的なホストは、その論理アドレス空間と、これがその各種ファイルに割り振った論理アドレスだけを認識する。他方、メモリシステムは、典型的なホスト/カードインターフェイスを通じて、データが書き込まれた論理アドレス空間部分だけを認識し、特定のホストファイルへ割り振られる論理アドレスは認識せず、ホストファイルの数すら認識しない。メモリシステムコントローラは、データの記憶や引き出しのためのホストから提供される論理アドレスを、ホストデータが記憶されるフラッシュメモリセルアレイの中の一意の物理アドレスに変換する。ブロック163は、メモリシステムコントローラによって保守される論理−物理アドレス変換の作業テーブルを表している。
メモリシステムコントローラは、システムの性能を高い水準に維持しながらメモリアレイ165のブロックおよびメタブロックの中でデータファイルを記憶する形にプログラムされる。この例証では4つのプレーンまたはサブアレイが使われている。データは好ましくは、各プレーンのブロックから形成されたメタブロック全体にわたってシステムが許容する最大限の並列度でプログラムされ、読み出される。通常は、メモリコントローラによって使用されるオペレーティングファームウェアおよびデータを記憶する予約ブロックとして、少なくとも1つのメタブロック167が割り振られる。そして、ホストオペレーティングソフトウェアやホストFATテーブル等の記憶のため、別のメタブロック169または複数のメタブロックを割り振ることができる。物理記憶空間のほとんどはデータファイルの記憶のために残る。しかし、メモリコントローラは、様々なファイルオブジェクトの中で受信データがホストによってどのように割り振られたかを認識しない。通常、メモリコントローラがホストとのやり取りを通じて知ることの全ては、ホストによって特定の論理アドレスに書き込まれるデータが対応する物理アドレスに記憶されるということだけであり、これはコントローラの論理−物理アドレステーブル163によって保守される。
典型的なメモリシステムにおいては、アドレス空間161の中でデータを記憶する必要があるのとは別に数ブロック分の記憶容量が余分に用意される。メモリの寿命の中で他のブロックが欠陥となった場合に代用される冗長ブロックとして、これらの余分なブロックを1つ以上用意することができる。当初メタブロックに割り当てられていた欠陥ブロックのための冗長ブロックを代用する等、個々のメタブロックの中に収容されるブロックの論理的グループ分けは通常、様々な理由から変更される。消去済みブロックのプールでは、メタブロック171などの、1つ以上の補助的ブロックが通常保守される。ホストがメモリシステムにデータを書き込む場合、コントローラはホストによって割り当てられた論理アドレスを、消去済みブロックプールにあるメタブロックの中の物理アドレスに変換する。次いで、論理アドレス空間161の中でデータを記憶するために使われていない他のメタブロックは消去され、以降のデータ書き込み操作のときに使用するため消去済みプールブロックとして指定される。
特定のホスト論理アドレスに記憶されたデータは、新規のデータによって頻繁に上書きされ、当初の記憶データが用済みになる。これに応じてメモリシステムコントローラは新規のデータを消去済みブロックに書き込み、データを論理アドレスに記憶する新しい物理ブロックを明らかにするために、それらの論理アドレスの論理−物理アドレステーブルを変更する。次いで、それらの論理アドレスのところで当初のデータを収容するブロックは消去され、新規のデータの記憶のために使用できるようになる。通常、書き込みが始まるときに消去ブロックプールの事前に消去済みのブロックに十分な記憶容量がない場合は、この消去を進行中のデータ書き込み操作が完了する前に行わなければならない。これはシステムのデータプログラミング速度を損なうおそれがある。メモリコントローラは通常、ある特定の論理アドレスにあるデータが用済みになっていることを、ホストがそれと同じ論理アドレスに新しいデータを書き込むときに初めて知る。したがって、メモリのブロックの多くは、そのような無効データを暫くの間記憶している可能性がある。
集積回路メモリチップの領域を効率よく運用するためにブロックとメタブロックのサイズは拡大している。その結果、個々のデータ書き込みの大部分で記憶されるデータの量はメタブロックの記憶容量に満たなく、多くの場合、ブロックの記憶容量にすら満たない。メモリシステムコントローラは普通、新規のデータを消去済みプールのメタブロックに誘導するから、メタブロックには埋まらない部分が生じる。新規のデータが別のメタブロックに記憶されたデータの更新である場合、別のメタブロックにある、新規のデータメタページの論理アドレスと連続する論理アドレスを持つ、残りの有効データメタページもまた、望ましくは論理アドレスの順序で新しいメタブロックにコピーされる。古いメタブロックは、他の有効データメタページを保持することがある。その結果、個々の特定のメタブロックのメタページのデータはいずれ用済み、無効になり、新規のデータによって置き換えられ、同じ論理アドレスが異なるメタブロックに書き込まれることになる。
論理アドレス空間161の全体にわたってデータを記憶するために十分な物理メモリ空間を維持するため、このようなデータは定期的に圧縮または整理される(ガーベッジコレクション)。メタブロックの中でデータセクタをできる限り論理アドレスと同じ順序に保つことも望ましい。というのは、こうすれば連続する論理アドレスでデータをより効率的に読み出すことができるからである。よって、通常は、このさらなる目的のためにもデータの圧縮とガーベッジコレクションが行われる。米国特許第6,763,424号(特許文献18)には、不完全ブロックデータ更新を受け取るときのメモリ管理とメタブロック使用の態様がいくつか記載されている。
データ圧縮では通常、メタブロックから有効データメタページを全て読み出し、それらを新しいブロックに書き込み、その過程で無効データを含むメタページは無視する。また、有効データを含むメタページは好ましくは、そこに記憶されたデータの論理アドレスの順序に一致する物理アドレス順で配置される。無効データを収容するメタページは新しいメタブロックへコピーされないから、新しいメタブロックに占めるメタページ数は古いメタブロックにおけるメタページ数を下回る。次いで、古いブロックは消去され、新規データの記憶のために使用できるようになる。この整理によって得られる追加メタページ容量は、他のデータを記憶するために役立てることができる。
ガーベッジコレクションのときには、論理アドレスが連続するかまたはほぼ連続する有効データのメタページが2つ以上のメタブロックから回収され、別のメタブロックに、通常ならば消去済みブロックプールのメタブロックに、再度書き込まれる。当初の2つ以上のメタブロックから全ての有効データメタページがコピーされたら、先々の使用に向けてそれらを消去できる。
データの整理とガーベッジコレクションには時間がかかり、データの整理またはガーベッジコレクションをホストからのコマンドを実行する前に行う必要がある場合は特に、メモリシステムの性能に影響する。メモリシステムコントローラは普通、このような操作を可能な限りバックグラウンドで行うようスケジュールするが、これらの操作を遂行する必要から、コントローラは、このような操作が完了するまではビジー状態信号をホストに提供しなければならない。例えば、ホストがメモリに書き込もうとするデータの全てを記憶するにあたって十分な事前に消去済みのメタブロックが消去済みブロックプールにない場合には、ホストコマンドの実行が延期されるから、まずはデータの整理またはガーベッジコレクションで1つ以上の有効データのメタブロックを片づける必要があり、その後にそれらのメタブロックを消去できる。したがって、このような混乱を最小限に抑えるためにメモリ制御の管理に注意を払わなければならない。これ以降「LBA特許出願」と呼ぶ以下の米国特許出願では、このような手法が数多く説明されている。これらの米国特許出願とは、2003年12月30日に出願された米国特許出願第10/749,831号「大きい消去ブロックを有する不揮発性メモリシステムの管理(Management of Non-Volatile Memory Systems Having Large Erase Blocks) 」(特許文献19)、2003年12月30日に出願された米国特許出願第10/750,155号「ブロック管理システムを伴う不揮発性メモリおよび方法(Non-Volatile Memory and Method with Block Management System) 」(特許文献20)、2004年8月13日に出願された米国特許出願第10/917,888号「メモリプレーンアラインメントを伴う不揮発性メモリおよび方法(Non-Volatile Memory and Method with Memory Planes Alignment) 」(特許文献21)、2004年8月13日に出願された米国特許出願第10/917,867号(特許文献22)、2004年8月13日に出願された米国特許出願第10/917,889号「段階的プログラム障害処理を伴う不揮発性メモリおよび方法(Non-Volatile Memory and Method with Phased Program Failure Handling) 」(特許文献23)、および2004年8月13日に出願された米国特許出願第10/917,725号「制御データ管理を伴う不揮発性メモリおよび方法(Non-Volatile Memory and Method with Control Data Management) 」(特許文献24)である。
非常に大きい消去ブロックを伴うメモリアレイの操作を効率的に制御するにあたって1つの課題となるのは、所与の書き込み操作のときに記憶されるデータセクタの数を、メモリのブロックの容量に一致させ、その境界に整合させることである。1つのアプローチでは、メタブロック全体を埋め尽くす量に満たない一定量のデータを記憶するのに必要なため、ホストからの新規データの記憶するのに使うメタブロックを、最大ブロック数未満で適宜構成する。適応メタブロックの使用が、2003年12月30日に出願された米国特許出願第10/749,189号「適応メタブロック(Adaptive Metablocks) 」(特許文献25)で説明されている。データブロック間の境界とメタブロック間の物理的境界の整合は、2004年5月7日に出願された米国特許出願第10/841,118号(特許文献26)、2004年12月16日に出願された米国特許出願第11/016,271号「データランプログラミング(Data Run Programming)」(特許文献27)で説明されている。
メモリコントローラはまた、ホストによって不揮発性メモリに記憶されるFATテーブルのデータをメモリシステムの効率的な動作に役立てることもできる。例えば、論理アドレスの解除によりホストによってデータが用済みと識別されたことを知るのに役立てる。メモリコントローラは、通常ならばホストがその論理アドレスに新規データを書き込むことで、データが用済みと識別されたことを事前に知ることができ、このような無効データを収容するブロックの消去スケジュールを立てることができる。これは、2004年7月21日に出願された米国特許出願第10/897,049号「不揮発性メモリシステムでデータを保守する方法および装置(Method and Apparatus for Maintaining Data on Non-Volatile Memory Systems)」(特許文献28)で説明されている。この他の手法として、ホストがメモリに新規のデータを書き込むパターンを監視することにより、所与の書き込み操作が単一ファイルか否かを、または複数のファイルである場合にはファイル間のどこに境界があるかを推定する。2004年12月23日に出願された米国特許出願第11/022,369号「最適逐次クラスタ管理のためのFAT解析(FAT Analysis for Optimized Sequential Cluster Management)」(特許文献29)では、この種の手法の使用が説明されている。
メモリシステムを効率よく操作するには、ホストによって個々のファイルのデータに割り当てられる論理アドレスについて、コントローラができるだけ多くのことを知ることが望ましい。かくしてデータファイルは、ファイルの境界が分からなければ多数のメタブロックに散在するところを、コントローラによって1つのメタブロックまたは1グループのメタブロックの中で、記憶することができる。その結果、データ整理およびガーベッジコレクション操作の回数と複雑さは抑えられる。結果的にメモリシステムの性能は向上する。しかし、前述したように、ホスト/メモリインターフェイスが論理アドレス空間161(図7)を含む場合、メモリコントローラがホストデータファイル構造について多くを知ることは困難である。
図8を参照し、すでに図7に示されている典型的な論理アドレスホスト/メモリインターフェイスが異なる形で図に示されている。ホスト生成データファイルにはホストによって論理アドレスが割り振られる。次いで、メモリシステムはこれらの論理アドレスを認識し、データが実際に記憶されるメモリセルのブロックの物理アドレスにマッピングする。
ファイルインターフェイス
大量データ記憶のためのホストとメモリシステムとの間のファイル本位インターフェイスは、論理アドレス空間の使用を解消する。代わりに、ホストは、一意なファイルID(またはその他の一意な参照符)およびファイル内でのデータ単位(バイトなど)のオフセットアドレスによって各ファイルを論理的にアドレスする。このファイルアドレスはメモリシステムコントローラへ直接提供され、メモリシステムコントローラは、各ホストファイルのデータが物理的に記憶される位置について独自のテーブルを保管する。この新しいインターフェイスは、図2〜6との関係で前述したのと同じメモリシステムで実施できる。図2〜6で説明したものとの主な違いは、メモリシステムとホストシステムとの通信のあり方にある。
図9にはファイルインターフェイスが示され、これは図7のLBAインターフェイスと比較するべきものである。ファイル1,2,および3の各々の識別情報と図9のファイルの中でのデータのオフセットは、メモリコントローラへ直に引き渡される。次いで、この論理アドレス情報はメモリコントローラ機能173によってメモリ165のメタブロックおよびメタページの物理アドレスに翻訳される。
ファイルインターフェイスは図10にも示され、これは図8の論理アドレスインターフェイスと比較するべきものである。図8の論理アドレス空間とホストによって保守されるFATテーブルは図10にない。むしろ、メモリシステムにとって、ホストによって生成されるデータファイルはファイル番号とファイル内でのデータのオフセットとによって識別される。次いで、メモリシステムはメモリセルアレイの物理ブロックにファイルを直接マッピングする。
メモリシステムは、各ファイルを構成するデータの位置を認識しているから、これらのデータは、ホストがファイルを削除した直後に消去できる。典型的な論理アドレスインターフェイスでこれを果たすことはできない。さらに、論理アドレスを使用する代わりにファイルによってホストデータを識別することにより、メモリシステムコントローラは、頻繁なデータの整理および回収の必要性を抑える形でデータを記憶できる。したがって、データコピー操作の頻度とコピーされるデータ量は大幅に低下し、これによりメモリシステムのデータプログラミングおよび読み出し性能は向上する。
ファイル本位インターフェイスの例として、直接データファイル記憶を使用するものがある。いずれも2005年2月16日に出願された、アラン・W・シンクレア(Alan W. Sinclair)のみを、または同人と併せてピーター・J・スミス(Peter J. Smith)を発明者とする、同時係属中の米国特許出願第11/060,174号(特許文献3)、第11/060,248号(特許文献4)、および第11/060,249号(特許文献5)、アラン・W・シンクレア(Alan W. Sinclair)およびバリー・ライト(Barry Wright)によって本願と同時に出願された「フラッシュメモリにおける直接データファイル記憶(Direct Data File Storage in Flash Memories)」という米国仮特許出願(特許文献30)では、直接データファイル記憶メモリシステムが説明されている。(これ以降、「直接データファイル記憶アプリケーション(Direct Data File Storage Applications) 」と総称する。)
図9および10に示された、これらの直接データファイル記憶アプリケーションの直接データファイルインターフェイスは、図7および8に示された、前述した論理アドレス空間インターフェイスよりシンプルであり、メモリシステムの性能を上げるから、直接データファイル記憶は多くの用途にとって好ましい。しかし、現在、ホストシステムは主にLBAインターフェイスで動作するよう構成されているから、直接データファイルインターフェイスを持つメモリシステムはほとんどのホストに適合しない。したがって、両方のインターフェイスで動作できるメモリシステムを提供することが望ましい。
デュアルインターフェイス
一部のメモリシステム、特に様々なホストと連動できる着脱可能なメモリカードに内蔵されたメモリシステムにとって、後方互換性は重要課題である。多くのホストシステムは図7および8に示すものと同様にセクタ本位記憶形式を使用し、これらのホストシステムのいくつかは、図9および10に示すようなファイル本位記憶に容易く適合できない。したがって、論理アドレスインターフェイスまたはファイル本位インターフェイスのいずれかを使用するホストと連動できるメモリシステムを用意することが望まれる。LBAインターフェイスとファイル本位バックエンドとの間に置かれたLBAプロトコルアダプタは、論理アドレス指定を使用するホストが、データをファイルとして管理するメモリアレイにデータを記憶することを可能にする。
2005年8月3日に出願された米国特許出願第11/196,869号「論理アドレス空間と直接データファイル方式で動作するインターフェイスシステム(Interfacing systems operating through a logical address space and on a direct data file basis) 」(特許文献31)は、メモリシステムが論理アドレスインターフェイスまたはファイル本位インターフェイスのいずれかを用いてホストと連動することを可能にするシステムを説明している。図11はこのようなシステムを示している。この例では、図7のホスト動作に図9のファイル本位メモリ動作が組み合わされ、さらにメモリシステムの中にアドレス変換172が加わる。アドレス変換172は、メモリ空間161にまたがる論理アドレスのグループを、修正アドレス空間161’にまたがる個々の論理ファイルa〜jにマッピングする。好ましくは、論理アドレス空間161全体がこれらの論理ファイルに分割され、かくして論理ファイルの数は、論理アドレス空間のサイズと個々の論理ファイルのサイズとに依拠する。論理ファイルの各々は、空間161にまたがる1グループの連続論理アドレスのデータを収容する。各々の論理ファイルの中のデータの量は好ましくは同じであり、その量は、メモリ165の1メタブロックのデータ記憶容量に等しい。論理ファイルの不等サイズおよび/またはメモリのブロックまたはメタブロックの記憶容量とは異なるサイズは、無論可能であるが、好ましくはない。
個々のファイルa〜jの中のデータは、ファイル内の論理オフセットアドレスによって表される。論理ファイルのファイル識別子とデータオフセットは173でメモリ165内の物理アドレスに変換される。論理ファイルa〜jは、直接データファイル記憶アプリケーションで説明したのと同じプロセスとプロトコルとによってメモリ165に直接記憶される。そのプロセスは、図9のデータファイル1〜3をメモリ165に記憶するのに使用するのと同じであるが、各論理ファイル内のデータ量は分かっているから、特にその量がメモリのブロックまたはメタブロックの容量に等しければ、プロセスはより簡単なものとなる。図11には、論理ファイルa〜jの各々がメモリ165の別々のメタブロックにマッピングされる様子が示されている。また、ファイル本位データ記憶は、ホストと連動するように設計された現在の論理アドレスメモリシステムと同じかまたは同等のやり方で、ホストとやり取りするのが望ましい。個々の論理ファイルを対応する個々のメモリメタブロックにマッピングすることにより、論理アドレス空間インターフェイスを使用する場合と実質的に同じ性能とタイミング特性とが、直接データファイルインターフェイスメモリシステムで達成される。
図12は、図11の方法を異なる形で示している。図12は、図8の論理アドレスメモリシステム動作と同じであるが、論理アドレス空間を論理ファイルに分割する機能、すなわち直前に説明した図11のステップ172が、加わっている。さらに、図12の「ファイルデータを物理記憶ブロックにマッピングするためのテーブル」が図8の「論理アドレスを物理記憶ブロックにマッピングするためのテーブル」に取って代わっている。論理アドレス−論理ファイル変換172は、LBAシステムを使用するインターフェイスとファイル本位のバックエンドとの間に位置するLBAプロトコルアダプタの一部とみなすことができる。
従来の論理アドレス空間インターフェイスを通じてホストと連動するように設計された図11〜12のデータファイル本位バックエンド記憶システムには、直接データファイルインターフェイスを加えることもできる。ファイルインターフェイスからのホストデータファイルと論理インターフェイスからの論理ファイルはいずれも、メモリメタブロックアドレスに翻訳される。次いで、データは、直接データファイルプロトコルを実行することによってメモリのアドレスに記憶される。このプロトコルには、前述した直接データファイル記憶アプリケーションの直接データファイル記憶手法が盛り込まれる。
携帯用メモリカード、フラッシュドライブ、またはその他の着脱可能なメモリシステムに両タイプのホストインターフェイスを用意すれば、論理アドレス空間インターフェイスで動作する現在のほとんどのホストと、ファイルをメモリに直接引き渡すホストでメモリを使用でき、あるいは両タイプのホスト間でメモリを交換できる。次いで、新しいファイル本位インターフェイスを備えるホストのユーザはメモリを極めて効率的に利用できると同時に、従来の論理アドレス空間インターフェイスとの後方互換性を有することができる。また、同じ1対1の論理ファイル−メタブロックマッピングの結果、実質的に同じ性能とタイミング特性とが達成される。ユーザが新しい直接データファイルインターフェイスを理由に入手するデュアルホストインターフェイスを備えるメモリは、従来の論理アドレス空間インターフェイスを有する多数の既存ホストにも利用できる。これは、現在のインターフェイスから直接データファイルインターフェイスへ移行するための手段となる。
図13は、デュアルホストインターフェイスを有するメモリシステム300を示している。メモリシステムは、ファイルインターフェイス307を通じてホストから直に提供されるホストデータファイル(HF1、HF2...HFn)と、LBAプロトコルアダプタ301によって変換されるLBAインターフェイス305からの論理ファイル(LFa、LFb...LFm)の両方を記憶する。ファイル本位バックエンド303はホストファイルから論理ファイルを区別する必要はなく、むしろ好ましくは、両方のファイルを扱うよう最適化される。かくして、論理ファイルは、LBA特許出願で説明されているシステムの論理グループに相当し、したがってホストインターフェイスから見たメモリシステム300の性能は、LBA特許出願で説明されている論理アドレス空間インターフェイスを備えるシステムの性能に一致する。
論理アドレス形式から論理ファイル形式にかけてホストデータを変換することに加え、LBAプロトコルアダプタ301は、特定の条件またはホストから受け取る特定のLBAコマンドに応じて、ファイル本位バックエンド303に適合するコマンドを生成できる。以下の表には、このような条件に応じて直接データファイルバックエンド向けにコマンドを生成する例が示されている。
Figure 2009518698
オブジェクトインターフェイス
電子デバイス間のデータ転送のために様々なファイル本位インターフェイスを使用できる。一部のプロトコルは、所定のサイズを有するファイルを、そのサイズの指示と併せて提供する。このようなシステムでは通常、ファイルのサイズが変化しないから、このようなシステムは、ファイルの編集が要求される用途にとって相応しくないかもしれない。しかし、あるデバイスから別のデバイスへファイルを転送する場合、このようなプロトコルは有利であり、高度なセキュリティを可能にするかもしれない。サイズの指示は通常、ファイルデータが送信される前に送信される。所定サイズのファイルをファイルサイズの標識と併せて転送するプロトコルはオブジェクトプロトコルとみなすことができる。マイクロソフト コーポレイション(Microsoft Corporation) によるピクチャ転送プロトコル(PTP)は、オブジェクトプロトコルのひとつである。同じくマイクロソフト コーポレイションによる、メディアトランスポートプロトコル(MTP)として知られる、メディア転送プロトコルもまた、このようなプロトコルのひとつである。オブジェクトプロトコルは、デジタル写真やMP3音楽ファイルなどの所定の量のデータを収容するファイルの送信に特に適している。例えば、デジタルカメラとPCとの間でデジタル写真を転送したり、あるいはPCからMP3プレイヤへMP3音楽ファイルを転送したりするために、このようなプロトコルを使用することができる。
メディア転送プロトコル(MTP)が提供するオブジェクトインターフェイスは、既定サイズのファイルオブジェクトの転送をサポートする。その主な目的は、各々かなりの記憶容量を持つ、互いに一時的に接続できる、デバイス間で通信を可能にすることにある。このインターフェイスはデバイス間でバイナリデータオブジェクトの交換を可能にし、さらに一方のデバイスによる他方のデバイスの内容の列挙を可能にする。これ以降、MTPインターフェイスの特性をいくつか記す。しかし、特性は、MTP以外のオブジェクトインターフェイスの場合に異なることがある。MTPの詳しい説明は、マイクロソフト コーポレイションの文書「強化メディア転送プロトコル(Media Transfer Protocol Enhanced)」に記載されている。
1.通信プロトコル
1.1イニシエータおよびレスポンダ:交換は必ず一度に2つのデバイスの間で起こり、一方のデバイスはイニシエータとして動作し、他方のデバイスはレスポンダとして動作する。イニシエータは、オペレーションを送信することによってレスポンダを相手にアクションを開始するデバイスである。レスポンダはアクションを開始せず、イニシエータによって送信されたオペレーションに対し応答を送信する。イニシエータとして動作するデバイスは、応答デバイスの内容を列挙でき、これを理解でき、プロトコルの中でオペレーションの流れを制御できなければならない。イニシエータは通常、レスポンダより性能の高いデバイスである。レスポンダの例として、デジタルカメラなどの簡素なコンテンツ製作デバイスや、携帯用オーディオプレイヤなどの簡素なコンテンツ出力デバイスが挙げられる。
1.2セッション:セッションとは、イニシエータとレスポンダとの間で接続が維持している通信状態である。セッションはコンテキストを提供し、このコンテキストの中でオブジェクトが参照され、さらに、イニシエータへの警報を省いてレスポンダデバイスの状態が変化しないことを保証する。セッションはイニシエータによって開放され、イニシエータまたはレスポンダのいずれかによって閉鎖される。1デバイスが複数の開放セッションを同時に維持できる。イニシエータは最初にセッションを開放するときに一意な識別子をこれに割り当て、オペレーションを送信するときにはその識別子を用いてセッションを識別する。
1.3トランザクション:イニシエータから起こるアクションはどれもトランザクションの中で、すなわち入力パラメータを伴うアクション起動、バイナリデータ交換、およびパラメータを伴う応答のためのメカニズムを提供する一連の標準段階で遂行される。各段階におけるデータの流れは一方向である。データはオペレーションを開始するときに専らイニシエータからレスポンダにかけて流れる。要求されたオペレーションに対する応答のとき、データは専らレスポンダからイニシエータにかけて流れる。バイナリデータ交換段階のとき、データはいずれか一方の方向に流れることができるが、決して両方向には流れない。双方向のバイナリデータ交換は必ず複数のオペレーションによって遂行される。イニシエータは各トランザクションに識別子を割り当てる。セッション中に開始する最初のオペレーションには規定の識別子が割り当てられ、その識別子は相継ぐトランザクションのたびに1ずつ増加する。
トランザクションは3つの段階、すなわちオペレーション要求段階と、データ段階と、応答段階とからなる。オペレーション要求段階と応答段階は同じ識別子を共有し、2つの段階の間に必要に応じてオプションのデータ段階が存在する。
オペレーション要求段階はオペレーション要求データセットの送信を含み、これによりイニシエータによって起動されようとしているオペレーションと、オペレーションが実行されるところのコンテキスト(セッションおよびトランザクション)と、所定のパラメータとが明らかになる。
オプションのデータ段階はオペレーション要求段階の後に続く。その存在は、オペレーション要求段階で定まるオペレーションから判明する。そのデータはプロトコルの中で定められた透過データセットであってよく、あるいは交換され受信側デバイスで記憶されるバイナリデータであってよい。データ段階における実際のデータ送信では、使用する特定のトランスポートの要求に応じて、データをコンテナ形式で送信すること、またはデータをパケットに分割することを含むことがある。
応答段階では、成功/失敗など、先行トランザクションに関する情報を報告するため、レスポンダからイニシエータにかけて一定のデータセットが送信される。
1.4イベント:イベントは主に、情報または警報を前もって送信する手段としてレスポンダによって送信される。オペレーションと違って、イベントを承認したり、これに働きかける必要はない。イベントは、データ送信またはオペレーショントランザクションと非同期で通信しなければならない。トランザクションのときにイベントとデータストリームをインターリーブするプロセスはトランスポートによって規定される。
1.5同期および非同期トランザクション:通信プロトコルにおけるトランザクションはどれも同期であり、つまり前のオペレーションが完全に完了するまでは新しいトランザクションを開始できない。オペレーションを開始するイニシエーションと、デバイスでオペレーションがバックグラウンドで実行されているときにレスポンダによって送信されるイベントによるプログレスモニタリングとに、オペレーションを分けることにより、非同期オペレーションを模擬できる。非同期オペレーションの進行中に新しいオペレーションが試みられると、レスポンダはビジー障害状態で応答し、イニシエータは後ほど再び試みなければならない。
2.情報データセット
データの交換にあたっては、データセットと呼ばれる所定の構造の中でデータが回収される。3つの情報データセットがあり、適切なオペレーションを用いてアクセスできる。
2.1デバイス情報データセット:デバイス情報データセットはデバイスの記述を提供するものであり、大抵は静的である。
2.2オブジェクト情報データセット:オブジェクト情報データセットはオブジェクトの中核プロパティの概要を提供する。中核プロパティには、オブジェクトのデータ成分のサイズが含まれる。プロパティにはアソシエーションも含まれ、アソシエーションはデータオブジェクトを関連づけ、デバイス上の階層ファイルシステムを記述するのに使用できる。デバイス上のファイル階層は、ある特定のファイルシステムに特有のパスまたは命名規約に頼らずとも表現できる。オブジェクトプロパティデータセットの中でオブジェクトのプロパティを引き出すこともできる。
2.3記憶情報データセット:記憶情報データセットは、デバイスの記憶内容を記述する。その記述には、最大容量と書き込みのために残っている空きスペースの両方が含まれる他、使用されているファイル命名規約やディレクトリ構造規約が含まれることもある。
3.プロパティ
3.1デバイスプロパティ:デバイスプロパティはデバイスの設定や状態を明らかにするものであり、デバイス上のデータオブジェクトには関連しない。デバイスプロパティは読み出し専用であってよく、または読み出し−書き込みであってもよい。プロパティはデバイスプロパティ記述データセットに収容され、適切なオペレーションを用いて設定できるるか、または引き出すことができる。
3.2オブジェクトプロパティ:オブジェクトプロパティは、オブジェクトを記述するメタデータを、オブジェクトそのものとは別に、交換するためのメカニズムを提供する。オブジェクトプロパティの主な利点として、ファイルシステムにかかわりなく大容量記憶を速やかに列挙できる。デバイス上のオブジェクトに関する情報を提供し、それらに収容できる値を指定する。プロパティはオブジェクトプロパティデータセットに収容され、適切なオペレーションを用いて設定できる、または引き出すことができる。
4.オブジェクトハンドル
オブジェクトハンドルは、デバイス上の論理オブジェクトに対する参照に一貫性を与える識別子であって、1セッションの中で一意である。オブジェクトハンドルの値に特別な意味はない。レスポンダは、イニシエータからのセッション開放オペレーションに応じてデバイス内のオブジェクトのためにオブジェクトハンドルのアレイを作成する。イニシエータはオブジェクトハンドル取得オペレーションによってオブジェクトハンドルを入手し、このオブジェクトハンドル取得オペレーションによってレスポンダはイニシエータへオブジェクトハンドルアレイを送信する。送信されるオブジェクトを規定するためにイニシエータがオブジェクト情報送信オペレーションを使用すると、レスポンダデバイスはオブジェクトハンドルを割り振り、オペレーションの応答段階でこれをイニシエータに返す。セッションが閉鎖されると全てのオブジェクトハンドルが無効となり、イニシエータはこれを改めて入手しなければならない。デバイスは同じオブジェクトハンドルを維持してよく、あるいは次のセッションでオブジェクトハンドルの値を変更してもよい。
5.オブジェクト参照
オブジェクトインターフェイスはファイルシステムに依存しないプロトコルだから、ファイル名を埋め込むことによってオブジェクト間に複雑なリンクが形成されることはない。任意のオブジェクト参照を可能にするために抽象的参照メカニズムが規定されている。参照は一方向であり、デバイス上の全てのオブジェクトで全ての参照を調べない限り、所与のオブジェクトを参照するオブジェクトがどれなのかを判断することはできない。参照は、適切なオペレーションを用いることによって設定できるか、または引き出すことができる。ファイルハンドルによって参照されるオブジェクトはセッションからセッションにかけて一貫しなければならない。削除済みオブジェクトに対する参照が誤って別のオブジェクトを参照することはあってはならない。オブジェクトハンドルは決して再使用してはならず、さもなくばデバイスがオブジェクトに対する全ての参照をオブジェクトと併せて削除しなければならない。
6.オペレーションと応答
トランザクションの中でイニシエータとレスポンダとの間で起こる通信はオペレーションによって決まる。開始されたオペレーションにレスポンダが働きかけるにあたって必要となる情報は、オペレーション要求でパラメータとして引き渡すことができる。5つのパラメータを送信できる。トランザクションのデータ段階では既定のデータセットの中で追加の情報を引き渡すこともできる。レスポンダはオペレーションの後に、最高5つまでのパラメータを伴う応答データセットと、オペレーションの結果を伝える応答コードとを返す。多数のオペレーションが定められている。一連のオペレーションの例として、「オブジェクト情報送信」オペレーションとその後に続く「オブジェクト送信」オペレーションがあり、これによりイニシエータはレスポンダへオブジェクトを送信し、さらに「オブジェクト情報取得」オペレーションとその後に続く「オブジェクト取得」オペレーションがあり、これによりイニシエータはレスポンダからオブジェクトを受信する。
図14Aは、イニシエータ410とレスポンダ412との間のトランザクションの一例を示している。イニシエータ410はPCであってよく、レスポンダ412はMP3音楽プレイヤまたはデジタルカメラであってよい。通信を可能にするため、イニシエータ410およびレスポンダ412は、例えばUSBケーブルによって接続される。第1に、イニシエータ410はオペレーション要求段階で起動しようとするオペレーションを「オブジェクト情報送信」オペレーションとして識別する。第2に、イニシエータ410はデータ段階でオブジェクト情報414をレスポンダ412へ送信する。オブジェクト情報414は、イニシエータ410によってレスポンダ412へ送信されようとしている特定のオブジェクトに関する情報である。オブジェクト情報414は、これが参照するオブジェクトが送信される前に、イニシエータ410によって送信される。オブジェクトのサイズなど、オブジェクトに関する様々な情報をオブジェクト情報に盛り込むことができる。送信すべきオブジェクトがMP3音楽ファイルなら、MP3音楽ファイルのサイズがオブジェクト情報の一部として送信される。第3に、レスポンダ412は応答段階で(レスポンダ412によってオブジェクト情報414が受信された後に)、オブジェクト情報414が受信済みであることを伝える。トランザクションはこの時点で終了してよい。
図14Bは、図14Aのトランザクションの後に続く、イニシエータ410とレスポンダ412との間の同一セッションの一部をなす、第2のトランザクションを示している。第2のトランザクションは「オブジェクト送信」トランザクションである。第1に、イニシエータ410はオペレーション要求段階で起動しようとするオペレーションを「オブジェクト送信」オペレーションとして識別する。第2に、イニシエータはデータ段階でオブジェクト416をレスポンダ412へ送信する。オブジェクト416はMP3音楽ファイルであってよく、あるいはJPEG、GIF、またはビットマップなどのファイル形式をとるデジタル写真であってもよい。オブジェクト416のオブジェクト情報414(ファイルサイズを含む)は、図14Aとの関係で説明したように、すでにイニシエータ410からレスポンダ412へ送信されている。第3に、レスポンダ412は応答段階で(オブジェクト416が受信された後に)、オブジェクト416が受信済みであることをイニシエータ410に伝える。トランザクションはこの時点で終了してよい。
オブジェクトプロトコルアダプタ
本発明の一実施形態において、前述したようにオブジェクトプロトコルを使用するホストがファイル本位バックエンドを使用するメモリシステムと連動できるようにするオブジェクトプロトコルアダプタがメモリシステムに用意される。オブジェクトプロトコルアダプタはオブジェクトプロトコルに従いオブジェクトインターフェイスを通じてデータおよびコマンドを受信し、データおよびコマンドをバックエンドへ送信する前に適切な翻訳を遂行する。一例において、ホストはMTPを使ってメモリシステムと連動し、メモリシステムは直接データファイルバックエンドを使ってデータを記憶する。オブジェクトプロトコルアダプタは、ホストインターフェイスおよびバックエンドとの間でコマンドとデータの両方で適切な変換を遂行する。
図15は、オブジェクトインターフェイス520とファイル本位バックエンド522との間に置かれたオブジェクトプロトコルアダプタの一例を示している。オブジェクトインターフェイス520は、所定サイズのファイルオブジェクト、例えばMTPまたはPTPオブジェクトのための、インターフェイスである。オブジェクトのサイズは、ホストによってオブジェクトが送信される前に送信される。オブジェクトプロトコルアダプタ524は、メモリシステム526がホストと通信する際のプロトコルを管理する。オブジェクトプロトコルアダプタ524はまた、ホストとの情報交換のためにトランザクションを管理し、翻訳を遂行する。オブジェクトプロトコルアダプタとファイル本位バックエンドとの間ではファイル本位プロトコルに従ってトランザクションが遂行される。
オブジェクトプロトコルアダプタ524は、(オブジェクトプロトコルに従って)新しいファイルオブジェクトがホストによって送信されるときに、適切なコマンドをファイル本位バックエンド522へ送信することによってファイルの開放と閉鎖とを管理する。特に、オブジェクトプロトコルではファイルが所定のサイズを有するため、オブジェクトプロトコルアダプタ524は、所定の量のファイルデータが受信されたときにファイルの閉鎖を担当する。オブジェクトプロトコルを使用するホストは通常、ファイル終了標識を別途送信しないから、ファイルオブジェクト全体が受信された時点でオブジェクトプロトコルアダプタ524がファイル終了標識を生成し、ファイル本位バックエンド522へ送信する。このように、オブジェクトプロトコルを使用するホストからメモリシステム526が複数のファイルを受信するとき、ファイル本位バックエンド522は、(直接データファイルバックエンドでよくあるように)最大開放ファイル数に達するまではファイルを開放状態に保たない。代わりに、各ファイルは完全なオブジェクトとして受信され、ファイル本位バックエンドは完全なファイルが受信された後にオブジェクトプロトコルアダプタ524からコマンドを受信するので、ファイル本位バックエンドはファイルを閉鎖する。これは多数の開放ファイルを維持する負担を軽減する。ひとたび閉鎖されたファイルはガーベッジコレクションのスケジュールに組み入れることができる。
オブジェクトプロトコルアダプタはメモリシステムの状態を管理できる。特に、直接データファイルバックエンドを有するメモリシステムの場合には、メモリシステムがそのオペレーションをホストコマンドに応じて変更できるようにするために3つの状態が規定される。3つの状態とは「アイドル」、「スタンバイ」および「シャットダウン」である。ホストが直接データファイルコマンドセットまたはこれと同等のものを使用する場合、3つの状態はホストからの対応する状態コマンドに応じて始まる。ホストがオブジェクトプロトコルを使用する場合、オブジェクトプロトコルアダプタは状態コマンドを生成できる。オブジェクトプロトコルアダプタは状態コマンドを、ホストがこれに対応するコマンドを含むオブジェクトプロトコルを使用しているならば、ホストから受信する同等のコマンドに応じて、ファイル本位バックエンドに送信できる。あるいは、オブジェクトプロトコルアダプタはホストの状態を他の要因からの推測に基づき状態コマンドを生成できる。例えば、ホストは一定期間にわたって電力を解除しないことを何らかの形で伝えることができ、これに応じてオブジェクトプロトコルアダプタは「アイドル」状態コマンドをファイル本位バックエンドへ送信できる。同様に、ホストは電力を解除しようとしていることを伝えることができ、あるいは電力が解除されようとしていることをオブジェクトプロトコルアダプタがホストの挙動に基づき推測でき、これに応じてオブジェクトプロトコルアダプタは「シャットダウン」コマンドをファイル本位バックエンドへ送信できる。
オブジェクトプロトコルアダプタの主要な機能の1つは、(オブジェクトプロトコルに従い)ホストから受信する規定ファイルのホストデータを、ファイル本位バックエンドのためのストリーミングデータに変換することである。オブジェクトプロトコルを使用するホストは(MTPの中でイニシエータとして動作しながら)既定サイズのファイルを送信し、レスポンダの応答を要求するが、ファイル本位バックエンドは通常、このような応答を提供する形に構成されていない。特に、直接データファイルバックエンドが使われる場合、データは通常ならばストリームされ、MTPの応答段階に相当するものはない。オブジェクトプロトコルアダプタはホストからのオブジェクトをストリーミングデータに変換し、オブジェクトの全データが受信された時点で適切な応答を生成する。
MTPなどのオブジェクトプロトコルでは、オブジェクトを読み出すまたは書き込む操作の前に、オブジェクトに関する情報を転送するために別途のオペレーションがある。オブジェクトが書き込まれる場合、このような情報転送オペレーションはオブジェクトプロパティ(オブジェクト情報)の「設定」オペレーションである。オブジェクトが読み出される場合、このような情報転送オペレーションはオブジェクトプロパティの「取得」オペレーションである。オブジェクトプロパティはデータセットの形をとり、ここにはオブジェクトの長さが含まれる。
図15のメモリシステム526へオブジェクトが書き込まれる場合はまず、オブジェクトプロトコルアダプタ524がホストからオブジェクトのデータセットを受け取る。ホストはMTPの中ではイニシエータとしてみなされる。データセットの中の情報は、書き込みオペレーションを実施する以降のトランザクションを制御するために使われる。データセットはまた、メタデータとしてメモリシステム526に記憶される。書き込みオペレーションの際に、オブジェクトプロトコルアダプタ524は書き込みオペレーションのデータ段階でイニシエータから転送されるデータ量をカウントする。オブジェクトプロトコルアダプタ524は、このカウントからオブジェクトデータの終わりを識別する。次いで、オブジェクトプロトコルアダプタは、ホストへ送信される応答を生成する。オブジェクトプロトコルアダプタ524はまた、ファイルを閉鎖するためのコマンドをファイル本位バックエンド522へ送信する。
図15のメモリシステム526からオブジェクトを読み出す場合はまず、オブジェクトプロトコルアダプタ524がファイル本位バックエンド522からオブジェクトのメタデータを入手する。オブジェクトのメタデータは、読み出しオペレーションを実施する以降のトランザクションを制御するために使われる。オブジェクトプロトコルアダプタ524はまた、メモリシステム526に記憶されたメタデータをオブジェクトのデータセットとしてホストへ送信する。オブジェクトプロトコルアダプタ526は、読み出しオペレーションのデータ段階でファイル本位バックエンド522から転送されるデータ量をカウントする。オブジェクトプロトコルアダプタ524は、このカウントからデータの終わりを識別する。オブジェクトプロトコルアダプタ524は応答を生成し、この応答はオブジェクトが送信された後にホストへ送信される。
オブジェクトプロトコルアダプタは、MTPなどのオブジェクトプロトコルで使われるオブジェクト情報データセットと、直接データファイルバックエンドを使用するファイル本位メモリシステムに記憶されたメタデータとの間で翻訳を行う。「メタデータ」はオブジェクトに関するデータを指す用語であり、オブジェクトとは別に記憶され、別個に管理される。よって、MTPにおけるオブジェクト情報データセットはメタデータの一例である。直接データファイルバックエンドはメタデータを、オブジェクトプロトコルで使われるものと同じ形式で、または異なる形式で記憶できる。用語「ファイル情報」は直接データファイルシステムのメタデータにも使われる。オブジェクトプロトコルアダプタ524はホストからメタデータ関係コマンドを受信する場合に、そのコマンドをファイル本位バックエンド522に適合する形式に翻訳できる。しかし、オブジェクトプロトコルでメタデータのために使われるコマンドはファイル本位バックエンド522に適合するから、翻訳は、場合によっては必要ない。
メタデータは、ホストによって生成されるファイル関連情報である。メタデータの性質と内容はホストによって決定され、通常ならばファイルとメタデータとを記憶するデバイスによって解析されない。メタデータコマンドは、直接データファイルバックエンドによって記憶される特定のファイルについてメタデータ入出力オペレーションを開始し、メタデータの中でオフセットアドレス値を規定するために使用される。メタデータコマンドは、MTPデータセットに関する対応するコマンドをホストから受信するときに、オブジェクトプロトコルアダプタによって生成される。以下の表には直接データファイルバックエンドシステムによって使用されるメタデータコマンドの例が示されている。
Figure 2009518698
Metadata_write :metadata_write_pointer の現在値によって決まるオフセットアドレスにある指定ファイルのメタデータは、metadata_write コマンドの受信後にデバイスへストリームされるメタデータによって上書きされる。指定ファイルのメタデータの内容と長さはホストによって決定される。metadata_write コマンドは、他の何らかのコマンドの受信をもって終了する。
Metadata_read:metadata_readコマンドの受信後、metadata_read_pointer の現在値によって決まるオフセットアドレスにある指定ファイルのメタデータはデバイスからストリームされる。メタデータのストリーミングはメタデータの終わりに達すると終了し、ホストはこの状況をステータスコマンドによって識別できる。metadata_readコマンドは、他の何らかのコマンドの受信をもって終了する。
Metadata_write_pointer :metadata_write_pointer コマンドは、指定ファイルのmetadata_write_pointer を指定されたオフセットアドレスに設定する。metadata_write_pointer は、metadata_write コマンドを受けてメタデータがデバイスへストリームされるにつれデバイスによって増加される。
Metadata_read_pointer :metadata_read_pointer コマンドは、指定ファイルのmetadata_read_pointer を指定されたオフセットアドレスに設定する。metadata_read_pointer は、metadata_readコマンドを受けてメタデータがデバイスからストリームされるにつれデバイスによって増加される。
ホストは、階層オブジェクト配置を有する場合がある。例えば、ファイルは、ディレクトリとサブディレクトリとに記憶されることがある。直接データファイルバックエンドは通常、階層構造なしでファイルを(つまり論理的にフラットな配置で)記憶する。2つのシステムを両立させるため、オブジェクトプロトコルアダプタは、記憶オブジェクトの階層構造を、オブジェクトに関連するメタデータを用いて再現できる。ホストが階層を保守する場合は、ファイルが記憶されるときに、階層におけるファイルの状態に関する情報がメタデータとして記憶される。メモリシステムがホストによってアクセスされるときには、最初にこのメタデータを読み出すことができ、これによりオブジェクトプロトコルアダプタは階層構造を判断でき、この情報をホストへ返すことができる。かくして、オブジェクトプロトコルアダプタは、たとえメモリシステムにて階層情報を顧慮せずファイルが記憶される場合でも、この階層情報を再現できる。例えば、ホストの階層の中でファイルが位置するディレクトリとサブディレクトリは、ファイルが記憶されるときにメタデータとして記憶できる。後ほどホストがメモリシステムの内容へアクセスを試みるときには、ホストへ返される情報にディレクトリおよびサブディレクトリの情報が反映される。
マルチプロトコルインターフェイス
本発明の一実施形態では、所定のサイズを有するオブジェクトと(例えば、MTPプロトコルに準拠)、所定のサイズを有さないストリーミングファイルとして受信されるファイルと、メモリシステムのために規定された論理アドレス空間の論理アドレスを持つデータセクタとを、受信でき記憶できるメモリシステムが提供される。プロトコルアダプタはこれらの3つのプロトコルに合わせて構成され、ホストで使われるプロトコルに応じて選択される。
図16は、共通の直接データファイルインターフェイス636へ接続された3つのプロトコルアダプタ630、632、634を有するメモリシステム629を示している。直接データファイルインターフェイス636および直接データファイル記憶638はファイル本位バックエンド640の中にあり、このファイル本位バックエンドは直接データファイルバックエンドとみなすことができる。よって、メモリシステム629は、ファイルインターフェイスのいずれかから受信するデータのための共通のバックエンドを使用する。このようなシステムにおいてメモリの区画化は必須ではないから、メモリアレイの使用可能な空間は効率的に使用される。よって、ファイルインターフェイスと、オブジェクトインターフェイスと、LBAインターフェイスとから別々のときに受信するデータを記憶するためにアレイ内のブロックを使用できる。しかし、LBAインターフェイスから受信するデータは、そのときLBAインターフェイスから受信したデータだけを記憶しているブロックに記憶できる。ファイルインターフェイスとオブジェクトインターフェイスから受信するデータは、そのファイル構造を概ね反映する形で管理されるから、ガーベッジコレクションは減る。
図16は、LBAプロトコルアダプタ634を通じてファイル本位バックエンド640へ接続されたLBAインターフェイス639を示している。LBAプロトコルアダプタ634はLBAデータを論理ファイルに変換でき、あるいは他の何らかの方法を用いてファイル本位バックエンドによる受信に適した形式にLBAデータを変換できる。
オブジェクトインターフェイス642はオブジェクトプロトコルアダプタ632を通じてファイル本位バックエンド640へ接続されている。通常、オブジェクトプロトコルアダプタ632は、オブジェクトプロトコルを使用するホストがファイル本位バックエンドにアクセスできるようにするため、ある1つのプロトコルから別のプロトコルにかけてデータおよびコマンドを変換する。これはオブジェクトプロトコルコマンドからファイル本位コマンドへの1対1の翻訳ですむこともあるが、場合によっては他方のプロトコルに対応するコマンドがないこともある。この場合、オブジェクトプロトコルアダプタは単なる翻訳以上のことを果たす。例えば、MTPホストがオブジェクトのサイズを含むメタデータを送信してからオブジェクトを送信する場合、オブジェクトプロトコルアダプタはそのオブジェクトの終わりを認識し、MTPホストに向けて応答を生成する。このときオブジェクトプロトコルアダプタは、ファイル本位バックエンドに向けてファイル閉鎖コマンドをも生成する。
ファイルインターフェイス644はファイルプロトコルアダプタ630を通じてファイル本位バックエンド640へ接続する。ホストは適切なファイル本位プロトコルを使用しながらファイル本位バックエンドと直接通信する場合もあり、翻訳は必要ない。しかし、ホストは、ファイル本位のプロトコルではあってもファイル本位バックエンドのそれとは同じでないプロトコルを使ってファイルを送信する場合もある。この場合、ファイルプロトコルアダプタ630が必要とされる翻訳を遂行する。
図16のメモリシステムは、少なくとも3通りのプロトコルを使用するホストに適合する。メモリシステムはまた、さらなるプロトコルアダプタが用意されるなら、別のホストにも適合する。
図17は図16のメモリシステム629を示し、ファイルプロトコルアダプタ630と、オブジェクトプロトコルアダプタ632と、LBAプロトコルアダプタ634とがまとめて翻訳層750とみなされる。各々のプロトコルアダプタは、特定のホストプロトコルとファイル本位バックエンド640との間で必要とされる翻訳を行う。メモリシステム629は、場合によっては一度に2つ以上のホストと通信することがある。例えば、メモリシステム629は、複数のホストが取り付けられたネットワークへ接続されることがある。別の例では、1つのホストが、あたかも別々のホストのようにそれぞれ動作するアプリケーションを実行し、異なるプロトコルを使用しながらメモリシステムと通信することがある。この場合、翻訳層750は各種ホスト間の不一致を解決しなければならない。翻訳層750は、ファイル本位バックエンド640が相反するコマンドを受け取らないようにするため、各種ホスト間の調停を行う。これは、ある1つのホストアクセスを、別のホストがある特定のタスクを完了するまで拒否することを意味する場合がある。例えば、オブジェクトプロトコルアダプタ632がオブジェクトまたはメタデータを転送している場合、翻訳層750は、そのオペレーションが完了するまで、LBAプロトコルアダプタ634とファイルプロトコルアダプタ630がファイル本位バックエンド640と通信するのを阻止する。これは、メモリシステムへのアクセスを試みているホストへ、LBAインターフェイス639またはファイルインターフェイス644を通じてビジー信号を送信することを意味することがある。いくつかの例では、別々のホストが互い違いのトランザクションにより同じ期間にわたってファイル本位バックエンド640にアクセスできる。この場合、翻訳層750がホスト間の調停を行う。
図17は、ファイルインターフェイス644と、オブジェクトインターフェイス642と、LBAインターフェイス639とを含むインターフェイス層752を示している。ファイルインターフェイス644と、オブジェクトインターフェイス642と、LBAインターフェイス639とは別個の構成要素として図に示されているが、これはメモリシステム629の論理インターフェイスを示す論理的表現であって、必ずしも3つの別々の物理インターフェイスがあるとは限らない。いくつかの例において、ファイルインターフェイス644、オブジェクトインターフェイス642、およびLBAインターフェイス639にとって、ならびに使用される他の何らかのインターフェイスにとって共通の、単一の物理インターフェイス(USBコネクタまたはSDコネクタなど)がある。使用するインターフェイス、したがって使用するプロトコルアダプタは、ホストで使用されるプロトコル次第で決まる。ホストは、メモリシステムが最初にホストへ接続されるときに、ハンドシェイクルーチンの一部としてホストプロトコルを指示する場合がある。ホストによって送信されるコマンドからメモリシステム629がホストプロトコルを推定する場合もある。インターフェイス層752は、ホストによって送信される指示から、または他の何らかの方法により、使用されているホストプロトコルを検出でき、そのホストプロトコルに準じた通信のための適切なインターフェイスを選択する。したがって、ホストでMTPプロトコルが使われていることをメモリシステムが検出する場合には、オブジェクトインターフェイス642とオブジェクトプロトコルアダプタ632とが選択される。通常は一度にただひとつのプロトコルアダプタが選択される。しかし、2つ以上のホストによる互い違いのアクセスを可能にするため、プロトコルアダプタがかわるがわるに選択されることもある。
図17の構成要素がメモリシステム629の論理コンポーネントに相当するが、必ずしも別々の物理構成要素に相当しないことが理解される。したがって、インターフェイス層752と翻訳層750の機能は専用回路によって達成でき、あるいはコントローラ上で動作する適切なファームウェアを用いて達成できる。一例において、メモリコントローラによって単一の物理インターフェイスが管理され、このメモリコントローラは、データとコマンドを共通バックエンドに適合する形式に変換するために、メモリコントローラ上で実行するプロトコルアダプタを選択する。図17は3つのプロトコルアダプタのみを示しているが、現実のメモリシステムに備わるプロトコルアダプタは3つを上回るか、または下回ることがある。場合によっては2つ以上のオブジェクトプロトコルアダプタがあってよい。例えば、MTPのためのオブジェクトプロトコルアダプタのほかに、別のオブジェクトプロトコル(例えば、PTP)のためのオブジェクトプロトコルアダプタがあってよい。同様に、別々のファイルプロトコルのための2つ以上のファイルプロトコルアダプタがあってよく、別々のLBAプロトコルのための別々のLBAプロトコルアダプタがあってよい。例えば、アラン・W・シンクレア(Alan W. Sinclair)による米国特許出願第11/302,764号「論理アドレスファイル記憶方法(Logically-Addressed File Storage Methods)」(特許文献32)には代替のLBAプロトコルの例が記載されている。
結論
これまで本発明の様々な態様をその代表的な実施形態との関係で説明してきたが、添付の特許請求の範囲の全範囲内においてその権利が保護されるべきであることが理解できよう。
現在実施されているホストと接続された不揮発性メモリシステムとを概略的に示す。 図1の不揮発性メモリとして使用されるフラッシュメモリシステムの例のブロック図である。 図2のシステムに使用できるメモリセルアレイの代表的な回路図である。 図2のシステムの物理メモリの編制例を示す。 図4の物理メモリの一部分の拡大図を示す。 図4および5の物理メモリの一部分のさらなる拡大図を示す。 ホストと再プログラム可能なメモリシステムとの間の一般的な先行技術の論理アドレスインターフェイスを示す。 ホストと再プログラム可能なメモリシステムとの間の一般的な先行技術の論理アドレスインターフェイスを図7とは異なる形で示す。 本発明によるホストと再プログラム可能なメモリシステムとの間の直接ファイル記憶インターフェイスを示す。 本発明によるホストと再プログラム可能なメモリシステムとの間の直接ファイル記憶インターフェイスを図9とは異なる形で示す。 メモリのために規定された共通論理アドレス空間の論理アドレスを有するセクタとしてホストから受信するホストファイルを記憶する方式を示し、このセクタは論理ファイルへマッピングされ、論理ファイルはメモリアレイにて1メタブロックにつき1論理ファイルずつ記憶される。 論理的にアドレスされるデータをメモリアレイ内の論理ファイルに記憶する方式を図11とは異なる形で示す。 ファイルインターフェイスと、ファイル本位バックエンドと通信するLBAインターフェイスの両方を有し、LBAインターフェイスとファイル本位バックエンドとの間にLBAプロトコルアダプタを置く、メモリシステムを示す。 MTP「オブジェクト情報送信」トランザクションを示す。 MTP「オブジェクト送信」トランザクションを示す。 オブジェクトインターフェイスとファイル本位バックエンドの両方を有し、それらの間にオブジェクトプロトコルアダプタを置く、メモリシステムを示す。 インターフェイスとファイル本位バックエンドとの通信を促進するため、ファイルインターフェイスと、オブジェクトインターフェイスと、LBAインターフェイスとを、ファイルプロトコルアダプタと、オブジェクトプロトコルアダプタと、LBAプロトコルアダプタとともに有する、メモリシステムを示す。 ファイルインターフェイスと、オブジェクトインターフェイスと、LBAインターフェイスとがインターフェイス層の一部とみなされ、ファイルプロトコルアダプタと、オブジェクトプロトコルアダプタと、LBAプロトコルアダプタとが翻訳層の一部とみなされる、図16のメモリシステムの代替図を示す。

Claims (37)

  1. 不揮発性メモリアレイにデータを記憶するメモリシステムであって、前記メモリシステムは1つ以上のアプリケーションから異なる論理形式でデータを受信し、かつ前記メモリアレイにて共通の論理形式でデータを記憶するメモリシステムにおいて、
    第1のアプリケーションから第1のデータを、第1のホストファイルとして、前記第1のホストファイルの長さを指示した後に、受信し、かつ前記第1のデータを前記不揮発性メモリアレイへ送信する第1のプロトコルアダプタであって、前記不揮発性メモリアレイでは第1のファイル識別子を用いて記録される位置に前記第1のデータが記憶される、第1のプロトコルアダプタと、
    第2のアプリケーションから第2のデータを、第2のホストファイルのデータとして識別されるデータストリームとして、前記第2のホストファイルの長さを指示せずに受信し、かつ前記第2のデータを前記不揮発性メモリアレイへ送信する第2のプロトコルアダプタであって、前記不揮発性メモリアレイでは第2のファイル識別子を用いて記録される位置に前記第2のデータが記憶される、第2のプロトコルアダプタと、
    第3のアプリケーションから第3のデータを、前記メモリシステムのために規定される論理アドレス範囲の中の個別論理アドレスを有する複数のセクタとして受信し、かつ前記第3のデータを前記不揮発性メモリアレイへ送信する第3のプロトコルアダプタであって、前記不揮発性メモリアレイでは第3のファイル識別子を用いて記録される位置に前記第3のデータが記憶される、第3のプロトコルアダプタと、
    を備えるメモリシステム。
  2. 請求項1記載のメモリシステムにおいて、
    前記メモリシステムは、規格化された接続により着脱可能な状態でホストシステムへ接続できるメモリカードに内蔵されるメモリシステム。
  3. 請求項2記載のメモリシステムにおいて、
    前記第1のアプリケーションは第1のホストシステムで実行し、前記メモリカードは第1のときに前記第1のホストシステムへ接続され、
    前記第2のアプリケーションは第2のホストシステムで実行し、前記メモリカードは第2のときに前記第2のホストシステムへ接続され、
    前記第3のアプリケーションは第3のホストシステムで実行し、前記メモリカードは第3のときに前記第3のホストシステムへ接続されるメモリシステム。
  4. 請求項1記載のメモリシステムにおいて、
    前記第1、第2、および第3のデータの前記位置は、前記第1、第2、および第3のファイル識別子の各々に対応する前記メモリアレイ内の1つ以上のブロックを指示する項目により記録されるメモリシステム。
  5. 請求項1記載のメモリシステムにおいて、
    前記第1のプロトコルアダプタは、前記第1のホストファイルが受信済みであることを伝える指示を前記ホストに向けて生成するメモリシステム。
  6. 請求項1記載のメモリシステムにおいて、
    前記第1のプロトコルアダプタは前記第1のホストファイルの終了の標識を生成し、標識により前記第1のデータはガーベッジコレクションのスケジュールに組み入れられるメモリシステム。
  7. ホストインターフェイスへ接続しかつ前記ホストインターフェイスを通じて受信するデータを記憶する着脱可能なメモリカードに埋め込まれたメモリシステムであって、
    不揮発性メモリアレイと、
    前記不揮発性メモリアレイの中でファイルとしてデータを管理するバックエンドメモリ管理システムと、
    ホストと通信するインターフェイス層と、
    前記インターフェイス層と前記バックエンドメモリ管理システムとの間に位置する翻訳層であって、前記翻訳層は前記インターフェイス層からホストコマンドを受信し、前記ホストコマンドはオブジェクトプロトコルに適合し、前記翻訳層は前記ホストコマンドの受信に応じて前記バックエンドメモリ管理システムに向けて翻訳済みコマンドを生成し、前記翻訳済みコマンドは前記オブジェクトプロトコルに適合しない、翻訳層と、
    を備えるメモリシステム。
  8. 請求項7記載のメモリシステムにおいて、
    前記オブジェクトプロトコルは、メディアトランスポートプロトコル(MTP)であるメモリシステム。
  9. 請求項7記載のメモリシステムにおいて、
    ホストはオブジェクトのサイズの指示を含むメタデータを前記オブジェクトを送信する前に送信し、前記翻訳層は前記ホストから前記オブジェクトの全体が受信済みであることを前記指示から判断するメモリシステム。
  10. 請求項9記載のメモリシステムにおいて、
    前記翻訳層は、前記オブジェクトの全体が受信済みとの判断に応じて、前記ホストへ送信される応答を生成し、かつ前記バックエンドメモリ管理システムへ送信されるファイル終了標識を生成するメモリシステム。
  11. 請求項7記載のメモリシステムであって、
    前記翻訳層は、
    ホストファイルプロトコルを使用する第2のホストから前記バックエンドファイルプロトコルにかけて通信を翻訳するファイルプロトコルアダプタと、
    論理アドレスプロトコルを使用する第3のホストから前記バックエンドファイルプロトコルにかけて通信を翻訳するLBAプロトコルアダプタと、
    をさらに備えるメモリシステム。
  12. 請求項11記載のメモリシステムにおいて、
    前記LBAプロトコルアダプタは、前記メモリシステムのために規定される論理アドレス空間から前記第3のホストによって割り振られた論理アドレスを有するデータセクタを受信し、かつ前記セクタを前記メモリアレイの1メタブロックの容量にサイズが等しい仮想ファイルにマッピングするメモリシステム。
  13. 不揮発性メモリアレイにデータを記憶するメモリシステムであって、前記メモリシステムは1つ以上のアプリケーションから異なる論理形式でデータを受信し、かつ前記メモリアレイにて共通の論理形式でデータを記憶するメモリシステムにおいて、
    第1のアプリケーションから第1のデータを、第1のホストファイルとして、前記第1のホストファイルの長さを指示した後に、受信し、かつ前記第1のデータを前記不揮発性メモリアレイへ送信する第1のプロトコルアダプタであって、前記不揮発性メモリアレイでは第1のファイル識別子を用いて記録される位置に前記第1のデータが記憶される、第1のプロトコルアダプタと、
    第2のアプリケーションから第2のデータを、第2のホストファイルのデータとして識別されるデータストリームとして、前記第2のホストファイルの長さを伝える先行の指示をせずに受信し、かつ前記第2のデータを前記不揮発性メモリアレイへ送信する第2のプロトコルアダプタであって、前記不揮発性メモリアレイでは第2のファイル識別子を用いて記録される位置に前記第2のデータが記憶される、第2のプロトコルアダプタと、
    を備えるメモリシステム。
  14. 請求項13記載のメモリシステムにおいて、
    前記メモリシステムは、規格化された接続により着脱可能な状態でホストシステムへ接続できるメモリカードに内蔵されるメモリシステム。
  15. 請求項14記載のメモリシステムにおいて、
    前記第1のアプリケーションは第1のホストシステムで実行し、前記メモリカードは第1のときに前記第1のホストシステムへ接続され、
    前記第2のアプリケーションは第2のホストシステムで実行し、前記メモリカードは第2のときに前記第2のホストシステムへ接続されるメモリシステム。
  16. 請求項13記載のメモリシステムにおいて、
    前記第1のデータと第2のデータとの前記位置は、前記第1および第2のファイル識別子の各々に対応する前記メモリアレイ内の1つ以上のブロックを指示する項目により記録されるメモリシステム。
  17. 請求項13記載のメモリシステムにおいて、
    前記第1のプロトコルアダプタは、前記第1のホストファイルが受信済みであることを伝える指示を前記ホストに向けて生成するメモリシステム。
  18. 請求項13記載のメモリシステムにおいて、
    前記第1のプロトコルアダプタは前記第1のホストファイルの終了の標識を生成し、標識により前記第1のデータはガーベッジコレクションのスケジュールに組み入れられるメモリシステム。
  19. 複数のホストプロトコルに適合するようにメモリシステムを操作する方法であって、前記メモリシステムはブロック消去可能なメモリアレイおよびコントローラを備える方法において、
    ホストへ接続されるときにホストプロトコルを検出し、検出された前記ホストプロトコルに応じて複数のプロトコルアダプタからプロトコルアダプタを選択するステップであって、前記複数のプロトコルアダプタは少なくとも第1、第2、および第3のプロトコルアダプタを含むステップと、
    所定の長さのファイルを、ファイルの長さの標識の後に、送信する第1のホストプロトコルの検出に応じて前記第1のプロトコルアダプタを選択するステップであって、個々のファイルは一意なファイル識別子を有するステップと、
    ファイルを、ファイルの長さの標識なしで、送信する第2のホストプロトコルの検出に応じて前記第2のプロトコルアダプタを選択するステップであって、個々のファイルは一意なファイル識別子を有するステップと、
    データセクタを送信する第3のホストプロトコルの検出に応じて前記第3のプロトコルアダプタを選択するステップであって、各セクタは前記メモリシステムのために規定される論理アドレス範囲の中の論理アドレスを有するステップと、
    を含む方法。
  20. 請求項19記載の方法において、
    前記第1のプロトコルアダプタを通じて受信する第1のファイルを前記メモリアレイの第1の複数のブロックに記憶し、前記第1のファイル識別子と前記第1の複数のブロックとの間の第1のアソシエーションを記録するステップと、
    前記第2のプロトコルアダプタを通じて受信する第2のファイルを前記メモリアレイの第2の複数のブロックに記憶し、前記第2のファイル識別子と前記第2の複数のブロックとの間の第2のアソシエーションを記録するステップと、
    前記第3のプロトコルアダプタを通じて受信する複数のセクタを第3の複数のブロックに記憶し、前記第3のファイル識別子と前記第3の複数のブロックとの間の第3のアソシエーションを記録するステップと、
    をさらに含む方法。
  21. 請求項19記載の方法において、
    前記第1のプロトコルアダプタは、前記所定の長さのデータが受信された後に前記第1のホストに向けて応答を生成する方法。
  22. 請求項19記載の方法において、
    前記第1のプロトコルアダプタは、前記所定の長さのデータの受信に応じてファイル終了標識を生成し、前記標識は、前記ファイルを閉鎖させ、かつガーベッジコレクションのスケジュールに組み入れる方法。
  23. 請求項19記載の方法において、
    前記第1、第2、または第3のプロトコルアダプタのうちのただひとつのプロトコルアダプタを随時一度に選択するステップをさらに含む方法。
  24. 請求項19記載の方法において、
    2つ以上のホストアプリケーションによる互い違いのアクセスを可能にするため、前記第1、第2、および第3のプロトコルアダプタのそれぞれをかわるがわるに選択するステップをさらに含む方法。
  25. 請求項19記載の方法において、
    前記メモリシステムは、着脱可能なメモリカードに埋め込まれる方法。
  26. 請求項25記載の方法において、
    前記メモリカードは、コンパクトフラッシュ、マルチメディアカード、セキュアデジタル、ミニSD、メモリスティック、スマートメディア、またはトランスフラッシュから選ばれる規格に準拠する方法。
  27. 着脱可能なメモリカードで不揮発性メモリシステムを操作する方法であって、
    オブジェクトの中のデータ量の指示を含むメタデータをホストから受信するステップと、
    引き続き前記ホストから前記オブジェクトを受信し、前記ホストから受信したオブジェクトデータの量を前記メタデータによって指示される前記データ量に比較することによって前記オブジェクトの全体が受信済みか否かを判断するステップと、
    前記オブジェクトの全体が受信済みとの判断に応じて、前記ホストへ応答を送信し、前記オブジェクトに対応する前記メモリシステム内のファイルを閉鎖するステップであって、前記ファイルは閉鎖の結果としてガーベッジコレクションに向けてマークされるステップと、
    を含む方法。
  28. 請求項27記載の方法において、
    前記不揮発性メモリシステムに前記メタデータを記憶するステップをさらに含む方法。
  29. 請求項27記載の方法において、
    前記ホストは前記オブジェクトを含む階層を保守し、前記階層の中での前記オブジェクトの位置は前記メタデータによって提供される方法。
  30. 請求項29記載の方法において、
    前記ファイルは、前記階層におけるその位置にかかわりなく前記メモリシステムに記憶される方法。
  31. 請求項30記載の方法において、
    前記メタデータは、その後前記ファイルがホストによって要求されるときに、前記階層を再現するために使用される方法。
  32. 複数のホストプロトコルに適合するように着脱可能なメモリシステムを操作する方法であって、前記メモリシステムはブロック消去可能なメモリアレイおよびコントローラを備える方法において、
    ホストへ接続されるときにホストプロトコルを検出し、検出された前記ホストプロトコルに応じて複数のプロトコルアダプタからプロトコルアダプタを選択するステップであって、前記複数のプロトコルアダプタは少なくとも第1のプロトコルアダプタと第2のプロトコルアダプタとを含むステップと、
    所定の長さのファイルを、ファイルの長さの標識の後に、送信する第1のホストプロトコルの検出に応じて前記第1のプロトコルアダプタを選択するステップであって、個々のファイルは一意なファイル識別子を有するステップと、
    ファイルを、ファイルの長さの標識なしで、送信する第2のホストプロトコルの検出に応じて前記第2のプロトコルアダプタを選択するステップであって、個々のファイルは一意なファイル識別子を有するステップと、
    を含む方法。
  33. 請求項32記載の方法において、
    前記第1のプロトコルアダプタを通じて受信する第1のファイルを前記メモリアレイの第1の複数のブロックに記憶し、第1のファイル識別子と前記第1の複数のブロックとの間の第1のアソシエーションを記録するステップと、
    前記第2のプロトコルアダプタを通じて受信する第2のファイルを前記メモリアレイの第2の複数のブロックに記憶し、第2のファイル識別子と前記第2の複数のブロックとの間の第2のアソシエーションを記録するステップと、
    をさらに含む方法。
  34. 請求項32記載の方法において、
    前記第1のプロトコルアダプタは、前記所定の長さのデータが受信された後に前記第1のホストに向けて応答を生成する方法。
  35. 請求項32記載の方法において、
    前記第1のプロトコルアダプタは、前記所定の長さのデータの受信に応じてファイル終了標識を生成し、前記標識は、前記ファイルを閉鎖させ、かつガーベッジコレクションのスケジュールに組み入れる方法。
  36. 請求項32記載の方法において、
    前記第1または第2のプロトコルアダプタのうちのただひとつのプロトコルアダプタを随時一度に選択するステップをさらに含む方法。
  37. 請求項32記載の方法において、
    前記着脱可能なメモリシステムが2つ以上のホストと通信する場合に、前記第1または第2のプロトコルアダプタのそれぞれをかわるがわるに選択するステップをさらに含む方法。
JP2008525201A 2005-08-03 2006-08-01 改良されたホストインターフェイス Expired - Fee Related JP5068754B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US70538805P 2005-08-03 2005-08-03
US60/705,388 2005-08-03
US11/316,577 2005-12-21
US11/316,578 2005-12-21
US11/316,577 US20070033326A1 (en) 2005-08-03 2005-12-21 Enhanced host interfacing methods
US11/316,578 US8291151B2 (en) 2005-08-03 2005-12-21 Enhanced host interface
PCT/US2006/030342 WO2007019258A2 (en) 2005-08-03 2006-08-01 Enhanced host interface

Publications (2)

Publication Number Publication Date
JP2009518698A true JP2009518698A (ja) 2009-05-07
JP5068754B2 JP5068754B2 (ja) 2012-11-07

Family

ID=37453103

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008525201A Expired - Fee Related JP5068754B2 (ja) 2005-08-03 2006-08-01 改良されたホストインターフェイス

Country Status (4)

Country Link
EP (1) EP1920318A2 (ja)
JP (1) JP5068754B2 (ja)
KR (1) KR101055324B1 (ja)
WO (1) WO2007019258A2 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8370402B2 (en) 2008-01-02 2013-02-05 Sandisk Il Ltd Dual representation of stored digital content
US8452927B2 (en) 2008-01-02 2013-05-28 Sandisk Technologies Inc. Distributed storage service systems and architecture
US8583878B2 (en) 2008-01-02 2013-11-12 Sandisk Il Ltd. Storage device having direct user access
US9098506B2 (en) 2008-01-02 2015-08-04 Sandisk Il, Ltd. Data indexing by local storage device
US8683148B2 (en) 2010-06-30 2014-03-25 Sandisk Il Ltd. Status indication when a maintenance operation is to be performed at a memory device
KR101278591B1 (ko) * 2011-05-30 2013-06-25 성균관대학교산학협력단 플래시 메모리 시스템 및 그 동작 방법
US9471484B2 (en) 2012-09-19 2016-10-18 Novachips Canada Inc. Flash memory controller having dual mode pin-out
US9165006B2 (en) 2012-10-25 2015-10-20 Blackberry Limited Method and system for managing data storage and access on a client device
US8943110B2 (en) 2012-10-25 2015-01-27 Blackberry Limited Method and system for managing data storage and access on a client device
EP2725477B1 (en) * 2012-10-25 2015-06-24 BlackBerry Limited Method and system for managing data storage and access on a client device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002369106A (ja) * 2001-04-06 2002-12-20 Sony Corp ディジタルカメラおよびデータ転送方法
US20040073727A1 (en) * 2002-07-29 2004-04-15 M-Systems Flash Disk Pioneers, Ltd. Portable storage media as file servers
WO2004042724A1 (en) * 2002-11-07 2004-05-21 Koninklijke Philips Electronics N.V. Record carrier having a main file system area and a virtual file system area
WO2004077335A2 (en) * 2003-02-25 2004-09-10 Infineon Technologies Flash Ltd. Multi-protocol memory card
JP2005122439A (ja) * 2003-10-16 2005-05-12 Sharp Corp デバイス機器、及びデバイス機器の記録装置のフォーマット変換方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7039727B2 (en) * 2000-10-17 2006-05-02 Microsoft Corporation System and method for controlling mass storage class digital imaging devices
KR100906856B1 (ko) * 2001-04-06 2009-07-08 소니 가부시끼 가이샤 디지털 카메라 및 데이터 전송 방법
US20020188592A1 (en) * 2001-06-11 2002-12-12 Storage Technology Corporation Outboard data storage management system and method
WO2005001701A1 (ja) * 2003-06-27 2005-01-06 Matsushita Electric Industrial Co., Ltd. スレイブ装置、通信設定方法
JP4318075B2 (ja) * 2003-08-29 2009-08-19 富士フイルム株式会社 Usbファンクション装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002369106A (ja) * 2001-04-06 2002-12-20 Sony Corp ディジタルカメラおよびデータ転送方法
US20040073727A1 (en) * 2002-07-29 2004-04-15 M-Systems Flash Disk Pioneers, Ltd. Portable storage media as file servers
WO2004042724A1 (en) * 2002-11-07 2004-05-21 Koninklijke Philips Electronics N.V. Record carrier having a main file system area and a virtual file system area
WO2004077335A2 (en) * 2003-02-25 2004-09-10 Infineon Technologies Flash Ltd. Multi-protocol memory card
JP2005122439A (ja) * 2003-10-16 2005-05-12 Sharp Corp デバイス機器、及びデバイス機器の記録装置のフォーマット変換方法

Also Published As

Publication number Publication date
EP1920318A2 (en) 2008-05-14
KR20080042850A (ko) 2008-05-15
WO2007019258A2 (en) 2007-02-15
JP5068754B2 (ja) 2012-11-07
KR101055324B1 (ko) 2011-08-08
WO2007019258A3 (en) 2007-07-19

Similar Documents

Publication Publication Date Title
US8291151B2 (en) Enhanced host interface
JP5068754B2 (ja) 改良されたホストインターフェイス
US8880483B2 (en) System and method for implementing extensions to intelligently manage resources of a mass storage system
US8762627B2 (en) Memory logical defragmentation during garbage collection
US7949845B2 (en) Indexing of file data in reprogrammable non-volatile memories that directly store data files
US7669003B2 (en) Reprogrammable non-volatile memory systems with indexing of directly stored data files
JP4533956B2 (ja) フラッシュメモリシステムのデータ記憶容量の解放
US7877540B2 (en) Logically-addressed file storage methods
US8239639B2 (en) Method and apparatus for providing data type and host file information to a mass storage system
US8713283B2 (en) Method of interfacing a host operating through a logical address space with a direct file storage medium
JP2009503729A (ja) 論理アドレス空間と直接データファイル方式で動作するインターフェイスシステム
US20070136553A1 (en) Logically-addressed file storage systems
KR101378031B1 (ko) 데이터 파일을 직접적으로 저장하는 메모리 블록의 관리
KR101464199B1 (ko) 연속 논리 주소 공간 인터페이스를 구비한 다이렉트 데이터 파일 시스템을 사용하는 방법
JP4441577B2 (ja) 固定サイズ格納ブロックを有するメモリシステムにおける変換データ単位格納
JP2009503744A (ja) 予定再生操作を伴う不揮発性メモリ
JP2009519555A (ja) 論理アドレス形ファイル記憶

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20101108

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101124

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110217

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111101

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120201

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20120615

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: 20120724

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120815

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150824

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5068754

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees