KR101055324B1 - Enhanced Host Interface - Google Patents

Abstract

Memory systems compatible with hosts using different protocols include protocol adapters for different protocols. Protocol adapters allow a common back end system to be used for data provided in different formats. The protocol adapter issues a response to the host and issues commands to the backend as appropriate.

Protocol, host, memory system, protocol adapter, common backend system.

Description

Enhanced Host Interface {ENHANCED HOST INTERFACE}

The present application relates to the operation of reprogrammable non-volatile memory systems such as semiconductor flash memory, and more particularly to the management of an interface between a host device and a memory. All patents, patent applications, articles and other publications, documents, and references herein (including all applications referred to above under cross-reference with related applications) are hereby incorporated by reference in their entirety for all uses. Reference is made.

In earlier generations of commercial flash memory systems, a rectangular array of memory cells has been divided into a number of groups of cells each storing an amount of data in a standard disk drive sector, ie 512 bytes. An additional amount of data, such as 16 bytes, is also typically included in each group to store error correction code (ECC) and user data and / or possibly other overhead data relating to the memory cell group in which it is stored. The memory cells in each such group are the minimum number of memory cells that can be erased together. That is, the erase unit is the number of memory cells that efficiently store one data sector and any overhead data included. Examples of this type of memory system are described in US Pat. Nos. 5,602,987 and 6,426,893. A characteristic of flash memory is that memory cells need to be erased before re-programming the memory cells with data.

Flash memory systems are most commonly provided in the form of a memory card or flash drive that is removably connected to a number of hosts, such as a personal computer, a camera, and the like, but may also be embedded within such host systems. When writing data to memory, the host typically assigns specific logical addresses to sectors, clusters or other data units within the contiguous virtual address space of the memory system. Like a disk operating system (DOS), a host writes data to and reads data from addresses in the logical address space of the memory system. The controller in the memory system translates the logical addresses received from the host into physical addresses in the memory array where the data is actually stored and then tracks these address translations. The data storage capacity of the memory system is at least as large as the amount of addressable data over the entire logical address space defined for the memory system.

In later generations of flash memory systems, the size of the erase unit has been increased to a block of memory cells sufficient to store multiple sectors of data. Although the host systems to which memory systems are connected can program and read data in small minimum units such as sectors, multiple sectors are stored in a single erase unit of flash memory. When a host updates or replaces logical sectors of data, it is common for some sectors of data in the block to be obsolete. Since the entire block must be erased before any data stored in the block is overwritten, new or updated data is typically erased and stored in another block with the remaining capacity for that data. This process allows the original block to have obsolete data that takes up valuable space in memory. However, the block cannot be erased if any valid data remains in it.

Thus, in order to better utilize the storage capacity of the memory, the effective partial block amounts of data are consolidated or collected by copying the effective partial block amounts of data into the erased block, so that the block (s) to which such data is duplicated. It is then common to allow them to be erased afterwards and to allow their entire storage capacity to be reused. It is also desirable to duplicate the data in order to group the data sectors within the block in order of their logical addresses, because this increases the speed of reading data and delivering the read data to the host. If such data replication occurs too frequently, the operating performance of the memory system may be degraded. This affects the operation of memory systems, especially when the storage capacity of the memory, which is a typical case, is slightly more than the amount of data that can be addressed by the host through the logical address space of the system. In this case, data integration and collection may be required before the host programming instructions are executed. After that, the programming time is increased.

Block sizes are increasing in future generations of memory systems to increase the number of bits of data that can be stored in a given semiconductor area. Blocks storing 256 data sectors and more are becoming commonplace. In addition, two, four or more blocks of different arrays and sub-arrays are often logically linked together into metablocks to increase the degree of parallelism in data programming and reading. With such large capacities, operating units are challenges in operating them efficiently.

Because of the newer innovations that result in greater memory capacity and faster speeds, it is desirable to provide products that generally use these innovations but are still compatible with products that do not use these innovations. This means that new products use technical innovations, but are backwards compatible so that the new products can be used with products that use older technologies. Such backward compatibility is particularly important for portable products that can be used in many configurations with many different technologies. One example of such a portable product is a removable flash memory card.

The memory system includes an interface layer in communication with a host and a back end for storing data in a memory array. Between the interface layer and the back end, the translation layer converts the data and instructions received by the interface layer into a format understandable to the back end according to the different protocols used by the hosts. Thus, the translation layer allows a common back end to be used with multiple hosts using multiple protocols. This is particularly useful for memory systems in removable memory cards. The translation layer includes one or more protocol adapters. The protocol adapter receives communications (commands and data) from the host according to the protocol used by the host and, in response, translates the data and commands for the backend. The protocol adapter may also generate signals to the host, where such signals are part of the host protocol.

The memory system includes an object protocol adapter that converts data and instructions transmitted in accordance with the object protocol into a format compatible with file-based storage in nonvolatile memory. In particular, the object protocol adapter receives metadata about the object before receiving the object. The size of the object is included in the metadata. The object protocol adapter determines when the entire object has been received by comparing the amount of data received with the size indicated by the metadata information. When the object protocol adapter determines that the entire object has been received, the object protocol adapter generates a response to the host and generates an endpoint of the file indicator at the back end of the memory system, causing the file to be closed by the back end. This allows the backend to schedule the file for garbage collection, thereby allowing file data to be stored and managed more efficiently.

The memory system includes an LBA protocol adapter that converts data and instructions according to the LBA protocol into data and instructions compatible with file-based storage in nonvolatile memory. In one example, received data having logical addresses assigned by the host from a logical address space defined for the memory system is mapped to logical files. The logical files are then processed by the backend in the same way as other files. Logical files generally occupy entire metablocks, so the logical files do not share metablocks with other data. However, the same blocks can be used for logical files at one time and other files at different times, so that the memory array does not have a hard partition between different types of files.

The memory system includes a file protocol adapter that converts data and instructions according to the file protocol into data and instructions compatible with file-based storage in nonvolatile memory. If the backend uses the same protocol as the host (for example, both use a direct data file protocol), no translation may be required. However, when different file protocols are used by the host, the file protocol adapter makes the appropriate translations.

In some cases, the memory system can communicate with one or more hosts using one or more protocol adapters. In such cases, the translation layer may select one protocol adapter at a time to communicate with the backend. In some cases, the translation layer may coordinate between different hosts by alternately selecting different protocol adapters to provide interleaved access to the backend.

The interface layer includes logical interfaces that are compatible with multiple hosts. In some cases, separate physical interfaces may also exist for connection with corresponding interfaces on host devices. However, this is not necessary and in some cases, a single physical interface, such as a USB connector, is provided and used by all logical interfaces. The interface layer and translation layer functions may be performed by dedicated circuitry or by firmware on the controller. This may be a memory controller managing the memory array. The memory array may be a NAND memory array and may be formed on one or more semiconductor chips. The memory system may be included in a removable card that is connected to different hosts at different times.

The backend system may in some cases manage data as files corresponding to host files (although in some cases, no one-to-one correspondence with the host file exists). Examples of file-based backend systems are the direct data file backends described in US Application Nos. 11 / 060,174, 11 / 060,248 and 11 / 060,249 and Provisional Patent Application No. 60 / 705,388.

1 schematically shows a host and connected non-volatile memory system as currently implemented.

2 is a block diagram of an exemplary flash memory system for use as the nonvolatile memory of FIG.

3 is an exemplary circuit diagram of a memory cell array that may be used in the system of FIG.

4 illustrates an exemplary physical memory configuration of the system of FIG.

5 is an enlarged view of a portion of the physical memory of FIG.

6 is an additional enlarged view of a portion of the physical memory of FIGS. 4 and 5;

FIG. 7 illustrates a common prior art logical address interface between a host and a reprogrammable memory system. FIG.

FIG. 8 illustrates a common prior art logical address interface between a host and a reprogrammable memory system in a different manner than FIG.

9 illustrates a direct file storage interface between a host and a reprogrammable memory system in accordance with the present invention.

FIG. 10 illustrates a direct file storage interface between the host and the re-programmable memory system in a different manner from FIG. 9 in accordance with the present invention. FIG.

FIG. 11 illustrates a manner of storing host files received from a host as sectors having logical addresses from a common logical address space defined for memory, wherein the sectors are mapped to logical files, and then a logical file Are stored in the memory array as one logical file per metablock.

FIG. 12 illustrates the manner in which logically addressed data is stored in a memory array as logical files in a different manner from FIG.

Figure 13 illustrates a memory system having both a file interface and an LBA interface communicating with a file based back end, with an LBA protocol adapter interposed between the LBA interface and the file based back end.

Fig. 14A illustrates an MTP "transmission object information" transaction.

Figure 14B illustrates an MTP "transmission object" transaction.

Figure 15 illustrates a memory system having an object interface and a file-based back end interposed therebetween.

Figure 16 illustrates a memory system having a file interface, an object interface, and an LBA interface with a file protocol adapter, an object protocol adapter, and an LBA protocol adapter to facilitate communication between an interface and a file-based backend.

FIG. 17 is an alternative view of the memory system of FIG. 16 with a file interface considered as part of the interface layer, a file protocol adapter considered as part of an object interface and an LBA interface, and a translation layer, an object protocol adapter, and an LBA protocol adapter;

