Patent Publication Number: US-9405705-B2

Title: Hierarchical data storage system

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 12/688,883, filed Jan. 17, 2010, which claims the benefit of U.S. Provisional Patent Application 61/145,562, filed Jan. 18, 2009, U.S. Provisional Patent Application 61/163,133, filed Mar. 25, 2009, U.S. Provisional Patent Application 61/163,138, filed Mar. 25, 2009, and U.S. Provisional Patent Application 61/294,498, filed Jan. 13, 2010, whose disclosures are incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     Embodiments described herein are related to the field of data storage, and particularly to distributed data storage in multiple memory devices. 
     BACKGROUND 
     Several types of memory devices, such as Flash memories, use arrays of analog memory cells for storing data. Each analog memory cell stores a quantity of an analog value, also referred to as a storage value, such as an electrical charge or voltage. This analog value represents the information stored in the cell. In Flash memories, for example, each analog memory cell holds a certain amount of electrical charge. The range of possible analog values is typically divided into intervals, each interval corresponding to one or more data bit values. Data is written to an analog memory cell by writing a nominal analog value that corresponds to the desired bit or bits. 
     Some memory devices, commonly referred to as Single-Level Cell (SLC) devices, store a single bit of information in each memory cell, i.e., each memory cell can be programmed to assume two possible programming levels. Higher-density devices, often referred to as Multi-Level Cell (MLC) devices, store two or more bits per memory cell, i.e., can be programmed to assume more than two possible programming levels. 
     Flash memory devices are described, for example, by Bez et al., in “Introduction to Flash Memory,” Proceedings of the IEEE, volume 91, number 4, Apr., 2003, pages 489-502, which is incorporated herein by reference. Multi-level Flash cells and devices are described, for example, by Eitan et al., in “Multilevel Flash Cells and their Trade-Offs,” Proceedings of the 1996 IEEE International Electron Devices Meeting (IEDM), New York, N.Y., pages 169-172, which is incorporated herein by reference. The paper compares several kinds of multilevel Flash cells, such as common ground, DINOR, AND, NOR and NAND cells. 
     Eitan et al., describe another type of analog memory cell called Nitride Read Only Memory (NROM) in “Can NROM, a 2-bit, Trapping Storage NVM Cell, Give a Real Challenge to Floating Gate Cells?” Proceedings of the 1999 International Conference on Solid State Devices and Materials (SSDM), Tokyo, Japan, Sep. 21-24, 1999, pages 522-524, which is incorporated herein by reference. NROM cells are also described by Maayan et al., in “A 512 Mb NROM Flash Data Storage Memory with 8 MB/s Data Rate”, Proceedings of the 2002 IEEE International Solid-State Circuits Conference (ISSCC 2002), San Francisco, Calif., Feb. 3-7, 2002, pages 100-101, which is incorporated herein by reference. Other exemplary types of analog memory cells are Floating Gate (FG) cells, Ferroelectric RAM (FRAM) cells, magnetic RAM (MRAM) cells, Charge Trap Flash (CTF) and phase change RAM (PRAM, also referred to as Phase Change Memory—PCM) cells. FRAM, MRAM and PRAM cells are described, for example, by Kim and Koh in “Future Memory Technology including Emerging New Memories,” Proceedings of the 24 th  International Conference on Microelectronics (MIEL), Nis, Serbia and Montenegro, May 16-19, 2004, volume 1, pages 377-384, which is incorporated herein by reference. 
     Some memory systems store data in a plurality of memory devices using multiple processors or controllers. For example, U.S. Patent Application Publication 2009/0172257, whose disclosure is incorporated herein by reference, describes a mass storage system and method for breaking a host command into a hierarchy of data structures. Different types of data structures are designed to handle different phases of tasks required by the host command, and multiple data structures are sometimes used to handle portions of the host command in parallel. Disclosed embodiments include a Flash memory controller designed to allow a high degree of pipelining and parallelism. 
     U.S. Patent Application Publication 2009/0172261, whose disclosure is incorporated herein by reference, describes a storage controller containing multiple processors. The processors are divided into groups, each of which handles a different stage of a pipelined process of performing host reads and writes. In one embodiment, the storage controller operates with a Flash memory module, and includes multiple parallel pipelines that allow plural host commands to be handled simultaneously. 
     SUMMARY 
     Embodiments described herein provide a data storage system, including: 
     a plurality of non-volatile memory devices arranged in one or more sets; 
     a main controller, which is configured to accept commands from a host, and to convert the commands into recipes, each recipe including a list of multiple memory operations to be performed sequentially in the non-volatile memory devices belonging to one of the sets; and 
     one or more processors, each of which processors is associated with a respective set of the non-volatile memory devices and is configured to receive one or more of the recipes from the main controller and to execute the memory operations specified in the received recipes in the non-volatile memory devices belonging to the respective set. 
     In some embodiments, the memory operations in each recipe access multiple memory pages in the non-volatile memory devices. In an embodiment, the main controller is configured to generate a recipe that instructs a given processor to perform at least one action selected from a group of actions consisting of reading multiple pages from the non-volatile memory devices, writing multiple pages in the non-volatile memory devices, and erasing one or more memory areas in the non-volatile memory devices. In another embodiment, the main controller is configured to generate a recipe that instructs a given processor to copy multiple pages from one or more first locations in the non-volatile memory devices to a second location in the non-volatile memory devices. The recipe may instruct the given processor to modify at least one of the pages read from the first locations and to write the modified pages to the second location. 
     In a disclosed embodiment, the main controller is configured to generate a recipe that instructs a given processor to read first data from a first location in the non-volatile memory devices, to use the first data as an address pointing to a second location in the non-volatile memory devices, and to read second data from the second location using the address. In an embodiment, the system includes a volatile memory coupled to the main controller, and a given processor is configured to store in the volatile memory data that is used in executing the received recipes. In another embodiment, a volatile memory is coupled to the main controller, and the main controller is configured to generate a recipe that instructs a given processor to read first data from the volatile memory, to read second data from the non-volatile memory devices, to merge the first and second data, and to write the merged first and second data into the non-volatile memory devices. In yet another embodiment, each processor is configured to send to the main controller a request for exchanging data between the processor and the main controller, and the main controller is configured to exchange the data with the processor responsively to the request. 
     In some embodiments, the commands accepted from the host specify logical addresses, and the main controller is configured to translate the logical addresses into respective physical storage locations in the non-volatile memory devices, and to specify the memory operations in the recipes using the physical storage locations. In an embodiment, each processor is configured to store in the non-volatile memory devices given data and a logical address corresponding to the given data, to receive a recipe, which instructs the processor to retrieve the given data from the non-volatile memory devices and indicates the logical address, to read the given data and the logical address from the non-volatile memory devices, and to report an error responsively to detecting a mismatch between the logical address indicated in the recipe and the logical address read from the non-volatile memory devices. In another embodiment, each processor is configured to store in the non-volatile memory devices given data and a logical address corresponding to the given data, and, when copying the given data to an alternative physical storage location in the non-volatile memory devices, to read the logical address of the given data from the non-volatile memory devices and to indicate to the main controller that the read logical address in associated with the alternative physical storage location. 
     In a disclosed embodiment, the main controller is configured to assign respective priorities to the recipes, and each processor is configured to execute the recipes in accordance with the priorities. Additionally or alternatively, each processor is configured to receive two or more of the recipes in a first order, and to execute the recipes in a second order, different from the first order. In another embodiment, each processor is configured to identify that a first recipe includes a first write operation addressed to a given location in the non-volatile memory devices, and that a second recipe includes a second write operation, which is addressed to the given location and is subsequent to the first write operation, and to inhibit execution of the first write operation. 
     In still another embodiment, each processor is configured to identify that a first recipe includes a first read operation addressed to a given location in the non-volatile memory devices, and that a second recipe includes a second read operation, which is addressed to the given location and is subsequent to the first read operation, and to inhibit execution of the second read operation. In an embodiment, each processor is configured to identify that a first recipe includes a write operation that writes a value to a given location in the non-volatile memory devices, and that a second recipe includes a read operation that is addressed to the given location and is subsequent to the first write operation, and to serve the read operation from an internally-buffered version of the value obtained from the write operation, without applying the read operation to the non-volatile memory devices. 
     In some embodiments, the non-volatile memory devices include multiple analog memory cells arranged in groups, the system includes a volatile memory coupled to the main controller, and the main controller is configured to store in the volatile memory respective values of at least one property of the memory cells for at least some of the groups, and, when producing a recipe that addresses a given group, to indicate in the recipe a value of the property for the given group. In an embodiment, each processor is configured to extract the value of the property from the received recipe, and to execute the memory operations specified in the recipe responsively to the extracted value. In a disclosed embodiment, the at least one property includes Programming and Verification (PV) levels used in programming the memory cells, read thresholds used in reading the memory cells, endurance measures of the memory cells, elapsed times since latest programming of the memory cells, estimates of read disturb in the memory cells, and/or time-temperature integral values computed over the memory cells. In an embodiment, the main controller is configured to store in the volatile memory one or more read threshold values applicable to each of at least some of the groups, and to update the read threshold values during operation of the system. 
     In another embodiment, the main controller is configured to convert a given host command to a set of one or more recipes, and to send a command completion indication to the host after sending the set of the recipes to the processors, irrespective of execution of the recipes in the set. In yet another embodiment, a volatile memory is coupled to the main controller, and the main controller is configured to store in the volatile memory a linked list of data items representing data, each data item including a portion of the data and a pointer to a next data item on the list, and to generate a recipe that instructs a given processor to store the data in the non-volatile memory devices and points to a first data item on the list. In an embodiment, the given processor is configured to store the data by reading each data item from the volatile memory, storing the respective portion of the data in the non-volatile memory devices, extracting the pointer to the next data item from the read data item, and reading the next data item from the volatile memory responsively to the pointer. 
     There is additionally provided, in accordance with another embodiment, a method for data storage, including: 
     accepting commands from a host for data storage in a plurality of non-volatile memory devices arranged in one or more sets; 
     converting the commands into recipes, each recipe including a list of multiple memory operations to be performed sequentially in the non-volatile memory devices belonging to one of the sets; and 
     executing the recipes using one or more processors, each of which processors is associated with a respective set of the non-volatile memory devices, receives one or more of the recipes, and executes the memory operations specified in the received recipes in the non-volatile memory devices belonging to the respective set. 
     These and other embodiments will be more fully understood from the following detailed description taken together with the drawings in which: 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram that schematically illustrates a memory system, in accordance with an embodiment; and 
         FIGS. 2-4  are flow charts that schematically illustrate methods for data storage, in accordance with other embodiments. 
         FIG. 5  illustrates an embodiment of a computing system. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
     Overview 
     Embodiments that are described hereinbelow provide improved data storage systems and associated methods. The disclosed techniques store data in a plurality of non-volatile memory devices using a hierarchical configuration of processors, typically comprising multiple processors operating in parallel. In some embodiments, a memory system (e.g., a Solid State Disk—SSD) comprises a main controller and one or more processors. The non-volatile memory devices are arranged in one or more sets, and each processor is assigned to store data in the memory devices belonging to one of the sets. 
     The main controller receives data storage commands from a host, and converts the commands into recipes for execution by the processors. Each recipe comprises a list of multiple memory operations (e.g., page write and page read operations), to be performed sequentially in the memory devices belonging to one of the sets. Each processor receives one or more of the recipes from the main controller, and executes the memory operations specified in the received recipes in its respective set of non-volatile memory devices. 
     Various kinds of recipes can be defined and executed. Example recipes are recipes that write multiple pages in the non-volatile memory devices, recipes that read multiple pages from the non-volatile memory devices, recipes that erase certain memory areas and recipes that copy multiple pages from one location to another in the non-volatile memory devices. Several additional types of recipes are described herein. Typically although not necessarily, the memory operations in each recipe access multiple different pages. In a typical implementation, the host commands specify logical addresses, and the main controller converts the logical addresses into physical addresses when generating the recipes. 
     In some embodiments, each processor executes the recipes it receives from the main controller in an efficient manner, such as by optimizing the order in which the recipes are executed, identifying and eliminating superfluous memory operations in the recipes, and defining priorities among recipes or recipe types. Several example techniques are described herein. 
     The hierarchical system configurations described herein enable the main controller to operate at a high level of recipes, and relieve the main controller from direct management of the non-volatile memory devices. In some embodiments, the processors have considerable processing power and are capable of performing complex data storage operations, such as error detection and correction. In addition, the processors are typically autonomous in deciding when and how to execute the recipes they receive. As a result, the techniques described herein are highly scalable and can achieve high storage throughput and small latency. Moreover, the system configurations described herein are flexible and modular in adapting to different system needs and specifications. Using these configurations, a memory system can be dimensioned to match different system requirements with little or no modification to the individual system components. 
     System Description 
       FIG. 1  is a block diagram that schematically illustrates a multi-device memory system  20 , in accordance with an embodiment. System  20  accepts data for storage from a host  24  and stores it in memory, and retrieves data from memory and provides it to the host. In the present example, system  20  comprises a Solid-State Disk (SSD) that stores data for a host computer. In alternative embodiments, however, system  20  may be used in any other suitable application and with any other suitable host, such as in computing devices, cellular phones or other communication terminals, removable memory modules such as Disk-On-Key (DOK) devices, Secure Digital (SD) cards, Multi-Media Cards (MMC) and embedded MMC (eMMC), digital cameras, music and other media players and/or any other system or device in which data is stored and retrieved. 
     System  20  comprises multiple non-volatile memory devices  28 , each comprising multiple analog memory cells  32 . In the present example, devices  28  comprise NAND Flash devices, although various other suitable solid state memory types, such as NOR and Charge Trap Flash (CTF) Flash cells, phase change RAM (PRAM, also referred to as Phase Change Memory—PCM), Nitride Read Only Memory (NROM), Ferroelectric RAM (FRAM), magnetic RAM (MRAM) and/or Dynamic RAM (DRAM) cells, can also be used. 
     In the context of the present patent application and in the claims, the term “analog memory cell” is used to describe any memory cell that holds a continuous, analog value of a physical parameter, such as an electrical voltage or charge. Any suitable type of analog memory cells, such as the types listed above, can be used. In the present example, each memory device  28  comprises a non-volatile memory of NAND Flash cells. The charge levels stored in the cells and/or the analog voltages or currents written into and read out of the cells are referred to herein collectively as analog values or storage values. Although the embodiments described herein mainly address threshold voltages, the methods and systems described herein may be used with any other suitable kind of storage values. 
     In each memory device  28 , data is stored in memory cells  32  by programming the cells to assume respective memory states, which are also referred to as programming levels. The programming levels are selected from a finite set of possible levels, and each level corresponds to a certain nominal storage value. For example, a 2 bit/cell MLC can be programmed to assume one of four possible programming levels by writing one of four possible nominal storage values into the cell. Memory cells  32  are typically arranged in one or more memory arrays (“planes”), each comprising multiple rows and columns. The memory cells in each row are connected to a respective word line, and the memory cells in each column are connected to a respective bit line. 
     Each memory array is typically divided into multiple pages, i.e., groups of memory cells that are programmed and read simultaneously. Pages are sometimes sub-divided into sectors. In some embodiments, each page occupies an entire row of the array, i.e., an entire word line. For two-bit-per-cell devices, for example, each word line stores two pages. In alternative embodiments, each row (word line) can be divided into two or more pages. For example, in some devices each row is divided into two pages, one comprising the odd-order cells and the other comprising the even-order cells. In an example implementation, a two-bit-per-cell memory device may have four pages per row, a three-bit-per-cell memory device may have six pages per row, and a four-bit-per-cell memory device may have eight pages per row. 
     Typically, a given memory device comprises multiple erasure blocks (also referred to as memory blocks), i.e., groups of memory cells that are erased together. Each memory device  28  may comprise a packaged device or an unpackaged semiconductor chip or die. A typical SSD may comprise a number of 4 GB devices. Generally, however, system  20  may comprise any suitable number of memory devices of any desired type and size. 
     Each memory device  28  comprises an internal NAND controller  36 , which stores data in the memory cells of the device. Each NAND controller  36  performs data storage and retrieval in its respective memory device in response to NAND commands. Each NAND command typically specifies writing or reading of a single memory page in the memory device. The interface with the NAND controllers may comprise, for example, the Open NAND Flash Interface Specification, revision 2.2, Oct. 7, 2009, which is incorporated herein by reference. Alternatively, NAND controllers  36  may be controlled using any other suitable standard or protocol. 
     In system  20 , data storage in memory devices  28  is carried out by a hierarchical configuration of processors and controllers, whose operation is described in detail below. The disclosed schemes provide a high degree of parallelization of storage tasks, and therefore achieves high storage throughput with small latency. 
     Memory devices  28  in system  20  are arranged in subsets. A Memory Signal Processor (MSP)  40  is associated with each subset and performs data storage and retrieval in the subset. In some embodiments, each MSP  40  comprises an Error Correction Code (ECC) unit  44 , which encodes the data for storage with a suitable ECC, and decodes the ECC of data retrieved from memory. In some embodiments, the subsets of memory devices  28  (each with its respective MSP) are aggregated into groups that are referred to as channels. 
     System  20  comprises a main controller  52 , which manages the system operation. Main controller  52  comprises multiple channel controllers  48 , each responsible for data storage and retrieval in a respective channel. The main controller accepts commands from host  24  to store and/or retrieve data, and communicates with the MSPs in order to carry out these commands. Typically, the communication between the main controller and the channel controllers, between the channel controllers and MSPs, and between the MSPs and the NAND controllers, comprise both data and control aspects. 
     In some embodiments, main controller  52  comprises a host interface processor  53  and a main processor  54 . The host interface processor forwards host commands between main controller  52  and host  24 , and forwards data between the MSPs and the host. Main processor  54  executes the host commands using the techniques described herein, performs Flash management functions on memory devices  28 , and communicates with the MSPs. In alternative embodiments, any other suitable main controller configuration can also be used. For example, Flash management functions may be partitioned between main processor  54  and MSPs  40 . In some embodiments, the system comprises volatile memory, in the present example one or more Dynamic Random Access Memory (DRAM) devices  56 , connected to main controller  52 . The role of DRAM  56  in the storage methods described herein is described in detail further below. In an embodiment, host interface controller  53  bridges data between the host and the DRAM. 
     In an example embodiment, system  20  comprises a total of eight channel controllers  48  and thirty-two MSPs  40 , i.e., each channel controller manages four MSPs. In this configuration, each MSP may manage between one and eight memory devices  28 . A given memory device  28  may comprise multiple dies. Alternatively, however, any other suitable numbers of channel controllers, MSPs and memory devices can also be used. The number of memory devices managed by each MSP may differ, for example, according to the storage capacity of system  20  and the storage density of devices  28 . In some embodiments, the channel controllers may be omitted. In these embodiments, the main controller stores and retrieves data by communicating directly with the MSPs. 
     The functions of NAND controllers  36 , MSPs  40 , channel controllers  48  and main controller  52  may be implemented, for example, using software running on suitable Central Processing Units (CPUs), using hardware (e.g., state machines or other logic), or using a combination of software and hardware elements. In some embodiments, NAND controllers  36 , MSPs  40 , channel controllers  48  and/or main controller  52  may comprise general-purpose processors, which are programmed in software to carry out the functions described herein. The software may be downloaded to the processors in electronic form, over a network, for example, or it may, alternatively or additionally, be provided and/or stored on tangible media, such as magnetic, optical, or electronic memory. 
     The system configuration of  FIG. 1  is an example configuration, which is shown purely for the sake of conceptual clarity. In alternative embodiments, any other suitable memory system configuration can also be used. Elements that are not necessary for understanding the principles of the embodiments, such as various interfaces, addressing circuits, timing and sequencing circuits and debugging circuits, have been omitted from the figure for clarity. 
     In the exemplary system configuration shown in  FIG. 1 , the channel controllers are comprised in the main controller, and the main controller, MSPs and memory devices are implemented as separate Integrated Circuits (ICs). In an alternative embodiment, memory devices  28 , MSPs  40 , channel controllers  48  and main controller  52  may be implemented as separate ICs. Alternatively, each subset of devices  28  with its respective MSP, can be fabricated on a common die or device. Further alternatively, the MSPs, channel controllers and main controller may be fabricated in a common Multi-Chip Package (MCP) or System-on-Chip (SoC), separate from memory devices  28  and DRAM  56 . In alternative embodiments, the elements of system  20  can be partitioned into packaged ICs or semiconductor dies in any other suitable way. 
     Further alternatively, some or all of the functionality of main controller  52  can be implemented in software and carried out by a processor or other element of the host system. In some embodiments, host  24  and main controller  52  may be fabricated on the same die, or on separate dies in the same device package. Although the embodiments described herein refer to multiple parallel processors (MSPs), the disclosed techniques can also be used in a system configuration comprising only a single MSP. 
     The hierarchical system configuration of  FIG. 1  is flexible in adapting to different system needs and specifications. For example, different capacity requirements may require different numbers of MSPs and memory devices, but have little effect on the main controller. Different throughput requirements can be met by changing the number of MSPs, without necessarily modifying the main controller or memory devices. Host interface changes typically affect the main controller but not the MSPs or memory devices. Adaptation to different kinds of memory devices usually affects the MSPs but has little or no effect on the main controller. The MSPs typically share the main controller&#39;s resources (e.g., DRAM), and therefore changing the number of MSPs usually does not require changes in the main processor. As such, system  20  can be dimensioned or adapted to different needs or specifications in a modular fashion, with minimal modifications of individual system elements. 
     Recipe-Based MSP Operation 
     In system  20 , main controller  52  receives commands from host  24  to store and retrieve data. The main controller carries out the host commands in a parallelized and efficient manner using the hierarchical structure of channel controllers  48  and MSPs  40 . Main controller  52  translates the host commands into recipes, and provides the recipes to the MSPs for execution. Each recipe comprises a list of multiple memory operations, which are to be executed sequentially in a certain subset of memory devices  28 . (As noted above, each subset of memory devices is controlled by a respective MSP.) The main controller sends to each MSP recipes, which specify memory operations that are to be applied to the memory devices in the subset managed by that MSP. Each MSP receives the recipes addressed thereto, and the MSPs execute their designated recipes concurrently. 
       FIG. 2  is a flow chart that schematically illustrates a method for data storage, in accordance with an embodiment. The method begins with host  24  sending host commands to main controller  52  of system  20 , at a command input step  60 . Main controller  52  translates the host commands into recipes, at a recipe generation step  64 . The main controller sends the recipes to the MSPs via the channel controllers, at a recipe sending step  68 . The MSPs execute the recipes, at a recipe execution step  72 . Each MSP translates each of its recipes into a sequence of NAND commands, and issues the NAND commands to the appropriate memory devices  28 . The memory devices accept and execute the NAND commands, at a NAND command execution step  76 . In each memory device  28 , NAND controller  36  accepts the NAND commands addressed thereto and executes them. Following execution of the NAND commands, results of the commands (e.g., retrieved data, acknowledgements of successful data storage and/or error messages) are forwarded from the memory devices back to the MSPs, channel controllers and/or main controller, at a result forwarding step  80 . 
     Main controller  52  may generate various kinds of recipes for execution by the MSPs. Typically although not necessarily, the memory instructions in each recipe access multiple memory pages in memory devices  28 . The term “access multiple pages” in the present context means, for example, write or read multiple memory pages. For example, a “multiple write” recipe instructs the MSP to write a body of data, typically comprising multiple pages, sequentially into a specified address range in memory devices  28 . A “multiple read” recipe instructs the MSP to read a body of data, typically comprising multiple pages, sequentially from a specified address range in memory devices  28 . A “multiple copy” recipe instructs the MSP to copy a body of data, typically comprising multiple pages, from a certain address range in memory devices  28  to another address range in the memory devices. 
     In some embodiments, the “multiple copy” recipe instructs the MSP to modify some of the read data or apply certain processing to the read data, before writing it to the destination address range. In some embodiments, the “multiple copy” recipe instructs the MSP to read the data from two or more different address ranges. This sort of recipe is useful, for example, for implementing “garbage collection” operations that collect the valid pages from two or more blocks and write them into another block. 
     Each of the above-described recipes instructs the MSP to read multiple pages and/or write multiple pages. Another example of recipe is a “multiple erase” recipe, which instructs the MSP to erase one or more memory areas, e.g., multiple erasure blocks. Several additional examples of recipes, which can be used in system  20 , are described further below. 
     Typically, the commands received from host  24  specify data storage and readout using logical addresses. When translating the host commands into the recipes, main controller  52  translates the logical addresses into physical addresses, i.e., physical storage locations in memory devices  28 . Any suitable logical-to-physical translation (often referred to as Logical Block Addressing—LBA) can be used. Thus, the recipes generated by the main controller specify the memory operations using physical addresses (e.g., block and page indices in memory devices  28 ). Typically, MSPs  40  operate according to the physical addresses, and the translation to and from logical addresses is performed at the main controller. 
     In some embodiments, main controller  52  stores information that is to be used by the recipes in DRAM  56  (or in other volatile memory). In these embodiments, the recipes specify that the appropriate information is to be read from the DRAM or written into the DRAM by the MSPs. For example, the “multiple write” recipe may specify that a body of data is to be read from a specified address range in DRAM  56  and stored in a specified address range in devices  28 . 
     Typically, each MSP  40  operates as a master toward the memory devices it controls. In some embodiments, a given MSP may operate as a master toward the channel controller, as well. For example, the MSP may request data transfer services from the channel controller. In an example embodiment, when executing (or preparing to execute) a programming recipe, the MSP may send to the channel controller a request to send it data for programming from the main controller. In response to such a request, the channel controller typically retrieves the requested data from DRAM  56  of the main controller and sends the data to the MSP. 
     As another example, when executing a reading recipe, the MSP may request the channel controller to read the data (which was previously read from memory devices  28 ) from the MSP&#39;s buffers and send it to the main controller. In response to such a request, the channel controller typically reads the appropriate data from the MSP&#39;s buffers and sends the data to the main controller. Using these techniques, the channel controllers can relieve the MSPs and the main controller from some communication tasks, and the system can therefore operate more efficiently. 
     In some embodiments, a given host command is translated to multiple recipes executed by multiple MSPs. For example, when the host interface processor receives a read command from the host, the main processor may translate this command into multiple recipes, each instructing a certain MSP to read data from its designated memory devices. The MSPs execute their respective recipes and send the read data to the host interface processor. The host interface processor collects the data, orders it and sends it to the host. When all data is collected, the host interface processor sends a “command complete” indication to the host. In some embodiments, the host interface processor sends the “command complete” indication to the host as soon as all recipes corresponding to a given host command have been sent to the MSPs, without waiting for acknowledgements from the MSPs or for actual completion of recipe execution, for further improving performance. 
     Recipe Processing in the MSP 
     Typically, each MSP  40  is autonomous in deciding when and how it will execute the recipes received from the channel controller. This autonomy enables the MSPs to execute the recipes in an efficient manner. For example, a given MSP may control and modify the order in which it executes the recipes received from the channel controller. In other words, the MSP does not necessarily execute the recipes in the same order they are received from the channel controller. 
     The MSP may set the recipe execution order based on various criteria. For example, the MSP may set the recipe execution order to optimize the utilization of system resources, e.g., bus utilization, utilization of logic units such as the ECC encoder and/or decoder or error detection circuitry in unit  44 , or utilization of different memory devices  28 . As another example, the MSP may modify the recipe execution order in a way that consolidates multiple random read (or random write) operations into a single sequential read (or write) operation. This technique utilizes the memory devices and their interfaces more efficiently. As yet another example, the MSP may modify the recipe execution order in a way that reduces peak power consumption. Additionally or alternatively, the MSP may set the execution order of the recipes based on any other suitable criterion. 
     In some embodiments, the MSP modifies the order in which pages are programmed or read within a given recipe. Page re-ordering of this sort sometimes assists in reducing interference between memory cells. For example, in some memory devices, data is programmed using an iterative Programming and Verification (P&amp;V) process. In a typical P&amp;V process, the memory device circuitry applies a sequence of programming pulses to the memory cells in a given word line, and verifies the threshold voltages of the cells after each pulse. Programming continues for those cells that have not yet reached their intended threshold voltages. 
     When programming a memory device word line by word line, the P&amp;V process inherently compensates for interference caused to the present word line by previously-programmed word lines. The P&amp;V process typically cannot compensate for interference from word lines that are programmed later. Thus, in some scenarios it is advantageous to read data in reverse order to the order in which it was programmed For example, if the data was programmed into the memory device in ascending order of word lines, it may be advantageous to read the data is descending order of word lines, and vice versa. In some embodiments, the MSP sets the order in which pages are read to be the inverse of the order in which the pages were written. 
     In some embodiments, the MSP applies an interference cancellation process that cancels the interference in a given word line based on the threshold voltages or data of neighboring word lines. Interference cancellation techniques are described, for example, in PCT International Publications WO 2007/132453, 2007/132457 and 2008/026203, whose disclosures are incorporated herein by reference. In these embodiments, the MSP may set the order in which pages are read in a given recipe, so that pages that potentially cause interference to a given page are read adjacently to the interfered page. This technique enables the interference cancellation process to use smaller buffers, and/or to apply interference cancellation using a larger number of neighboring word lines. Alternatively, the MSP may modify the order in which pages are programmed or read in a given recipe based on any other suitable criterion. 
     In some embodiments, the MSP may eliminate some of the read or write operations specified in recipes by considering multiple recipes jointly. For example, if the MSP identifies two or more write operations to the same physical address in different recipes, it may execute only the latest write operation and discard the others. As another example, if the MSP identifies two or more read operations from the same physical address in different recipes, it may execute only the earliest read operation and discard the others. As yet another example, the MSP may detect a program operation that writes data to a certain physical address in one recipe, and a later read operation that reads the data from the same physical address in another recipe. In such a case, the MSP may read the data from its internal buffers instead of reading it from memory devices  28 . Additionally or alternatively, the MSP may decide to eliminate read and/or write operations when executing the recipes, based on any other suitable logic. These techniques enable the MSP to avoid superfluous or unnecessary access to memory devices  28 , and therefore improve system performance. 
     Additionally or alternatively, different recipes or recipe types may be assigned different priorities, and the MSPs may execute the recipes according to their priorities. For example, an MSP may be in the process of executing a certain recipe, when another recipe is received from the main controller. If the priority of the newly-arriving recipe is higher than the priority of the currently-executed recipe, the MSP may temporarily suspend execution of the currently-executed recipe, execute the higher-priority recipe, and then resume execution of the suspended recipe. This technique can be used, for example, by assigning a relatively low priority to recipes having long execution times. Shorter recipes can be assigned higher priorities, and thus need not suffer long delays. 
     Additional Recipe Types 
     In some embodiments, the main controller may send a “merge and write” recipe that requests the MSP to write data into a specified address range in memory devices  28 . In the “merge and write” recipe, part of the data resides in a certain address range in DRAM  56 , while another part of the data resides in a certain address range in memory devices  28 . The “merge and write” recipe can be used, for example, to copy a body of data from one location to another in memory devices  28 , while replacing part of the data with data provided by the main controller. 
       FIG. 3  is a flow chart that schematically illustrates a method for data storage, in accordance with an embodiment. The method begins with MSP  40  receiving a “merge and write” recipe from main controller  52 , at a merge and write input step  90 . The recipe typically specifies (1) an address range in DRAM  56  in which a first part of the data is stored, (2) an address range in memory devices  28  in which a second part of the data is stored, and (3) an address range in memory devices  28  in which the merged data is to be stored. The MSP reads the first part of the data from DRAM  56 , typically using the channel controller services, at a first readout step  94 . The MSP reads the second part of the data from memory devices  28 , at a second readout step  98 . The MSP them merges the first and second parts, and writes the merged data to memory devices  28 , at a merge and write output step  102 . 
     The description of  FIG. 3  assumes that the internal memory of MSP  40  is sufficient for holding both parts of the data in order to perform the merging operation. This assumption typically holds for small data sizes, e.g., when reading a page from memory devices  28 , and replacing a sector in this page with data from DRAM  56 . When the total size of the first and second data parts exceeds the internal storage capacity of MSP  40 , the MSP may store the data temporarily in DRAM  56  and perform the merging operation using the DRAM. 
     In some embodiments, the main controller generates an “indirect read” recipe. The “indirect read” recipe specifies a physical address, whose content indicates (e.g., points to) the address from which data is to be retrieved. In other words, the “indirect read” recipe instructs the MSP to perform the following:
         Read a physical address X specified in the recipe.   Decode the data read from physical address X, and use the decoded data as another physical address Y.   Read physical address Y, and return the data read from physical address Y as the recipe output.       

     The “indirect read” recipe is an example of a recipe in which the MSP decodes the retrieved data and uses this data in order to configure the operations in the recipe. In alternative embodiments, other types of recipes may modify the recipe operation based on the read data in any other suitable way. 
     Efficient Recipe Execution Using Main Controller Dram 
     In some embodiments, MSPs  40  use DRAM  56  as an external memory resource when executing recipes. Typically, the available memory space in DRAM  56  is considerably larger than the internal memory of the MSP, and using the DRAM enables the MSPs to execute recipes more efficiently. Consider, for example, a “multiple copy” recipe that instructs a given MSP to copy N pages from one location to another in memory devices  28 . In the present example, the MSP is able to buffer internally only up to K pages, K&lt;N. 
     It is possible in principle for the MSP to read a group of K pages at a time, and write it to its destination before reading the next group. Alternatively, however, the MSP can read all N pages sequentially and store them in DRAM  56 . Then, the MSP can program the N pages sequentially from the DRAM to their destination in memory devices  28 . Reading and writing all N pages sequentially is considerably more efficient, for example since it enables to MSP to operate in a pipeline and use the memory devices&#39; cache commands. Thus, the copying speed is increased. 
     Some host commands involve transferring large amounts of data from DRAM  56  to memory devices  28 . The data may be addressed to multiple memory devices and MSP, and therefore often involves generation and execution of multiple recipes. Executing such commands may result in considerable computation and communication load on the main controller. In some embodiments, system  20  relieves most of this computation and communication load by transferring more functions to the channel controllers and MSPs. 
     For example, in some embodiments the main controller formats data for storage as a linked list of data items, referred to as cache lines. Each cache line is stored in a certain location in DRAM  56 . Each cache line holds a portion of the data, and a pointer to the location in DRAM  56  of the next cache line. In order to store the data, the main controller sends to a given MSP a program recipe which comprises a pointer to the first cache line in the list. Note that no data is typically transferred in this recipe, only the pointer. 
     Upon receiving this recipe, the MSP requests the channel controller to prepare the first cache line. The channel controller reads the requested cache line from the DRAM and sends it to the MSP. The MSP stores the data from the cache line in memory devices  28 . In addition, the MSP extracts the pointer to the next cache line from the present cache line data, and uses this pointer to request the channel controller to prepare the next cache line. The process continues until the entire list of cache lines has been transferred from DRAM  56  to memory devices  28 . When storage is completed, the MSP issues a “program complete” notification. As can be appreciated, most of the processing load in this process is shifted to the MSP and channel controller. 
     In alternative embodiments, the MSP can store any other suitable data in DRAM  56 , as part of the recipe execution. Typically, the recipes produced by main controller  52  instruct the MSPs as to how to use the DRAM. 
     Recipe Execution Using Memory Cell Properties Stored in DRAM 
     In some embodiments, main controller  52  stores in DRAM  56  certain properties of groups of memory cells  32 , e.g., of erasure blocks or even individual word lines. MSPs  40  may use the information stored in DRAM  56  when executing recipes. In some embodiments, the main controller indicates the memory cell properties as part of the recipe. Alternatively, the MSP may query the information stored in the DRAM when executing the recipe. 
     For example, memory devices  28  may program the memory cells using a P&amp;V process, as described above. In a typical P&amp;V process, the cell threshold voltages are compared with certain Programming Verification (PV) levels, which indicate the desired threshold voltages corresponding to the different programming states. The optimal PV levels may differ from one group of memory cells to another, and/or vary over time, for various reasons. In some embodiments, main controller  52  stores the desired PV levels to be used with different cell groups (e.g., PV levels for each erasure block) in DRAM  56 . When the main controller generates a recipe for programming data in a certain cell group, the main controller may indicate the PV levels to be used in programming the cell group in question. The recipe format may include a field dedicated for this purpose. When executing such a recipe, the MSP instructs the NAND controller to apply the PV levels specified in the recipe. 
     As another example, data is typically read from analog memory cells by comparing the cells&#39; threshold voltages to certain read thresholds. The optimal read threshold values may vary over time, and/or between one cell group to another, for various reasons. In some embodiments, the main controller stores the read threshold values to be used for reading different cell groups (e.g., read thresholds for each erasure block) in DRAM  56 . When the main controller generates a recipe for reading data from a certain cell group, the main controller may indicate the read thresholds to be used in programming the cell group in question. The recipe format may include a field dedicated for this purpose. When executing such a recipe, the MSP instructs the NAND controller to apply the read thresholds specified in the recipe. 
     In some embodiments, the optimal read threshold values are calculated by the MSPs and provided to the main controller for storage in the DRAM. Any suitable method for calculating read thresholds can be used. Example methods are described in PCT International Publication WO 2007/132457, cited above, and PCT International Publications WO 2008/111058 and 2008/053472, whose disclosures are incorporated herein by reference. The main controller may send a given MSP a “read threshold acquisition” recipe, which contains a list of memory operations that determine the optimal read thresholds in a given block or other cell group. 
     Other examples of properties of memory cell groups that can be stored in DRAM  56  comprise the endurance of the cell group (e.g., the number of programming and erasure cycles the cell group has gone through), the time that elapsed since the last programming of the cell group, the estimated read disturb (or other interference) in the cell group, an integral of the cell group temperature over time (which is a measure of the cell group&#39;s wear level), and/or any other suitable property. Any of these properties can be reported to the MSPs as part of the recipes, and the MSPs can configure the readout or programming operations in any suitable way based on the reported properties. 
       FIG. 4  is a flow chart that schematically illustrates a method for data storage, in accordance with an embodiment. The method begins with main controller  52  storing properties of different groups of memory cells, at a property storage step  110 . When generating a recipe to be applied to a certain group of memory cells, the main controller inserts the properties of the cell group in question into the recipe, at a property specification step  114 . The main controller sends the recipe, including the specified properties, to one of the MSPs, at a recipe forwarding step  118 . The MSP executes the recipe based on the memory cell group properties reported in the recipe, at an execution step  122 . 
     Additional Variations and Embodiments 
     As noted above, main controller  52  typically translates the logical addresses specified in the host commands into physical addresses, and uses the physical addresses when generating the recipes. In some embodiments, system  20  uses this translation to ensure that the correct data in memory devices  28  is being accessed. In an example embodiment, at least some of the recipes comprise a field in which the main controller indicates the logical address of the data. When programming data (e.g., a block) in memory devices  28 , the MSP stores the logical address indicated in the “write” recipe together with the data. When requesting to read the data, the main controller indicates the logical address of the data as part of the “read” recipe. In response to the “read” recipe, the MSP reads the data, extracts the logical address from the read data, and compares the extracted logical address with the logical address indicated in the “read” recipe. If the stored logical address does not match the logical address indicated in the “read” recipe, the MSP issues an error message. 
     In some embodiments, MSPs  40  copy memory pages from one location to another in memory devices  28  during operation of system  20 . These copy operations may comprise, for example, “garbage collection” operations in which the MSP copies valid pages from one block to another in order to free sparsely-programmed blocks for erasure. As noted above, the main controller typically holds a logical-to-physical address mapping, for translating the logical addresses specified by the host into physical addresses in memory devices  28 . 
     When performing the above-described copy operations by the MSPs, the logical-to-physical address mapping in the main controller should be updated to reflect the updated physical locations of the copied data. This task is often complex, since the logical-to-physical address mapping typically comprises a very large number of entries, and the main controller has no straightforward way of determining which logical addresses should be mapped to new physical locations. 
     As noted above, the MSP stores the logical address indicated in the “write” recipe together with the data in memory devices  28 . In some embodiments, system  20  uses this information to update the logical-to-physical address mapping in an efficient manner. In an example process, the MSP receives a recipe that instructs it to copy data from certain source physical addresses to respective destination physical addresses. When copying a given page, the MSP extracts and records the logical address corresponding to this page (which has been stored together with the data by the “write” recipe”). After completing the copy recipe, the MSP sends to the main controller a list of the logical addresses that were subjected to the copy operations, and the respective new physical addresses to which the logical addresses should now correspond. The main controller updates its logical-to-physical address mapping based on this information. Using this technique, the main controller need not search or otherwise determine which logical addresses were affected by the copy operations, since the logical addresses are provided explicitly be the MSPs. 
     As noted above, the main controller may hold in DRAM  56  a data structure that records the optimal read threshold values for different groups of memory cells (e.g., for different blocks). The main controller and/or MSPs may manage and update this information during system operation in any suitable way. In some embodiments, the read thresholds of a certain block can be adjusted during each read operation from the block. In an embodiment, whenever the MSP reads a certain word line from a given block, it updates the main controller with the read thresholds that were found to be optimal in that read operation. The main controller updates the data structure in DRAM  56  accordingly. Thus, when the MSP will encounter another read operation from the same block in the future, it can perform the readout using the read thresholds that were previously found to be optimal for the block. This technique assumes that the differences in read threshold values between different word lines in a block are relatively small (or that the differences can be compensated for using other means). 
     Additionally or alternatively, when the MSP calculates an initial estimate of the read thresholds with no prior information, or using read thresholds that highly non-optimal, it reports the read thresholds found to be optimal to the main controller. The main controller updates the data structure in DRAM  56  accordingly. Acquisition may be performed for a given word line in a block. This technique is useful, for example, when large differences exist in the read threshold values between different word lines in the block. In some embodiments, the main controller or MSP may initiate an acquisition process for blocks for which no read threshold information exists in the data structure. These acquisition attempts may be performed, for example, during idle times of the system. This technique increases the likelihood of finding up-to-date read threshold information regarding a given block in the data structure. 
     It will be appreciated that the embodiments described above are cited by way of example, and that the present embodiments are not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present embodiments include both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art. 
     Refer to the system described in  FIG. 5 . A Memory Controller is connected to N Memory devices. The Memory Controller is connected to a Host the controls the system. The Host has more memory resources, as it is connected to an external DRAM. 
     An example for such a system is a Cellular Phone, where the Host is the processor that controls the system and the Memory Controller is an eMMC/SD controller that implements the storage functionality. In this example, the eMMC/SD controller has limited memory resources, whereas the Host has a large amount of DRAM. 
     Generally, there can be a few Memory Controllers connected to one Host. The Memory Controller can reside on the same die of the Memory Device, on the same die as the Host, on a different die, that reside in the same Multi-Chip Package (MCP), or on different packages. It is also possible that all entities reside on the same die. 
     In the proposed method, the Memory Controller stores and retrieves data that is required for its functionality to/from the DRAM connected to the Host. The Host and the Memory Controller are connected via so called Memory I/F 2. Examples for such interfaces are: NAND I/F, uSD I/F, eMMC I/F, UFS I/F, SATA I/F, USB I/F. Usually the Host is the Master, while the Memory Controller is the slave. As a result, the Memory Controller cannot send commands to the Host, asking to store or retrieve data. Therefore, it is suggested that the Memory Controller will use a signal, for example, the ready/busy signal line in the NAND I/F, to indicated the Host it requires to store/retrieve data. 
     Whenever the Host sends a read or write command to the Memory Controller, it also includes Meta-Data, to exchange data between the two components. 
     The host may store the parameters required by the Memory Controller in the DRAM. For example, every time the Memory Controller performs page read, it transfers to the host the read thresholds besides the data. The Host stores the read thresholds in its DRAM. When the host instructs the Memory Controller to read, it also transfers the read thresholds. This enables faster operation of the Memory Controller.