JP2010507147A - Nonvolatile memory with data management in the worst case and method therefor - Google Patents
Nonvolatile memory with data management in the worst case and method therefor Download PDFInfo
- Publication number
- JP2010507147A JP2010507147A JP2009532520A JP2009532520A JP2010507147A JP 2010507147 A JP2010507147 A JP 2010507147A JP 2009532520 A JP2009532520 A JP 2009532520A JP 2009532520 A JP2009532520 A JP 2009532520A JP 2010507147 A JP2010507147 A JP 2010507147A
- Authority
- JP
- Japan
- Prior art keywords
- block
- data
- memory
- update
- blocks
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
- G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C16/00—Erasable programmable read-only memories
- G11C16/02—Erasable programmable read-only memories electrically programmable
- G11C16/06—Auxiliary circuits, e.g. for writing into memory
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C16/00—Erasable programmable read-only memories
- G11C16/02—Erasable programmable read-only memories electrically programmable
- G11C16/06—Auxiliary circuits, e.g. for writing into memory
- G11C16/10—Programming or data input circuits
- G11C16/102—External programming circuits, e.g. EPROM programmers; In-circuit programming or reprogramming; EPROM emulators
- G11C16/105—Circuits or methods for updating contents of nonvolatile memory, especially with 'security' features to ensure reliable replacement, i.e. preventing that old data is lost before new data is reliably written
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C16/00—Erasable programmable read-only memories
- G11C16/02—Erasable programmable read-only memories electrically programmable
- G11C16/06—Auxiliary circuits, e.g. for writing into memory
- G11C16/34—Determination of programming status, e.g. threshold voltage, overprogramming or underprogramming, retention
- G11C16/349—Arrangements for evaluating degradation, retention or wearout, e.g. by counting erase cycles
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C16/00—Erasable programmable read-only memories
- G11C16/02—Erasable programmable read-only memories electrically programmable
- G11C16/06—Auxiliary circuits, e.g. for writing into memory
- G11C16/34—Determination of programming status, e.g. threshold voltage, overprogramming or underprogramming, retention
- G11C16/349—Arrangements for evaluating degradation, retention or wearout, e.g. by counting erase cycles
- G11C16/3495—Circuits or methods to detect or delay wearout of nonvolatile EPROM or EEPROM memory devices, e.g. by counting numbers of erase or reprogram cycles, by using multiple memory areas serially or cyclically
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C8/00—Arrangements for selecting an address in a digital store
- G11C8/12—Group selection circuits, e.g. for memory block selection, chip selection, array selection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/0292—User address space allocation, e.g. contiguous or non contiguous base addressing using tables or multilevel address translation means
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/72—Details relating to flash memory management
- G06F2212/7202—Allocation control and policies
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/72—Details relating to flash memory management
- G06F2212/7205—Cleaning, compaction, garbage collection, erase control
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
Abstract
ブロック管理システムを伴う不揮発性メモリにおいて、ブロックに書き込まれたデータは、ホスト書き込みデータと、ブロックを管理するためのシステム制御データも含む。ブロックが一杯になるか、またはもはやデータを受け付けない場合には、書き換え動作において当該ブロック上にあるデータの有効なバージョンを他のブロックへリロケートさせた後に、当該ブロックを閉鎖させる。改良されたプリエンプティブな書き換え手法は、偶然にも同時に一杯になる場合に複数の書き換えが一度に生じるといった最悪の場合の状況を防止する。特に、制御データについてのプリエンプティブな書き換えのスケジューリングは、ホストデータを記憶するための更新ブロックの構成に基づく、制御ブロック書き換え毎に必要な時間および制御ブロック書き換えに利用可能な時間と、フォアグラウンドホスト動作およびホスト書き込みレイテンシにおいて必要な時間とを含む複数の考慮事項に基づく。 In non-volatile memory with a block management system, the data written to the block also includes host write data and system control data to manage the block. If the block is full or no longer accepting data, the rewrite operation re-locates the valid version of the data on the block to another block before closing the block. The improved preemptive rewriting approach prevents the worst case situation where multiple rewrites occur at once if it happens to fill at the same time. In particular, preemptive rewrite scheduling for control data is based on the configuration of the update block for storing host data, the time required for each control block rewrite and the time available for control block rewrite, foreground host operation and Based on several considerations, including the time required for host write latency.
Description
本発明は、一般的には、不揮発性半導体メモリに関し、より詳しく言えば、メモリの動作を制御するために使用されるシステムデータを管理するための改良されたシステムを伴うメモリブロック管理システムを有するものに関する。 The present invention relates generally to non-volatile semiconductor memory, and more particularly, to a memory block management system with an improved system for managing system data used to control the operation of the memory. About things.
電荷を不揮発的に記憶することができる固体メモリであり、特に、小形形状のファクタカードとしてパッケージ化されたＥＥＰＲＯＭおよびフラッシュＥＥＰＲＯＭの形態を取るものが、最近、様々な移動および携帯装置、とりわけ情報機器および一般消費者向け電子製品における記憶装置の選択肢となってきている。同じく固体メモリであるＲＡＭ（ランダムアクセスメモリ）とは異なり、フラッシュメモリは不揮発性であり、電源を切った後でもその記憶したデータを保持する。また、ＲＯＭ（読み出し専用メモリ）とは異なり、フラッシュメモリは、ディスク記憶装置と同様に書き換え可能である。高いコストにもかかわらず、フラッシュメモリは、大容量記憶装置の利用の際にますます使用されるようになっている。従来の大容量記憶装置は、ハードドライブおよびフロッピーディスクなどの回転磁気媒体に基づき、移動および携帯環境には不適切である。というのは、ディスクドライブはかさばりがちであり、機械的な故障が生じやすく、大きな待ち時間および高電力という要件を有するからである。これらの望ましくない属性により、ディスクをベースとした記憶装置は、ほとんどの移動および携帯の利用において実用的でないものとなっている。他方、フラッシュメモリは、埋め込み形および着脱可能なカードの形態の両方で、小さいサイズ、低電力消費、高速および高い信頼性という特徴が理由で、移動および携帯環境に理想的なほど適している。 Solid-state memory capable of storing charge in a nonvolatile manner, in particular in the form of EEPROMs and flash EEPROMs packaged as small form factor cards, has recently been used in a variety of mobile and portable devices, especially information equipment. And has become a storage option in consumer electronic products. Unlike RAM (Random Access Memory), which is also solid-state memory, flash memory is non-volatile and retains its stored data even after the power is turned off. Also, unlike ROM (read only memory), flash memory is rewritable like a disk storage device. Despite the high cost, flash memory is increasingly being used in the utilization of mass storage devices. Conventional mass storage devices are based on rotating magnetic media such as hard drives and floppy disks and are unsuitable for mobile and portable environments. Disk drives are bulky, prone to mechanical failure, and have high latency and high power requirements. These undesirable attributes make disk-based storage impractical for most mobile and portable applications. On the other hand, flash memory, both in the form of embedded and removable cards, is ideally suited for mobile and portable environments due to its small size, low power consumption, high speed and high reliability features.
フラッシュＥＥＰＲＯＭは、消去可能な不揮発性メモリであること、およびメモリセルに新たなデータを書き込むまたは「プログラム」するという点で、ＥＥＰＲＯＭ（電気的に消去可能でプログラム可能な読み出し専用メモリ）に類似している。両方とも、フローティング（未接続の）導電ゲートを使用し、電界効果トランジスタの構造であり、半導体基板におけるソース領域とドレイン領域と間のチャネル領域を覆って位置している。そして、コントロールゲートがフローティングゲートを覆って設けられる。トランジスタのしきい値電圧特性は、フローティングゲート上に保持された電荷量によって制御される。すなわち、フローティングゲート上の電荷の所定のレベルについて、トランジスタが「オン」に転換されてソース領域とドレイン領域との間が導通することができるようにする前にコントロールゲートに印加されなければならない対応する電圧（しきい値）がある。特に、フラッシュＥＥＰＲＯＭなどのフラッシュメモリは、メモリセルの全ブロックを同時に消去することができる。 Flash EEPROM is similar to EEPROM (electrically erasable programmable read only memory) in that it is an erasable non-volatile memory and writes or "programs" new data into the memory cells. ing. Both use floating (unconnected) conductive gates and are the structure of a field effect transistor, positioned over the channel region between the source region and the drain region in the semiconductor substrate. A control gate is provided to cover the floating gate. The threshold voltage characteristics of the transistor are controlled by the amount of charge held on the floating gate. That is, for a given level of charge on the floating gate, the response must be applied to the control gate before the transistor is turned "on" to allow conduction between the source and drain regions. Voltage (threshold) to be In particular, a flash memory such as a flash EEPROM can erase all blocks of memory cells simultaneously.
フローティングゲートは、ある範囲の電荷を保持することができるので、しきい値電圧ウィンドウ内の任意のしきい値電圧レベルにプログラムすることができる。しきい値電圧ウィンドウのサイズは、装置の最小および最大しきい値レベルによって区切られ、さらにフローティングゲート上にプログラムすることができる電荷の範囲に対応している。しきい値ウィンドウは、一般的には、メモリデバイスの特徴、動作状態、および履歴に依存している。ウィンドウ内の各別個の分解可能なしきい値電圧レベルの範囲は、原則的には、セルの限定的なメモリ状態を指定するために使用されてもよい。しきい値電圧が２つの別個の領域に分割される場合には、各メモリセルは１ビットのデータを記憶することができることになる。同様に、しきい値電圧ウィンドウが２つ以上の別個の領域に分割される場合には、各メモリセルは、１ビット以上のデータを記憶することができることになる。 The floating gate can hold a range of charge so it can be programmed to any threshold voltage level within the threshold voltage window. The size of the threshold voltage window is bounded by the minimum and maximum threshold levels of the device and further corresponds to the range of charge that can be programmed on the floating gate. The threshold window is generally dependent on the memory device's features, operating conditions, and history. Each distinct resolvable threshold voltage level range within the window may in principle be used to specify a limited memory state of the cell. If the threshold voltage is divided into two separate regions, each memory cell will be able to store one bit of data. Similarly, if the threshold voltage window is divided into two or more separate regions, each memory cell will be able to store one or more bits of data.
メモリセルとしての役割を果たすトランジスタは、典型的には、２つの機構のうちの１つによって「プログラムされた」状態にプログラムされる。「熱い電子注入」において、ドレインに印加された高い電圧が基板チャネル領域にわたって電子を加速させる。同時に、コントロールゲートに印加された高い電圧が、熱い電子を薄いゲート誘電体を通ってフローティングゲートへ引き寄せる。「トンネル注入」において、高い電圧が基板に対するコントロールゲートに印加される。このように、電子は、基板から介在フローティングゲートへと引き寄せられる。メモリの状態を変化させるために、メモリセルの最初に消去される電荷蓄積ユニットに電子を注入することによってメモリに対する書き込みを行うことを説明するために、「プログラム」という用語を従来使用してきたが、この用語は、現在では、「書き込み」または［記録する」などといった、より一般的な用語と交換可能に使用されてきている。 A transistor acting as a memory cell is typically programmed to a "programmed" state by one of two mechanisms. In "hot electron injection", the high voltage applied to the drain accelerates the electrons across the substrate channel region. At the same time, the high voltage applied to the control gate draws the hot electrons through the thin gate dielectric to the floating gate. In "tunnel injection", a high voltage is applied to the control gate to the substrate. Thus, electrons are attracted from the substrate to the intervening floating gate. The term "program" has been used conventionally to describe writing to the memory by injecting electrons into the first charge storage unit of the memory cell to change the state of the memory. However, this term is now used interchangeably with more general terms such as "write" or "record".
メモリデバイスの消去は、数多くの機構によって行われてもよい。例えば、ＥＥＰＲＯＭについて、高い電圧をコントロールゲートに関連した基板に印加して、フローティングゲート内の電子を薄い酸化物層を通じて基板チャネル領域へと通すようにすることによって（すなわち、ファウラー・ノルドハイムトンネル現象）、メモリセルは電気的に消去可能である。典型的には、ＥＥＰＲＯＭは、バイト毎に消去可能である。フラッシュＥＥＰＲＯＭについて、メモリは、すべて一度に電気的に消去可能であるか、または１回につき１つ以上の最小の消去可能なブロックを電気的に消去可能であり、最小の消去可能なブロックは、１つ以上のセクタからなってもよく、各セクタは、５１２バイト以上のデータを記憶してもよい。 Erasing a memory device may be performed by a number of mechanisms. For example, for EEPROM, a high voltage is applied to the substrate associated with the control gate to cause electrons in the floating gate to pass through the thin oxide layer to the substrate channel region (ie Fowler-Nordheim tunneling) And memory cells are electrically erasable. Typically, the EEPROM is erasable byte by byte. For flash EEPROM, the memory is electrically erasable all at once, or one or more smallest erasable blocks can be electrically erasable at one time, and the smallest erasable block is It may consist of one or more sectors, and each sector may store 512 bytes or more of data.
メモリデバイスは、典型的には、カードに実装されてもよい１つ以上のメモリチップを備える。各メモリチップは、デコーダまたは消去、書き込み、および読み出し回路のような周辺回路によってサポートされたメモリセルのアレイを備える。より高性能のメモリデバイスは、高機能および高レベルのメモリ動作およびインターフェイスを行うコントローラも搭載されている。 The memory device typically comprises one or more memory chips that may be implemented on the card. Each memory chip comprises an array of memory cells supported by peripheral circuits such as decoders or erase, write and read circuits. Higher performance memory devices are also equipped with controllers that perform sophisticated and high level memory operations and interfaces.
商業的に成功している数多くの不揮発性固体メモリデバイスが現在使用されている。これらのメモリデバイスはフラッシュＥＥＰＲＯＭであってもよく、または他の種類の不揮発性メモリセルを使用してもよい。フラッシュメモリおよびそれを製造するシステムおよび方法の例は、米国特許第５，０７０，０３２号（特許文献１）、第５，０９５，３４４号（特許文献２）、第５，３１５，５４１号（特許文献３）、第５，３４３，０６３号（特許文献４）、および第５，６６１，０５３号（特許文献５）、第５，３１３，４２１号（特許文献６）、および第６，２２２，７６２号（特許文献７）に記載されている。特に、ＮＡＮＤストリング構造のフラッシュメモリデバイスは、米国特許第５，５７０，３１５号（特許文献８）、第５，９０３，４９５号（特許文献９）、第６，０４６，９３５号（特許文献１０）に記載されている。また、不揮発性メモリデバイスは、電荷を蓄積するための誘電体層を有するメモリセルからも製造される。前に説明した導電性のフローティングゲート素子の代わりに、誘電体層が使用される。誘電体蓄積素子を使用するこのようなメモリデバイスは、エイタンらによる「ＮＲＯＭ：新規の局所化されたトラッピング、２ビット不揮発性メモリセル」，米国電子電気学会（ＩＥＥＥ）電子デバイスレター，第２１巻，第１１号，２０００年１１月，５４３〜５４５ページ (“NROM: A Novel Localized Trapping, 2-Bit Nonvolatile Memory Cell", IEEE Electron Device Letter, vol. 21, no. 11, November 2000, pp. 543-545)（非特許文献１）に記載されている。ＯＮＯ誘電体層が、ソースおよびドレイン拡散間のチャネルにわたって延在している。１データビットに対する電荷は、ドレインに隣接する誘電体層にて局在化され、他のデータビットについての電荷は、ソースに隣接する誘電体層にて局在化される。例えば、米国特許第５，７６８，１９２号（特許文献１１）および第６，０１１，７２５号（特許文献１２）は、２つの二酸化シリコン層間に挟まれたトラッピング誘電体を有する不揮発性メモリセルを開示している。多状態のデータ記憶装置は、誘電体内の空間的に別個の電荷蓄積領域のバイナリ状態を別個に読み出すことによって実施される。 A number of commercially successful non-volatile solid state memory devices are currently in use. These memory devices may be flash EEPROMs, or other types of non-volatile memory cells may be used. Examples of flash memory and systems and methods of manufacturing the same are described in U.S. Patent Nos. 5,070,032, 5,095,344, and 5,315,541. Patent Documents 3), 5,343,063 (patent documents 4), and 5,661,053 (patent documents 5), 5,313,421 (patent documents 6), and 6,222 , 762 (Patent Document 7). In particular, flash memory devices having a NAND string structure are disclosed in U.S. Patent Nos. 5,570,315 (patent documents 8), 5,903,495 (patent documents 9), 6,046,935 (patent documents 10) )It is described in. Nonvolatile memory devices are also manufactured from memory cells having a dielectric layer for storing charge. Instead of the conductive floating gate device described above, a dielectric layer is used. Such memory devices using dielectric storage elements are described in Atan et al., "NROM: A Novel Localized Trapping, 2-Bit Nonvolatile Memory Cell," Institute of Electronics and Electrical Engineers (IEEE) Electronic Device Letter, Volume 21. , No. 11, November 2000, pages 543-545 ("NROM: A Novel Localized Trapping, 2-Bit Nonvolatile Memory Cell", IEEE Electron Device Letter, vol. 21, no. 11, November 2000, pp. 543 -545) (Non-Patent Document 1). An ONO dielectric layer extends across the channel between the source and drain diffusions. The charge for one data bit is localized in the dielectric layer adjacent to the drain, and the charge for the other data bit is localized in the dielectric layer adjacent to the source. For example, US Pat. Nos. 5,768,192 and 6,011,725 disclose a non-volatile memory cell having a trapping dielectric sandwiched between two silicon dioxide layers. It is disclosed. Multi-state data storage is implemented by separately reading the binary states of spatially distinct charge storage regions within the dielectric.
読み出しおよびプログラミング性能を改善するために、アレイ内の複数の電荷蓄積素子またはメモリトランジスタが、並列に読み出しまたはプログラムされる。よって、メモリ素子の「ページ」が、一緒に読み出されるか、またはプログラムされる。既存のメモリ構成において、列は、典型的には、いくつかのインターリーブされたページを含むか、または１つのページを構成することもある。あるページのすべてのメモリ素子が、一緒に読み出されるか、またはプログラムされることもある。 Multiple charge storage elements or memory transistors in the array are read or programmed in parallel to improve read and program performance. Thus, "pages" of memory elements are read or programmed together. In existing memory configurations, a column typically contains several interleaved pages or may constitute one page. All memory elements of a page may be read or programmed together.
フラッシュメモリシステムにおいて、消去動作は、読み出しおよびプログラミング動作よりも非常に長くかかる場合がある。よって、かなりのサイズの消去ブロックがあることが望ましい。このように、消去時間は、メモリセルの大きな集合体にわたって償却される。 In flash memory systems, erase operations can take much longer than read and programming operations. Thus, it is desirable to have erase blocks of considerable size. Thus, erase time is amortized over a large collection of memory cells.
フラッシュメモリの性質は、データが消去されたメモリ位置に書き込まれなければならないということに基づいている。ホストからのある論理アドレスのデータを更新すべき場合、１つのやり方は、更新データを同一の物理メモリ位置に書き換えるというものである。すなわち、論理／物理アドレスマッピングは変化しない。しかし、これは、この物理位置を含む消去ブロック全体が最初に消去されてから、更新されたデータで書き換えられなければならないということを意味する。この更新方法は、消去ブロック全体が消去され、かつ書き換えられる必要があるので効率が悪く、更新すべきデータが消去ブロックの小さい部分のみを占める場合には特に効率が悪い。また、メモリブロックの消去リサイクルが高い頻度で生じる結果となり、この種のメモリデバイスの限られた耐久性の観点から望ましくない。 The nature of flash memory is based on the fact that data must be written to erased memory locations. If the data of a certain logical address from the host is to be updated, one way is to rewrite the update data to the same physical memory location. That is, the logical / physical address mapping does not change. However, this means that the entire erase block containing this physical location must first be erased and then be rewritten with updated data. This update method is inefficient because the entire erase block needs to be erased and rewritten, and is particularly inefficient when the data to be updated occupies only a small portion of the erase block. Also, erase recycling of memory blocks results in high frequency, which is not desirable from the viewpoint of limited durability of this type of memory device.
フラッシュメモリシステムの他の問題点は、システム制御およびディレクトリデータと関係がある。データは、様々なメモリ動作の過程で生成かつアクセスされる。よって、効率的な取り扱いおよび素早いアクセスが性能に直接影響を与えることになる。フラッシュメモリは記憶装置用を意図し、かつ不揮発性であるので、フラッシュメモリ内のこの種のデータを保持するのが望ましい。しかし、コントローラとフラッシュメモリとの間の介在ファイル管理システムによって、データは直接にはアクセスすることができない。また、システム制御およびディレクトリデータは、アクティブかつ断片化しがちであり、大規模なブロック消去を伴うシステムへの記憶には役に立たない。従来、この種のデータは、コントローラＲＡＭに設定され、コントローラによる直接アクセスを可能としている。メモリデバイスの電源投入後、コントローラＲＡＭに配置すべき必要なシステム制御およびディレクトリ情報をコンパイルするために、初期化の処理によって、フラッシュメモリを走査することができる。この処理は時間がかかり、フラッシュメモリの容量が増加しているのでいっそうのコントローラＲＡＭの容量が要求される。 Another issue with flash memory systems relates to system control and directory data. Data is generated and accessed in the course of various memory operations. Thus, efficient handling and quick access will directly affect performance. Because flash memory is intended for storage and is non-volatile, it is desirable to retain this type of data in flash memory. However, data can not be accessed directly by the intervening file management system between the controller and the flash memory. Also, system control and directory data tend to be active and fragmented and not useful for storage in systems with large block erasures. Conventionally, this type of data is set in the controller RAM to allow direct access by the controller. After powering up the memory device, the flash memory can be scanned by an initialization process to compile the necessary system control and directory information to be placed in the controller RAM. This process is time-consuming, and the capacity of the flash memory is increasing, so more controller RAM capacity is required.
米国特許第６，５６７，３０７号（特許文献１３）は、メモ帳としての役割を果たす複数の消去ブロック内に更新データを記録し、また様々なブロック内の有効なセクタを最終的に統合化し、かつこのセクタを論理的な順次順序で再構成した後にセクタを書き換えることを含む大きな消去ブロック内のセクタ更新を扱う方法を開示している。このように、ブロックは、ごくわずかな更新の度に消去され、かつ書き込まれる必要はない。 U.S. Pat. No. 6,567,307 records updated data in multiple erase blocks that serve as a note pad and finally integrates valid sectors in the various blocks And a method of handling sector updates within a large erase block that includes rewriting the sectors after rearranging the sectors in logical sequential order. In this way, blocks are erased every few updates and need not be written.
国際公開特許出願第ＷＯ０３／０２７８２８号（特許文献１４）および国際公開特許出願第ＷＯ００／４９４８８号（特許文献１５）は共に、論理セクタアドレスを区画に分割することを含む、大きな消去ブロック内での更新を扱うメモリシステムを開示している。小さな区画の論理アドレス範囲が、ユーザデータ用の他の区画とは別に、アクティブなシステム制御データ用に確保される。このように、システム制御データを独自の区画内で操作すれば、他の区画内の関連するユーザデータと相互に作用しないことになる。更新は論理セクタレベルであり、書き込みポインタは、書き込むべきブロック内の対応する物理セクタを指す。マッピング情報は、ＲＡＭ内にバッファリングされ、最終的にはメインメモリ内のセクタ割り当てテーブルに記憶される。論理セクタの最新バージョンによって、既存のブロック内のすべての以前のバージョンは廃止されることになり、既存のブロックは、部分的に廃止される。部分的に廃止されたブロックを許容することができる数に維持するために、ガーベッジコレクションが行われる。 Both WO 03/027828 and WO 00/49488 both divide the logical sector address into partitions, within a large erase block. Disclosed is a memory system that handles updates. A small partition logical address range is reserved for active system control data separately from other partitions for user data. Thus, manipulating system control data in its own compartment will not interact with associated user data in other compartments. The update is at the logical sector level, and the write pointer points to the corresponding physical sector in the block to be written. The mapping information is buffered in the RAM and finally stored in the sector allocation table in the main memory. With the latest version of the logical sector, all previous versions in the existing block will be retired and the existing block will be partially retired. Garbage collection is performed to keep partially obsolete blocks in an acceptable number.
従来技術のシステムは、更新データを数多くのブロックに渡って分散させる傾向にあるか、または更新データによって数多くの既存ブロックを部分的に廃止する場合もある。その結果、部分的に廃止されたブロックに対して大量のガーベッジコレクションが必要となることが多く、これは効率的でなく、メモリの早すぎる老化を生じさせる。また、非順次更新に比べて、順次更新を扱う体系化された効率的なやり方がない。 Prior art systems tend to distribute update data across many blocks, or update data may partially eliminate many existing blocks. As a result, a large amount of garbage collection is often required for partially obsolete blocks, which is not efficient and results in premature aging of the memory. Also, there is no systematic and efficient way to handle sequential updates compared to non-sequential updates.
メモリ位置のブロックに組織化されたデータ記憶システムにおいて、ホストは、ホストデータをホストデータブロックのセットにして記憶することができる。ところで、当該システムは、さらに、ブロックがどのように割り当てられているか、およびブロック内のどこにデータがあるかを常に把握するために、制御データを制御データブロックの他のセットにして記憶する。いずれの場合にも、データおよびその更新があるブロックを埋めると、当該ブロックは、そのデータの最新バージョンを空きブロックにリロケートさせた後に閉鎖されることになる。この書き換え処理は、一般的には、ガーベッジコレクションと称される。ガーベッジコレクションには様々な種類があり、あるものは他のものよりも時間がかかる。 In a data storage system organized in blocks of memory locations, a host can store host data in sets of host data blocks. By the way, the system also stores control data in another set of control data blocks, to keep track of how the blocks are allocated and where in the block data is always present. In either case, if the data and its updates fill a block, the block will be closed after relocating the latest version of the data to a free block. This rewriting process is generally referred to as garbage collection. There are various types of garbage collection, some of which take longer than others.
ガーベッジコレクションは、ブロックの境界を渡る場合または障害に遭遇する場合のホスト書き込み中にトリガされてもよい。同様に、ガーベッジコレクションは、制御ブロックの境界を渡る場合（制御ブロック書き換え）や、プログラムエラーがある場合、または障害に遭遇する場合（エラー処理）など、メモリシステムの内部またはハウスキーピング動作中にトリガされてもよい。ガーベッジコレクションの他の例には、ウェアレベリングおよび読み出しスクラブが含まれる。 Garbage collection may be triggered during host writes when crossing block boundaries or encountering faults. Similarly, garbage collection triggers during memory system internal or housekeeping operations, such as crossing control block boundaries (control block rewrite), when there is a program error, or when a failure is encountered (error handling). It may be done. Other examples of garbage collection include wear leveling and read scrubbing.
ガーベッジコレクションは時間がかかり、最悪の場合の状況によっては、いくつかのガーベッジコレクションが連続して生じることがあるので、システムのタイミングが乱される恐れがあり、メモリが動作しなくなることがある。
したがって、大容量および高性能の不揮発性メモリに対する一般的な要求がある。特に、前述した問題なくメモリ動作を行うことが可能な大容量の不揮発性メモリに対する要求がある。
Garbage collection can be time consuming and, under worst case conditions, some garbage collection may occur in succession, which may cause the timing of the system to be disturbed and the memory may not work.
Thus, there is a general need for high capacity and high performance non-volatile memory. In particular, there is a need for a large capacity non-volatile memory that can perform memory operations without the aforementioned problems.
よって、本発明の目的は、タイミング要件に違反することなく任意のホスト更新シーケンスで内部動作を処理可能な、強固なデータ記憶システムを提供することである。
特に、本発明の目的は、メモリ動作を制御するために使用されるシステム制御データを記憶するためのメモリブロックのプールにおける予約ブロックの数を減少させることと、制御ブロック更新のために、最悪の場合におけるタイミングを減少させることである。
Accordingly, it is an object of the present invention to provide a robust data storage system that can handle internal operations with any host update sequence without violating timing requirements.
In particular, the object of the present invention is to reduce the number of reserved blocks in the pool of memory blocks for storing system control data used to control memory operations and for the worst case for control block updates. It is to reduce the timing in the case.
本発明によれば、長時間にわたって行われ得る制御データのカスケード更新を回避するために、改良された手法が提供される。これは、制御データの型毎にブロックマージンを設定して、当該ブロックマージンに到達したもっとも早い時機にブロックを書き換えることによって達成される。特に、マージンは、書き換えが生じ得る前にブロックをすべて埋めてしまわないように、書き換えが生じ得る前に所定の間隔で蓄積されたデータを収容するのにちょうど十分であるように設定される。当該所定の間隔は、とりわけ、書き換えが生じ得る前に最悪の場合における間隔を生じさせるホスト書き込みパターンを考慮することによって決定される。マージンを設定するための他の考慮事項としては、ホストデータを記憶するための更新ブロックの構成に基づく、制御ブロック書き換え毎に必要な時間と、制御ブロック書き換えのために利用可能な時間と、フォアグラウンドホスト動作およびホスト書き込みレイテンシにおいて必要な時間とが含まれる。 According to the present invention, an improved approach is provided to avoid cascaded updating of control data that may occur over time. This is achieved by setting a block margin for each type of control data and rewriting the block at the earliest when the block margin is reached. In particular, the margin is set to be just enough to accommodate the data accumulated at a predetermined interval before rewriting can occur, so that it does not fill the entire block before rewriting can occur. The predetermined interval is determined, inter alia, by considering the host write pattern which gives rise to the interval in the worst case before rewriting can occur. Other considerations for setting the margin include the time required for each control block rewrite, the time available for control block rewrite, and the foreground based on the configuration of the update block for storing host data. It includes the time required for host operation and host write latency.
一実施例において、１つより多くの制御ブロック書き換えが待ち状態にある場合に、よりアクティブな制御データ型を有するものが、ホスト動作において次に利用可能な時機に、優先的に実行される。このように、一度に生じることになる制御ブロック書き換えは１つだけなので、制御ブロック書き換えのためのリソースとして必要最小限の予約ブロックが取っておかれる。 In one embodiment, if more than one control block rewrite is pending, the one with the more active control data type is preferentially executed at the next available opportunity in host operation. As described above, since only one control block rewrite can occur at a time, a minimum necessary reservation block is reserved as a resource for the control block rewrite.
また、本願の改良は、カスケード制御更新毎の複数のプログラムエラーに備えるものであり、限られた時間内にすぐに次々と生じる１つのＥＣＣまたはプログラムエラーに対処することができる。この特徴は、ワンタイムプログラマブル（「ＯＴＰ」：one-time programmable ）メモリにとって特に重要である。なぜならば、障害が低レベルにおいてパッチされない場合にはリスクが非常に高いからである。また、本願改良は、最小限のブロックが、制御データを記憶するための更新ブロックのプールに予約されるようにすることができる。予約ブロックにより、メモリ制御システムは、すべての制御データブロックが同時に埋められる可能性があるという最悪のカスケード更新を処理することができ、予約ブロックすべて、同じビジーな期間に書き換えられなければならない。制御データ用に予約される必要のあるブロックが少なければ、より多くのブロックをホストデータ更新用に利用することが可能となる。 Also, the improvement of the present application is to prepare for multiple program errors per cascade control update, and can cope with one ECC or program error immediately occurring one after another within a limited time. This feature is particularly important for one-time programmable ("OTP") memory. Because the risk is very high if the fault is not patched at low levels. Also, the refinement can be such that minimal blocks are reserved in the pool of update blocks for storing control data. The reserved blocks allow the memory control system to handle the worst cascade update that all control data blocks may be filled simultaneously, and all reserved blocks must be rewritten in the same busy period. If fewer blocks need to be reserved for control data, more blocks can be used for host data updates.
本発明の利点には、以下のものがある。最悪の場合における更新シーケンスにおいて、より多くのエラーを処理することができる。ガーベッジコレクション（ＧＣ）の最も長い組み合わせと制御ブロックの圧縮という最悪の場合を回避することができる。例えば、カオス的ＧＣは、連続ＧＣよりも長く生じるので、制御更新をカオス的ＧＣと同時に行うことを回避することによって、この最悪の場合のコマンドレイテンシを軽減することができる。ブロックマージンを最良に選択して（例えば、圧縮のためのフラー（ｆｕｌｌｅｒ）制御ブロックを選択）、実行する内部動作をスケジューリングすることによって、最適性能が得られる。最悪の場合の更新シーケンスを処理するために、予約消去ブロックの数を減少させることが必要である。プリエンプティブな内部動作の場合には、エラー処理を再スケジューリングすることができるので、遥かに高速にエラーを処理することができる。部分的なエラー処理およびエラー処理のスケジューリング完了が可能である。読み出し動作中にＥＣＣエラー処理をスケジューリングすることができ、これは、レイテンシが短く、後で実行される（例えば、次の書き込み動作中など）。 Among the advantages of the invention are: More errors can be processed in the update sequence in the worst case. The worst case of the longest combination of garbage collection (GC) and control block compression can be avoided. For example, since chaotic GCs occur longer than continuous GCs, this worst case command latency can be reduced by avoiding simultaneous control updates with chaotic GCs. Optimal performance is obtained by scheduling the internal operations to be performed with the best choice of block margins (e.g., select fuller control blocks for compression). In order to handle the worst case update sequence, it is necessary to reduce the number of reserved erase blocks. In the case of preemptive internal operations, error handling can be rescheduled, so errors can be handled much faster. Partial error handling and scheduling completion of error handling is possible. ECC error handling can be scheduled during a read operation, which has a short latency and will be performed later (eg, during the next write operation, etc.).
本発明のさらなる特徴および利点は、添付の図面と共に理解される以下の好ましい実施形態の説明から理解されるだろう。 Additional features and advantages of the present invention will be understood from the following description of the preferred embodiments, taken in conjunction with the accompanying drawings.
図１から図２０は、本願の様々な態様が実施されるようなブロック管理を伴うメモリシステムの例を示す。同様のメモリシステムが、Gorobetsらによる「Non-Volatile Memory and Method with Control Data Management 」という米国公開特許出願第２００５／０１４４３６５号（特許文献１６）に記載されている。 FIGS. 1 through 20 illustrate examples of memory systems with block management as various aspects of the present application may be implemented. A similar memory system is described in Gorobets et al., US Published Patent Application No. 2005/0144365, "Non-Volatile Memory and Method with Control Data Management".
図１は、本発明を実施するのに適切なメモリシステムの主要ハードウェアの構成要素を概略的に示す。メモリシステム２０は、典型的には、ホストインターフェイスを通じてホスト１０と共に動作する。メモリシステムは、典型的には、メモリカードの形式を取るか、または埋め込み形メモリシステムである。メモリシステム２０は、動作がコントローラ１００によって制御されるメモリ２００を含む。メモリ２００は、１つ以上の集積回路チップに渡って分散された不揮発性メモリセルの１つ以上のアレイからなる。コントローラ１００は、インターフェイス１１０と、プロセッサ１２０と、オプションのコプロセッサ１２１と、ＲＯＭ１２２（読み出し専用メモリ）と、ＲＡＭ１３０（ランダムアクセスメモリ）と、オプションのプログラム可能な不揮発性メモリ１２４とを含む。インターフェイス１１０は、ある構成要素をコントローラからホストへとインターフェイスさせ、他の構成要素をメモリ２００とインターフェイスさせる。不揮発性ＲＯＭ１２２および／またはオプションの不揮発性メモリ１２４に記憶されたファームウェアは、コントローラ１００の機能を実施するためにプロセッサ１２０に対して符号を提供する。誤り訂正符号は、プロセッサ１２０またはオプションのコプロセッサ１２１によって処理されてもよい。代替の実施形態において、コントローラ１００は、状態マシン（図示せず）によって実施される。さらに他の実施形態において、コントローラ１００は、ホスト内で実施される。
FIG. 1 schematically shows the major hardware components of a memory system suitable for implementing the present invention.
論理および物理ブロック構造
図２は、本発明の好ましい実施形態に係る、セクタ（またはメタブロック）の物理グループに組織化され、コントローラのメモリマネージャによって管理されたメモリを示す。メモリ２００は、メタブロックに組織化され、各メタブロックは、共に消去可能な物理セクタＳ0 ，．．．，ＳN-1 のグループである。
Logical and Physical Block Structure FIG. 2 illustrates memory organized into physical groups of sectors (or metablocks) and managed by a controller's memory manager, in accordance with a preferred embodiment of the present invention.
ホスト１０は、ファイルシステムまたはオペレーティングシステムの下でアプリケーションを実行する場合に、メモリ２００にアクセスする。典型的には、ホストシステムは、データを論理セクタ単位でアドレス指定し、例えば、各セクタは、５１２バイトのデータを含んでもよい。また、ホストが、論理クラスタ単位でメモリシステムに対して読み出しまたは書き込みを行うのが通常であり、各クラスタは、１つ以上の論理セクタからなる。ホストシステムによっては、より低いレベルのメモリ管理をホスト側で行うためにオプションのホスト側メモリマネージャが存在する場合がある。多くの場合、読み出しまたは書き込み動作中に、ホスト１０は、実質的に、メモリシステム２０に対してコマンドを発行して、データの論理セクタのストリングを含むセグメントを連続するアドレスと共に読み出しまたは書き込みを行う。
The
フラッシュメモリ２００のメタブロック内のホスト論理セクタのデータの記憶および検索を管理するために、メモリ側メモリマネージャが、メモリシステム２０のコントローラ１００内で実施される。好ましい実施形態において、メモリマネージャは、メタブロックの消去、読み出し、書き込み動作を管理するための数多くのソフトウェアモジュールを含む。また、メモリマネージャは、フラッシュメモリ２００とコントローラＲＡＭ１３０との間の動作に関連したシステム制御およびディレクトリデータを保持する。
A memory-side memory manager is implemented within
図３Ａ（ｉ）〜（ｉｉｉ）は、本発明の好ましい実施形態に係る、論理グループとメタブロックとの間のマッピングを概略的に示す。物理メモリのメタブロックは、論理グループのデータのＮ個の論理セクタを記憶するためのＮ個の物理セクタを有する。図３Ａ（ｉ）は、論理グループＬＧi からのデータを示し、論理セクタは、連続論理順序０，１，．．．，Ｎ−１である。図３Ａ（ｉｉ）は、同一の論理順序のメタブロック内に記憶されている同じデータを示す。このように記憶される場合に、メタブロックは、「順次」であるといわれる。一般的に、メタブロックは、異なる順序で記憶されたデータを有してもよく、その場合は、メタブロックは、「非順次」または「カオス的」であるといわれる。
3A (i)-(iii) schematically illustrate the mapping between logical groups and metablocks according to a preferred embodiment of the present invention. A metablock of physical memory has N physical sectors for storing N logical sectors of data of a logical group. FIG. 3A (i) shows data from logical group LG i , where logical sectors are arranged in sequential
論理グループの最小のアドレスと、それがマッピングされるメタブロックの最小アドレスとの間には、オフセットがあることがある。この場合、論理セクタアドレスは、メタブロック内の論理グループの末尾から先頭へ戻るループとして折り返す。例えば、図３Ａ（ｉｉｉ）では、メタブロックは、その最初の位置が論理セクタｋのデータで始まるように記憶する。最終論理セクタＮ−１に達すると、セクタ０に戻り、最終的には、その最終物理セクタに論理セクタｋ−１に関連したデータを記憶する。好ましい実施形態において、メタブロックの最初の物理セクタに記憶されたデータの最初の論理セクタアドレスを識別するといった、任意のオフセットの識別のために、ページタグが使用される。２つのブロックは、ページタグだけが異なる場合、その論理セクタを同様の順序で記憶しているものと考えられる。
There may be an offset between the lowest address of the logical group and the lowest address of the metablock to which it is mapped. In this case, the logical sector address wraps around as a loop from the end of the logical group in the metablock back to the beginning. For example, in FIG. 3A (iii), the metablock stores such that its first position starts with the data of logical sector k. When the final logical sector N-1 is reached, the process returns to
図３Ｂは、論理グループとメタブロックと間のマッピングを概略的に示す。各論理グループは、データが現在更新中の少数の論理グループを除いて、固有のメタブロックにマッピングされる。論理グループが更新された後、別のメタブロックにマッピングされてもよい。マッピング情報は、論理／物理ディレクトリのセットに維持され、これについては、詳細に後述する。 FIG. 3B schematically illustrates the mapping between logical groups and metablocks. Each logical group is mapped to a unique metablock, except for the few logical groups whose data is currently being updated. After the logical group is updated, it may be mapped to another metablock. The mapping information is maintained in a set of logical / physical directories, which will be described in detail later.
メタブロックマッピングに対する他の種類の論理グループも予期される。例えば、可変サイズのメタブロックが、本願と同日にAlan Sinclair によって出願された「Adaptive Metablocks 」という同時継続出願中の共有された米国特許出願（特許文献１７）に開示されている。同時継続出願の開示全体は、本願明細書において参照により援用されている。 Other types of logical groups for metablock mapping are also contemplated. For example, variable size metablocks are disclosed in co-pending US patent application Ser. No. 07 / 956,648, entitled "Adaptive Metablocks," filed by Alan Sinclair on the same day as the present application. The entire disclosure of the co-pending application is incorporated herein by reference.
本発明の特徴の１つは、システムは単一の論理区画で動作し、メモリシステムの論理アドレス範囲にわたる論理セクタのグループは同一に扱われることである。例えば、システムデータを含むセクタと、ユーザデータを含むセクタとは、論理アドレス空間内のどこにでも分散することができる。 One of the features of the present invention is that the system operates in a single logical partition, and groups of logical sectors across the logical address range of the memory system are treated identically. For example, sectors containing system data and sectors containing user data can be distributed anywhere within the logical address space.
従来技術のシステムとは異なり、高頻度かつ小サイズの更新を伴うデータを含む可能性が高い論理アドレス空間セクタに局在化させるための、システムセクタ（すなわち、ファイル割り当てテーブルに関連するセクタ、ディレクトリ、またはサブディレクトリ）の特別な分割またはゾーニングはない。代わりに、セクタの論理グループを更新するこの手法は、システムセクタに典型的なアクセスパターンおよびファイルデータに典型的なアクセスパターンを効率的に扱うことになる。 System sectors (ie, sectors, directories associated with the file allocation table) for localization to logical address space sectors that are likely to contain data with frequent and small size updates, unlike prior art systems There is no special splitting or zoning of or sub-directories). Instead, this approach of updating logical groups of sectors will efficiently handle the access patterns typical of system sectors and the access patterns typical of file data.
図４は、物理メモリにおける構造を含むメタブロックの配列を示す。フラッシュメモリは、一単位として共に消去可能なメモリセルのブロックを備える。このような消去ブロックは、フラッシュメモリの消去の最小単位、またはメモリの最小消去ユニット（ＭＥＵ）である。最小消去ユニットは、メモリのハードウェア設計パラメータであるが、複数のＭＥＵの消去をサポートするメモリシステムによっては、１つ以上のＭＥＵを備える「超ＭＥＵ」を構成することができる。フラッシュＥＥＰＲＯＭについて、ＭＥＵは１つのセクタを備えてもよいが、複数のセクタが好ましい。図に示されている例では、Ｍ個のセクタを有する。好ましい実施形態において、各セクタは、５１２バイトのデータを記憶することができ、ユーザデータ部分と、システムまたはオーバーヘッドデータを記憶するためのヘッダ部分とを有する。メタブロックがＰ個のＭＥＵから構成されている場合には、各ＭＥＵはＭ個のセクタを含み、そして、各メタブロックは、Ｎ＝Ｐ＊Ｍ個のセクタを有することになる。 FIG. 4 shows an arrangement of metablocks containing structures in physical memory. Flash memory comprises blocks of memory cells that are erasable together as a unit. Such an erase block is the minimum unit of erase of the flash memory or the minimum erase unit (MEU) of the memory. The minimum erase unit is a hardware design parameter of the memory, but depending on the memory system that supports the erasure of multiple MEUs, a "super MEU" can be configured with one or more MEUs. For flash EEPROM, the MEU may comprise one sector, but multiple sectors are preferred. In the example shown in the figure, it has M sectors. In a preferred embodiment, each sector can store 512 bytes of data and has a user data portion and a header portion for storing system or overhead data. If the metablock is composed of P MEUs, then each MEU will contain M sectors, and each metablock will have N = P * M sectors.
メタブロックは、システムレベルでは、例えば共に消去可能なセクタといった、メモリ位置のグループを表す。フラッシュメモリの物理アドレス空間は、メタブロックを消去の最小単位とした、メタブロックのセットとして扱われる。本願明細書において「メタブロック」および「ブロック」という用語は、媒体管理のためのシステムレベルにおける消去の最小単位を規定するために類義語として使用され、「最小消去ユニット」またはＭＥＵは、フラッシュメモリの消去の最小単位を示すために使用される。 Metablocks represent groups of memory locations at the system level, eg, sectors that can be erased together. The physical address space of the flash memory is treated as a set of metablocks, with the metablock as the smallest unit of erase. As used herein, the terms "metablock" and "block" are used as synonyms to define the minimum unit of erase at the system level for media management, and the "minimum erase unit" or MEU is used to Used to indicate the minimum unit of erasure.
メタブロックを形成するための最小消去ユニット（ＭＥＵ）のリンク付け
プログラミング速度および消去速度を最大限にするために、複数のＭＥＵにある複数のページの情報が並列にプログラミングされるように、かつ複数のＭＥＵが並列に消去されるようにすることによって、並行処理ができる限り活用される。
フラッシュメモリにおいて、ページは、１回の動作で共にプログラムすることができるメモリセルの集まりである。ページは、１つ以上のセクタを備えていてもよい。また、メモリアレイは、１つ以上のプレーンに分割されてもよく、１つのプレーン内の１つのＭＥＵのみが１度にプログラムまたは消去されてもよい。最後に、プレーンは、１つ以上のメモリチップに渡って分散されていてもよい。
To maximize the linking programming speed and erasing speed of the minimum erase unit (MEU) to form a metablock , multiple pages of information in multiple MEUs can be programmed in parallel, and to maximize the programming speed Parallel processing is exploited as much as possible by allowing the MEUs to be eliminated in parallel.
In flash memory, a page is a collection of memory cells that can be programmed together in a single operation. A page may comprise one or more sectors. Also, the memory array may be divided into one or more planes, and only one MEU in one plane may be programmed or erased at one time. Finally, the planes may be distributed across one or more memory chips.
フラッシュメモリにおいて、ＭＥＵは、１つ以上のページを備えていてもよい。フラッシュメモリチップ内のＭＥＵは、プレーンに組織化されてもよい。各プレーンからの１つのＭＥＵは並行してプログラムまたは消去されてもよいので、各プレーンから１つのＭＥＵを選択することによって複数のＭＥＵメタブロックを形成するのが得策である（以下の図５Ｂ参照）。 In flash memory, the MEU may comprise one or more pages. The MEUs in the flash memory chip may be organized into planes. Since one MEU from each plane may be programmed or erased in parallel, it is better to form multiple MEU metablocks by selecting one MEU from each plane (see FIG. 5B below) ).
図５Ａは、互いに異なるプレーンの最小消去ユニットのリンク付けから構成されるメタブロックを示す。ＭＢ０，ＭＢ１，．．．などの各メタブロックは、メモリシステムの互いに異なるプレーンからのＭＥＵから構成され、互いに異なるプレーンは、１つ以上のチップにわたって分散されていてもよい。図２に示されているメタブロックリンクマネージャ１７０は、各メタブロックについてのＭＥＵのリンク付けを管理する。各メタブロックは、初期フォーマット処理中に構成され、その構成成分であるＭＥＵを、ＭＥＵのうちの１つに障害があるまで、システムの寿命がある限り保持する。
図５Ｂは、１つの最小消去ユニット（ＭＥＵ）が、メタブロックへのリンク付けのために各プレーンから選択される、一実施形態を示す。
FIG. 5A shows a metablock consisting of linking of the minimum erasure units of different planes. MB0, MB1,. . . Each metablock, such as, is composed of MEUs from different planes of the memory system, and different planes may be distributed over one or more chips. The
FIG. 5B shows an embodiment in which one minimum erasure unit (MEU) is selected from each plane for linking to a metablock.
図５Ｃは、１つより多くの最小消去ユニット（ＭＥＵ）が、メタブロックへのリンク付けのために各プレーンから選択される、別の実施形態を示す。別の実施形態において、１つより多くのＭＥＵが各プレーンから選択されて超ＭＥＵが形成されてもよい。例えば、超ＭＥＵは、２つのＭＥＵから形成されてもよい。この場合、読み出しまたは書き込み動作について１つより多くのパスを利用してもよい。 FIG. 5C shows another embodiment in which more than one minimum erasure unit (MEU) is selected from each plane for linking to a metablock. In another embodiment, more than one MEU may be selected from each plane to form a super MEU. For example, the super MEU may be formed from two MEUs. In this case, more than one pass may be utilized for read or write operations.
ＭＥＵをメタブロックにリンク付けまたは再リンク付けすることは、本願と同日にCarlos Gonzales らによって出願された「Adaptive Deterministic Grouping of Blocks into Multi-Block Structures 」という同時継続出願中の共有された米国特許出願（特許文献１８）に開示されている。同時継続出願の開示全体は、本願明細書において参照により援用されている。 Linking or relinking MEUs to metablocks is a co-pending US patent application entitled “Adaptive Determining Grouping of Blocks into Multi-Block Structures” filed by Carlos Gonzales et al. (Patent Document 18). The entire disclosure of the co-pending application is incorporated herein by reference.
メタブロック管理
図６は、コントローラおよびフラッシュメモリにおいて実施されるようなメタブロック管理システムの概略ブロック図である。メタブロック管理システムは、コントローラ１００において実施された様々な機能モジュールを備え、様々な制御データ（ディレクトリデータを含む）をフラッシュメモリ２００およびコントローラＲＡＭ１３０内に階層的に分散されたテーブルおよびリストに保持する。コントローラ１００内に実装された機能モジュールは、インターフェイスモジュール１１０と、論理／物理アドレス変換モジュール１４０と、更新ブロックマネージャモジュール１５０と、消去ブロックマネージャモジュール１６０と、メタブロックリンクマネージャモジュール１７０とを含む。
Metablock Management FIG. 6 is a schematic block diagram of a metablock management system as implemented in the controller and flash memory. The metablock management system comprises various functional modules implemented in the
インターフェイス１１０により、メタブロック管理システムは、ホストシステムとインターフェイスすることができる。論理／物理アドレス変換モジュール１４０は、論理アドレスをホストから物理メモリ位置へマッピングする。更新ブロックマネージャモジュール１５０は、データの所定の論理グループについて、メモリにおけるデータ更新動作を管理する。消去ブロックマネージャモジュール１６０は、メタブロックの消去動作と、新規の情報を記憶するためのメタブロック割り当てとを管理する。メタブロックリンクマネージャモジュール１７０は、セクタの最小消去可能ブロックのサブグループのリンク付けを管理して、所定のメタブロックを構成する。これらのモジュールの詳細な説明は、それぞれの欄で行う。
動作中に、メタブロック管理システムは、アドレス、制御および状態情報などの制御データを生成して、それと共に動作する。制御データのほとんどが小さなサイズの頻繁に変化するデータであることが多いので、大きなブロック構造のフラッシュメモリ内では簡単かつ効率的に記憶および保持することができない。より静的な制御データを不揮発性フラッシュメモリに記憶させ、より変化するより少ない量の制御データをコントローラＲＡＭに位置づけるという階層的分散手法を使用することで、さらに効率的な更新およびアクセスを行う。電源遮断または障害時には、この手法により、揮発性コントローラＲＡＭ内の制御データは、不揮発性メモリ内の小さなセットの制御データを走査することによって、迅速に再構築することができる。これが可能なのは、本発明が、データの所定の論理グループの予想される動作に関連するブロックの数を制限しているからである。加えて、存続が必要とされる制御データのいくつかは、セクタ毎に更新可能な不揮発性のメタブロックに記憶され、新規のセクタを生じさせる各更新が、以前の更新に代わって記録される。セクタインデックス付け手法を制御データのために使用して、メタブロック内のセクタ毎の更新を追跡する。 During operation, the metablock management system generates control data, such as address, control and status information, to work with it. Because most of the control data is often small sized, frequently changing data, it can not be stored and held easily and efficiently in large block structured flash memories. More efficient updates and accesses are achieved by using a hierarchical distribution approach where more static control data is stored in non-volatile flash memory and less changing amounts of control data are located in controller RAM. On power down or failure, this approach allows control data in volatile controller RAM to be quickly reconstructed by scanning a small set of control data in non-volatile memory. This is possible because the present invention limits the number of blocks associated with the expected operation of a given logical group of data. In addition, some of the control data that needs to be persisted is stored in a non-volatile metablock that can be updated sector by sector, and each update that results in a new sector is recorded on behalf of the previous update . A sector indexing scheme is used for control data to track sector-by-sector updates in metablocks.
不揮発性フラッシュメモリ２００は、比較的静的な大量の制御データを記憶する。これには、グループアドレステーブル（ＧＡＴ）２１０と、カオス的ブロックインデックス（ＣＢＩ）２２０と、消去済みブロックリスト（ＥＢＬ）２３０と、ＭＡＰ２４０とが含まれる。ＧＡＴ２１０は、セクタの論理グループと、その対応するメタブロックとの間のマッピングを追跡する。マッピングは、更新を受けるもの以外は変化しない。ＣＢＩ２２０は、更新中の論理的な非順次セクタのマッピングを追跡する。ＥＢＬ２３０は、消去されたメタブロックのプールを追跡する。ＭＡＰ２４０は、フラッシュメモリ内のすべてのメタブロックの消去状態を示すビットマップである。
The
揮発性コントローラＲＡＭ１３０は、頻繁に変化およびアクセスされる制御データの小さな部分を記憶する。これには、割り当てブロックリスト（ＡＢＬ）１３４と、クリア済みブロックリスト（ＣＢＬ）１３６とが含まれる。ＡＢＬ１３４は、更新データを記録するためにメタブロックの割り当てを追跡し、ＣＢＬ１３６は、割り当て解除および消去されたメタブロックを追跡する。好ましい実施形態において、ＲＡＭ１３０は、フラッシュメモリ２００に記憶された制御データについてのキャッシュとしての役割を果たす。
更新ブロックマネージャ
（図２に示されている）更新ブロックマネージャ１５０は、論理グループの更新を扱う。本発明の一態様によれば、更新を受けているセクタの各論理グループには、更新データを記録するために、専用の更新メタブロックが割り当てられる。好ましい実施形態において、論理グループの１つ以上のセクタの任意のセグメントが、更新ブロックに記録されることになる。更新ブロックは、順次順序または非順次（カオス的としても知られる）順序のいずれかで更新データを受信するように管理される。カオス的更新ブロックでは、セクタデータを論理グループ内で任意の順序で更新することができ、また個別のセクタの任意の繰り返しがあってもよい。特に、順次更新ブロックは、いずれのデータセクタの移転の必要なく、カオス的更新ブロックになりえる。カオス的データ更新には、ブロックの所定の割り当ては必要ない。任意の論理アドレスでの非順次書き込みが自動的に対処される。よって、従来技術のシステムとは異なり、論理グループの様々な更新セグメントが論理的な順次順序であってもまたは非順次順序であっても、特殊な処理はない。一般的な更新ブロックは、ホストによって要求された順序で様々なセグメントを記憶するために、単に使用されることになる。例えば、ホストシステムデータまたはシステム制御データがカオス的に更新されがちな場合でも、ホストシステムデータに対応する論理アドレス空間の領域を、ホストユーザデータを伴う領域と別々に扱う必要はない。
Update Block Manager (shown in FIG. 2)
セクタの完全な論理グループのデータは、１つのメタブロック内に論理的な順次順序で記憶されるのが好ましい。このように、記憶された論理セクタに対するインデックスは、予め規定されている。メタブロックが所定の順序で所定の論理グループのすべてのセクタを記憶している場合、これは「変化なし(intact)」といわれる。更新ブロックに関して、更新データを論理的な順次順序で最終的に充填する場合、更新ブロックは、元メタブロックを容易に置換する更新された変化なしのメタブロックとなる。他方、更新ブロックが更新データを、変化なしのブロックとは異なる論理的な順序で充填する場合、更新ブロックは、非順次またはカオス的更新ブロックであり、順序がばらばらのセグメントは、変化なしのブロックと同一の順序で論理グループの更新データが最終的には記憶されるように、さらに処理されなければならない。好ましい場合において、このセグメントは、１つのメタブロック内の論理的な順次順序である。さらなる処理には、元ブロック内の変化していないセクタを伴う更新ブロック内の更新されたセクタを、さらに他の更新メタブロックに統合化することを伴う。統合化された更新ブロックは、その後、論理的な順次順序となり、元ブロックを置換するために使用することができる。何らかの所定の条件下では、統合化処理に先立って、１つ以上のコンパクト化処理がある。コンパクト化処理は、カオス的更新ブロックのセクタを、置換するカオス的更新ブロックに単純に再記録し、同じ論理セクタの以前の更新によって廃止された重複する論理セクタを削除することはない。 Data in complete logical groups of sectors are preferably stored in one metablock in logically sequential order. Thus, the index for the stored logical sector is predefined. If the metablock stores all the sectors of a given logical group in a given order, this is said to be "intact". For the update block, if the update data is finally filled in a logical sequential order, the update block will be an updated unchanged metablock that easily replaces the original metablock. On the other hand, if the update block fills the update data in a logical order different from the block without change, the update block is a non-sequential or chaotic update block and the unordered segments are the block without change The update data of the logical group has to be further processed in order to be finally stored in the same order as. In the preferred case, this segment is a logical sequential order within one metablock. Further processing involves integrating the updated sectors in the update block with the unaltered sectors in the original block into yet another update metablock. The consolidated update block is then in logical sequential order and can be used to replace the original block. Under some predetermined conditions, there is one or more compacting processes prior to the consolidation process. The compacting process simply re-record the sectors of the chaotic update block into the replacing chaotic update block and does not delete duplicate logical sectors that were obsoleted by previous updating of the same logical sector.
更新手法により、複数の更新スレッドを、所定の最大限まで並行して実行することができる。各スレッドは、専用の更新メタブロックを使用して更新を受けている論理グループである。 The update approach allows multiple update threads to be run in parallel, up to a predetermined maximum. Each thread is a logical group that is receiving updates using a dedicated update metablock.
順次データ更新
ある論理グループに属するデータを最初に更新する場合、論理グループの更新データについての更新ブロックとして、メタブロックが専用に割り当てられる。更新ブロックが割り当てられるのは、コマンドがホストから受信されて、既存のメタブロックがそのすべてのセクタを変化なく記憶している論理グループの１つ以上のセクタのセグメントを書き込む場合である。最初のホスト書き込み動作の場合、データの最初のセグメントが更新ブロックに記録される。各ホスト書き込みは連続論理アドレスを伴う１つ以上のセクタのセグメントであるので、最初の更新は、その性質上常に順次的であることとなる。後続のホスト書き込みでは、同一の論理グループ内の更新セグメントが、ホストから受信された順序で更新ブロックに記録される。ブロックは、順次更新ブロックとして管理され続けるのに対し、関連する論理グループ内でホストによって更新されたセクタは、論理的に順次的であり続ける。この論理グループ内で更新されたすべてのセクタは、このブロックが閉鎖されるか、カオス的更新ブロックに変換されるかのいずれかとなるまで、この順次更新ブロックに書き込まれる。
Sequential Data Update When data belonging to a logical group is first updated, a metablock is allocated exclusively as an update block for updated data of the logical group. An update block is assigned when a command is received from the host and the existing metablock writes a segment of one or more sectors of the logical group storing all its sectors unchanged. For the first host write operation, the first segment of data is recorded in the update block. Since each host write is a segment of one or more sectors with consecutive logical addresses, the first update will, by its nature, always be sequential. For subsequent host writes, update segments in the same logical group are recorded in the update block in the order received from the host. Blocks continue to be managed as sequentially updated blocks, while sectors updated by the host in the associated logical group remain logically sequential. All sectors updated in this logical group are written to this sequential update block until either this block is closed or converted to a chaotic update block.
図７Ａは、２つの別個のホスト書き込み動作の結果、順次更新ブロックへ順次順序で書き込まれる論理グループ内のセクタの一例を示し、この論理グループについての元ブロック内の対応するセクタは廃止になる。ホスト書き込み動作＃１において、論理セクタＬＳ５〜ＬＳ８内のデータが更新中である。ＬＳ５’〜ＬＳ８’として更新されたデータは、新規に割り当てられた専用の更新ブロックに記録される。
FIG. 7A shows an example of a sector in a logical group written sequentially to a sequentially updated block as a result of two separate host write operations, and the corresponding sector in the source block for this logical group is obsolete. In host
便宜上、論理グループ内の更新すべき第１のセクタは、第１の物理セクタ位置から開始する専用更新ブロックに記録される。一般的に、更新すべき第１の論理セクタは、必ずしもグループの論理的に第１番目のセクタではないので、論理グループの最初と、更新ブロックの最初との間にはオフセットがあることがある。このオフセットは、図３Ａに関連して前に説明したように、ページタグとして知られている。後続のセクタは、論理的な順次順序で更新される。論理グループの最後のセクタが書き込まれる場合、グループアドレスは折り返して、書き込みシーケンスを、グループの最初のセクタで継続する。 For convenience, the first sector to be updated in the logical group is recorded in a dedicated update block starting from the first physical sector location. Generally, there may be an offset between the beginning of the logical group and the beginning of the update block, as the first logical sector to be updated is not necessarily the logical first sector of the group . This offset is known as a page tag, as described earlier in connection with FIG. 3A. Subsequent sectors are updated in a logical sequential order. If the last sector of the logical group is written, the group address wraps around and the write sequence continues at the first sector of the group.
ホスト書き込み動作＃２において、論理セクタＬＳ９〜ＬＳ１２内のデータのセグメントが更新中である。ＬＳ９’〜ＬＳ１２’として更新されたデータは、専用の更新ブロック内の、最後の書き込みが終了した場所に直接続く位置に記録される。２つのホスト書き込みは、更新データが論理的な順次順序で、すなわち、ＬＳ５’〜ＬＳ１２’のようにして、更新ブロックに記録されたようなものとして理解することができる。更新ブロックが順次更新ブロックとみなされるのは、論理的な順次順序で充填されているからである。更新ブロックに記録された更新データによって、元ブロック内の対応するデータが廃止される。
In host
カオス的データ更新
カオス的更新ブロック管理は、関連論理グループ内でホストによって更新された任意のセクタが論理的に非順次の場合に、既存の順次更新ブロックについて開始される。カオス的更新ブロックは、関連する論理グループ内の論理セクタが任意の順序でかつ任意の繰り返し量で更新されてもよいようなデータ更新ブロックの形式を取る。これは、ホストによって書き込まれたセクタが、更新中の論理グループ内の以前書き込んだセクタに対して論理的に非順次である場合に、順次更新ブロックからの変換によって作成される。この論理グループ内のその後の更新されたすべてのセクタは、グループ内の論理セクタアドレスが何であれ、カオス的更新ブロック内の次に使用可能なセクタ位置に書き込まれる。
Chaotic Data Update Chaotic Update Block Management is initiated for existing sequential update blocks if any sector updated by the host in the associated logical group is logically non-sequential. The chaotic update block takes the form of a data update block such that logical sectors within the associated logical group may be updated in any order and with any repeat amount. This is created by conversion from a sequential update block if the sector written by the host is logically non-sequential to previously written sectors in the logical group being updated. All subsequent updated sectors in this logical group are written to the next available sector location in the chaotic update block, whatever the logical sector address in the group.
図７Ｂは、５つの別個のホスト書き込み動作の結果、カオス的更新ブロックへカオス的順序で書き込まれる論理グループ内のセクタの一例を示し、この論理グループについての元ブロック内の取り替えられたセクタと、カオス的更新ブロック内の複製セクタとは廃止になる。ホスト書き込み動作＃１において、元メタブロックに記憶されている所定の論理グループの論理セクタＬＳ１０〜ＬＳ１１が更新される。更新された論理セクタＬＳ１０’〜ＬＳ１１’は、新規に割り当てられた更新ブロックに記憶される。この点で、更新ブロックは、順次的である。ホスト書き込み動作＃２において、論理セクタＬＳ５〜ＬＳ６がＬＳ５’〜ＬＳ６’に更新されて、更新ブロック内の最終の書き込みに直接続く位置に記録される。これにより、更新ブロックは、順次的からカオス的なものへと変換される。ホスト書き込み動作＃３において、論理セクタＬＳ１０が再び更新中であり、更新ブロックの次の位置にＬＳ１０’’として記録される。この点で、更新ブロック内のＬＳ１０’’は、元ブロック内のＬＳ１０に取って代わる以前の記録内のＬＳ１０’に取って代わる。ホスト書き込み動作＃４において、論理セクタＬＳ１０内のデータは再び更新されて、更新ブロックの次の位置にＬＳ１０’’’として記録される。よって、ＬＳ１０’’’が、論理セクタＬＳ１０についての現在における最新かつ唯一の有効データとなる。ホスト書き込み動作＃５において、論理セクタＬＳ３０内のデータが更新中であり、更新ブロックにＬＳ３０’として記録される。よって、この例は、任意の順序および任意の繰り返しによって、論理グループ内のセクタをカオス的更新ブロックに書き込むことができることを示す。
FIG. 7B shows an example of a sector in a logical group written in chaotic order to a chaotic update block as a result of five separate host write operations, with the replaced sector in the original block for this logical group; The duplicate sectors in the chaotic update block are obsolete. In host
強制的順次更新
図８は、２つの別個のホスト書き込み動作の結果としての、論理アドレスに不連続性を有する、順次更新ブロックへ順次順序で書き込まれる論理グループ内のセクタの一例を示す。ホスト書き込み＃１において、論理セクタＬＳ５〜ＬＳ８における更新データは、ＬＳ５’〜ＬＳ８’として専用の更新ブロック内に記録される。ホスト書き込み＃２において、論理セクタＬＳ１４〜ＬＳ１６における更新データは、最終の書き込みに続く更新ブロック内にＬＳ１４’〜ＬＳ１６’として記録されている。しかし、ＬＳ８とＬＳ１４との間にアドレスジャンプがあり、ホスト書き込み＃２は、通常、更新ブロックを非順次的にすることになる。アドレスジャンプは重要ではないので、１つのオプションとしては、ホスト書き込み＃２を実行する前に、介在セクタのデータを元ブロックから更新ブロックへコピーすることによってパディング動作（＃２Ａ）をまず行うというものである。このように、更新ブロックの順次的性質が維持される。
Forced Sequential Update FIG. 8 illustrates an example of sectors within a logical group that are sequentially written into sequential update blocks with discontinuities in logical addresses as a result of two separate host write operations. In
図９は、本発明の一般的な一実施形態に係る、データの論理グループを更新するための更新ブロックマネージャによる処理を示すフロー図である。更新処理は、以下のステップを含む。
ステップ２６０：メモリはブロックに組織化され、各ブロックは共に消去可能なメモリユニットに分割され、各メモリユニットは、データの論理ユニットを記憶するためのものである。
ステップ２６２：データは論理グループに組織化され、各論理グループは、論理ユニットに分割される。
ステップ２６４：標準的な場合、論理グループのすべての論理ユニットは、第１の所定の順序、好ましくは論理的な順次順序に従って、元ブロックのメモリユニットに記憶される。このように、ブロック内の個々の論理ユニットをアクセスするためのインデックスがわかる。
ステップ２７０：データの所定の論理グループ（例えば、ＬＧx ）について、ＬＧx 内で論理ユニットを更新するための要求が行われる（一例として、論理ユニット更新が挙げられる。一般的には、更新は、ＬＧx 内の１つ以上の連続論理ユニットのセグメントとなる）。
ステップ２７２：要求された更新論理ユニットが、ＬＧx の更新の記録専用の第２のブロックに記憶されることになる。記録順序は、第２の順序であり、典型的には、更新が要求された順序に従う。本発明の一特徴は、論理的な順次またはカオス的順序でデータを記録するように、更新ブロックを最初に一般的に設定することができるようにする。第２の順序によっては、第２のブロックは、順次的なものである場合も、カオス的なものである場合もある。
ステップ２７４：処理がステップ２７０にループバックするにつれて、第２のブロックは、論理ユニットが記録されるように要求し続ける。閉鎖のための所定の条件が具体化すると、第２のブロックは閉鎖されて、さらなる更新を受信しなくなる。この場合、処理は２７６へ進む。
ステップ２７６：閉鎖された第２のブロックが元ブロックと同様の順序でその更新論理ユニットを記録しているかどうかについて決定が行われる。図３Ａに関して説明したように、ページタグ分だけ異なる論理ユニットを記録している場合には、２つのブロックは同様の順序であるとみなされる。２つのブロックが同様の順序である場合は、処理はステップ２８０へ進み、そうでなければ、ステップ２９０において、何らかのガーベッジコレクションを行う必要がある。
ステップ２８０：第２のブロックは第１のブロックと同一の順序なので、第２のブロックは、元ブロックである第１のブロックを置換するために使用される。更新処理は、その後、ステップ２９９で終了する。
ステップ２９０：所定の論理グループの各論理ユニットの最新バージョンが、第２のブロック（更新ブロック）および第１のブロック（元ブロック）から収集される。所定の論理グループの統合化された論理ユニットは、その後、第１のブロックと同様の順序で第３のブロックに書き込まれる。
ステップ２９２：第３のブロック（統合化されたブロック）は第１のブロックと同様の順序であるので、第３のブロックは、元ブロックである第１のブロックを置換するために使用される。更新処理は、その後、ステップ２９９で終了する。
ステップ２９９：閉鎖処理によって変化のない更新ブロックが作成されると、これが所定の論理グループにとっての新規の標準ブロックとなる。論理グループについての更新スレッドは終了される。
FIG. 9 is a flow diagram that illustrates the processing by the update block manager to update logical groups of data according to a general embodiment of the present invention. The update process includes the following steps.
STEP 260: The memory is organized into blocks, each block being divided together into erasable memory units, each memory unit being for storing a logical unit of data.
STEP 262: Data is organized into logical groups, and each logical group is divided into logical units.
Step 264: In the standard case, all logical units of the logical group are stored in the memory unit of the original block according to a first predetermined order, preferably in a logical sequential order. In this way, an index for accessing individual logical units in a block is known.
Step 270: For a given logical group of data (e.g. LG x ), a request is made to update the logical unit within LG x (an example is logical unit update, in general updating is , LG x will be segments of one or more consecutive logical units).
Step 272: The requested update logic unit will be stored in a second block dedicated to recording LG x updates. The recording order is a second order and typically follows the order in which the update is requested. One feature of the present invention allows an update block to be generally initially configured to record data in a logical sequential or chaotic order. Depending on the second order, the second block may be sequential or chaotic.
Step 274: As processing loops back to step 270, the second block continues to request that the logical unit be recorded. When the predetermined condition for closing takes effect, the second block is closed and no further updates are received. In this case, processing proceeds to 276.
Step 276: A determination is made as to whether the closed second block is recording its update logical units in the same order as the original block. As described with respect to FIG. 3A, two blocks are considered to be in the same order when recording logical units that differ by page tags. If the two blocks are in the same order, processing proceeds to step 280, otherwise some garbage collection needs to be done at
Step 280: Since the second block is in the same order as the first block, the second block is used to replace the first block which is the original block. The update process then ends in
Step 290: The latest version of each logical unit of a given logical group is collected from the second block (update block) and the first block (original block). The integrated logical units of the predetermined logical group are then written to the third block in the same order as the first block.
Step 292: Since the third block (integrated block) is in the same order as the first block, the third block is used to replace the first block which is the original block. The update process then ends in
Step 299: If an update block without change is created by the closing process, this becomes a new standard block for a predetermined logical group. The update thread for logical groups is terminated.
図１０は、本発明の好ましい実施形態に係る、データの論理グループを更新するための更新ブロックマネージャによる処理を示すフロー図である。更新処理は、以下のステップを含む。
ステップ３１０：データの所定の論理グループ（例えば、ＬＧx ）について、ＬＧx 内で論理セクタを更新するための要求が行われる（一例として、セクタ更新が挙げられる。一般的には、更新は、ＬＧx 内の１つ以上の連続論理セクタのセグメントととなる）。
ステップ３１２：ＬＧx に専用の更新ブロックがまだ存在しない場合、ステップ４１０へ進み、論理グループについて新規の更新スレッドを開始する。これは、論理グループの更新データを記録するのに専用の更新ブロックを割り当てることによって達成されることになる。開放されている更新ブロックが既にあれば、ステップ３１４へ進み、更新ブロックに対する更新セクタの記録を開始する。
ステップ３１４：現在の更新ブロックが既にカオス的（すなわち、非順次的）である場合には、そのままステップ５１０へ進み、要求された更新セクタをカオス的更新ブロックに記録する。現在の更新ブロックが順次的である場合、ステップ３１６へ進み、順次更新ブロックの処理を行う。
ステップ３１６：本発明の一特徴は、論理的な順次またはカオス的順序でデータを記録するように、更新ブロックを最初に一般的に設定することができるようにする。しかし、論理グループは、最終的にはそのデータを論理的な順次順序でメタブロックに記憶させるので、更新ブロックをできるだけ順次的に維持するのが望ましい。そうすれば、更新ブロックが閉鎖されてさらなる更新ができなくなった場合、ガーベッジコレクションは必要ないので、必要とされる処理が少なくなる。
FIG. 10 is a flow diagram illustrating the processing by the update block manager to update logical groups of data according to a preferred embodiment of the present invention. The update process includes the following steps.
Step 310: For a given logical group of data (eg, LG x ), a request is made to update the logical sector within LG x (an example is sector update. Generally, the update is It becomes a segment of one or more consecutive logical sectors in LG x ).
Step 312: If there is not a dedicated update block in LG x yet, go to step 410 and start a new update thread for the logical group. This will be achieved by allocating a dedicated update block to record the logical group's update data. If there is already an open update block, the process proceeds to step 314 to start recording the update sector for the update block.
Step 314: If the current update block is already chaotic (ie non-sequential), proceed directly to step 510 and record the requested update sector in the chaotic update block. If the current update block is sequential, proceed to step 316 to process the sequential update block.
Step 316: One feature of the present invention allows the update block to be generally configured initially to record data in a logical sequential or chaotic order. However, since logical groups will eventually store their data in the metablock in a logical sequential order, it is desirable to maintain update blocks as sequentially as possible. Then, if the update block is closed and can not be updated further, garbage collection is not required and less processing is required.
要求された更新が更新ブロックの現在の順次順序に従うかどうかについての決定がなされる。更新が順次的に従う場合、ステップ５１０へ進み、順次更新が行われ、更新ブロックは順次的なままである。他方、更新が順次的に従わない（カオス的更新の）場合、他の動作が行われないならば、順次更新ブロックをカオス的なものに変換する。
一実施形態において、状況を守るためにこれ以上何もせず、処理は直接ステップ３７０へ進み、更新ブロックをカオス的なものにする更新が許容される。
A determination is made as to whether the requested update follows the current sequential order of update blocks. If the updates follow sequentially, then proceed to step 510 where sequential updates are performed and the update blocks remain sequential. On the other hand, if the update does not follow sequentially (of chaotic update), then the sequential update block is converted to chaotic if no other action is taken.
In one embodiment, nothing more is done to protect the situation and the process proceeds directly to step 370 where an update is allowed that makes the update block chaotic.
オプションの強制的順次処理
他の実施形態において、強制的順次処理ステップ３２０が、保留中のカオス的更新の観点から順次更新ブロックをできるだけ保存するためにオプションとして行われる。２つの状況があり、どちらも、欠落したセクタを元ブロックからコピーして、更新ブロック上に記録された論理セクタの順次順序を維持するものである。第１の状況は、更新によって短いアドレスジャンプが生じることである。第２の状況は、更新ブロックを順次的に保つために、更新ブロックを早く閉鎖することである。強制的順次処理ステップ３２０は、以下のサブステップを含む。
ステップ３３０：更新によって、所定の量ＣB より大きい論理アドレスジャンプが生じる場合、処理はステップ３５０の強制的順次更新処理へと進み、そうでなければ、処理はステップ３４０へと進んで、強制的順次閉鎖の資格があるかどうかの検討を行う。
ステップ３４０：充填されていない物理セクタ数が、更新ブロックのサイズの半分が典型的な値である所定の設定パラメータＣC を超える場合、更新ブロックは、比較的使用されず、早く閉鎖されることはない。処理はステップ３７０へ進み、更新ブロックは、カオス的となる。他方、更新ブロックがおおむね充填されている場合、既に十分に使っているとみなされるので、ステップ３６０へと進み、強制的順次閉鎖となる。
ステップ３５０：強制的順次更新により、現在の順次更新ブロックを、アドレスジャンプが所定量ＣB を超えない限り順次的なままとすることができる。基本的には、更新ブロックの関連する元ブロックからのセクタがコピーされて、アドレスジャンプによるギャップを埋める。よって、順次更新ブロックは、ステップ５１０へ進んで現在の更新を順次記録する前に、介在アドレス内のデータで埋められることになる。
ステップ３６０：強制的順次閉鎖により、現在の順次的な更新ブロックを、カオス的なものに変換するよりも保留中のカオス的更新によって既におおむね充填されていれば、閉鎖することができる。カオス的または非順次更新は、前述したアドレスジャンプ例外、逆方向アドレス遷移、またはアドレス反復の対象ではなく、順方向アドレス遷移を伴うものとして規定される。順次更新ブロックがカオス的更新によって変換されるのを防止するために、更新ブロックの未書き込みのセクタ位置が、更新ブロックの関連した元の部分的に廃止されたブロックからセクタをコピーすることによって充填される。元ブロックは、その後完全に廃止されて、消去することができる。現在の更新ブロックは、現在では、フルセットの論理セクタを有するので、元メタブロックを置き換える変化のないメタブロックとして閉鎖される。処理は、ステップ４３０へと進み、ステップ３１０において最初に要求された保留中のセクタ更新の記録を受け付けるために、新規の更新ブロックをその位置に割り当てる。
Optional Forced Sequential Processing In another embodiment, a forced
Step 330: the update, if the predetermined amount C B is greater than the logical address jump occurs, the process proceeds to forced sequential update process in
Step 340: If the number of unfilled physical sectors exceeds a predetermined configuration parameter C C where half the size of the update block is a typical value, the update block is relatively unused and closed early There is no. Processing proceeds to step 370 where the update block is chaotic. On the other hand, if the update block is generally filled, it is assumed that it has already been fully used, and so the process proceeds to step 360 where it is forced to close sequentially.
Step 350: the forced sequential update, the current sequential update block address jump may be as long remain sequential not exceeding a predetermined amount C B. Basically, the sectors from the associated original block of the update block are copied to fill the gap due to the address jump. Thus, the sequential update block will be filled with data in the intervening address before proceeding to step 510 to sequentially record the current update.
Step 360: Forced sequential closure allows the current sequential update block to be closed if it is already roughly filled by the pending chaotic update rather than being converted to a chaotic one. Chaotic or non-sequential updates are defined as with forward address transitions, rather than subject to the address jump exceptions, backward address transitions, or address iterations described above. To prevent sequential update blocks from being converted by chaotic updates, the unwritten sector locations of the update block are filled by copying sectors from the associated original partially obsolete block of the update block Be done. The original block is then completely abolished and can be erased. Since the current update block now has a full set of logical sectors, it is closed as an unchanged metablock replacing the original metablock. Processing proceeds to step 430, where a new update block is assigned to that location to receive a record of the pending sector update originally requested in
カオス的更新ブロックへの変換
ステップ３７０：保留中の更新が順次順序でなく、オプションとして、強制的順次条件が満たされていない場合、処理がステップ５１０へ進むときに非順次アドレスを有する保留中の更新セクタが更新ブロックへ記録されるようにするために、順次更新ブロックは、カオス的なものに変換されることが許容される。カオス的更新ブロックの最大数が存在する場合に、変換が進む前に、最近最もアクセスされていないカオス的更新ブロックを閉鎖する必要がある。よって、カオス的更新ブロックの最大数が超えないようにする。最近最もアクセスされていないカオス的更新ブロックの識別は、ステップ４２０において説明した一般的な場合と同一であるが、カオス的更新ブロックだけに制約される。このときにカオス的更新ブロックを閉鎖することは、ステップ５５０において説明したような統合化によって達成される。
Convert to a chaotic update block step 370: pending updates are not in sequential order, and optionally, if the forced sequential condition is not met, pending processing with non-sequential addresses as processing proceeds to step 510 In order for update sectors to be recorded to update blocks, sequential update blocks are allowed to be transformed into chaotic ones. If there is a maximum number of chaotic update blocks, it is necessary to close the least recently accessed chaotic update block before the transformation proceeds. Thus, the maximum number of chaotic update blocks is not exceeded. The identification of the least recently accessed chaotic update block is identical to the general case described in
システム制約を受ける新規の更新ブロックの割り当て
ステップ４１０：消去メタブロックを更新ブロックとして割り当てる処理は、所定のシステム制約が超えているかどうかを判断することから開始する。リソースは有限であるため、メモリ管理システムは、典型的には、更新ブロックの所定の最大数ＵMAX が並行して存在することを許容する。この制限は、順次更新ブロックとカオス的更新ブロックとの総計であり、設計パラメータである。好ましい実施形態において、この制限は、例えば、最大８つの更新ブロックである。また、システムリソースに対するさらなる高い需要により、並行して開放されているカオス的更新ブロックの最大数に対する対応する所定の制限があってもよい（例えば、４つ）。
よって、ＵMAX 個の更新ブロックが既に割り当てられていれば、次の割り当て要求は、既存の割り当てられたものの１つが閉鎖された後にはじめて満足することができるようになる。処理はステップ４２０へ進む。開放更新ブロックの数がＣA を下回る場合には、処理は直接ステップ４３０へ進む。
Assigning a New Update Block Subject to System Constraints Step 410: The process of assigning an erasure metablock as an update block begins with determining whether a predetermined system constraint has been exceeded. Because resources are finite, memory management systems typically allow for a predetermined maximum number U MAX of update blocks to exist in parallel. This limitation is the sum of sequential update blocks and chaotic update blocks and is a design parameter. In the preferred embodiment, this limit is, for example, up to eight update blocks. Also, due to the higher demand for system resources, there may be a corresponding predetermined limit on the maximum number of chaotic update blocks being opened in parallel (e.g. four).
Thus, if U MAX update blocks have already been allocated, the next allocation request can only be satisfied after one of the existing allocations has been closed. Processing proceeds to step 420. If the number of open update blocks is less than C A , processing proceeds directly to step 430.
ステップ４２０：更新ブロックＣA の最大数を超える場合には、最近最もアクセスされていない更新ブロックが閉鎖されて、ガーベッジコレクションが行われる。最近最もアクセスされていない更新ブロックは、最近最もアクセスされていない論理ブロックに関連した更新ブロックとして識別される。最近最もアクセスされていないブロックを決定する目的で、アクセスは、論理セクタの書き込みと、オプションで読み出しとを含む。開放更新ブロックのリストが、アクセス順に保持され、初期化の際には、アクセス順序は何ら想定されていない。更新ブロックの閉鎖は、更新ブロックが順次的な場合のステップ３６０および５３０、ならびに更新ブロックがカオス的な場合のステップ５４０に関連して説明したのと同様の処理に従う。閉鎖により、ステップ４３０において新規の更新ブロックを割り当てる空間ができる。
ステップ４３０：割り当て要求は、新規のメタブロックを所定の論理グループＬＧx に専用の更新ブロックとして割り当てることで満足される。その後、処理はステップ５１０へ進む。
Step 420: If the maximum number of update blocks C A is exceeded, the least recently accessed update block is closed and garbage collection is performed. The least recently accessed update block is identified as the update block associated with the least recently accessed logical block. In order to determine the least recently accessed block, accesses include writing of logical sectors and optionally reading. A list of open update blocks is held in access order, and upon initialization, no access order is assumed. The closing of the update block follows the same process as described in connection with
Step 430: allocation request is satisfied by assigning as an update block dedicated to the new metablock in the given logical group LG x. Thereafter, the process proceeds to step 510.
更新データの更新ブロックへの記録
ステップ５１０：要求された更新セクタは、更新ブロックの次に使用可能な物理位置上に記録される。その後、処理はステップ５２０へ進み、更新ブロックを閉鎖する機が熟したかどうかが判断される。
Record update data in update block 510: The requested update sector is recorded on the next available physical location of the update block. Thereafter, the process proceeds to step 520 where it is determined if the opportunity to close the update block is mature.
更新ブロックの閉鎖
ステップ５２０：さらなる更新を受け付けるための空間が更新ブロックにまだある場合には、ステップ５７０へ進む。そうでない場合には、ステップ５２２へ進み、更新ブロックを閉鎖する。現在の要求された書き込みが、ブロックが有する空間よりも多くの論理セクタを書き込もうとするものである場合に、更新ブロックを満たす実装例として２つのものがある。第１の実装例において、書き込み要求は２つの部分に分割され、第１の部分がブロックの最終物理セクタまで書き込む。その後、ブロックは閉鎖され、書き込みの第２の部分が、次に要求された書き込みとして扱われることになる。他方の実装例において、要求された書き込みは、ブロックが残りのセクタが埋め込まれて閉鎖されている間は保留される。要求された書き込みは、次に要求された書き込みとして扱われることになる。
ステップ５２２：更新ブロックが順次的であれば、ステップ５３０へと進み、順次閉鎖となる。更新ブロックがカオス的であれば、ステップ５４０へと進み、カオス的閉鎖となる。
Update block closing step 520: If there is still space in the update block to receive further updates, then go to step 570. If not, proceed to step 522 and close the update block. If the current requested write is to write more logical sectors than the block has space, there are two example implementations that satisfy the update block. In a first implementation, the write request is split into two parts, the first part writing to the last physical sector of the block. The block is then closed and the second part of the write will be treated as the next requested write. In the other implementation, the requested write is suspended while the block is embedded with the remaining sectors closed. The requested write will be treated as the next requested write.
Step 522: If the update block is sequential, proceed to step 530 and sequentially close. If the update block is chaotic, proceed to step 540, which results in a chaotic closure.
順次更新ブロックの閉鎖
ステップ５３０：更新ブロックが順次的かつ満杯であるので、そこに記憶された論理グループには変化がない。メタブロックは変化がなく、元のものを置換する。このとき、元ブロックは完全に廃止され、消去されてもよい。その後、処理はステップ５７０へと進み、所定の論理グループに対する更新スレッドは終了する。
Closing
カオス的更新ブロックの閉鎖
ステップ５４０：更新ブロックは非順次的に充填され、いくつかの論理セクタの複数の更新を含む場合もあるので、ガーベッジコレクションが行われて、内部の有効なデータを救い出す。カオス的更新ブロックは、コンパクト化または統合化のいずれかが行われることになる。どちらの処理を行うかは、ステップ５４２において決定される。
ステップ５４２：コンパクト化を行うか、または統合化を行うかは、更新ブロックの重なり具合に依存する。論理セクタが複数回更新されていれば、その論理アドレスは非常に重なっている。更新ブロックに記録された同一の論理セクタの複数のバージョンがあることになり、最後に記録されたバージョンのみが、この論理セクタについて有効なものである。複数のバージョンを有する論理セクタを含む更新ブロックにおいて、別個の論理セクタの数は、論理グループの数よりはるかに少ないことになる。
Chaotic update block closing step 540: Because the update block is filled non-sequentially and may include multiple updates of several logical sectors, garbage collection is performed to salvage internal valid data. Chaotic update blocks will either be compacted or integrated. Which process to perform is determined in
Step 542: Whether to compact or integrate depends on how the update blocks overlap. If a logical sector has been updated multiple times, its logical addresses are very overlapping. There will be multiple versions of the same logical sector recorded in the update block, and only the last recorded version is valid for this logical sector. In an update block that includes logical sectors having multiple versions, the number of distinct logical sectors will be much smaller than the number of logical groups.
好ましい実施形態において、更新ブロック内の別個の論理セクタの数が、論理グループの大きさの半分が典型的な値である所定の設計パラメータＣD を超える場合には、閉鎖処理はステップ５５０において統合化を行い、そうでなければ、処理はステップ５６０においてコンパクト化を行う。
ステップ５５０：カオス的更新ブロックが統合化されることになる場合、元ブロックと更新ブロックとが、統合化されたデータを含む新規の標準メタブロックに置換されることになる。統合化後、更新スレッドはステップ５７０において終了する。
ステップ５６０：カオス的更新ブロックがコンパクト化されることになる場合、コンパクト化されたデータを保持する新規の更新ブロックに置換されることになる。コンパクト化後、コンパクト化された更新ブロックの処理は、ステップ５７０において終了する。代わりに、更新ブロックが再び書き込まれるまで、コンパクト化を遅らせることもでき、これにより、介在する更新がないのに統合化に続いてコンパクト化が生じる可能性を排除する。新規の更新ブロックは、その後、ＬＧx における更新への次の要求がステップ５０２において生じるときに、所定の論理ブロックのさらなる更新を行う際に使用されることになる。
ステップ５７０：閉鎖処理によって変化のない更新ブロックが作成される場合には、それが所定の論理グループの新規の標準ブロックになる。この論理グループの更新スレッドは終了することになる。閉鎖処理によって既存のものを置換する新規の更新ブロックが作成される場合には、この新規の更新ブロックは、所定の論理グループに対して要求される次の更新を記録するために使用されることになる。更新ブロックが閉鎖されない場合には、処理は、ＬＧx 内の更新に対する次の要求がステップ３１０に生じる場合に継続する。
In the preferred embodiment, the closing process is integrated at
Step 550: If the chaotic update block is to be integrated, the original block and the update block will be replaced with a new standard metablock that contains integrated data. After consolidation, the update thread ends at
Step 560: If the chaotic update block is to be compacted, it will be replaced by a new update block that holds compacted data. After compacting, processing of the compacted update block ends at
Step 570: If the closing process creates an unchanged update block, it becomes a new standard block of the given logical group. The update thread for this logical group will end. If a new update block is created which replaces the existing one by the closing process, this new update block is used to record the next update required for the given logical group become. If the update block is not closed, processing continues if the next request for update in LG x occurs at
前述した処理からわかるように、カオス的更新ブロックが閉鎖される場合には、そこに記録された更新データがさらに処理される。特に、その有効データに対しては、他のカオス的ブロックへコンパクト化する処理か、またはその関連する元ブロックに統合化して新たな標準順次ブロックを形成する処理によって、ガーベッジコレクションが行われる。 As can be seen from the process described above, if the chaotic update block is closed, then the update data recorded there is further processed. In particular, garbage collection is performed on the effective data by a process of compacting into other chaotic blocks or by a process of integrating into other associated original blocks to form a new standard sequential block.
図１１Ａは、図１０に示されているカオス的更新ブロックを閉鎖する統合化処理をより詳細に示すフロー図である。カオス的更新ブロックの統合化は、更新ブロックが閉鎖されている場合、例えば、更新ブロックが最終物理セクタ位置に書き込みがなされた状態で一杯である場合に行われる、２つの予想される処理のうちの１つである。統合化は、ブロックに書き込まれた別個の論理セクタの数が所定の設計パラメータＣD を超える場合に選ばれる。図１０に示されている統合化処理ステップ５５０は、以下のサブステップを備える。
ステップ５５１：カオス的更新ブロックが閉鎖されている場合に、それを置換する新規のメタブロックが割り当てられることになる。
ステップ５５２：廃止されたセクタはすべて無視して、カオス的更新ブロックおよびその関連する元ブロック内の各論理セクタの最新バージョンを収集する。
ステップ５５４：収集された有効なセクタを新規のメタブロックに論理的な順次順序で記録して、変化のないブロック、すなわち、論理グループのすべての論理セクタが順次順序で記録されているブロックを形成する。
ステップ５５６：元ブロックを新規の変化のないブロックに置換する。
ステップ５５８：閉鎖された更新ブロックおよび元ブロックを消去する。
FIG. 11A is a flow diagram showing in more detail the consolidation process of closing the chaotic update block shown in FIG. The consolidation of the chaotic update block is performed out of two possible processes which occur when the update block is closed, for example when the update block is full written to the last physical sector location. It is one of the Integration is chosen when the number of distinct logical sectors written in the block exceeds a predetermined design parameter C D. The
Step 551: If the chaotic update block is closed, a new metablock will be assigned to replace it.
Step 552: Ignore all obsolete sectors and collect the latest version of each logical sector in the chaotic update block and its associated original block.
Step 554: Record the collected valid sectors in a new metablock in a logical sequential order to form a block without change, ie a block in which all logical sectors of the logical group are recorded in sequential order Do.
Step 556: Replace the original block with a new unchanged block.
Step 558: Erase the closed update block and the original block.
図１１Ｂは、図１０に示されているカオス的更新ブロックを閉鎖するためのコンパクト化処理をより詳細に示すフロー図である。コンパクト化は、ブロック内の別個の論理セクタの数が所定の設計パラメータＣD を下回る場合に選ばれる。図１０に示されているコンパクト化処理ステップ５６０は、以下のサブステップを備える。
ステップ５６１：カオス的更新ブロックがコンパクト化されている最中に、それを置換する新規のメタブロックが割り当てられる。
ステップ５６２：コンパクト化されるべき既存のカオス的更新ブロック内の各論理セクタの最新バージョンを収集する。
ステップ５６４：収集されたセクタを新規更新ブロックに記録して、コンパクト化されたセクタを有する新規の更新ブロックを形成する。
ステップ５６６：既存の更新ブロックをコンパクト化されたセクタを有する新規の更新ブロックに置換する。
ステップ５６８：閉鎖された更新ブロックを消去する。
11B is a flow diagram showing in more detail the compaction process for closing the chaotic update block shown in FIG. Compaction is chosen when the number of distinct logical sectors in the block is below a predetermined design parameter C D. The compacting
Step 561: While the chaotic update block is compacted, a new metablock is assigned to replace it.
Step 562: Gather the latest version of each logical sector in the existing chaotic update block to be compacted.
STEP 564: Record the collected sectors in a new update block to form a new update block with compacted sectors.
Step 566: Replace the existing update block with a new update block having a compacted sector.
Step 568: Erase the closed update block.
論理およびメタブロック状態
図１２Ａは、様々な動作下における、論理グループの予想されるすべての状態と、その状態間で予想される遷移とを示す。
図１２Ｂは、論理グループの予想される状態を列挙する表である。論理グループの状態は、以下のように規定される。
１．変化なし：論理グループ内のすべての論理セクタが、論理的な順次順序で、ページタグ折り返しなどを使用して、１つのメタブロックに書き込まれている。
２．未書き込み：論理グループ内の論理セクタが全く書き込まれていない。論理グループは、グループアドレステーブルにおいて未書き込みとして印付けされ、割り当てられたメタブロックはない。このグループ内のすべてのセクタに対するホスト読み出しに応答して、予め定められたデータパターンが返される。
３．順次更新：論理グループ内のいくつかのセクタが、論理的な順次順序で、ページタグなどを使用してメタブロックに書き込まれ、これらのセクタによって、このグループの以前の変化なしの状態から対応する論理セクタが置換される。
４．カオス的更新：論理グループ内のいくつかのセクタが、論理的な非順次順序で、ページタグなどを使用してメタブロックに書き込まれ、これらのセクタによって、このグループの以前の変化なしの状態から対応する論理セクタが置換される。グループ内のセクタは、１回より多く書き込まれてもよく、最新のバージョンが、以前のすべてのバージョンを置換することになる。
Logic and Metablock State Diagram 12A shows all the possible states of a logical group and the expected transitions between them under various operations.
FIG. 12B is a table listing the expected states of the logical group. The states of logical groups are defined as follows.
1. No change: All logical sectors in the logical group are written in one metablock, using page tag wrap etc, in logical sequential order.
2. Not written: No logical sector in the logical group has been written. Logical groups are marked as unwritten in the group address table and there are no metablocks assigned. In response to host reads for all sectors in this group, a predetermined data pattern is returned.
3. Sequential update: Several sectors in a logical group are written to the metablock using page tags etc. in logical sequential order, and these sectors correspond to the previous unaltered state of this group Logical sectors are replaced.
4. Chaotic update: Several sectors in a logical group are written to the metablock using page tags etc, in logical non-sequential order, and these sectors allow the previous unaltered state of this group The corresponding logical sector is replaced. Sectors in the group may be written more than once, and the latest version will replace all previous versions.
図１３Ａは、様々な動作下における、メタブロックの予想されるすべての状態と、その状態間で予想される遷移とを示す。
図１３Ｂは、メタブロックの予想される状態を列挙する表である。メタブロックの状態は、以下のように規定される。
１．消去済み：メタブロック内のすべてのセクタは消去される。
２．順次更新：メタブロックには、セクタが論理的な順次順序でページタグなどを使用して部分的に書き込まれている。すべてのセクタは、同一の論理グループに属する。
３．カオス的更新：メタブロックには、セクタが論理的な非順次順序で部分的または一杯に書き込まれている。任意のセクタは１回より多く書き込むことができる。すべてのセクタは、同一の論理グループに属する。
４．変化なし：メタブロックは、論理的な順次順序でページタグなどを使用して一杯に書き込まれている。
５．オリジナル：メタブロックは、以前は変化なしであったが、少なくとも１つのセクタがホストデータ更新によって廃止されている。
FIG. 13A shows all possible states of the metablock and the expected transitions between the states under various operations.
FIG. 13B is a table listing the expected states of the metablock. The state of the metablock is defined as follows.
1. Erased: All sectors in the metablock are erased.
2. Sequential Update: In the metablock, sectors are partially written using page tags etc. in logical sequential order. All sectors belong to the same logical group.
3. Chaotic Update: In a metablock, sectors are written partially or fully in logical non-sequential order. Any sector can be written more than once. All sectors belong to the same logical group.
4. No change: Metablocks are completely written using page tags etc. in logical sequential order.
5. Original: The metablock was previously unchanged, but at least one sector has been obsoleted by host data updates.
図１４（Ａ）〜１４（Ｊ）は、論理グループの状態と、物理メタブロックとに対する様々な動作の効果を示す状態図である。
図１４（Ａ）は、第１の書き込み動作についての論理グループおよびメタブロック遷移に対応する状態図である。ホストは、依然未書き込みの論理グループの１つ以上のセクタを、新規に割り当てられた消去済みメタブロックに、論理的な順次順序で書き込む。論理グループおよびメタブロックは、順次更新状態になる。
図１４（Ｂ）は、第１の変化なし動作についての論理グループおよびメタブロック遷移に対応する状態図である。以前に未書き込みだった順次更新論理グループは、すべてのセクタが順次的にホストによって書き込まれると、変化なしとなる。この遷移は、カードが残りの未書き込みのセクタを予め定められたデータパターンで埋めることによって、グループを充填する場合も生じうる。メタブロックは変化なしとなる。
図１４（Ｃ）は、第１のカオス的動作についての論理グループおよびメタブロック遷移に対応する状態図である。以前に未書き込みだった順次更新論理グループは、少なくとも１つのセクタが非順次的にホストによって書き込まれると、カオス的となる。
図１４（Ｄ）は、最初のコンパクト化動作についての論理グループおよびメタブロック遷移に対応する状態図である。以前に未書き込みだったカオス的更新論理グループ内のすべての有効なセクタが、旧ブロックから新規のカオス的メタブロックへコピーされ、旧ブロックは、その後消去される。
図１４（Ｅ）は、最初の統合化動作についての論理グループおよびメタブロック遷移に対応する状態図である。以前に未書き込みだったカオス的更新論理グループ内のすべての有効なセクタが、旧カオス的ブロックから移動されて、新規に割り当てられたブロックに論理的な順次順序で充填される。ホストによって書き込みされていないセクタには、予め定められたデータパターンが充填される。旧カオス的ブロックは、その後消去される。
14 (A) -14 (J) are state diagrams showing the effects of various operations on the states of logical groups and physical metablocks.
FIG. 14A is a state diagram corresponding to logical group and metablock transitions for the first write operation. The host writes one or more sectors of the still unwritten logical group to the newly allocated erased metablock in a logical sequential order. Logical groups and metablocks are sequentially updated.
FIG. 14 (B) is a state diagram corresponding to the logical group and metablock transition for the first no change operation. Sequential update logical groups that were previously unwritten are not changed if all sectors are sequentially written by the host. This transition may also occur if the card fills a group by filling the remaining unwritten sectors with a predetermined data pattern. The metablock is unchanged.
FIG. 14C is a state diagram corresponding to logical groups and metablock transitions for the first chaotic operation. Sequential update logical groups that were previously unwritten become chaotic when at least one sector is written non-sequentially by the host.
FIG. 14D is a state diagram corresponding to logical grouping and metablock transitions for the first compacting operation. All valid sectors in the previously unwritten chaotic update logical group are copied from the old block to the new chaotic metablock, and the old block is then erased.
FIG. 14E is a state diagram corresponding to logical group and metablock transitions for the first consolidation operation. All valid sectors in the previously unwritten chaotic update logical group are moved out of the old chaotic block and filled into the newly allocated block in a logical sequential order. Sectors not written by the host are filled with a predetermined data pattern. The old chaotic block is then erased.
図１４（Ｆ）は、順次書き込み動作についての論理グループおよびメタブロック遷移に対応する状態図である。ホストは、変更なしの論理グループの１つ以上のセクタを、論理的な順次順序で、新規に割り当てられた消去済みブロックに書き込む。論理グループおよびメタブロックは、順次更新状態となる。以前変更なしであったメタブロックは、元メタブロックとなる。
図１４（Ｇ）は、順次充填動作についての論理グループおよびメタブロック遷移に対応する状態図である。順次更新論理グループは、そのすべてのセクタが順次的にホストによって書き込まれる場合に、変化なしとなる。これは、順次更新論理グループを変化無しとするために、元ブロックからの有効なセクタで充填する場合にも生じることがあり、その後、元ブロックは消去される。
図１４（Ｈ）は、非順次書き込み動作についての論理グループおよびメタブロック遷移に対応する状態図である。順次更新論理グループは、少なくとも１つのセクタが非順次的にホストによって書き込まれる場合に、カオス的となる。非順次的セクタの書き込みは、更新ブロック内または対応する元ブロック内のいずれかの有効なセクタを廃止することがあってもよい。
図１４（Ｉ）は、コンパクト化動作についての論理グループおよびメタブロック遷移に対応する状態図である。カオス的更新論理グループ内のすべての有効なセクタは、旧ブロックから新規のカオス的メタブロックへコピーされて、旧ブロックは、その後消去される。元ブロックは、影響を受けない。
図１４（Ｊ）は、統合化動作についての論理グループおよびメタブロック遷移に対応する状態図である。カオス的更新論理グループ内のすべての有効なセクタは、旧カオス的ブロックおよび元ブロックからコピーされて、新規に割り当てられた消去ブロックは論理的な順次順序で充填される。その後、旧カオス的ブロックおよび元ブロックは消去される。
FIG. 14F is a state diagram corresponding to logical groups and metablock transitions for sequential write operations. The host writes one or more sectors of the unaltered logical group to the newly allocated erased block in a logical sequential order. Logical groups and metablocks are sequentially updated. A metablock that has not been changed before becomes the original metablock.
FIG. 14G is a state diagram corresponding to logical groups and metablock transitions for sequential fill operations. A sequential update logical group will be unchanged if all its sectors are written by the host sequentially. This may also occur when filling with valid sectors from the original block to make the sequential update logical group unchanged, after which the original block is erased.
FIG. 14H is a state diagram corresponding to logical group and metablock transitions for non-sequential write operations. A sequential update logical group is chaotic if at least one sector is written non-sequentially by the host. The writing of non-sequential sectors may abolish any valid sectors in the update block or in the corresponding original block.
FIG. 14I is a state diagram corresponding to logical grouping and metablock transitions for the compacting operation. All valid sectors in the chaotic update logical group are copied from the old block to the new chaotic metablock and the old block is then erased. The original block is not affected.
FIG. 14J is a state diagram corresponding to logical groups and metablock transitions for the consolidation operation. All valid sectors in the chaotic update logical group are copied from the old chaotic block and the original block, and the newly allocated erase block is filled in a logical sequential order. Thereafter, the old chaotic block and the original block are erased.
更新ブロックの追跡および管理
図１５は、割り当てのための開放または閉鎖された更新ブロックおよび消去ブロックの状況を追跡するための割り当てブロックリスト（ＡＢＬ）の構造の好ましい実施形態を示す。割り当てブックリスト（ＡＢＬ）６１０は、コントローラＲＡＭ１３０に保持され、消去されたブロックの割り当て、割り当てられた更新ブロック、関連するブロック、および制御構造の管理を行うことができ、また正確な論理／物理アドレス変換を可能にする。好ましい実施形態において、ＡＢＬは、消去済みブロックのリストと、開放更新ブロックリスト６１４と、閉鎖更新ブロックリスト６１６とを含む。
Update Block Tracking and Management FIG. 15 shows a preferred embodiment of the structure of the Allocation Block List (ABL) for tracking the status of open or closed update blocks and allocation blocks for allocation. Allocation book list (ABL) 610 is maintained in
開放更新ブロックリスト６１４は、開放更新ブロックの属性を伴う、ＡＢＬ内のブロックエントリのセットである。開放更新ブロックリストは、現在開放されている各データ更新ブロック毎に１つのエントリを有する。各エントリは、以下の情報を保持する。ＬＧは、現在の更新メタブロックが専用である論理グループアドレスである。順次／カオス的は、更新ブロックが順次またはカオス的更新データで充填されているかどうかを示す状態である。ＭＢは、更新ブロックのメタブロックアドレスである。ページタグは、更新ブロックの最初の物理位置に記録された開始論理セクタである。書き込まれたセクタ数は、更新ブロックに現在書き込まれたセクタの数を示す。ＭＢ0 は、関連する元ブロックのメタブロックアドレスである。ページタグ0 は、関連する元ブロックのページタグである。
The open
閉鎖更新ブロックリスト６１６は、割り当てブロックリスト（ＡＢＬ）のサブセットである。閉鎖更新ブロックの属性を伴う、ＡＢＬ内のブロックエントリのセットである。閉鎖更新ブロックリストは、閉鎖されたデータ更新ブロック毎に１つのエントリを有するが、そのエントリは、論理的に主要物理ディレクトリに更新されていない。各エントリは、以下の情報を保持する。ＬＧは、現在の更新ブロックが専用である論理グループアドレスである。ＭＢは、更新ブロックのメタブロックアドレスである。ページタグは、更新ブロックの最初の物理位置に記録された開始論理セクタである。ＭＢ0 は、関連する元ブロックのメタブロックアドレスである。
The closed
カオス的ブロックのインデックス付け
順次更新ブロックは、論理的に順次順序でデータを記憶しているので、ブロック内の任意の論理セクタは、容易に位置決定することができる。カオス的更新ブロックは、その論理セクタを順序がばらばらに記憶し、論理セクタの複数の更新生成物を記憶してもよい。各有効な論理セクタがカオス的更新ブロックのどこにあるかを追跡するために、追加の情報を保持しなければならない。
Indexed Sequential Update of Chaotic Blocks Since the blocks store data in logical sequential order, any logical sector within the block can be easily located. A chaotic update block may store its logical sectors out of order and store multiple update products of logical sectors. Additional information must be kept to track where each valid logical sector is located in the chaotic update block.
好ましい実施形態において、カオス的ブロックのインデックス付けのデータ構造は、カオス的ブロックにおけるすべての有効なセクタの追跡および高速アクセスを可能にする。カオス的ブロックのインデックス付けは、論理アドレス空間の小さな領域を独立して管理するものであり、システムデータと、ユーザデータのホット領域を効率的に扱う。インデックス付けデータ構造により、性能が大幅な影響を受けないように、本質的にインデックス付け情報が、更新が稀であるという要件でフラッシュメモリ内に保持することができる。他方、カオス的ブロックに現在書き込まれているセクタのリストは、コントローラＲＡＭにおけるカオス的セクタリストに保持される。また、フラッシュメモリからのインデックス情報のキャッシュが、アドレス変換のためのフラッシュセクタアクセス数を最小限にするために、コントローラＲＡＭに保持される。カオス的ブロック毎のインデックスが、フラッシュメモリ内のカオス的ブロックインデック（ＣＢＩ）内に記憶される。 In the preferred embodiment, the chaotic block indexing data structure allows tracking and fast access of all valid sectors in the chaotic block. Chaotic block indexing independently manages a small area of the logical address space and efficiently handles system data and hot areas of user data. The indexing data structure allows the indexing information to be inherently retained in flash memory with the requirement that updates be rare, so that performance is not significantly impacted. On the other hand, the list of sectors currently written to the chaotic block is kept in the chaotic sector list in the controller RAM. Also, a cache of index information from flash memory is maintained in the controller RAM to minimize the number of flash sector accesses for address translation. An index for each chaotic block is stored in a chaotic block index (CBI) in flash memory.
図１６Ａは、カオス的ブロックインデックス（ＣＢＩ）セクタのデータフィールドを示す。カオス的ブロックインデックスセクタ（ＣＢＩセクタ）は、カオス的更新ブロックにマッピングされた論理グループ内のセクタ毎のインデックスを含み、カオス的更新ブロックまたはその関連する元ブロック内の論理グループの各セクタの位置を規定する。ＣＢＩセクタは、カオス的ブロック内の有効セクタを追跡するためのカオスブロックインデックスフィールドと、カオスブロックについてのアドレスパラメータを追跡するためのカオス的ブロック情報フィールドと、ＣＢＩセクタを記憶するメタブロック（ＣＢＩブロック）内の有効なＣＢＩセクタを追跡するためのセクタインデックスフィールドとを含む。 FIG. 16A shows data fields of a chaotic block index (CBI) sector. The chaotic block index sector (CBI sector) includes a sector-by-sector index within the logical group mapped to the chaotic update block and locates each sector of the logical group within the chaotic update block or its associated original block. Specify. The CBI sector includes a chaotic block index field for tracking an effective sector in a chaotic block, a chaotic block information field for tracking an address parameter for the chaotic block, and a metablock (CBI block for storing a CBI sector). And sector index fields for tracking valid CBI sectors within
図１６Ｂは、カオス的ブロックインデックス（ＣＢＩ）セクタが専用のメタブロックに記録されている一例を示す。専用のメタブロックを、ＣＢＩブロック６２０と称する。ＣＢＩセクタが更新されると、ＣＢＩブロック６２０内の次に使用可能な物理セクタ位置に書き込まれる。したがって、ＣＢＩセクタの複数のコピーがＣＢＩブロック内に存在し、最後に書き込まれたコピーのみが有効である。例えば、論理グループＬＧ1 についてのＣＢＩセクタは３回更新され、最後に書き込まれたコピーのみが有効なものである。ＣＢＩブロック内の各有効セクタの位置は、ブロック内の最後に書き込まれたＣＢＩセクタ内のインデックスのセットによって識別される。この例において、ブロック内に最後に書き込まれたＣＢＩセクタは、ＬＧ136 についてのＣＢＩセクタであり、そのインデックスのセットは、以前のすべてのものに取って代わる有効なものである。ＣＢＩブロックが最終的にＣＢＩセクタで満杯になると、ブロックは、制御書き込み動作中に、すべての有効セクタを新規のブロック位置に書き換えることによってコンパクト化される。その後、一杯のブロックは、消去される。
FIG. 16B shows an example in which chaotic block index (CBI) sectors are recorded in dedicated metablocks. The dedicated metablock is referred to as
ＣＢＩセクタ内のカオス的ブロックインデックスフィールドは、カオス的更新ブロックにマッピングされた論理グループまたはサブグループ内の各論理セクタについてのインデックスエントリを含む。各インデックスエントリは、対応する論理セクタについての有効データが位置するカオス的更新ブロック内のオフセットを示す。予約されたインデックス値は、論理セクタについての有効データがカオス的更新ブロック内に存在しないことを示し、関連する元ブロック内の対応するセクタが有効であることを示す。いくつかのカオス的ブロックインデックスフィールドエントリのキャッシュが、コントローラＲＡＭに保持される。 The chaotic block index field in the CBI sector contains an index entry for each logical sector in the logical group or subgroup mapped to the chaotic update block. Each index entry indicates an offset within the chaotic update block at which valid data for the corresponding logical sector is located. The reserved index value indicates that valid data for the logical sector is not present in the chaotic update block, and indicates that the corresponding sector in the associated original block is valid. A cache of some chaotic block index field entries is kept in the controller RAM.
ＣＢＩセクタ内のカオス的ブロック情報フィールドは、システム内に存在するカオス的更新ブロック毎に１つのエントリを含み、ブロックについてのアドレスパラメータ情報を記録する。このフィールド内の情報は、ＣＢＩブロック内に最後に書き込まれたセクタにおいて有効であるのみである。この情報は、ＲＡＭ内のデータ構造にも存在する。 The chaotic block information field in the CBI sector contains one entry for each chaotic update block present in the system and records address parameter information for the block. The information in this field is only valid in the sector last written in the CBI block. This information is also present in data structures in RAM.
カオス的更新ブロック毎のエントリは、３つのアドレスパラメータを含む。１つ目は、カオス的更新ブロックに関連する論理グループの論理アドレス（または論理グループ番号）である。２つ目は、カオス的更新ブロックのメタブロックアドレスである。３つ目は、カオス的更新ブロック内に最後に書き込まれたセクタの物理アドレスのオフセットである。オフセット情報は、ＲＡＭ内にデータ構造を再構築するために、初期化中のカオス的更新ブロックの走査のための開始点を設定する。 The entry for each chaotic update block contains three address parameters. The first is the logical address (or logical group number) of the logical group associated with the chaotic update block. The second is the metablock address of the chaotic update block. The third is the offset of the physical address of the sector last written into the chaotic update block. The offset information sets the starting point for the scan of the chaotic update block during initialization to reconstruct the data structure in RAM.
セクタインデックスフィールドは、ＣＢＩブロックにおける有効ＣＢＩセクタ毎のエントリを含む。各許可されたカオス的更新ブロックに関する最も最近書き込まれたＣＢＩセクタが位置するＣＢＩブロック内のオフセットを規定する。インデックス内のオフセットの予約値は、許可されたカオス的更新ブロックが存在しないことを示す。 The sector index field contains an entry for each valid CBI sector in the CBI block. Define an offset within the CBI block where the most recently written CBI sector for each granted chaotic update block is located. The reserved value of the offset in the index indicates that there are no allowed chaotic update blocks.
図１６Ｃは、カオス的更新を受けている所定の論理グループの論理セクタのデータに対するアクセスを示すフロー図である。更新処理中に、更新データがカオス的更新ブロックに更新データを記録し、変化していないデータは、論理グループに関連する元メタブロック内に留まる。カオス的更新下で論理グループの論理セクタをアクセスする処理は、以下のようである。
ステップ６５０：所定の論理グループの所定の論理セクタの位置決定を開始する。
ステップ６５２：ＣＢＩブロック内の最終書き込みＣＢＩセクタを位置決定する。
ステップ６５４：最終書き込みＣＢＩセクタのカオス的ブロック情報フィールドを検索することによって、所定の論理グループに関連したカオス的更新ブロックまたは元ブロックを位置決定する。このステップは、ステップ６６２の前であればいつでも行うことができる。
ステップ６５８：最終書き込みＣＢＩセクタが所定の論理グループ宛であれば、ＣＢＩセクタは位置決定される。ステップ６６２へ進む。そうでなければ、ステップ６６０へ進む。
ステップ６６０：最終書き込みＣＢＩセクタのセクタインデックスフィールドを検索することによって、所定の論理グループについてのＣＢＩセクタを位置決定する。
ステップ６６２：位置決定されたＣＢＩセクタのカオス的ブロックインデックスフィールドを検索することによって、カオス的ブロックまたは元ブロック内の所定の論理セクタを位置決定する。
FIG. 16C is a flow diagram illustrating access to data of logical sectors of a given logical group undergoing chaotic update. During the update process, the update data records the update data in the chaotic update block, and unchanged data remains in the original metablock associated with the logical group. The process of accessing logical sectors of a logical group under chaotic update is as follows.
Step 650: Begin positioning of a given logical sector of a given logical group.
Step 652: Locate the last written CBI sector in the CBI block.
Step 654: Locate a chaotic update block or an original block associated with a predetermined logical group by searching the chaotic block information field of the last write CBI sector. This step can be performed anytime before
Step 658: If the final write CBI sector is for a given logical group, the CBI sector is located. Proceed to step 662. Otherwise, proceed to step 660.
Step 660: Locate a CBI sector for a given logical group by searching the sector index field of the last write CBI sector.
Step 662: Locate a predetermined logical sector in a chaotic block or original block by searching the chaotic block index field of the located CBI sector.
図１６Ｄは、論理グループがサブグループに分割されている代替の実施形態に係る、カオス的更新を受けている所定の論理グループの論理セクタのデータに対するアクセスを示すフロー図である。ＣＢＩセクタの容量は有限なので、論理セクタの所定の最大数を追跡することができるのみである。論理グループが単一のＣＢＩセクタが扱えるより多くの論理セクタを有する場合には、論理グループは、ＣＢＩセクタがそれぞれ割り当てられた複数のサブグループに分割される。一例において、各ＣＢＩセクタは、２５６個のセクタと、８個までのカオス的更新ブロックとからなる論理グループを追跡するのに十分な容量を有する。論理グループが２５６セクタを超えるサイズを有する場合には、２５６セクタのサブグループのそれぞれための別個のＣＢＩセクタが論理グループ内に存在する。８個までのサブグループのためのＣＢＩセクタが論理グループ内に存在してもよく、サイズで２０４８個のセクタまでの論理グループに対してサポートを提供する。
好ましい実施形態において、インデックスの管理を促進するために、間接インデックス付け手法が取られる。セクタインデックスの各エントリは、直接および間接フィールドを有する。
FIG. 16D is a flow diagram illustrating access to data of logical sectors of a given logical group undergoing chaotic update according to an alternative embodiment in which logical groups are divided into sub-groups. Because the capacity of the CBI sector is finite, it is only possible to track a predetermined maximum number of logical sectors. If the logical group has more logical sectors that can be handled by a single CBI sector, the logical group is divided into a plurality of subgroups, each of which is assigned a CBI sector. In one example, each CBI sector has sufficient capacity to track a logical group of 256 sectors and up to 8 chaotic update blocks. If the logical group has a size greater than 256 sectors, then separate CBI sectors for each of the 256 sector sub-groups are present in the logical group. CBI sectors for up to eight subgroups may be present in a logical group, providing support for logical groups up to 2048 sectors in size.
In the preferred embodiment, an indirect indexing approach is taken to facilitate the management of the index. Each entry of sector index has direct and indirect fields.
直接セクタインデックスは、特定のカオス的更新ブロックに関連するすべての予想されるＣＢＩセクタが位置するＣＢＩブロック内のオフセットを規定する。このフィールドの情報は、最後に書き込まれた、この特定のカオス的更新ブロックに関連するＣＢＩセクタにおいてのみ有効である。インデックス内のオフセットの予約値は、ＣＢＩセクタが存在しないことを示す。というのは、カオス的更新ブロックに関連する対応する論理サブグループが、存在しないか、または更新ブロックが割り当てられて以来更新されていないからである。
間接セクタインデックスは、各許可されたカオス的更新ブロックに関連する最も最近書き込まれたＣＢＩセクタが位置するＣＢＩブロック内のオフセットを規定する。インデックス内のオフセットの予約値は、許可された更新ブロックが存在しないことを示す。
The direct sector index defines an offset within the CBI block where all possible CBI sectors associated with a particular chaotic update block are located. The information in this field is valid only in the CBI sector associated with this particular chaotic update block that was last written. The reserved value of the offset in the index indicates that there is no CBI sector. The reason is that the corresponding logical subgroups associated with the chaotic update block do not exist or have not been updated since the update block was assigned.
The indirect sector index defines the offset within the CBI block where the most recently written CBI sector associated with each granted chaotic update block is located. The reserved value of the offset in the index indicates that there is no authorized update block.
図１６Ｄは、以下のような、カオス的更新下の論理グループの論理セクタをアクセスする処理を示す。
ステップ６７０：各論理グループを複数のサブグループに分割して、ＣＢＩセクタを各サブグループに割り当てる。
ステップ６８０：所定の論理グループの所定のサブグループの所定の論理セクタの位置決定を開始する。
ステップ６８２：ＣＢＩブロック内の最終書き込みＣＢＩセクタを位置決定する。
ステップ６８４：最終書き込みＣＢＩセクタのカオス的ブロック情報フィールドを検索することによって、所定のサブグループに関連したカオス的更新ブロックまたは元ブロックを位置決定する。このステップは、ステップ６９６の前であればいつでも行うことができる。
ステップ６８６：最終書き込みＣＢＩセクタが所定の論理グループ宛である場合には、ステップ６９１へ進む。そうでなければ、ステップ６９０へ進む。
ステップ６９０：最終書き込みＣＢＩセクタの間接セクタインデックスフィールドを検索することによって、所定の論理グループについての複数のＣＢＩセクタの最終書き込みを位置決定する。
ステップ６９１：所定の論理グループについてのサブグループの１つに関連したＣＢＩセクタが少なくとも位置決定されている。続く。
ステップ６９２：位置決定されたＣＢＩセクタが所定のサブグループ宛である場合には、この所定のサブグループについてのＣＢＩセクタが位置決定される。ステップ６９６へ進む。そうでなければ、ステップ６９４へ進む。
ステップ６９４：現在の位置決定されたＣＢＩセクタの直接セクタフィールドを検索することによって、所定のサブグループについてのＣＢＩセクタを位置決定する。
ステップ６９６：所定のサブグループについてのＣＢＩセクタのカオス的ブロックインデックスフィールドを検索することによって、カオス的ブロックまたは元ブロック内の所定の論理セクタを位置決定する。
FIG. 16D shows the process of accessing the logical sectors of the logical group under chaotic update as follows.
Step 670: Divide each logical group into a plurality of sub-groups and assign a CBI sector to each sub-group.
Step 680: Initiate positioning of a given logical sector of a given subgroup of a given logical group.
STEP 682: Locate the last written CBI sector in the CBI block.
Step 684: Locate the chaotic update block or original block associated with the predetermined subgroup by searching the chaotic block information field of the last write CBI sector. This step can be performed anytime before
Step 686: If the final write CBI sector is for a given logical group, then go to step 691. Otherwise, go to step 690.
Step 690: Locate the final write of multiple CBI sectors for a given logical group by searching the indirect sector index field of the final write CBI sector.
Step 691: At least the CBI sector associated with one of the subgroups for the given logical group is located. Continue.
Step 692: If the located CBI sector is for a given subgroup, then the CBI sector for this given subgroup is located. Proceed to step 696. Otherwise, proceed to step 694.
Step 694: Locate a CBI sector for a given subgroup by searching the direct sector field of the current located CBI sector.
Step 696: Locate a predetermined logical sector in the chaotic block or original block by searching the chaotic block index field of the CBI sector for a predetermined subgroup.
図１６Ｅは、各論理グループが複数のサブグループに分割される実施形態についての、カオス的ブロックインデックス付け（ＣＢＩ）セクタおよびその機能の例を示す。論理グループ７００は、その変化のないデータを、元メタブロック７０２内に記憶する。その後、論理グループは、専用のカオス的更新ブロック７０４の割り当てを伴う更新を受ける。この例において、論理グループ７００は、サブグループＡ，Ｂ，Ｃ，Ｄのようなサブグループに分割され、各サブグループは２５６個のセクタを有する。
FIG. 16E shows an example of a chaotic block indexing (CBI) sector and its function for an embodiment where each logical group is divided into multiple sub-groups.
サブグループＢ内のｉ番目のセクタを位置決定するために、ＣＢＩブロック６２０内の最終書き込みＣＢＩセクタを最初に位置決定する。最終書き込みＣＢＩセクタのカオス的ブロック情報フィールドは、所定の論理グループについてのカオス的更新ブロック７０４を位置決定するためのアドレスを提供する。同時に、これは、カオス的ブロックに書き込まれた最終セクタの位置をも提供する。この情報は、走査および再構築の際に有用である。
In order to locate the i th sector in subgroup B, the last write CBI sector in CBI block 620 is located first. The chaotic block information field of the final write CBI sector provides an address for locating the
最終書き込みＣＢＩセクタが所定の論理グループの４つのＣＢＩセクタのうちの１つであることがわかると、このセクタが確かにｉ番目の論理セクタを含む所定のサブグループＢについてのＣＢＩセクタかどうかをさらに確認することになる。そうであれば、ＣＢＩセクタのカオス的ブロックインデックスは、ｉ番目の論理セクタについてのデータを記憶するメタブロック位置を指すことになる。セクタ位置は、カオス的更新ブロック７０４または元ブロック７０２のいずれかでありうる。
If it is found that the final write CBI sector is one of the four CBI sectors of a given logical group, then this sector is indeed a CBI sector for a given subgroup B including the ith logical sector. I will check further. If so, the chaotic block index of the CBI sector will point to the metablock location storing data for the ith logical sector. The sector location may be either a
最終書き込みＣＢＩセクタが所定の論理グループの４つのＣＢＩセクタのうちの１つではあるが、正確にはサブグループＢについてのＣＢＩセクタではないことがわかると、その直接セクタインデックスを検索して、サブグループＢについてのＣＢＩセクタを位置決定する。この正確なＣＢＩセクタが位置決定されると、そのカオス的ブロックインデックスを検索して、カオス的更新ブロック７０４および元ブロック７０２の中のｉ番目の論理セクタを位置決定する。
If the final write CBI sector is found to be one of the four CBI sectors of a given logical group, but not exactly the CBI sector for subgroup B, then search its direct sector index to Locate the CBI sector for group B. Once this correct CBI sector is located, its chaotic block index is retrieved to locate the ith logical sector in the
最終書き込みＣＢＩセクタが所定の論理グループの４つのＣＢＩセクタのうちのいずれでもないことがわかると、その間接セクタインデックスを検索して、４つのうちの１つを位置決定する。図１６Ｅに示されている例において、サブグループＣについてのＣＢＩセクタを位置決定する。その後、サブグループＣについてのこのＣＢＩセクタは、その直接セクタインデックスを検索して、サブグループＢについての正確なＣＢＩセクタを位置決定する。図に示されている例では、カオス的ブロックインデックスを検索すると、ｉ番目の論理セクタが変化していないことがわかり、その有効データが元データ内で位置決定される。 If it is found that the final write CBI sector is not any of the four CBI sectors of a given logical group, its indirect sector index is searched to locate one of the four. In the example shown in FIG. 16E, the CBI sector for subgroup C is located. Then, this CBI sector for subgroup C searches its direct sector index to locate the correct CBI sector for subgroup B. In the example shown in the figure, when the chaotic block index is searched, it is found that the i-th logical sector has not changed, and its valid data is located in the original data.
同様の検討が、所定の論理グループのサブグループＣ内のｊ番目の論理セクタを位置決定することにも適用される。図に示されている例では、最終書き込みＣＢＩセクタが所定の論理グループの４つのＣＢＩセクタのうちのいずれでもないことがわかる。その間接セクタインデックスは、所定のグループについての４つのＣＢＩセクタのうちの１つを指す。また、４つのうちの指された最終書き込み分は、確かにサブグループＣについてのＣＢＩセクタであることがわかる。そのカオス的ブロックインデックスを検索すると、ｊ番目の論理セクタが、カオス的更新ブロック７０４内の指定された位置に位置決定されることがわかる。
Similar considerations apply to locating the jth logical sector within subgroup C of a given logical group. In the example shown, it can be seen that the last written CBI sector is not any of the four CBI sectors of a given logical group. The indirect sector index points to one of four CBI sectors for a given group. Also, it can be seen that the last written portion pointed out of the four is indeed the CBI sector for subgroup C. Searching the chaotic block index, it can be seen that the jth logical sector is located at the specified position in the
カオス的セクタのリストが、システム内の各カオス的更新ブロックについてのコントローラＲＡＭ内にある。各リストは、関連するＣＢＩセクタがフラッシュメモリ内で最後に更新されたときからの、カオス的更新ブロック内に書き込まれたセクタの記録を含む。特定のカオス的更新ブロックについての論理セクタアドレスの数は、カオス的セクタリスト内に保持することができ、８から１６というのが典型的な値の設計パラメータである。このリストの最適なサイズは、カオス的データ書き込み動作についてのオーバーヘッドに対する影響と、初期化中のセクタ走査時間とを調整して決定される。 A list of chaotic sectors is in the controller RAM for each chaotic update block in the system. Each list contains a record of the sectors written in the chaotic update block since the associated CBI sector was last updated in flash memory. The number of logical sector addresses for a particular chaotic update block can be kept in the chaotic sector list, with 8 to 16 being typical design parameters. The optimal size of this list is determined by adjusting the impact on overhead for chaotic data write operations and the sector scan time during initialization.
システム初期化中に、各カオス的更新ブロックを必要に応じて走査して、関連するＣＢＩセクタのうちの１つについての以前の更新以来書き込まれた有効なセクタを識別する。各カオス的更新ブロックについてのコントローラＲＡＭ内のカオス的セクタリストが構築される。各ブロックは、最終書き込みＣＢＩセクタ内のカオス的ブロック情報フィールドで規定された最終セクタアドレスから走査されればよい。 During system initialization, each chaotic update block is scanned as needed to identify valid sectors written since the previous update for one of the associated CBI sectors. A chaotic sector list in the controller RAM for each chaotic update block is constructed. Each block may be scanned from the last sector address defined in the chaotic block information field in the last write CBI sector.
カオス的更新ブロックが割り当てられると、ＣＢＩセクタが、すべての更新された論理サブグループに対応するように書き込まれる。カオス的更新ブロックについての論理および物理アドレスは、カオス的ブロックインデックスフィールド内の空白エントリと共に、セクタ内の使用可能なカオス的ブロック情報フィールド内に書き込まれる。カオス的セクタリストは、コントローラＲＡＭにおいて開放される。
カオス的更新ブロックが閉鎖されると、ＣＢＩセクタが、セクタ内のカオス的ブロック情報フィールドから除去されたブロックの論理および物理アドレスと共に書き込まれる。ＲＡＭ内の対応するカオス的セクタリストは、使用されなくなる。
When a chaotic update block is assigned, CBI sectors are written to correspond to all updated logical subgroups. The logical and physical addresses for the chaotic update block are written into the available chaotic block information field in the sector, with blank entries in the chaotic block index field. The chaotic sector list is released in the controller RAM.
When a chaotic update block is closed, a CBI sector is written with the logical and physical addresses of the block removed from the chaotic block information field in the sector. The corresponding chaotic sector list in RAM is not used.
コントローラＲＡＭ内の対応するカオス的セクタリストは、カオス的更新ブロックに書き込まれたセクタの記録を含むように修正される。コントローラＲＡＭ内のカオス的セクタリストが、カオス的更新ブロックに対するさらなるセクタ書き込みの記録について使用可能な空間を有していない場合には、更新されたＣＢＩセクタが、リスト内のセクタに関連する論理サブグループについて書き込まれ、リストはクリアされる。
ＣＢＩブロック６２０が満杯になると、有効なＣＢＩセクタが割り当てられた消去済みブロックにコピーされ、以前のＣＢＩブロックは消去される。
The corresponding chaotic sector list in the controller RAM is modified to include a record of the sector written to the chaotic update block. If the chaotic sector list in the controller RAM does not have space available for recording additional sector writes to the chaotic update block, then the updated CBI sector is associated with the logical subs associated with the sectors in the list. The group is written and the list is cleared.
When CBI block 620 is full, valid CBI sectors are copied to the allocated erased block and previous CBI blocks are erased.
アドレステーブル
図２に示されている論理／物理アドレス変換モジュール１４０は、ホストの論理アドレスをフラッシュメモリ内の対応する物理アドレスに関連付ける役割を担う。論理グループと物理グループ（メタブロック）との間のマッピングが、不揮発性フラッシュメモリ２００および揮発性だが動作が速いＲＡＭ１３０（図１参照）に分散されたテーブルおよびリストのセット内に記憶される。アドレステーブルは、フラッシュメモリに保持され、メモリシステム内の各論理グループについてのメタブロックアドレスを含む。加えて、最近書き込まれたセクタについての論理／物理アドレス記録は、ＲＡＭに一時的に保持される。これらの揮発性記録は、電源投入後にシステムを初期化するときに、フラッシュメモリ内のブロックリストおよびデータセクタヘッダから再構築することができる。よって、フラッシュメモリ内のアドレステーブルは、たまに更新されればよく、制御データについてのオーバーヘッド書き込み動作の割合が減ることになる。
Address Table The logical / physical
論理グループについてのアドレス記録の階層は、開放更新ブロックリストと、ＲＡＭ内の閉鎖更新ブロックリストと、フラッシュメモリに保持されたグループアドレステーブル（ＧＡＴ）とを含む。
開放更新ブロックリストは、更新されたホストセクタデータについて現在開放されているデータ更新ブロックのコントローラＲＡＭ内のリストである。あるブロックに対するエントリは、ブロックが閉鎖されると、閉鎖更新ブロックリストに移動される。閉鎖更新ブロックリストは、閉鎖されているデータ更新ブロックのコントローラＲＡＭ内のリストである。リスト内のエントリのサブセットは、制御書き込み動作中に、グループアドレステーブル内のセクタに移動される。
The hierarchy of address records for logical groups includes an open update block list, a closed update block list in RAM, and a group address table (GAT) held in flash memory.
The open update block list is a list in the controller RAM of data update blocks that are currently open for updated host sector data. An entry for a block is moved to the closed update block list when the block is closed. The closed update block list is a list in the controller RAM of data update blocks that are closed. A subset of the entries in the list is moved to a sector in the group address table during a control write operation.
グループアドレステーブル（ＧＡＴ）は、メモリシステム内のホストデータのすべての論理グループについてのメタブロックアドレスのリストである。ＧＡＴは、論理アドレスに従って順次的に並べられた、論理グループ毎に１つのエントリを含む。ＧＡＴ内のｎ番目のエントリは、アドレスｎの論理グループについてのメタブロックアドレスを含む。好ましい実施形態において、このテーブルは、フラッシュメモリ内にあるテーブルであり、メモリシステム内のすべての論理グループについてのメタブロックアドレスを規定するエントリを伴うセクタ（ＧＡＴセクタと称する）のセットを含む。ＧＡＴセクタは、フラッシュメモリ内の１つ以上の専用制御ブロック（ＧＡＴブロックと称する）内にある。 The group address table (GAT) is a list of metablock addresses for all logical groups of host data in the memory system. The GAT includes one entry per logical group, arranged in order according to the logical address. The nth entry in the GAT contains the metablock address for the logical group of address n. In the preferred embodiment, this table is a table in flash memory and contains a set of sectors (referred to as GAT sectors) with entries defining metablock addresses for all logical groups in the memory system. GAT sectors are in one or more dedicated control blocks (referred to as GAT blocks) in flash memory.
図１７Ａは、グループアドレステーブル（ＧＡＴ）セクタのデータフィールドを示す。ＧＡＴセクタは、例えば、１２８個の連続する論理グループのセットについてのＧＡＴエントリを含むのに十分な容量を有してもよい。各ＧＡＴセクタは、２つの構成要素、すなわち、ある範囲内の各論理グループのメタブロックアドレスについてのＧＡＴエントリのセットと、ＧＡＴセクタインデックスとを含む。第１の構成要素は、論理アドレスに関連するメタブロックを位置決定するための情報を含む。第２の構成要素は、ＧＡＴブロック内のすべての有効なＧＡＴセクタを位置決定するための情報を含む。各ＧＡＴエントリは、３つのフィールド、すなわち、メタブロック番号と、図３Ａ（ｉｉｉ）に関連して前に規定したようなページタグと、メタブロックが再リンクされたかどうかを示すフラグとを有する。ＧＡＴセクタインデックスは、ＧＡＴブロック内の有効なＧＡＴセクタの位置を列挙する。このインデックスは、各ＧＡＴセクタ内にあるが、ＧＡＴブロック内の次に書き込まれたＧＡＴセクタのバージョンによって取って代わられる。よって、最終書き込みＧＡＴセクタ内のバージョンのみが有効である。 FIG. 17A shows data fields of a group address table (GAT) sector. A GAT sector may have, for example, sufficient capacity to contain GAT entries for a set of 128 consecutive logical groups. Each GAT sector contains two components: a set of GAT entries for the metablock address of each logical group within a range, and a GAT sector index. The first component includes information for locating the metablock associated with the logical address. The second component contains information for locating all valid GAT sectors in the GAT block. Each GAT entry has three fields: a metablock number, a page tag as defined above in connection with FIG. 3A (iii), and a flag indicating whether the metablock has been relinked. The GAT sector index enumerates the locations of valid GAT sectors within a GAT block. This index is in each GAT sector but is replaced by the version of the GAT sector written next in the GAT block. Thus, only the version in the last write GAT sector is valid.
図１７Ｂは、グループアドレステーブル（ＧＡＴ）セクタが１つ以上のＧＡＴブロックに記録されている一例を示す。ＧＡＴブロックは、ＧＡＴセクタを記録する専用のメタブロックである。ＧＡＴセクタが更新される場合には、ＧＡＴブロック７２０内の次に使用可能な物理セクタ位置に書き込まれる。したがって、ＧＡＴセクタの複数のコピーがＧＡＴブロック内に存在することがあり、最後に書き込まれたコピーのみが有効である。例えば、ＧＡＴセクタ４５は、少なくとも２回更新され、最終バージョンが有効なものである。ＧＡＴブロック内の各有効セクタの位置は、ブロック内の最終書き込みＧＡＴセクタ内のインデックスのセットによって識別される。この例において、ブロック内の最終書き込みＧＡＴセクタは、ＧＡＴセクタ５６であり、そのインデックスのセットは、すべての以前のものにとって代わる有効なものである。ＧＡＴブロックが、ＧＡＴセクタで最終的に満杯になった場合には、ブロックは、すべての有効なセクタを新規のブロック位置に書き換えることによって、制御書き込み動作中にコンパクト化される。その後、一杯のブロックは消去される。
FIG. 17B shows an example in which a group address table (GAT) sector is recorded in one or more GAT blocks. The GAT block is a dedicated metablock for recording GAT sectors. If the GAT sector is updated, then it is written to the next available physical sector location in GAT block 720. Thus, multiple copies of the GAT sector may be present in the GAT block, and only the last written copy is valid. For example, the
前に説明したように、ＧＡＴブロックは、論理アドレス空間のある領域におけるグループの論理的に連続したセットについてのエントリを含む。ＧＡＴブロック内のＧＡＴセクタは、それぞれ、１２８個の連続する論理グループについての論理／物理マッピング情報を含む。ＧＡＴブロックが対象とするアドレス範囲内のすべての論理グループについてのエントリを記憶するのに必要な数多くのＧＡＴセクタは、ブロック内の全セクタ位置のほんのわずかを占めるに過ぎない。したがって、あるＧＡＴセクタは、ブロック内の次に使用可能なセクタ位置に書き込まれることによって更新されてもよい。すべての有効なＧＡＴセクタおよびそれらのＧＡＴブロック内の位置のインデックスが、直近の書き込みＧＡＴセクタ内のインデックスフィールドに保持される。有効なＧＡＴセクタによって占められたＧＡＴブロック内の僅かな合計セクタは、システム設計パラメータであり、典型的には２５％である。しかし、ＧＡＴブロック毎に最大６４個の有効ＧＡＴセクタがある。論理容量が大きいシステムにおいて、１つ以上のＧＡＴブロックにＧＡＴセクタを記憶する必要がある場合がある。この場合、各ＧＡＴブロックは、固定的な範囲の論理グループに関連付けられる。 As discussed earlier, the GAT block contains entries for logically contiguous sets of groups in an area of logical address space. Each GAT sector in the GAT block contains logical / physical mapping information for 128 consecutive logical groups. The large number of GAT sectors needed to store entries for all logical groups within the address range targeted by the GAT block occupy only a fraction of the total sector positions within the block. Thus, certain GAT sectors may be updated by writing to the next available sector location in the block. An index of all valid GAT sectors and their location in the GAT block is kept in the index field in the last write GAT sector. The fractional total sectors within the GAT block occupied by valid GAT sectors are system design parameters, typically 25%. However, there are up to 64 valid GAT sectors per GAT block. In systems with large logical capacity, it may be necessary to store GAT sectors in one or more GAT blocks. In this case, each GAT block is associated with a fixed range logical group.
ＧＡＴ更新は、制御書き込み動作の一部として行われ、割り当てのためのブロックがＡＢＬになくなったときにトリガされる（図１８参照）。これは、ＡＢＬ充填動作およびＣＢＬを空にする動作と並行して行われる。ＧＡＴ更新動作中に、１つのＧＡＴセクタは、閉鎖更新ブロックリスト内の対応するエントリからの情報で更新されたエントリを有する。ＧＡＴエントリが更新されると、対応するエントリはどれでも、閉鎖更新ブロックリスト（ＣＵＢＬ）から除去される。例えば、更新すべきＧＡＴセクタは、閉鎖更新ブロックリスト内の最初のエントリに基づいて選択される。更新されたセクタは、ＧＡＴブロック内の次に使用可能なセクタ位置に書き込まれる。 GAT updates are performed as part of a control write operation and are triggered when there are no more blocks for allocation in the ABL (see FIG. 18). This is done in parallel with the ABL filling operation and the CBL emptying operation. During a GAT update operation, one GAT sector has an updated entry with information from the corresponding entry in the closed update block list. When a GAT entry is updated, any corresponding entry is removed from the Closed Update Block List (CUBL). For example, the GAT sector to be updated is selected based on the first entry in the closed update block list. The updated sector is written to the next available sector position in the GAT block.
更新されたＧＡＴセクタに使用可能なセクタ位置がなくなったときに、ＧＡＴ書き換え動作は、制御書き込み動作中に生じる。新たなＧＡＴブロックが割り当てられ、ＧＡＴインデックスによって規定された有効なＧＡＴセクタは、順次順序で一杯のＧＡＴブロックからコピーされる。その後、一杯のＧＡＴブロックは消去される。 GAT rewrite operations occur during control write operations when there are no available sector locations in the updated GAT sector. A new GAT block is allocated, and valid GAT sectors defined by the GAT index are copied from the full GAT block in sequential order. Thereafter, the full GAT block is erased.
ＧＡＴキャッシュは、ＧＡＴセクタ内の１２８個のエントリの再分割部分内のエントリの、コントローラＲＡＭ１３０内のコピーである。ＧＡＴキャッシュエントリの数は、システム設計パラメータであり、典型的な値は３２である。該当セクタの再分割部分についてのＧＡＴキャッシュは、エントリがＧＡＴセクタから読み出される度に作成される。複数のＧＡＴキャッシュが保持される。その数は、設計パラメータであり、典型的な値は４である。ＧＡＴキャッシュは、最近最も使用されていないことに基づいて、異なるセクタの再分割部分についてのエントリで上書きされる。
The GAT cache is a copy in
消去済みメタブロックの管理
図２に示されている消去ブロックマネージャ１６０は、ディレクトリおよびシステム制御情報を保持するためのリストのセットを使用して、消去ブロックを管理する。これらのリストは、コントローラＲＡＭ１３０およびフラッシュメモリ２００に分散されている。消去されたメタブロックがユーザデータの記憶のため、またはシステム制御データ構造の記憶のために割り当てられなければならない場合には、コントローラＲＡＭに保持された割り当てブロックリスト（ＡＢＬ）（図１５参照）内の次に使用可能なメタブロック番号が選択される。同様に、メタブロックが廃棄後に消去される場合には、その番号が、同じくコントローラＲＡＭに保持されたクリア済みブロックリスト（ＣＢＬ）に追加される。比較的静的なディレクトリおよびシステム制御データが、フラッシュメモリ内に記憶される。これらには、消去済みブロックリストと、フラッシュメモリ内のすべてのメタブロックの消去された状態のビットマップ（ＭＡＰ）リストとが含まれる。消去済みブロックリストおよびＭＡＰは、個別のセクタに記憶され、ＭＡＰブロックとして知られる専用のメタブロックに記録される。これらのリストは、コントローラＲＡＭおよびフラッシュメモリに分散されて、消去済みメタブロックの使用を効率的に管理するための消去済みブロック記録の階層を提供する。
Managing Erased Metablocks The erase
図１８は、消去済みブロックの使用およびリサイクルのための制御およびディレクトリ情報の分配および流れを示す概略ブロック図である。制御およびディレクトリデータは、コントローラＲＡＭ１３０内か、フラッシュメモリ２００内に常駐するＭＡＰブロック７５０内のいずれかに保持されるリストに保持される。
FIG. 18 is a schematic block diagram showing the distribution and flow of control and directory information for use and recycling of erased blocks. The control and directory data is held in a list held either in
好ましい実施形態において、コントローラＲＡＭ１３０は、割り当てブロックリスト（ＡＢＬ）６１０と、クリア済みブロックリスト（ＣＢＬ）７４０とを保持する。図１５に関連して前に説明したように、割り当てブロックリスト（ＡＢＬ）は、ユーザデータの記憶のため、またはシステム制御データ構造の記憶のために最近割り当てられたのがどのメタブロックかを追跡する。新規の消去済みメタブロックを割り当てる必要がある場合には、割り当てブロックリスト（ＡＢＬ）内の次に使用可能なメタブロック番号が選択される。同様に、クリア済みブロックリスト（ＣＢＬ）を使用して、割り当て解除および消去された更新メタブロックを追跡する。ＡＢＬおよびＣＢＬは、比較的アクティブな更新ブロックを追跡する際の迅速なアクセスおよび容易な操作のために、コントローラＲＡＭ１３０（図１参照）に保持される。
In the preferred embodiment,
割り当てブロックリスト（ＡＢＬ）は、消去済みメタブロックのプールと、消去済みメタブロックを更新ブロックにする割り当てとを追跡する。よって、これらの各メタブロックは、ＡＢＬ保留割り当ての消去済みブロックか、開放更新ブロックか、閉鎖更新ブロックかどうかを指定する属性によって記述されてもよい。図１８は、消去済みＡＢＬリスト６１２と、開放更新ブロックリスト６１４と、閉鎖更新ブロックリスト６１６とを含むＡＢＬを示す。加えて、開放更新ブロックリスト６１４に関連付けられているのは、関連する元ブロックリスト６１５である。同様に、閉鎖更新ブロックリストに関連付けられているのは、関連消去済みの元ブロックリスト６１７である。図１５において前に示したように、これらの関連リストは、それぞれ、開放更新ブロックリスト６１４および閉鎖更新ブロックリスト６１６のサブセットである。消去済みＡＢＬブロックリスト６１２、開放更新ブロックリスト６１４、および閉鎖更新ブロックリスト６１６は、すべて、割り当てブロックリスト（ＡＢＬ）６１０のサブセットであり、それぞれの中のエントリは、それぞれ対応する属性を有する。
The Allocation Block List (ABL) tracks the pool of erased metablocks and the allocation that makes the erased metablocks an update block. Thus, each of these metablocks may be described by an attribute that specifies whether it is an erased block, an open update block, or a closed update block of ABL pending allocation. FIG. 18 shows an ABL that includes an erased
ＭＡＰブロック７５０は、フラッシュメモリ２００内の消去管理記録を記憶するのに専用のメタブロックである。ＭＡＰブロックは、時系列のＭＡＰブロックセクタを記憶し、各ＭＡＰセクタは、消去ブロック管理（ＥＢＭ）セクタ７６０またはＭＡＰセクタ７８０のいずれかである。メタブロックが廃棄されて、消去済みブロックが割り当てで使い尽くされてリサイクルされるにつれて、関連する制御およびディレクトリデータは、ＭＡＰブロック内で更新される論理セクタに含まれるのが好ましく、更新データの各インスタンスは、新規のブロックセクタに記録される。ＥＢＭセクタ７６０およびＭＡＰセクタ７８０の複数のコピーがＭＡＰブロック７５０内に存在してもよく、その最新バージョンのみが有効である。有効ＭＡＰセクタの位置へのインデックスは、ＥＭＢブロック内のフィールド内に含まれる。有効なＥＭＢセクタが、制御書き込み動作中のＭＡＰブロック内にいつも最後に書き込まれる。ＭＡＰブロック７５０が一杯の場合には、すべての有効セクタを新規のブロック位置に書き換えることによって、制御書き込み動作中にコンパクト化される。その後、一杯のブロックは消去される。
The
各ＥＢＭセクタ７６０は、消去済みブロックリスト（ＥＢＬ）７７０を含み、これは、消去済みブロックの母集団のサブセットのアドレスのリストである。消去済みブロックリスト（ＥＢＬ）７７０は、消去済みメタブロック番号を含むバッファとしての役割を果たし、ＥＢＬから、メタブロック番号が周期的に取り出されてＡＢＬを再充填し、ＥＢＬに対して、メタブロック番号が周期的に追加されてＣＢＬを再び空にする。ＥＢＬ７７０は、使用可能ブロックバッファ（ＡＢＢ）７７２、消去済みブロックバッファ（ＥＢＢ）７７４、および消去済みブロックバッファ（ＣＢＢ）７７６のためのバッファとしての役割を果たす。
Each EBM sector 760 includes an erased block list (EBL) 770, which is a list of addresses of subsets of the erased block population. The erased block list (EBL) 770 acts as a buffer containing the erased metablock numbers, and from EBL, the metablock numbers are periodically taken to refill the ABL, and for the EBL, the metablocks A number is periodically added to empty the CBL again.
使用可能ブロックバッファ（ＡＢＢ）７７２は、前回のＡＢＬ充填動作のすぐ後に続くＡＢＬ６１０内のエントリのコピーを含む。これは、実質上、ＡＢＬ充填動作直後のＡＢＬのバックアップコピーである。
消去済みブロックバッファ（ＥＢＢ）７７４は、ＭＡＰセクタ７８０から、または（後述する）ＣＢＢリスト７７６からのいずれかから先に転送され、かつＡＢＬ充填動作中にＡＢＬ６１０へ転送に使用可能である消去済みブロックアドレスを含む。
クリアされたブロックバッファ（ＣＢＢ）７７６は、ＣＢＬを空にする動作中にＣＢＬ７４０から転送され、かつＭＡＰセクタ７８０またはＥＢＢリスト７７４へ後に転送される消去済みブロックのアドレスを含む。
The Available Block Buffer (ABB) 772 contains a copy of the entry in
An erased block buffer (EBB) 774 is transferred earlier from either
A cleared block buffer (CBB) 776 contains the addresses of erased blocks transferred from
各ＭＡＰセクタ７８０は、ＭＡＰと称されるビットマップ構造を含む。ＭＡＰは、フラッシュメモリ内のメタブロック毎に１ビットを使用し、これは、各ブロックの消去状態を示すために使用される。ＡＢＬ、ＣＢＬ、またはＥＢＭ内の消去済みブロックリスト内に列挙されたブロックアドレスに対応するビットは、ＭＡＰ内において消去済み状態に設定されない。
Each
有効データ構造を含まず、かつＭＡＰ内の消去済みブロック、消去済みブロックリスト、ＡＢＬ、またはＣＢＬとして指定されていないブロックはどれでも、ブロック割り当てアルゴリズムによって決して使用されず、従ってホストまたは制御データ構造の記憶のためにアクセスすることはできない。これにより、アクセス可能なフラッシュメモリアドレス空間から障害位置のあるブロックを除外するための簡単な機構が提供される。 Any block that does not contain a valid data structure and is not designated as an erased block, an erased block list, an ABL, or a CBL in the MAP is never used by the block allocation algorithm, and so is not a host or control data structure. It can not be accessed for storage. This provides a simple mechanism to exclude blocks with fault locations from accessible flash memory address space.
図１８に示されている階層により、消去済みブロック記録を効率的に管理することができるようになり、コントローラのＲＡＭ内に記憶されたブロックアドレスリストの完全なセキュリティを提供する。消去済みブロックエントリが、これらのブロックアドレスリストと、１つ以上のＭＡＰセクタ７８０との間で、稀に交換される。これらのリストは、電源が切られた後のシステム初期化中に、消去済みブロックリスト、およびフラッシュメモリ内のセクタに記憶されたアドレス変換テーブル内の情報と、フラッシュメモリ内のわずかな数の参照済みデータブロックの限定的な走査とを介して再構築される。
The hierarchy shown in FIG. 18 allows for efficient management of erased block records and provides complete security of the block address list stored in the controller's RAM. Erased block entries are exchanged infrequently between these block address lists and one or
消去済みメタブロック記録の階層を更新するために採用されたアルゴリズムにより、消去済みブロックが、ＭＡＰブロック７５０からのアドレス順序のブロックのバーストと、ブロックがホストによって更新された順序を反映するＣＢＬ７４０からのブロックアドレスのバーストとをインターリーブする順序で使用するために割り当てられる結果となる。メタブロックサイズおよびシステムメモリ容量のほとんどについて、１つのＭＡＰセクタは、システム内のすべてのメタブロックについてのビットマップを提供する。この場合、消去済みブロックは、このＭＡＰセクタに記録されるとおりのアドレス順序での使用のために常に割り当てられる。
The algorithm employed to update the hierarchy of the erased metablock record causes the erased block to be a burst of blocks in address order from the
消去ブロック管理動作
前に説明したように、ＡＢＬ６１０は、使用のために割り当てられるであろう消去済みメタブロック、およびデータ更新ブロックとして最近割り当てられたメタブロックについてのアドレスエントリを有するリストである。ＡＢＬ内のブロックアドレスの実際の数は、上限と下限という、システム設計の変数の間にある。製造中にフォーマットされたＡＢＬエントリの数は、カードの種類と容量との関数である。加えて、システムの寿命の終わりが近づくとＡＢＬ内のエントリの数が減少するのは、使用可能な消去済みブロックの数が寿命内でのブロックの障害によって減少するためである。例えば、充填動作の後、ＡＢＬ内のエントリは、以下の目的のために使用可能なブロックを指定してもよい。ブロック毎に１つのエントリを有する部分的に書き込まれたデータ更新ブロックについてのエントリであり、同時に開放されている更新ブロックの最大数についてのシステム制限を越えないもの。データ更新ブロックとして割り当てるための消去済みブロックについての１個から１２個の間のエントリ。制御ブロックとして割り当てるための消去済みブロックについての４つのエントリ。
Erase Block Management Operation As described earlier,
ＡＢＬ充填動作
ＡＢＬ６１０が割り当てによって使い尽くされると、再充填される必要があることになる。ＡＢＬを充填する動作は、制御書き込み動作中に生じる。これは、ブロックを割り当てなければならない場合にトリガされるが、ＡＢＬには、データ更新ブロックとして割り当てるため、またはいくつかの他の制御データ更新ブロックのために使用可能な消去済みブロックエントリが十分には含まれていない。制御書き込み中に、ＡＢＬ充填動作は、ＧＡＴ更新動作と並行して行われる。
ABL Fill Operation When the
以下の動作が、ＡＢＬ充填動作中に生じる。
１．現在のデータ更新ブロックの属性を有するＡＢＬエントリは保持される。
２．閉鎖データ更新ブロックの属性を有するＡＢＬエントリは、このブロックについてのエントリが並行ＧＡＴ更新動作において書き込み中でなければ保持され、書き込み中であれば、このエントリはＡＢＬから除去される。
３．割り当てられていない消去ブロックについてのＡＢＬエントリは保持される。
４．ＡＢＬは、エントリの除去によって生じたギャップを除去するためにコンパクト化され、エントリの順序が維持される。
５．ＡＢＬは、ＥＢＢリストから次に使用可能なエントリをつけることによって完全に充填される。
６．ＡＢＢリストは、ＡＢＬ内の現在のエントリで上書きされる。
The following actions occur during the ABL fill operation.
1. ABL entries with the attributes of the current data update block are retained.
2. An ABL entry having the attributes of a closed data update block is retained if the entry for this block is not writing in a parallel GAT update operation, and if writing, this entry is removed from the ABL.
3. ABL entries for unallocated erase blocks are maintained.
4. The ABL is compacted to eliminate gaps created by the removal of entries, and the order of entries is maintained.
5. The ABL is completely filled by making the next available entry from the EBB list.
6. The ABB list is overwritten with the current entry in the ABL.
ＣＢＬを空にする動作
ＣＢＬは、消去済みブロックエントリの数に対するＡＢＬと同じ制限を有する、コントローラＲＡＭ内の消去済みブロックアドレスのリストである。ＣＢＬを空にする動作は、制御書き込み動作中に生じる。したがって、この動作は、ＡＢＬ充填／ＧＡＴ更新動作、またはＣＢＩブロック書き込み動作と並行して行われる。ＣＢＬを空にする動作において、エントリはＣＢＬ７４０から除去されて、ＣＢＢリスト７７６に書き込まれる。
The operation CBL to empty CBL is a list of erased block addresses in the controller RAM with the same limitations as ABL on the number of erased block entries. The act of emptying CBL occurs during a control write operation. Therefore, this operation is performed in parallel with the ABL fill / GAT update operation or the CBI block write operation. In the CBL empty operation, the entry is removed from
ＭＡＰ交換動作
ＭＡＰセクタ７８０およびＥＢＭセクタ７６０内の消去ブロック情報間のＭＡＰ交換動作は、ＥＢＢリスト７７４が空の場合に、制御書き込み動作中に周期的に生じてもよい。システム内のすべての消去済みメタブロックは、ＥＢＭセクタ７６０内に記録され、ＭＡＰセクタ７８０はなく、ＭＡＰ交換は行われない。ＭＡＰ交換動作中に、ＥＢＢ７７４に消去済みブロックを入力するＭＡＰセクタは、送信元ＭＡＰセクタ７８２とみなされる。逆に、ＣＢＢ７７６から消去済みブロックを受信するＭＡＰセクタは、送信先ＭＡＰセクタ７８４とみなされる。ＭＡＰセクタが１つだけ存在する場合は、以下に規定するように、送信元および送信先ＭＡＰセクタの両方としての役割を果たす。
MAP Exchange Operation A MAP exchange operation between erase block information in
以下の動作が、ＭＡＰ交換中に行われる。
１．送信元ＭＡＰセクタが、増分ポインタに基づいて選択される。
２．送信先ＭＡＰセクタが、送信元ＭＡＰセクタ内ではない最初のＣＢＢエントリ内のブロックアドレスに基づいて選択される。
３．送信先ＭＡＰセクタが、ＣＢＢ内の該当エントリによって規定されたように更新され、当該エントリは、ＣＢＢから除去される。
４．別個の送信元ＭＡＰセクタが存在しなければ、更新された送信先ＭＡＰセクタが、ＭＡＰブロックに書き込まれる。
５．送信元ＭＡＰセクタが、ＣＢＢ内の該当エントリによって規定されたように更新され、当該エントリは、ＣＢＢから除去される。
６．ＣＢＢ内の残りのエントリが、ＥＢＢに付加される。
７．ＥＢＢには、送信元ＭＡＰセクタから規定された消去済みブロックアドレスができる限り充填される。
８．更新済みの送信元ＭＡＰセクタが、ＭＡＰブロック内に書き込まれる。
９．更新済みのＥＢＭセクタが、ＭＡＰブロック内に書き込まれる。
The following operations are performed during MAP exchange.
1. A source MAP sector is selected based on the incremental pointer.
2. A destination MAP sector is selected based on the block address in the first CBB entry not in the source MAP sector.
3. The destination MAP sector is updated as specified by the corresponding entry in the CBB, and the entry is removed from the CBB.
4. If there is no separate source MAP sector, the updated destination MAP sector is written to the MAP block.
5. The source MAP sector is updated as specified by the corresponding entry in the CBB, and the entry is removed from the CBB.
6. The remaining entries in the CBB are appended to the EBB.
7. The EBB is filled as much as possible of the erased block address specified from the source MAP sector.
8. The updated source MAP sector is written into the MAP block.
9. The updated EBM sector is written into the MAP block.
リスト管理
図１８は、様々なリスト間の制御およびディレクトリ情報の分配および流れを示す。便宜のために、リストの要素間でエントリを移動する動作、またはエントリの属性を変更する動作は、［Ａ］から［Ｏ］として図１８に示され、以下のようなものである。
［Ａ］消去済みブロックがホストデータについての更新ブロックとして割り当てられる場合には、そのエントリのＡＢＬ内にある属性は、消去済みＡＢＬブロックから開放更新ブロックに変更される。
［Ｂ］消去されたブロックが制御ブロックとして割り当てられる場合には、ＡＢＬ内のそのエントリが除去される。
［Ｃ］ＡＢＬエントリが開放更新ブロック属性と共に作成される場合には、更新中の論理グループについての元メタブロックアドレスを記録するために、関連する元ブロックフィールドがエントリに付加される。この情報は、ＧＡＴから取得される。
［Ｄ］更新ブロックが閉鎖されると、そのエントリのＡＢＬ内にある属性は、開放更新ブロックから閉鎖更新ブロックへ変更される。
［Ｅ］更新ブロックが閉鎖されると、その関連する元ブロックは消去されて、ＡＢＬ内にあるそのエントリ内の関連する元ブロックフィールドの属性は、消去済み元ブロックに変更される。
［Ｆ］ＡＢＬ充填動作中、同一の制御書き込み動作中にＧＡＴ内でアドレスが更新された閉鎖更新ブロックはどれでも、そのエントリがＡＢＬから除去される。
［Ｇ］ＡＢＬ充填動作中、閉鎖更新ブロックについてのエントリがＡＢＬから除去されると、その関連する消去済みの元ブロックについてのエントリが、ＣＢＬへ移動される。 ［Ｈ］制御ブロックが消去されると、それについてのエントリが、ＣＢＬへ追加される。
［Ｉ］ＡＢＬ充填動作中、消去済みブロックエントリが、ＥＢＢリストからＡＢＬへ移動され、消去済みＡＢＬブロックの属性が与えられる。
［Ｊ］ＡＢＬ充填動作中のすべての該当ＡＢＬエントリの修正後、ＡＢＬ内のブロックアドレスが、ＡＢＢリスト内のブロックアドレスに取って代わる。
［Ｋ］制御書き込み中にＡＢＬ充填動作と並行して、ＣＢＬ内の消去済みブロックについてのエントリが、ＣＢＢリストへ移動される。
［Ｌ］ＭＡＰ交換動作中、すべての該当エントリが、ＣＢＢリストからＭＡＰ送信先セクタへ移動される。
［Ｍ］ＭＡＰ交換動作中、すべての該当エントリが、ＣＢＢリストからＭＡＰ送信元セクタへ移動される。
［Ｎ］ＭＡＰ交換動作中の［Ｌ］および［Ｍ］に続いて、すべての残りのエントリが、ＣＢＢリストからＥＢＢリストへ移動される。
［Ｏ］ＭＡＰ交換動作中の［Ｎ］に続いて、可能であれば、［Ｍ］において移動されたもの以外のエントリが、ＭＡＰ送信元セクタから移動されて、ＥＢＢリストを充填する。
List Management FIG. 18 illustrates the distribution and flow of control and directory information between the various lists. For convenience, the operation of moving entries between elements of the list, or the operation of changing the attributes of the entries is shown in FIG. 18 as [A] to [O] and is as follows.
[A] When an erased block is assigned as an update block for host data, the attribute in the ABL of the entry is changed from the erased ABL block to the release update block.
[B] If an erased block is assigned as a control block, its entry in the ABL is removed.
[C] If an ABL entry is created with the open update block attribute, an associated original block field is added to the entry to record the original metablock address for the logical group being updated. This information is obtained from GAT.
[D] When the update block is closed, the attributes in the ABL of the entry are changed from the open update block to the closed update block.
[E] When an update block is closed, its associated original block is erased, and the attribute of the associated original block field in the entry in ABL is changed to the erased original block.
[F] During the ABL fill operation, any closed update block whose address is updated in the GAT during the same control write operation has its entry removed from the ABL.
[G] During an ABL fill operation, when the entry for a closed update block is removed from the ABL, the entry for its associated erased source block is moved to the CBL. [H] When the control block is erased, an entry for it is added to CBL.
[I] During an ABL fill operation, erased block entries are moved from the EBB list to the ABL and given the attributes of the erased ABL block.
[J] After modifying all relevant ABL entries during ABL filling operation, the block address in ABL replaces the block address in ABB list.
[K] During control write, in parallel with the ABL filling operation, the entry for the erased block in the CBL is moved to the CBB list.
[L] During the MAP exchange operation, all corresponding entries are moved from the CBB list to the MAP destination sector.
[M] During the MAP exchange operation, all corresponding entries are moved from the CBB list to the MAP source sector.
[N] Following [L] and [M] in the MAP exchange operation, all remaining entries are moved from the CBB list to the EBB list.
[O] Following [N] in the MAP exchange operation, if possible, entries other than those moved in [M] are moved from the MAP source sector to fill the EBB list.
論理／物理アドレス変換
フラッシュメモリ内の論理セクタの物理位置を位置決定するために、図２に示されている論理／物理アドレス変換モジュール１４０は、論理／物理アドレス変換を行う。最近更新された論理グループを除いて、大量の変換を、フラッシュメモリ２００またはコントローラＲＡＭ１３０内のＧＡＴキャッシュ内にあるグループアドレステーブル（ＧＡＴ）を使用して行うことになる可能性がある。最近更新された論理グループについてのアドレス変換は、主にコントローラＲＡＭ１３０内にある更新ブロックについてのアドレスリストを検索することを必要とすることになる。したがって、論理セクタアドレスについての論理／物理アドレス変換のための処理は、セクタが位置する論理グループに関連したブロックの種類に依存する。ブロックの種類には、変化のないブロックと、順次データ更新ブロックと、カオス的データ更新ブロックと、閉鎖データ更新ブロックとがある。
Logical / Physical Address Translation The logical / physical
図１９は、論理／物理アドレス変換の処理を示すフローチャートである。基本的には、対応するメタブロックおよび物理セクタは、論理セクタアドレスを使用して、最初に、開放更新ブロックリストおよび閉鎖更新ブロックリストなどの様々な更新ディレクトリを検索することによって、位置決定される。関連するメタブロックが更新処理の一部でない場合、ディレクトリ情報がＧＡＴによって提供される。論理／物理アドレス変換は、以下のステップを含む。
ステップ８００：論理セクタアドレスが与えられる。
ステップ８１０：コントローラＲＡＭ内の開放更新ブロックリスト６１４（図１５および１８参照）内の所定の論理アドレスが検索される。検索が失敗すると、ステップ８２０へ進み、そうでなければ、ステップ８３０へ進む。
ステップ８２０：閉鎖更新ブロックリスト６１６内の所定の論理アドレスを検索する。検索が失敗すると、所定の論理アドレスはどの更新処理の一部でもないことになり、ＧＡＴアドレス変換のためのステップ８７０へ進む。そうでなければ、閉鎖更新ブロックアドレス変換のためのステップ８６０へ進む。
ステップ８３０：所定の論理アドレスを含む更新ブロックが順次であれば、順次更新ブロックアドレス変換のためのステップ８４０へ進む。そうでなければ、カオス的更新ブロックアドレス変換のためのステップ８５０へ進む。
ステップ８４０：順次更新ブロックアドレス変換を使用して、メタブロックアドレスを取得する。ステップ８８０へ進む。
ステップ８５０：カオス的更新ブロックアドレス変換を使用して、メタブロックアドレスを取得する。ステップ８８０へ進む。
ステップ８６０：閉鎖更新ブロックアドレス変換を使用して、メタブロックアドレスを取得する。ステップ８８０へ進む。
ステップ８７０：グループアドレステーブル（ＧＡＴ）変換を使用して、メタブロックアドレスを取得する。ステップ８８０へ進む。
ステップ８８０：メタブロックアドレスを物理アドレスに変換する。変換方法は、メタブロックが再リンクされているかどうかに依存する。
ステップ８９０：物理セクタアドレスが取得される。
FIG. 19 is a flowchart showing processing of logical / physical address conversion. Basically, the corresponding metablocks and physical sectors are located by searching the various update directories, such as the open update block list and the closed update block list, first using the logical sector address . Directory information is provided by GAT if the associated metablock is not part of the update process. Logical / physical address translation includes the following steps.
Step 800: A logical sector address is provided.
Step 810: A predetermined logical address in the open update block list 614 (see FIGS. 15 and 18) in the controller RAM is searched. If the search fails, proceed to step 820, otherwise proceed to step 830.
Step 820: Search for a predetermined logical address in the closed
Step 830: If the update block including the predetermined logical address is sequential, proceed to step 840 for sequential update block address conversion. Otherwise, proceed to step 850 for chaotic update block address translation.
Step 840: Obtain metablock address using sequential update block address translation. Proceed to step 880.
Step 850: Obtain a metablock address using chaotic update block address translation. Proceed to step 880.
Step 860: Obtain metablock address using closed update block address translation. Proceed to step 880.
Step 870: Obtain a metablock address using a group address table (GAT) translation. Proceed to step 880.
Step 880: Convert the metablock address to a physical address. The conversion method depends on whether the metablock is relinked.
Step 890: A physical sector address is obtained.
様々なアドレス変換処理について、以下により詳細に説明する。
順次更新ブロックアドレス変換（ステップ８４０）
順次更新ブロックに関連した論理グループ内の対象論理セクタアドレスについてのアドレス変換は、以下のように、開放更新ブロックリスト６１４内の情報から直接達成される（図１５および１８）。
１．リスト内の「ページタグ」フィールドおよび「書き込みセクタの数」フィールドから、対象論理セクタが更新ブロックにあるか、またはその関連する元ブロックにあるかどうかを判断する。
２．対象論理セクタに適切なメタブロックアドレスが、リストから読み出される。
３．メタブロック内のセクタアドレスが、適切な「ページタグ」フィールドから決定される。
Various address translation processes are described in more detail below.
Sequential Update Block Address Translation (Step 840)
Address translation for the target logical sector address in the logical group associated with the sequential update block is achieved directly from the information in the open
1. From the "page tag" field and the "number of write sectors" field in the list, it is determined whether the target logical sector is in the update block or in its associated original block.
2. The appropriate metablock address for the target logical sector is read from the list.
3. The sector address in the metablock is determined from the appropriate "page tag" field.
カオス的更新ブロックアドレス変換（ステップ８５０）
カオス的更新ブロックに関連した論理グループ内の対象論理セクタアドレスについてのアドレス変換シーケンスは、以下の通りである。
１．ＲＡＭ内のカオス的セクタリストから、セクタが最近書き込まれたセクタであると判断される場合には、アドレス変換は、このリスト内のその位置から直接達成されてもよい。
２．ＣＢＩブロック内の直近に書き込まれたセクタは、そのカオス的ブロックデータフィールド内に、対象論理セクタアドレスに該当するカオス的更新ブロックの物理アドレスを含む。また、その間接セクタインデックスフィールド内に、このカオス的更新ブロックに関連する最終書き込みＣＢＩセクタのＣＢＩブロック内のオフセットを含む（図１６Ａ〜１６Ｅ参照）。
３．これらのフィールド内の情報は、ＲＡＭ内にキャッシュされ、後続のアドレス変換中にセクタを読み出す必要をなくしている。
４．間接セクタインデックスフィールドによってステップ３において識別されたＣＢＩセクタが読み出される。
５．直近にアクセスされたカオス的更新サブグループについての直接セクタインデックスフィールドは、ＲＡＭ内にキャッシュされ、同一のカオス的更新ブロックに対する繰り返しのアクセスのためのステップ４における読み出しを行う必要をなくしている。
６．ステップ４または５において読み出された直接セクタインデックスフィールドは、対象論理セクタアドレスを含む論理サブグループに関連するＣＢＩセクタを識別する。
７．対象論理セクタアドレスについてのカオス的ブロックインデックスエントリは、ステップ６において識別されたＣＢＩセクタから読み出される。
８．直近に読み出されたカオス的ブロックインデックスフィールドは、コントローラＲＡＭ内にキャッシュされてもよく、同一の論理サブグループに対する繰り返しのアクセスのためのステップ４およびステップ７における読み出しを行う必要をなくしている。
９．カオス的ブロックインデックスエントリは、カオス的更新ブロックまたは関連する元ブロックのいずれかの内に対象論理セクタの位置を規定する。対象論理セクタの有効コピーが元ブロック内にあれば、元メタブロックおよびページタグ情報を使用して位置決定される。
Chaotic Update Block Address Translation (Step 850)
The address translation sequence for the target logical sector address in the logical group associated with the chaotic update block is as follows.
1. If it is determined from the chaotic sector list in RAM that the sector is a recently written sector, address translation may be achieved directly from its location in this list.
2. The most recently written sector in the CBI block contains, within its chaotic block data field, the physical address of the chaotic update block that corresponds to the target logical sector address. Also included in the indirect sector index field is the offset within the CBI block of the last write CBI sector associated with this chaotic update block (see FIGS. 16A-16E).
3. The information in these fields is cached in RAM, eliminating the need to read the sector during subsequent address translation.
4. The CBI sector identified in
5. The direct sector index field for the most recently accessed chaotic update subgroup is cached in RAM, eliminating the need to perform the read in
6. The direct sector index field read in
7. The chaotic block index entry for the target logical sector address is read from the CBI sector identified in
8. The most recently read chaotic block index field may be cached in the controller RAM, eliminating the need to perform the read in
9. The chaotic block index entry defines the location of the target logical sector within either the chaotic update block or the associated original block. If a valid copy of the target logical sector is in the original block, it is located using the original metablock and page tag information.
閉鎖更新ブロックアドレス変換（ステップ８６０）
閉鎖更新ブロックに関連した論理ブロックループ内の対象論理セクタアドレスについてのアドレス変換は、以下のように、閉鎖ブロック更新リスト内の情報から直接達成することができる（図１８参照）。
１．対象論理グループに割り当てられたメタブロックアドレスは、リストから読み出される。
２．メタブロック内のセクタアドレスは、リスト内の「ページタグ」フィールドから決定される。
Closed update block address translation (step 860)
Address translation for the target logical sector address in the logical block loop associated with the closed update block can be achieved directly from the information in the closed block update list as follows (see FIG. 18).
1. The metablock address assigned to the target logical group is read from the list.
2. The sector address in the metablock is determined from the "page tag" field in the list.
ＧＡＴアドレス変換（ステップ８７０）
論理グループが開放または閉鎖ブロック更新リストのいずれかによって参照されない場合には、ＧＡＴ内のそのエントリは有効である。ＧＡＴによって参照される論理グループ内の対象論理セクタアドレスについてのアドレス変換シーケンスは、以下の通りである。
１．ＲＡＭ内の使用可能なＧＡＴキャッシュの範囲を評価して、対象論理グループについてのエントリがＧＡＴキャッシュ内に含まれるかどうかを判断する。
２．対象論理グループがステップ１において見つかった場合、ＧＡＴキャッシュは、メタブロックアドレスおよびページタグを含む全グループアドレス情報を含み、対象論理セクタアドレスの変換が可能となる。
３．対象アドレスがＧＡＴキャッシュ内にない場合、ＧＡＴインデックスを対象ＧＡＴブロックについて読みだして、対象論理グループアドレスに関するＧＡＴセクタの位置を識別しなければならない。
４．最後にアクセスされたＧＡＴブロックについてのＧＡＴインデックスは、コントローラＲＡＭ内に保持され、フラッシュメモリからセクタを読み出す必要なくアクセスされてもよい。
５．各ＧＡＴブロックについてのメタブロックアドレスのリストと、各ＧＡＴブロック内に書き込まれたセクタの数とが、コントローラＲＡＭ内に保持される。必要なＧＡＴインデックスがステップ４において使用可能でない場合、フラッシュメモリからすぐに読み出されてもよい。
６．対象論理グループアドレスに関するＧＡＴセクタは、ステップ４またはステップ６において取得されたＧＡＴインデックスによって規定されたＧＡＴブロック内のセクタ位置から読み出される。ＧＡＴキャッシュが、対象エントリを含むセクタの再分割部分によって更新される。
７．対象セクタアドレスは、対象ＧＡＴエントリ内のメタブロックアドレスおよび「ページタグ」フィールドから取得される。
GAT address translation (step 870)
If the logical group is not referenced by either the open or closed block update list, then its entry in the GAT is valid. The address translation sequence for the target logical sector address in the logical group referenced by GAT is as follows.
1. The extent of available GAT cache in RAM is evaluated to determine if an entry for the subject logical group is included in the GAT cache.
2. If the target logical group is found in
3. If the target address is not in the GAT cache, the GAT index must be read for the target GAT block to identify the location of the GAT sector with respect to the target logical group address.
4. The GAT index for the last accessed GAT block may be kept in the controller RAM and accessed without having to read the sector from the flash memory.
5. A list of metablock addresses for each GAT block and the number of sectors written in each GAT block are kept in the controller RAM. If the required GAT index is not available at
6. The GAT sector relating to the target logical group address is read from the sector position in the GAT block defined by the GAT index obtained in
7. The target sector address is obtained from the metablock address in the target GAT entry and the "page tag" field.
メタブロック／物理アドレス変換（ステップ８８０）
メタブロックが再リンクされていることをメタブロックアドレスに関連したフラグが示されている場合、該当ＬＴセクタがＢＬＭブロックから読み出されて、対象セクタアドレスについての消去ブロックアドレスであると決定する。そうでなければ、消去ブロックアドレスは、メタブロックアドレスから直接決定される。
Metablock to physical address conversion (step 880)
If a flag associated with the metablock address indicates that the metablock is relinked, the corresponding LT sector is read from the BLM block and determined to be the erase block address for the target sector address. Otherwise, the erase block address is determined directly from the metablock address.
スクラッチパッドブロック
他の実施形態において、スクラッチパッドブロック（「ＳＰＢ」）が、更新ブロックに書き込まれたデータをバッファするために実施される。不揮発性メモリへの更新データは、所定の条件によっては、更新ブロックまたはスクラッチパッドブロックのいずれかといった、少なくとも２つのインターリーブするストリームに記憶されてもよい。スクラッチパッドブロックは、最終的には更新ブロックを宛て先とする更新データをバッファするために使用される。好ましい一実施形態において、スクラッチパッドブロックに記憶されたデータのインデックスに加えて、更新ブロックに記憶されたデータのインデックス（「ＳＰＢＩ／ＣＢＩ」）も、コントローラＲＡＭのデータ構造に維持される。これらのデータ構成により、スクラッチパッドブロック（ＳＰＢ）およびカオス的ブロック内のすべての有効なセクタの追跡および高速アクセスが可能になる。後述するように、ＳＰＢＩ／ＣＢＩデータは、スクラッチパッドブロックのページの未使用部分に適時セーブされることになる。
Scratch Pad Block In another embodiment, a scratch pad block ("SPB") is implemented to buffer data written to the update block. Update data to non-volatile memory may be stored in at least two interleaving streams, such as either an update block or a scratch pad block, depending on predetermined conditions. The scratch pad block is used to buffer update data ultimately destined for the update block. In a preferred embodiment, in addition to the index of data stored in the scratch pad block, the index of data stored in the update block ("SPBI / CBI") is also maintained in the data structure of the controller RAM. These data structures allow tracking and fast access of all valid sectors in scratch pad blocks (SPBs) and chaotic blocks. As will be described later, SPBI / CBI data will be saved timely in the unused portion of the page of the scratch pad block.
この実施形態において、図１９に示すアドレス変換は、ＳＰＢにバッファされた任意のデータのルックアップを含むように修正される。よって、「更新ブロックを開放」８１０および「連続更新ブロック」８３０は、ＳＰＢにバッファされたデータがあるかどうかを判断するための追加のクエリボックスである。データがなければ、フローは「連続更新ブロック」８３０ヘ進み、そうでなければ、「メタブロックから物理アドレスへの変換モジュール」８９０へ進む前に、ＳＰＢアドレス変換があることになる。
スクラッチパッドブロックの実施例については、２００６年７月１３日公開のGorobetsらによる「Non-Volatile Memory And Method With Improved Indexing For Scratch Pad And Update Blocks 」という米国公開特許出願第２００６／０１５５９２２号（特許文献１９）に記載されている。
In this embodiment, the address translation shown in FIG. 19 is modified to include a lookup of any data buffered in the SPB. Thus, "release update block" 810 and "continuous update block" 830 are additional query boxes to determine if there is data buffered in the SPB. If there is no data, then the flow goes to "Continuous Update Block" 830, otherwise there will be SPB address translation before going to "Transform module from metablock to physical address" 890.
For an example of the scratch pad block, US Patent Application No. 2006/0155922 entitled “Non-Volatile Memory And Method With Improved Indexing For Scratch Pad And Update Blocks” by Gorobets et al., Published on July 13, 2006. 19).
制御データ管理
図２０は、メモリ管理の動作過程において制御データ構造に対して行われる動作のヒエラルキーを示す。データ更新管理動作は、ＲＡＭに常駐する様々なリストに対して作用する。制御書き込み動作は、フラッシュメモリ内の様々な制御データセクタおよび専用ブロックに対して作用すると共に、ＲＡＭ内のリストとデータを交換する。
Control Data Management FIG. 20 shows a hierarchy of operations performed on control data structures in the memory management operation process. Data update management operations operate on various lists resident in RAM. Control write operations operate on various control data sectors and dedicated blocks in flash memory and exchange data with lists in RAM.
データ更新管理動作は、ＲＡＭ内において、ＡＢＬ、ＣＢＬ、スクラッチパッドセクタリスト／カオス的セクタリストに対して行われる。ＡＢＬは、消去ブロックが更新ブロックまたは制御ブロックとして割り当てられるか、または更新ブロックが閉鎖されると更新される。ＣＢＬは、制御ブロックが消去されるか、または閉鎖更新ブロックに対するエントリがＧＡＴに書き込まれると更新される。スクラッチパッドセクタリストは、セクタがスクラッチパッドブロックに書き込まれると更新される。更新カオス的セクタリストは、セクタがカオス的更新ブロックに書き込まれると更新される。ここで、セクタは、書き込みデータの単位の一例であって、ページとも称されることが理解される。 Data update management operations are performed on ABL, CBL, scratch pad sector list / chaotic sector list in RAM. The ABL is updated when the erase block is assigned as an update block or control block or when the update block is closed. The CBL is updated when the control block is erased or an entry for a closed update block is written to the GAT. The scratch pad sector list is updated as sectors are written to the scratch pad block. The updated chaotic sector list is updated as sectors are written to the chaotic update block. Here, it is understood that a sector is an example of a unit of write data and is also referred to as a page.
制御書き込み動作によって、ＲＡＭ内の制御データ構造からの情報がフラッシュメモリ内の制御データ構造に書き込まれ、その結果、必要があれば、フラッシュメモリおよびＲＡＭ内の他の支援制御データ構造の更新を伴う。これは、更新ブロックとして割り当てるべき消去ブロックに対するエントリをＡＢＬがこれ以上含まない場合か、またはＳＰブロックが書き換えられる場合かのいずれかの場合にトリガされる。 The control write operation writes information from the control data structure in the RAM to the control data structure in the flash memory so that, if necessary, updating the flash memory and other supporting control data structures in the RAM. . This is triggered when the ABL does not contain any more entries for the erase block to be allocated as an update block or when the SP block can be rewritten.
好ましい実施形態において、ＡＢＬフィル動作と、ＣＢＬ空き（ｅｍｐｔｙ）動作と、ＥＢＭセクタ更新動作とが、各制御書き込み動作中に行われる。ＥＢＭセクタを含むＭＡＰブロックが一杯になると、有効なＥＢＭおよびＭＡＰセクタが、割り当てられた消去ブロックにコピーされ、以前のＭＡＰブロックは消去される。
１つのＧＡＴセクタが書き込まれ、それにしたがって、各制御書き込み動作中に、閉鎖更新ブロックリストが修正される。
ＧＡＴブロックが一杯になって、割り当てられた消去ブロックに当該一杯のブロックデータがリロケートすることになると、１つのＧＡＴブロック書き換えが生じる。
ＳＰＢＩ／ＣＢＩセクタは、あるカオス的セクタ書き込み動作の後に書き込まれる。
ＳＰＢＩ／ＣＢＩブロックが一杯になると、ＳＰＢブロック書き換えが生じる。有効なＳＰＢＩ／ＣＢＩセクタが、割り当てられた消去ブロックへコピーされ、以前のＳＰＢブロックは消去される。
In the preferred embodiment, ABL fill operations, CBL empty operations, and EBM sector update operations are performed during each control write operation. When the MAP block containing the EBM sector is full, valid EBM and MAP sectors are copied to the assigned erase block and the previous MAP block is erased.
One GAT sector is written, and the closed update block list is modified accordingly during each control write operation.
When the GAT block becomes full and the full block data is to be relocated to the allocated erase block, one GAT block rewrite occurs.
The SPBI / CBI sectors are written after some chaotic sector write operation.
When the SPBI / CBI block is full, SPB block rewrite occurs. Valid SPBI / CBI sectors are copied to the assigned erase block and the previous SPB block is erased.
ＭＡＰ交換動作は、前述したように、ＥＢＭセクタ内のＥＢＢリストにこれ以上消去ブロックエントリがない場合に行われる。
ＭＡＰブロックが一杯になって、有効なＥＢＭおよびＭＡＰセクタが、割り当てられた消去ブロックへコピーされると、ＭＡＰブロック書き換えが生じ、以前のＭＡＰブロックは消去される。
ブートセクタは、ＭＡＰブロックが移動される各場合に、現在のブートブロックに書き込まれる。
ブートブロックが一杯になると、ブートブロック書き換えが生じる。有効なブートセクタは、ブートブロックの現在のバージョンからバックアップバージョンへコピーされ、その後、現在のバージョンとなる。以前の現在のバージョンは消去され、バックアップバージョンとなり、有効なブートセクタが書き戻される。
The MAP exchange operation is performed when there are no more erase block entries in the EBB list in the EBM sector, as described above.
When the MAP block is full and valid EBM and MAP sectors are copied to the assigned erase block, a MAP block rewrite occurs and the previous MAP block is erased.
The boot sector is written to the current boot block each time a MAP block is moved.
When the boot block is full, boot block rewrite occurs. Valid boot sectors are copied from the current version of the boot block to the backup version and then become the current version. The previous current version is erased and becomes a backup version, and a valid boot sector is written back.
制御データの例としては、図２０に関して説明したような、ディレクトリ情報およびメモリブロック管理システムに関連したブロック割り当て情報がある。前述したように、制御データは、高速ＲＡＭおよびより低速な不揮発性メモリブロックの両方で保持される。任意の頻繁に変化する制御データがＲＡＭで保持され、不揮発性メタブロックに記憶された対応情報を更新するための定期的な制御書き込みを伴う。このように、制御データは、頻繁なアクセスを必要とせずに、不揮発であるがより低速なフラッシュメモリに記憶される。図２０に示すブートセクタ、ＧＡＴ、ＳＢＩ／ＣＢＩ、およびＭＡＰなどの制御データ構造のヒエラルキーがフラッシュメモリに保持される。よって、制御書き込み動作によって、ＲＡＭ内の制御データ構造からの情報が、フラッシュメモリ内の対応制御データ構造を更新する。 Examples of control data include directory information and block allocation information associated with the memory block management system, as described with respect to FIG. As mentioned above, control data is held in both the fast RAM and the slower non-volatile memory block. Any frequently changing control data is held in RAM, with periodic control writes to update the correspondence information stored in the non-volatile metablock. In this way, control data is stored in non-volatile but slower flash memory without the need for frequent access. A hierarchy of control data structures such as the boot sector, GAT, SBI / CBI, and MAP shown in FIG. 20 is held in the flash memory. Thus, the control write operation causes the information from the control data structure in the RAM to update the corresponding control data structure in the flash memory.
図２０に関連して説明したように、ブロック管理システムは、その動作中にフラッシュメモリ内の制御データのセットを保持する。制御データのこのセットは、ホストデータと同様のメタブロックに記憶される。このように、制御データ自体はブロック管理されることになり、更新を受けることになるので、ガーベッジコレクション動作を受けることになる。 As described in connection with FIG. 20, the block management system maintains a set of control data in flash memory during its operation. This set of control data is stored in metablocks similar to host data. In this way, the control data itself is block-managed and will be updated, so it will be subject to garbage collection operations.
ワンタイムプログラマブルメモリ（「ＯＴＰ」）
あるメモリアプリケーションでは、データが、再び更新されないメモリ用であるとされる。したがって、このようなアプリケーション用のメモリ装置は、ワンタイムプログラマブルメモリ、言い換えればＯＴＰメモリ装置と称されるが、消去および再プログラム機構を提供する必要がない。ＯＴＰメモリ装置は、簡易なブロック管理システムを有し得るので、複雑性およびオーバーヘッドを軽減する。
One-time programmable memory ("OTP")
In some memory applications, data may be for memory that is not updated again. Thus, although memory devices for such applications are referred to as one-time programmable memories, in other words OTP memory devices, there is no need to provide erase and reprogram mechanisms. OTP memory devices may have a simple block management system, thus reducing complexity and overhead.
本願明細書において説明するブロック管理システムは、ＯＴＰメモリ装置の実装に対応している。実質的にＯＴＰメモリにとって、各ブロックは、メモリストレージの単位として扱われる。前述した消去ブロック管理システムとの違いは、ブロックが消去されないということである。しかし、あるブロックから他のブロックへのプリエンプティブなデータのリロケートの手法は、ＯＴＰメモリに対しても等しく適用可能である。
ＯＴＰメモリシステムは、２００６年３月２日公開の「Method and Apparatus for Using a One-Time or Few-Time Programmable Memory with a Host Device designated for Erasable/Rewritable Memory」という米国公開特許出願第２００６／００４７９２０号（特許文献２０）に記載されている。
The block management system described herein corresponds to the implementation of an OTP memory device. Essentially for OTP memory, each block is treated as a unit of memory storage. The difference with the erase block management system described above is that the blocks are not erased. However, the preemptive data relocation approach from one block to another is equally applicable to OTP memory.
The OTP memory system is disclosed in US Patent Application No. 2006/0047920, published on March 2, 2006, entitled "Method and Apparatus for Using a One-Time Programmable Memory with a Host Device Designated for Erasable / Rewritable Memory". (Patent Document 20).
プリエンプティブなデータのリロケート
前述したように、制御データのヒエラルキーがあり、低ヒエラルキーのものほど、高ヒエラルキーのものよりも頻繁に更新される。例えば、各制御ブロックは書き込むべきＮ個の制御セクタを有するものとすると、制御更新およびブロックリロケートの以下のようなシーケンスが通常生じる。図２０を再び参照すると、各Ｎ個のＳＰＢＩ／ＣＢＩ更新はＳＰブロックを埋めて、ＳＰＢリロケート（書き換え）およびＭＡＰ更新をトリガする。カオス的ブロックが閉鎖されると、ＧＡＴ更新をもトリガしてもよい。各ＧＡＴ更新は、ＭＡＰ更新をトリガする。各Ｎ個のＧＡＴ更新はブロックを埋めて、ＧＡＴブロックのリロケートをトリガする。加えて、ＭＡＰブロックが一杯になると、ＭＡＰブロックのリロケートおよびブートブロック更新をもトリガする。加えて、ブートブロックが一杯になると、アクティブなブートブロックを他のブートブロックへリロケートすることをトリガする。
Re-positioning of Preemptive Data As described above, there is a control data hierarchy, and the one with low hierarchy is updated more frequently than the one with high hierarchy. For example, assuming that each control block has N control sectors to be written, the following sequence of control update and block relocation usually occurs. Referring again to FIG. 20, each N SPBI / CBI updates fill the SP block and trigger SPB relocation and MAP updates. GAT updates may also be triggered when a chaotic block is closed. Each GAT update triggers a MAP update. Each N GAT update fills the block and triggers relocation of the GAT block. In addition, when the MAP block is full, it also triggers relocation and boot block updates of the MAP block. In addition, when the boot block becomes full, it triggers the relocation of the active boot block to another boot block.
ヒエラルキーは、最上部にあるブート制御データ、それに続いてＭＡＰ、そしてＧＡＴからなるので、場合によっては、ＧＡＴ更新の後に「カスケード制御更新」があることになる。そこでは、ＧＡＴ、ＭＡＰ、およびブートブロックのすべてがリロケートされることになる。ホスト書き込みの結果、カオス的または連続更新ブロック閉鎖によってＧＡＴ更新が生じる場合には、ガーベッジコレクション動作（例えば、リロケートまたは書き換え）があることになる。カオス的更新ブロックのガーベッジコレクションの場合には、ＳＰＢＩ／ＣＢＩインデックスが更新されることになり、これは、ＳＰブロックのリロケートもトリガし得る。よって、このような極端な状況では、数多くのメタブロックに対して同時にガーベッジコレクションが行われる必要がある。 The hierarchy consists of boot control data at the top, followed by MAP, and then GAT, so in some cases there will be a "cascade control update" after the GAT update. There, GAT, MAP, and the boot block will all be relocated. As a result of host writes, there will be garbage collection operations (eg, relocation or rewriting) if GAT updates occur due to chaotic or continuous update block closure. In the case of garbage collection of chaotic update blocks, the SPBI / CBI index will be updated, which may also trigger relocation of SP blocks. Thus, in such extreme situations, garbage collection needs to be performed simultaneously for many metablocks.
ヒエラルキーの各制御データブロックは、一杯になってリロケートされるという点で、それぞれ独自の周期性を有する。それぞれが通常通り進めば、数多くのブロックの位相が並んで、同時にすべてのブロックを伴う大規模なリロケートまたはガーベッジコレクションをトリガすることになる。多くの制御ブロックのリロケートには長い時間がかかり、ホストによっては、そのような大規模な制御動作によって生じる長時間の遅延に耐えられないものもあるので、避けるべきである。 Each control data block of the hierarchy has its own periodicity, in that it is full and relocated. If each goes as usual, the phases of many blocks will line up and trigger massive relocation or garbage collection with all blocks at the same time. The relocation of many control blocks takes a long time, and some hosts can not tolerate the long delays caused by such large control operations and should be avoided.
例えば、このような望ましくない状況は、ブロック管理システムの動作を制御するために使用される制御データを更新する際に生じ得る。制御データ型のヒエラルキーは、様々な度合いの更新頻度と共に存在し得、関連更新ブロックが異なるレートでガーベッジコレクションまたはリロケートを必要とするという結果となる。１つより多い制御データ型のガーベッジコレクション動作が一致する場合があることになる。極端な状況において、制御データ型すべてのブロックのリロケートフェーズは並び得るので、すべてのブロックがリロケートまたは書き換えを同時に必要とするという結果となる。 For example, such undesirable situations may occur in updating control data used to control the operation of the block management system. A control data type hierarchy may exist with varying degrees of update frequency, resulting in related update blocks requiring garbage collection or relocation at different rates. Garbage collection operations of more than one control data type may coincide. In extreme situations, the relocation phase of all control data type blocks can be aligned, resulting in all blocks requiring relocation or rewriting simultaneously.
データのカスケードリロケートを回避するために１つの解決策が、２００５年６月３０日公開のGorobetsらによる「Non-Volatile Memory and Method with Control Data Management 」という米国公開特許出願第２００５／０１４４３６５号（特許文献１６）に記載されている。ブロック管理システムを有する不揮発性メモリにおいて、メモリブロックのプリエンプティブなリロケートまたは制御された書き換えは、数多くの制御更新ブロックが偶然にも同時にリロケートする必要があるという状況を回避するために実施される。この望ましくない状況は、現在のホスト動作がハウスキーピング動作にも対応可能なときにはいつでも、ブロックが完全に埋められる前に制御ブロックのプリエンプティブなリロケートが生じることで回避される。特に、最速のフィルレートを有するデータ型を有するブロックに優先権が与えられる。本方法は、問題となる様々なブロックのフェーズが揃うことを回避するために、ある種のディザリングを混合体全体に導入するものとみなされることができる。よって、機会があればいつでも、完全に埋められるよりもわずかにマージンを有する高速フィリングブロックが、プリエンプティブにリロケートされることになる。 One solution to avoid cascading data relocation is described in US Published Patent Application No. 2005/0144365 entitled "Non-Volatile Memory and Method with Control Data Management" by Gorobets et al., Published June 30, 2005. It describes in the literature 16). In non-volatile memory with block management systems, preemptive relocation or controlled rewriting of memory blocks is implemented to avoid the situation where many control update blocks need to be relocated simultaneously by chance. This undesirable situation is avoided by causing a preemptive relocation of the control block before the block is completely filled, whenever the current host operation can also accommodate the housekeeping operation. In particular, blocks with data types with the fastest fill rates are given priority. The method can be viewed as introducing some kind of dithering throughout the mixture to avoid the phase alignment of the various blocks in question. Thus, whenever there is an opportunity, fast filling blocks with a slight margin rather than being completely filled will be relocated preemptively.
時間バジェット分析を伴う内部ハウスキーピング動作のスケジューリング
前に述べたように、制御データを含むブロックが一杯になると、書き換え動作が必要となる。一連の更新を経た後には、埋められたブロックは、典型的には、有効なデータと共に古いデータをも含む。有効なデータは、空き空間を有する他のブロックへコピーされることになる。このリロケート動作は、ガーベッジコレクション動作であり、この動作において、有効なデータが回収されて他のブロックへコピーされた後に全ブロックが消去および再利用される。リロケートの他の理由は、ブロック内で不具合が生じた場合に、ブロックを使用できないようにすることである。これは、内蔵の誤り訂正符号によって過度の誤り訂正を必要とするか、または単に訂正ができない不具合について、特に当てはまる。リロケートのさらに他の理由は、ブロックが過度の消去／プログラムサイクリングを受けて早く消耗してしまわないように、メモリ内のすべてのブロックの均一な使用を確保する必要があるということである。
As mentioned before the scheduling of the internal housekeeping operation with time budget analysis , a rewrite operation is required when the block containing the control data is full. After undergoing a series of updates, the filled block typically also includes old data as well as valid data. Valid data will be copied to other blocks with free space. This relocation operation is a garbage collection operation, in which all blocks are erased and reused after valid data is recovered and copied to other blocks. Another reason for relocation is to make the block unusable if a failure occurs in the block. This is especially true for faults that require excessive error correction with built-in error correction codes, or can not simply be corrected. Yet another reason for relocation is that it is necessary to ensure uniform use of all blocks in memory so that the blocks do not wear out quickly due to excessive erase / program cycling.
前述したリロケート動作は、システムのハウスキーピング動作のすべての例である。データをあるブロックから他へリロケートすることは、かなりのデータ量を読み出しおよび書き込むことを伴うので、典型的には比較的時間がかかる。ハウスキーピング動作は、ホストがメモリにアクティブに関わっていないときにバックグラウンドで行われ得る。しかし、進行中に、ホストがコマンドをメモリへ送ることができず、電力低下になって、進行中のハウスキーピング動作を中断することがある。好ましいやり方の１つは、メモリがホストコマンドを実行するのと同時に、ハウスキーピング動作をフォアグラウンドで行うことである。 The relocation operations described above are all examples of housekeeping operations of the system. Relocating data from one block to another typically involves relatively time consuming as it involves reading and writing a significant amount of data. Housekeeping operations may occur in the background when the host is not actively engaged in memory. However, while in progress, the host may not be able to send commands to memory and may lose power and interrupt ongoing housekeeping operations. One of the preferred ways is to perform the housekeeping operation in the foreground at the same time as the memory executes the host command.
２００６年７月２０日公開のBennett らによる「Scheduling of Housekeeping Operations in Flash Memory Systems 」という米国公開特許出願第２００６／０１６１７２８号（特許文献２１）は、特定のホストコマンドを実行するために確立された時間バジェット内で１つ以上のこのようなハウスキーピング動作と共に行われるホストコマンドの実行を開示している。特に、そのようなホストコマンドの１つは、受信されているデータをメモリへ書き込むことである。そのようなハウスキーピング動作の１つは、繰り返しの消去および再プログラミングを通じて蓄積する個別ブロックの消耗を同等にすることである。 US Published Patent Application No. 2006/0161728, entitled "Scheduling of Housekeeping Operations in Flash Memory Systems" by Bennett et al. Published July 20, 2006, was established to execute specific host commands. It discloses the execution of host commands performed with one or more such housekeeping operations within a time budget. In particular, one such host command is to write the data being received to memory. One such housekeeping operation is to equalize the depletion of individual blocks that accumulate through repeated erasure and reprogramming.
最悪の場合における制御データ管理
本発明によれば、長時間にわたって行われ得る制御データのカスケード更新を回避するために、改良された手法が提供される。これは、制御データの型毎にブロックマージンを設定して、当該ブロックマージンに到達したもっとも早い時機にブロックを書き換えることによって達成される。特に、マージンは、書き換えが生じ得る前にブロックをすべて埋めてしまわないように、書き換えが生じ得る前に所定の間隔で蓄積されたデータを収容するのにちょうど十分であるように設定される。当該所定の間隔は、とりわけ、書き換えが生じ得る前に最悪の場合における間隔を生じさせるホスト書き込みパターンを考慮することによって決定される。マージンを設定するための他の考慮事項としては、ホストデータを記憶するための更新ブロックの構成に基づく、制御ブロック書き換え毎に必要な時間と、制御ブロック書き換えのために利用可能な時間と、フォアグラウンドホスト動作およびホスト書き込みレイテンシにおいて必要な時間とが含まれる。
Worst Case Control Data Management In accordance with the present invention, an improved approach is provided to avoid cascading control data updates that may occur over time. This is achieved by setting a block margin for each type of control data and rewriting the block at the earliest when the block margin is reached. In particular, the margin is set to be just enough to accommodate the data accumulated at a predetermined interval before rewriting can occur, so that it does not fill the entire block before rewriting can occur. The predetermined interval is determined, inter alia, by considering the host write pattern which gives rise to the interval in the worst case before rewriting can occur. Other considerations for setting the margin include the time required for each control block rewrite, the time available for control block rewrite, and the foreground based on the configuration of the update block for storing host data. It includes the time required for host operation and host write latency.
また、本願の改良は、カスケード制御更新毎の複数のプログラムエラーに備えるものであり、限られた時間内にすぐに次々と生じる１つのＥＣＣまたはプログラムエラーに対処することができる。この特徴は、ワンタイムプログラマブル（「ＯＴＰ」）メモリにとって特に重要である。なぜならば、障害が低レベルにおいてパッチされない場合にはリスクが非常に高いからである。また、本願の改良は、最小限のブロックが、制御データを記憶するための更新ブロックのプールに予約されるようにすることができる。予約ブロックにより、メモリ制御システムは、すべての制御データブロックが同時に埋められる可能性があるという最悪のカスケード更新を処理することができ、予約ブロックすべて、同じビジーな期間に書き換えられなければならない。制御データ用に予約される必要のあるブロックが少なければ、より多くのブロックをホストデータ更新用に利用することが可能となる。 Also, the improvement of the present application is to prepare for multiple program errors per cascade control update, and can cope with one ECC or program error immediately occurring one after another within a limited time. This feature is particularly important for one-time programmable ("OTP") memories. Because the risk is very high if the fault is not patched at low levels. Also, the refinement of the present application may allow a minimum of blocks to be reserved in the pool of update blocks for storing control data. The reserved blocks allow the memory control system to handle the worst cascade update that all control data blocks may be filled simultaneously, and all reserved blocks must be rewritten in the same busy period. If fewer blocks need to be reserved for control data, more blocks can be used for host data updates.
本発明の利点には、以下のものがある。最悪の場合における更新シーケンスにおいて、より多くのエラーを処理することができる。ガーベッジコレクション（ＧＣ）の最も長い組み合わせと制御ブロックの圧縮という最悪の場合を回避することができる。例えば、カオス的ＧＣは、連続ＧＣよりも長く生じるので、制御更新をカオス的ＧＣと同時に行うことを回避することによって、この最悪の場合のコマンドレイテンシを軽減することができる。ブロックマージンを最良に選択して（例えば、圧縮のためのフラー制御ブロックを選択）、実行する内部動作をスケジューリングすることによって、最適性能が得られる。最悪の場合の更新シーケンスを処理するために、予約消去ブロックの数を減少させることが必要である。プリエンプティブな内部動作の場合には、エラー処理を再スケジューリングすることができるので、遥かに高速にエラーを処理することができる。部分的なエラー処理およびエラー処理のスケジューリング完了が可能である。読み出し動作中にＥＣＣエラー処理をスケジューリングすることができ、これは、レイテンシが短く、後で実行される（例えば、次の書き込み動作中など）。 Among the advantages of the invention are: More errors can be processed in the update sequence in the worst case. The worst case of the longest combination of garbage collection (GC) and control block compression can be avoided. For example, since chaotic GCs occur longer than continuous GCs, this worst case command latency can be reduced by avoiding simultaneous control updates with chaotic GCs. Optimal performance is obtained by scheduling the internal operations to be performed with the best choice of block margins (e.g., select fuller control blocks for compression). In order to handle the worst case update sequence, it is necessary to reduce the number of reserved erase blocks. In the case of preemptive internal operations, error handling can be rescheduled, so errors can be handled much faster. Partial error handling and scheduling completion of error handling is possible. ECC error handling can be scheduled during a read operation, which has a short latency and will be performed later (eg, during the next write operation, etc.).
ホストコマンド動作期間の推定
書き込みホストデータなどの典型的なホストコマンドにおいて、ホストは、メモリがコマンドを完了するのに最悪の場合における状況に対処するように設計されたタイムアウトまたは書き込みレイテンシを指定する。メモリがコマンドを実行する実際の期間は、データが書き込まれつつあるメモリブロックの状態による。特に、さらに時間のかかるブロック間のデータリロケートを書き込みが含むかどうかによる。このようなデータリロケートは、新規のブロックが割り当て中であることに応じたブロックの閉鎖によって生じる。ブロックの閉鎖は、典型的には、消去および再利用される前にガーベッジコレクションが必要である。
Estimated Write of Host Command Operation Period In a typical host command, such as host data, the host specifies a timeout or write latency designed to handle the worst case situation for the memory to complete the command. The actual time that the memory executes the command depends on the state of the memory block where the data is being written. In particular, depending on whether the write involves data relocation between the more time consuming blocks. Such data relocation is caused by the closing of blocks in response to new blocks being allocated. Block closure typically requires garbage collection before being erased and reused.
更新ブロックのプールの構成
ブロックは、典型的には、一杯になったか、または何らかの理由でデータがもはや書き込まれなくなると閉鎖される。ブロックが閉鎖されるタイミングに影響を与える他の要因は、同時に更新のために開放された更新ブロックのプールがどのように構成されているかである。プール内のブロックの数には限りがあるので、新規のブロックが完全に埋まったプールに導入されると、既存のブロックは閉鎖されなければならない。
The constituent blocks of the pool of update blocks are typically closed when they are full or data is no longer written for some reason. Another factor that affects when the blocks are closed is how the pool of update blocks opened at the same time for updates is configured. Due to the limited number of blocks in the pool, when new blocks are introduced into a completely filled pool, existing blocks must be closed.
同時に開放されている更新ブロックの最大数までサポートするという実際上のシステム制限については前に述べた。例えば、図１０に関連して説明した一実施形態において、ステップ４１０は、新規の割り当てによって、更新データを受け付けるために同時に開放され得る更新ブロックの最大数ＵMAX を超えることになるかどうかをテストする。ＵMAX を超えることになる場合には、更新ブロックのうちで最もアクティブでないものがステップ４２０において閉鎖されることになり、所定の制限内にシステムを維持する。
The practical system limitation of supporting up to the maximum number of update blocks open at the same time was mentioned earlier. For example, in one embodiment described in connection with FIG. 10, step 410 tests whether the new assignment will exceed the maximum number U MAX of update blocks that can be released simultaneously to accept update data. Do. If U MAX is to be exceeded, the least active of the update blocks will be closed at
一杯のプールにある更新ブロックのうちのいずれを閉鎖するかを選択する他のやり方は、２００６年９月１５日出願のJason Lin による「Method For Class-Based Update Block Replacement Rules In Non-Volatile Memory」という米国特許出願第１１／５３２，４５６号（特許文献２２）に記載されている。 Another way to select which of the update blocks in the full pool are to be closed is the "Method For Class-Based Update Block Replacement Rules In Non-Volatile Memory" by Jason Lin, filed September 15, 2006. No. 11 / 532,456, which is incorporated herein by reference.
図２１は、ブロック管理システムのための更新ブロック数に対する２つの所定の制限を概略的に示す。システムによって保持される更新ブロックのプール内の全体的な制限がある。更新ブロックの総数は、最大数（ＵMAX ）を超えることはできず、これは、カオス的更新ブロックＮC の数と連続更新ブロックＮS の数との合計によって与えられる。よって、更新プールは、連続およびカオス的更新ブロックが混在したものを含み得る。カオス的更新ブロックは、より多くのリソースを要し、カオス的ブロックインデックス（ＣＢＩ）をさらに保持することを必要とし、好ましくは、カオス的更新ブロックの最大数（「ＵCMAX」）に対する規制もある。よって、第１の規制は、更新ブロック総数ＮC ＋ＮS ＜＝ＵMAX であることを要求する。第２の規制は、カオス的更新ブロック数ＮC ＜＝ＵCMAXであることを要求する。したがって、連続更新ブロックがＮS ＝ＵMAX であることもあり得るが、一般的には、カオス的更新ブロック数ＵCMAXはＵMAX より小さい。 FIG. 21 schematically illustrates two predetermined limits on the number of update blocks for a block management system. There is an overall limit within the pool of update blocks held by the system. The total number of update blocks can not exceed the maximum number (U MAX ), which is given by the sum of the number of chaotic update blocks N C and the number of consecutive update blocks N S. Thus, the update pool may include a mix of continuous and chaotic update blocks. Chaotic update blocks require more resources, require more chaotic block index (CBI) retention, and preferably also have restrictions on the maximum number of chaotic update blocks ("U CMAX ") . Thus, the first restriction requires that the total number of update blocks N C + N S <= U MAX . The second restriction requires that the number of chaotic update blocks N C <= U CMAX . Therefore, it is also may be continuous update block is N S = U MAX, in general, a chaotic update blocks U CMAX is less than U MAX.
図２２は、様々なメモリ装置に最適な２つの制限の組み合わせの典型例を示す。ＵMAX 様々なメモリ装置用に最適化された２つの規制の組み合わせの典型例を示す。ある組み合わせは、ＵMAX 「ダッシュ」ＵCMAXによって指定される。例えば、「３−１」は、更新プール内の最大３つの更新ブロックを許容し、そのうち１つまでのみがカオス的更新ブロックであるブロック管理システムを指定する。同様に、「７−３」は、最大７つの更新ブロックまでをサポートし、そのうち３つまでがカオス的更新ブロックであり得るブロック管理システムを指定する。一般的に、小さいメモリ容量を有する単純なメモリシステムほど、制限が厳しくなり、最大数が小さくなることになる。 FIG. 22 illustrates a typical example of a combination of two limits that is optimal for various memory devices. U MAX illustrates a typical example of a combination of two regulations optimized for various memory devices. One combination is specified by U MAX "dash" U CMAX . For example, "3-1" allows up to three update blocks in the update pool, and specifies a block management system in which only one of them is a chaotic update block. Similarly, "7-3" supports up to seven update blocks, of which up to three specify block management systems that may be chaotic update blocks. In general, the simpler the memory system with the smaller memory capacity, the tighter the limit and the smaller the maximum number.
図２３Ａ、図２３Ｂ、および図２３Ｃは、新規の更新ブロックを更新ブロックのプールに導入するためのイベントのシーケンスを概略的に示すものであって、結果、既存の連続ブロックの閉鎖となる。
図２３Ａは、図２２において説明したような「５−２」構成の更新プールを概略的に示す。本例において、更新プールは、最大５つの許容更新ブロックによって完全に埋められている。更新プールは、３つの連続更新ブロックＳ１、Ｓ２およびＳ３を含む連続プール１２００と、最大２つのカオス的または不連続更新ブロックＣ４およびＣ５を含むカオス的プール１３００とにさらに分割される。この例は、最もアクティブでないブロックが偶然にも１２０１のＳ３のような連続更新ブロックであることを示す。
Figures 23A, 23B, and 23C schematically illustrate the sequence of events for introducing a new update block into the pool of update blocks, resulting in the closure of existing contiguous blocks.
FIG. 23A schematically illustrates an updated pool of “5-2” configuration as described in FIG. In this example, the update pool is completely filled with up to five allowed update blocks. The update pool is further divided into a
新規の更新ブロックを割り当てる必要がある場合には、空きを作るために、更新プール内の既存の更新ブロックのうちの１つが閉鎖される必要があることになる。例えば、プール内の既存の更新ブロックによってサービス提供されていないセクタの論理グループについて連続データをホストが書き込む場合には、当該データを記録するために、新規の更新ブロックを割り当てる必要がある。 If a new update block needs to be allocated, one of the existing update blocks in the update pool will need to be closed to make room. For example, if the host writes continuous data for a logical group of sectors not served by an existing update block in the pool, a new update block needs to be allocated to record that data.
図２３Ｂは、新規の更新ブロック用に空きを作るために最もアクティブでない更新ブロックを閉鎖することを概略的に示す。最もアクティブでない更新ブロックは、この場合では偶然にも１２０１のＳ３であり、閉鎖されて更新ブロックのプールから削除されることになる。前述したように、連続ブロックの閉鎖は、一般的には、あったとしても比較的小さなリロケートを伴うものであり、例えば、いずれの残りの空き空間をも他のブロックからコピーされたデータでパディングするなどである。 FIG. 23B illustrates schematically closing the least active update block to make room for a new update block. The least active update block, which in this case happens to be S3 of 1201, will be closed and removed from the pool of update blocks. As mentioned above, closure of successive blocks generally involves relatively little, if any, relocation, eg, padding any remaining free space with data copied from other blocks And so on.
図２３Ｃは、空きを作るために閉鎖された更新ブロックが削除された後、新たに割り当てられた更新ブロックをプールに導入することを概略的に示す。この場合、データを論理的に連続した順序で記録するために、新規に割り当てられた更新ブロックである１２１２のＳ６が、連続プール１２００に導入されることになる。このように、許容される更新ブロックの最大数であるＵMAX を超えることはない。
FIG. 23C illustrates schematically introducing a newly allocated update block into the pool after the closed update block has been deleted to make room. In this case, S6 of 1212 which is a newly allocated update block will be introduced to the
図２４Ａ、図２４Ｂ、および図２４Ｃは、新規の更新ブロックを更新ブロックのプールに導入するためのイベントのシーケンスを概略的に示すものであって、結果、既存の連続ブロックの閉鎖となる。
図２４Ａは、図２２において説明したような「５−２」構成の更新プールを概略的に示す。この例において、更新プールは、最大５つの許容更新ブロックで完全に埋められている。更新プールは、３つの連続更新ブロックＳ１、Ｓ２およびＳ３を含む連続プール１２００と、最大２つのカオス的または不連続更新ブロックＣ４およびＣ５を含むカオス的プール１３００とにさらに分割される。本例は、閉鎖されるべきカオス的ブロックが偶然にも１３０１のＣ４のようなカオス的更新ブロックであることを示す。
Figures 24A, 24B, and 24C schematically illustrate the sequence of events for introducing a new update block into the pool of update blocks, resulting in the closure of an existing contiguous block.
FIG. 24A schematically illustrates an updated pool of “5-2” configuration as described in FIG. In this example, the update pool is completely filled with up to five allowed update blocks. The update pool is further divided into a
図２４Ｂは、新規のカオス的更新ブロック用に空きを作るためにカオス的更新ブロックを閉鎖することを概略的に示す。例えば、連続更新ブロックＳ１が非連続にデータを記録し始め、カオス的更新ブロックである１３１２のＣ１に変わる場合には、既存のカオス的ブロック（例えば、１３０１のＣ４）が閉鎖され、カオス的プール１３００から除去されることになる。他の例として、カオス的更新ブロックである１３０１のＣ４が一杯になる場合がある。これは、このデータが圧縮されて新規のカオス的ブロックになった後に閉鎖されて、プールから除去されることになる。前述したように、カオス的ブロックの閉鎖は、統合を伴ってもよく、この統合において、カオス的ブロックが、統合されたデータを乗せている新規のブロックに取って代わられる。
FIG. 24B schematically illustrates closing a chaotic update block to make room for a new chaotic update block. For example, if successive update block S1 starts to record data non-consecutively and changes to C1 of 1312 which is a chaotic update block, the existing chaotic block (eg, C4 of 1301) is closed and chaotic pool It will be removed from 1300. As another example, C4 of the
図２４Ｃは、空きを作るために閉鎖されたカオス的更新ブロックが削除された後、新たに割り当てられた更新ブロックをプールに導入することを概略的に示す。この場合、新規に割り当てられたカオス的更新ブロックである１３１２のＣ１が、閉鎖されたカオス的ブロックである１３０１のＣ４に取って代わることになり、統合されたデータを乗せている（図２４Ｂ参照）。カオス的プール１３００に新規に導入された１３１２のＣ１は、論理的に不連続な順序でデータを記録することになる。このように、許容されるカオス的更新ブロックの最大数であるＵCMAXを超えることはない。
FIG. 24C illustrates schematically introducing a newly allocated update block into the pool after the closed chaotic update block has been deleted to make room. In this case, C1 of 1312 which is a newly allocated chaotic update block replaces C4 of 1301 which is a closed chaotic block, and carries integrated data (see FIG. 24B). ). The 1312 C1 newly introduced into the
ホストコマンド実行タイミング
図２５Ａから図２５Ｄは、メモリに対するホスト書き込みコマンドのタイミング例を示す。典型的には、ホストは、メモリが実行する書き込みコマンドを発行する。ホストは、コマンドが完了すると見込まれる特定のタイムアウトまたは書き込みレイテンシを有する。メモリがホストコマンドを実行中に、ビジー（ＢＵＳＹ）信号をホストに対してアサートすることによって、この状況を通信する。ビジー信号が書き込みレイテンシ期間を超える場合には、ホストはタイムアウトして、書き込みコマンドを中止することになる。メモリがレイテンシ期間内に書き込みコマンドを完了させた場合には、ビジー信号から準備完了（ＲＥＡＤＹ）という信号にし、実行が済んで次のコマンドを受信する準備ができたことをホストに対してデアサートすることになる。
Host Command Execution Timing FIGS. 25A-25D illustrate example timings of host write commands to memory. Typically, the host issues a write command that the memory executes. The host has a specific timeout or write latency that is expected to complete the command. This condition is communicated by asserting a busy (BUSY) signal to the host while the memory is executing a host command. If the busy signal exceeds the write latency period, the host will time out and abort the write command. If the memory completes the write command within the latency period, the busy signal is signaled ready (READY), and the host deasserts that it has been executed and ready to receive the next command. It will be.
図２５Ａ〜図２５Ｄは、書き込みデータの性質およびリソースが限られたプール内の更新ブロックの状態によって実行期間が異なる場合があるといる様々な場面を示す。
図２５Ａは、単純な連続更新を伴うホスト書き込みをメモリが実行する際のタイミング図を概略的に示す。ホスト書き込み１は、あるホストデータがブロック１などのブロックに書き込まれるという単純な更新である。図２３Ａにおける例を使用すると、データは、連続更新プール１２００内の、例えばＳ１などの連続ブロックに追加される。図２５Ａから、他のデータのリロケートが含まれないというこの単純な場合においては、書き込み動作は、書き込みコマンドのためのレイテンシ期間ＴW内でうまく完了される。同様に、カオス的プール１３００内のカオス的ブロックへの単純な書き込みも、他のデータのリロケートが含まれなければ、比較的速いものとなる。
25A-25D illustrate various situations where the execution period may differ depending on the nature of the write data and the state of the update block in the resource limited pool.
FIG. 25A schematically illustrates a timing diagram when the memory performs a host write with a simple sequential update. Host write 1 is a simple update in which certain host data is written to a block such as
図２５Ｂは、連続更新に加えて他の連続ブロックの閉鎖を伴うホスト書き込みをメモリが実行する際のタイミング図を概略的に示す。ホスト書き込み２において、データの書き込みは、偶然にも、データを記録するための新規の連続ブロックの割り当てを要する。例えば、データは、更新プール内のいずれの更新ブロックによっても現在対象となっていない論理グループに属する。図２３Ｂにおける例を使用すると、更新プールは既に７つの更新ブロックという最大数にあるので、既存の更新ブロックのうちの１つをまず閉鎖して、新たに割り当てられたもののために空きを作らなければならない。この場合、連続ブロックＳ３が閉鎖される。これは、典型的には、他のブロックから転送された既存のデータで残りの空き空間がパディングされる。図２３Ｃにおける例も参照すると、新規の連続ブロックＳ６が割り当てられて、その後、ホストはデータをそこへ書き込むことになる。図２５Ｂから、この連続閉鎖の場合、連続ブロックの閉鎖というさらなる動作のために書き込み動作は完了するに少し時間がかかるが、それでも、全体の動作は、書き込みコマンドのためのレイテンシ期間ＴW 内でうまく収まる。
FIG. 25B schematically illustrates a timing diagram when the memory performs a host write with consecutive updates as well as the closure of other consecutive blocks. In
図２５Ｃは、カオス的更新に加えて他のカオス的更新ブロックの閉鎖およびリロケートを伴うホスト書き込みをメモリが実行する際のタイミング図を概略的に示す。ホスト書き込み３において、データの書き込みは、不連続で連続ブロックに書き込まれる。これは、連続ブロックがカオス的ブロックになるという効果があり、実際、新規のカオス的ブロックを更新プールに割り当てる必要がある。図２４Ｂにおける例を使用すると、カオス的更新プール１３００は最大数である２つの更新ブロックに既に達しているので、新規に割り当てられるもののために空きを作るために、既存のカオス的更新ブロックのうちの１つ（例えば、１３０１のＣ４）が最初に閉鎖されなければならない。この場合、カオス的ブロックＣ４は、そのデータが新規に割り当てられたブロック（例えば、１３１２のＣ６）へリロケートされた後に閉鎖される。図２４Ｃにおける例も参照すると、新規のカオス的ブロックＣ６が割り当てられて、カオス的更新プール内のＣ４に取って代わる。その後、ホストは、データをそこに書き込む。図２５Ｃから、このカオス的閉鎖の場合には、書き込み動作は、カオス的ブロックを閉鎖するという追加の動作のために、完了にさらに時間がかかることがわかるだろう。一般的には、カオス的ブロックの閉鎖には、連続ブロックの閉鎖よりも多くのデータのリロケートを要するので、それには比較的長い時間がかかることになる。しかし、それでも、カオス的ブロックの閉鎖とカオス的書き込みとを組みあわせた全体の動作は、書き込みコマンドのためのレイテンシ期間ＴW 内に収まる。
FIG. 25C schematically illustrates a timing diagram when the memory performs a host write with the closing and relocation of other chaotic update blocks in addition to the chaotic update. In
図２５Ｄは、カオス的更新に加えて他のカオス的更新ブロックを閉鎖する際の２つのパスを伴うホスト書き込みをメモリが実行する際のタイミング図を概略的に示す。本例は、図２５Ｃに示す例と同様だが、Ｃ４の閉鎖からデータのリロケートが１回より多く繰り返される。これは、Ｃ４からのデータがＣ６に統合されて、Ｃ６において不具合が生じる場合に起こり得る。圧縮されたデータを受信するためには、さらに他の新規ブロックを割り当てる必要があることになる。図２５Ｄから、エラーが生じるというこのカオス的閉鎖の場合には、書き込み動作は図２５Ａから図２５Ｃに示す場合よりも長く時間がかかることになることがわかるだろう。これは、カオス的ブロックのデータを２回リロケートしなければならないからである。この場合には、全体の動作は、実施的に、書き込みコマンドのためのレイテンシ期間ＴW のほとんどを使い尽くす。プログラムエラーをリアルタイムで処理することを回避するための一方法は、米国公開特許出願第２００５／０１４４３６５号（特許文献１６）に記載されている。代わりに、生じたエラーは、後に取り扱われる。このように、ＴW を超えるという危険は、後で実行されるべきスケジューリングされたタスクの数への加算という犠牲によって最小限にされる。 FIG. 25D schematically illustrates a timing diagram when the memory performs a host write with two passes in closing another chaotic update block in addition to the chaotic update. This example is similar to the example shown in FIG. 25C, but data relocation from C4 closure is repeated more than once. This can happen if data from C4 is integrated into C6 and a failure occurs at C6. In order to receive compressed data, it will be necessary to allocate yet another new block. It will be appreciated from FIG. 25D that for this chaotic closure where an error occurs, the write operation will take longer than in the case shown in FIGS. 25A-25C. This is because the data of the chaotic block has to be relocated twice. In this case, the entire operation is carried out, the exhausted most of the latency period T W for the write command. One method to avoid processing program errors in real time is described in US Published Patent Application No. 2005/0144365. Instead, errors that occur are handled later. Thus, the risk of exceeding T W is minimized at the cost of addition to the number of scheduled tasks to be performed later.
制御データブロックの書き換え
図２６は、制御データを記憶するために予約されたブロックのプールを概略的に示す。図２０に示す例を使用すると、４種類の制御情報があり、少なくとも１つのブロックは、各型の制御データを記憶するためのものである。よって、制御データブロック１４００のプールは、制御データを記憶するために予約された複数のブロック１４０２を含む。特に、ＭＡＰブロックは、ＭＡＰ制御データを記憶するためのものであり、ＧＡＴブロックは、ＧＡＴ制御データを記憶するためのものであり、ＳＰＢブロックは、ＳＰＢＩ／ＣＢＩ制御データを記憶するためのものであり、ブートブロックは、ブートブロック制御データを記憶するためのものである。
Rewriting of Control Data Blocks FIG. 26 schematically illustrates a pool of blocks reserved for storing control data. Using the example shown in FIG. 20, there are four types of control information, and at least one block is for storing control data of each type. Thus, the pool of control data blocks 1400 includes a plurality of
制御ブロックが一杯になると、内部書き換え動作によって、当該ブロックからプール内のそれに取って代わる新規ブロックへ有効なデータがリロケートされる。ある実施例において、書き換えのカスケードが同時に生じる場合には、複数の消去ブロック１４０６がプール内で予約される。
When the control block is full, the internal rewrite operation relocates valid data from the block to a new block that replaces it in the pool. In one embodiment, multiple erase
最悪の場合におけるカスケード更新は、ブートブロック、ＭＡＰブロック、スクラッチパッドブロック、およびＧＡＴブロックが同じビジー期間に書き換えられる場合である。これに加えてさらに悪いことには、カスケード更新は、ホスト書き込み中のブロックガーベッジコレクションと同時に生じ得る。そのようなカスケード更新を回避するために、制御ブロックがほとんど一杯になると、できるだけ早い時機に書き換えが行われることになり、最悪の場合のシナリオにおいて、危険なタイミングのホスト書き込みの結果として書き換えをせざるを得なくなる前に、プリエンプティブに制御ブロックを書き換えるのに充分な時間が常にあるようにする。 The worst case cascaded update is when the boot block, MAP block, scratch pad block, and GAT block are rewritten in the same busy period. Worse still, cascaded updates can occur simultaneously with block garbage collection during host writes. In order to avoid such cascaded updates, when the control block is almost full, rewriting will occur as soon as possible, and in the worst case scenario, rewriting as a result of host writes at dangerous timing Make sure that there is always enough time to rewrite the control block preemptively, before it becomes inevitable.
図２６は、制御ブロック１４０２毎の「ほとんど一杯である」しきい値またはマージン１４０４を示す。制御ブロックの書き込みポインタがこのしきい値に到達すると、ブロックを書き換えるためのフラグが設定されることになる。その後、ブロックは、次に最も早い時機に書き換えられることになる。そのようなプリエンプティブな書き換え手法も、米国特許出願公開第２００５／０１４４３６５号（特許文献１６）に開示されている。この「ほとんど一杯である」しきい値またはマージンの設定が高すぎると、ブロックは、書き換えをせざるを得なくなる前に書き換えられない場合がある。その一方で、このしきい値の設定が低すぎると、ブロックは、必要以上に頻繁に書き換えられることになり、データ構造を保持するオーバーヘッドが増加する。
FIG. 26 shows the “almost full” threshold or
１つより多い制御ブロックが同時にほとんど一杯になる場合には、制御ブロックは、所定の順序で書き換えられることになり、更新に利用可能なフリーの予約ブロック１４０６が常にあること、および、１つの制御ブロックに対する更新が他の制御ブロックの書き換えをトリガしてカスケードを強制することのないことを保証する。
If more than one control block is almost full at the same time, the control block will be rewritten in a predetermined order, there is always a free reserved
優先制御データ型
一実施例において、１つより多い制御ブロック書き込みが保留となっている場合には、よりアクティブな制御データ型のものが、ホスト動作において次に利用可能な機会に優先的に実行される。このように、一度に生じることになる制御ブロック書き換えは１つだけなので、制御ブロック書き換えのためのリソースとして必要最小限の予約ブロックが取っておかれる。
Priority Control Data Type In one embodiment, if more than one control block write is pending, the more active control data type will take precedence over the next available opportunity in host operation. Be done. As described above, since only one control block rewrite can occur at a time, a minimum necessary reservation block is reserved as a resource for the control block rewrite.
図２６は、好ましい一実施例に係る、ＭＡＰブロック→ＧＡＴブロック→ＳＰＢブロック→ブートブロックという順序で優先順位が付された制御データ型またはブロックを示す。一般的には、本順序は、アクティブなデータ型ほど書き換えの優先度が高くなることになる。また、ＭＡＰブロックをＧＡＴブロックよりも先に書き換えることによって、ＧＡＴブロック書き換えがＭＡＰブロック書き換えをトリガしないことが保証される。さらに、ＭＡＰブロック書き換えの後に、古いＭＡＰブロックが消去プールに戻されて、任意の後続の制御ブロック書き換えのために即座に再利用され得る。ＳＰＢの動作は、ホスト書き込みパターンによって左右され、代替の実施例において、ＧＡＴブロックより前に位置付けられ得る。ブートブロックは、他のブロックよりも更新頻度が低いので、書き換える緊急性が乏しいため、最も低い優先度が与えられる。このように、制御データブロックプール１４００内の予約ブロック１４０６の数は最小限に削減され、いつでも一度に１つの書き換えをサポートするために１つの予約ブロックとなる。
FIG. 26 illustrates control data types or blocks prioritized in the following order: MAP block → GAT block → SPB block → boot block according to a preferred embodiment. In general, in this order, the active data type has a higher priority of rewriting. Also, by rewriting the MAP block earlier than the GAT block, it is ensured that the GAT block rewrite does not trigger the MAP block rewrite. In addition, after MAP block rewrite, old MAP blocks may be returned to the erase pool for immediate reuse for any subsequent control block rewrites. The operation of the SPB is governed by the host write pattern, and may be positioned ahead of the GAT block in alternative embodiments. Since the boot block is updated less frequently than other blocks, it has the lowest priority because it is less urgent to rewrite. In this way, the number of
最悪の場合におけるホスト書き込みパターンについてのプリエンプティブな書き換えのためのマージンの設定
最悪の場合におけるホスト書き込みパターンが生じてもよいようにしきい値が設定されることを保証することによって、カスケード更新がいつでも確実に回避されることになる。制御データブロック（例えば、ＭＡＰ、ＧＡＴ、ＳＰＢ、およびブート）毎のしきい値は、最期から所定のページ数のマージンで設定される。ブロック毎の正確なマージンは、使用されるカスケードを回避する機構によって左右されることになる。
最悪の場合のシナリオは、各制御ブロック書き換え中に転送するデータページの最大量と、ホスト書き込み中に制御ブロック書き換えを重畳するための機会がほとんどないという結果になるホスト書き込みパターンという最悪の場合とによって、さらに悪化する。
Setting Margins for Preemptive Rewrite for Host Write Patterns in Worst Case Ensure that cascaded updates are always in place by ensuring that thresholds are set to allow host write patterns in the worst case to occur. Will be avoided. The threshold value for each control data block (for example, MAP, GAT, SPB, and boot) is set with a predetermined number of page margins from the end. The exact margin per block will depend on the mechanism that avoids the cascade used.
The worst case scenario is the worst case of a host write pattern, which results in the maximum amount of data pages transferred during each control block rewrite and there is little opportunity for superimposing control block rewrites during host writes. It gets worse by
データ型毎の書き換えのデータ量
前述した特定のメモリシステム例を使用すると、各制御ブロック書き換え中に転送するデータページの量という観点からの最悪の場合は、以下のようなものである。ＭＡＰブロック書き換えは、最大８つのＭＡＰセクタとＥＢＭセクタとをコピーすることを伴う。各セクタがあるページに書き込まれると、新規のＭＡＰブロックにコピーされるのは９ページになる。ＧＡＴブロック書き換えは、６４個のＧＡＴセクタをコピーして、新規のＧＡＴブロックにコピーされた１６ページとするのに加えて、１ページのＥＢＭ更新をＭＡＰブロックへ行うので、都合８ページをコピーするのに加えて１ページを書き換えることになる。スクラッチパッドブロック書き換えは、（更新プールに８ページあるとすると）バッファされたホストデータの８つのスクラッチパッドページを新規のＳＰブロックへコピーすることに加えて、新規のＳＰブロックに対する１つのスクラッチパッドインデックス更新と、１ページの１つのＥＢＭ更新とを伴い、都合８ページをコピーするのに加えて１ページを書き込むことになる。ブートブロック書き換えは、８つのＬＴセクタと、８つのＳＰＢＬセクタと、ブートセクタとのコピーを伴い、都合１７ページとなる。ブートブロックの２つのコピーがメモリに保持される場合には、コピーが繰り返される。
Using the specific memory system example described above for each data type, the worst case in terms of the amount of data pages transferred during each control block rewrite is as follows. MAP block rewriting involves copying up to eight MAP sectors and EBM sectors. When each sector is written to a page, nine pages are copied to a new MAP block. Since GAT block rewriting copies 64 GAT sectors into 16 pages copied to a new GAT block, EBM update of 1 page is performed to the MAP block, so 8 pages are copied. In addition to the one will rewrite the page. The scratch pad block rewrite adds one scratch pad index to the new SP block in addition to copying eight scratch pad pages of buffered host data to the new SP block (assuming 8 pages in the update pool) Along with the update and one EBM update of one page, one page will be written in addition to copying eight pages. The boot block rewrite involves copying of eight LT sectors, eight SPBL sectors, and a boot sector, resulting in 17 pages. If two copies of the boot block are kept in memory, the copy is repeated.
制御データブロック書き換えの４つの種類のそれぞれは、完了するのにかなりの時間を要することになる。更新プールが８個より少ない場合、またはホストデータがあまりバッファされる必要がない場合の一実施例において、ＳＰＢブロック書き換えは、他のものよりも高速である場合がある。なぜならば、コピーするページが比較的少ないからである。 Each of the four types of control data block rewrites will take considerable time to complete. In one embodiment where there are fewer than eight update pools, or less host data needs to be buffered, SPB block rewrite may be faster than others. This is because there are relatively few pages to copy.
最悪の場合におけるホスト書き込みのシーケンス中の様々なメモリ構成に関する制御ブロック書き換えの可能性のケーススタディ
プリエンプティブな制御ブロック書き換えを行うための理想的な時間は、ホストコマンドのフォアグラウンド実行に「重畳（ｐｉｇｇｙ−ｂａｃｋ）」することである。これは、新規のホストコマンド自体はガーベッジコレクションをトリガしないのでホストコマンドのレイテンシ期間内で制御ブロック書き換えを行う時間が多くあることになる場合には特に望ましい。しかし、多くの場合、ホスト書き込みなどのホストコマンドは、さらなるガーベッジコレクションと共に実行されることになる（連続ブロック閉鎖またはカオス的ブロック統合）。このような場合において、制御ブロック書き換えを重畳させる時間は少ないか、それどころか不十分なものとなる。
Case Study of Possibilities of Control Block Rewriting for Various Memory Configurations in a Worst Case Host Write Sequence The ideal time to do preemptive control block rewriting is: back). This is particularly desirable if the new host command itself does not trigger garbage collection, so that there will be a lot of time to do a control block rewrite within the latency period of the host command. However, in many cases host commands such as host writes will be performed with additional garbage collection (continuous block closure or chaotic block consolidation). In such a case, the time for superimposing control block rewriting is short or even insufficient.
特定のメモリシステムおよび構成についての以下のケーススタディは、最悪の場合におけるホスト書き込みパターンにおいて、各ホスト書き込みとともに連続ブロック閉鎖を得ることができることを示す（例えば、図２８Ｂ参照）。代わりに、カオス的ブロック統合を１つおきのホスト書き込みで得ることもできる。このような最悪の場合におけるシナリオで制御データ書き換えをスケジューリングする余裕を見いだすためには、様々なタイミングによる複数の書き換えスケジューリング方法が可能である。 The following case studies for specific memory systems and configurations show that in the worst case host write pattern, a continuous block closure can be obtained with each host write (see, eg, FIG. 28B). Alternatively, chaotic block consolidation can be obtained with alternate host writes. In order to find room for scheduling control data rewrite in such a worst case scenario, multiple rewrite scheduling methods with various timings are possible.
カスケード更新を保証するためには、少なくとも１つのプリエンプティブな制御ブロック書き換えがガーベッジコレクションと共に許可されなければならない。ある方法では、１つの制御ブロック書き換えが連続閉鎖と共に許可されるが、カオス的ブロック統合歯許可されない。なぜなら、連続閉鎖は、一般的には、より短い動作だからである。一般的に、数多くの統合を立て続けにトリガすることは可能ではない。ホストコマンド動作によってトリガされるガーベッジコレクションがない場合には、動作時間は、２つの制御ブロック書き換えまでをサポートできる。 In order to guarantee cascading updates, at least one preemptive control block rewrite must be allowed with garbage collection. In one method, one control block rewrite is allowed with continuous closure but chaotic block consolidation teeth are not allowed. Because continuous closure is generally a shorter operation. In general, it is not possible to trigger many integrations in quick succession. If there is no garbage collection triggered by host command operation, the operation time can support up to two control block rewrites.
この方法は、完全に一杯になる前の都合のよいときに制御ブロックを書き換えることとしている。これらのケーススタディの目的は、ガーベッジコレクションのオーバーヘッドに対するコマンドの最悪のシーケンスを見つけて、それらがトリガする更新を制御することである。これは、その後、制御ブロックが書き換えられるべき順序を規定するためと、ほとんど一杯であると思われる前にどれほどの空間を予約しなければならないかを規定するためとに使用され得る。 The method is to rewrite the control block at a convenient time before it is completely full. The purpose of these case studies is to find the worst sequence of commands to garbage collection overhead and control the updates they trigger. This can then be used to define the order in which the control blocks are to be rewritten and to define how much space must be reserved before it is considered almost full.
典型的な更新プール構成のための計算例（図２２参照）が示され、最大頻度のカオス的統合という最悪の場合と、一連の継続的な連続閉鎖という最悪の場合とを区別している。以下のような最悪の場合の前提がなされる。
（１）各書き込みは、スクラッチパッドに対する単一のセクタ書き込みである（１つのビジー期間のみで、少なくとも１つの制御ブロック書き込み）。
（２）各連続閉鎖は、スクラッチパッド更新をトリガする。これは、有効なホストデータがこのブロックについてのスクラッチパッドにある場合に生じる。
（３）各カオス的統合は、常にスクラッチパッド更新をトリガする。
（４）連続的からカオス的への各変換は、スクラッチパッド更新をトリガする。
（５）最悪のランの間に、ＭＡＰ更新のうちの１つがＭＡＰ交換を伴うことになる
（６）更新プールまたはブロックリストは常に一杯なので、新規の消去メタブロックに対する各要求は、ブロックリストの解放をトリガする（ＧＡＴおよびＭＡＰ更新）。
（７）すべてのＧＡＴ更新は、ＧＡＴブロックに向けられたものである。なぜならば、異なるＧＡＴブロックを更新すると、ＧＡＴブロックが一杯になるレートが遅くなるからである。
An example calculation (see FIG. 22) for a typical update pool configuration is shown to distinguish between the worst case of chaotic integration of maximum frequency and the worst case of a series of continuous continuous closures. The following worst case assumptions are made:
(1) Each write is a single sector write to the scratch pad (only one busy period, at least one control block write).
(2) Each successive closure triggers a scratch pad update. This occurs when valid host data is in the scratchpad for this block.
(3) Each chaotic integration always triggers a scratch pad update.
(4) Each conversion from continuous to chaotic triggers a scratch pad update.
(5) During the worst run, one of the MAP updates will involve a MAP exchange. (6) Because the update pool or block list is always full, each request for a new erase metablock is a block list of Trigger a release (GAT and MAP update).
(7) All GAT updates are directed to GAT blocks. This is because updating different GAT blocks slows the rate at which GAT blocks become full.
図２７Ａは、「７−３」更新プールを有するメモリ構成について最大頻度のカオス的ブロック統合を生じさせる、最悪の場合における書き込みパターンを示す表である。図２２と共に前述したように、「７−３」更新プール構成は、ホストデータを記憶するための最大５つの更新ブロックをメモリが同時にサポートし、そのうち最大３つの更新ブロックがカオス的または不連続であってもよいというものである。 FIG. 27A is a table showing a worst case write pattern that results in chaotic block consolidation of maximum frequency for memory configurations having a “7-3” update pool. As described above with reference to FIG. 22, in the “7-3” update pool configuration, the memory simultaneously supports up to five update blocks for storing host data, of which up to three update blocks are chaotic or discontinuous. It may be there.
更新プールの初期状態は、７つの更新ブロックすべてが開放され、そのうちの３つがカオス的更新ブロックである。ホスト書き込みパターンは、ホストが各連続更新ブロックに対してカオス的に書き込み、新規の連続ブロックを繰り返し開放し、次の書き込みではカオス的にするというものである。
ステップ０：初期状態
ステップ１：新規のメタブロック（ＧＡＴおよびＭＡＰ更新）およびスクラッチパッドへの書き込みが必要なカオス的ブロック１は閉鎖される。新規のコマンドによって、連続ブロック４はカオス的になり（スクラッチパッド更新）、その後、ホストデータをスクラッチパッドに書き込むことができるようになる。トリガされる全制御データは、１つのＧＡＴ更新と、１つのＭＡＰ更新と、３つのスクラッチパッド更新である。カオス的ブロックの閉鎖の結果、その上にある有効なデータが他のブロックへリロケート（または統合）される。本方法によれば、この統合オーバーヘッドによって、制御ブロックの書き換えはこのステップに重畳されないことになる。
ステップ２〜ステップ４：ステップ１と同様。よって、制御ブロックの書き換えは可能でない。
ステップ５：これがプリエンプティブな書き換えを行う最初の機会である。新規のコマンドによって、新規の連続更新ブロックが開放される。予備の更新ブロックがあるので、他のブロックは閉鎖される必要はないが、ホスト書き込みはスクラッチパッドへ向かい得る。この時点までに、４つのＭＡＰ更新と、４つのＧＡＴ更新と、１３個のスクラッチパッド更新を行うことができる。
ステップ６：ステップ１と同様
ステップ７：ステップ５と同様。この時点までに、６つのＭＡＰページと、６つのＧＡＴページと、１６個のスクラッチパッドページを書き込むことができる。
The initial state of the update pool is that all seven update blocks are open, three of which are chaotic update blocks. The host write pattern is such that the host chaotically writes to each successive update block, repeatedly releases new successive blocks, and chaos on the next write.
Step 0: Initial State Step 1:
Step 5: This is the first opportunity to do a preemptive rewrite. A new command releases a new continuous update block. Because there are spare update blocks, other blocks need not be closed, but host writes can go to the scratch pad. Up to this point, 4 MAP updates, 4 GAT updates, and 13 scratch pad updates can be done.
Step 6: Similar to Step 1 Step 7: Similar to Step 5 Up to this point, six MAP pages, six GAT pages, and sixteen scratch pad pages can be written.
よって、ＭＡＰブロックについて６つのフリーＭＡＰページと、ＧＡＴブロックについて４つのフリーＧＡＴページと、ＳＰブロックについて１６個のフリーのスクラッチパッドページとでマージンが設定される場合には、ステップ５においてＭＡＰおよびＧＡＴブロックを、ステップ７においてスクラッチパッドを書き換えることによって、カスケードを回避するために、様々な制御ブロックが間に合うように書き込まれることを保証することができる。
Thus, if the margin is set by 6 free MAP pages for MAP block, 4 free GAT pages for GAT block, and 16 free scratch pad pages for SP block, MAP and GAT in
図２７Ｂは、「７−３」更新プールを有するメモリ構成について継続的な一連の連続ブロック閉鎖を生じさせる、最悪の場合における書き込みパターンを示す表である。
更新プールの初期状態は、７つの更新ブロックすべてが開放され、そのうちの３つがカオス的更新ブロックであって一杯となっている。ホスト書き込みパターンは、ホストがカオス的ブロックを埋めるようにカオス的に書き込み、その後、連続更新ブロックを繰り返し開放するというものである。
ステップ０：初期状態
ステップ１：既に一杯のカオス的ブロック１に対して書き込む。これにより、ＧＡＴおよびＭＡＰ更新と、スクラッチパッド更新とをトリガする統合がトリガされる。新規の連続更新ブロックが開放され、ホストデータはスクラッチパッドに書き込まれる。
ステップ２およびステップ３：ステップ１と同様。
ステップ４：これがプリエンプティブな書き換えを行う最初の機会である。新規のコマンドは、新規更新ブロックを要し、既存の連続更新ブロックを閉鎖する。閉鎖は、スクラッチパッド書き込みを要し、新規のブロックは、ＧＡＴおよびＭＡＰ更新を要する。この時点までに、４つのＭＡＰ更新と、４つのＧＡＴ更新と、８個のスクラッチパッド更新を行うことができる。
ステップ５以降：ステップ４と同様に、それぞれ連続閉鎖をトリガし、１つのＧＡＴ更新と、１つのＭＡＰ更新と、２つのスクラッチパッド更新とをトリガする新規ブロックを割り当てる。
FIG. 27B is a table showing a worst case write pattern that results in a continuous series of consecutive block closures for a memory configuration having a "7-3" update pool.
In the initial state of the update pool, all seven update blocks are open, and three of them are chaotic update blocks and are full. The host write pattern is such that the host writes chaotically so as to fill the chaotic block, and then repeatedly releases the continuously updated block.
Step 0: Initial State Step 1: Write to
Step 4: This is the first opportunity to do a preemptive rewrite. The new command takes a new update block and closes the existing continuous update block. Closure requires scratch pad writes, new blocks require GAT and MAP updates. Up to this point, four MAP updates, four GAT updates, and eight scratch pad updates can be done.
ステップ４においてＭＡＰブロックが、ステップ５においてＧＡＴブロックが、ステップ６においてスクラッチパッドが書き換えられるとすると、ＭＡＰブロックには６ページ、ＧＡＴブロックには５ページ、スクラッチパッドブロックには１２ページでマージンを設定する必要がある。
Assuming that the MAP block is rewritten in
図２８Ａは、「３−１」更新プールを有するメモリ構成について最大頻度のカオス的ブロック統合を生じさせる、最悪の場合における書き込みパターンを示す表である。図２２と共に前述したように、「３−１」更新プール構成は、ホストデータを記憶するための最大３つの更新ブロックをメモリが同時にサポートし、３つの更新ブロックのうちのせいぜい１つがカオス的または不連続であってもよいというものである。 FIG. 28A is a table showing a worst case write pattern that results in chaotic block consolidation of maximum frequency for memory configurations having a “3-1” update pool. As described above with reference to FIG. 22, in the "3-1" update pool configuration, the memory simultaneously supports up to three update blocks for storing host data, and at most one of the three update blocks is chaotic or It may be discontinuous.
更新プールの初期状態は、３つの更新ブロックすべてが開放され、そのうちの１つがカオス的更新ブロックである。ホスト書き込みパターンは、ホストが各連続更新ブロックに対してカオス的に書き込み、新規の連続ブロックを繰り返し開放し、次の書き込みではカオス的にするというものである。
ステップ０：初期状態
ステップ１：新規のメタブロック（ＧＡＴおよびＭＡＰ更新）およびスクラッチパッドへの書き込みが必要なカオス的ブロック１は閉鎖される。新規のコマンドによって、連続ブロック２はカオス的になり（スクラッチパッド更新）、その後、ホストデータをスクラッチパッドに書き込むことができるようになる。合計で、１つのＧＡＴページと、１つのＭＡＰページと、３つのスクラッチパッドページである。
ステップ２：ステップ１と同様。
ステップ３：これがプリエンプティブな書き換えを行う最初の機会である。新規のコマンドによって、新規の連続更新ブロックが開放される。予備の更新ブロックがあるので、他のブロックは閉鎖される必要はないが、ホスト書き込みはスクラッチパッドへ向かい得る。この時点までに、３つのＭＡＰ更新と、３つのＧＡＴ更新と、７個のスクラッチパッド更新を行うことができる。
ステップ４：ステップ１と同様。
ステップ５：ステップ３と同様。この時点までに、６つのＭＡＰページと、６つのＧＡＴページと、１１個のスクラッチパッド更新を行うことができる。
The initial state of the update pool is that all three update blocks are open, one of which is a chaotic update block. The host write pattern is such that the host chaotically writes to each successive update block, repeatedly releases new successive blocks, and chaos on the next write.
Step 0: Initial State Step 1:
Step 2: Same as
Step 3: This is the first opportunity to do a preemptive rewrite. A new command releases a new continuous update block. Because there are spare update blocks, other blocks need not be closed, but host writes can go to the scratch pad. Up to this point, 3 MAP updates, 3 GAT updates, and 7 scratch pad updates can be done.
Step 4: Same as
Step 5: Same as
よって、ＭＡＰブロックについて５つのフリーＭＡＰページと、ＧＡＴブロックについて３つのフリーＧＡＴページと、ＳＰブロックについて１１個のフリーのスクラッチパッドページとでマージンが設定される場合には、ステップ３においてＭＡＰおよびＧＡＴブロックを、ステップ５においてスクラッチパッドを書き換えることによって、カスケードを回避するために、様々な制御ブロックが間に合うように書き込まれることを保証することができる。
Thus, if the margin is set by 5 free MAP pages for MAP block, 3 free GAT pages for GAT block, and 11 free scratch pad pages for SP block, MAP and GAT in
図２８Ｂは、「３−１」更新プールを有するメモリ構成について継続的な一連の連続ブロック閉鎖を生じさせる、最悪の場合における書き込みパターンを示す表である。
更新プールの初期状態は、３つの更新ブロックすべてが開放され、そのうちの１つがカオス的更新ブロックであって一杯となっている。ホスト書き込みパターンは、ホストがカオス的ブロックを埋めるようにカオス的に書き込み、その後、連続更新ブロックを繰り返し開放するというものである。
ステップ０：初期状態
ステップ１：既に一杯のカオス的ブロック１に対して書き込む。これにより、ＧＡＴおよびＭＡＰ更新と、スクラッチパッド更新とをトリガする統合がトリガされる。新規の連続更新ブロックが開放され、ホストデータはスクラッチパッドに書き込まれる。合計で２つのＧＡＴ更新と、２つのＭＡＰ更新と、２つのスクラッチパッド更新とをこの時点までに行うことができる。
ステップ２：これがプリエンプティブな書き換えを行う最初の機会である。新規のコマンドは、新規更新ブロックを要し、既存の連続更新ブロックを閉鎖する。閉鎖は、スクラッチパッド書き込みを要し、新規のブロックは、ＧＡＴおよびＭＡＰ更新を要する。この時点までに、３つのＭＡＰ更新と、３つのＧＡＴ更新と、６個のスクラッチパッド更新を行うことができる。
ステップ３以降：ステップ２と同様に、それぞれ連続閉鎖をトリガし、１つのＧＡＴ更新と、１つのＭＡＰ更新と、２つのスクラッチパッド更新とをトリガする新規ブロックを割り当てる。
FIG. 28B is a table showing a worst case write pattern that results in a continuous series of consecutive block closures for a memory configuration having a "3-1" update pool.
The initial state of the update pool is that all three update blocks are open, one of which is a chaotic update block and is full. The host write pattern is such that the host writes chaotically so as to fill the chaotic block, and then repeatedly releases the continuously updated block.
Step 0: Initial State Step 1: Write to
Step 2: This is the first opportunity to do a preemptive rewrite. The new command takes a new update block and closes the existing continuous update block. Closure requires scratch pad writes, new blocks require GAT and MAP updates. Up to this point, three MAP updates, three GAT updates, and six scratch pad updates can be done.
ステップ２においてＭＡＰブロックが、ステップ３においてＧＡＴブロックが、ステップ４においてスクラッチパッドが書き換えられるとすると、ＭＡＰブロックには５ページ、ＧＡＴブロックには４ページ、スクラッチパッドブロックには１０ページでマージンを設定する必要がある。
Assuming that the MAP block is rewritten in
図２９Ａは、「３−３」更新プールを有するメモリ構成について最大頻度のカオス的ブロック統合を生じさせる、最悪の場合における書き込みパターンを示す表である。図２２と共に前述したように、「３−３」更新プール構成は、ホストデータを記憶するための最大３つの更新ブロックをメモリが同時にサポートし、３つの更新ブロックのうちの任意のブロックがカオス的または不連続のいずれであってもよいというものである。 FIG. 29A is a table showing a worst case write pattern that results in chaotic block consolidation of maximum frequency for memory configurations having a “3-3” update pool. As described above with reference to FIG. 22, in the "3-3" update pool configuration, the memory simultaneously supports up to three update blocks for storing host data, and any one of the three update blocks is chaotic. Or discontinuous.
更新プールの初期状態は、３つの更新ブロックすべてが開放され、そのうちの３つがカオス的更新ブロックである。ホスト書き込みパターンは、ホストが各連続更新ブロックに対してカオス的に書き込み、新規の連続ブロックを繰り返し開放し、次の書き込みではカオス的にするというものである。
ステップ０：初期状態
ステップ１：新規のメタブロック（ＧＡＴおよびＭＡＰ更新）およびスクラッチパッドへの書き込みが必要なカオス的ブロック１は閉鎖される。新規のコマンドは、新規のメタブロック（ＧＡＴおよびＭＡＰ更新）を要し、スクラッチパッドへ向かう。合計で、２つのＧＡＴ更新と、２つのＭＡＰ更新と、２つのスクラッチパッド更新をこの時点までに行うことができる。
ステップ２およびステップ３：ステップ１と同様。
ステップ４：これがプリエンプティブな書き換えを行う最初の機会である。新規のコマンドによって、新規の連続更新ブロックが開放される。予備の更新ブロックがあるので、他のブロックは閉鎖される必要はないが、ホスト書き込みはスクラッチパッドへ向かい得る。この時点までに、６つのＭＡＰ更新と、６つのＧＡＴ更新と、８個のスクラッチパッド更新を行うことができる。
ステップ５およびステップ６：ステップ４と同様。
ステップ７：ステップ１と同様。
The initial state of the update pool is that all three update blocks are open, three of which are chaotic update blocks. The host write pattern is such that the host chaotically writes to each successive update block, repeatedly releases new successive blocks, and chaos on the next write.
Step 0: Initial State Step 1:
Step 4: This is the first opportunity to do a preemptive rewrite. A new command releases a new continuous update block. Because there are spare update blocks, other blocks need not be closed, but host writes can go to the scratch pad. Up to this point, six MAP updates, six GAT updates, and eight scratch pad updates can be done.
Step 7: Same as
よって、ＭＡＰブロックについて８つのフリーＭＡＰページと、ＧＡＴブロックについて６つのフリーＧＡＴページと、ＳＰブロックについて１０個のフリーのスクラッチパッドページとでマージンが設定される場合には、ステップ４においてＭＡＰおよびＧＡＴブロックを、ステップ５においてスクラッチパッドを書き換えることによって、カスケードを回避するために、様々な制御ブロックが間に合うように書き込まれることを保証することができる。
Thus, if the margin is set by 8 free MAP pages for MAP block, 6 free GAT pages for GAT block, and 10 free scratch pad pages for SP block, MAP and GAT in
図２９Ｂは、「３−３」更新プールを有するメモリ構成について継続的な一連の連続ブロック閉鎖を生じさせる、最悪の場合における書き込みパターンを示す表である。
更新プールの初期状態は、３つの更新ブロックすべてが開放され、そのうちの３つがカオス的更新ブロックであって一杯となっている。ホスト書き込みパターンは、ホストがカオス的ブロックを埋めるようにカオス的に書き込み、その後、連続更新ブロックを繰り返し開放するというものである。
ステップ０：初期状態
ステップ１：既に一杯のカオス的ブロック１に対して書き込む。これにより、ＧＡＴおよびＭＡＰ更新と、スクラッチパッド更新とをトリガする統合がトリガされる。新規の連続更新ブロックが開放され、ホストデータはスクラッチパッドに書き込まれる。合計で２つのＧＡＴ更新と、２つのＭＡＰ更新と、２つのスクラッチパッド更新とをこの時点までに行うことができる。
ステップ２およびステップ３：ステップ１と同様。
ステップ４：これがプリエンプティブな書き換えを行う最初の機会である。新規のコマンドは、新規更新ブロックを要し、既存の連続更新ブロックを閉鎖する。閉鎖は、スクラッチパッド書き込みを要し、新規のブロックは、ＧＡＴおよびＭＡＰ更新を要する。この時点までに、７つのＭＡＰ更新と、４つのＧＡＴ更新と、８個のスクラッチパッド更新を行うことができる。
ステップ５：ステップ４と同様に、それぞれ連続閉鎖をトリガし、１つのＧＡＴ更新と、１つのＭＡＰ更新と、２つのスクラッチパッド更新とをトリガする新規ブロックを割り当てる。
FIG. 29B is a table showing a worst case write pattern that results in a continuous series of consecutive block closures for a memory configuration having a "3-3" update pool.
In the initial state of the update pool, all three update blocks are open, and three of them are chaotic update blocks and are full. The host write pattern is such that the host writes chaotically so as to fill the chaotic block, and then repeatedly releases the continuously updated block.
Step 0: Initial State Step 1: Write to
Step 4: This is the first opportunity to do a preemptive rewrite. The new command takes a new update block and closes the existing continuous update block. Closure requires scratch pad writes, new blocks require GAT and MAP updates. Up to this point, seven MAP updates, four GAT updates, and eight scratch pad updates can be done.
Step 5: As in
よって、ＭＡＰブロックについて９ページと、ＧＡＴブロックについて５ページと、スクラッチパッドブロックについて１２ページとでマージンが設定される場合には、ステップ４においてＭＡＰおよびＧＡＴブロックを、ステップ５においてスクラッチパッドを書き換えることによって、カスケードを回避するために、様々な制御ブロックが間に合うように書き込まれることを保証することができる。
Therefore, if margins are set by 9 pages for MAP blocks, 5 pages for GAT blocks, and 12 pages for scratch pad blocks, rewrite the MAP and GAT blocks in
エラー処理
データリロケート処理中のプログラムエラーは、時間のかかる動作を再び再開させる必要がある場合があるので、遥かに重大である。予想される発生の１つとしては、ホストコマンドによってトリガされた、カオス的ブロックの統合中または連続ブロックの閉鎖中である。他の予想される発生としては、制御ブロック書き換え中である。カスケードを回避するためのプリエンプティブな制御ブロック書き換えは、これらの問題を考慮する必要がある。
Error Handling Program errors during data relocation processing are much more serious because it may be necessary to resume time-consuming operations again. One expected occurrence is during consolidation of chaotic blocks or closure of consecutive blocks triggered by a host command. Another expected occurrence is during control block rewriting. Preemptive control block rewriting to avoid cascading needs to take these issues into account.
統合中のプログラムエラーは、２つのやり方のうちの１つで処理される。エラーが統合開始付近で生じる場合には、統合は他のブロックを使用して再開される。エラーが統合の終了近くで生じる場合には、残りのセクタを記憶するために、フェーズ化されたエラーブロックが使用される。フェーズ化されたプログラムエラー処理は、２００５年７月２８日公開の米国公開特許出願第２００５／０１６６０８７号（特許文献２３）に開示されている。フェーズ化されたエラーが使用される場合には、フェーズ化されたエラーブロックが、次の都合がよいときに閉鎖されることになり、そのデータは、不具合のないブロックへリロケートされることになる。これは、プリエンプティブな書き換えが遅延されるであろうことを意味する。これに対処するために、より多くのセクタを各制御ブロックのマージンに予約する必要がある。連続閉鎖中のプログラムエラーは、基本的には、統合中のプログラムエラーと同様に処理される。 Program errors during integration are handled in one of two ways. If an error occurs near the start of consolidation, consolidation is resumed using other blocks. If errors occur near the end of consolidation, phased error blocks are used to store the remaining sectors. Phased program error handling is disclosed in US Published Patent Application No. 2005/0166087, published Jul. 28, 2005. If a phased error is used, the phased error block will be closed at the next convenient time, and the data will be relocated to the fault free block . This means that preemptive rewriting will be delayed. To address this, more sectors need to be reserved for the margin of each control block. Program errors during continuous closure are basically treated the same as program errors during consolidation.
プログラムエラーは、制御データ更新中も生じる場合がある。エラーを処理する方法の１つは、制御データを新規の制御ブロックへリロケートすることである。代替策は、制御ブロック内の次に利用可能なページへセクタを書き込むというものである。その後、このブロックが次の都合のよいときに書き換えられるように、フラグが設定されてもよい。これは、制御ブロックのマージンにさらなるページを予約することを要する。 Program errors may also occur during control data updates. One way to handle errors is to relocate control data to a new control block. An alternative is to write the sector to the next available page in the control block. Then, a flag may be set so that this block can be rewritten at the next convenient time. This requires reserving additional pages in the margin of the control block.
プリエンプティブな制御ブロック書き換え中のプログラムエラーは、他のブロックへの書き換えを繰り返すことによって処理される。代替策は、プリエンプティブな書き換えを破棄して、次の都合のよいときに再び書き込みを試行するというものである。
いずれの場合にも、任意の他の保留中のプリエンプティブな書き換えが遅延されることになろう。これに対処するために、さらなるセクタを各制御ブロックのマージンに予約する必要がある。
Program errors during preemptive control block rewriting are handled by repeated rewriting to other blocks. An alternative is to discard the preemptive rewrite and attempt to write again at the next convenient time.
In any case, any other pending preemptive rewrites will be delayed. To address this, additional sectors need to be reserved for the margin of each control block.
プリエンプティブな制御ブロック書き換えのためのスケジューリング方法
前述したように、ホストおよびメモリシステムの様々なタイミングによる複数の制御ブロック書き換えスケジューリング方法が可能である。以下は、制御ブロック書き換えスケジューリング方法のいくつかの例である。
方法１は、図２７Ａ〜図２７Ｂ、図２８Ａ〜図２８Ｂ、および図２９Ａ〜図２９Ｂに示すケーススタディについて計算を行うために使用される方法である。この方法が基本的に想定しているのは、コマンドによってトリガされるガーベッジコレクションがない場合に２つの書き換えを行い、ガーベッジコレクションが連続閉鎖を伴う場合に１つの書き換えを行い、ガーベッジコレクションがカオス的閉鎖を伴う場合には書き換えを行わないための充分な時間をホスト書き込みレイテンシが許容するというものである。
１．同一のビジー期間において、カオス的ブロック統合として、プリエンプティブな制御ブロック書き換えを行わない。
２．同一のビジー期間において、連続ブロック閉鎖として、１つのプリエンプティブな制御ブロック書き換えを許容する。
３．更新ブロックのガーベッジコレクションがない場合には、２つのプリエンプティブな制御ブロック書き換えを許容する。
Scheduling Methods for Preemptive Control Block Rewriting As discussed above, multiple control block rewrite scheduling methods are possible with different timing of the host and memory system. The following are some examples of control block rewrite scheduling methods.
1. In the same busy period, preemptive control block rewriting is not performed as chaotic block integration.
2. In the same busy period, one preemptive control block rewrite is permitted as continuous block closure.
3. If there is no garbage collection of update blocks, then two preemptive control block rewrites are allowed.
図３０は、方法１の制御ブロック書き換えスケジュールを適用することによる、制御データ型毎の計算されたマージン例を列挙する表である。要約すると、方法１は、すべての更新プール構成に関して、ＭＡＰブロックについて９つのＭＡＰページと、ＧＡＴブロックについて６つのＧＡＴページと、スクラッチパッドブロックについて１６ページとでマージンを設定することになっている。また、処理されるべき各エラーについては、２つの追加ページが各マージンに追加されることになっている。
FIG. 30 is a table listing example calculated margins for each control data type by applying the control block rewrite schedule of
方法２が基本的に想定しているのは、ホスト書き込みがガーベッジコレクションをトリガしていても、ホスト書き込みレイテンシは、スクラッチパッド書き換えなどの短い制御ブロック書き換えを行うのに充分な時間を許容しているということである。
１．プリエンプティブなスクラッチパッド書き換えをいつでも許容する。
２．同一のビジー期間において、連続ブロック閉鎖として、１つのプリエンプティブな制御ブロック書き換えを許容する。
３．更新ブロックのガーベッジコレクションがない場合には、２つのプリエンプティブな制御ブロック書き換えを許容する。
1. Allow preemptive scratchpad rewriting anytime.
2. In the same busy period, one preemptive control block rewrite is permitted as continuous block closure.
3. If there is no garbage collection of update blocks, then two preemptive control block rewrites are allowed.
図３１は、方法２の制御ブロック書き換えスケジュールを適用することによる、制御データ型毎の計算されたマージン例を列挙する表である。要約すると、方法２は、すべての更新プール構成に関して、ＭＡＰブロックについて２つのＭＡＰページと、ＧＡＴブロックについて４つのＧＡＴページと、スクラッチパッドブロックについて３ページとでマージンを設定することになっている。また、処理されるべき各エラーについては、２つの追加ページが各マージンに追加されるべきである。
FIG. 31 is a table listing example calculated margins for each control data type by applying the control block rewrite schedule of
方法３は、基本的には、書き換え毎にリロケートするページ量を検査して、いずれかがホスト書き込みレイテンシによって設定される残り時間内に実行可能であるかを調べることによって、より定量的なアプローチをとるものである。この方法は、書き換え毎のリロケート量をマクロ的に追跡するという犠牲によって、ホスト書き込みレイテンシを最も効率的に利用することになる。利点は、マージンが最小になるであろうということである。
１．制御ブロック書き換え毎に必要な作業（ページコピー数）をカウントする。
２．総作業が所定のしきい値を超えるまで、プリエンプティブな制御ブロック書き換えを許容する。
1. The work (the number of page copies) necessary for each control block rewrite is counted.
2. Allow preemptive control block rewriting until the total work exceeds a predetermined threshold.
図３２は、方法３の制御ブロック書き換えスケジュールを適用することによる、制御データ型毎の計算されたマージン例を列挙する表である。要約すると、方法３は、すべての更新プール構成に関して、ＭＡＰブロックについて２つのＭＡＰページと、ＧＡＴブロックについて２つのＧＡＴページと、スクラッチパッドブロックについて３ページとでマージンを設定することになっている。また、処理されるべき各エラーについては、２つの追加ページが各マージンに追加されることになっている。
FIG. 32 is a table listing example calculated margins for each control data type by applying the control block rewrite schedule of
方法４は、方法１と同様であって、カオス的閉鎖が連続閉鎖と同じ速度で行われ得るというさらなる前提を伴う。
１．ＭＡＰブロック→スクラッチパッド→ＧＡＴ→ＢＢの順序で制御ブロックを書き換える。これにより、ＳＰには４ページ分少ないページを予約することができる。
２．同一のビジー期間において、連続ブロック閉鎖またはカオス的圧縮のいずれかとして、１つのプリエンプティブな制御ブロック書き換えを許容する。
３．更新ブロックのガーベッジコレクションがない場合には、２つのプリエンプティブな制御ブロック書き換えを許容する。
1. The control block is rewritten in the order of MAP block → scratch pad → GAT → BB. As a result, it is possible to reserve a page smaller by four pages in the SP.
2. In the same busy period, one preemptive control block rewrite is permitted, either as continuous block closure or chaotic compression.
3. If there is no garbage collection of update blocks, then two preemptive control block rewrites are allowed.
図３３は、方法４の制御ブロック書き換えスケジュールを適用することによる、制御データ型毎の計算されたマージン例を列挙する表である。要約すると、方法４は、すべての更新プール構成に関して、ＭＡＰブロックについて４つのＭＡＰページと、ＧＡＴブロックについて６つのＧＡＴページと、スクラッチパッドブロックについて５ページとでマージンを設定することになっている。また、処理されるべき各エラーについては、２つの追加ページが各マージンに追加されることになっている。
FIG. 33 is a table listing example calculated margins for each control data type by applying the control block rewrite schedule of
改良されたプリエンプティブな制御データリロケート
図３４は、最悪の場合の考慮事項に基づく、制御データブロックのプリエンプティブな書き換えのための手法を示すフロー図である。
ステップ１４０２：不揮発性メモリをブロックに組織化する。
ステップ１４０４：異なる型のデータを保持する。
ステップ１４１０：データ型毎にブロックが一杯になる前に、複数の空きメモリユニットのマージンを設定することであって、当該マージンは、ブロック内のデータがリロケートを許可される前に、所定の間隔で蓄積されたデータを収容するのにちょうど十分であり、当該所定の間隔は、ブロック内のデータがリロケートを許可される前に最悪の場合における間隔を生じさせるホスト書き込みパターンから決定される。
ステップ１４２０：各ブロックが実質的に同じ型のデータを記憶するように、複数のブロック内に当該異なる型のデータの更新を記憶する。
ステップ１４３０：許可される場合には、ブロックがデータ型のマージンに到達するデータを記憶するのに応じて、当該ブロック内のデータを他のブロックにリロケートする。中断されなければ、ステップ１４２０へ進む。
Improved Preemptive Control Data Relocation FIG. 34 is a flow diagram showing a technique for preemptive rewriting of control data blocks based on worst case considerations.
Step 1402: Organize non-volatile memory into blocks.
Step 1404: Hold different types of data.
Step 1410: setting a margin of a plurality of free memory units before the block is full for each data type, wherein the margin is a predetermined interval before the data in the block is permitted to be relocated The predetermined interval is determined from the host write pattern which results in an interval in the worst case before the data in the block is allowed to relocate.
Step 1420: Store updates of the different types of data in multiple blocks, such that each block stores substantially the same type of data.
Step 1430: If permitted, relocate data in the block to another block as the block stores data reaching the margin of the data type. If not interrupted, the process proceeds to step 1420.
図３５は、より高位のデータ型に対するさらに好ましい対応以外は図３４と同様のプリエンプティブな書き換えのための代替手法を示すフロー図である。
ステップ１４０２：不揮発性メモリをブロックに組織化する。
ステップ１４０４：異なる型のデータを保持する。
ステップ１４０６：順位付けを異なる型のデータに割り当てる。
ステップ１４１０：データ型毎にブロックが一杯になる前に、複数の空きメモリユニットのマージンを設定することであって、当該マージンは、ブロック内のデータがリロケートを許可される前に、所定の間隔で蓄積されたデータを収容するのにちょうど十分であり、当該所定の間隔は、ブロック内のデータがリロケートを許可される前に最悪の場合における間隔を生じさせるホスト書き込みパターンから決定される。
ステップ１４２０：各ブロックが同一の型のデータを実質的に記憶するように、複数のブロック内に当該異なる型のデータの更新を記憶する。
ステップ１４３０’：許可される場合には、ブロックがデータ型のマージンに到達しかつ任意の同様のブロックのうちで最高位のデータ型を有するデータを記憶するのに応じて、当該ブロック内のデータを他のブロックにリロケートする。中断されなければ、ステップ１４２０へ進む。
FIG. 35 is a flow diagram illustrating an alternative approach to preemptive rewriting similar to FIG. 34 except for the more desirable correspondence to higher order data types.
Step 1402: Organize non-volatile memory into blocks.
Step 1404: Hold different types of data.
Step 1406: Assign rankings to different types of data.
Step 1410: setting a margin of a plurality of free memory units before the block is full for each data type, wherein the margin is a predetermined interval before the data in the block is permitted to be relocated The predetermined interval is determined from the host write pattern which results in an interval in the worst case before the data in the block is allowed to relocate.
Step 1420: Store updates of the different types of data in multiple blocks, such that each block substantially stores the same type of data.
Step 1430 ': If permitted, the data in the block in response to the block reaching the margin of the data type and storing the data having the highest data type of any similar blocks. Relocate to another block. If not interrupted, the process proceeds to step 1420.
図３６は、図３４および図３５のフロー図のステップのうちの１つについての代替ステップを示す。ステップ１４０２’は、図３４および図３５に示すステップ１４０２の代替ステップである。
ステップ１４０２’：不揮発性メモリをブロックに組織化し、各ブロックは、共に消去可能なメモリユニットに分割される。
FIG. 36 illustrates alternative steps for one of the steps of the flow diagrams of FIGS. 34 and 35. Step 1402 'is an alternative to step 1402 shown in FIGS.
Step 1402 ': Organize the non-volatile memory into blocks, each block being divided together into erasable memory units.
図３７は、図３４および図３５のフロー図のステップのうちの１つについてのさらなる代替ステップを示す。ステップ１４１０’は、図３４および図３５に示すステップ１４１０の代替ステップである。
ステップ１４１０’：各データ型毎にブロックが一杯になる前に、複数の空きメモリユニットのマージンを設定することであって、当該マージンは、ブロック内のデータがリロケートを許可される前に、所定の間隔で蓄積されたデータを収容するのにちょうど十分であり、当該所定の間隔は、データのブロックがリロケートを許可される前に最悪の場合における間隔を生じさせるホスト書き込みパターンと、リロケートするデータ量とから決定される。
FIG. 37 shows a further alternative step for one of the steps of the flow diagrams of FIGS. 34 and 35. Step 1410 'is an alternative to step 1410 shown in FIGS.
Step 1410 ': setting a margin of a plurality of free memory units before the block is full for each data type, wherein the margin is determined before data in the block is permitted to be relocated. The host write pattern and the data to be relocated, which are just enough to accommodate the data accumulated in the interval between the host and the predetermined interval is the worst case interval before the block of data is allowed to be relocated. It is determined from the amount.
本願明細書において参照されたすべての特許、特許出願、記事、書籍、明細書、他の出版物、書類、および事物は、あらゆる目的のためにその全体が本願明細書において参照により援用されている。任意の包含された出版物、書類、および事物と、本願明細書の文章との間に用語の定義または用法における矛盾または不一致がある場合には、本願明細書における用語の定義または用法に従う。 All patents, patent applications, articles, books, descriptions, other publications, documents, and things referenced herein are hereby incorporated by reference in their entirety for all purposes. . In case of conflict or inconsistency in the definition or usage of terms between any incorporated publication, documents, and things and the text of this specification, the definition or usage of terms herein is followed.
本発明の様々な態様をある実施形態に関して説明してきたが、本発明は、添付の特許請求の範囲の全範囲内においてその権利が保護されるべきであることが理解できよう。 While various aspects of the invention have been described with respect to certain embodiments, it will be understood that the invention is to be protected within the full scope of the appended claims.
Claims (60)
複数のブロックに組織化された不揮発性メモリと、
前記メモリ内に保持された１つ以上のデータ型と、
データ型毎のマージンであって、前記マージンは、ブロックが一杯になる前の複数の空きメモリユニットであり、前記マージンは、前記ブロック内のデータがリロケートを許可される前に、所定の間隔で蓄積されたデータを収容するのにちょうど十分であり、前記所定の間隔は、前記ブロック内のデータがリロケートを許可される前に最悪の場合における間隔を生じさせるホスト書き込みパターンから決定される前記マージンと、
前記１つ以上のデータ型の更新を記憶する複数のブロックであって、それぞれ同一の型のデータを実質的に記憶するブロックと、
許可される場合には、ブロックが前記データ型の前記マージンに到達するデータを記憶するのに応じて、前記ブロック内のデータを他のブロックへリロケートするための読み出し／書き込み回路と、
を備えるメモリ。 Memory,
Non-volatile memory organized into multiple blocks,
One or more data types held in the memory;
A margin for each data type, wherein the margin is a plurality of free memory units before the block is full, and the margin is at a predetermined interval before data in the block is allowed to be relocated The margin determined from the host write pattern that is just enough to accommodate the accumulated data, and the predetermined interval is the worst case interval before the data in the block is allowed to be relocated When,
A plurality of blocks storing updates of the one or more data types, each block substantially storing data of the same type;
Read / write circuitry for relocating data in the block to another block as the block stores data reaching the margin of the data type, if permitted;
Memory with
前記メモリを動作させることは、そこへのホスト書き込みを含み、
前記所定の間隔は、前記ブロック内のデータがリロケートを許可される前に最大の間隔を生じさせる最悪の場合におけるホスト書き込みパターンに依存するメモリ。 In the memory according to claim 1,
Operating the memory includes host writes to it;
The predetermined interval depends on the host write pattern in the worst case causing the maximum interval before the data in the block is allowed to be relocated.
前記所定の間隔は、リロケートするデータの最大量を生じさせるブロックの最悪の場合における構成に依存するメモリ。 In the memory according to claim 1,
The predetermined interval depends on the worst case configuration of the block resulting in the largest amount of data to be relocated.
前記異なるデータ型は、所定の順位付けを有し、
データをリロケートする前記読み出し／書き込み回路は、前記データ型の前記マージンに到達しかつ任意の同様のブロックのうちで最高位のデータ型を有するデータをブロックが記憶するのに応答可能であるメモリ。 In the memory according to claim 1,
The different data types have a predetermined ranking,
A memory wherein the read / write circuit for relocating data is capable of reaching the margin of the data type and being capable of storing data having the highest data type of any similar block.
前記最高位を有する前記データ型は、前記ブロックを最速で埋めることが見込まれるものであるメモリ。 In the memory according to claim 4,
The memory having the highest data type expected to fill the block at the fastest.
前記異なるデータ型は、前記メモリが前記ブロックを管理するために使用する制御データであるメモリ。 In the memory according to claim 1,
The memory wherein the different data types are control data that the memory uses to manage the block.
前記異なるデータ型は、前記ブロックの提供を制御するためのものを含むメモリ。 In the memory according to claim 6,
A memory comprising the different data types for controlling provision of the block.
前記異なるデータ型は、前記ブロック内に記憶されたデータの位置に関するものを含むメモリ。 In the memory according to claim 6,
The memory comprising the different data types pertaining to the location of data stored in the block.
前記ブロック内のデータは、前記メモリ上のホストコマンドの実行中にリロケートが許可されるメモリ。 In the memory according to claim 6,
Memory in which data in the block is allowed to be relocated during execution of a host command on the memory.
前記ブロック内のデータがリロケートを許可される前の前記所定の間隔は、前記ブロック内の前記データをリロケートするために必要な時間に依存するメモリ。 In the memory according to claim 1,
The predetermined interval before data in the block is allowed to be relocated depends on the time required to relocate the data in the block.
前記ブロック内のデータがリロケートを許可される前の前記所定の間隔は、ホストデータを受信するために開放されたブロックのプールがどのように構成されているかに依存するメモリ。 In the memory according to claim 1,
The predetermined interval before the data in the block is allowed to be relocated depends on how the pool of blocks released for receiving host data is configured.
前記ブロック内のデータがリロケートを許可される前の前記所定の間隔は、ホストコマンドによって設定される最大時間に依存するメモリ。 In the memory according to claim 1,
The predetermined interval before the data in the block is allowed to be relocated depends on the maximum time set by the host command.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 1,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 2,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 3,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 4,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 5,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 6,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 7,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 8,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 9,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 10,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 11,
A memory in which the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能であるメモリ。 In the memory according to claim 12,
A memory in which the data in each block are erasable together.
前記メモリは、ワンタイムプログラマブルメモリであるメモリ。 In the memory according to claim 1,
The memory is a one-time programmable memory.
前記メモリは、フラッシュＥＥＰＲＯＭであるメモリ。 In the memory according to claim 1,
The memory is a flash EEPROM.
前記メモリは、着脱可能なメモリカード内に実施されるメモリ。 In the memory according to claim 1,
The memory is implemented in a removable memory card.
複数のブロックに組織化された不揮発性メモリと、
前記メモリ内に保持された１つ以上のデータ型と、
データ型毎のマージンであって、前記マージンは、ブロックが一杯になる前の複数の空きメモリユニットであり、前記マージンは、前記ブロック内のデータがリロケートを許可される前に、所定の間隔で蓄積されたデータを収容するのにちょうど十分であり、前記所定の間隔は、前記ブロック内のデータがリロケートを許可される前に最悪の場合における間隔を生じさせるホスト書き込みパターンから決定される前記マージンと、
前記１つ以上のデータ型の更新を記憶する複数のブロックであって、それぞれ同一の型のデータを実質的に記憶する前記ブロックと、
許可される場合には、ブロックが前記データ型の前記マージンに到達するデータを記憶するのに応じて、前記ブロック内のデータを他のブロックへリロケートするための手段と、
を含むメモリ。 Memory,
Non-volatile memory organized into multiple blocks,
One or more data types held in the memory;
A margin for each data type, wherein the margin is a plurality of free memory units before the block is full, and the margin is at a predetermined interval before data in the block is allowed to be relocated The margin determined from the host write pattern that is just enough to accommodate the accumulated data, and the predetermined interval is the worst case interval before the data in the block is allowed to be relocated When,
A plurality of blocks storing updates of the one or more data types, each block substantially storing data of the same type;
Means, if permitted, for relocating data in the block to another block in response to the block storing data reaching the margin of the data type;
Memory that contains
前記異なるデータ型は、所定の順位付けを有し、
データをリロケートする前記手段は、前記データ型の前記マージンに到達しかつ任意の同様のブロックのうちで最高位のデータ型を有するデータをブロックが記憶するのに応答可能であるメモリ。 In the memory according to claim 28,
The different data types have a predetermined ranking,
A memory, wherein said means for relocating data is responsive to the block reaching said margin of said data type and storing data having the highest data type of any similar block.
前記メモリは、１ビットのデータをそれぞれ記憶するメモリセルを有するメモリ。 In the memory according to any one of claims 1 to 29,
The memory is a memory having memory cells each storing 1-bit data.
前記メモリは、１ビットより多くのデータをそれぞれ記憶するメモリセルを有するメモリ。 In the memory according to any one of claims 1 to 29,
The memory is a memory having memory cells each storing data of more than one bit.
不揮発性メモリをブロックに組織化するステップと、
１つ以上のデータ型を保持するステップと、
データ型毎にブロックが一杯になる前の複数の空きメモリユニットのマージンを設定するステップであって、前記マージンは、前記ブロック内のデータがリロケートを許可される前に、所定の間隔で蓄積されたデータを収容するのに実質的に十分であるステップと、
各ブロックが同一の型のデータを実質的に記憶しているように、前記１つ以上のデータ型の更新を複数のブロックに記憶するステップと、
許可される場合には、ブロックが前記データ型の前記マージンに到達するデータを記憶するのに応じて、前記ブロック内のデータを他のブロックへリロケートするステップと、
を含む方法。 A method of operating the memory,
Organizing the non-volatile memory into blocks;
Holding one or more data types;
Setting a margin of a plurality of free memory units before the block is full for each data type, wherein the margin is accumulated at a predetermined interval before data in the block is permitted to be relocated Steps that are substantially sufficient to accommodate different data;
Storing the one or more data type updates in a plurality of blocks, such that each block substantially stores the same type of data;
If permitted, relocating data in the block to another block in response to the block storing data reaching the margin of the data type;
Method including.
前記メモリを動作させることは、そこへのホスト書き込みを含み、
前記所定の間隔は、前記ブロック内のデータがリロケートを許可される前に最大の間隔を生じさせる最悪の場合におけるホスト書き込みパターンに依存する方法。 The method according to claim 32, wherein
Operating the memory includes host writes to it;
The predetermined interval depends on the host write pattern in the worst case resulting in a maximum interval before the data in the block is allowed to be relocated.
前記所定の間隔は、リロケートするデータの最大量を生じさせるブロックの最悪の場合における構成に依存する方法。 The method according to claim 32, wherein
The predetermined interval depends on the worst case configuration of the block resulting in the largest amount of relocated data.
１つより多い場合には、各データ型に順位付けを割り当てるステップをさらに含み、
前記データリロケートは、前記マージンに到達しかつ任意の同様のブロックのうちで最高位のデータの型を有するデータをブロックが記憶するのに応答可能である方法。 The method according to claim 32, wherein
If more than one, further including the step of assigning a ranking to each data type;
The method wherein the data relocation is responsive to the block reaching the margin and storing data having the type of the highest order data of any similar block.
前記最高位を有する前記データ型は、前記ブロックを最速で埋めることが見込まれるものである方法。 The method according to claim 35, wherein
The method wherein the data type having the highest rank is expected to fill the block at the fastest.
前記異なるデータ型は、前記メモリが前記ブロックを管理するために使用する制御データである方法。 The method according to claim 32, wherein
The method wherein the different data types are control data that the memory uses to manage the block.
前記異なるデータ型は、前記ブロックの提供を制御するためのものを含む方法。 The method according to claim 37, wherein
The different data types include those for controlling provision of the block.
前記異なるデータ型は、前記ブロック内に記憶されたデータの位置に関するものを含む方法。 The method according to claim 37, wherein
The different data types include those relating to the position of data stored in the block.
前記ブロック内のデータは、前記メモリ上のホストコマンドの実行中にリロケートが許可される方法。 The method according to claim 37, wherein
The method in which data in the block is permitted to be relocated during execution of a host command on the memory.
前記ブロック内のデータがリロケートを許可される前の前記所定の間隔の前記決定は、前記ブロック内の前記データをリロケートするために必要な時間を含む方法。 The method according to claim 32, wherein
The method of determining the predetermined interval before data in the block is allowed to be relocated includes the time required to relocate the data in the block.
前記ブロック内のデータがリロケートを許可される前の前記所定の間隔の前記決定は、ホストデータを受信するために開放されたブロックのプールがどのように構成されているかを含む方法。 The method according to claim 32, wherein
The method of determining the predetermined interval before data in the block is allowed to be relocated includes how a pool of blocks released to receive host data is configured.
前記ブロック内のデータがリロケートを許可される前の前記所定の間隔の前記決定は、ホストコマンドによって設定される最大時間を含む方法。 The method according to claim 32, wherein
The method wherein the determination of the predetermined interval before data in the block is allowed to be relocated includes a maximum time set by a host command.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 32, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 33, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 35. The method of claim 34, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 35, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 In the method according to claim 36,
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 37, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 38, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 39, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 41. The method of claim 40, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 42. The method of claim 41, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 42, wherein
The method wherein the data in each block are erasable together.
各ブロック内の前記データは、共に消去可能である方法。 The method according to claim 43, wherein
The method wherein the data in each block are erasable together.
前記メモリは、ワンタイムプログラマブルメモリである方法。 The method according to claim 32, wherein
The method wherein the memory is a one time programmable memory.
前記メモリは、フラッシュＥＥＰＲＯＭである方法。 The method according to claim 32, wherein
The method wherein the memory is a flash EEPROM.
前記メモリは、着脱可能なメモリカード内に実施される方法。 The method according to claim 32, wherein
The method wherein the memory is implemented in a removable memory card.
前記メモリは、１ビットのデータをそれぞれ記憶するメモリセルを有する方法。 60. A method according to any of claims 32-58,
The memory includes memory cells each storing 1-bit data.
前記メモリは、１ビットより多くのデータをそれぞれ記憶するメモリセルを有する方法。 60. A method according to any of claims 32-58, wherein
The memory comprises memory cells each storing more than one bit of data.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/549,040 US20080091871A1 (en) | 2006-10-12 | 2006-10-12 | Non-volatile memory with worst-case control data management |
| US11/549,035 US20080091901A1 (en) | 2006-10-12 | 2006-10-12 | Method for non-volatile memory with worst-case control data management |
| PCT/US2007/080725 WO2008045839A1 (en) | 2006-10-12 | 2007-10-08 | Non-volatile memory with worst-case control data management and methods therefor |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010507147A true JP2010507147A (en) | 2010-03-04 |
| JP2010507147A5 JP2010507147A5 (en) | 2010-11-25 |
Family
ID=39052642
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009532520A Pending JP2010507147A (en) | 2006-10-12 | 2007-10-08 | Nonvolatile memory with data management in the worst case and method therefor |
Country Status (4)
| Country | Link |
|---|---|
| JP (1) | JP2010507147A (en) |
| KR (1) | KR20090088858A (en) |
| TW (1) | TW200844999A (en) |
| WO (1) | WO2008045839A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012517627A (en) * | 2009-02-12 | 2012-08-02 | 株式会社東芝 | Memory system and memory system control method |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI413984B (en) * | 2008-10-16 | 2013-11-01 | Silicon Motion Inc | Flash memory apparatus and updating method |
| TWI408689B (en) * | 2009-04-14 | 2013-09-11 | Jmicron Technology Corp | Method for accessing storage apparatus and related control circuit |
| TWI404071B (en) * | 2009-06-23 | 2013-08-01 | Phison Electronics Corp | Controller circuit having functions for identifying error data in flash memory and storage system and method thereof |
| TWI426528B (en) * | 2009-09-30 | 2014-02-11 | Phison Electronics Corp | Block management method for a flash memory and flash memory controller and storage system using the same |
| DE102011107435A1 (en) * | 2011-07-15 | 2013-01-17 | Giesecke & Devrient Gmbh | Method for detecting erased memory areas |
| KR101889298B1 (en) * | 2011-11-08 | 2018-08-20 | 삼성전자주식회사 | Memory device including nonvolatile memory and controling method of nonvolatile memory |
| US20240143171A1 (en) * | 2022-07-06 | 2024-05-02 | Samsung Electronics Co., Ltd. | Systems, methods, and devices for using a reclaim unit based on a reference update in a storage device |
| US20240012579A1 (en) * | 2022-07-06 | 2024-01-11 | Samsung Electronics Co., Ltd. | Systems, methods, and apparatus for data placement in a storage device |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050144365A1 (en) * | 2003-12-30 | 2005-06-30 | Sergey Anatolievich Gorobets | Non-volatile memory and method with control data management |
| US20050195821A1 (en) * | 2004-03-03 | 2005-09-08 | Samsung Electronics Co., Ltd. | Method and apparatus for dynamically controlling traffic in wireless station |
-
2007
- 2007-10-08 WO PCT/US2007/080725 patent/WO2008045839A1/en active Application Filing
- 2007-10-08 KR KR1020097007576A patent/KR20090088858A/en not_active Application Discontinuation
- 2007-10-08 JP JP2009532520A patent/JP2010507147A/en active Pending
- 2007-10-12 TW TW096138384A patent/TW200844999A/en unknown
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050144365A1 (en) * | 2003-12-30 | 2005-06-30 | Sergey Anatolievich Gorobets | Non-volatile memory and method with control data management |
| US20050141312A1 (en) * | 2003-12-30 | 2005-06-30 | Sinclair Alan W. | Non-volatile memory and method with non-sequential update block management |
| US20050195821A1 (en) * | 2004-03-03 | 2005-09-08 | Samsung Electronics Co., Ltd. | Method and apparatus for dynamically controlling traffic in wireless station |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012517627A (en) * | 2009-02-12 | 2012-08-02 | 株式会社東芝 | Memory system and memory system control method |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20090088858A (en) | 2009-08-20 |
| WO2008045839A1 (en) | 2008-04-17 |
| TW200844999A (en) | 2008-11-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4938460B2 (en) | Non-volatile memory and method with block management system | |
| US7774392B2 (en) | Non-volatile memory with management of a pool of update memory blocks based on each block's activity and data order | |
| US20080091871A1 (en) | Non-volatile memory with worst-case control data management | |
| US20080091901A1 (en) | Method for non-volatile memory with worst-case control data management | |
| US7779056B2 (en) | Managing a pool of update memory blocks based on each block's activity and data order | |
| JP4682261B2 (en) | Method for non-volatile memory and class-based update block replacement rules | |
| EP1702338B1 (en) | Robust data duplication and improved update method in a multibit non-volatile memory | |
| JP2010507147A (en) | Nonvolatile memory with data management in the worst case and method therefor | |
| KR20070007264A (en) | Non-volatile memory and method with non-sequential update block management | |
| KR20060134011A (en) | Non-volatile memory and method with memory planes alignment | |
| EP1704479B1 (en) | Non-volatile memory and method with phased program failure handling | |
| JP2007519996A6 (en) | Nonvolatile memory and method with phased program fault handling |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101006 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20101006 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20120615 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120828 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20121116 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20121126 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130220 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20130820 |