Flash memory general description

Typical operation by current flash memory systems and host devices is described with reference to FIGS. 1-8. Various aspects of the invention may be implemented in such a system. The host system 1 of FIG. 1 stores data into and retrieves data from the flash memory 2. Although flash memory may be embedded within the host, the memory 2 is a more popular form of card that is removably connected to the host via mating parts 3 and 4 of the mechanical and electrical connector. It is shown. There are many different flash memory cards currently available commercially, examples being compact flash (CF), multimedia card (MMC), secure digital (SD), miniSD, memory stick, smart media and transflash card. Although each of these cards has a specific mechanical and / or electrical interface according to its standardized specifications, the flash memory contained in each is very similar. These cards are all available from SanDisk, the assignee of the present application. SanDisk also offers a line of flash drives under its Cruzer brand, which are portable memory systems in small packages with Universal Serial Bus (USB) plugs for connecting to the host by plugging into the host's USB receptacle. Each of these memory cards and flash drives includes controllers interfacing with the host and controlling the operation of flash memory within them.

Host systems using such memory cards and flash drives are numerous and varied. These host systems include personal computers (PCs), laptops and other portable computers, cellular telephones, personal digital assistants (PDAs), digital still cameras, digital movie cameras and portable audio players. The host typically includes a built-in receptacle for one or more types of memory cards or flash drives, but some require adapters to which the memory card is plugged.

The host system 1 of FIG. 1 can be seen as having two main parts consisting of a combination of circuit and software, as long as the memory 2 is related. These are the application part 5 and the driver part 6 which interface with the memory 2. For example, in a personal computer, application portion 5 may include a processor that executes word processing, graphics, controls, and other popular application software. In a camera, cellular telephone or other host systems that are primarily dedicated to performing a single set of functions, the application portion 5 operates to allow the camera to take pictures and store pictures, and to allow the cellular telephone to make calls and receive calls. Software that allows for the operation of such operations.

The memory system 2 of FIG. 1 comprises a flash memory 7 and a circuit 8 for interfacing with a host to which a card is connected and controlling the memory 7 for passing data back and forth. The controller 8 typically translates between the logical address of the data used by the host 1 and the physical address of the memory 7 during data programming and reading.

Referring to FIG. 2, a circuit of a typical flash memory system that can be used as the nonvolatile memory 2 of FIG. 1 is described. The system controller is typically implemented on a single integrated circuit chip 11 that is connected in parallel with one or more integrated circuit memory chips via a system bus 13, a single such memory chip 15 being shown in FIG. 2. have. The particular bus 13 shown includes a separate set of conductors 17 for carrying data, a set 19 for memory addresses and a set 21 for control and status signals. Alternatively, a single set of conductors can be time shared between these three functions. In addition, other configurations of system buses, such as a ring bus, filed August 9, 2004 and described in US Patent Application No. 10 / 915,039, entitled "Ring Bus Structure and It's Use in Flash Memory Systems," may be used. have.

A typical controller chip 11 has its own internal bus 23 that interfaces with the system bus 13 via the interface circuit 25. The main functions typically connected to the bus are the processor 27 (such as a microprocessor or micro-controller), a read only memory (ROM) 29 including code for initializing (“booting”) the system, memory and host. Random access memory (RAM) 31, which is mainly used for buffering data transferred between, and circuit 33 for calculating and checking an error correction code (ECC) for data passing through a controller between the memory and the host. . The controller bus 23 interfaces with the host system via circuits 35, which, via the external contacts 37 of the card, which is part of the connector 4, when the system of FIG. 2 is included in the memory card. Is done. The clock 39 is connected to each of the other components of the controller 11 and used by each of the other components of the controller 11.

In addition to the memory chip 15, any other connected to the system bus 13 typically includes an array of memory cells consisting of a number of sub-arrays or planes, two such planes for simplicity. Although 41 and 43 are shown, a larger number of such planes, such as four or eight, may be used instead. Alternatively, the memory cell array of chip 15 may not be divided into planes. However, when so divided, each plane has its own column control circuits 45 and 47 that can operate independently of each other. The circuits 45 and 47 receive their respective memory cell arrays from the address portion 19 of the system bus 13 and decode them so that a particular one or more of the respective bit lines 49 and 51 are received. To. Word lines 53 are addressed through row control circuits 55 in response to addresses received on address bus 19. Source voltage control circuits 57 and 59 are also connected to the respective planes, as are p-well voltage control circuits 61 and 63. If the memory chip 15 has a single array of memory cells, and if there are two or more such chips in the system, each array of chips is similar to a plane or sub-array within the multi-plane chip described above. Can work.

Data is transferred into and out of planes 41 and 43 through respective data input / output circuits 65 and 67 that are connected to data portion 17 of system bus 13. The circuits 65 and 67 program data into memory cells of their respective planes through lines 69 and 71 that are connected to the planes via respective column control circuits 45 and 47. To read data from the memory cells of their respective planes.

Although the controller 11 controls the operation of the memory chip 15 to program the data, read and erase the data, and pay attention to various housekeeping problems, each memory chip also performs such functions. In order to carry out commands from the controller 11. The interface circuit 73 is connected to the control and status portion 21 of the system bus 13. Instructions from the controller are provided to the state machine 75, which later provides specific control of other circuits to execute these instructions. Control lines 77-81 connect state machine 75 with these other circuits as shown in FIG. Status information from the state machine 75 is communicated to the interface 73 via lines 83 for transmission to the controller 11 via the bus portion 21.

Although other structures, such as NOR, may be used instead, the NAND structure of memory cell arrays 41 and 43 is presently preferred. For examples of NAND flash memories and their operation as part of a memory system, reference may be made to US Pat. Nos. 5,570,315, 5,774,397, 6,046,935, 6,373,746, 6,456,528, 6,522,580, 6,771,536 and 6,781,877 and US Patent Application Publication No. 2003/0147278.

An exemplary NAND array is shown by the circuit diagram of FIG. 3, which is part of the memory cell array 41 of the memory system of FIG. A large number of global bit lines are provided, and only four such lines 91-94 are shown in FIG. 2 for simplicity of description. Multiple serially connected memory cell strings 97-104 are connected between one of these bit lines and the reference potential. Using memory cell string 99 as a representative, multiple charge storage memory cells 107-110 are connected in series with select transistors 111 and 112 at either end of the string. When the select transistors of a string become conductive, the string is connected between its bit line and the reference potential. Then, one memory cell in the string is programmed or read at one time.

The word lines 115-118 of Figure 3 extend individually across the charge storage element of one memory cell in each of the plurality of strings of memory cells, with gates 119 and 120 selected at each end of the strings. Control the states of the transistors. Memory cell strings sharing the common word and control gate lines 115-120 form a block 123 of memory cells that are erased together. This block of cells contains the minimum number of cells that are simultaneously physically erasable. A row of one of the memory cells that is along one of the word lines 115-118 is programmed at a time. Typically, the rows of a NAND array are programmed in a defined order when starting at a row along word line 118 closest to the end of strings connected to ground or another common potential. A row of memory cells along word line 117 is next programmed and proceeds in this manner across block 123. The row along word line 115 is programmed last.

The second block 125 is similar and the strings of memory cells of the second block are connected to the same global bit lines as the strings in the first block 123, but with different sets of word and control gate lines. The word and control gate lines are driven to their proper operating voltages by the row control circuit 55. As shown in planes 1 and 2 of FIG. 2, when there is more than one plane or sub-array in the system, one memory structure uses common word lines that extend between them. Alternatively, there may be two or more planes or sub-arrays sharing common word lines. In other memory structures, the word lines of individual planes or sub-arrays are driven individually.

As described in the various referenced NAND patents and published applications, the memory system operates to store more than one bit of data in each by storing two or more detectable charge levels in each charge storage element or region. Can be. The charge storage elements of the memory cells are the most common conductive floating gates, as described in US Patent Application No. 2003/0109093, but may alternatively be a non-conductive dielectric charge trapping material.

4 shows the configuration of the flash memory cell array 7 (FIG. 1) used as an example in the following additional descriptions. Four planes or sub-arrays 131-134 of memory cells are placed on a single integrated memory cell chip, on two chips (two planes on each chip), or on four individual chips. May exist. The specific arrangement is not important to the discussion below. Of course, one, two, eight, sixteen or more other numbers of planes may exist in the system. The planes are separately divided into blocks of memory cells shown in FIG. 4 by rectangles, such as blocks 137, 138, 139 and 140, located in respective planes 131-134. There may be dozens or hundreds of blocks in each plane. As described above, a block of memory cells is an erase unit that is the minimum number of memory cells that can be physically erased together. However, because of the increased parallelism, blocks operate on larger metablock units. One block from each plane is logically linked together to form a metablock. Four blocks 137-140 are shown to form one metablock 141. All cells in the metablock are typically erased together. The blocks used to form the metablock need not be limited to the same relative positions within their respective planes, as shown in the second metablock 143 consisting of blocks 145-148. For high system performance, although it is usually desirable to extend metablocks across all planes, the memory system dynamically selects any or all of the metablocks in one, two or three blocks in different planes. It can be operated to have the ability to form. This allows the size of the metablock to more accurately match the amount of data available for storage in one programming operation.

