JP7167291B2 - メモリシステムおよび制御方法 - Google Patents

メモリシステムおよび制御方法 Download PDF

Info

Publication number
JP7167291B2
JP7167291B2 JP2021172380A JP2021172380A JP7167291B2 JP 7167291 B2 JP7167291 B2 JP 7167291B2 JP 2021172380 A JP2021172380 A JP 2021172380A JP 2021172380 A JP2021172380 A JP 2021172380A JP 7167291 B2 JP7167291 B2 JP 7167291B2
Authority
JP
Japan
Prior art keywords
data
write
host
request
storage device
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.)
Active
Application number
JP2021172380A
Other languages
English (en)
Other versions
JP2022009357A (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.)
Kioxia Corp
Original Assignee
Kioxia 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 JP2017236269A external-priority patent/JP6967959B2/ja
Application filed by Kioxia Corp filed Critical Kioxia Corp
Priority to JP2021172380A priority Critical patent/JP7167291B2/ja
Publication of JP2022009357A publication Critical patent/JP2022009357A/ja
Priority to JP2022166280A priority patent/JP7400053B2/ja
Application granted granted Critical
Publication of JP7167291B2 publication Critical patent/JP7167291B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Memory System (AREA)

Description

本発明の実施形態は、不揮発性メモリを制御する技術に関する。
近年、不揮発性メモリを備えるメモリシステムが広く普及している。このようなメモリシステムの一つとして、NANDフラッシュ技術ベースのソリッドステートドライブ(SSD)が知られている。
データセンターのサーバにおいても、ストレージデバイスとしてSSDが使用されている。
サーバのようなホスト計算機システムにおいて利用されるストレージデバイスにおいては、高いI/O性能が求められている。
このため、最近では、ホストとストレージデバイスとの間の新たなインタフェースが提案され始めている。
また、最近のストレージデバイスにおいては、異なる種類のデータを異なる書き込み先ブロックに書き込むことを可能にすることが求められる場合がある。
Yiying Zhang, 外, "De-indirection for flash-based SSDs with nameless writes." FAST. 2012, [online], [平成29年9月13日検索], インターネット<URL: https://www.usenix.org/system/files/conference/fast12/zhang.pdf >
しかし、同時に利用可能な書き込み先ブロックの数が増えると、個々の書き込み先ブロックに書き込むべきライトデータを一時的に格納するために必要なライトバッファの数も増やすことが必要となる。通常、ストレージデバイス内のランダムアクセスメモリの容量は限られているので、ストレージデバイスにとっては、十分な数のライトバッファを用意することは困難な場合がある。このため、実際上、同時に利用可能な書き込み先ブロックの数は制限される結果となる。
本発明が解決しようとする課題は、同時に利用可能な書き込み先ブロックの数を増やすことができるメモリシステムおよび制御方法を提供することである。
実施形態によれば、ホストに接続可能なメモリシステムは、複数のブロックを含む不揮発性メモリと、前記不揮発性メモリに電気的に接続され、前記不揮発性メモリを制御するように構成されたコントローラとを具備する。前記コントローラは、書き込むべき第1のデータが格納されている前記ホストのメモリ上のライトバッファ内の位置を示す記憶位置情報を含むライト要求を前記ホストから受信し、前記第1のデータを、複数段階のプログラム動作によって前記不揮発性メモリに書き込む際に、前記複数段階のプログラム動作の各プログラム動作の度に、前記記憶位置情報を含む転送要求を前記ホストに送信することによって前記第1のデータを前記ライトバッファから取得し、前記第1のデータを前記不揮発性メモリに転送し、前記第1のデータを前記複数のブロックのうちの一つの書き込み先ブロックに書き込む
ホストとメモリシステム(フラッシュストレージデバイス)との関係を示すブロック図。 フラッシュストレージデバイスの構成例を示すブロック図。 フラッシュストレージデバイスにおいて使用される複数のチャンネルと複数のNAND型フラッシュメモリチップとの関係を示すブロック図。 フラッシュストレージデバイスにおいて使用される、あるスーパーブロックの構成例を示す図。 複数のエンドユーザに対応する複数の書き込み先ブロックと複数のライトバッファ領域との関係を示す図。 フラッシュストレージデバイスとホスト側UWBとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理を説明するためのブロック図。 複数の書き込み先ブロックと複数のライトバッファ領域(UWB領域)との関係の例を示す図。 フラッシュストレージデバイスとホスト側UWBとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ読み出し処理を説明するためのブロック図。 フォギー・ファイン書き込みをサポートするフラッシュストレージデバイスとホスト側UWBとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理を説明するためのブロック図。 フォギー・ファイン書き込みをサポートするフラッシュストレージデバイスとホスト側UWBとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ読み出し処理を説明するためのブロック図。 ホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理の手順を示すシーケンス図。 フラッシュストレージデバイスによって実行される通知処理の手順を示すフローチャート。 転送要求の受信に応じて実行されるホスト側処理の手順を示すフローチャート。 リード要求の受信に応じてフラッシュストレージデバイスによって実行されるデータ読み出し動作の手順を示すフローチャート。 データ読み出しのためのホスト側処理の手順を示すフローチャート。 ストリーム書き込みをサポートするフラッシュストレージデバイスとホスト側UWBとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理を説明するためのブロック図。 複数のストリームIDとこれらストリームIDに関連付けられた複数の書き込み先ブロックとの関係を示す図。 ストリーム書き込みをサポートするフラッシュストレージデバイスとホスト側UWBとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ読み出し処理を説明するためのブロック図。 フォギー・ファイン書き込みをサポートするフラッシュストレージデバイスとホストとによって実行されるデータ書き込み処理の手順を示すシーケンス図。 ホストの構成例を示すブロック図。 ホスト内のプロセッサ(CPU)によって実行されるデータ書き込み処理の手順を示すフローチャート。 ホスト内のプロセッサによって実行されるデータ読み出し処理の手順を示すフローチャート。 ホスト内のプロセッサによって実行されるデータ読み出し処理の別の手順を示すフローチャート。 ホスト内のプロセッサによって実行されるUWB領域解放処理の手順を示すフローチャート。
以下、図面を参照して、実施形態を説明する。
まず、図1を参照して、ホストとメモリシステムとの関係を説明する。
このメモリシステムは、不揮発性メモリにデータを書き込み、不揮発性メモリからデータを読み出すように構成された半導体ストレージデバイスである。このメモリシステムは、NANDフラッシュ技術ベースのフラッシュストレージデバイス3として実現されている。
ホスト(ホストデバイス)2は、複数のフラッシュストレージデバイス3を制御するように構成されている。ホスト2は、複数のフラッシュストレージデバイス3によって構成されるフラッシュアレイをストレージとして使用するように構成された情報処理装置によって実現される。この情報処理装置はパーソナルコンピュータであとてもよいし、サーバコンピュータであってもよい。
なお、フラッシュストレージデバイス3は、ストレージアレイ内に設けられる複数のストレージデバイスの一つとして利用されてもよい。ストレージアレイは、サーバコンピュータのような情報処理装置にケーブルまたはネットワークを介して接続されてもよい、ストレージアレイは、このストレージアレイ内の複数のストレージ(例えば複数のフラッシュストレージデバイス3)を制御するコントローラを含む。フラッシュストレージデバイス3がストレージアレイに適用された場合には、このストレージアレイのコントローラが、フラッシュストレージデバイス3のホストとして機能してもよい。
以下では、サーバコンピュータのような情報処理装置がホスト2として機能する場合を例示して説明する。
ホスト(サーバ)2と複数のフラッシュストレージデバイス3は、インタフェース50を介して相互接続される(内部相互接続)。この相互接続のためのインタフェース50としては、これに限定されないが、PCI Express(PCIe)(登録商標)、NVM Express(NVMe)(登録商標)、Ethernet(登録商標)、NVMe over Fabrics(NVMeOF)等を使用し得る。
ホスト2として機能するサーバコンピュータの典型例としては、データセンター内のサーバコンピュータ(以下、サーバと称する)が挙げられる。
ホスト2がデータセンター内のサーバによって実現されるケースにおいては、このホスト(サーバ)2は、ネットワーク51を介して複数のエンドユーザ端末(クライアント)61に接続されてもよい。ホスト2は、これらエンドユーザ端末61に対して様々なサービスを提供することができる。
ホスト(サーバ)2によって提供可能なサービスの例には、(1)システム稼働プラットフォームを各クライアント(各エンドユーザ端末61)に提供するプラットホーム・アズ・ア・サービス(PaaS)、(2)仮想サーバのようなインフラストラクチャを各クライアント(各エンドユーザ端末61)に提供するインフラストラクチャ・アズ・ア・サービス(IaaS)、等がある。
複数の仮想マシンが、このホスト(サーバ)2として機能する物理サーバ上で実行されてもよい。ホスト(サーバ)2上で走るこれら仮想マシンの各々は、対応する幾つかのクライアント(エンドユーザ端末61)に各種サービスを提供するように構成された仮想サーバとして機能することができる。
ホスト(サーバ)2は、フラッシュアレイを構成する複数のフラッシュストレージデバイス3を管理するストレージ管理機能と、エンドユーザ端末61それぞれに対してストレージアクセスを含む様々なサービスを提供するフロントエンド機能とを含む。
フラッシュストレージデバイス3は、NAND型フラッシュメモリのような不揮発性メモリを含む。一つのフラッシュストレージデバイス3は、不揮発性メモリ内の複数のブロックから割り当てられた複数の書き込み先ブロックを管理する。書き込み先ブロックとは、データが書き込まれるべきブロックを意味する。ホスト2からフラッシュストレージデバイス3に送出されるライト要求(ライトコマンド)には、データが書き込まれるべき一つの書き込み先ブロックに関連づけられた識別子が含まれる。このライト要求に含まれるこの識別子に基づいて、フラッシュストレージデバイス3は、複数の書き込み先ブロックから、このデータが書き込まれるべき一つの書き込み先ブロックを決定する。
このライト要求に含まれる識別子は、特定の書き込み先ブロックを指定するブロック識別子であってもよい。ブロック識別子は、ブロックアドレス(ブロック番号)によって表されてもよい。あるいは、フラッシュストレージデバイス3が複数のNAND型フラッシュメモリチップを含むケースにおいては、ブロック識別子は、ブロックアドレス(ブロック番号)とチップ番号との組み合わせによって表されてもよい。
フラッシュストレージデバイス3がストリーム書き込みをサポートしているケースにおいては、このライト要求に含まれる識別子は、複数のストリーム内の一つのストリームの識別子(ストリームID)であってもよい。ストリーム書き込みにおいては、複数の書き込み先ブロックが複数のストリームにそれぞれ関連付けられる。換言すれば、フラッシュストレージデバイス3があるストリームIDを含むライト要求をホスト2から受信した場合、このフラッシュストレージデバイス3は、このストリームIDに対応するストリームに関連づけられた書き込み先ブロックにデータを書き込む。フラッシュストレージデバイス3が別のストリームIDを含むライト要求をホスト2から受信した場合、このフラッシュストレージデバイス3は、この別のストリームIDに対応する別のストリームに関連づけられた別の書き込み先ブロックにデータを書き込む。
フラッシュストレージデバイス3によって管理される複数の書き込み先ブロックは、このフラッシュストレージデバイス3を共有する複数のエンドユーザ(クライアント)によってそれぞれ使用されてもよい。この場合、フラッシュストレージデバイス3においては、フラッシュストレージデバイス3を共有するエンドユーザの数と同数またはそれ以上の書き込み先ブロックがオープンされる。
このように、同時に利用可能な複数の書き込み先ブロックがフラッシュストレージデバイス3に存在する環境においては、これら書き込み先ブロックの数と同数のライトバッファを用意することが必要となる。
なぜなら、最近のNAND型フラッシュメモリの多くはメモリセル当たりに複数ビットのデータを書き込むように構成されており、書き込み先ブロック毎に、この書き込み先ブロックに書き込まれるべき複数ページ分のデータを保持しておくことが必要となるからである。
また、最近のNAND型フラッシュメモリにおいては、プログラムディスターブを削減するために、ライトデータをNAND型フラッシュメモリに複数回転送することを伴う複数段階のプログラム動作によってライトデータをNAND型フラッシュメモリに書き込むというライト方法が適用されるケースがある。このようなライト方法の典型例としては、フォギー・ファイン・プログラム動作が挙げられる。この場合においても、複数段階のプログラム動作が終了するまでライトデータを保持する必要があるので、書き込み先ブロックの数と同数のライトバッファを用意することが必要となる。
フォギー・ファイン・プログラム動作では、例えば、複数ページ分の第1のライトデータがNAND型フラッシュメモリに転送され、そして第1のライトデータが最初の物理ページ(あるワード線に接続されたメモリセル群)に書き込まれる(一段階目の書き込み:フォギー書き込み)。この後、最初の物理ページに隣接する別の物理ページ(別のワード線に接続されたメモリセル群)に対するフォギー書き込みが実行される。そして、上述の複数ページ分の第1のライトデータがNAND型フラッシュメモリに再び転送され、そしてこの第1のライトデータが最初の物理ページに書き込まれる(二段階目の書き込み:ファイン書き込み)。この後、上述の別の物理ページに対するファイン書き込みが実行される。
しかし、フラッシュストレージデバイス3内のランダムアクセスメモリの容量は限られているので、十分な数のライトバッファをフラッシュストレージデバイス3内のランダムアクセスメモリ上に用意することは困難な場合がある。また、たとえフラッシュストレージデバイス3に大容量のランダムアクセスメモリを用意したとしても、フラッシュストレージデバイス3を共有するエンドユーザの数が少ない場合には、大容量のランダムアクセスメモリが無駄になる結果となる。
そこで、本実施形態では、ホスト2のメモリ上の所定の記憶領域がライトバッファ(以下、UWB:Unified Write Bufferと称する)2Aとして利用される。ホスト2側のUWB2Aは、複数の書き込み先ブロックに対応する複数のライトバッファ領域を含む。
ホスト2は、一つの書き込み先ブロックに書き込むべきライトデータをUWB2A(この書き込み先ブロックに対応するライトバッファ領域)に格納する。そして、ホスト2は、この一つの書き込み先ブロックに関連付けられた識別子(ブロック識別子またはストリームID)と、このライトデータが格納されているUWB2A内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス3に送出する。
フラッシュストレージデバイス3は、このライト要求をホスト2から受信し、識別子と記憶位置情報とを保持する。フラッシュストレージデバイス3は、このライトデータをNAND型フラッシュメモリに書き込む際に、上述の記憶位置情報を含む転送要求をホスト2に送出することによって上述のライトデータをUWB2Aから取得する。例えば、NAND型フラッシュメモリがメモリセル当たりに3ビットのデータを格納するTLC(トリプル・レベル・セル)-フラッシュメモリである場合には、同一の物理ページに書き込むべき3ページ分のライトデータがUWB2Aから取得される。一つの物理ページには3つのページアドレスが割り当てられてもよい。そして、フラッシュストレージデバイス3は、このライトデータを一つの書き込み先ブロック(この書き込み先ブロックのある物理ページ)に書き込む。
フラッシュストレージデバイス3は、フル・シーケンス・プログラム動作によってこのライトデータを一つの書き込み先ブロックに書き込んでもよい。
あるいは、フラッシュストレージデバイス3は、ライトデータ(例えば3ページ分のライトデータ)をNAND型フラッシュメモリに複数回転送することを伴う複数段階のプログラム動作(例えばフォギー・ファイン・プログラム動作)によってこのライトデータを一つの書き込み先ブロックに書き込んでもよい。この場合には、フラッシュストレージデバイス3は、最初に、一段階目の書き込み動作を実行する。その後、二段階目の書き込み動作を実行するタイミングになった時に、フラッシュストレージデバイス3は、上述の記憶位置情報を含む転送要求をホスト2に再び送出する。ホスト2は、上述の記憶位置情報を含む転送要求をフラッシュストレージデバイス3から受信する度に、このライトデータをUWB2Aからフラッシュストレージデバイス3に転送する。上述のライトデータをUWB2Aから再び取得すると、フラッシュストレージデバイス3は、二段階目の書き込み動作を実行する。
フラッシュストレージデバイス3は、このライトデータの書き込みが終了し且つこのライトデータがNAND型フラッシュメモリから読み出し可能になった場合(フル・シーケンス・プログラム動作においてはフル・シーケンス・プログラム動作が終了した場合、フォギー・ファイン・プログラム動作においてはフォギー書き込み動作とファイン書き込み動作の双方が終了した場合)に、UWB2Aに保持されているこのライトデータが不要になったことをホスト2に通知する。
したがって、本実施形態においては、フラッシュストレージデバイス3に多数のライトバッファを用意することなく、多数の書き込み先ブロックを同時に利用することが可能となる。したがって、フラッシュストレージデバイス3に大容量のランダムアクセスメモリを設ける必要が無くなるので、フラッシュストレージデバイス3のコストアップを招くことなく、フラッシュストレージデバイス3を共有するエンドユーザの数を容易に増やすことが可能となる。
図2は、フラッシュストレージデバイス3の構成例を示す。
フラッシュストレージデバイス3は、コントローラ4および不揮発性メモリ(NAND型フラッシュメモリ)5を備える。フラッシュストレージデバイス3は、ランダムアクセスメモリ、例えば、DRAM6も備えていてもよい。
NAND型フラッシュメモリ5は、マトリクス状に配置された複数のメモリセルを含むメモリセルアレイを含む。NAND型フラッシュメモリ5は、2次元構造のNAND型フラッシュメモリであってもよいし、3次元構造のNAND型フラッシュメモリであってもよい。
NAND型フラッシュメモリ5のメモリセルアレイは、複数のブロックBLK0~BLKm-1を含む。ブロックBLK0~BLKm-1の各々は多数のページ(ここではページP0~Pn-1)によって編成される。ブロックBLK0~BLKm-1は、消去単位として機能する。ブロックは、「消去ブロック」、「物理ブロック」、または「物理消去ブロック」と称されることもある。ページP0~Pn-1の各々は、同一ワード線に接続された複数のメモリセルを含む。ページP0~Pn-1は、「物理ページ」と称されることもある。ページP0~Pn-1は、データ書き込み動作およびデータ読み込み動作の単位である。
コントローラ4は、Toggle、オープンNANDフラッシュインタフェース(ONFI)のようなフラッシュプログラミングコントローラ13を介して、不揮発性メモリであるNAND型フラッシュメモリ5に電気的に接続されている。コントローラ4は、NAND型フラッシュメモリ5を制御するように構成されたメモリコントローラとして動作する。このコントローラ4は、System-on-a-chip(SoC)のような回路によって実現されてもよい。
NAND型フラッシュメモリ5は、図3に示すように、複数のNAND型フラッシュメモリチップ(NAND型フラッシュメモリダイ)を含んでいてもよい。個々のNAND型フラッシュメモリチップは独立して動作可能である。このため、NAND型フラッシュメモリチップは、並列動作可能な単位として機能する。図3においては、フラッシュプログラミングコントローラ13に16個のチャンネルCh.1~Ch.16が接続されており、16個のチャンネルCh.1~Ch.16の各々に2つのNAND型フラッシュメモリチップが接続されている場合が例示されている。この場合、チャンネルCh.1~Ch.16に接続された16個のNAND型フラッシュメモリチップ#1~#16がバンク#0として編成されてもよく、またチャンネルCh.1~Ch.16に接続された残りの16個のNAND型フラッシュメモリチップ#17~#32がバンク#1として編成されてもよい。バンクは、複数のメモリモジュールをバンクインタリーブによって並列動作させるための単位として機能する。図3の構成例においては、16チャンネルと、2つのバンクを使用したバンクインタリーブとによって、最大32個のNAND型フラッシュメモリチップを並列動作させることができる。
消去動作は、一つのブロック(物理ブロック)の単位で実行されてみよいし、並列動作可能な複数の物理ブロックの集合を含むスーパーブロックの単位で実行されてもよい。一つのスーパーブロックは、これに限定されないが、NAND型フラッシュメモリチップ#1~#32から一つずつ選択される計32個の物理ブロックを含んでいてもよい。なお、NAND型フラッシュメモリチップ#1~#32の各々はマルチプレーン構成を有していてもよい。例えば、NAND型フラッシュメモリチップ#1~#32の各々が、2つのプレーンを含むマルチプレーン構成を有する場合には、一つのスーパーブロックは、NAND型フラッシュメモリチップ#1~#32に対応する64個のプレーンから一つずつ選択される計64個の物理ブロックを含んでいてもよい。
図4には、32個の物理ブロック(ここでは、NAND型フラッシュメモリチップ#1内の物理ブロックBLK2、NAND型フラッシュメモリチップ#2内の物理ブロックBLK3、NAND型フラッシュメモリチップ#3内の物理ブロックBLK7、NAND型フラッシュメモリチップ#4内の物理ブロックBLK4、NAND型フラッシュメモリチップ#5内の物理ブロックBLK6、…NAND型フラッシュメモリチップ#32内の物理ブロックBLK3)を含む一つのスーパーブロック(SB)が例示されている。
書き込み先ブロックは一つの物理ブロックであってもよいし、一つのスーパーブロックであってもよい。なお、一つのスーパーブロックが一つの物理ブロックのみを含む構成が利用されてもよく、この場合には、一つのスーパーブロックは一つの物理ブロックと等価である。
次に、図1のコントローラ4の構成について説明する。
コントローラ4は、ホストインタフェース11、CPU12、フラッシュプログラミングコントローラ13、およびDRAMインタフェース14等を含む。これらCPU12、フラッシュプログラミングコントローラ13、DRAMインタフェース14は、バス10を介して相互接続される。
このホストインタフェース11は、ホスト2との通信を実行するように構成されたホストインタフェース回路である。このホストインタフェース11は、例えば、PCIeコントローラ(NVMeコントローラ)であってもよい。あるいは、フラッシュストレージデバイス3がEthernet(登録商標)を介してホスト2に接続される構成においては、ホストインタフェース11は、NVMe over Fabrics(NVMeOF)コントローラであってもよい。フラッシュストレージデバイス3がEthernet(登録商標)を介してホスト2に接続される構成は、必要に応じて、フラッシュストレージデバイス3の数を容易に増やすことを可能にする。さらに、ホスト2の数を容易に増やすことも可能である。
ホストインタフェース11は、ホスト2から様々な要求(コマンド)を受信する。これら要求(コマンド)には、ライト要求(ライトコマンド)、リード要求(リードコマンド)、他の様々な要求(コマンド)が含まれる。
CPU12は、ホストインタフェース11、フラッシュプログラミングコントローラ13、DRAMインタフェース14を制御するように構成されたプロセッサである。CPU12は、フラッシュストレージデバイス3の電源オンに応答してNAND型フラッシュメモリ5または図示しないROMから制御プログラム(ファームウェア)をDRAM6にロードし、そしてこのファームウェアを実行することによって様々な処理を行う。なお、ファームウェアはコントローラ4内の図示しないSRAM上にロードされてもよい。このCPU12は、ホスト2からの様々なコマンドを処理するためのコマンド処理等を実行することができる。CPU12の動作は、CPU12によって実行される上述のファームウェアによって制御される。なお、コマンド処理の一部または全部は、コントローラ4内の専用ハードウェアによって実行してもよい。
CPU12は、ブロック識別子/バッファアドレス受信部21、転送要求送信部22、および通知部23として機能することができる。
ブロック識別子/バッファアドレス受信部21は、ブロック識別子とバッファアドレスとを含むライト要求をホスト2から受信し、これらブロック識別子とバッファアドレスを所定の記憶領域に保持する。ライト要求に含まれるブロック識別子は、ある特定の書き込み先ブロックを指定するブロックアドレスであってもよい。あるいは、ライト要求は、ブロック識別子の代わりに、ストリームIDを含んでいてもよい。ブロック識別子またはストリームIDは、一つの書き込み先ブロックに関連付けられた識別子として機能する。ライト要求に含まれるバッファアドレスは、書き込むべきデータ(ライトデータ)が格納されているUWB2A内の位置を示す記憶位置情報である。あるいは、ライト要求は、バッファアドレスの代わりに、バッファ内オフセットを記憶位置情報として含んでいてもよい。バッファ内オフセットは、ライトデータが格納されているUWB2A内のオフセット位置を示す。
転送要求送信部22は、上述のライトデータをNAND型フラッシュメモリ5に書き込む際に、記憶位置情報(例えばバッファアドレス)を含む転送要求をホスト2に送出し、これによってライトデータをUWB2Aから取得する。
通知部23は、上述のライトデータの書き込みが終了し且つ上述のライトデータがNAND型フラッシュメモリ5から読み出し可能になった場合、UWB2Aに保持されている上述のライトデータが不要になったことをホスト2に通知する。
フラッシュプログラミングコントローラ13は、CPU12の制御の下、NAND型フラッシュメモリ5を制御するように構成されたメモリ制御回路である。
DRAMインタフェース14は、CPU12の制御の下、DRAM6を制御するように構成されたDRAM制御回路である。DRAM6の記憶領域の一部は、リードバッファ(RB)30、ライトバッファ(WB)31、ブロック管理テーブル32、不良情報管理テーブル33の格納のために使用される。なお、これらリードバッファ(RB)30、ライトバッファ(WB)31、ブロック管理テーブル32、不良情報管理テーブル33は、コントローラ4内の図示しないSRAMに格納されてもよい。ブロック管理テーブル32は、各ブロックに格納されているデータが有効データまたは無効データのいずれであるかを管理する。不良情報管理テーブル33は、不良ブロックのリストを管理する。
図5は、複数のエンドユーザに対応する複数の書き込み先ブロックと複数のライトバッファ領域との関係を示す。
フラッシュストレージデバイス3においては、ブロックの状態は、有効データを格納しているアクティブブロックと、有効データを格納していないフリーブロックとに大別される。アクティブブロックである各ブロックは、アクティブブロックプールと称されるリストによって管理される。一方、フリーブロックである各ブロックは、フリーブロックプールと称されるリストによって管理される。
本実施形態では、コントローラ4は、フリーブロックプールから選択された複数のブロック(フリーブロック)を、ホスト2から受信されたライトデータが書き込まれるべき書き込み先ブロックとして割り当てる。この場合、コントローラ4は、まず、選択された各ブロック(フリーブロック)に対する消去動作を実行し、これによって各ブロックを、書き込み可能な消去状態にする。書き込み可能な消去状態にされたブロックが、オープンされた書き込み先ブロックとなる。ある書き込み先ブロックの全体がホスト2からのライトデータで満たされると、コントローラ4は、この書き込み先ブロックをアクティブブロックプールに移動し、フリーブロックプールから新たな一つのブロック(フリーブロック)を新たな書き込み先ブロックとして割り当てる。
フラッシュストレージデバイス3においては、フラッシュストレージデバイス3を共有するエンドユーザ(エンドユーザ端末)と同数またはそれよりも多い書き込み先ブロック(フラッシュブロック)がオープンされる。ホスト2側のUWB2Aは、これら書き込み先ブロック(フラッシュブロック)と同数のライトバッファ領域(UWB領域)を含んでいてもよい。
図5においては、ライトバッファ領域#1は書き込み先ブロック#1に関連付けられており、書き込み先ブロック#1に書き込むべき全てのデータはライトバッファ領域#1に格納される。ライトバッファ領域#2は書き込み先ブロック#2に関連付けられており、書き込み先ブロック#2に書き込むべき全てのデータはライトバッファ領域#2に格納される。ライトバッファ領域#3は書き込み先ブロック#3に関連付けられており、書き込み先ブロック#4に書き込むべき全てのデータはライトバッファ領域#3に格納される。同様に、ライトバッファ領域#nは書き込み先ブロック#nに関連付けられており、書き込み先ブロック#nに書き込むべき全てのデータはライトバッファ領域#nに格納される。
ホスト2は、エンドユーザ端末#1からのライトデータをライトバッファ領域#1に格納し、エンドユーザ端末#2からのライトデータをライトバッファ領域#2に格納し、エンドユーザ端末#3からのライトデータをライトバッファ領域#3に格納し、エンドユーザ端末#4からのライトデータをライトバッファ領域#4に格納し、そして、エンドユーザ端末#nからのライトデータをライトバッファ領域#nに格納する。
ホスト2は、書き込み先ブロック#1に関連付けられた識別子と、エンドユーザ端末#1からのライトデータが格納されているライトバッファ領域#1内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス3に送出する。書き込み先ブロック#1に関連付けられた識別子は、書き込み先ブロック#1を指定するブロック識別子(ブロックアドレス)であってもよいし、書き込み先ブロック#1に関連付けられストリームIDであってもよい。
フラッシュストレージデバイス3は、この記憶位置情報を含む転送要求をホスト2に送出することによって1物理ページのサイズに相当するライトデータ(例えば、TLC-フラッシュメモリの場合には3ページ分のライトデータ)をライトバッファ領域#1から取得する。なお、この転送要求は、記憶位置情報のみならず、書き込み先ブロック#1に関連付けられた識別子(例えば、書き込み先ブロック#1を指定するブロック識別子、または書き込み先ブロック#1に関連付けられストリームID)を含んでいてもよい。これにより、ホスト2は、フラッシュストレージデバイス3に転送すべきライトデータが格納されているライトバッファ領域とこのライトバッファ領域内の位置(記憶位置)とを容易に特定することができる。
ホスト2は、書き込み先ブロック#2に関連付けられた識別子(例えば、書き込み先ブロック#2を指定するブロック識別子、または書き込み先ブロック#2に関連付けられストリームID)と、エンドユーザ端末#2からのライトデータが格納されているライトバッファ領域#2内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス3に送出する。
フラッシュストレージデバイス3は、この記憶位置情報を含む転送要求をホスト2に送出することによって1物理ページのサイズに相当するライトデータ(例えば、TLC-フラッシュメモリの場合には3ページ分のライトデータ)をライトバッファ領域#2から取得する。なお、この転送要求は、記憶位置情報のみならず、書き込み先ブロック#2に関連付けられた識別子(例えば、書き込み先ブロック#2を指定するブロック識別子、または書き込み先ブロック#2に関連付けられストリームID)を含んでいてもよい。これにより、ホスト2は、フラッシュストレージデバイス3に転送すべきライトデータが格納されているライトバッファ領域とこのライトバッファ領域内の位置(記憶位置)とを容易に特定することができる。
同様に、ホスト2は、書き込み先ブロック#nに関連付けられた識別子(例えば、書き込み先ブロック#nを指定するブロック識別子、または書き込み先ブロック#nに関連付けられストリームID)と、エンドユーザ端末#nからのライトデータが格納されているライトバッファ領域#n内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス3に送出する。
フラッシュストレージデバイス3は、この記憶位置情報を含む転送要求をホスト2に送出することによって1物理ページのサイズに相当するライトデータ(例えば、TLC-フラッシュメモリの場合には3ページ分のライトデータ)をライトバッファ領域#nから取得する。なお、この転送要求は、記憶位置情報のみならず、書き込み先ブロック#nに関連付けられた識別子(例えば、書き込み先ブロック#nを指定するブロック識別子、または書き込み先ブロック#nに関連付けられストリームID)を含んでいてもよい。これにより、ホスト2は、フラッシュストレージデバイス3に転送すべきライトデータが格納されているライトバッファ領域とこのライトバッファ領域内の位置(記憶位置)とを容易に特定することができる。
図6は、フラッシュストレージデバイス3とホスト側UWB2Aとの関係とホスト2とフラッシュストレージデバイス3とによって実行されるデータ書き込み処理を示す。
ここでは、図示を簡単にするために、ある一つの書き込み先ブロックBLKに対するデータ書き込み処理を例示して説明する。また、ここでは、フル・シーケンス・プログラム動作によってライトデータを一つの書き込み先ブロックBLKに書き込む場合を想定する。
(1) ホスト2においては、フラッシュストレージデバイス3を管理するホストソフトウェアであるフラッシュストレージマネージャが実行される。フラッシュストレージマネージャは、フラッシュストレージデバイス3用のデバイスドライバ内に組み込まれていてもよい。フラッシュストレージマネージャは、UWB2Aを管理する。上位ソフトウェア(アプリケーションプログラムまたはファイルシステム)からのデータを書き込む要求に応じて、フラッシュストレージマネージャは、書き込むべきデータ、タグ、ブロック識別子を伴うライト要求をUWB2Aに格納する。タグは、このデータを識別可能な識別子である。タグは、論理ブロックアドレス(LBA)のような論理アドレスであってもよいし、キー・バリュー・ストアのキーであってもよいし、ファイル名のようなファイル識別子であってもよい。ブロック識別子は、書き込み先ブロックBLKのブロックアドレスであってもよい。なお、このライト要求は、書き込むべきデータの長さ(Length)を含んでもよいし、固定長のライトデータの書き込みを要求するケースにおいては、このライト要求は、長さ(Length)を含まなくてもよい。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。なお、上位ソフトウェアがこのライト要求を発行してもよく、そしてフラッシュストレージマネージャがこのライト要求を上位ソフトウェアから受信し、受信したライト要求をUWB2Aに格納してもよい。
(2) フラッシュストレージマネージャは、フラッシュストレージデバイス3にライト要求(ライトコマンド)を送出する。このライト要求は、タグ、ブロック識別子(ブロックアドレス)、バッファアドレス(またはバッファ内オフセット)を含む。バッファアドレスは、書き込むべきデータが格納されているUWB2A内の位置を示す。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。フラッシュストレージデバイス3のコントローラ4は、このライト要求を受信し、このライト要求に含まれるタグ、ブロック識別子、バッファアドレス(またはバッファ内オフセット)を保持する。
(3) フラッシュプログラミングコントローラ13がこのデータを書き込み先ブロックBLKに書き込む際に、フラッシュストレージデバイス3のコントローラ4は、転送要求(Transfer Request)をホスト2に送出する。この転送要求は、保持されているバッファアドレス(またはバッファ内オフセット)を含む。あるいは、この転送要求は、保持されているタグと、保持されているバッファアドレス(またはバッファ内オフセット)とを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス(またはバッファ内オフセット)と、保持されているブロック識別子(ブロックアドレス)を含んでいてもよい。
(4) ホスト2のフラッシュストレージマネージャは、少なくともバッファアドレス(またはバッファ内オフセット)を含む転送要求を受信すると、このバッファアドレス(またはバッファ内オフセット)によって指定されるUWB2A内の位置に格納されているデータをUWB2Aからフラッシュストレージデバイス3に転送する。例えば、NAND型フラッシュメモリ5がTLC-フラッシュメモリである場合には、3ページ分のデータがUWB2Aからフラッシュストレージデバイス3に転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。
(5) フラッシュストレージデバイス3のコントローラ4は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ13を介してNAND型フラッシュメモリ5に転送し、このデータを書き込み先ブロックBLKに書き込む。フル・シーケンス・プログラム動作によって3ページ分のデータをある物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ13は、3ページ分のデータをNAND型フラッシュメモリ5内のページバッファ群に順次転送し、そして書き込み指示をNAND型フラッシュメモリ5に送出する。フラッシュプログラミングコントローラ13は、NAND型フラッシュメモリ5からのステータスをモニタすることによって書き込み動作(フル・シーケンス・プログラム動作)が終了したかどうかを判定することができる。
(6) 書き込み動作が終了し且つこのデータ(ここでは3ページ分のデータ)の読み出しが可能になった場合、つまりフル・シーケンス・プログラム動作が成功で終了した場合、コントローラ4は、UWB2Aに保持されているこのデータ(ここでは3ページ分のデータ)が不要になったことをホスト2に通知する。この場合、フラッシュストレージデバイス3のコントローラ4は、タグ、ページアドレス、長さを含む書き込み完了(Write Done)をホスト2に送出してもよいし、無効化要求(invalidate
Request)をホスト2に送出してもよい。無効化要求は、読み出し可能になったデータが格納されているバッファアドレス(またはバッファ内オフセット)を含む。あるいは、無効化要求は、読み出し可能になったデータのタグと、読み出し可能になったデータが格納されているバッファアドレス(またはバッファ内オフセット)を含んでいてもよい。あるいは、この書き込み先ブロックBLKの最後の物理ページへのフル・シーケンス・プログラム動作が終了してこの書き込み先ブロックBLKの全体がデータで満たされた場合には、コントローラ4は、書き込み先ブロックBLKに対応するUWB領域が不要になったことをホスト2に通知する。この場合、コントローラ4は、クローズ要求(Close Request)をホスト2に送出する。クローズ要求は、書き込み先ブロックBLKのブロック識別子(ブロックアドレス)を含んでいてもよい。書き込み先ブロックBLKのブロック識別子を含むクローズ要求を受信した場合、ホスト2のフラッシュストレージマネージャは、この書き込み先ブロックBLKに関連づけられているUWB領域を解放し、このUWB領域を他の用途に使用する。この場合、フラッシュストレージマネージャは、この解放したUWB領域を、他の書き込み先ブロック(例えば新たにオープンされた書き込み先ブロック)用のUWB領域として再利用してもよい。
図7は、複数の書き込み先ブロックと複数のライトバッファ領域(UWB領域)との関係の例を示す。
ある書き込み先ブロックBLK#1に対応するライトバッファ領域(UWB領域#1)は、例えば、複数ページ分のデータを一時的に格納するための複数の記憶領域を含んでいてもよい。この場合、各記憶領域は、タグフィールド、バリッド/インバリッドフィールド、データ記憶フィールド、ページアドレスフィールドを含んでいてもよい。タグフィールドは、対応するデータのタグを格納する。バリッド/インバリッドフィールドは、対応するデータを保持することが必要であるか否かを示すバリッド/インバリッドフラグを保持する。データ記憶フィールドは、書き込み先ブロックBLK#1に書き込むべきデータを格納する。データ記憶フィールドは1ページ分のサイズを有していてもよい。ページアドレスフィールドはオプショナルなフィールドであり、ライト要求がページアドレスを含むならば、このページアドレスがページアドレスフィールドに格納される。
UWB領域#1に保持されているあるデータが不要になったことがフラッシュストレージデバイス3から通知された場合、ホスト2(フラッシュストレージマネージャ)は、このデータに対応する記憶領域内のバリッド/インバリッドフラグを無効を示す値に更新する。バリッド/インバリッドフラグを無効を示す値に更新された記憶領域は、書き込み先ブロックBLK#1に書き込むべき他のデータの格納に再利用される。
図7に示されるUWB領域のデータ構造は一例であり、例えば、ページサイズとは異なるサイズでデータ(ライトデータ)がUWB領域で管理されてもよい。
図8は、フラッシュストレージデバイス3とホスト側UWB2Aとの関係とホスト2とフラッシュストレージデバイス3とによって実行されるデータ読み出し処理を示す。
(1) 上位ソフトウェアからのデータをリードするための要求に応答して、ホスト2のフラッシュストレージマネージャは、このデータをリードするためのリード要求をフラッシュストレージデバイス3に送出する。このリード要求は、たとえば、タグ、ブロック識別子(ブロックアドレス)、ページアドレス、長さを含んでいてもよい。
(2) このリード要求で指定されたデータの書き込み先ブロックBLKへの書き込み動作が既に終了し且つこのデータが読み出し可能であるならば、フラッシュストレージデバイス3のコントローラ4は、フラッシュプログラミングコントローラ13を介してこのデータを書き込み先ブロックBLKからリードする。
(3) フラッシュストレージデバイス3のコントローラ4は、リードされたデータを、このデータのタグと一緒に、ホスト2に送出する。
(3’) このリード要求で指定されたデータが読み出し可能でないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間中にこのデータをリードするためのリード要求をホスト2から受信した場合、フラッシュストレージデバイス3のコントローラ4は、UWB2Aからこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト2に送出する。この転送要求は、転送すべきUWB2A内のデータを特定可能な情報として、このデータに対応するバッファアドレス、またはこのデータに対応するバッファアドレスとこのデータに対応するブロック識別子の双方を含んでいてもよい。あるいは、この転送要求は、このデータに対応するタグを含んでいてもよいし、このデータに対応するブロック識別子とページアドレスを含んでいてもよい。
(4’) ホスト2のフラッシュストレージマネージャは、このデータをUWB2Aからリードし、リードしたデータを、このデータのタグと一緒に、上位ソフトウェアに返す。
あるいは、ホスト2のフラッシュストレージマネージャは、UWB2Aに格納されているあるデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をフラッシュストレージデバイス3に送出せずに、このデータをUWB2Aから直接リードしてもよい。この場合、データリード処理は以下のように実行される。
(1”) UWB2Aに格納されているあるデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、ホスト2のフラッシュストレージマネージャは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をUWB2Aに送出してこのデータをUWB2Aからリードする。このリード要求は、例えば、タグ、バッファアドレス、長さを含んでいてもよい。
(2”) フラッシュストレージマネージャは、UWB2Aからリードされたデータを、このデータのタグと一緒に上位ソフトウェアに返す。
図9は、フォギー・ファイン書き込みをサポートするフラッシュストレージデバイス3とホスト側UWB2Aとの関係とホスト2とフラッシュストレージデバイス3とによって実行されるデータ書き込み処理を示す。
ここでは、複数段階の書き込み動作(フォギー・ファイン・プログラム動作)によってライトデータを一つの書き込み先ブロックBLKに書き込む場合を想定する。
(1) ホスト2においては、フラッシュストレージマネージャは、上位ソフトウェアからのデータを書き込む要求に応じて、書き込むべきデータ、タグ、ブロック識別子を伴うライト要求をUWB2Aに格納する。なお、このライト要求は、書き込むべきデータの長さ(Length)を含んでもよいし、固定長のライトデータの書き込みを要求するケースにおいては、このライト要求は、長さ(Length)を含まなくてもよい。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。なお、上位ソフトウェアがこのライト要求を発行してもよく、そしてフラッシュストレージマネージャがこのライト要求を上位ソフトウェアから受信し、受信したライト要求をUWB2Aに格納してもよい。
(2) フラッシュストレージマネージャは、フラッシュストレージデバイス3にライト要求(ライトコマンド)を送出する。このライト要求は、タグ、ブロック識別子(ブロックアドレス)、バッファアドレス(またはバッファ内オフセット)を含む。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。フラッシュストレージデバイス3のコントローラ4は、このライト要求を受信し、このライト要求に含まれるタグ、ブロック識別子、バッファアドレス(またはバッファ内オフセット)を保持する。
(3) フラッシュプログラミングコントローラ13がこのデータの一段階目の書き込み動作(フォギー書き込み)を開始する際に、フラッシュストレージデバイス3のコントローラ4は、転送要求(Transfer Request)をホスト2に送出する。この転送要求は、保持されているバッファアドレス(またはバッファ内オフセット)を含む。あるいは、この転送要求は、保持されているタグと、保持されているバッファアドレス(またはバッファ内オフセット)とを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス(またはバッファ内オフセット)と、保持されているブロック識別子(ブロックアドレス)を含んでいてもよい。
(4) ホスト2のフラッシュストレージマネージャは、少なくともバッファアドレス(またはバッファ内オフセット)を含む転送要求を受信すると、このバッファアドレス(またはバッファ内オフセット)によって指定されるUWB2A内の位置に格納されているデータ(ここでは、「Foggy Data」として図示されている)をUWB2Aからフラッシュストレージデバイス3に転送する。例えば、NAND型フラッシュメモリ5がTLC-フラッシュメモリである場合には、3ページ分のデータがUWB2Aからフラッシュストレージデバイス3にFoggy Dataとして転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。
(5) フラッシュストレージデバイス3のコントローラ4は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ13を介してNAND型フラッシュメモリ5に転送し、このデータを書き込み先ブロックBLKの書き込み先物理ページに書き込む(一段階目の書き込み:フォギー書き込み)。フォギー書き込みによって3ページ分のデータをある書き込み先物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ13は、3ページ分のデータをNAND型フラッシュメモリ5内のページバッファ群に順次転送し、そして一段階目の書き込み指示をNAND型フラッシュメモリ5に送出する。フラッシュプログラミングコントローラ13は、NAND型フラッシュメモリ5からのステータスをモニタすることによって書き込み動作(一段階目の書き込み動作)が終了したかどうかを判定することができる。通常、フォギー・ファイン・プログラム動作は、プログラムディスターブを削減するために、例えば、物理ページ#1のフォギー書き込み、物理ページ#2のフォギー書き込み、物理ページ#1のファイン書き込み、物理ページ#2のファイン書き込みのように、複数のワード線(複数の物理ページ)を往復しながら実行される。
(6) この書き込み先物理ページへの二段階目の書き込み(ファイン書き込み)を実行するタイミングが到来すると、フラッシュストレージデバイス3のコントローラ4は、ファイン書き込みで書き込まれるべきデータ(フォギー書き込みで書き込まれたデータと同じデータ)を取得するために、転送要求(Transfer Request)をホスト2に再び送出する。この転送要求は、上述の保持されているバッファアドレス、つまり、処理(3)で送出した転送要求に含まれていたバッファアドレスと同じバッファアドレスを含む。
(7) ホスト2のフラッシュストレージマネージャは、少なくともバッファアドレス(またはバッファ内オフセット)を含む転送要求を受信すると、このバッファアドレス(またはバッファ内オフセット)によって指定されるUWB2A内の位置に格納されているデータ(ここでは、「Fine Data」として図示されている)をUWB2Aからフラッシュストレージデバイス3に転送する。Fine Dataは、Foggy Dataと同じデータである。例えば、NAND型フラッシュメモリ5がTLC-フラッシュメモリである場合には、上述の3ページ分のデータがUWB2Aからフラッシュストレージデバイス3にFine Dataとして転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。なお、ホスト2は、転送すべきデータがFoggy DataまたはFine Dataのいずれであるかを認識する必要は無い。
(8) フラッシュストレージデバイス3のコントローラ4は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ13を介してNAND型フラッシュメモリ5に転送し、このデータを書き込み先ブロックBLKの上述の書き込み先物理ページに書き込む(二段階目の書き込み:ファイン書き込み)。ファイン書き込みによって3ページ分のデータをこの書き込み先物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ13は、フォギー書き込みで使用した3ページ分のデータと同じ3ページ分のデータをNAND型フラッシュメモリ5内のページバッファ群に順次転送し、そして二段階目の書き込み指示をNAND型フラッシュメモリ5に送出する。フラッシュプログラミングコントローラ13は、NAND型フラッシュメモリ5からのステータスをモニタすることによって書き込み動作(二段階目の書き込み動作)が終了したかどうかを判定することができる。
(9)二段階目の書き込み動作が終了し且つこのデータ(ここでは3ページ分のデータ)の読み出しが可能になった場合、つまりフォギー・ファイン・プログラム動作全てが成功で終了した場合、コントローラ4は、UWB2Aに保持されているこのデータ(ここでは3ページ分のデータ)が不要になったことをホスト2に通知する。この場合、フラッシュストレージデバイス3のコントローラ4は、タグ、ページアドレス、長さを含む書き込み完了(Write Done)をホスト2に送出してもよいし、無効化要求(invalidate Request)をホスト2に送出してもよい。無効化要求は、読み出し可能になったデータが格納されているバッファアドレス(またはバッファ内オフセット)を含む。あるいは、無効化要求は、読み出し可能になったデータのタグと、読み出し可能になったデータが格納されているバッファアドレス(またはバッファ内オフセット)を含んでいてもよい。あるいは、この書き込み先ブロックBLKの最後の物理ページへのフォギー・ファイン・プログラム動作が終了してこの書き込み先ブロックBLKの全体がデータで満たされた場合には、コントローラ4は、書き込み先ブロックBLKに対応するUWB領域が不要になったことをホスト2に通知する。この場合、コントローラ4は、クローズ要求(Close Request)をホスト2に送出する。クローズ要求は、書き込み先ブロックBLKのブロック識別子(ブロックアドレス)を含んでいてもよい。書き込み先ブロックBLKのブロック識別子を含むクローズ要求を受信した場合、ホスト2のフラッシュストレージマネージャは、この書き込み先ブロックBLKに関連づけられているUWB領域を解放し、このUWB領域を他の用途に使用する。この場合、フラッシュストレージマネージャは、この解放したUWB領域を、他の書き込み先ブロック(例えば新たにオープンされた書き込み先ブロック)用のUWB領域として再利用してもよい。
図10は、フォギー・ファイン書き込みをサポートするフラッシュストレージデバイス3とホスト側UWB2Aとの関係とホスト2とフラッシュストレージデバイス3とによって実行されるデータ読み出し処理を示す。
(1) 上位ソフトウェアからのデータをリードするための要求に応答して、ホスト2のフラッシュストレージマネージャは、このデータをリードするためのリード要求をフラッシュストレージデバイス3に送出する。このリード要求は、たとえば、タグ、ブロック識別子(ブロックアドレス)、ページアドレス、長さを含んでいてもよい。
(2) このリード要求で指定されたデータの書き込み先ブロックBLKへの書き込み動作が既に終了し且つこのデータが読み出し可能であるならば、つまりこのデータのフォギー書き込みとこのデータのファイン書き込みの双方が終了しているならば、フラッシュストレージデバイス3のコントローラ4は、フラッシュプログラミングコントローラ13を介してこのデータを書き込み先ブロックBLKからリードする。
(3) フラッシュストレージデバイス3のコントローラ4は、リードされたデータを、このデータのタグと一緒に、ホスト2に送出する。
(3’) このリード要求で指定されたデータが読み出し可能でないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間中にこのデータをリードするためのリード要求をホスト2から受信した場合、フラッシュストレージデバイス3のコントローラ4は、UWB2Aからこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト2に送出する。この転送要求は、このデータに対応するバッファアドレスを含んでいてもよい。
(4’) ホスト2のフラッシュストレージマネージャは、このデータをUWB2Aからリードし、リードしたデータを、このデータのタグと一緒に、上位ソフトウェアに返す。
あるいは、ホスト2のフラッシュストレージマネージャは、UWB2Aに格納されているあるデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をフラッシュストレージデバイス3に送出せずに、このデータをUWB2Aから直接リードしてもよい。この場合、データリード処理は以下のように実行される。
(1”) UWB2Aに格納されているあるデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、ホスト2のフラッシュストレージマネージャは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をUWB2Aに送出してこのデータをUWB2Aからリードする。このリード要求は、例えば、タグ、バッファアドレス、長さを含んでいてもよい。
(2”) フラッシュストレージマネージャは、UWB2Aからリードされたデータを、このデータのタグと一緒に上位ソフトウェアに返す。
図11のシーケンス図は、ホスト2とフラッシュストレージデバイス2とによって実行されるデータ書き込み処理の手順を示す。
ホスト2は、ある書き込み先ブロックに書き込むべきデータ(ライトデータ)をこの書き込み先ブロックに関連づけられたUWB領域に格納し、そしてブロック識別子とバッファアドレス(またはバッファ内オフセット)とを含むライト要求をフラッシュストレージデバイス3に送出する(ステップS11)。ブロック識別子は、このライトデータが書き込まれるべき書き込み先ブロックのブロックアドレスである。バッファアドレスは、このライトデータが格納されているUWB領域内の位置を示す。
フラッシュストレージデバイス3のコントローラ4は、このライト要求をホスト2から受信し、このライト要求内のブロック識別子とバッファアドレス(またはバッファ内オフセット)を保持する(ステップS21)。この場合、コントローラ4は、ブロック識別子とバッファアドレスをDRAM6上のライトバッファ31に格納することによってこれらブロック識別子とバッファアドレスを保持してもよい。
保持しているブロック識別子によって指定される書き込み先ブロックにこのライト要求に対応するライトデータを書き込む際、フラッシュストレージデバイス3のコントローラ4は、保持しているバッファアドレス(またはバッファ内オフセット)を含む転送要求をホスト2に送出する(ステップS22)。
ホスト2がこの転送要求を受信すると、ホスト2は、このライトデータをUWB領域からフラッシュストレージデバイス3に転送する(ステップS12)。
フラッシュストレージデバイス3のコントローラ4は、ホスト2から転送されるこのライトデータを受信する(ステップS23)。コントローラ4は、受信したライトデータを例えばDRAM6上のライトバッファ31等に格納することによって保持する(ステップS24)。
コントローラ4は、受信したライトデータをNAND型フラッシュメモリ5に転送する(ステップS25)。NAND型フラッシュメモリ5へのライトデータの転送が完了するまで、コントローラ4は、このライトデータを保持する。そして、コントローラ4は、このライトデータを、保持しているブロック識別子によって指定される書き込み先ブロックに書き込む(ステップS26)。この場合、ライトデータが書き込まれるべき書き込み先ブロック内の書き込み先ページはコントローラ4によって決定される。なお、ライト要求が書き込み先ページを指定するページアドレスを含んでいてもよい。
このライトデータの書き込み動作が終了し且つこのライトデータが読み出し可能になった場合(フル・シーケンス・プログラム動作においてはフル・シーケンス・プログラム動作が終了した場合)、コントローラ4は、UWB領域に格納されているこのライトデータが不要になったことをホスト2に通知する(ステップS27)。
図12のフローチャートは、フラッシュストレージデバイス3によって実行される通知処理の手順を示す。
フラッシュストレージデバイス3のコントローラ4は、書き込み先ブロックへのデータの書き込み動作が終了し且つこのデータが読み出し可能になったか否かを判定する(ステップS31)。
データの書き込み動作が終了し且つこのデータが読み出し可能になったならば(ステップS31のYES)、コントローラ4は、この書き込み先ブロックの最後のページ(最後の物理ページ)への書き込み動作が終了してこの書き込み先ブロックの全体がデータで満たされたか否かを判定する(ステップS32)。
この書き込み先ブロックに利用可能な物理ページ(未書き込みの物理ページ)が残っているならば(ステップS32のNO)、コントローラ4は、UWB領域に保持されている読み出し可能になったデータが不要になったことをホスト2に通知するために、書き込み完了(Write Done)または無効化要求(invalidate Request)をホスト2に送出する(ステップS33)。
この書き込み先ブロックの最後のページ(最後の物理ページ)への書き込み動作が終了してこの書き込み先ブロックの全体がデータで満たされたならば(ステップS32のYES)、コントローラ4は、この書き込み先ブロックに対応するUWB領域全体が不要になったことをホスト2に通知するために、クローズ要求(Close Request)をホスト2に送出する(ステップS34)。
図13のフローチャートは、転送要求の受信に応じて実行されるホスト側処理の手順を示す。
ホスト2は、ブロック識別子とバッファアドレス(またはバッファ内オフセット)とを含むライト要求をフラッシュストレージデバイス3に送出する(ステップS40)。ホスト2は、フラッシュストレージデバイス3から転送要求が受信された否かを判定する(ステップS41)。
フラッシュストレージデバイス3から転送要求が受信されたならば(ステップS41のYES)、ホスト2は、転送要求内のバッファアドレス(またはバッファ内オフセット)によって指定されるUWB領域内の位置に格納されているデータをフラッシュストレージデバイス3に転送する(ステップS42)。そして、ホスト2は、UWB領域内の不要データがフラッシュストレージデバイス3から通知されたか否か、またはクローズ要求(Close Request)がフラッシュストレージデバイス3から受信されたか否かを判定する(ステップS43、S44)。
UWB領域内の不要データがフラッシュストレージデバイス3から通知されたならば(ステップS43のYES)、ホスト2は、この不要データに対応するバリッド/インバリッドフラグを無効を示す値に更新して、この不要データが格納されているUWB領域内の一つの記憶領域を解放する(ステップS44)。ホスト2は、この解放された記憶領域を、このUWB領域に対応する書き込み先ブロックに書き込むべき新たなライトデータのための記憶領域として再利用することができる。
このように、本実施形態では、あるデータの書き込み動作が終了してこのデータが読み出し可能になると、UWB領域内のこのデータが不要になったことがフラッシュストレージデバイス3からホスト2に通知される。したがって、このデータがNAND型フラッシュメモリ5から読み出し可能になるまでは、このデータはUWB領域内に保持される。
クローズ要求(Close Request)がフラッシュストレージデバイス3から受信されたならば(ステップS45のYES)、ホスト2は、クローズ要求に含まれるブロック識別子の書き込み先ブロックに関連付けられたUWB領域全体を解放する(ステップS46)。ホスト2は、この解放されたUWB領域を、フラッシュストレージデバイス3によって新たに割り当てられた書き込み先ブロック用のUWB領域として再利用することができる。
図14のフローチャートは、リード要求の受信に応じてフラッシュストレージデバイス3によって実行されるデータ読み出し動作の手順を示す。
フラッシュストレージデバイス3のコントローラ4は、リード要求をホスト2から受信する(ステップS51)。コントローラ4は、リード要求によって指定されたリードすべきデータが、書き込み先ブロックへの書き込み動作が終了し且つ読み出し可能なデータであるか否かを判定する(ステップS52)。
リードすべきデータが、書き込み先ブロックへの書き込み動作が終了し且つ読み出し可能なデータであるならば(ステップS52のYES)、コントローラ4は、リードすべきデータをNAND型フラッシュメモリ5からリードし(ステップS53)、このリードしたデータをホスト2に返す(ステップS54)。
一方、リードすべきデータが、書き込み先ブロックへの書き込み動作が終了し且つ読み出し可能なデータではないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間内にこのデータに対するリード要求がホスト2から受信されたならば(ステップS52のNO)、コントローラ4は、UWB領域からこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト2に送出する(ステップS55)。
図15のフローチャートは、データ読み出しのためのホスト側処理の手順を示す。
ホスト2は、リードすべきデータがUWB領域内に存在するか否かにかかわらず、このデータのリードを要求するリード要求をフラッシュストレージデバイス3に送出する(ステップS61)。
そして、ホスト2は、UWB領域からこのデータを返す(リードする)ように要求する転送要求がフラッシュストレージデバイス3から受信されたか否かを判定する(ステップS62)。
この転送要求がフラッシュストレージデバイス3から受信されたならば(ステップS62のYES)、ホスト2は、このデータをUWB領域からリードする(ステップS63)。
図16は、ストリーム書き込みをサポートするフラッシュストレージデバイス3とホスト側UWB2Aとの関係とホスト2とフラッシュストレージデバイス3とによって実行されるデータ書き込み処理を示す。
ここでは、フル・シーケンス・プログラム動作によってライトデータを一つの書き込み先ブロックBLKに書き込む場合を想定する。
(1) ホスト2においては、上位ソフトウェア(アプリケーションプログラムまたはファイルシステム)からのデータを書き込む要求に応じて、フラッシュストレージマネージャは、書き込むべきデータ、ストリームID、LBA、長さを伴うライト要求をUWB2Aに格納する。ストリームIDは、複数の書き込み先ブロックに関連付けられている複数のストリーム内のあるストリームの識別子である。なお、上位ソフトウェアがこのライト要求を発行してもよく、そしてフラッシュストレージマネージャがこのライト要求を上位ソフトウェアから受信し、受信したライト要求をUWB2Aに格納してもよい。
(2) フラッシュストレージマネージャは、フラッシュストレージデバイス3にライト要求(ライトコマンド)を送出する。このライト要求は、ストリームID、LBA、長さ、バッファアドレス(またはバッファ内オフセット)を含む。バッファアドレスは、書き込むべきデータが格納されているUWB2A内の位置を示す。フラッシュストレージデバイス3のコントローラ4は、このライト要求を受信し、このライト要求に含まれるストリームID、LBA、長さ、バッファアドレスを保持する。
(3) フラッシュプログラミングコントローラ13がこのデータを書き込み先ブロックBLKに書き込む際に、フラッシュストレージデバイス3のコントローラ4は、転送要求(Transfer Request)をホスト2に送出する。この転送要求は、保持されているバッファアドレス(またはバッファ内オフセット)を含む。あるいは、この転送要求は、保持されているLBAと、保持されているバッファアドレス(またはバッファ内オフセット)とを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス(またはバッファ内オフセット)と、保持されているストリームIDを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス(またはバッファ内オフセット)と、保持されているストリームIDに関連付けられている書き込み先ブロックのブロック識別子(ブロックアドレス)を含んでもよい。
(4) ホスト2のフラッシュストレージマネージャは、少なくともバッファアドレス(またはバッファ内オフセット)を含む転送要求を受信すると、このバッファアドレス(またはバッファ内オフセット)によって指定されるUWB2A内の位置に格納されているデータをUWB2Aからフラッシュストレージデバイス3に転送する。例えば、NAND型フラッシュメモリ5がTLC-フラッシュメモリである場合には、3ページ分のデータがUWB2Aからフラッシュストレージデバイス3に転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。
(5) フラッシュストレージデバイス3のコントローラ4は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ13を介してNAND型フラッシュメモリ5に転送し、このデータを書き込み先ブロックBLKに書き込む。フル・シーケンス・プログラム動作によって3ページ分のデータをある物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ13は、3ページ分のデータをNAND型フラッシュメモリ5内のページバッファ群に順次転送し、そして書き込み指示をNAND型フラッシュメモリ5に送出する。フラッシュプログラミングコントローラ13は、NAND型フラッシュメモリ5からのステータスをモニタすることによって書き込み動作(フル・シーケンス・プログラム動作)が終了したかどうかを判定することができる。
(6) 書き込み動作が終了し且つこのデータ(ここでは3ページ分のデータ)の読み出しが可能になった場合、つまりフル・シーケンス・プログラム動作が成功で終了した場合、コントローラ4は、UWB2Aに保持されているこのデータ(ここでは3ページ分のデータ)が不要になったことをホスト2に通知する。この場合、フラッシュストレージデバイス3のコントローラ4は、LBA、長さを含む書き込み完了(Write Done)をホスト2に送出してもよいし、無効化要求(invalidate Request)をホスト2に送出してもよい。無効化要求は、読み出し可能になったデータが格納されているバッファアドレス(またはバッファ内オフセット)を含む。あるいは、無効化要求は、読み出し可能になったデータのLBAと、読み出し可能になったデータが格納されているバッファアドレス(またはバッファ内オフセット)を含んでいてもよい。あるいは、この書き込み先ブロックBLKの最後の物理ページへのフル・シーケンス・プログラム動作が終了してこの書き込み先ブロックBLKの全体がデータで満たされた場合には、コントローラ4は、書き込み先ブロックBLKに対応するUWB領域が不要になったことをホスト2に通知する。この場合、コントローラ4は、クローズ要求(Close Request)をホスト2に送出する。クローズ要求は、書き込み先ブロックBLKのブロック識別子(ブロックアドレス)を含んでいてもよい。書き込み先ブロックBLKのブロック識別子を含むクローズ要求を受信した場合、ホスト2のフラッシュストレージマネージャは、この書き込み先ブロックBLKに関連づけられているUWB領域を解放し、このUWB領域を他の用途に使用する。この場合、フラッシュストレージマネージャは、この解放したUWB領域を、他の書き込み先ブロック(例えば新たにオープンされた書き込み先ブロック)用のUWB領域として再利用してもよい。
図17は、複数のストリームIDとこれらストリームIDに関連付けられた複数の書き込み先ブロックとの関係を示す。
ここでは、ストリームID#1のストリームに書き込み先フロックBLK#1が関連付けられており、ストリームID#2のストリームに書き込み先フロックBLK#2が関連付けられており、ストリームID#3のストリームに書き込み先フロックBLK#3が関連付けられており、そしてストリームID#nのストリームに書き込み先フロックBLK#nが関連付けられている場合が例示されている。
ストリームID#1を含むライト要求によって指定されるライトデータは、書き込み先フロックBLK#1に書き込まれる。ストリームID#2を含むライト要求によって指定されるライトデータは、書き込み先フロックBLK#2に書き込まれる。ストリームID#3を含むライト要求によって指定されるライトデータは、書き込み先フロックBLK#3に書き込まれる。ストリームID#nを含むライト要求によって指定されるライトデータは、書き込み先フロックBLK#nに書き込まれる。
図18は、ストリーム書き込みをサポートするフラッシュストレージデバイス3とホスト側UWB2Aとの関係とホスト2とフラッシュストレージデバイス3とによって実行されるデータ読み出し処理を示す。
(1) 上位ソフトウェアからのデータをリードするための要求に応答して、ホスト2のフラッシュストレージマネージャは、このデータをリードするためのリード要求をフラッシュストレージデバイス3に送出する。このリード要求は、たとえば、LBA、長さを含んでいてもよい。
(2) このリード要求で指定されたデータの書き込み先ブロックBLKへの書き込み動作が既に終了し且つこのデータが読み出し可能であるならば、フラッシュストレージデバイス3のコントローラ4は、フラッシュプログラミングコントローラ13を介してこのデータを書き込み先ブロックBLKからリードする。
(3) フラッシュストレージデバイス3のコントローラ4は、リードされたデータを、このデータのLBAと一緒に、ホスト2に送出する。
(3’) このリード要求で指定されたデータが読み出し可能でないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間中にこのデータをリードするためのリード要求をホスト2から受信した場合、フラッシュストレージデバイス3のコントローラ4は、UWB2Aからこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト2に送出する。この転送要求は、このデータに対応するバッファアドレスを含んでいてもよい。
(4’) ホスト2のフラッシュストレージマネージャは、このデータをUWB2Aからリードし、リードしたデータを、このデータのLBAと一緒に、上位ソフトウェアに返す。
あるいは、ホスト2のフラッシュストレージマネージャは、UWB2Aに格納されているあるデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をフラッシュストレージデバイス3に送出せずに、このデータをUWB2Aから直接リードしてもよい。この場合、データリード処理は以下のように実行される。
(1”) UWB2Aに格納されているあるデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、ホスト2のフラッシュストレージマネージャは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をUWB2Aに送出してこのデータをUWB2Aからリードする。このリード要求は、例えば、LBA、長さを含んでいてもよい。
(2”) フラッシュストレージマネージャは、UWB2Aからリードされたデータを、このデータのLBAと一緒に上位ソフトウェアに返す。
図19のシーケンス図は、フォギー・ファイン書き込みをサポートするフラッシュストレージデバイス3とホスト2とによって実行されるデータ書き込み処理の手順を示す。
ここでは、ライト要求がブロック識別子とバッファアドレス(またはバッファ内オフセット)を含む場合を例示して説明する。
ホスト2は、ある書き込み先ブロックに書き込むべきデータ(ライトデータ)をこの書き込み先ブロックに関連づけられたUWB領域に格納し、そしてブロック識別子とバッファアドレス(またはバッファ内オフセット)とを含むライト要求をフラッシュストレージデバイス3に送出する(ステップS71)。ブロック識別子は、このライトデータが書き込まれるべき書き込み先ブロックのブロックアドレスである。バッファアドレスは、このライトデータが格納されているUWB領域内の位置を示す。
フラッシュストレージデバイス3のコントローラ4は、このライト要求をホスト2から受信し、このライト要求内のブロック識別子とバッファアドレス(またはバッファ内オフセット)を保持する(ステップS81)。この場合、コントローラ4は、ブロック識別子とバッファアドレスをDRAM6上のライトバッファ31に格納することによってこれらブロック識別子とバッファアドレスを保持してもよい。
保持しているブロック識別子によって指定される書き込み先ブロックにこのライト要求に対応するライトデータを複数段階のプログラム動作(フォギー・ファイン・プログラム動作)で書き込む際、フラッシュストレージデバイス3のコントローラ4は、まず、フォギー書き込みのために使用されるライトデータ(フォギーデータ)をUWB領域から取得するために、保持しているバッファアドレス(またはバッファ内オフセット)を含む転送要求をホスト2に送出する(ステップS82)。
ホスト2がこの転送要求を受信すると、ホスト2は、このライトデータをUWB領域からフラッシュストレージデバイス3に転送する(ステップS72)。
フラッシュストレージデバイス3のコントローラ4は、ホスト2から転送されるこのライトデータをフォギーデータとして受信する(ステップS83)。コントローラ4は、受信したライトデータ(フォギーデータ)を例えばDRAM6上のライトバッファ31等に格納することによって保持する(ステップS84)。
コントローラ4は、受信したライトデータ(フォギーデータ)をNAND型フラッシュメモリ5に転送する(ステップS85)。NAND型フラッシュメモリ5へのライトデータ(フォギーデータ)の転送が完了するまで、コントローラ4は、このライトデータ(フォギーデータ)を保持する。そして、コントローラ4は、このライトデータ(フォギーデータ)を、保持しているブロック識別子によって指定される書き込み先ブロックの書き込み先物理ページに書き込む(一段階目の書き込み:フォギー書き込み)(ステップS86)。
この後、この書き込み先物理ページへの二段階目の書き込み(ファイン書き込み)を実行するタイミングが到来すると、フラッシュストレージデバイス3のコントローラ4は、ファイン書き込みのために使用されるライトデータ(ファインデータ)をUWB領域から取得するために、保持しているバッファアドレス(またはバッファ内オフセット)を含む転送要求をホスト2に再び送出する(ステップS87)。ファインデータは、フォギーデータと同じデータである。
ホスト2がこの転送要求を受信すると、ホスト2は、このライトデータをUWB領域からフラッシュストレージデバイス3に転送する(ステップS73)。
フラッシュストレージデバイス3のコントローラ4は、ホスト2から転送されるこのライトデータをファインデータとして受信する(ステップS88)。コントローラ4は、受信したライトデータ(ファインデータ)を例えばDRAM6上のライトバッファ31等に格納することによって保持する(ステップS89)。
コントローラ4は、受信したライトデータ(ファインデータ)をNAND型フラッシュメモリ5に転送する(ステップS90)。NAND型フラッシュメモリ5へのライトデータ(ファインデータ)の転送が完了するまで、コントローラ4は、このライトデータ(ファインデータ)を保持する。そして、コントローラ4は、このライトデータ(ファインデータ)を、この書き込み先ブロックのこの書き込み先物理ページに書き込む(二段階目の書き込み:ファイン書き込み)(ステップS91)。
書き込み動作が終了し且つこのライトデータが読み出し可能になった場合(つまり、フォギー書き込み動作とファイン書き込み動作の双方が終了した場合)、コントローラ4は、UWB領域に格納されているこのライトデータが不要になったことをホスト2に通知する(ステップS92)。
図20は、ホスト2(情報処理装置)の構成例を示す。
このホスト2は、プロセッサ(CPU)101、メインメモリ102、BIOS-ROM103、ネットワークコントローラ105、周辺インタフェースコントローラ106、コントローラ107、およびエンベデッドコントローラ(EC)108等を含む。
プロセッサ101は、この情報処理装置内の各コンポーネントの動作を制御するように構成されたCPUである。このプロセッサ101は、メインメモリ102上の様々なプログラムを実行する。メインメモリ102は、DRAMのようなランダムアクセスメモリから構成される。プロセッサ101によって実行されるプログラムは、アプリケーションソフトウェアレイヤ41、オペレーティングシステム(OS)42、ファイルシステム43、デバイスドライバ44、等を含む。
様々なアプリケーションプログラムがアプリケーションソフトウェアレイヤ41上で走る。一般に知られているように、OS42は、この情報処理装置全体を管理し、この情報処理装置内のハードウェアを制御し、ソフトウェアがハードウェアおよびフラッシュストレージデバイス3を使用することを可能にするための制御を実行するように構成されたソフトウェアである。ファイルシステム43は、ファイルの操作(クリエイト、保存、更新、削除等)のための制御を行うために使用される。
デバイスドライバ44は、フラッシュストレージデバイス3を制御および管理するためのプログラムである。このデバイスドライバ44は、上述のフラッシュストレージマネージャを含む。このフラッシュストレージマネージャ45は、メインメモリ102上のUWB2Aを管理するための命令群、フラッシュストレージデバイス3にライト要求、リード要求等を送出するための命令群、フラッシュストレージデバイス3から転送要求を受信する度にUWB2Aからフラッシュストレージデバイス3にデータを転送するための命令群、UWB2Aに格納されているあるデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、このデータをUWB2Aからリードするための命令群、等を含む。プロセッサ101は、デバイスドライバ44内のフラッシュストレージマネージャ45の命令群を実行することによって、データ書き込み処理、データ読み出し処理、UWB領域解放処理、等を実行する。
ネットワークコントローラ105は、ethernetコントローラのような通信デバイスである。周辺インタフェースコントローラ106は、USBデバイスのような周辺デバイスとの通信を実行するように構成されている。
コントローラ107は、複数のコネクタ107Aにそれぞれ接続されるデバイスとの通信を実行するように構成されている。本実施形態では、複数のフラッシュストレージデバイス3が複数のコネクタ107Aにそれぞれ接続されてもよい。コントローラ107は、SAS expander、PCIe Switch、PCIe expander、フラッシュアレイコントローラ、またはRAIDコントローラでもよい。あるいは、複数のフラッシュストレージデバイス3は、ethernetを介してネットワークコントローラ105に接続されてもよい。
図21のフローチャートは、プロセッサ101によって実行されるデータ書き込み処理の手順を示す。
データ書き込み処理においては、プロセッサ101は、一つの書き込み先ブロックに書き込むべきライトデータをUWB2A(この書き込み先ブロックに対応するUWB領域)に格納する(ステップS101)。プロセッサ101は、この書き込み先ブロックに関連付けられた識別子と、ライトデータが格納されているUWB2A内の位置(UWB領域無いとの位置)を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス3に送出する(ステップS102)。書き込み先ブロックに関連付けられた識別子は、上述したように、書き込み先ブロックのブロック識別子(ブロックアドレス)であってもよい。記憶位置情報は、上述したように、バッファアドレス(またはバッファ内オフセット)であってもよい。この場合、プロセッサ101は、タグ、ブロック識別子、バッファアドレス(またはバッファ内オフセット)を含むライト要求をフラッシュストレージデバイス3に送出してもよい。また、ホスト2がブロックのみならず、ページも指定する構成においては、ライト要求は、タグ、ブロック識別子(ブロックアドレス)、ページアドレス、バッファアドレス(またはバッファ内オフセット)を含んでもよい。
あるいは、ストリーム書き込みを使用するケースにおいては、ブロック識別子(ブロックアドレス)の代わりに、ストリームIDが利用されてもよい。この場合、ライト要求は、ストリームID、LBA、バッファアドレス(またはバッファ内オフセット)を含んでもよい。
プロセッサ101がライト要求をフラッシュストレージデバイス3に送出した後、プロセッサ101は、バッファアドレス(またはバッファ内オフセット)を含む転送要求をフラッシュストレージデバイス3から受信する度に、上述のライトデータをUWB2A(UWB領域)からフラッシュストレージデバイス3に転送する(ステップS103、S104)。より詳しくは、プロセッサ101は、バッファアドレス(またはバッファ内オフセット)を含む転送要求がフラッシュストレージデバイス3から受信されたか否かを判定する(ステップS103)。そして、この転送要求がフラッシュストレージデバイス3から受信されたならば(ステップS103のYES)、プロセッサ101は、上述のライトデータをUWB2A(UWB領域)からフラッシュストレージデバイス3に転送する。
上述したように、複数段階のプログラム動作(フォギー・ファイン・プログラム動作)でライトデータが書き込み先ブロックに書き込まれるケースにおいては、プロセッサ101は、同じバッファアドレス(または同じバッファ内オフセット)を含む転送要求をフラッシュストレージデバイス3から複数回受信する。そして、この転送要求を受信する度に、プロセッサ101は、上述のライトデータをUWB2A(UWB領域)からフラッシュストレージデバイス3に転送する。
図22のフローチャートは、プロセッサ101によって実行されるデータ読み出し処理の手順を示す。
UWB2A(UWB領域)に格納されているデータが不要になったことがフラッシュストレージデバイス3から通知されるまでは、プロセッサ101は、上位ソフトウェアからのこのデータをリードするための要求に応答してこのデータをUWB2A(UWB領域)からリードし、このリードしたデータを上位ソフトウェアに返す。
すなわち、上位ソフトウェアからデータのリードが要求されたならば(ステップS111のYES)、プロセッサ101は、UWB2A(UWB領域)上のこのデータが不要になったことがフラッシュストレージデバイス3から既に通知されているか否かを判定する(ステップS112)。
このデータが不要になったことがまだ通知されていないならば(ステップS112のNO)、プロセッサ101は、このデータをUWB2A(UWB領域)からリードし、リードしたデータを上位ソフトウェアに返す(ステップS112)。
一方、このデータが不要になったことが既に通知されているならば(ステップS112のYES)、プロセッサ101は、このデータをリードするためのリード要求をフラッシュストレージデバイス3に送出し、これによってこのデータをフラッシュストレージデバイス3からリードする(ステップS114)。
図23のフローチャートは、プロセッサ101によって実行されるデータ読み出し処理の別の手順を示す。
上位ソフトウェアからデータをリードするための要求が受信されたならば(ステップS121のYES)、プロセッサ101は、このデータがUWB2A(UWB領域)に存在するか否かにかかわらず、つまりこのデータが不要になったことが既にフラッシュストレージデバイス3から通知されているか否かにかかわらず、このデータをリードするためのリード要求をフラッシュストレージデバイス3に送出する(ステップS122)。
フラッシュストレージデバイス3は、このリード要求によって指定されたデータがまだ読み出し可能になっていないならば、このデータをUWB2A(UWB領域)から返すように要求する転送要求をホスト2に送出する。
この転送要求がフラッシュストレージデバイス3から受信されたならば(ステップS123のYES)、プロセッサ101は、このデータをUWB2A(UWB領域)からリードし、このリードしたデータを上位ソフトウェアに返す(ステップS124)。
この転送要求がフラッシュストレージデバイス3から受信されなかったならば(ステップS123のNO)、プロセッサ101は、リード要求に対する応答としてフラッシュストレージデバイス3から返されるデータを受信し、このデータを上位ソフトウェアに返す(ステップS125)。
図24のフローチャートは、プロセッサ101によって実行されるUWB領域解放処理の手順を示す。
一つの書き込み先ブロックに関連付けられたUWB領域全体が不要になったことを示す通知(クローズ要求)をプロセッサ101がフラッシュストレージデバイス3から受信した場合(ステップS131のYES)、プロセッサ101は、このUWB領域全体を解放する(ステップS132)。ステップS132では、プロセッサ101は、この解放したUWB領域に対応するメモリスペースを他の任意の用途に使用することができる。例えば、プロセッサは、フラッシュストレージデバイス3のコントローラ4によって新たに割り当てられた書き込み先ブロックに関連付けられたUWB領域としてこの解放したUWB領域を再利用してもよい。この新たに割り当てられた書き込み先ブロックにデータを書き込むことが必要な時、プロセッサ101は、まず、この新たに割り当てられた書き込み先ブロックに関連付けられたUWB領域にこのデータを格納し、そして、この新たに割り当てられた書き込み先ブロックに関連付けられた識別子(ブロック識別子、またはストリームID)と、このデータが格納されているこのUWB領域内の位置を示す記憶位置情報(例えばバッファアドレス)とを含むライト要求をフラッシュストレージデバイス3に送出する。
以上説明したように、本実施形態によれば、フラッシュストレージデバイス3のコントローラ4は、一つの書き込み先ブロックに関連付けられた第1の識別子(ブロック識別子、またはストリームID)と、書き込むべき第1のデータが格納されているホスト2のメモリ上のライトバッファ(UWB2A)内の位置を示す記憶位置情報(バッファアドレス、またはバッファ内アドレス)とを含むライト要求をホスト2から受信する。そして、第1のデータをNAND型フラッシュメモリ5に書き込む際に、コントローラ4は、記憶位置情報を含む転送要求をホスト2に送出することによって第1のデータをライトバッファ(UWB2A)から取得する。したがって、書き込み動作のために必要なデータをホスト2のライトバッファ(UWB2A)から取得できるので、フラッシュストレージデバイス3に多数のライトバッファを用意することなく、同時に利用可能な書き込み先ブロックの数を増やすことができる。よって、フラッシュストレージデバイス3のコストアップを招くことなく、フラッシュストレージデバイス3を共有するエンドユーザの数を容易に増やすことが可能となる。
また、コントローラ4は、第1のデータの書き込みが終了し且つ第1のデータがNAND型フラッシュメモリ5から読み出し可能になった場合、ライトバッファ(UWB2A)に保持されている第1のデータが不要になったことをホスト2に通知する。この通知に応じて、ホスト2は、必要に応じてこのデータを破棄することができる。したがって、書き込むべきデータがNAND型フラッシュメモリ5から読み出し可能になるまでは、コントローラ4は、必要に応じて、このデータをライトバッファ(UWB2A)から繰り返し取得することもできる。したがって、フォギー・ファイン・プログラム動作のような複数段階のプログラム動作を実行する場合であっても、コントローラ4は、各段階のプログラム動作の開始の度に、必要なデータをライトバッファ(UWB2A)から取得することができる。
なお、本実施形態では、不揮発性メモリとしてNAND型フラッシュメモリを例示した。しかし、本実施形態の機能は、例えば、MRAM(Magnetoresistive
Random Access Memory)、PRAM(Phase change
Random Access Memory)、ReRAM(Resistive Random Access Memory)、又は、FeRAM(Ferroelectric Random Access Memory)のような他の様々な不揮発性メモリにも適用できる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
2…ホスト、2A…ライトバッファ、3…フラッシュストレージデバイス、4…コントローラ、5…NAND型フラッシュメモリ、21…ブロック識別子/バッファアドレス受信部、22…転送要求送信部、23…通知部。

Claims (16)

  1. ホストに接続可能なメモリシステムであって、
    複数のブロックを含む不揮発性メモリと、
    前記不揮発性メモリに電気的に接続され、前記不揮発性メモリを制御するように構成されたコントローラとを具備し、
    前記コントローラは、
    書き込むべき第1のデータが格納されている前記ホストのメモリ上のライトバッファ内の位置を示す記憶位置情報を含むライト要求を前記ホストから受信し、
    前記第1のデータを、複数段階のプログラム動作によって前記不揮発性メモリに書き込む際に、
    前記複数段階のプログラム動作の各プログラム動作の度に、
    前記記憶位置情報を含む転送要求を前記ホストに送信することによって前記第1のデータを前記ライトバッファから取得し、
    前記第1のデータを前記不揮発性メモリに転送し、
    前記第1のデータを前記複数のブロックのうちの一つの書き込み先ブロックに書き込む、ように構成されるメモリシステム。
  2. 前記コントローラは、前記第1のデータの書き込み開始から前記第1のデータが読み出し可能になるまでの期間中に前記第1のデータをリードするためのリード要求を前記ホストから受信した場合、前記ライトバッファから前記第1のデータを取得するように要求する取得要求を、前記ホストに送信するように構成されている請求項1記載のメモリシステム。
  3. 前記ライトバッファは前記複数のブロックに対応する複数のライトバッファ領域を含み、
    前記コントローラは、前記一つの書き込み先ブロックの全体がデータで満たされた場合、前記一つの書き込み先ブロックに対応する前記ライトバッファ内のライトバッファ領域が不要になったことを前記ホストに通知するように構成されている請求項1記載のメモリシステム。
  4. 前記メモリシステムは前記ホストにEthernet(登録商標)を介して接続される請求項1記載のメモリシステム。
  5. 前記ライト要求は、書き込み先ブロックを指定するブロック識別子を含む請求項1記載のメモリシステム。
  6. 前記複数のブロックは複数のストリームにそれぞれ関連付けられており、
    前記ライト要求は、前記複数のストリーム内の一つのストリームの識別子を含む請求項1記載のメモリシステム。
  7. 前記ライトバッファは前記複数のブロックに対応する複数のライトバッファ領域を含み、
    前記転送要求は前記一つの書き込み先ブロックの識別子と前記記憶位置情報とを含む請求項1記載のメモリシステム。
  8. 前記コントローラは、前記複数段階のプログラム動作が終了し且つ前記第1のデータが前記不揮発性メモリから読み出し可能になった場合、前記ライトバッファに格納されている前記第1のデータが不要になったことを前記ホストに通知するように構成される請求項1記載のメモリシステム。
  9. 複数のブロックを含む不揮発性メモリを制御する制御方法であって、
    書き込むべき第1のデータが格納されているホストのメモリ上のライトバッファ内の位置を示す記憶位置情報を含むライト要求を前記ホストから受信することと、
    前記第1のデータを、複数段階のプログラム動作によって前記不揮発性メモリに書き込む際に、
    前記複数段階のプログラム動作の各プログラム動作の度に、
    前記記憶位置情報を含む転送要求を前記ホストに送信することによって前記第1のデータを前記ライトバッファから取得し、
    前記第1のデータを前記不揮発性メモリに転送し、
    前記第1のデータを前記複数のブロックのうちの一つの書き込み先ブロックに書き込むこととを具備する制御方法。
  10. 前記第1のデータの書き込み開始から前記第1のデータが読み出し可能になるまでの期間中に前記第1のデータをリードするためのリード要求を前記ホストから受信した場合、前記ライトバッファから前記第1のデータを取得するように要求する取得要求を、前記ホストに送信することをさらに具備する請求項9記載の制御方法。
  11. 前記ライトバッファは前記複数のブロックに対応する複数のライトバッファ領域を含み、
    前記一つの書き込み先ブロックの全体がデータで満たされた場合、前記一つの書き込み先ブロックに対応する前記ライトバッファ内のライトバッファ領域が不要になったことを前記ホストに通知することをさらに具備する請求項9記載の制御方法。
  12. 前記ライト要求をEthernet(登録商標)を介して前記ホストから受信する請求項9記載の制御方法。
  13. 前記ライト要求は、書き込み先ブロックを指定するブロック識別子を含む請求項9記載の制御方法。
  14. 前記複数のブロックは複数のストリームにそれぞれ関連付けられており、
    前記ライト要求は、前記複数のストリーム内の一つのストリームの識別子を含む請求項9記載の制御方法。
  15. 前記ライトバッファは前記複数のブロックに対応する複数のライトバッファ領域を含み、
    前記転送要求は前記一つの書き込み先ブロックの識別子と前記記憶位置情報とを含む請求項9記載の制御方法。
  16. 前記複数段階のプログラム動作が終了し且つ前記第1のデータが前記不揮発性メモリから読み出し可能になった場合、前記ライトバッファに格納されている前記第1のデータが不要になったことを前記ホストに通知することをさらに具備する請求項9記載の制御方法。
JP2021172380A 2017-12-08 2021-10-21 メモリシステムおよび制御方法 Active JP7167291B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021172380A JP7167291B2 (ja) 2017-12-08 2021-10-21 メモリシステムおよび制御方法
JP2022166280A JP7400053B2 (ja) 2017-12-08 2022-10-17 メモリシステムおよび制御方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017236269A JP6967959B2 (ja) 2017-12-08 2017-12-08 メモリシステムおよび制御方法
JP2021172380A JP7167291B2 (ja) 2017-12-08 2021-10-21 メモリシステムおよび制御方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2017236269A Division JP6967959B2 (ja) 2017-12-08 2017-12-08 メモリシステムおよび制御方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022166280A Division JP7400053B2 (ja) 2017-12-08 2022-10-17 メモリシステムおよび制御方法

Publications (2)

Publication Number Publication Date
JP2022009357A JP2022009357A (ja) 2022-01-14
JP7167291B2 true JP7167291B2 (ja) 2022-11-08

Family

ID=87654645

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021172380A Active JP7167291B2 (ja) 2017-12-08 2021-10-21 メモリシステムおよび制御方法
JP2022166280A Active JP7400053B2 (ja) 2017-12-08 2022-10-17 メモリシステムおよび制御方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2022166280A Active JP7400053B2 (ja) 2017-12-08 2022-10-17 メモリシステムおよび制御方法

Country Status (1)

Country Link
JP (2) JP7167291B2 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012128660A (ja) 2010-12-15 2012-07-05 Toshiba Corp 半導体記憶装置
JP2013109419A (ja) 2011-11-17 2013-06-06 Toshiba Corp 情報処理装置
US20160321010A1 (en) 2015-04-28 2016-11-03 Kabushiki Kaisha Toshiba Storage system having a host directly manage physical data locations of storage device
JP2017054465A (ja) 2015-09-11 2017-03-16 株式会社東芝 メモリシステムおよびホスト装置
US20170123721A1 (en) 2015-10-28 2017-05-04 Sandisk Technologies Inc. System and method for utilization of a data buffer by command completion in parts
JP2017162068A (ja) 2016-03-08 2017-09-14 東芝メモリ株式会社 ストレージシステム、情報処理システムおよび制御方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5547154B2 (ja) 2011-09-21 2014-07-09 株式会社東芝 メモリ・デバイス

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012128660A (ja) 2010-12-15 2012-07-05 Toshiba Corp 半導体記憶装置
JP2013109419A (ja) 2011-11-17 2013-06-06 Toshiba Corp 情報処理装置
US20160321010A1 (en) 2015-04-28 2016-11-03 Kabushiki Kaisha Toshiba Storage system having a host directly manage physical data locations of storage device
JP2017054465A (ja) 2015-09-11 2017-03-16 株式会社東芝 メモリシステムおよびホスト装置
US20170123721A1 (en) 2015-10-28 2017-05-04 Sandisk Technologies Inc. System and method for utilization of a data buffer by command completion in parts
JP2017162068A (ja) 2016-03-08 2017-09-14 東芝メモリ株式会社 ストレージシステム、情報処理システムおよび制御方法

Also Published As

Publication number Publication date
JP2022179797A (ja) 2022-12-02
JP7400053B2 (ja) 2023-12-18
JP2022009357A (ja) 2022-01-14

Similar Documents

Publication Publication Date Title
JP6967959B2 (ja) メモリシステムおよび制御方法
JP7048289B2 (ja) 情報処理装置および方法
JP7159069B2 (ja) メモリシステムおよび制御方法
JP7051546B2 (ja) メモリシステムおよび制御方法
JP7358594B2 (ja) メモリシステム
US11237756B2 (en) System and method of writing to nonvolatile memory using write buffers
JP2021033849A (ja) メモリシステムおよび制御方法
JP7381678B2 (ja) メモリシステム
JP2021033848A (ja) メモリシステムおよび制御方法
JP2021033847A (ja) メモリシステムおよび制御方法
JP2023010765A (ja) メモリシステム
JP2021033845A (ja) メモリシステムおよび制御方法
JP7167291B2 (ja) メモリシステムおよび制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211021

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220729

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220823

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220914

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20221026

R151 Written notification of patent or utility model registration

Ref document number: 7167291

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151