The individual blocks are then divided into pages of memory cells for operational purposes, as shown in FIG. The memory cells of each of the blocks 131-134 are divided into, for example, eight pages P0-P7. Alternatively, there may be 16, 32 or more pages of memory cells in each block. A page is a unit of data programming and reading within a block, including the minimum amount of data that is programmed at the same time. In the NAND structure of Fig. 3, a page is formed of memory cells along a word line in a block. However, to increase memory system operational parallelism, such pages in two or more blocks may be logically linked into metapages. The metapage 151 is shown in FIG. 5 and is formed of one physical page from each of the four blocks 131-134. The metapage 151, for example, includes a page P2 in each of the four blocks, but the pages of the metapage do not necessarily have the same relative position within each of the blocks. For high system performance, although it may be desirable to program and read the maximum amount of data in parallel across all four planes, the memory system may also have one, two or three blocks in separate blocks within different planes. May be operated to form any or all of the metablocks. This allows programming and read operations to adaptively match the amount of data that can be conveniently handled in parallel, reducing the cases where portions of the metapage remain unprogrammed with data.

Most memory management techniques used to manage data using single pages and single blocks at a time can also be applied to metapages and metablocks. Similarly, techniques using metapages and metablocks may also be applied to single blocks and single pages. In general, it will be understood that certain examples of using pages and blocks are applicable to metapages and metablocks. Similarly, it will be understood that certain examples relating to metapages and metablocks are generally applicable to pages and blocks.

As shown in FIG. 5, a metapage formed of physical pages of multiple planes includes memory cells along the word line rows of such multiple planes. Rather than programming all of the cells in one word line row simultaneously, they are more typically programmed alternately into two or more interleaved groups, each group being a page of data (in a single block) or (multiple blocks). Store the metapage of the data). By programming alternating memory cells at the same time, a unit of peripheral circuits including data resisters and sense amplifiers need not be provided on each bit line, but rather is time-shared between adjacent bit lines. This saves the amount of substrate space needed for peripheral circuits and allows memory cells to be packed at increased density along the rows. Otherwise, it is desirable to program all cells simultaneously along a row to maximize the parallelism available from a given memory system.

Referring to Figure 3, simultaneous programming of data into all other memory cells along a row results in two rows of select transistors (not shown) along at least one end of the NAND strings, instead of the single row shown. Is most conveniently accomplished by providing them. The select transistors in one row then connect all other strings in the block to their respective bit lines in response to one control signal, and the select transistors in the other row all intervene in response to another control signal. Connect another string to their respective bit lines. Thus, two pages of data are written into each row of memory cells.

The amount of data in each logical page is typically an integer of one or more sectors of data, with each sector conventionally containing 512 bytes of data. 6 shows a logical data page of two sectors 153 and 155 of data of a page or metapage. Each sector is typically a 512 byte portion of user or system data stored therein and another number of bytes for the data in the portion 157 or overhead data associated with one of the physical pages or blocks in which it is stored. 159. The number of bytes of overhead data is typically 16 bytes, totaling 528 bytes for each of sectors 153 and 155. The overhead portion 159 includes an ECC calculated from the data portion 157 during programming, its logical address, and an experience count of one time the block was erased and re-programmed, one or more control flags, an operating voltage level. , And / or the like, plus ECC calculated from such overhead data 159. Alternatively, overhead data 159, or portions thereof, may be stored in different pages within other blocks.

As the parallelism of memories increases, the data storage capacity of the metablock increases, and the size of data pages and metapages also increases as a result. The data page can then comprise two or more data sectors. If there are two sectors in the data page and two pages per metapage, then there are four sectors in the metapage. Thus, each metapage stores 2048 bytes of data. This is a high degree of parallelism and can be increased even more as the number of memory cells in the rows increases. For this reason, the width of flash memories is expanding to increase the amount of data in pages and metapages.

Physically small, reprogrammable non-volatile memory cards and flash drives recognized above with data storage capacity of 512 megabytes (MB), 1 gigabyte (GB), 2 GB and 4 GB are commercially available, Data storage capacity can be higher. Figure 7 illustrates the most common interface between a host and such a mass memory system. The host processes data files generated or used by application software or firmware programs executed by the host. One example is a word processing data file, commonly found in computer hosts such as PCs, laptop computers, and the like, and another example is a drawing file of computer aided design (CAD) software. Documents in pdf format are also such files. Still digital video cameras generate a data file for each picture stored on the memory card. Cellular phones use data from files on an internal memory card, such as a phone directory. PDAs store and use various different files such as address files, calendar files, and the like. In any such application, the memory card may also include software to run the host.

Memory systems, in particular memory systems embedded in removable cards, can communicate with different hosts through a standard interface. Different hosts may use different interfaces for communicating with memory systems. The two categories of interfaces are to use a logical addressing system with a common logical address space and to use a file based addressing system.

LBA  interface

A common logical interface between the host and the memory system is shown in FIG. The contiguous logical address space 161 is large enough to provide addresses for all data that can be stored in the memory system. The host address space is typically divided into increments of clusters of data. Each cluster may be designed in a given host system to include multiple sectors of data, between about typical 4 and 64 sectors. The standard sector contains 512 bytes of data.

Three files 1, 2 and 3 have been created in the example of FIG. An application program running on a host system creates each file as an ordered data set and identifies it by a specific name or other reference. Sufficient available logical address space that is not already allocated to other files is allocated to file 1 by the host. File 1 is shown being assigned a contiguous range of available logical addresses. Ranges of addresses are also typically used for specific uses, such as specific ranges for host operating software that are later avoided to store data, even if these addresses are not used at the time the host is assigning logical addresses to the data. Is assigned.

When file 2 is later created by the host, as shown in FIG. 7, the host similarly allocates two different ranges of contiguous addresses within logical address space 161. The file does not need to be assigned contiguous logical addresses, but rather may be fragments of addresses between address ranges already assigned to other files. This example then indicates that another file 3 created by the host is allocated files 1 and 2 and other portions of the host address space that have not been previously assigned to other data. File 1, File 2, and File 3 are all allocated to the portions of the common logical address space (logical address space 161) in this example.

The host tracks memory logical address spaces by maintaining a file allocation table (FAT) where the logical addresses that the host assigns to a number of host files are maintained. FAT tables are typically stored in host memory as well as non-volatile memory, and are updated frequently by the host when new files are stored, other files are deleted, and files are changed. For example, when a host file is deleted, the hose can deallocate a previously deleted logical address to the deleted file by updating the FAT table to indicate that the logical addresses are now available for use with other data files. To do that. The logical address used in the FAT may be referred to as a logical block address (LBA), so that an interface that uses such logical addressing through a logical address space common to data from different files may be referred to as an LBA interface. Similarly, a protocol for communication using logical addresses for data to be conveyed may be considered an LBA protocol.

The host is not associated with the physical locations that the memory system controller chooses to store the files. A typical host only knows its logical address space and the logical addresses it has assigned to its various files. On the other hand, the memory system, through a typical host / card interface, only knows the portions of the logical address space in which data has been written, but not the logical address assigned to particular host files, or even the number of host files. The memory system controller translates the logical addresses provided by the host for storage and retrieval of data to specific physical addresses in the flash memory cell array in which the host data is stored. Block 163 represents an operational table of these logical-to-physical transformations maintained by the memory system controller.

The memory system controller is programmed to store data files in blocks and metablocks of the memory array 165 in a manner that maintains a high level of system performance. Four planes or sub-arrays are used in this description. The data is preferably programmed and read in the maximum parallelism allowed by the system, over the entire metablock formed of blocks from each of the planes. At least one metablock 167 is typically allocated as a reserved block for storing operating firmware and data used by the memory controller. Another metablock 169, or multiple metablocks, may be allocated for storage of host operating software, host FAT tables, and the like. Most of the physical storage space is reserved for the storage of data files. However, the memory controller does not know how received data is allocated by the host among its various file objects. All memory controllers typically interact with the host that data written to specific logical addresses by the host is stored at corresponding physical addresses as maintained by the controller's logical-to-physical address table 163. Recognize from

In a typical memory system, more storage capacity is provided for more blocks than are needed to store the amount of data in address space 161. One or more of these redundant blocks may be provided as redundant blocks for replacement for other blocks that may become defective during the life of the memory. The logical grouping of blocks contained within individual metablocks can vary for a variety of reasons, including replacement of the redundancy block, typically for the defective block originally assigned to the metablock. One or more additional blocks, such as metablock 171, are typically maintained in an erased block pool. When the host writes data to the memory system, the controller translates the logical addresses assigned by the host into physical addresses in the metablock in the erased block pool. Thereafter, other metablocks that are not used to store data in the logical address space 161 are erased and designated as erased full blocks for use during subsequent data write operations.

Data stored at specific host logical addresses is often overwritten by new data when the original stored data becomes obsolete. In response, the memory system controller writes new data to the erased block and then changes the logical-to-physical address table for these logical addresses, thereby creating a new physical block in which data at those logical addresses is stored. To identify. Thereafter, the blocks containing the original data at those logical addresses are erased and made available for storage of new data. If there is not enough storage capacity in the pre-erased blocks from the erase block pool at the beginning of the write, such erase often must occur before the current data write operation is completed. This adversely affects the speed of system data programming. The memory controller typically knows that data at a given logical address is obsolete by the host only when the host writes new data to their same logical address. Thus, many blocks of memory may be storing such invalid data for the time being.

In order to use the area of the integrated circuit memory chip efficiently, the sizes of blocks and metablocks are increasing. As a result, most individual data records store less data than the storage capacity of the metablock, and in many cases, much less data than the storage capacity of the block. Since the memory system controller typically directs new data to the erased full metablock, this may prevent portions of the metablocks from filling up. If the new data is updates of some data stored in another metablock, the remaining valid metapages of data from another metablock with logical addresses adjacent to the logical addresses of the new data metapages are also preferably in logical address order. Is copied into a new metablock. Older metablocks can hold other valid data metapages. This, over time, causes the data of some metapages in individual betablocks to become obsolete or invalidated and replaced with new data with the same logical address written to different metablocks.

Such data is periodically compressed or consolidated (garbage collection) to maintain sufficient physical memory space to store data over the entire logical address space 161. It is also desirable to keep sectors of data in the metablocks actually in the same order as their logical addresses, since this makes it more efficient to read the data at adjacent logical addresses. Thus, data compression and garbage collection are typically performed for this additional purpose. Some aspects of managing the use of metablocks and memory when receiving partial block data updates are described in US Pat. No. 6,763,424.

Data compression typically includes reading all valid data metapages from the metablock, writing them into a new block, and ignoring metapages with invalid data in the process. Metapages with valid data are also preferably arranged in physical address order that matches the logical address order of the data stored therein. Since metapages containing invalid data are not copied to the new metablock, the number of metapages occupied in the new metablock will be less than the number of metapages occupied in the old metablock. The old block is then erased and made available for storing new data. Then, the capacity of additional metapages obtained by consolidation can be used to store other data.

During garbage collection, metapages of adjacent or near adjacent logical addresses are collected from two or more metablocks and re-written into another metablock, typically a metablock in the erased block pool. When all valid data metapages are copied from the original two or more metablocks, all of the valid data metapages may be erased for future use.

Data consolidation and garbage collection can be time-consuming and can affect the performance of a memory system, especially if data consolidation and garbage collection need to occur before a command from the host is executed. Such operations are typically scheduled by the memory system controller to occur in the background as much as possible, but the need to perform these operations provides the host with a busy status signal until such operation is complete. You can do it. An example of where a host command may be delayed is that there are not enough pre-erased metablocks in the erased block pool to store all the data that the host wishes to write into memory, and that can be erased later. This is the case where data aggregation or garbage collection is first needed to remove one or more metablocks of data. Therefore care must be taken to manage the control of the memory in order to minimize such confusion. Many such technologies are filed December 30, 2003 and are entitled Serial Number 10 / 749,831, entitled “Management of Non-Volatile Memory Systems Having Large Erase Blocks”; Serial number 10 / 750,155, filed December 30, 2003, entitled “Non-Volatile Memory and Method with Block Management System”; Serial No. 10 / 917,888, filed August 13, 2004, entitled "Non-Volatile Memory and Method with Memory Planes Alighment"; Serial number 10 / 917,867, filed August 13, 2004; Serial number 10 / 917,889, filed August 13, 2004, entitled "Non-Volatile Memory and Method with Phased Program Failure Handling"; And serial number 10 / 917,725, collectively referred to hereinafter as "LAB patent applications," filed August 13, 2004, entitled "Non-Volatile Memory and Method with Control Data Management". .

One task in efficiently controlling the operation of memory arrays having very large erase blocks is to match and align the number of data sectors stored during a given write operation with the boundaries and capacity of the blocks of memory. One way is to configure the metablock used to store new data from the host to be less than the maximum number of blocks, as needed to store a smaller amount of data than the amount that fills the entire metablock. The use of adaptive metablocks is described in US patent application Ser. No. 10 / 749,189, filed December 30, 2003 and entitled "Adaptive Metablocks". The adjustment of the physical boundaries between metablocks and the boundaries between blocks of data is described in patent application serial numbers 10 / 841,118, filed May 7, 2004, and filed December 16, 2004, and entitled " Data Run Programming ", serial number 11 / 016,271.

The memory controller may also use the data from the FAT table stored in the nonvolatile memory by the host to operate the memory system more efficiently. One such use is to know when it is identified by the host that data is invalidated by deallocating their logical addresses. Recognizing this, the memory controller can typically schedule the erasure of blocks containing such invalid data before the host typically knows to write new data to such logical addresses. This is described in US patent application Ser. No. 10 / 897,049, filed on July 21, 2004, entitled "Method and Apparatus for Maintaining Data on Non-Volatile Memory Systems." Other techniques include monitoring host patterns that write new data into memory to infer where certain write operations are single files or multiple files, and where boundaries between files exist. US patent application Ser. No. 11 / 022,369, filed December 23, 2004, entitled "FAT Analysis for Optimized Sequential Cluster Management," describes the use of this type of technology.

In order to operate the memory system efficiently, it is desirable for the controller to know as much as possible about the logical addresses assigned by the host to the data of its individual files. The data files can then be stored in a single metablock or group of metablocks by the controller, rather than being scattered between a larger number of metablocks when the file boundary is not recognized. The result is that the number and complexity of data integration and garbage collection operations is reduced. As a result, the performance of the memory system is improved. However, when the host / memory interface includes the logical address space 161 (FIG. 7) as described above, it is difficult for the memory controller to recognize more about the host data file structure.

Referring to FIG. 8, a typical logical address host / memory interface as shown already in FIG. 7 is shown differently. Data files generated by the host are assigned logical addresses by the host. The memory system then looks at these logical addresses and maps them into the physical addresses of the blocks of memory cells where the data is actually stored.

File interface

The file-based interface between the memory system and the host for storing large amounts of data avoids using logical address space. Instead, the host logically addresses each file by a specific file ID (or other specific reference) and offset addresses of data units (such as bytes) within the file. This file address is provided directly to the memory system controller, which maintains its own table if the data in each host file is subsequently stored physically. This new interface can be implemented with the same memory system as described above with reference to Figures 2-6. The main difference from that described in Figures 2-6 is the way the memory system communicates with the host system.

The file interface is shown in FIG. 9, which should be compared with the LBA interface of FIG. The offsets of the data in the files of Figure 9 and the identification of files 1, 2 and 3 respectively are passed directly to the memory controller. This logical address information is then translated by the memory controller function 173 into the physical addresses of the metablocks and metapages of the memory 165.

The file interface is also shown in FIG. 10, which should be compared with the logical address interface of FIG. The logical address space of FIG. 8 and the FAT table maintained by the host do not exist in FIG. Rather, data files generated by the host are identified to the memory system by the file number and the offset of the data in the file. The memory then maps the files directly to the physical blocks of the memory cell array.

Since the memory system knows the locations of the data that make up each file, this data can be erased immediately after the host deletes the file. This is not possible with a typical logical address interface. In addition, by identifying host data by files instead of using logical addresses, the memory system controller can store data in a manner that reduces the need for frequent data integration and garbage collection. Thus, the frequency of data replication operations and the amount of replicated data are significantly reduced, thereby increasing the data programming and reading performance of the memory system.

Examples of file-based interfaces include those using direct data file storage. Direct data file storage memory systems are all pending US patent applications Ser. Nos. 11 / 060,174, 11 / 060,248 and 11 / 060,249, filed February 16, 2005, both Alan W. Sinclair or Peter J. Smith. And provisional application 60 / 705,388, filed by Alan W. Sinclair and Barry Wright and entitled "Direct Data File Storage in Flash Memories" (collectively referred to herein as "direct data file storage applications"). .

The direct data file interface of these direct data file storage applications as shown in Figures 9 and 10 is simpler than the logical address space interface described above as shown in Figures 7 and 8, and allows the memory system to perform better. Because of this, direct data file storage is desirable for many applications. However, host systems are nowadays primarily configured to work with LBA interfaces, so memory systems with direct data file interfaces are not compatible with most hosts. Thus, it would be desirable to provide the memory system with the ability to operate with either interface.

Dual interface

For some memory systems, especially those included in removable memory cards that can interface with different hosts, backward compatibility is a major concern. Many host systems use a form of sector-based storage similar to those shown in FIGS. 7 and 8 but cannot be easily adapted to work with file-based storage such as those shown in FIGS. 9 and 10. . Thus, it is desirable to have a memory system capable of interfacing with hosts using either a logically addressed interface or a file-based interface. Interposed between the LBA interface and the file-based backend, the LBA protocol adapter can allow a host using logical addressing to store data in a memory array that manages the data as files.

US patent application Ser. No. 11 / 196,869, filed August 3, 2005, entitled “Interfacing systems operating through a logical address space and on a direct data files basis”, describes an interface or file-based logically addressed memory system. We describe systems that allow you to interface with hosts using one of the interfaces. 11 shows such a system. This example combines the host operation of Figure 7 with the file-based memory operation of Figure 9, plus address translation 172 in the plus memory system. Address translation 172 maps groups of logical addresses across memory space 161 into individual logical files a-j shown across the altered address space 161 '. The entire logical address space 161 is preferably divided into such logical files so that the number of logical files depends on the logical address space and the size of the individual logical files. Each of the logical files contains data of a group of contiguous logical addresses over space 161. The amount of data in each of the logical files is preferably made identical, and the amount is equal to the data storage capacity of one metablock in memory 165. Unequal sizes of logical files and / or sizes different from the storage capacity of a block or metablock of memory are of course possible but not preferred.

The data in each of the individual files a-j is represented by a logical offset address in the files. The data offset and file identifier of the logical files are translated into physical addresses in memory 165 at 173. Logical files a-j are stored directly in memory 165 by the same processes and protocols described in direct data file storage applications. The process is similar to the data of FIG. 9 in memory 165, except that the known amount of data in each logical file may facilitate this, especially if the amount is equal to the capacity of a block or metablock of memory. Same as the one used to store files 1-3. It is shown in FIG. 11 that logical files a-j are mapped to different ones of the metablocks of memory 165. It is desirable to have a file-based data store interact with the host in the same or equivalent manner as current logical address memory systems that the host was designed to interface with. By mapping the individual logical files into corresponding individual memory metablocks, essentially the same performance and timing characteristics as when the logical address space interface is used are achieved by the direct data file interface memory system.

12 illustrates the method of FIG. 11 in a different manner. Figure 12 is the same as the logical address memory system operation of Figure 8, but with the added function of dividing the logical address space into logical files, step 172 of Figure 11 just described. Additionally, "Table for Mapping Data File to Physical Storage Blocks" in Figure 12 replaces "Table for Mapping Logical Addresses to Physical Storage Blocks in Figure 8." Logical Address-to-Logical File translation 172 may be considered part of an LBA protocol adapter that exists between a file-based backend and an interface using an LBA system.

The data file based back end storage system of FIGS. 11 and 12 designed to operate through a conventional logical address space interface with a host may also have an added direct data file interface. Both host data files from the file interface and logical files from the logical interface are translated into memory metablock addresses. The data is then stored at those addresses in memory by executing a direct data file protocol. This protocol includes the direct data file storage techniques of the direct data file storage applications previously listed.

By providing both types of host interface to a portable memory card or flash drive, or other form of removable memory system, the memory can be stored directly in memory, with most current hosts operating with a logical address space interface. It may work with the interfacing host or may be exchanged between two types of hosts. This allows users of hosts with newer file-based interfaces to use the memory most efficiently, but at the same time in a way that is backward compatible with conventional logical address space interfaces. In addition, essentially the same performance and timing characteristics are achieved as a result of the same one-to-one logical file to metablock mapping. Memory with dual host interfaces is still useful for a wide range of installed bases of hosts with conventional logical address space interfaces, allowing this to be accomplished by the user for newer direct data file interfaces. This provides a way to move directly from the current interface to the data file interface.

13 shows a memory system 300 having a dual host interface. The memory system includes host data files HF1, HF2... HFn supplied directly by the host via file interface 307 and logical files converted by LBA protocol adapter 301 from LBA interface 305. Save (LFa, LFb ... LFm). File-based backend 303 need not distinguish logical files from host files, but rather is optimized to handle both files. As such, the logical files are equivalent to the logical groups of systems described in the LBA patent applications, so the performance of the memory system 300 seen from the host system is dependent on the logical address space interface as described in the LBA patent applications. Match the performance of the system.

In addition to converting host data from a logically addressed format to a logical file format, the LBA protocol adapter 301 is compatible with the file-based backend 303 in response to certain conditions or specific LBA commands received from the host. Possible commands can be generated. Examples of generating commands for a direct data file back end in response to these conditions are shown in the following table.

Condition Direct data file commands issued Start of LBA Command Record_pointer <fileID><offset>
This command sets the offset address in the current file at which the next write command will operate. The current file is not open
Open_files = max Close <file ID> + idle + hang <until busy>
Instructions in this group close the least recently accessed file and allow the device to perform all ongoing garbage collection operations for the file. The file is not currently open Open <file ID> + record_pointer <file ID><offset>
The commands in this group open the current file and set the offset address at which the next write command will operate. The current file has changed. Record <fileID> + stream + record_pointer <fileID><offset>
The commands in this group record the accumulated data for the previous file and set the offset address in the current file at which the next write command will operate. The program block is full. Record <fileid> + stream
The commands in this group record the accumulated data for the current file. The program block is full
Valid_pages> min Close <file ID> + idle + hang <until busy>
Instructions in this group close the current file and allow the device to perform all ongoing garbage collection operations for the file. Termination of LBA Commands Record <file ID> + stream + save_buffer <file ID>
Instructions in this group write the accumulated data for the current file and allow the unprogrammed data remaining in the buffer to be programmed to a "swap block" in flash.

Object  interface

Various file-based interfaces can be used to transfer data between electronic devices. Some protocols provide files with a predetermined size according to the indication of the size. The size of the file generally remains unchanged in such a system, such a system may not be suitable for applications that require editing of the file. However, in transferring files from one device to another, such protocols can be useful and allow a high level of security. The indication of size is usually sent before the file data is transferred. A protocol for delivering files of a predefined size with an indicator of file size may be considered an object protocol. One object protocol is Microsoft's Picture Transfer Protocol (PTP). Another such protocol is also the Media Transfer Protocol, known as Media Transport Protocol (MTP) by Microsoft Corporation. The object protocol is particularly suitable for transferring files containing a predetermined amount of data, such as digital photos or MP3 music files. For example, such protocols can be used to transfer digital photos between a digital camera and a PC or to transfer MP3 music files from a PC to an MP3 player.

Media Transfer Protocol (MTP) provides an object interface that supports delivery of file objects of predefined size. Its main purpose is to allow communication between devices that can be temporarily connected to each other if each of the devices has a significant storage capacity. The interface allows for the exchange of binary data objects between devices, and the enumeration of the content of one device by another device. Some characteristics of the MTP interface are listed below. However, other object interfaces may have different characteristics. A more complete description of the MTP is provided in a document entitled "Media Transfer Protocol Enhanced" from Microsoft.

1. Communication Protocol

1.1 Initiator and Responder: Exchanges occur only between two devices at the same time, one device acting as the initiator and the other acting as the responder. An initiator is a device that initiates operations with a responder by sending operations. The responder does not initiate any operations but sends responses to the operations sent by the initiator. The device acting as the initiator must be able to enumerate and understand the content of the responding device to control the flow of operations in the protocol. Initiators are generally more powerful devices than responders. Examples of responders are simple content-playing devices such as digital cameras, and simple content-output devices such as portable audio players.

1.2 Sessions: A session is a communication state in which a connection is maintained between an initiator and a responder. The session provides a context for the reference objects and ensures that the responder device state does not change without the initiator alerting. The session is opened by the initiator and closed by either the initiator or the responder. The device can simultaneously maintain multiple open sessions. The initiator assigns a specific identifier to the session when the session is first opened and uses this identifier to identify the session when sending operations.

1.3 Transactions: Any operation arising from the initiator is a standard sequence of steps that provides a mechanism for transactions, action invocation by input parameters, binary data exchange, and response by parameters. Is performed. The data flow within each step is unidirectional. During the start of operation, data flows only from the initiator to the responder. During the response to the requested operation, data flows only from the responder to the initiator. During the binary data-exchange phase, data can flow in either direction, but never in both directions. Bidirectional binary data exchange must be performed by a number of operations. The initiator assigns an identifier to each transaction. The specified identifier is assigned to the first operation initiated in the session, which is incremented by one for each subsequent transaction.

A transaction consists of up to three phases: an operation request phase, a data phase, and a response phase. The operation request step and the response step share the same identifier, and an optional data step exists between two different steps as needed.

The operation request phase consists of the transmission of an operation request dataset identifying the operation that is invoked by the initiator, the context (session and transaction) in which the operation should be executed, and a limited set of parameters.

An optional data phase follows the operation request phase. The presence of this step is determined by the operation specified in the operation request phase. The data may be a transparent dataset defined within the protocol, or exchanged binary data for storage on the receiving device. The actual transmission of data at the data level may include sending the data in a container format and breaking it into packets, as may be required for the particular transport in use.

In the response phase, a fixed dataset is sent from the responder to the initiator, reporting information about ongoing transactions such as success / failure.

1.4 Events: Events are primarily transmitted by the responder as a way of transmitting information or alerts in advance. Unlike operations, events do not need to be acknowledged or triggered. Events need to be delivered asynchronously with data transfer or operational transactions. A transport defines a process by which events can be interleaved with a data stream during a transaction.

1.5 Synchronous and Asynchronous Transactions: All transactions in the communication protocol are synchronous, i.e. no new operation can be initiated until the previous operation is completely completed. Asynchronous operations can be simulated by separating the operation into an initiation to start the operation, and proceed with monitoring via events sent by the responder while the operation is running in the background on the device. If a new operation is attempted while an asynchronous operation is in progress, the responder responds with a busy failure state and the initiator must try again later.

2. Information Datasets

When the collections of data are exchanged, they are collected in a predefined structure called a dataset. There are three sets of information datasets that can be accessed using appropriate operations.

2.1 Device Information Dataset: The Device Information Dataset provides a description of the device and is the most static.

2.2 Object Information Dataset: The Object Information Dataset provides an overview of the key characteristics of an object. These key characteristics include the size of the data component of the object. The properties also include associations that can be used to associate data objects and describe hierarchical file systems on devices. The file hierarchy on the device can be represented without depending on any path or naming conventions specific to a particular file system. The properties of the object can also be retrieved from the object properties dataset.

2.3 Repository Information Dataset: A repository information dataset describes a repository contained in a device. The above description includes both the maximum capacity and the remaining free space to be written, and may include file naming conventions or directory structure conventions in use.

3. Characteristics

3.1 Device Characteristics: The device characteristics identify the settings and status conditions of the device and are not linked with any data objects on the device. Device characteristics may be read only or read-write. The characteristics are included in the device characteristic description dataset and can be set or retrieved using the appropriate operations.

3.2 Object properties: Object properties provide a mechanism for exchanging separate object-descriptive metadata with the objects themselves. The main advantage of object properties is to allow fast enumeration of large repositories, regardless of file-system. These properties provide information about the objects on the device and define the values they can contain. The properties are included in the object property dataset and can be set or retrieved using the appropriate actions.

4. Object Handles

Object handles are identifiers that provide a consistent reference to a logical object on the device, specified within the session. There is no special meaning for the value of object handles. The responder generates an array of object handles for the objects in the device in response to the open session operation from the initiator. Object handles are captured by the initiator by a get object handles operation that causes the responder to send an array of object handles to the initiator. When the initiator uses an object information transfer operation to define an object to be sent, the responder device allocates an object handle and returns it to the initiator in the response phase of the operation. When the session is closed, all object handles are invalidated and must be re-acquired by the initiator. The device may maintain the same object handles or change object handle values for the next session.

5. Object References

Because the object interface is a file system independent protocol, complex linkages cannot be formed between objects by embedding file names. An outline referencing mechanism has been defined to allow arbitrary object referencing. The references are unidirectional and it is not possible to determine which objects refer to a given object without examining all references on all objects in the device. References can be set or retrieved by using appropriate operations. Objects referenced by file handles must be consistent between sessions. References to deleted objects should not incorrectly refer to another object. Either object handlers should never be reused, or the device must delete all references to the object following the object.

6. Operations and Responses

Operation defines the communication that occurs between the initiator and the responder within a transaction. Information needed by the responder to perform the disclosed operation can be passed as parameters to the operation request. Five parameters can be sent. Additional information may also be passed to a predefined dataset in the data phase of the transaction. After every operation, the responder returns a response dataset with up to five parameters and a response code indicating the result of the operation. A large number of operations are defined. Examples of sequences of operations include a "transmit object" operation in which the initiator sends an object to the responder following a "send object information" operation and a "obtain object" in which the initiator receives an object from the responder following the "obtain object information" operation. It works.

14A shows an example of a transaction between initiator 410 and responder 412. Initiator 410 may be a PC and responder 412 may be an MP3 music player or a digital camera. Initiator 410 and responder 412 are connected to allow communication by, for example, a USB cable. For the first time, in the operation request phase, the initiator 410 identifies the operation that is invoked as the "send object information" operation. Secondly, in the data phase, initiator 410 sends object information 414 to responder 412. The object information 414 is information about a particular object that has just been sent by the initiator 410 to the responder 412. The object information 414 is transmitted by the initiator 410 before the object referenced by the initiator is transmitted. The object information may include a number of information about the object, including the size of the object. When the object to be transmitted is an MP3 music file, the size of the MP3 music file is transmitted as part of the object information. Third, in the response phase (after the object information 414 has been received by the responder 412), the responder 412 indicates that the object information 414 has been received. The transaction can end at this point.

FIG. 14B shows a second transaction that follows the transaction of FIG. 14A and is part of the same session between initiator 410 and responder 412. The second transaction is an "object transfer" transaction. For the first time, in the operation request phase, the initiator 410 identifies the operation that is invoked as an "object send" operation. Second, in the data phase, the initiator sends an object 416 to the responder 412. The object 416 may be an MP3 music file or a digital photo in a file format such as JPEG, GIF or bitmap. Object information 414 (including file size) for object 416 has already been sent to responder 412 by initiator 410 as described with reference to FIG. 14A. Third, in the response phase (after the object 416 is received), the responder 412 indicates to the initiator 410 that the object 416 has been received. The transaction can end at this point.

Object  Protocol adapter

In an embodiment of the invention, an object protocol adapter is provided in the memory system that allows a host using the object protocol to interface with a memory system using a file based backend as described above. The object protocol adapter receives data and commands via the object interface according to the object protocol and performs appropriate translations before sending the data and commands to the backend. In one example, the host uses MTP to interface with the memory system, and the memory system uses a direct data file backend to store data. The object protocol adapter performs the proper conversion of both commands and data between the host interface and the back end.

FIG. 15 shows an example of an object protocol adapter interposed between object interface 520 and file-based backend 522. The object interface 520 is an interface to a file object of a predetermined size, eg, MTP or PTP objects. The size of the object is sent before the object is sent by the host. The object protocol adapter 524 manages the protocol by which the memory system 526 communicates with a host. The object protocol adapter 524 also manages transactions for information exchange with the host and performs translations. Transactions are performed between the file-based backend and the object protocol adapter according to the file-based protocol.

The object protocol adapter 524 manages opening and closing files by sending appropriate commands to the file-based backend 522 when a new file object is sent by the host (according to the object protocol). In particular, because the file has a predetermined size in the object protocol, the object protocol adapter 524 is responsible for closing the file when a predetermined amount of file data has been received. Hosts using the object protocol typically do not send a separate end-of-file indicator, which causes the object protocol adapter 524 to generate a file endpoint indicator, which is used when the entire file object is received. To the backend 522 that is based. In this way, when the memory system 526 receives a number of files from a host using the object protocol, the file-based back end 522 (as usually occurs in the direct data file back end) is the maximum that this is. Do not keep files open until a number of open files are reached. Instead, each file is received as a complete object, and the file-based backend receives instructions from the object protocol adapter 524 after the complete file has been received, so that the file-based backend closes the file. This reduces the burden of maintaining many open files. Once closed, the file can be scheduled for garbage collection.

The object protocol adapter can manage the state of the memory system. In particular, for memory systems having a direct data file back end, three states are defined that cause the memory system to change its behavior in response to a host command. These three states are "idle", "standby" and "shutdown". The three states are initiated in response to the corresponding state commands from the host, in case the host uses a direct data file instruction set and equivalents thereof. If the host uses an object protocol, the object protocol adapter may issue status commands. The object protocol adapter may send status commands to a file based backend in response to equivalent commands received from the host if the host is using an object protocol that includes such commands. Alternatively, the object protocol adapter may generate state commands based on inferring the state of the host from other factors. For example, the host may provide some indication that it will not remove power for a period of time, and in response, the Object Protocol adapter may send a "idle" status command to the file-based backend. Similarly, it may indicate that the host is about to remove the membrane power, or the Object Protocol adapter may infer that the power is about to be removed based on the host's operation, and in response, the Object Protocol adapter may attach to the file-based backend. You can send a "Shutdown" command.

One of the main functions of the Object Protocol Adapter is to convert host data from predefined files received from the host (according to the object protocol) to streaming data for the file-based backend. Whereas a host using an object protocol (which acts as an initiator in MTP) transfers a file with a predefined size and requires a response from the responder, the file-based backend typically provides such a response. It is not configured. In particular, where a direct data file backend is used, the data is generally streamed and there is no equivalent of the response phase of the MTP. The object protocol adapter converts the object from the host into streaming data and generates an appropriate response to the host when all the data of the object is received.

In object protocols such as MTP, a separate operation for the transfer of information about an object precedes the operation to read or write the object. This information transfer operation is a "setting" operation on object properties (object information) when an object is recorded. This information transfer operation is the "acquisition" operation on the object characteristics when the object is read. Object properties are in the form of a dataset that contains the length of the object.

When an object is being written to the memory system 526 of Figure 15, the dataset for the object is first received by the object protocol adapter 524 from the host. The host is considered to be an initiator in the MTP period. The information in the dataset is used to control subsequent transactions that implement the write operation. The dataset is also stored in the memory system 526 as metadata. During the write operation, the object protocol adapter 524 counts the amount of data delivered from the initiator during the data phase of the write operation. The object protocol adapter 524 identifies the endpoint of the object data from this count. The object protocol adapter then generates a response that is sent to the host. The object protocol adapter 524 also sends a command to the file-based backend 522 to close the file.

When an object is being read from the memory system 526 of FIG. 15, metadata for the object is first obtained from the back end 522 on a file basis by the object protocol adapter 524. The metadata for the object is then used to control subsequent transactions that implement the read operation. The object protocol adapter 524 also sends metadata stored in the memory system 526 to the host as a dataset for the object. The object protocol adapter 526 counts the amount of data transferred from the file-based backend 522 during the data phase of the read operation. The object protocol adapter 524 identifies the endpoint of the data from this count. The object protocol adapter 524 then generates a response that is sent to the host after the object is sent.

The object protocol adapter translates between object information datasets used in object protocols such as MTP and metadata stored in file based memory systems such as using a direct data file backend. "Metadata" is a term used to indicate data about an object stored separately from and managed separately from the object. Thus, the object information dataset in the MTP is an example of metadata. The direct data file backend may store the metadata in the same format or in a different format as used by the object protocol. The term "file_information" is also used for metadata in direct data file systems. When the object protocol adapter 524 receives a metadata related command from a host, the object protocol adapter 524 may translate the command into a format compatible with the file-based backend 522. In some cases, however, no translation is needed since the instructions used for metadata in the object protocol are compatible with file-based backend 522.

Metadata is information generated by the host associated with a file. The characteristics and content of the metadata are determined by the host and are generally not interpreted by the device that stores the files and metadata. Metadata instructions are used to initiate metadata input and output operations for the specified file stored by the direct data file back end, and to specify an offset address value in the metadata. Metadata commands may be generated by the object protocol adapter when corresponding commands regarding MTP datasets are received from the host. Examples of metadata commands used by the direct data file backend system are shown in the following table.

Command Parameters Explanation Metadata_record <File ID> Writes metadata for the file specified at the offset address specified by the current value of the metadata_record pointer. Metadata_read <File ID> Read the metadata for the file specified at the offset address specified by the current value of the metadata_read pointer. Metadata_record_pointer <File ID>
<Offset> Defines a new current value for the metadata_record_pointer for the specified file. Metadata_read_pointer <File ID>
<Offset> Defines a new current value for the metadata_block_pointer for the specified file.

Metadata_Record: The metadata streamed to the device after receipt of the metadata_record command is overwritten with metadata for the file specified at the offset address defined by the current value of the metadata_record_pointer. The content and length of metadata for a specified file is determined by the host. The metadata_write command is terminated by the reception of any other command.

Metadata_Read: The metadata for the file specified at the offset address defined by the current value of the metadata_read_pointer may be streamed from the device after receipt of the metadata_read command. Metadata streaming ends when the end point of the metadata is reached, and this condition can be identified by the host by status command. The metadata_read command is terminated by the receipt of any other command.

Metadata_record_pointer: The metadata_record pointer instruction sets a metadata_record_pointer for a specified file for a specified offset address. The metadata_record_pointer is incremented by the device when metadata is streamed to the device after the metadata_record command.

Metadata_read_pointer: The metadata_read_pointer command sets a metadata_read_pointer for a specified file for a specified offset address. The metadata_read_pointer is incremented by the device when metadata is streamed from the device after the metadata_read_command.

In some cases, the host may have a hierarchical arrangement of objects. For example, files can be stored in directories and subdirectories. Direct data file backends generally store files without any hierarchical structure (ie, in a logically flat arrangement). To harmonize the two systems, the object protocol adapter can recreate the hierarchical structure of the stored objects by using metadata associated with the objects. In the case where the host maintains the hierarchy, information about the state of the file in the hierarchy is stored as metadata when the file is stored. When the memory system is accessed by the host, the metadata is read first so that the object protocol adapter can determine the hierarchical structure and return this information to the host. In this way, the object protocol adapter can regenerate hierarchical information even if the files are stored in the memory system regardless of this hierarchical information. For example, directories and sub-directories in which files are located in a hierarchy of hosts can be stored as metadata when the files are stored. Subsequently, when the host attempts to access the contents of the memory system, directory and subdirectory information is reflected in the information returned to the host.

Multi-Protocol Interfaces

In an embodiment of the present invention, a logical defined over a logical address space defined for objects with objects having a predetermined size (such as in accordance with the MTP protocol), files received as streamed files without a predetermined size, and defined for the memory system. A memory system is provided that can receive and store sectors of data having addresses. Protocol adapters are configured to correspond to these three protocols and are selected according to the protocol used by the host.

16 shows a memory system 629 having three protocol adapters 630, 632, 634 connected to a common direct data file interface 636. Direct data file interface 636 and direct data file store 638 are within a file based back end 640 that can be considered as a direct data file back end. Thus, memory system 629 uses a common back end for data received from either of the file interfaces. Partitioning of memory may not be required in such a system, so that the available space in the memory array is used efficiently. Thus, blocks in the array can be used for storage of data received from file interfaces, object interfaces, and LBA interfaces at different times. However, data received from the LBA interface may be stored in blocks that store only data received from the LBA interface at that time. Data received from the file interface and the object interface is generally managed in such a way that garbage collection is reduced to reflect its file structure.

FIG. 16 illustrates LBA interface 639 connected to file-based backend 640 via LBA protocol adapter 634. LBA protocol adapter 634 may use any other method of converting LBA data into logical files, or converting LBA data into a format suitable for reception by a file-based back end.

Object interface 642 is connected to file-based backend 640 via object protocol adapter 632. In general, object protocol adapter 632 translates data and instructions from one protocol to another, allowing a host using the object protocol to access a file-based backend. While this may simply include a one-to-one translation from an object protocol command to a file based command, in some cases, the commands do not have equivalents in other protocols. In such cases, the object protocol adapter can make more translations than simple. For example, when an MTP host sends metadata that includes an object's size, then sends the object, the object protocol adapter recognizes the end point of the object and issues a response to the MTP host. The object protocol adapter also issues a close file command for the file-based backend at this point.

File interface 644 is connected to file-based backend 640 via file protocol adapter 630. In some cases, a host using an appropriate file-based protocol can communicate directly with the file-based backend without requiring any translations. However, in other cases, the host may transfer files using a protocol that is file-based but not the same as that of the file-based backend. In such cases, the file protocol adapter 630 may perform any necessary translation.

The memory system of Figure 16 is compatible with hosts using at least three different protocols. The memory system may also be compatible with other hosts if additional protocol adapters are provided.

FIG. 17 illustrates the memory system 629 of FIG. 16 with a file protocol adapter 630, an object protocol adapter 632, and an LBA protocol adapter 634 together considered a translation layer 750. Each protocol adapter provides translations as needed between the backend 640 based on a particular host protocol and file. In some cases, memory system 629 may communicate with one or more hosts at the same time. For example, memory system 629 may be connected to a network to which multiple hosts are attached. In other examples, a single host may have different applications running that act as if they are different hosts, and may communicate with the memory system using different protocols. In such cases, the translation layer 750 must resolve any conflict between different hosts. By providing coordination between different hosts, the file-based backend 640 does not receive conflicting commands. This may mean that one host is denied access until another host completes a particular task. For example, if the object protocol adapter 632 is delivering an object or metadata, the translation layer 750 may be file based on the LBA protocol adapter 634 and the file protocol adapter 630 until the operation is complete. It may be so as not to communicate with one backend 640. This may mean sending a busy signal to hosts attempting to access the memory system via LBA interface 639 or file interface 644. In some examples, different hosts may access the file-based backend 640 via interleaved transactions, over the same time period. In such cases, the translation layer 750 coordinates between hosts.

17 shows an interface layer 752 that includes a file interface 644, an object interface 642, and an LBA interface 639. File interface 644, object interface 642, and LBA interface 639 are shown as other elements, but this is a logical representation of the logical interface of memory system 629, and three separate physical interfaces It doesn't have to exist. In some examples, a single physical interface (such as a USB connector or SD connector) is common to file interface 644, object interface 642 and LBA interface 639 along with any other interfaces used. Which interface is used and hence which protocol adapter is used depends on the protocol used by the host. In some cases, the host protocol may be indicated by the host as part of a hand-shaking routine when the memory system is first connected to the host. In other cases, the host protocol is inferred by the memory system 629 from instructions sent by the host. The interface layer 752 can detect the host protocol used from the indication sent by the host or in some other manner, and select the appropriate interface for communication in accordance with the host protocol. Thus, when the memory system detects that the host is using the MTP protocol, the object interface 642 and the object protocol adapter 632 are selected. In general, only one protocol adapter is selected at any one time. In some cases, however, protocol adapters may be selected alternately to allow interleaved access by two or more hosts.

It will be appreciated that the elements of FIG. 17 correspond to logical components of the memory system 629 and do not necessarily correspond to individual physical elements. Thus, the functions of the interface layer 752 and the translation layer 750 may be accomplished by dedicated circuitry or using appropriate firmware operating on the controller. In one example, a single physical interface may be managed by a memory controller selecting protocol adapters operating on the memory controller to convert data and instructions into a format compatible with the common back end. Although FIG. 17 shows only three protocol adapters, real memory systems may have more than three or fewer protocol adapters. In some cases, there may be more than one object protocol adapter. For example, there may be an object protocol adapter for MTP and a separate object protocol for another object protocol (eg, PTP). Similarly, there may be one or more file protocol adapters for different file protocols and different LBA protocol adapters for different LBA protocols. For example, Patent Application No. 11,302,764 by Alan W. Sinclair, entitled “Logically-Addressed File Storage Methods” provides examples of alternative LBA protocols.

conclusion

Although various aspects of the invention have been described with reference to exemplary embodiments of the invention, it will be understood that the invention is protected within the scope of the appended claims.

Claims (37)

A memory system for storing data in a nonvolatile memory array, the memory system receiving data from one or more applications in different logical formats, storing data in the nonvolatile memory array in a common logical format, and silver, A first protocol adapter for receiving first data from a first application as a first host file after an indication of the length of the first host file and transferring the first data to the nonvolatile memory array, wherein the first protocol adapter. A first protocol adapter, wherein the data is stored at a location recorded using the first file identifier; A second data stream from the second application, the second data being identified as data in a second host file, without receiving an indication of the length of the second host file, and transmitting the second data to the non-volatile memory array. A second protocol adapter, wherein the second data is stored at a location recorded using a second file identifier; And As a third protocol adapter for receiving third data from a third application as a plurality of sectors having individual logical addresses from a logical address range defined for the memory system and transmitting the third data to the non-volatile memory array A third protocol adapter, wherein the third data is stored at a location recorded using a third file identifier; Memory system comprising a. 2. The memory system of claim 1 wherein the memory system is included in a memory card that can be removably connected to host systems by a standardized connection. The method of claim 2, wherein the first application is executed in a first host system, and the memory card is connected to the first host system at a first time. The second application is executed on a second host system, the memory card is connected to the second host system at a second time, The third application is executed on a third host system, and the memory card is connected to the third host system at a third time. The method of claim 1, wherein locations of the first, second, and third data are written to entries representing one or more blocks in the memory array corresponding to each of the first, second, and third file identifiers. Characterized by a memory system. 2. The memory system of claim 1 wherein the first protocol adapter generates and provides an indication to the host that the first host file has been received. 2. The memory system of claim 1 wherein the first protocol adapter generates an indicator of an endpoint of the first host file that causes the first data to be scheduled for garbage collection. A memory system included in a removable memory card connected to a host interface and storing data received via the host interface, the memory system comprising: Nonvolatile memory array; A back end memory management system for managing data in the nonvolatile memory array as files; An interface layer in communication with the host; And A translation layer located between the interface layer and the backend memory management system; Including, The translation layer receives host commands from the interface layer, the host commands comply with an object protocol, and the translation layer generates translated commands toward the backend memory management system in response to receiving the host commands. And the translated instructions do not conform to the object protocol. 8. The memory system of claim 7, wherein the object protocol is a media transport protocol (MTP). 8. The method of claim 7, wherein the host transmits metadata including an indication of the size of the object before transmitting the object, and wherein the translation layer determines from the indication when the entire object was received from the host. Memory system. 10. The system of claim 9, wherein the translation layer generates a response sent to the host and an endpoint of a file indicator sent to the backend memory management system in response to determining that the entire object has been received. Memory system. The method of claim 7, wherein the translation layer, A first protocol adapter for translating communication from a second host using a host file protocol into a back end file protocol; And An LBA protocol adapter for translating communication from a third host using a logical address protocol into a backend file protocol; The memory system further comprises. 12. The system of claim 11, wherein the LBA protocol adapter receives sectors of data having logical addresses assigned by the third host from a logical address space defined for the memory system, and converts the data sectors into meta data of the memory array. A memory system for mapping to virtual files of the same size as the capacity of the block. A memory system for storing data in a nonvolatile memory array, the memory system receiving data from one or more applications in different logical formats, storing data in the nonvolatile memory array in a common logical format, and silver, A first protocol adapter for receiving first data from a first application as a first host file after an indication of the length of the first host file and transferring the first data to the nonvolatile memory array, wherein the first protocol adapter. A first protocol adapter, wherein the data is stored at a location recorded using the first file identifier; And Receiving second data from a second application as a stream of data identified as data of a second host file, without a preceding indication of the length of the second host file, and transmitting the second data to the non-volatile memory array. A second protocol adapter, wherein the second data is stored at a location recorded using a second file identifier; Memory system comprising a. 14. The memory system of claim 13 wherein the memory system is included in a memory card that can be removably connected to host systems by a standardized connection. 15. The system of claim 14, wherein the first application is run on a first host system, and the memory card is connected to the first host system at a first time; The second application is executed on a second host system, and the memory card is connected to the second host system at a second time. 15. The memory system of claim 13 wherein the locations of the first and second data are written into entries representing one or more blocks in the memory array corresponding to each of the first and second file identifiers. 15. The memory system of claim 13 wherein the first protocol adapter generates and provides an indication to the host that the first host file has been received. 14. The memory system of claim 13 wherein the first protocol adapter generates an indicator of an endpoint of the first host file that causes the first data to be scheduled for garbage collection. A method of operating a memory system to be compatible with a plurality of host protocols, the memory system comprising a block erasable memory array and a controller, the method comprising: Detecting a host protocol when connected to a host, and selecting one protocol adapter from the plurality of protocol adapters in response to the detected host protocol, wherein the plurality of protocol adapters are at least first, second and third protocol adapters; Including, detecting and selecting; Selecting a first protocol adapter in response to detection of a first host protocol that transfers files of a predetermined length behind indicators of the file length, wherein each file has a unique file identifier; Selecting a second protocol adapter in response to detection of a second host protocol that transmits files without indicators of file length, wherein each file has a unique file identifier; And Selecting a third protocol adapter in response to detection of a third host protocol transmitting sectors of data, wherein each sector has a logical address from a logical address range defined for the memory system; step; Memory system operation method comprising a. 20. The method of claim 19, wherein the first file received via the first protocol adapter is stored in a first plurality of blocks of a memory array and a first relationship between the first file identifier and the first plurality of blocks. Recording; Storing a second file received via the second protocol adapter in a second plurality of blocks of a memory array and recording a second file identifier and a second relationship between the second plurality of blocks; And Storing the plurality of sectors received via the third protocol adapter in a third plurality of blocks and recording a third file identifier and a third relationship between the third plurality of blocks. How it works. 20. The method of claim 19, wherein the first protocol adapter generates a response to the first host after a predetermined length of data is received. 20. The method of claim 19, wherein the first protocol adapter generates an endpoint of a file indicator in response to receiving a predetermined length of data, the indicator causing the files to be closed and scheduled for garbage collection. 20. The method of claim 19, further comprising selecting only one of the first, second, or third protocol adapters at any one time. 20. The memory system of claim 19 further comprising alternately selecting different ones of the first, second, and third protocol adapters at different times to allow interleaved access by one or more host applications. How it works. 20. The method of claim 19, wherein the memory system is implemented in a removable memory card. 27. The method of claim 25, wherein the memory card is in accordance with a standard selected from compact flash, multimedia card, secure digital, miniSD, memory stick, smart media or transflash. A method of operating a nonvolatile memory system in a removable memory card, comprising: Receiving metadata from a host, the metadata comprising an indication of the amount of data in the object; Receiving the object from the host and determining whether the entire object has been received by comparing the amount of object data received from the host with the amount of data represented by the metadata; And In response to determining that the entire object has been received, sending a response to the host and closing a file in the memory system corresponding to the object, wherein the file is marked for garbage collection as a result of the closure. step; Non-volatile memory system operating method comprising a. 28. The method of claim 27, further comprising storing the metadata in a nonvolatile memory system. 28. The method of claim 27, wherein the host maintains a layer containing an object, and the location of the object within the layer is provided by metadata. 30. The method of claim 29 wherein the file is stored in a memory system regardless of its location within the hierarchy. 31. The method of claim 30, wherein metadata is used to regenerate the layer later when a file is requested by the host. A method of operating a removable memory system compatible with a plurality of host protocols, the memory system comprising a block erasable memory array and a controller, the method comprising: Detecting a host protocol when connected to a host, and selecting one protocol adapter from the plurality of protocol adapters in response to the detected host protocol, wherein the plurality of protocol adapters comprises at least first and second protocol adapters; , Detection and selection step; Selecting a first protocol adapter in response to detection of a first host protocol that transfers files of a predetermined length behind indicators of the file length, wherein each file has a unique file identifier; And Selecting a second protocol adapter in response to detection of a second host protocol that transmits files without indicators of file length, wherein each file has a unique file identifier; A method of operating a removable memory system comprising a. 33. The method of claim 32, wherein the first file received via the first protocol adapter is stored in a first plurality of blocks of a memory array and the first relationship between the first file identifier and the first plurality of blocks is determined. Recording; And Storing a second file received via the second protocol adapter in a second plurality of blocks of a memory array and recording a second file identifier and a second relationship between the second plurality of blocks. How a removable memory system works. 33. The method of claim 32 wherein the first protocol adapter generates a response to the first host after a predetermined length of data is received. 33. The removable memory system of claim 32, wherein the first protocol adapter generates an endpoint of a file indicator in response to receiving a predetermined length of data, the indicator causing the files to be closed and scheduled for garbage collection. Way. 33. The method of claim 32, further comprising selecting only one of the first or second protocol adapters at any one time. 33. The method of claim 32, further comprising selecting alternating adapters of the first and second protocol adapters when the removable memory system is in communication with one or more hosts.

Images